Workspaces: Do not touch saved workspaces

[thrinn]

At the moment, it is very easy to inadvertently change a saved workspace: If I select a workspace, I am essentially working IN this workspace. All changes are in a sense automatically saved.

I would like to suggest the following behaviour:
The user always works in one workspace (say: CURRENT). To save the panel layout etc. for later reuse, there is a "Save Workspace" command, where I can select an existing saved workspace (thus overwrite it) or enter a new name (thus creating a new saved workspace). This is exactly how it is implemented at the moment, so no change required for saving workspaces.

But selecting another saved workspace (say: SAVED) should only copy the settings of SAVED to CURRENT. Now CURRENT has the same layout as SAVED, so I work with my carefully prepared layout. If I change something, e.g. open the Exiftool output panel to have a quick look, only CURRENT is changed. I can always return to my saved layout be just loading SAVED again.

The way it is implemented now I always have to remember to perform multiple steps if I want to use a saved layout, but at the same time be certain that it remains unchanged:

• Select the saved workspace.
• Save it under a different name (say: TEMP)
• Select TEMP.

Possible, but a bit cumbersome.

Regards,
Thorsten

[ubacher]

Exactly.
As is is not intuitive.

And the help file says:

Saving a workspace freezes all current workspace settings, window positions and sizes, panel layouts etc. You can later return to these settings at any time by loading the workspace.

which is not how it works. Thus I consider it a bug.

[Mario]

When you consider something a bug, please file a bug report. I don't look for bug reports in the Feature Request board.
If you think that something is not documented correctly, use the link at the bottom of the corresponding help page to inform me about it. Hiding such comments in a Feature Request does not help.

[Mario]

As is is not intuitive.

Consider it analog using databases. When you load a database (workspace) and you make changes, these changes are made to the database. There is no "virtual copy" of a database or anything.

The workspace currently loaded (and which name is displayed in the main caption bar) controls the layout you see in IMatch. And changes you make to the current workspace updates that workspace. If you want to secure a workspace, save it under another name. Then you can later revert back to it by loading it again.

[ubacher]

This started in the BUG section but thrinn wrote it as a request and I continued on here.

Please re-read the description by thrinn. 

If I use you database example - here is how it works:

I store a copy of the database. Then I make some changes. When I try return to the stored database
I get the stored database with all the changes I have made since I stored it.

[Mario]

If you save your current workspace to A, IMatch will not touch A - ever.

[Gerd]

Hi,
I do not understand the problem ...

Before I change the standard workspace, I save it under e.g. "Default", then I do my changes in the active workspace and save them under e.g. "WS_A".

Now I have two different workspaces, which I can load and use with their settings ...

[thrinn]

Gerd,
the reason why I posted this feature request is: It happened to me that I created a workspace for metadata editing and saved it as META. I then continued working and testing, changing the layout and panels back and forth. Later on, I wanted to return to metadata editing, so I just loaded (or more precisely: selected) my saved workspace META. Up to this point, everything works fine.

The problem arose when I opened some additional panels, closing others to make space on the screen. As I was working in the META workspace now, my saved layout was gone because all changes were automatically saved in META. I did not want that.

I fully understand that this is how things work at the moment. But I would prefer to see saved workspaces secured against automatic changes: If, after loading/selecting a saved workspace, I change the layout, these changes should be temporary. If I really want to update my saved workspace with these changes, I can always use the Save Workspace command on the existing workspace.

This is why I posted this as a feature request.

[ChrisMatch]

I too had problems at first and I think I know what confused me (and maybe others).
Of course, once you got the hang of how it works - it is usable.

For me it is a wording issue:
- you can save workspaces but don't need to
- the current workspace is auto-saved if you change something

So the "Save Workspace" options is more like a "Create new workspace" option and could/should be named accordingly (or maybe something like "Save current Workspace as..."). I think this would end the confusion.

[cytochrome]

Like others here I have spent time to set up a workspace to my liking and have lost it... This won't happen again (I hope..) because now it is saved 4 times under 4 names.

What I suggest is that IM renames it to Current (or Last, or any meanningful name) at program start. This would be a reminder that it is THIS workspace that will be saved, and under a different and generic name.

Francis

[Gerd]

Hi,
I would like, if it is selectable on/off in the preferences. It works like Word-Auto Safe.
If I can, I switch off all atutomatic savings, because I want to determine, what and when something has to be saved.

[ilan]

After trying to work with workspaces I think thrinn's original suggestion makes most sense.

[thrinn]

