Layout per database

[Aubrey]

When a database is loaded, the viewer loads the layout of the last database loaded.
It would be better to have layout taking the last layout of the current database loaded rather than the layout of the last database.

Explanation:
I have a specific layout for my photograph database.

I have another database containing technical papers, I usually use a grid format for this database.

When I switch from technical papers to photography (and vise versa) my photography appears with a grid format.

It would be great on opening a database one inherits last setup of that database

There may well be others who like the current setup. Perhaps there could be a preference switch  so that some users could retain current setup.

Aubrey.

[Mario]

Hm, not sure that i can follow straight away.
By a quick look, the Viewer stores these settings in the workspace, unrelated to the database.
Do you use the same workspace for both databases?

[Aubrey]

When I open a different database it uses the settings from the last opened database.
See attached jpg...
When I open the database containing my technical papers it opens with "Aubrey_V7", I then change it to "PDF papers grid", which is most appropriate for listing technical papers (titles, authors etc.)

When I reopen my photography database, it opens by default with "PDF papers grid", I then need to change back to "Aubrey_V7" to have photos displayed as I would like...

It would be better if opening of a database was associated with a particular layout.

Hopefully this clarifies.

Aubrey.

[Carlo Didier]

Great idea, Aubrey!

[Mario]

When I open a different database it uses the settings from the last opened database.
See attached jpg...

Ah, you mean File Window layouts. You did speak about the Viewer in your post. Which has also grid settings.
The last used layout are also stored in the workspace.
Why don't you setup two workspaces, one for each database? See Loading and Saving Workspaces

Note that, looking at telemetry, most users use only one database. Using multiple databases is pretty rare and thus I'm reluctant to invest time into features only of relevance if the user uses more than one database. I think using two workspaces will solve your problem nicely.

[Aubrey]

Sure, changing workspace works.
this is effectively what I do when I change my database.

As enhancement I was asking for each database to remember its particular workspace.

if it's a lot of work, then I can certainly live with the current situation.

it was simply an enhancement suggestion!

[Jingo]

As part of this request - not sure how others feel... but, even though I use a single database.. I use multiple workspaces to track what I'm doing (keywording vs versioning, etc). 

I really wish there was option to have the file window NOT be part of the workspace... because each time I change the workspace - my file window changes to what it was when the workspace was first set (based on the folder location).  Perhaps this is good in some scenarios.. but for changing workspaces during my workflow - it would preferable to keep the file window fixed to the current selection (or have an option as part of the workspace).

[Carlo Didier]

As part of this request - not sure how others feel... but, even though I use a single database.. I use multiple workspaces to track what I'm doing (keywording vs versioning, etc). 

I really wish there was option to have the file window NOT be part of the workspace... because each time I change the workspace - my file window changes to what it was when the workspace was first set (based on the folder location).  Perhaps this is good in some scenarios.. but for changing workspaces during my workflow - it would preferable to keep the file window fixed to the current selection (or have an option as part of the workspace).

+1

[Aubrey]

As part of this request - not sure how others feel... but, even though I use a single database.. I use multiple workspaces to track what I'm doing (keywording vs versioning, etc). 

I really wish there was option to have the file window NOT be part of the workspace... because each time I change the workspace - my file window changes to what it was when the workspace was first set (based on the folder location).  Perhaps this is good in some scenarios.. but for changing workspaces during my workflow - it would preferable to keep the file window fixed to the current selection (or have an option as part of the workspace).

++++1

This is a really good idea, more important than mine in the original tread.

[Mario]

The file window has over 30 settings, options, states and whatnot that can only be stored in the workspace. There is no other place for that.

When I understand you correctly, you only want IMatch to not remember the last used file window layout per database. But to keep the selected layout even when you switch databases.
What happens if a user uses data in the layout which exists only in one database (metadata, attributes)? The layout would break in that case or show no or wrong data.

Yes. YOU of course now that and YOU will create your file window layouts so they function with all your databases.
But I cannot depend on that ALL users understand that. Or even bother to read the help for the new switch/option/toggle.

We would need yet another option to allow a user to configure whether or not IMatch remembers the last used file window layout per database. But IMatch has so many options already, not even I can remember any option anymore, or anticipate how all these options interact.

Looking at the minimal number of users who have more than one database and the (currently) only 3 users who +1 this, I'd say we wait for a couple of other users who also would want such a feature. The year 2020 is long, plenty of time to add new options. Although I'm more into removing options to simplify usage, code base and support...

[Aubrey]

When I understand you correctly, you only want IMatch to not remember the last used file window layout per database.
But to keep the selected layout even when you switch databases.

Keep the fileviewer window on a per database. Currently it is stored on a Global basis.

What happens if a user uses data in the layout which exists only in one database (metadata, attributes)? The layout would break in that case or show no or wrong data.

