XnView Software

xnview wrote:(...) By using tabbar at the top, i think that it's better. (...)

Maybe this will help you with your decisions. I am not sure, but well...

1.) Mouse movements; It is always easier and faster to move the mouse UPwards, because an upward flick with the wrist away with the arm in a lying position on the table is naturally easier, than to pull it back towards the position of the arm. Try it for yourself, you will see, it is harder, and not so good to control than any upway movements. Therefore, placing menues at the top of an application of the screen (yes, also the Win-Taskbar/Startmenue), will always grant faster access of buttons, tabs, etc..

2.) The eye; Looking upwards with the eyes is also more "natural", aka. more precise than looking down. Don't ask me why. Maybe thousands of years hunting mammals helped a lot. Try it. Try to find something on the lower place from your screen, maybe after you typed something, and than on the top of the screen. Should at least be more precise (and quicker) to find something with your mousepointer, though.

To sum it all up, I would love to have the toolbar more on the top.

Maybe this was of help.

Well, I don't code in Qt4, but can't you define two "contextual boxes", one above the tabbar (the menu, which can be only a toolbar) and one below (with everything else), and don't use the normal menu at all ?
Changing tab will change both contexts.
Of course, I think problems will arise on OSX. I'm not shure on how Qt4 interfaces with the menu bar of OSX.

Once again, if I'm saying something silly, I apologize.

But once again, I would say don't focus too much on this if this is preventing you from progressing on XnViewMP. Maybe you could keep a single menu for every context for now.

The basic placement of XnView's UI elements is very important and shouldn't be changed without deep consideration and for very good reason.

Some comments:

If the document tabs (Browser 1..n, Viewer 1..n, Compare 1..n, etc) are at the top of the XnView window, with the menu beneath them, then the UI implication is that: each kind of tab (ie, browser, viewer, slide show, compare, etc) has it's own unique menu bar.

I like that approach and could get used to it, if indeed the menus differed. Otherwise (if the menu doesn't change), the relationship between tabs, menu, and window contents becomes ambiguous and possibly confusing to the user. In that case it would not make good UI sense to put the menu beneath the document tabs by default.

Now, if the user wants to move the menu, that's another thing.

An important guideline for good UI design is that the hierarchy of user tasks/data matches (i.e. is accurately mapped by) the corresponding hierarchy of UI controls and data "containers".

JohnFredC wrote: I like that approach and could get used to it, if indeed the menus differed.

It's already like that, browser has a different menu than viewer

Pierre

Hello !

• About the GUI design, I ought say that I dislike totally the vertical tabs in the browser, it's just to get a stiff neck…
… except for the (rare) 90°-necked users :



• I guess that the labels might be written vertically too (one line per character, good luck…),
or rather an icon+info-text could do the trick much better…

- Just my 0.10 € (inflation is running…)

KR
Claude
Clo

Clo wrote:

Hello, I noticed the treatment for that rare affliction is found in ini.
[Browser]
vTabs=false

marsh

Hello B. !

• I dislike the labels on the vertical tabs, and of course I have already changed the INI entry.
- However, I get normal - but too small- tabs instead at the left-bottom (Layout #4)…
- IMHO, we miss an option allowing to keep the larger V-tabs, but either with readable captions,
or a symbol+info text, like I said above…

KR
Claude
Clo