Moderators: helmut, XnTriq, xnview
You drag to Categories header and then whole tab appears and you can put to category.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.
How does it look like?JohnFredC wrote: a single sidebar (no tabs) with collapsable sections/panels, one each for Folders, Categories, Favorites, etc.?
No please put some screenshots...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.
Perhaps i don't understand, but it's always one tree with 3/4 root entries???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.
currently i can't move all my code for folders in the same panel as favorites or categories 
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...nightflyer wrote:I think that joining is bad. It is better to allow fast access.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)
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:xnview wrote: No please put some screenshots...
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).Perhaps i don't understand, but it's always one tree with 3/4 root entries???
Ok, so eveyrone agree with this solution?JohnFredC wrote: 2PierreYes, 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).Perhaps i don't understand, but it's always one tree with 3/4 root entries???
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.
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).xnview wrote: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...nightflyer wrote:I think that joining is bad. It is better to allow fast access.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)
Except, the user interaction functions are exactly the same: expand, contract, drag, drop, rename, show context menu... etc.I think it is better to not mix dissimilar functions on same tab/tree
Yes, another solution, but here we can have scrollbar on the each bar and on global panel. And it's almost the same solution thanJohnFredC 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.
but with less space lost...
The new ideas? The current structure? Have to think about this.