XnView Software

JohnFredC wrote:It is useful...

1. ...to understand that an image tab is linked to the browser
2. ...to know which image tab is linked to the browser
3. ...to know when a linkage has been changed/broken
4. ...to be able to deliberately break/reassign that linkage, if required.

Does that help?

I means is it useful to have a view synchronized to the browser?

xnview wrote:I means is it useful to have a view synchronized to the browser?

For me, the only useful synchronization would "backwards" from the viewer to the browser: a button to synchronize the browser to the folder of the image in the current viewer tab and then switch back to the browser tab all in one step would be very useful.

But since the browser already has a preview pane, synchronizing in the other direction (from the browser to a single dedicated browser:viewer tab) is not useful to me personally at all. Just confusing. Better to enhance the browser's preview pane.

Perhaps someone else will step in here with another opinion.

Here is a previous thread about this topic.

For my point of view, it would be more useful for a "Viewer software" to have a "full screen view" synchronized (pre-loaded to spend less time) with the browser (preview), than synchronized with an other view tab, because the View mode is usually only used to make changes to the image, not to show it (but this function can also be useful, as option for fast editing).

oops66 wrote:because the View mode is usually only used to make changes to the image, not to show it

Not for me. I almost never use full screen view, except temporarily, always preferring to use the view tabs for "view"ing...

Amazing how differently we all work. Quite a tribute to the excellence of XnView that it manages to accommodate so many different methods.

MP should continue that tradition, despite the Macintosh crowd, who I am fully expecting to invade here any moment.

I means is it useful to have a view synchronized to the browser?

yes.
single way sync (viewer > browser) like it currently implemented.

on a side note I'd make sure the browser preview and the synchronized tab do not share the same cache.
currently while image A is in the viewer tab, select image B in the browser and wait for the preview to display (always damn too long if you ask me )
now promptly open image C (double click) > the viewer tab will display image B (which was supposedly never "opened" in the viewer) while image C is loading

because the View mode is usually only used to make changes to the image

not for me either.

thibaud wrote:

I means is it useful to have a view synchronized to the browser?

single way sync (viewer > browser) like it currently implemented.

Ok, so i keep this way, perhaps the simplest

One single dedicated browser-viewer pair will just confuse me.

Perhaps an option to turn that behavior off and return to 1.9x behavior?

Please?

v.0.21 Tabs are not synchronized with browser.

marsh wrote:v.0.21 Tabs are not synchronized with browser.

How that??

xnview wrote:

marsh wrote:v.0.21 Tabs are not synchronized with browser.

How that??

What puzzled me was changing from a viewer window to browser by only selecting tabs (not double-click or <enter>). I expected the thumbnail to match the most recent picture being switched from.
Is it possible to update browser list when selecting its tab and leave the current images open and unchanged?

marsh wrote:What puzzled me was changing from a viewer window to browser by only selecting tabs (not double-click or <enter>). I expected the thumbnail to match the most recent picture being switched from.
Is it possible to update browser list when selecting its tab and leave the current images open and unchanged?

But if you have opened many view tabs, you would like that browser synchronize by selecting the browser tab??
I think it's strange...

I expected this question to arise. In the early days of MP, Pierre implemented a "dedicated" relationship between the browser and the viewer. Opening additional viewer tabs required a different user behavior. Most of us objected to that behavior and now MP acts as does 1.9x. I personally prefer this.

Nevertheless, the issue is: which image tab belongs to (i.e., is the same location as) the browser?

Is it possible to update browser list when selecting its tab and leave the current images open and unchanged?

If the image tab points to a file in the same folder shown in the browser, well OK. But suppose the image is in a different folder than that currently shown in the browser?

It is probably too much to expect that the browser navigates to the folder of the image tab every time a user switches from that image tab back to the browser. Possibly confusing, too.

But what to do?

My idea (and this won't happen, I know) is (partly) that every tab should be a browser AND a viewer, with different "modes" that control the visibility of the individual panels within the tab. Switching to viewer-mode (of a tab) would hide the browser-specific panels. Switching to browser-mode (of a tab) would redisplay the browser panels. The browser preview panel could behave as a view at all times, should the user desire.

I guess a simpler way to describe this would be: eliminate the view mode/tabs altogether. Instead, each and every tab would be a browser, and the browser preview panel would have all the behaviors and capabilities of the currently implemented view tabs.

IMO, this won't happen partly because: MP development is already too far down the road for such a serious change in paradigm, and partly because: (I think) considerable additional system resources would be required (including processor cycles).

So I think it best to accept the current behavior and let the user continue to "keep straight" that the folder shown in the browser is fixed until the user changes it.

JohnFredC wrote: Nevertheless, the issue is: which image tab belongs to (i.e., is the same location as) the browser?

For me, the isssue is the opposite: which folder belongs to the image. I'm not sure this viewpoint has been presented (as I haven't finished looking through articles).

Hi Marsh...

For me, the issue is the opposite: which folder belongs to the image

Yes!!! Actually that IS my viewpoint exactly!

One aspect of XnView should be "image-centric", not "folder-hierarchy-centric".

An image's location in the file system is just another (editable) property of the image, like keywords, bit depth, etc. The browser panels edit the file system location property of the image.

That was the point of my suggestion (above) about making every tab a "browser". The browser sub-panels would be subordinate to the viewer (be "property sidebars" of the image...) and not the other way around.

The forum touched on this kind of perspective in a long thread regarding the browser panel hierarchy here, quite some time ago.

It would not be good to eliminate the browser paradigm entirely, though, because frequently we need to move and copy multiple images, slide shows, etc.

So I say... browser subpanels in each view tab, plus at least one browser tab.

Or something like that.

xnview wrote:

marsh wrote:What puzzled me was changing from a viewer window to browser by only selecting tabs (not double-click or <enter>). I expected the thumbnail to match the most recent picture being switched from.
Is it possible to update browser list when selecting its tab and leave the current images open and unchanged?

But if you have opened many view tabs, you would like that browser synchronize by selecting the browser tab??
I think it's strange...

Yes, another "switching mode" (though a little more direct than the other means).