XnView Software

JohnFredC wrote: For instance, I would like to browse the Folder tree to find appropriate images (in various folders) and drag them to a Slideshow, or to a Category, or an Album, or whatever.

You drag to Categories header and then whole tab appears and you can put to category.

JohnFredC wrote: a single sidebar (no tabs) with collapsable sections/panels, one each for Folders, Categories, Favorites, etc.?

How does it look like?

-=nightflyer=-

JohnFredC wrote:Be that as it may... (see prior post)

All of the screenshots I had intended to show were from "combined" trees, such as described above. Since a "combined" tree, no matter how elegantly implemented, appears to be less desirable than tabs for most of you, I won't waste everyone's time with examples of tree implementations.

No please put some screenshots...

JohnFredC wrote:Further, why waste all that screen space for just two tabs? (NOW I understand why Pierre chose buttons...): tabs take up too much real estate if there are only two or three of them to display).

So, instead of two tabs (er, buttons), what about this alternative approach:

a single sidebar (no tabs) with collapsable sections/panels, one each for Folders, Categories, Favorites, etc.?

The interaction with such a schema would show the benefits of tabs (easy to understand) AND the interaction benefits of a tree (drag and drop between subpanels/sections), but without complicating the XnView interface with lots of extra layout items (ie. nested tabs/panels) and also without merging everything into a single tree.

Perhaps i don't understand, but it's always one tree with 3/4 root entries???
And one problem for me currently i can't move all my code for folders in the same panel as favorites or categories

xnview wrote: But do you think that only 2 tabs is better than 3, 4, ....?
One tab for folder, and one tab for 'organize' (favorites/categories)

I think that joining is bad. It is better to allow fast access.

nightflyer wrote:

xnview wrote: But do you think that only 2 tabs is better than 3, 4, ....?
One tab for folder, and one tab for 'organize' (favorites/categories)

I think that joining is bad. It is better to allow fast access.

So a tab for every organize feature? 2 tabs is good for me, 3 becomes a little too much, but if i want to add in the future another feature, 4 will not be good... I have no idea which is the better solution...

xnview wrote: No please put some screenshots...

Hmm... maybe I get what JohnFredC is trying to explain. And after a second thought, it might be a pretty good idea! I use a superb program called MediaMonkey for my music-collection, and it uses a tree-structure to handle all music. It works well and looks like this:


JohnFredC, was it something like this you had in mind? With this solution MediaMonkey has been able to add new categories during its development (i.e. Net Radio and Web), and it works just fine.

2Troken

Yes, that is exactly the "combined" tree idea I was promoting. I use Media Monkey also and was planning to post essentially that screenshot..

The multiple collapsible panels idea is different... will post a screenshot from Adobe Lightroom Beta 4 later today, but you can try that software out by signing up for free.

2Pierre

Perhaps i don't understand, but it's always one tree with 3/4 root entries???

Yes, it behaves that way, though a collapsible panel doesn't actually have to have a (sub) tree in it. This kind of approach is in use for many years in 3-D modeling software (3DS Studio Max was one of the first).

Another good paradigm for this sort of thing (panels, sidebars) is PaintShopPro (version 8 and above). It has a very dynamic approach to sidebars with drag-and drop of panels into/out of the sidebars. Sidebar panels can collapse to vertical tabs, or float over the image, or dock inside the sidebar in any position and any size you want.

But... That's more flexibility than I think is strictly necessary for XnView, hence my original suggestion of a "combined" tree, instead.

Solving this trees vs tabs vs panels layouts thing for XnView once-and-for-all would make enhancing XnView much easier in the future, though I realize that here is a LOT of upfront design and programming work involved.

JohnFredC wrote: 2Pierre

Perhaps i don't understand, but it's always one tree with 3/4 root entries???

Yes, it behaves that way, though a collapsible panel doesn't actually have to have a (sub) tree in it. This kind of approach is in use for many years in 3-D modeling software (3DS Studio Max was one of the first).

