2 fullscreens- differences

[Drahken]

Wasn't quite sure where to put this, so this section will do for now.

Screenshots of the context menu from viewer version of fullscreen on the left & browser version on the right:



First major problem we see is that even the items that are common to both menus are in different locations on each. Now as to the similarities and differences:
The following appear on both menus (but in different locations on each):
next(file)
previous(file)
first(file)
last(file)
zoom+/-
lock zoom
zoom submenu
auto image size submenu
quick slide show
copy to folder
move to folder
delete
rename
properties
close
================
The following items only appear on the viewer version of fullscreen:
crop
select none
selection- swap width/height
set selection size (submenu)
set selection ratio (submenu)
open with (submenu)
set as wallpaper (submenu)
====================
The following items only appear on the browser version of fullscreen:
open
configure quick slideshow
page (submenu) [multipage files, next, prev, etc]
real size
show mask
edit IPTC data
===================

In addition, you can't make a selection on the browser version, only on the viewer version.
Now, the reason given for some things not working on the browser version is that you're not in editing mode. This applies to making selections, the menu entries relating to selections, and the crop entry. The open with entry and set as wallpaper entry however, should be added to the browser version.
Additionally, I see no reason at all why the browser version (which is supposed to be the "lite" version) has several entries that the viewer one lacks. The page submenu (for navigating multipage files) & real size entries especially.

If the 2 fullscreen modes can't be merged or made identical o each other, then the browser/lite one should be given a thin border or faint background pattern or some such in order to distinguish it from the other. Having 2 modes that appear the same visually, but do not function exactly the same ("almost" isn't enough) just leads to confusion. Additionally, there should be an option in each menu to switch to the other fullscreen mode. This will server both to relieve some of the confusion, and provide a way for users to quickly access the editing options such as cropping.




Just for comparison purposes, these are the same 2 menus when not in fullscreen mode (again, viewer on the left, browser on the right):


EDIT: For those who are wondering what this is about, see THIS topic and THIS topic.

[JohnFredC]

As a general principle of software design when building an application, I consider all individual context menus as views into an all inclusive (but virtual) "master context menu" that has all possible entries in it. The master context menu is an ordered list of all of the sections and entries and sequences of sections and entries for every context menu command available anywhere in the application, combined into one "giant" context menu.

Individual context menus are simply "filters" or "views" into the master context menu, so they always show the same sections and entries in the same sequences as defined in the "master", and the visibilities of individual sections and entries vary according to the "contexts" within the application from which the menus are called.

Of course, this "master context menu" only exists on "paper" (ie. conceptually), but I use it as a design template to assure that context menus which share common entries and sections always show them with the same wording, in the same places, and with the same accelerator keys in each of the application's context menus in which they are supposed to appear.

This is just basic good design practice.

[xnview]

Right, perhaps i can reorder menu items in the 2 menus. But which is good?
And for fullscreen, you know which fullscreen you have, if you have in view mode (edit mode), you have a fullscreen with some edit functions. Else in browser, you can only see it.
But if you think that it's important, i can add some features from edit fullscreen....

[Drahken]

Pierre- The problem is that people don't know there ARE 2 fullscreen modes. That crop tool thread is a perfect example, almost none of us knew that there was a second fullscreen mode that he might be in. Maybe rename the browser fullscreen mode in the menus to "maximum" mode or "fullscreen browser" or something, then in cases like the crop tool thread we can say "make sure you're in FULLSCREEN mode, not MAXIMUM mode". It's easy to tell when you're in viewer mode or browse mode, and it's not a huge surprise when you see that the menus are a little different, but when you have 2 modes that look the same & are labeled the smae, but the menus are different, you sit there scratching your head and saying WTF.

[xnview]

