Session management

[ersi-dnd]

1. I have Otter set to continue from last session
2. I have some other sessions saved in session manager
3. So, I have the Default session open and then I open another session in a new window, let's call it Home session
4. I switch back to the Default session window and close it (by the way, closing one of the windows when two sessions are open often causes Otter to crash)
5. The other window closed, I turn to the newly opened window and I think I am in Home session
6. I close Home session, i.e. I close Otter entirely
7. When I open Otter again and go to session manager, it's called Default session again

I thought about this a bit and I think this behaviour should remain as it is. However, there should be more clarity in session management. Like this:

• There's always a Default session, saved as default.ini in sessions folder in the profile
• Whenever Otter starts, it starts as per default.ini session
• Whenever Otter is in session, its status is observed by default.ini session
• When a new Otter session is saved in session manager, the status is saved as another ini file
• Title and Identifier columns in Session manager should be one - Identifier. Otherwise it seems there arise session conflicts (this is why I think Otter often crashes as I described at step 4 above).
• The name of the Default session should be unalterable, but it would be nice to make it possible to rename other sessions in the session manager, just like you can in Search engines manager, somewhat, by triple-clicking on them.
• The Default session constantly follows its own state automatically. Recovery of the last session is done based on what's found there.
• Other sessions are saved instances from the moment when a new-name session is saved or a pre-saved session is replaced.
• When another session is opened, it's actually Default session that continues. It's just a saved session re-opened within Default session.
• When another session is saved, it's actually the state of the Default session saved under another name in another session.ini file, whereas the current browser session remains Default.
• Hence no session switching is possible within Otter. The running session is always Default. This is to prevent session conflicts.
• Other sessions do not get automatically saved when they are continued. They must be explicitly saved again to replace their earlier state.
• Some might think this is too limiting and inflexible, but separate profiles provide all the added flexibility one might want.

I hope this ticket here also clarifies how I think the "Save" buttons should work in session manager, as described in #577

[Emdek]

@ersi-dnd, yes, this is exactly the way as it is currently implemented (maybe except renaming of other sessions), with exception that startup dialog or --session switch should run application as specified session and not default one. One missing bit is the option to truly continue from previous session (load session manually selected on startup). Autosave is currently enabled only for default session and it might be a good idea to make it a per session option (this could also apply for #582).

Please note that currently it is possible to have only one named session running per profile, as SessionsManager exists per profile and not a group of windows (this could be changed but it would require designing some good way to mark windows as belonging to specified session), so once one session is opened then other sessions will be appended.

I'm not aware of these mentioned crashes, I'll try to reproduce that but backtraces are always welcome. ;-)

[ersi-dnd]

@Emdek Please note that currently it is possible to have only one named session running per profile,..

Do you mean session title? The thing that puzzles me that when we choose Save current session, the dialogue offers two names to write:

• Session title
• Session identifier

I found that the safest way (to avoid crashes) was to change them both. But then, why not have just one, the stronger one, the identifier?

When I change both the title and the identifier, I can save as many sessions in the profile as I like. The only question I have here is why I have to type the names twice - as title first and then as identifier too.

[Emdek]

@ersi-dnd, I was talking about different context, but yes, identifier (not title, it was supposed to be more user friendly name to be shown to user) has to be unique per profile since it is also used as file name. It could be a good idea to modify save dialog a bit, put identifier first and use it as initial value for title.

Please note that currently it is possible to have only one named session running per profile,..

I meant that we can't have two named sessions running simultaneously as currently we can keep track of only single identifier.

[ersi-dnd]

@Emdek It could be a good idea to modify save dialog a bit, put identifier first and use it as initial value for title.

Why not modify the save dialog so that you get only one name to save? When we save files, and we pick a filename for it, we don't type it twice, do we? Is there some special need to have both title and identifier?

Re: Please note that currently it is possible to have only one named session running per profile,.. I now understand. My crashes must have come precisely because I was trying to make two sessions run side by side.

[Emdek]

@ersi-dnd, there is good reason: to keep filenames limited to basic latin alphabet and numbers and to have user friendly names using anything that can be encoded in UTF-8. And we shouldn't hide filename as it is useful for --session switch.

[ersi-dnd]

Well, can we agree on something like this?

• In Save session dialog there are two fields like now, one for "Title" the other for "Session ID".
• "Title" is where the user types whatever the user likes, in native tongue, Chinese or whatever.
• When the user types the title, the "Session ID" at the same time self-fills in ASCII. Session ID also equals the session filename in /session directory.
• "Session ID" field is inaccessible and uneditable by the user.

[Emdek]

