Saving configuration on exit / multiple instances

[Oliver S]

Not sure, maybe this is really a feature request.

I have switched off the setting to save the configuration on exit, because it seemed to take too much time. Now I noticed that some things are not saved on exit, which I wouldn't have thought to be part of "the configuration". In other words, I would really like to have the following things saved (in the hope that this will be far quicker than a full save):

• the last directories of the two panels
• last sort orders, fiters - everything that can be configured directly from the Left and Right menus, maybe with the exception of the columns.
• the Shift+F4 history

I'm sure there are other things similar to this.

Another idea: why don't you change the configuration logic so that changes from the configuration dialog are saved after the dialog has been left? Only the changes that the user made, of course, not the complete set. This should also be very fast under most circumstances and get rid of the lengthy saving process.

Now, the second thing, but related to this, is the fact that I have multiple instances of SS running most of the time. When I make an important setting change in one of these instances and Save that, I would like to be able to Load the configuration in the other instances, without having to restart them. Also, if I forget to Load the configuration (or restart, as things are now), I might decide at a later point to Save the configuration from one of those other instances - and kill the earlier changes that are already saved. It would be better if the current instance would note at this point that its "copy" of the configuration is not a current one, because the registry settings have already changed, and ask me about it.

I hope this doesn't sound too chaotic... now, from a professional perspective (I have some experience with software design, see my blog at http://www.sturmnet.org/blog if you want) I find that the whole saving mechanism is pretty poorly implemented for certain use cases. It works fine in many ways, but it has enormous drawbacks in others. If I were you, I would:

1. change the configuration system from the registry to a config file system, use XML for the config file
2. implement the saving system in such a way that all changes are saved immediately after the user has confirmed them. It's crap to have an app running for a few days, until it crashes, and lose a wealth of configuration changes that the user doesn't even remember any more. I never switch off my system and I never quit certain applications - why would I?
3. make running instances of SS watch their configuration file using Windows API. Ask the user whether he wants settings reloaded when the file changes. Notify the user when he tries to change settings while the file has newer than the ones loaded into the running instance.
4. extract that "run information"/history/whatever information that I listed at the beginning of this post from the overall settings and store it elsewhere. Make all running instances access the same store of that information. For example, if I use Shift-F7 to access a specific location in one instance, and later I hit Shift-F7 in another running instance, I want to see the history entry.

Is this a re-design of a functional area? Yes, sure it is. But it shouldn't be too difficult if your settings system is well designed internally. I hope you find my suggestions useful.

Oliver

[Jan Rysavy]

Hi Oliver!

Thank you for your post, I will move it to the Feature Requests section.

Option to store settings to file instead of Registry is already on ALTAP Roadmap.

I have switched off the setting to save the configuration on exit, because it seemed to take too much time.

How long it takes on your computer to save Servant Salamander settings? We run Servant Salamander whole day so one or two seconds is not a problem for us.

make running instances of SS watch their configuration file using Windows API. Ask the user whether he wants settings reloaded when the file changes. Notify the user when he tries to change settings while the file has newer than the ones loaded into the running instance.

Do you know other applications with such functionality?

[jis]

I have switched off the setting to save the configuration on exit, because it seemed to take too much time.

How long it takes on your computer to save Servant Salamander settings? We run Servant Salamander whole day so one or two seconds is not a problem for us.

Just curious, I measure how long is SS exiting on my old 1GHz notebook: 0.9s.

[jis]

1. change the configuration system from the registry to a config file system, use XML for the config file
2. implement the saving system in such a way that all changes are saved immediately after the user has confirmed them. It's crap to have an app running for a few days, until it crashes, and lose a wealth of configuration changes that the user doesn't even remember any more. I never switch off my system and I never quit certain applications - why would I?
3. make running instances of SS watch their configuration file using Windows API. Ask the user whether he wants settings reloaded when the file changes. Notify the user when he tries to change settings while the file has newer than the ones loaded into the running instance.
4. extract that "run information"/history/whatever information that I listed at the beginning of this post from the overall settings and store it elsewhere. Make all running instances access the same store of that information. For example, if I use Shift-F7 to access a specific location in one instance, and later I hit Shift-F7 in another running instance, I want to see the history entry.

Your plan seems to me very reasonably. Did you think about something like rebuilding SS into client server architecture...?

[jis]

Oh, no. The problem with server clock is back again. I publish this message in 17:25 not in 23:41.

[KNUT]

For me this issue is not a problem. Also 2, 3 or 4 seconds to save the configuration - I can live with.
I start Servant Salamander once a day - that's it
Sorry, but I don't understand the excitement

[jis]

For me this issue is not a problem. Also 2, 3 or 4 seconds to save the configuration - I can live with.
I start Servant Salamander once a day - that's it
Sorry, but I don't understand the excitement