Pierre- The problem is that people don't know there ARE 2 fullscreen modes. That crop tool thread is a perfect example, almost none of us knew that there was a second fullscreen mode that he might be in. Maybe rename the browser fullscreen mode in the menus to "maximum" mode or "fullscreen browser" or something, then in cases like the crop tool thread we can say "make sure you're in FULLSCREEN mode, not MAXIMUM mode". It's easy to tell when you're in viewer mode or browse mode, and it's not a huge surprise when you see that the menus are a little different, but when you have 2 modes that look the same & are labeled the smae, but the menus are different, you sit there scratching your head and saying WTF.

Fullscreen (edit) / Fullscreen is perhapsbetter??

[JohnFredC]

Another way to think of these modes might be:

Fullscreen - Edit tools visible

Fullscreen - Edit tools hidden

Full screen is full screen. If you specify that "edit" mode is linked to the visibility of the edit tools (ie toolbars and menus, etc), then you have effectively merged the two "full screen" modes into one and moved the distinction to the edit tools visibility.

This may be easier to think about/understand than the current confusing situation.

A good INI toggle would be, then:

[x] Allow edit tools in full screen mode

...for those who do not want to be able (or want their users to be able) to show/hide the edit capability in full screen mode.

[xnview]

Another way to think of these modes might be:

Fullscreen - Edit tools visible

Fullscreen - Edit tools hidden

Full screen is full screen. If you specify that "edit" mode is linked to the visibility of the edit tools (ie toolbars and menus, etc), then you have effectively merged the two "full screen" modes into one and moved the distinction to the edit tools visibility.

If you have edit mode in browser fullscreen, so you'll have editing in browser preview too (it's the same component).

[helmut]

Thank you for listing all differences, Drahken.

Some thoughts in brief:
It's pretty clear and obvious that the current situation with two fullscreens is no good. The two fullscreen modes are only there for technical reasons. The user does not need two different fullscreen modes and it can be confusing for users.

I see two approaches:
A - Make two technically different fullscreens identical for the user
B - Make the user clear that he/she uses different modes

I think B.) would be just a mid-term workaround, the real solution is A.). As long as we don't have A.), a different naming here in the forum and the user interface of XnView might help.

[JohnFredC]

If you have edit mode in browser fullscreen, so you'll have editing in browser preview too (it's the same component).

I really like this idea (editing in browser preview). It's the way I would work most of the time in XnView and is the way Adobe Lightroom is designed.

But when thinking about that and all the many "Image changed, Save?" dialogs that XnView would pop-up while one navigates through a folder of thumbs making edits here and there in the previews, I think that XnView needs another way to manage changes applied to images before editing in the browser ever becomes practical.

If XnView had a mode where changes to images were "virtual" a la Lightroom, Picasa, LightZone, et al, then one could navigate/edit/navigate/edit/navigate, etc in the browser's thumbs/preview mode without being concerned about save dialogs.

[Clo]

JohnFredC

Hello John !

• I like this approach too…
- Currently, there are means to prevent the boring “Save…” messages,
there are entries in the INI files under the [Start] section.
- Details in the Manual…

- That brought me some “fresh air”, since I have been grousing and yelling for a decade because that, especially the awful
“… Do you want to replace it ?” while I needed to save a change only …
- Now I can also make a change, no save >> Exit, no message… Ah ! What a relief ! (OUF !)

KR
Claude
Clo

[xnview]

B - Make the user clear that he/she uses different modes

I think B.) would be just a mid-term workaround, the real solution is A.). As long as we don't have A.), a different naming here in the forum and the user interface of XnView might help.

But how?

[Clo]

Pierre

Hello !

• What about “Large View” (Grand affichage in French) ,

KR
Claude
Clo

[marsh]

How about the name 'Secondary' ?
In recent versions the term 'Normal' is included as a starting mode, so a switching mode could resemble this:
Browser <> Secondary (fullscreen) | Normal <> Primary (fullscreen)
Browser <> Normal
Browser > Normal > Primary (fullscreen)
Browser > Primary (fullscreen) > Normal