@ersi-dnd, it could work that way but I'm not sure if it will be easy to find good transliterator for all cases (this is why I've suggested to do it the other way around). Session identifier should by writable in all cases, so user won't end up with some odd identifier that cannot be changed without closing application and renaming file manually. ;-) Of course the second filed (be it title or identifier) would be filled automatically only when it's empty.

[ersi-dnd]

Well, my idea is good because it clarifies these issues very well:

1. We need an algorithm that would translate anything into ASCII sensibly
2. The user must understand that the filename must be ASCII

My idea makes the second point clear to the user without extra warning. It will be self-evident.

As to the first point, I guess such translating algorithms already exist and it's just a matter of picking the one you feel is most sensible.

[Emdek]

@ersi-dnd, maybe, but transliteration is not a trivial task and so far I've only found tools to cover single language... Identifier has validator, it only accepts latin characters, numbers and AFAIR underscore.

[ersi-dnd]

Frenzie may know more about those transliteration things.

[ersi-dnd]

Ah, but this raises the question: There's a list of sessions in File > Sessions. How does the user determine if they open in the same or new window? If it will be as it's checkmarked in the session manager, then how will it be shown in the menu list? Will it be shown at all?

For me looks like a global setting would make best sense.

[Emdek]

@ersi-dnd, uhm, we could add some kind of hint there, for example:

Test Session (2 tabs, the same window)

Or something like that. It's kind of edge case, if user doesn't remember settings then there is always full list with details in manager.

[ersi-dnd]

Again I saved a session in Otter and I must say that it's extremely counterintuitive to have to type two names for one session. The way Opera had solved this was this:

• In the interface, users only see "Title"
• When a session is saved, a separate file with the title's name (or an approximation of that name) is saved in the profile. The user only sees that name when he looks in the profile

I find Opera's way much more user-friendly. You may think it's friendly to let users set the session filename (session id) too, but actually only advanced users understand this after some puzzling, like I was puzzled about it.

I warmly recommend doing it either Opera's way or as I suggested in https://github.com/Emdek/otter/issues/578#issuecomment-67751714

As to the algorithm problem, how about this:

• In Latin-based writing systems, change the filename to the base ASCII alphabet, ä -> a etc. (as far as I know, there are such Latinizing transliterators for Slavic and Greek alphabets too)
• For other writing systems (Arabic, Indian, Chinese), use numbers, like 0001, 0002, 0003 etc.

[ersi-dnd]

And, naturally, Opera has this feature: I can move any file into the /sessions folder when Opera is closed. If the file has appropriate session content (particularly the header) then Opera recognises it on startup and displays its title in the menus and session manager. This is indeed how advanced users would want it.

[Emdek]

@ersi-dnd, ICU seems to be best choice for transliteration. As noted earlier, this field should be visible:

And we shouldn't hide filename as it is useful for --session switch.

It seems to be better idea to let to set identifier when creating session than require to rename it later. But for sure it has to be documented and we should make use of QWidget:::whatsThis(). Sessions management by itself is a feature targeting more advanced users, a someone recently noted, we should have some kind of dictionary with definitions of basic terms like profile, session etc.

Sessions can be created manually, the same way like in Opera, just by placing them into folder, we could even allow to do it when profile is in use (with exception that file of current profile will be recreated if autosave is enabled and session will be marked as dirty).

[ersi-dnd]

Okay. Then modify my recommendation in the linked comment like this:

• When the user types the title, the "Session ID" at the same time self-fills in ASCII. Session ID also equals the session filename in /session directory.
• "Session ID" field is accessible and editable by the user so that he can overwrite when he doesn't like what was automatically offered there

[Emdek]

@ersi-dnd, lets keep discussion as is, we can use #577 for conclusions.

So, the first conclusion is to automatically generate identifiers from titles (still having some fallback mechanism, as different words can generate the same identifier or resulting string may end up empty for some reason), which could be also applied for all other uses (these annoying prompts asking for unique identifiers...).

I would like to use this this ticket to continue discussion about possibilities to run more than one session simultaneously:

• how to mark these windows (there are some existing solutions out there, but we need something universal and obvious, appending name of session to window title seems to be best idea);
• if there should be different way to run them other than executing --session with different identifier while another one is already active, for example by adding additional checkbox - Append to current session (there is alternative by turning checkbox determining if it should be opened in the same window to combobox, but that could be less readable for users), or using different wording, which ensures that user will be aware of the difference (keeping session separate or opening its windows / tabs as part of current session).

[ersi-dnd]

@Emdek So, the first conclusion is to automatically generate identifiers from titles (still having some fallback mechanism, as different words can generate the same identifier or resulting string may end up empty for some reason), which could be also applied for all other uses (these annoying prompts asking for unique identifiers...).

I'd favour a mechanism where the Save session only has one prompt: Do you want to overwrite? [Yes] [No]

