Page 2 of 3
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 12:34
by zer0
jacky wrote:zer0 wrote:It is, in fact, silly to allow maximisation of modal windows outside the scope of XYplorer. As I'm sure you know, a modal window is a child window, so how come it can be maximised to fill the whole screen while XYplorer takes up less than that? Why a child window can outsize its parent? It makes one confused whether it's a child window after all
What you're saying doesn't make sense. Allowing to resize/move/maximized a modal window is perfectly fine, normal and not confusing at all. It can in fact be pretty useful. Allowing its minimizing however is a completely different situation, and a silly thing to do. Maximizing != Minimizing, the two have different uses/implications.
Uhuh, allowing to resize/maximise a modal window is not perfectly fine. A modal window must already been designed to encompass all the necessary components and not need resizing or maximising. Move -- sure. Can you please think of some examples of mainstream software where modal windows can be resized/maximised? I really can't think of any (apart from those I mentioned already).
jacky wrote:As for trying to change your original wish into a "make modal windows non-modal", that's another thing entirely. You say it is "completely unnecessary", but who are you to say this? Maybe there are implications that you haven't considered but make this behavior a necessity.
Sure, from a user POV I guess some windows such as Try Script could be non-modal, and reactivated if triggered again, but maybe there are things we don't/can't see. Plus, to do the same for LM or Action Log could create new unnecessary issues (like a lack of updating the AL while the widow is shown and XY used in the mean time, which could lead to loss in the AL upon its validation, etc)
Who am I to say this? Well, a user of this software
I looked at various modal windows and tried to think of reasons why XYplorer
needs for me to keep that window modal and couldn't think of any. Sure, there may be implications I don't know of, but I can't disregard my conclusions due to such. As for AL, having it non-modal would mean that appropriate synchronisation mechanism would need to be established. It is perfectly feasible for me to do something in XYplorer, go into AL and undo something that has nothing to do with what I've just done (prior to going into AL). Therefore, it becomes non-essential for AL to be modal, since impact of actions within it is equally likely to affect or not affect what I'm currently doing.
jacky wrote:(As for the About window, it's a very common thing to have such a dialog modal; and there's no real reason to need/want to have this window non-modal/visible while using XY. Is there any real motivation behind this one at all?...)
Yes, my experience with other applications. Firefox allows minimisation of About window, as does QuickTime Player -- just a couple to begin with. Another reason is that XY's About window has more information that a standard About window. It has e-mail and web links for a user to return to for quick access to those (ideally, it should also have a link to EULA). The whole "Help" menu would benefit from a redesign, but I'll reserve my ideas for that GUI thread in the "Wishes" section
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 15:31
by jacky
zer0 wrote:Uhuh, allowing to resize/maximise a modal window is not perfectly fine. A modal window must already been designed to encompass all the necessary components and not need resizing or maximising. Move -- sure. Can you please think of some examples of mainstream software where modal windows can be resized/maximised? I really can't think of any (apart from those I mentioned already).
Sure it is, maybe you don't see it but it is. I don't really have the time (nor the will) to look for examples where it's done, but I know in EPP the window to config menus/toolbar is a resizable modal one, and it's perfectly fine. Just look at the Quick File View in XY, why the Hell should we not be allowed to resize that window? How about any "Edit Script" window in XY (editing Catalog item, etc), why the hell should we not be allowed to maximized those while working on our scripts, even though it's a modal window (and even if XY isn't maximized itself) ?
zer0 wrote:Yes, my experience with other applications. Firefox allows minimisation of About window, as does QuickTime Player -- just a couple to begin with.
Okay, well if your motivations for such changes are only to mimic other apps...
IMO everyone would benefit incredibly more if Don kept working on looking forward and creating/inventing new features that don't exists elsewhere and allow (us to) gain in productivity, instead of just mimicking such (unimportant) little things just for the sake of it.
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 16:18
by j_c_hallgren
jacky wrote:zer0 wrote:Uhuh, allowing to resize/maximise a modal window is not perfectly fine. A modal window must already been designed to encompass all the necessary components and not need resizing or maximising. Move -- sure. Can you please think of some examples of mainstream software where modal windows can be resized/maximised? I really can't think of any (apart from those I mentioned already).
Sure it is, maybe you don't see it but it is. I don't really have the time (nor the will) to look for examples where it's done, but I know in EPP the window to config menus/toolbar is a resizable modal one, and it's perfectly fine. Just look at the Quick File View in XY, why the Hell should we not be allowed to resize that window? How about any "Edit Script" window in XY (editing Catalog item, etc), why the hell should we not be allowed to maximized those while working on our scripts, even though it's a modal window (and even if XY isn't maximized itself) ?
I'm definitely on jacky's side on this one! There are times when I want to see QFV along with some other data like list/tree/etc and there are times I don't so allowing me to fully control size is ideal!
Now maybe if the child window at max size was such that XY parent titlebar still showed, then that would be better so you'd always have the overall min/max/exit controls available...not sure if this is possible but I wouldn't mind loosing that tiny bit of screen to have XY parent titlebar show.
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 16:38
by avsfan
j_c_hallgren wrote:I'm definitely on jacky's side on this one! There are times when I want to see QFV along with some other data like list/tree/etc and there are times I don't so allowing me to fully control size is ideal!
I guess one question I have specifically regarding QFV is: why is this a modal window? There have been quite a few times I've popped it open and then tried to do something else in the XY window, and had to close QFV before I could do anything -- that's a pain... I agree that having it resizable is a good thing, though...
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 16:50
by admin
avsfan wrote:j_c_hallgren wrote:I'm definitely on jacky's side on this one! There are times when I want to see QFV along with some other data like list/tree/etc and there are times I don't so allowing me to fully control size is ideal!
I guess one question I have specifically regarding QFV is: why is this a modal window? There have been quite a few times I've popped it open and then tried to do something else in the XY window, and had to close QFV before I could do anything -- that's a pain... I agree that having it resizable is a good thing, though...
This window is used for a lot of things in XY, it just looks different every time. It must be modal, else many things would not work while it is open.
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 16:52
by avsfan
admin wrote:avsfan wrote:j_c_hallgren wrote:I'm definitely on jacky's side on this one! There are times when I want to see QFV along with some other data like list/tree/etc and there are times I don't so allowing me to fully control size is ideal!
I guess one question I have specifically regarding QFV is: why is this a modal window? There have been quite a few times I've popped it open and then tried to do something else in the XY window, and had to close QFV before I could do anything -- that's a pain... I agree that having it resizable is a good thing, though...
This window is used for a lot of things in XY, it just looks different every time. It must be modal, else many things would not work while it is open.
Ah, OK. That explains a lot, and answers my next question, which was going to be if it would be possible to have multiple child QFV windows open... Obviously not, given this situation!
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 17:00
by admin
avsfan wrote:admin wrote:avsfan wrote:j_c_hallgren wrote:I'm definitely on jacky's side on this one! There are times when I want to see QFV along with some other data like list/tree/etc and there are times I don't so allowing me to fully control size is ideal!
I guess one question I have specifically regarding QFV is: why is this a modal window? There have been quite a few times I've popped it open and then tried to do something else in the XY window, and had to close QFV before I could do anything -- that's a pain... I agree that having it resizable is a good thing, though...
This window is used for a lot of things in XY, it just looks different every time. It must be modal, else many things would not work while it is open.
Ah, OK. That explains a lot, and answers my next question, which was going to be if it would be possible to have multiple child QFV windows open... Obviously not, given this situation!
Of course I could add that (by adding a separate window object just for this job), but I think it's out of scope of a file manager. And XY makes it so easy to use an external app for this.
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 17:32
by avsfan
admin wrote:avsfan wrote:Ah, OK. That explains a lot, and answers my next question, which was going to be if it would be possible to have multiple child QFV windows open... Obviously not, given this situation!
Of course I could add that (by adding a separate window object just for this job), but I think it's out of scope of a file manager. And XY makes it so easy to use an external app for this.
Sure -- that makes sense. That's what I usually do now, anyway...
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 17:42
by admin
avsfan wrote:admin wrote:avsfan wrote:Ah, OK. That explains a lot, and answers my next question, which was going to be if it would be possible to have multiple child QFV windows open... Obviously not, given this situation!
Of course I could add that (by adding a separate window object just for this job), but I think it's out of scope of a file manager. And XY makes it so easy to use an external app for this.
Sure -- that makes sense. That's what I usually do now, anyway...
PLus in one of the next versions I will add a very noob-friendly (I don't mean you) way to define a (external) viewer-avec-KS that will even work in the Home exdition.
Re: Question about 8.80.0009 Changelog
Posted: 08 Jan 2010 23:04
by zer0
jacky wrote:zer0 wrote:Uhuh, allowing to resize/maximise a modal window is not perfectly fine. A modal window must already been designed to encompass all the necessary components and not need resizing or maximising. Move -- sure. Can you please think of some examples of mainstream software where modal windows can be resized/maximised? I really can't think of any (apart from those I mentioned already).
Sure it is, maybe you don't see it but it is. I don't really have the time (nor the will) to look for examples where it's done, but I know in EPP the window to config menus/toolbar is a resizable modal one, and it's perfectly fine. Just look at the Quick File View in XY, why the Hell should we not be allowed to resize that window? How about any "Edit Script" window in XY (editing Catalog item, etc), why the hell should we not be allowed to maximized those while working on our scripts, even though it's a modal window (and even if XY isn't maximized itself) ?
Why does a config menus/toolbar have to be a resizeable modal window? All the config options are already there. Where is the benefit in resizing a config window if one can just move it to another place?
Regarding QFV window, if you wish to resize it then it might as well be a transient window so that one has complete control of what happens to it. Making it a transient window will allow me to minimise it as well. No harm in minimising a preview window, right? Regarding "Edit Script" window, if one has a reason to maximise it, then one would have just as much reason to minimise it, yet having it modal won't allow for that. Modifying a script and using XY to do file management can be concurrent activities, yet at present they clash, because one is required to finish editing a script before one is allowed to do something else -- too tight of a restriction.
jacky wrote:zer0 wrote:Yes, my experience with other applications. Firefox allows minimisation of About window, as does QuickTime Player -- just a couple to begin with.
Okay, well if your motivations for such changes are only to mimic other apps...
IMO everyone would benefit incredibly more if Don kept working on looking forward and creating/inventing new features that don't exists elsewhere and allow (us to) gain in productivity, instead of just mimicking such (unimportant) little things just for the sake of it.
Errr, quite a few features in XY resemble (a synonym for mimiced) those from other apps, there's precedent for that. Also, look at the roadmap: more of such to come.
Please bear in mind that my biggest grunt isn't with resizeability, but with not being able to minimise any of the windows that XYplorer shows. If you're in favour of productivity enhancements, then I hope that you'd agree that launching an "Edit Script" window, minimising it, starting a file transfer using XYcopy (when it comes!), going back to my "script editor", do a script while the transfer happens and when it finishes my script will be ready to apply (or not) to freshly-transferred files is all for the benefit of productivity. More work is being done simultaneously. Sure, some possible concerns would need to be addressed, but that's nothing new
Re: Question about 8.80.0009 Changelog
Posted: 09 Jan 2010 08:22
by j_c_hallgren
jacky wrote:I have one more wish about QFV : it seems you decided to trade one tab for 2 spaces when showing files. I'm sure you like that, but I don't and I'd wish it could change, and you'd use actual tabulations instead.
Which in v8.80.13 was done as:
Code: Select all
* Quick File View and Raw View: Now TAB characters are expanded (by system default drawn as 8 spaces). Before, they were internally replaced by 2 spaces.
Well, that be nice for some, but in the two editors that I use most often, the tab is equal to FOUR spaces and thus my spacing now looks quite wacky (2 is closer to 4 than to 8! ) and items are getting shoved quite far over...so...given that I've seen where this value can be set within an editor pref's, could this be available via tweak here as minimum? Please?
Re: Question about 8.80.0009 Changelog
Posted: 09 Jan 2010 09:25
by admin
j_c_hallgren wrote:jacky wrote:I have one more wish about QFV : it seems you decided to trade one tab for 2 spaces when showing files. I'm sure you like that, but I don't and I'd wish it could change, and you'd use actual tabulations instead.
Which in v8.80.13 was done as:
Code: Select all
* Quick File View and Raw View: Now TAB characters are expanded (by system default drawn as 8 spaces). Before, they were internally replaced by 2 spaces.
Well, that be nice for some, but in the two editors that I use most often, the tab is equal to FOUR spaces and thus my spacing now looks quite wacky (2 is closer to 4 than to 8! ) and items are getting shoved quite far over...so...given that I've seen where this value can be set within an editor pref's, could this be available via tweak here as minimum? Please?
Hmm, I expected this kind of problem. It was the reason for me to originally use 2 spaces for the tabs. So I guess now we need that setting that is also present in all editors:
Tab Stop Value.
Okay?
Re: Question about 8.80.0009 Changelog
Posted: 09 Jan 2010 16:44
by jacky
admin wrote:Hmm, I expected this kind of problem. It was the reason for me to originally use 2 spaces for the tabs. So I guess now we need that setting that is also present in all editors: Tab Stop Value. Okay?
If that can get everyone happy, why would anyone be against that? And thanks for doing this, I like seeing/copying things aligned
Code: Select all
* Quick File View: Now the Hex View remembers its own width
independently of the Text View width.
So I see what you did there, not really what I had in mind. Instead of remembering a different size, I was more thinking of showing as much data as possible with the current size. IOW, going from something like this:
Code: Select all
00000000: 52 49 46 46 1C 6D E1 2B 41 56 49 20 4C 49 53 54 RIFF.má+AVI LIST
00000010: 72 22 00 00 68 64 72 6C 61 76 69 68 38 00 00 00 r"..hdrlavih8...
00000020: EC A2 00 00 00 00 00 00 00 00 00 00 10 01 00 00 ì¢..............
00000030: 7A F2 00 00 00 00 00 00 02 00 00 00 00 00 00 00 zò..............
00000040: C0 03 00 00 20 02 00 00 00 00 00 00 00 00 00 00 À... ...........
00000050: 00 00 00 00 00 00 00 00 4C 49 53 54 94 10 00 00 ........LIST”...
00000060: 73 74 72 6C 73 74 72 68 38 00 00 00 76 69 64 73 strlstrh8...vids
00000070: 78 76 69 64 00 00 00 00 00 00 00 00 00 00 00 00 xvid............
00000080: E9 03 00 00 C0 5D 00 00 00 00 00 00 7A F2 00 00 é...À]......zò..
00000090: 9E 04 02 00 10 27 00 00 00 00 00 00 00 00 00 00 ž....'..........
To something like this:
Code: Select all
00000000: 52 49 46 46 1C 6D E1 2B 41 56 49 20 4C 49 53 54 72 22 00 00 68 64 72 6C 61 76 69 68 38 00 00 00 RIFF.má+AVI LISTr"..hdrlavih8...
00000020: EC A2 00 00 00 00 00 00 00 00 00 00 10 01 00 00 7A F2 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ì¢..............zò..............
00000040: C0 03 00 00 20 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 49 53 54 94 10 00 00 À... ...................LIST”...
00000060: 73 74 72 6C 73 74 72 68 38 00 00 00 76 69 64 73 78 76 69 64 00 00 00 00 00 00 00 00 00 00 00 00 strlstrh8...vidsxvid............
00000080: E9 03 00 00 C0 5D 00 00 00 00 00 00 7A F2 00 00 9E 04 02 00 10 27 00 00 00 00 00 00 00 00 00 00 é...À]......zò..ž....'..........
But if that's too much, that's ok, I'll be fine with the current situation.
Re: Question about 8.80.0009 Changelog
Posted: 09 Jan 2010 17:33
by j_c_hallgren
jacky wrote:admin wrote: So I guess now we need that setting that is also present in all editors: Tab Stop Value. Okay?
That would be GREAT!
jacky wrote:To something like this:
Code: Select all
00000000: 52 49 46 46 1C 6D E1 2B 41 56 49 20 4C 49 53 54 72 22 00 00 68 64 72 6C 61 76 69 68 38 00 00 00 RIFF.má+AVI LISTr"..hdrlavih8...
00000020: EC A2 00 00 00 00 00 00 00 00 00 00 10 01 00 00 7A F2 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ì¢..............zò..............
I would never use a display like this myself as I find it very hard to read...but if you like it, ok!
Re: Question about 8.80.0009 Changelog
Posted: 09 Jan 2010 18:44
by jacky
j_c_hallgren wrote:I would never use a display like this myself as I find it very hard to read...but if you like it, ok!
You realize the only single difference is that I use all the space available in the QFV window, instead of just half of it, and nothing else?