Not sure I understand here. I would like Database1 keeps workspace_1 database2 keeps workspace_2.
Currently when I reload database_1 after using database_2, database_1 now now opens with workspace used in database_2.

Yes. YOU of course now that and YOU will create your file window layouts so they function with all your databases.
But I cannot depend on that ALL users understand that. Or even bother to read the help for the new switch/option/toggle.

I think it's simpler than this - please see below, the proposed requirements in a nutshell

We would need yet another option to allow a user to configure whether or not IMatch remembers the last used file window layout per database.

Correct!

But IMatch has so many options already, not even I can remember any option anymore, or anticipate how all these options interact.

Looking at the minimal number of users who have more than one database and the (currently) only 3 users who +1 this, I'd say we wait for a couple of other users who also would want such a feature. The year 2020 is long, plenty of time to add new options. Although I'm more into removing options to simplify usage, code base and support...

We would like to have:
Point 1. Database and workspace linked (i.e., layout linked).
Why?: It makes no sense to have layout from one database being the same as for another database with different type of data; layouts are data type dependent
Result: Each database keeps its own layout.
Comment: I suppose this means that this must be stored on a per database setting rather than an IMatch global setting. BTW after

Point 2. When a workspace is changed then retain focus on fileviewer used before workspace change.
Why?: The most usual reason for a change of Workspace is to view different panels but on the same focus of file viewer
Result: There is no need to refocus files that had been previously selected

Nothing here is business critical, just some suggestions...
Point 1 I can live with the current setup (the original reason for this thread)
Point 2, from Carlos is really useful - it would be great to have this incorporated.

[Jingo]

We would like to have:
Point 1. Database and workspace linked (i.e., layout linked).
Why?: It makes no sense to have layout from one database being the same as for another database with different type of data; layouts are data type dependent
Result: Each database keeps its own layout.
Comment: I suppose this means that this must be stored on a per database setting rather than an IMatch global setting. BTW after

Point 2. When a workspace is changed then retain focus on fileviewer used before workspace change.
Why?: The most usual reason for a change of Workspace is to view different panels but on the same focus of file viewer
Result: There is no need to refocus files that had been previously selected

Nothing here is business critical, just some suggestions...
Point 1 I can live with the current setup (the original reason for this thread)
Point 2, from Carlos is really useful - it would be great to have this incorporated.

Yes.. this does make sense so long as coding is doable... for me, each time I switch workspaces I must navigate back to the file location from before - not a deal breaker by any means... but an extra step that could be avoided. 

[ubacher]

+1

Makes sense to have the layout fixed to a database.

and

. for me, each time I switch workspaces I must navigate back to the file location from before

This is what makes Mario's suggestion to just have a layout for each database and invoke it when switching databases a nuisance.

[graham1]

+1

In particular, I have differing thumbnail layouts for different databases: some are basic, others show metadata in the footers such as keyword and character counts.  I have saved the layouts and can switch between them, but it would be a lot better if each database remembered its preferred layout.

Graham

[thrinn]

+1
I support both suggestions from Aubrey.

Point 1. Database and workspace linked (i.e., layout linked).
Why?: It makes no sense to have layout from one database being the same as for another database with different type of data; layouts are data type dependent
Result: Each database keeps its own layout.
Comment: I suppose this means that this must be stored on a per database setting rather than an IMatch global setting. BTW after

Point 2. When a workspace is changed then retain focus on fileviewer used before workspace change.
Why?: The most usual reason for a change of Workspace is to view different panels but on the same focus of file viewer
Result: There is no need to refocus files that had been previously selected

I use different workspaces for the same database mostly to rearrange the panels (for example, one workspace for keywording, another one for working on my own apps). For this use case, it would be definitely better if switching the work space would not change the folder or categorie I was working with.

I am also one the few users who use two different databases, one for photos, one for documents. For this use case, I have set up another workspace which would not work with my photos database. It would be easier if the document database would start with its own workspace.

For me, these features are of "nice-to-have" priority.

[graham1]

+1

I too have at least three databases.  The first has my entire collection of master photos (relatively static, mainly RAW files - 650,000 images).  The second is for the JPG photos exported from my RAW processor which I am preparing ready for submission to my agency (in which I deal with keyboarding in final detail, a number of metadata presents for the particular agency concerned etc.) - this has no more than about 50 images at any one time. The third catalogues the images that have been submitted to the agency (22,000 images).

The second database is therefore very much smaller and faster than the first.  Both are on my main computer.  The third database catalogues the archived JPG images which are not on my main computer, so it is slower to access over my home network, which is one of several reasons for not incorporating them in my main database. 

It therefore makes sense for my workflow to keep the three databases separate.  As you might well imagine, each has a very different Workspace set up for it, for their very different purposes.

Graham