After trying to work with workspaces I think thrinn's original suggestion makes most sense.

Thank you! 

Consider it analog using databases.  When you load a database (workspace) and you make changes, these changes are made to the database. There is no "virtual copy" of a database or anything.

I understand that from a technical point of view. But considering other applications like some advanced text editors which also allow to save their configuration data (window layout, menus etc.) for later reuse, saved configurations are usually NOT overwritten automatically. Even Word asks if it should really overwrite your templates (Normal.dot) if necessary. This is of course another approach: Let IMatch ask if the changes to the current workspace should be saved whenever the user quits IMatch OR switches to another workspace. IMatch could even offer to save the changes under a different name. But I suspect this takes more effort to implement than my initial suggestion, and without much additional benefit.

What I suggest is that IM renames it to Current (or Last, or any meanningful name) at program start. This would be a reminder that it is THIS workspace that will be saved, and under a different and generic name.

You idea with the generic name (CURRENT) is very similar to my intial proposition. The difference is that I would not "rename" the workspace at the next start but when the user switches to another workspace.

[ColinIM]

I've bumped this up again after seeing this feature discussed once again here:

"Workspaces" posted on 05 May 2014 -
https://www.photools.com/community/index.php?topic=2254.0

I vote +1 for Thorsten's variation above, on how Workspaces are currently saved and maintained.

The current implementation of Workspaces in IMatch 5 (which I could refer to as being 'always volatile' workspaces) is different to that used by most (if not all) of the programming development environments (mainly C/C++ IDEs) in which I've worked for many years.  Those IDE workspaces aren't changed unless we explicitly overwrite them, so I'll label them as being 'safely static' workspaces.

The arguments for and against the current 'always volatile' workspaces have already been aired in other threads so I won't resurrect them here, but I will add that while I'm trying to find my own place of "comfortable competence" with IMatch 5, I am hindered and unsettled by the 'always volatile' layouts.  My layouts are on shaky, unstable ground ... and therefore I feel less willing to experiment with the many possible alternatives!

So please Mario, give us the option to work instead with 'safely static' workspaces.

Colin P.

[KimAbel]

+1

[Mario]

About the volatile workspaces:

1. IMatch only ever changes the active workspace.
2. You choose which workspace you make active
3. Workspaces saved but not active are never touched.

[Richard]

1. IMatch only ever changes the active workspace.
2. You choose which workspace you make active
3. Workspaces saved but not active are never touched.

Hi Mario,

Your three items are great except for the nut behind the keyboard. I can picture myself working in a workspace and making some changes to the workspace to do something a bit different, then saving. Too late I realize that by saving my changes, I did not create a new workspace, I messed up one I never intended to change.

[ubacher]

It is the same for rename presets - I keep a screen shot of my settings so I can recover when I accidentally change it.
Except with rename-presets there is no "save current layout" option to make the user think s/he stored a setting and can recall it.

[Mario]

I can picture myself working in a workspace and making some changes to the workspace to do something a bit different, then saving. Too late I realize that by saving my changes, I did not create a new workspace, I messed up one I never intended to change.

All changes you make go into the active workspace. No separate save is required. You can save the current settings to another (new or existing) workspace, but that requires explicit action and is thus never accidental.

Just remember: You modify the active workspace (which is checked in the menu and the name of the active workspace is also displayed in the main menu bar).

[Mario]

It is the same for rename presets - I keep a screen shot of my settings so I can recover when I accidentally change it.
Except with rename-presets there is no "save current layout" option to make the user think s/he stored a setting and can recall it.

The renamer has an active preset (the name of which is displayed right on top). There is no need for an explicit save because all your changes are saved automatically. You can save your current settings to another name to recall them later.

[Ferdinand]

Here is how I propose to use workspaces, as things work at the moment.  Let's say I have three saved - A, B, and C.  I recall workspace A.  I will then immediately save it as workspace "temp" and then recall temp.  This way any changes I make will be to temp, not the saved copy of A.  Now I recall workspace B.  Again I immediately save it as temp and recall temp. 

This is a cumbersome way to use workspaces, but it seems to be the only way to use them and not accidentally modify the saved copy of my active workspace.

For this reason I support the feature request, which I think would bring IMatch into line with generally accepted practice.

[meyersoft]

Maybe the actual behaviour should not be changed, just extended:

If there would be an additional command
"Load/Copy workspace w2 into actual workspace w1"
this could be a good way for everybody...!?

