Question about 8.80.0009 Changelog

[Mesh]

The changelog for 8.80.0009 lists this:

Code: Select all

v8.80.0009 - 2010-01-05 10:53
  +++ Now the various edit box dialogs are resizable. In case of Quick 
      File View and Try Script the size and position are stored between 
      calls and sessions.

Does this mean that the Rename Preview window is now resizeable as well?

[admin]

The changelog for 8.80.0009 lists this:

Code: Select all

v8.80.0009 - 2010-01-05 10:53
  +++ Now the various edit box dialogs are resizable. In case of Quick 
      File View and Try Script the size and position are stored between 
      calls and sessions.

Does this mean that the Rename Preview window is now resizeable as well?

LOL, I waited for you to come up with this. Well, ok, I'll see whether I can do that now...

[Mesh]

LOL, I waited for you to come up with this. Well, ok, I'll see whether I can do that now...

I'm kind of surprised you remembered all that!

Thanks for looking into this.

[ilya]

Does this mean that the Rename Preview window is now resizeable as well?

LOL, I waited for you to come up with this. Well, ok, I'll see whether I can do that now...

And Customize File Associations window?

[ilya]

And Action Log window

[admin]

And Action Log window

(ok)

[zer0]

(ok)

Let's keep riding this wave I noticed that you've added minimise/maximise buttons to titlebars of various dialogue windows. Yet, the minimise button is always greyed out. Is its presence an unfortunate by-product of adding maximise or are you seriously toying with an idea of allowing us to minimise windows?

[admin]

Is its presence an unfortunate by-product of adding maximise)

yes.

[zer0]

yes.

Hmmm, I was hoping you wouldn't say that word Bearing in mind that not every dialogue box is contingent upon have item(s) (or set thereof) selected in Tree/List, what difficulties would it pose to remove the minimising restrictions?

[jacky]

yes.

Hmmm, I was hoping you wouldn't say that word Bearing in mind that not every dialogue box is contingent upon have item(s) (or set thereof) selected in Tree/List, what difficulties would it pose to remove the minimising restrictions?

At the same time, it would be quite a silly idea to allow minimizing a modal window, as it is quite certain to cause more trouble than anything else.

On another note, I do like those recent changes as well, I am particularly happy to have my QFV eating up almost all my screen space! Thanks for that. One note about it though, I'd like it if, in Hex view, you could check how wide the window will be and then show data accordingly.

Right now in hex view I have more than half of the QFV blank, which is a waste (and I guess in reverse you could have some with a (little) Hscrollbar which could be a PITA).

Side note: didn't see that with the recent addition of LM to the mix, but for QFV and Try Script at least IIRC, the windows were originally not centered but on the top-left corner, which was much less nice. (Also, since I have my taskbar on top and that wasn't taken into account, I couldn't see the upper side of said windows, always a PITA when that happens.)

Finally, and then I'll let you relax , 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. Why?
- Because I'd love to look as something like this:

Code: Select all

$f      Would
$foo    Be
$foobar Aligned

And have it be aligned. With your 2-space conversion (or 3-space conversion as the forum seems to do, hence why I didn't use tabs here) such things are quite messed up/harder to read. Tabs were actually used, and it looked like this
- In the same idea, when selecting/copying stuff, we don't copy one tab but 2 spaces, thus again messing up everything.

For now my fix is to use QFE instead, because in text/edit area one tab is one tab so I can see stuff aligned and copy them as they are, but I would like it if QFV would allow me to view files as they actually are...

Lastly, since I'm not sure I said anything since last year, happy new year everyone!

[admin]

Hi jacky,

Agreed about the TABs.
I'll check what I can do for hex view.

happy new year!
don

[mwb1100]

At the same time, it would be quite a silly idea to allow minimizing a modal window, as it is quite certain to cause more trouble than anything else.

Unless it minimizes the whole app, in which case it can be useful at times.

[admin]

At the same time, it would be quite a silly idea to allow minimizing a modal window, as it is quite certain to cause more trouble than anything else.

Unless it minimizes the whole app, in which case it can be useful at times.

True, but I can't get this to work; the minimize part works, but the restore does not play along. Too lo prio ATM to investigate further.

PS: looks like Win7 has the same problem: http://www.windows7taskforce.com/view/1839

[zer0]

yes.

Hmmm, I was hoping you wouldn't say that word Bearing in mind that not every dialogue box is contingent upon have item(s) (or set thereof) selected in Tree/List, what difficulties would it pose to remove the minimising restrictions?

At the same time, it would be quite a silly idea to allow minimizing a modal window, as it is quite certain to cause more trouble than anything else.

Au contraire mon freire

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

That being said, there is precedent in minimising/maximising modal windows. A couple of examples are Adobe Photoshop CS4 and FullShot 9.5 (there are more, but can't think of any off the top of my head). No, I admit, they are not file managers, but I compared to Explorer on Win 7 and no truly modal window allows maximisation. In XYplorer, absolutely every child window is a modal window -- this is completely unnecessary. From my understanding, modal windows are typically used in the following 4 situations:

1. Attracting attention to something vital
2. Blocking the flow in order for essential-to-continue information to be entered
3. Collection of configuration options that are applied upon clicking "OK/Apply"
4. Warning about irreversibility of actions if one proceeds

Now please do tell in which of those categories modal windows like "Try Script", "Customize Toolbar", "About...", "Action Log" fall into? What trouble would it be to transform them into transient windows? Not only this would mean that not-essentially-modal windows could be minimised, but it'd also make possible to minimise XYplorer while carrying on working in a child window. Two birds. A stone. Death

[jacky]

At the same time, it would be quite a silly idea to allow minimizing a modal window, as it is quite certain to cause more trouble than anything else.

Unless it minimizes the whole app, in which case it can be useful at times.

Well, but it would be a completely different wish then. Also, one that I would probably find odd/unexpected, considering I don't think such a behavior is standard/expected/seen elsewhere. As implied in Don's answer, this isn't a standard Windows behavior.

Au contraire mon freire

(For the record, it probably should be "Au contraire, mon frere". There's no "i" in frère.)

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.

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)
(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?...)