As to the fallback, when the strings happen to match, then the suggestion mechanism would simply add a number to the end. Would this work? And indeed it occurred to me that the identifier should be editable, because I often most definitely want to overwrite a session, not to create a new one. So I should be able to set an existing identifier and overwrite it with Save session dialogue. But it could be more intuitively done in the Session manager, if Session manager had a Save button.

As to running multiple sessions side by side or within the same window, each evidently auto-updating its own status, I must say I don't see the use for this idea. I think that even when there's an Otter instance already up and running, and the user launches another session by --session, then the newly launched session should become an integral part of the running instance, because they are the same profile after all.

Maybe I will get different ideas later. We'll see.

[Emdek]

@ersi-dnd, I meant totally unrelated use cases, like identifiers for custom shortcuts set or search engines. And yes, we would append increasing numbers and use specified keyword as base (for example session in case of sessions) if transliterated value would be empty.

As to running multiple sessions side by side or within the same window, each evidently auto-updating its own status, I must say I don't see the use for this idea.

No, we won't allow this case, single main window cannot host multiple sessions, as hierarchy is as follows:

1. profile (set of settings and global history etc.),
2. session (set of windows and tabs),
3. window (set of tabs),
4. tab (with own history and optionally settings with highest priority) or stack of tabs (containing tabs and possibly other stacks).

[ersi-dnd]

Let me get this straight. When you have Otter open, you want to be able to launch another session by --session and you want the window title to display the session name/title/identifier? I see no point to naming windows when the session really belongs to the current running instance and the relevant session file does not get updated anyway.

[Emdek]

@ersi-dnd, only when there is more than one session running (or show it always for windows belonging to sessions other than the default - as identifier), so it won't add noise when using single session. And I don't think it really matters if it is autosaved or not in this case as user would want anyway to distinguish them as they can be closed separately (by closing all windows belonging to one of them or using some new action, like Close Current Session). Also all of them could be restored if setting startup behavior to continue previous.

[ersi-dnd]

@Emdek only when there is more than one session running (or show it always for windows belonging to sessions other than the default - as identifier), so it won't add noise when using single session.

But the difficulty of comprehension that I have lies in the fact that the running instance is always a single session, called Default session. When Otter is open, it's the Default session that is open. Other sessions may be launched secondarily, but they become part of the running instance - Default session.

It's like bookmarks and history. When I open a bookmark, I don't need to know afterwards what folder it came from. It's just my browser window displaying webpages. I may sort my history and open up a link from there, but as soon as I have opened it, I don't need an indicator that it came from history. When I open up one page from bookmarks and another from history and the first displays "This came from Bookmarks" and the other "This came from History" then this actually is noise, too much detail.

I see sessions the same way. As soon as a session opens up, it's an integral part of the running instance. No special indicators necessary. It seems to me you want to overelaborate something that does not need elaboration.

Similar with the "Open in the current window" option. It may seem like an advancement to have the option separately for each and every session, but as you remember, this raised the problem how to indicate in the File -> Sessions menu list which session opens in the new window and which in the current window. Something that should be simple becomes complicated this way. The global sticky option for "Open in the current window" would be much simpler to handle.

I personally would always want to open sessions within the current window. What to do with --session I don't know. The most sensible solution seems to always open sessions launched by --session in a new window. And it should not display session indicators anywhere. Otter is just Otter, no matter how many windows it has open.

If you want names for windows or names for tabgroups, then the user perhaps could have those names flexibly on the fly in the tabs sidebar. Not tabbar. Tabbar is good as it is now. This extra information could find its place in tabs sidebar or in the full-size tabs-and-windows manager about:tabs.

[Emdek]

@ersi-dnd, well, the point is to allow different use cases, which are perfectly valid. Current mechanism has to be changed anyway after beta4, as I want to finally go for model based architecture for managing active session and this will be extended to manage all sessions (since it's a kind of requirement to allow to modify sessions by dragging items from one to another, as suggested in #577, at least without additional complexity or code duplication). We could take advantage of that rework and add this new feature for advanced use cases.

[ersi-dnd]

Wait. You mean allow dragging session items (i.e. a specific tab of a session that is displayed in the session manager) to another session in the session manager? This is indeed an overelaboration. Advanced tabs management can take care of this:

1. Open up a session (not the session manager, but the session with all its tabs in the browser)
2. Open up another session in another window
3. Go to the tabs manager (sidebar and/or about:tabs which should of course display the tabs of all open windows like Opera does)
4. Drag tabs around as you please
5. As soon as you are happy with the tabs in one of the windows, save that window as a session

[Emdek]

@ersi-dnd, sure, it could work also this way. Although it's far easier to do when you don't have to switch windows and there is no requirement at all to open source or target session.