(I have some problem with previous solution)
Interface...
Moderators: XnTriq, helmut, xnview
Interface...
What do you think if the menu is swapped with tabbar (tabbar could be on the top or on the bottom)?
(I have some problem with previous solution)
(I have some problem with previous solution)
Pierre.
Re: Interface...
Currently you have a tab 'browser', and a tab 'preview'.
The tab 'preview' is the same view as the preview in browser (current selected item). This is for example to edit the current picture.
But you can open a new tab (a new view of a picture) to edit it...
What do you think about this behaviour?
The tab 'preview' is the same view as the preview in browser (current selected item). This is for example to edit the current picture.
But you can open a new tab (a new view of a picture) to edit it...
What do you think about this behaviour?
Pierre.
-
Schattenreiter
- Posts: 43
- Joined: Mon Sep 19, 2005 5:46 pm
- Location: Berlin, Germany
- Contact:
Re: Interface...
For me, the best way is the faster one (consuming less extra time and/or resources).xnview wrote:Currently you have a tab 'browser', and a tab 'preview'.
The tab 'preview' is the same view as the preview in browser (current selected item). This is for example to edit the current picture.
But you can open a new tab (a new view of a picture) to edit it...
What do you think about this behaviour?
If the preview tab consumes an extra time, then it's better to remove this redundant function, because a preview area is already into the browser mode.
About the swapped tabbar, for me, you can keep it as it is in the alpha1 MP version (like in the windows version).
XnViewMP Linux X64 - Debian - X64
Re: Interface...
No it's not time consuming, it's to edit the current view, so it's a better way to edit the file...oops66 wrote: For me, the best way is the faster one (consuming less extra time and/or resources).
If the preview tab consumes an extra time, then it's better to remove this redundant function, because a preview area is already into the browser mode.
In XnView win, some users don't know how to edit the picture. Like this, you can do that easily without open a new tab...
I have some problem with tab like alpha1...About the swapped tabbar, for me, you can keep it as it is in the alpha1 MP version (like in the windows version).
Pierre.
Re: Interface...
OK - in this case, it's a good idea.xnview wrote: ...No it's not time consuming, it's to edit the current view, so it's a better way to edit the file...
In XnView win, some users don't know how to edit the picture. Like this, you can do that easily without open a new tab... .
I hope it is not april fools ? LOLxnview wrote: I have some problem with tab like alpha1...
Then in this case, I prefer tabs bar in the Top !
Congratulation for this new MP project and your good work.
When does the new Alpha 0.002 MP release comes ?
XnViewMP Linux X64 - Debian - X64
Well, I feel sorry to say this, but I would rather have the menu above the tab bar, as with every other application in windows and Linux.
Plus, the look & feel would be the same on a Mac, where the menu bar is on top of the screen.
But maybe you shouldn't focus on this, if this is preventing you from making progress on XnView MP.
Plus, the look & feel would be the same on a Mac, where the menu bar is on top of the screen.
But maybe you shouldn't focus on this, if this is preventing you from making progress on XnView MP.
-
Maximiliano Meilán
- Posts: 2
- Joined: Sat Jun 17, 2006 7:25 pm
- Location: Piriápolis
I think it would be a good idea not to change the interface too much. A code rewrite is surely a good situation to make big changes, but designing a good and intuitive interface needs quite some understanding of things and a lot of discussion. And I doubt that such an intensive discussion can be hold via posts in a forum.
Just to give an idea how controverse such a discussions and opinions could be:
- Tabs consume space, I want maximum space for the image.
- One should be able to hide the tabs
- Tabs should be at the bottom
- Editing should be clearly separated from viewing
- Editing should be disabled
- One should be able to edit immediately
- Our users want the old user interface
- Editing is the most important part of XnView
- XnView is a File manager and needs two panels for source and target.
- ...
I don't want to prevent progress and changes, but I want to make clear
a.) ...that changes in the user interface might be good for some people, but not good for some others.
b.) ...that changes are good if thoroughly discussed and well thought through.
c.) ...that discussions in a forum have their limits: A screenshot is something different than a life application, a written word is something different than a spoken word.
It would be really good if some workflows could be streamlined when developing XnView MP. But often these areas need a real concept behind it. E.g. from my point of view it's time to introduce modes (e.g. for Cropping) in XnView. And a database which is fed by decentral data, see topic IPTC/XMP for hierarchical categories + internal DB. But I guess the savest and best way for XnView and XnView MP is still evolution, not revolution.
Just some thoughts...
Just to give an idea how controverse such a discussions and opinions could be:
- Tabs consume space, I want maximum space for the image.
- One should be able to hide the tabs
- Tabs should be at the bottom
- Editing should be clearly separated from viewing
- Editing should be disabled
- One should be able to edit immediately
- Our users want the old user interface
- Editing is the most important part of XnView
- XnView is a File manager and needs two panels for source and target.
- ...
I don't want to prevent progress and changes, but I want to make clear
a.) ...that changes in the user interface might be good for some people, but not good for some others.
b.) ...that changes are good if thoroughly discussed and well thought through.
c.) ...that discussions in a forum have their limits: A screenshot is something different than a life application, a written word is something different than a spoken word.
It would be really good if some workflows could be streamlined when developing XnView MP. But often these areas need a real concept behind it. E.g. from my point of view it's time to introduce modes (e.g. for Cropping) in XnView. And a database which is fed by decentral data, see topic IPTC/XMP for hierarchical categories + internal DB. But I guess the savest and best way for XnView and XnView MP is still evolution, not revolution.
Just some thoughts...
I guess you are speaking of the position of menubar and toolbar. In your above screenshot you have menubar at the top (which is good and standard for Windows application).xnview wrote:... The user interface, very difficult to have menu/toolbar, very simple to have toolbar/menu
Is the screenshot outdated? I'm confused...No, here:helmut wrote:I guess you are speaking of the position of menubar and toolbar. In your above screenshot you have menubar at the top (which is good and standard for Windows application).
It's a little bit difficult to explain.
By using tabbar at the top, i think that it's better. menubar & toolbar is depending from the current context, and the context is selected by the tabbar. (IE 7 use toolbar at the top for example)
In XnView win32, i've made something that is not 100% normal (menu is changed depending the selected MDI child). In MDI application, menu is not changed.
So in QT, it's difficult, i need to patch QT source
On the first alpha, menubar was on the top, but was not changed following the context, toolbar too.
I have a Window with tabbar + 2 childs windows, on each child i have menubar + toolbar + view.
If i have Window with menu + tabbar + 2 childs window, the menu can't be changed easily...
I hope that you understand a bit better my problem...
Pierre.