Another good paradigm for this sort of thing (panels, sidebars) is PaintShopPro (version 8 and above). It has a very dynamic approach to sidebars with drag-and drop of panels into/out of the sidebars. Sidebar panels can collapse to vertical tabs, or float over the image, or dock inside the sidebar in any position and any size you want.

But... That's more flexibility than I think is strictly necessary for XnView, hence my original suggestion of a "combined" tree, instead.

Solving this trees vs tabs vs panels layouts thing for XnView once-and-for-all would make enhancing XnView much easier in the future, though I realize that here is a LOT of upfront design and programming work involved.

Ok, so eveyrone agree with this solution?
But for 1.90, i can not add folders in same panel as categories/Favorites (i need to rewrite all my folder tree code)!

xnview wrote:

nightflyer wrote:

xnview wrote: But do you think that only 2 tabs is better than 3, 4, ....?
One tab for folder, and one tab for 'organize' (favorites/categories)

I think that joining is bad. It is better to allow fast access.

So a tab for every organize feature? 2 tabs is good for me, 3 becomes a little too much, but if i want to add in the future another feature, 4 will not be good... I have no idea which is the better solution...

Another concept would be a single view cycling button/tab in addition to current folder tab (if there were 4+ panels to choose from). I think it is better to not mix dissimilar functions on same tab/tree and I like not using "[+]" expanders whenever possible (cf. new options).

If tabs are disabled to gain some screen space, perhaps a view changing shortcut would be a marginal improvement also (middle-mouse button?).

2Marsh

I think it is better to not mix dissimilar functions on same tab/tree

Except, the user interaction functions are exactly the same: expand, contract, drag, drop, rename, show context menu... etc.

The paradigm for user interaction is identical, even though the "names" (that is, folders vs categories vs favorites, etc) are different.

Here is an annotated screen capture of LightRoom's sidebar.

The LR sidebar has various expandable/collapsible panels that contain lists, trees, forms, etc. The sidebar itself is collapsible, and if there are too many panels to show vertically, it will display a scroll bar.



Something like this in XnView would work fine for me. This paradigm is even more flexible than the "combined" tree approach, though I expect it has more programming and resource overhead than the tree would.

I really don't know which is best anymore! The new ideas? The current structure? Have to think about this.

Troken wrote:I really don't know which is best anymore! The new ideas? The current structure? Have to think about this.

I agree. That's partly why I started this thread.

Perhaps 1.9 version level isn't a good one for big changes, anyway.

2.0 would be, I think.

JohnFredC wrote:Here is an annotated screen capture of LightRoom's sidebar.

The LR sidebar has various expandable/collapsible panels that contain lists, trees, forms, etc. The sidebar itself is collapsible, and if there are too many panels to show vertically, it will display a scroll bar.



Something like this in XnView would work fine for me. This paradigm is even more flexible than the "combined" tree approach, though I expect it has more programming and resource overhead than the tree would.

Yes, another solution, but here we can have scrollbar on the each bar and on global panel. And it's almost the same solution than but with less space lost...

My ideas are:
-It is possible to put just icons in tree panel, not icons with names, like here: http://www.pspad.com/img/screen/mainfull.png Now you have easily place for 5 or 6 tabs. You can display tab name in tooltip (balloon) if needed. If user makes tree panel very narrow, he just gets two rows of tabs.
-Sidebar headers take too much useful space!
-Joining items in tree is bad and not useful. If there are some more items and/or expanded branches, I cannot see two kind of items anyway. Then, if I want to precisely navigate with tabs, I just click tab header and in big tree I have to scroll and look for.
-To drag and drop between tabs is simple. Just drag to tab header and then tab displays and you can drop. After drop the original tab can be re-displayed!
-I think tabs are also easier for the programmer! We can get it fast with good and stable implementation.
-This interface novelties are often more fun and appearance than productvity and comfort.