The Oliver's proposal is not only about delay when SS is saving all configuration on exit, but mainly about technique of work with multiple instances of SS. That is the point.

[KNUT]

That is the point.

Thanks for your advice, jis

[Oliver S]

How long it takes on your computer to save Servant Salamander settings? We run Servant Salamander whole day so one or two seconds is not a problem for us.

I don't think it takes longer than a second or two. But I still find it a nuisance and, honestly, it's just the wrong place to save settings... and if you use more than one instance of SS, you can't use automatic saving on exit, because then it's most probable that you'll kill important settings from another instance when exiting.

make running instances of SS watch their configuration file using Windows API. Ask the user whether he wants settings reloaded when the file changes. Notify the user when he tries to change settings while the file has newer than the ones loaded into the running instance.

Do you know other applications with such functionality?

Actually, yes. But is that the point?

1. It's easy to do, so why wouldn't you do it?
2. If nobody's done it before, it'll be a great feature for your product.

Your plan seems to me very reasonably. Did you think about something like rebuilding SS into client server architecture...?

Me? No I wasn't going to publish a concept for an allround SS redesign And I don't think they need it, or I wouldn't like the app as much as I do.

For me this issue is not a problem. Also 2, 3 or 4 seconds to save the configuration - I can live with.
I start Servant Salamander once a day - that's it
Sorry, but I don't understand the excitement

Who's excited? And anyway, the remark about the time it takes to save settings was just that... a remark. I don't usually quit SS at all - ever. All the more reason to state that the moment when I quit the application is the wrong point to save settings. This should be done the moment the settings are changed, IMO. Maybe this is hard to imagine, but to me the usual way of ending work with most Windows apps (okay, those that I consider "everyday tools" and which I have always running) is that they crash. Of course there are apps that don't crash - those exit when Windows crashes every 10 to 20 days or so. In either event, I never get my settings stored on exit

Just as anecdotal evidence for my way of working with computers, maybe this blog post is funny: http://www.sturmnet.org/blog/archives/2 ... witch-off/

Oliver

[mazy]

guys, this is in some ways related to issues from my feature request here. i'm sort of sad that no one took time to reply to them ...

[jis]

guys, this is in some ways related to issues from my feature request here. i'm sort of sad that no one took time to reply to them ...

Don't be sad
Maybe the reason was, that forum has had some problems with server clock, so posting was disabled. Next day your post was past for forum participants...

[Jan Rysavy]

make running instances of SS watch their configuration file using Windows API. Ask the user whether he wants settings reloaded when the file changes. Notify the user when he tries to change settings while the file has newer than the ones loaded into the running instance.

Do you know other applications with such functionality?

Actually, yes. But is that the point?

1. It's easy to do, so why wouldn't you do it?

The point is that it is not easy to implement (in Servant Salamander).

Oliver, why do you run multiple instances of Servant Salamander?
Would the Tabbed browsing (as you know it from Firefox/Opera) satisfy your needs?

[mazy]

jan, i also run multiple instances of salamander ... from just one to 3, mostly just two. some info why and what would help is in my post here.

as for tabbed browsing, yes, that would help. not sure what i would like better (tabbed vs. what i proposed), however my ideas would be actually very helpful for tabbed browsing too ...

jan, if you could find some time, could you read my last three posts in this forum?

[jis]

jan, i also run multiple instances of salamander ...

I use usually two instances of SS. Only for really simple task I use only one instance. But with more than one SS running simultaneously I must carefully think about potential problems with saving configuration on exit in different instances.

Tabbed SS will be definitely helpful. And Mazy's idea of subsets of configuration settings related to panels/tabs will be really great.

I use as my primary web browser Avant Browser. I can say, that there is no way back, when one habituate to tabbed browsing.

[Oliver S]

Oliver, why do you run multiple instances of Servant Salamander?
Would the Tabbed browsing (as you know it from Firefox/Opera) satisfy your needs?

Partly, I guess. The part where it would not help is to do with my way of working. I have a lot of different things to do all day. Often one things interrupts me in the middle of something else. Usually the things I'm doing have to do with files. When something interrupts me while I'm doing something else, I run another instance of SS to work on that new thing. I leave all windows of previous tasks open. I have a big workspace over three screens and I often have tens of windows open. Seeing these windows in their positions reminds of the job I was doing in them and helps me remember where I left off. Does this make any sense?

I do use tabbed browsing with Firefox all the time. But I still have multiple Firefox windows open most of the time, I guess maybe up to five or so, most of them with five to ten tabs. This is the same task-oriented system, mostly.

That said, I do like mazy's idea of the workspaces - depending on how this is implemented, it might be a solution to my own troubles as well.

Oliver

Sorry I don't reply faster - every second time I try to post, I find it's currenly deactivated for some reason