The actual behaviour would be the same. You always work in and modify the actual workspace w1.
If you want to save it, you save it under a new name w2, but keep working in w1 (as before).
If you want to load w2 AND CHANGE it, you switch to w2 as before.
If you want to load w2 and do not change it, but change w1 which might be your default, you load/copy w2 into w1. This would be the new feature.

It would avoid having to save and switch workspaces as Ferdinand and others describe.

[ubacher]

Would it not be easier if the workspace be ONLY saved when the user selects this option?
( Right now it is automatically saved under the current name - and thus wiping out the deliberately saved workspace.)

[meyersoft]

Would it not be easier if the workspace be ONLY saved when the user selects this option?
( Right now it is automatically saved under the current name - and thus wiping out the deliberately saved workspace.)

This would be a change in behaviour.
I like the current behaviour - and it is the same in actual editors, IDEs (Eclipse,...).
It could only be enhanced/extended to save some necessary user action.

[Mario]

If there would be an additional command
"Load/Copy workspace w2 into actual workspace w1"
this could be a good way for everybody...!?

I already suggested that. No sure if it was in this thread or the other recent workspace thread.
Got no response.

I'm reluctant to change something as complex and important as the workspace feature (all all screen shots, documentation, translations) before the initial release of IMatch 5.

[sinus]

If there would be an additional command
"Load/Copy workspace w2 into actual workspace w1"
this could be a good way for everybody...!?

I already suggested that. No sure if it was in this thread or the other recent workspace thread.
Got no response.

I'm reluctant to change something as complex and important as the workspace feature (all all screen shots, documentation, translations) before the initial release of IMatch 5.

I understand, that the initial release of IM5 is realy important!
From my point of view the actual behavior of the workspace is not very intuitve and I guess, users will ask for this a lot.
So this behaviour should be changed, in what way I do not know, but you and users have some ideas.

The question is: is it very important, that Mario must do this before the official release or can this be done later, in a version update.

I think, this can be done later, like other things, to enhance IM5 in other versions.
At least it is not a bug, it is simply a behaviour, like IM5 does work.
I would leave it now, and change it later. At least, Mario must have work for later too ...

[Ferdinand]

If there would be an additional command
"Load/Copy workspace w2 into actual workspace w1"
this could be a good way for everybody...!?

I already suggested that. No sure if it was in this thread or the other recent workspace thread.
Got no response.

I don't recall seeing that suggestion.  I could live with that, although I don't think it's the best option.

You seem quite close to release and I'm not pushing for an urgent change, I just wanted to express support for the proposal.  But I think it's something that will crop up often after the public release.  Photoshop is in common use and its saved workspaces behave in the suggested manner.

[Richard]

I think, this can be done later, like other things, to enhance IM5 in other versions.
At least it is not a bug, it is simply a behaviour, like IM5 does work.
I would leave it now, and change it later. At least, Mario must have work for later too ...

At this point in the beta test I believe it is important that all of us think about what we ask for and ask ourselves how important a change is. As sinus says "it is not a bug, it is simply a behaviour, like IM5 does work." I would love it if all applications worked as I would like but very often this old dog has to learn new tricks.

[ColinIM]

I agree, and from my position this is not actually an urgent matter and I'd be happy to see it implemented later.

The big snag IMHO with delaying a change is that within a few weeks after IMatch 5's final release, almost the entire population of IMatch Users will become accustomed (more or less grumpily  ) to "how things are" with IM5 workspaces ... and ironically, a later (significant) change in workspace behaviour might then prove to be unpopular among the majority of Users!

But yes, on balance IMHO - given the magnitude of work needed to change this behaviour - this should dwell on Mario's lower priority list.

Colin P.

[ben]

Hi everyone,

i am very new to iMatch and was experimenting the last few days with all the options that iMatch has to offer. And that's a lot of work ;-)
I do understand all of your different point of views.

Personally, i also got confused a couple of times, since i kept on working with a (before) saved workspace and thus messed it up. No way to return to the saved one.

So maybe Mario can figure out a way that satisfies all of us (options, additional menu item, ...).
Don't confuse people who are used to the current implementation, but give the others the chance to do it the other way round.

So +1 for the first post of thrinn.

Nik

[Jingo]

In most programs that I use, workspaces do not get overwritten if one loads that workspace (not using the default workspace).   I think that is the logical benefit of workspaces - it will remain the same for later recall no matter what you do it unless you explicity save it again.

