XnView Software

We have different dialogs which work with multiple files. Their file list is:

Multi-Page file

Thumbnails - fixed size (it seems) @ 300x200 (??)

Join images

File List - (file name + path)

Batch Convert

Thumbnails view - fixed size (it seems) - other way to arrange (by drag & drop) compared with Multi-Page file dialog

Slideshow

Thumbnails view - fixed size (it seems) (the same engine from Batch Convert)

...besides the difference we have problems with both ways of seeing files because the thumbnails view needs adjustments/settings (the thumbs size mainly) and eats a lot of space. The list view is much better to see the files at a glance and from where they come but one cannot see the thumbs if he is interested in these.


Please gradually unify all these in on single widget which, using a tab control, can show alternatively the thumbs or the file list. Something like this:

Besides the obvious advantages outlined above there are other ones:

- the program doesn't look "patched" by using different GUI metaphors for same purpose
- the code will be smaller and cleaner
- a new feature can be implemented simultaneously to all these subsystems

A good suggestion, m.Th.. There was a related discussion years ago, see topic Unified way for creating file list. Unfortunately, when implementing XnView MP this hasn't been considered until now.

The basic idea is that you (always) have at least three or four tabs:
Input | <Action> | Rename | Output, just like in Batch processing/XnConvert.

"Input" tab
The Input tab contains the files that are basis for the action. When selecting files in the browser, this input tab is filled with the selected files, already. When started as standalone (e.g. from Viewer/Image View mode), the input tab contains only the current file and you can add files using "Add file..", "Add folder", and even Drag & Drop from Windows Explorer.

<Action> tab
The action tab allows for specifying details for the action. This could be conversions (like in the Batch processing) or other stuff like "Mult-Page". The action tab might even be named differently, depending on the action.

"Output - Settings" tab
This tab allows for specifying output settings like output folder(s), handling of meta data, and so on.

"Output - Naming" tab
The "Output - Naming" tab lets the user control the name(s) of the output files. In a list the user can see path & name of all input files and path & name of all output names.

Notes:
• List of input files could stem from the selection in the XnView browser, alternatively, the user just starts the action and adds arbitrary files. This way the dialogs/actions can be initiated from the XnView browser or standalone.

• Create multi-page files, join images, and so on would pretty much have the same dialog except of the "Action" tab.

• Actions like "Create multi-page file" which have one output file only, wouldn't have a fully featured "Output - Naming" tab.

___

Summary: A unified "Input" tab is a good first start and makes much sense. Later, dialogs might be unified even more as suggested in the old discussion and drafted above.

Summary: A unified "Input" tab is a good first start and makes much sense. Later, dialogs might be unified even more as suggested in the old discussion and drafted above.

Yes, sure. All (?) the programs have this paradigm because of many reasons ranging from user-friendly/ease to learn till to speed of development/code quality.

However, as I stressed in my first post, the Input tab should have (at least) two views: Thumbnails & List of file names.

The basic idea is that you (always) have at least three or four tabs:
Input | <Action> | Rename | Output, just like in Batch processing/XnConvert.

Humm... I am thinking now that it is a bit difficult to follow this standard on all modules.

I would say:

Input | {Action}
...we already discussed these - just a big Aside note here:

Open important Note>>>

Take care to support the MODELESS way of working (Add to Queue) because one of the main disadvantages of XnView is that any lengthily operation blocks the entire program. This is especially important now because one of the main advantages of XnView vs Lightroom - Speed - is threatened today (see here for details: https://www.dpreview.com/news/694730587 ... -to-try-it).

The sad/happy part about modeless support is that the difficult multi-threaded code to support it is already in place, we just need just some minor GUI/list management adjustments in order to make this work. See details here: http://newsgroup.xnview.com/viewtopic.php?f=60&t=29204

<<<Close important Note

Besides these two tabs I would say that just one more tab is needed as standard one: Status
...which will have the layout from Batch Convert, just having the Print function (or printf or sprintf or cout or whatever ) modified a little in order to print the dateTime stamp in front of each line. This will help the user experience by informing him with the stages which program is executing, thing which is particularly useful when we deal with a batch of files to load (in order to convert, make a multipage, strip etc.). Of course the gauge/progress bar will remain.

Besides these three tabs, depending on module, we will have Output - Settings / Output - Rename or anything else but bear in mind that these tabs aren't generally applicable to all situations. Many things from "Create" menu end in the Editor, hence the Output - Rename isn't applicable, for instance.

Tl;dr: Input | <Action>
"Status" - highly recommended
Prepare for Modeless support.

WRT GUI: Two lists of tabs isn't good. Much better IMHO is to use radio buttons:

...also WRT GUI: Do not forget to add a slider to change the size of the thumbs...