For example, in Indesign, I have a workspace setup for "book design"... it has about 15 panels open in various locations across 2 monitors.  It remembers all this perfectly each time I recall that workspace.  There are times while I have that workspace up that I need to activate and locate a new panel that was not viewable before - perhaps the Glyphs panel.  This panel is just unique to this "instance" and not something I want added to my "book design" workspace all the time.  So, when I reopen the software and choose "book design" again, that panel is not opened...  if I just open the software and do not choose the workspace - then the changes remain persistent until I do.

I wouldn't want the software to save changes to the workspace each time I add a panel... a reload of the workspace should default to how it was last manually saved (by the user).

[Mario]

In most programs that I use, workspaces do not get overwritten if one loads that workspace (not using the default workspace).   I think that is the logical benefit of workspaces - it will remain the same for later recall no matter what you do it unless you explicity save it again.

If you work in the workspace "Default" and you save it to "Temp", you make a copy of the current workspace into Temp. Whatever you do from now on, Temp will not be changed because it is not the active workspace. In IMatch you don't load a workspace, you switch to it. If you switch to the Temp workspace later, you make it the active workspace and from now on changes you make are applied to Temp.

You always have an active workspace which you manipulate.

Different philosophy.

[ben]

Different philosophy.

I totally agree. And none of it, is the only right or wrong one.
So maybe there is a solution for both

[Jingo]

In most programs that I use, workspaces do not get overwritten if one loads that workspace (not using the default workspace).   I think that is the logical benefit of workspaces - it will remain the same for later recall no matter what you do it unless you explicity save it again.

If you work in the workspace "Default" and you save it to "Temp", you make a copy of the current workspace into Temp. Whatever you do from now on, Temp will not be changed because it is not the active workspace. In IMatch you don't load a workspace, you switch to it. If you switch to the Temp workspace later, you make it the active workspace and from now on changes you make are applied to Temp.

You always have an active workspace which you manipulate.

Different philosophy.

Yes.. but - isn't it true that if I then switch to TEMP and make a change (say adding 2 panels) then TEMP gets saved and from now on TEMP will have those 2 extra panels?  IF not, then I don't understand what the problem is.. if so, then I still feel that isn't a preferred approach.   

[Mario]

When you switch your active workspace to TEMP, all changes you make to your workspace from then on go into TEMP. There is no need to manually save them, IMatch always updates the active workspace. The name of the active workspace is displayed in the IMatch title bar.

[Ferdinand]

I would like to observe that this is a feature request thread, and such a request has been made, and I support that request.

[ubacher]

I finally figured out why Save Workspace works as it does:
It is not designed to switch between different panel layouts - rather it is intended for
switching between different uses of Imatch. So switching between dealing with, say, Audio files
or Video files or Still pictures is the idea. This is why the folder, the filter settings, the category tabs, the selected script
are stored with the settings. This intended use makes it easy to understand why the current settings are stored when switching the workspace, something which
has caused a lot of confusion, not only in my mind.


My feature request is thus for a save current panel layout / load saved panel layout. This would only
change the displayed panels and their size and position. Every thing else is to be left alone.
For this, the stored layouts are not to be changed except by executing the SAVE command.

[Mario]

That's basically what workspaces do. Save panel layouts, states and the like.

[Jingo]

Ok.. so now I'm very confused.  I just played around with workspaces and did the following:
  1 - closed all panels except for the GPS panel and main browser
  2 - Saved a new Workspace called GPS
  3 - closed the GPS panel and opened the Keywords and Metadata panels
  4-  Saved a new Workspace called Keywording

So, with Keywording workspace open, I switched to GPS - all looks great!  I then switched back to Keywording, all looks great again!

Then, I closed the keyword panel and opened the Quickview panel.  I then switched to GPS - all looks great!  I then switched back to Keywording... and my Keywords and Metadata panels are gone and the Quickview panel is there... this seems like totally unexpected behavior as I create workspaces so they NEVER EVER change unless I force a save.

I guess I'm confused why anyone would want the system to autosave "saved" workspaces?  I would think a better solution would be to ask the user if the changes to the workspace should be saved when switching to a new workspace after changes were made to a saved workspace.  So, if you are on a "non-default" (saved) workspace and you make panel changes, that all great.. but the system shouldn't overwrite your workspace unless you tell it to do so when moving to a different workspace (or recalling the saved workspace to re-engage it).

Am I missing something?   

[ubacher]

You understanding of workspaces is the same as most of us - and you are confused by the behaviour
just as many of us are/were. I only started to understand why workspaces work like they do (auto-save)
when I realized that their purpose is to switch between completely different uses of Imatch: Like between
administering photos and administering mp3's.

Workspaces are (as I now realize) not designed for switching between different panel layouts.

Thus my request for a way to switch between panel layouts.

[Mees Dekker]

+1

[Jingo]

You understanding of workspaces is the same as most of us - and you are confused by the behaviour
just as many of us are/were. I only started to understand why workspaces work like they do (auto-save)
when I realized that their purpose is to switch between completely different uses of Imatch: Like between
administering photos and administering mp3's.

Workspaces are (as I now realize) not designed for switching between different panel layouts.

Thus my request for a way to switch between panel layouts.

I suppose.. though I think that is exactly what the workspaces functionality IS... one would create workspaces for MP3's, MP3's-Metadata, MP3-Previews, Photos-GPS, Photos-Keywording, PDF - Preview, PDF - Find, Fonts-Preview, etc... 

I think by just turning off the auto-save option (and adding a "Save?" dialog when switching workspace), you enable the functionality for all purposes without the need for a new set of panel saving.

[ubacher]

I think by just turning off the auto-save option (and adding a "Save?" dialog when switching workspace), you enable the functionality for all purposes without the need for a new set of panel saving.

Not quite: The selected folder, filter, etc. also needs to be left alone when we want to switch only the panel layout.

[stzari]

Hi,

Having been bitten once by the current implementation I second thrinn's request.

What I would like to request would be the following:

Add a global preference "Always use <current> workspace".
If active, this would change the behaviour of "switch workplace to <xxx>" to "copy workspace <xxx> to <current>".

At the cost of one added workspace both behaviours could be acommodated.

As an afterthought:
Saving the <current> workspace should offer to save the workspace to <xxx> (last loaded)

Stamatis

[ben]

Workspaces are (as I now realize) not designed for switching between different panel layouts.
Thus my request for a way to switch between panel layouts.

That would be an additional benefit, since i would asume that switching between panel layouts might be quicker that switching between workspaces.
Right or wrong?

My laptop needs >4s to switch between workspaces (Core 2 Duo, 2.2 GHz). So that doesn't help to quickly change the panel layouts.
Or maybe i simple need a new computer? 

[PaulS]

Agree with the posters who find the current implementation of loading and saving workspaces to be non-intuitive.  I would like to load a workspace and then not have any changes automatically saved.

An approach that I find more intuitive is implemented in Beyond Compare, a file comparison and synchronization utility.  BC allows the user to define and save "sessions", which contain settings related to comparison methods, files to include/exclude, etc.  Users can save different sessions for tasks such as backing up different folders.

After a saved session is loaded, it can be modified as desired.  However, changes are not automatically saved, but are indicated by a * next to the session name.  If the user tries to close the session, there is a prompt which asks if the changes should be saved or not.  It also gives the option to cancel, which gives the user an opportunity to save the session with a different name, preserving the changes while also preserving the original session.

See the attached jpg for an example with a session named "IMatch ProgramData" which I modified and then attempted to close without saving.

[attachment deleted by admin]

[Jingo]

After a saved session is loaded, it can be modified as desired.  However, changes are not automatically saved, but are indicated by a * next to the session name.  If the user tries to close the session, there is a prompt which asks if the changes should be saved or not.  It also gives the option to cancel, which gives the user an opportunity to save the session with a different name, preserving the changes while also preserving the original session.

Yes.. this was what I was trying to explain above as well..

[Carlo Didier]

I'd like to give my opinion on this too, though maybe a little late, but I didn't look at the layout saving before. Now I wanted to define some and because of the current way they work, I completely abandoned them as it's just too complicated to use them safely. Why?
Here's how it goes for me: I create Layout-1 and save it, plus a copy of it under Layout-1-backup. Then I must not forget to switch back to Layout-1. Same for any other layouts I create.
When I then accidentally modify a layout (which happened several times while I was trying to build them), I have to re-load Layout-x-backup and save it back again to Layout-x.

The logical behaviour for me would be that any changes made to an active layout are not saved automatically, but that as soon as I want to switch to another layout or when I close iMatch, it should simply ask if the changes should be saved under the same name or a new one or not at all. Or, alternatively, on the first change, iMatch could ask to save under a new name. But the first approach is for me the most logical and corresponds to what one is used from similar situations in nearly any other application.

Again, as it is now, it is not usable for me (and there is a bug which I'll post seperately).

[Mario]

Workspace behavior changed for 5.3.2.

[Menace]

  Great! Again!