New approach for sidebar(s)

[Emdek]

Currently we support only one sidebar and let to select on which side it should be shown, which is not flexible enough and not very straightforward as that option is quite hidden. We had already explored possibility to have two or unlimited amount of sidebars but back then we had blockers, for example let switcher for active panel to know to which sidebar it belongs (in sane and generic way, not some ugly workaround) or let them have own keyboard shortcuts. And this can be now solved by passing parameters when action is triggered (in this case identifier of sidebar).

In case of keyboards shortcut we can start appending dynamic actions that contain identifier of associated sidebar. Sidebars will be able to (by default) associate their panel switcher widget to themselves etc.

From technical point of view sidebar would become (not so) special case of toolbar, but instead of set of actions it would contain special widget to display panels etc. Being toolbar will allow to move them around just like other toolbars when interface is unlocked.

Right now floating sidebars aren't planned yet, but this approach might allow to add them in near future (their blocker was QtWebKit disliking so much detaching from main window that it simply crashed, when there were web panels around).

[Emdek]

This ticket is also open for discussion about layout of sidebar contents and how it could be improved and become more flexible. If there should be just ability to define that mini toolbar on top once for all instances or separately. Plus options to disable switcher icons and toggle button belonging to instance of sidebar, not being part of global settings.

[Emdek]

There is important related topic, if we should allow to set independent toolbars settings per main window (sidebar is going to become special case of toolbar soon), which seems to be required by tickets like #898 and even seemingly unrelated #1240 (I could disable unwanted toolbars there by passing custom configuration when creating such main window, which a bonus of allowing to show them again in standard way, or create such minimal main window from existing one). But there are two issues that have to be solved first:

1. how far should it go, should it be just list of elements (toolbars and sidebars settings - which panels are enabled, which one is active etc.) or complete configuration tree (easier and more powerful approach);
2. in case of the latter path: how to expose in friendly way configuration determining if this toolbar should end up in global configuration or just as session specific tweak to single main window, basically how to allow to determine global default settings and main window specific set in sane way (there could be some checkbox in options to mark it as "local" toolbar, but that doesn't resolve issue of default locations etc.). We could also allow to decide if toolbar settings should be shared or not, but then we would still have to store at least state of sidebars (which panel is opened). Another thing, what to do when creating new main window, should it inherit settings from active main window or prefer global settings (there could be an option to toggle behavior)?

Perhaps default toolbars settings could be resolved by using approach similar to Firefox, special about page which triggers appearance customization and in our case also some checkbox determining if this set should become default template or just be applied to current main window. In this case we still need to determine sane defaults (perhaps by default making new toolbars global and only keeping visibility and location settings for toolbars and sidebar settings as values that are applied on top of global settings when creating main window).

[ersi-dnd]

@Emdek There is important related topic, if we should allow to set independent toolbars settings per main window

Can a single session handle (save and open) multiple main windows without crashing and other problems? Multiple instances can handle whatever alterations to main windows, but can a single session do it?

@Emdek Another thing, what to do when creating new main window, should it inherit settings from active main window or prefer global settings (there could be an option to toggle behavior)?

A toggle should solve it: New Window either clones the existing window or opens a new default/global one.

For me, True Detach as distinct from New Window provides all the flexibility required to handle any possible workflow.

[Emdek]

@ersi-dnd, I haven't seen any issues with multiple main windows, I guess that defaults could be improved, but that's all. Right now all toolbar and sidebar settings are shared by all main windows, whatever you will do in one, others will follow.

The point is to have flexible internals to allow to create "true detach" as simply set of options on top of it, not something completely special. ;-)

[Emdek]

Proposal for options (naming needs polishing): Sessions/ReuseCurrentToolBarSet (boolean, TRUE by default) - copy set of toolbars (including state) when creating new main window from "parent" one; Sessions/PreserveToolBarSetMode (list, stateOnly by default) - none (do not preserve, use global set), stateOnly (preserve just state, not definitions, except these toolbars that were created as non global ones during that session), stateAndDefinitions (preserve both state and definitions, so if toolbar gets removed od modified globally it will be still work when loading this session).

Note that "toolbars" means toolbars and sidebars.

[ersi-dnd]

Sessions/ReuseCurrentToolBarSet - if this refers to what happens when you open a new main window, I would suggest Sessions/NewWindowCopiesCurrent or Sessions/NewWindowClonesCurrent

Sessions/PreserveToolBarSetMode this refers to what gets saved in session files? Maybe Sessions/SessionSaveMode and 0|1|2|etc along with definitions what they do. What do you think?

[Emdek]

@ersi-dnd, I have strict rule of no numeric only option values (unless they are... numeric ;-)). What about Sessions/InheritWindowSettings (or something like that), then it could also replace Interface/MaximizeNewWindows.

[ersi-dnd]

@Emdek What about Sessions/InheritWindowSettings (or something like that), then it could also replace Interface/MaximizeNewWindows.

Yes :) and I think that this particular option actually makes more sense under Interface or Choices , not under Sessions

[Emdek]

@ersi-dnd, Choices is sort of fake category used for the first use time choices, but that reminds me that we could consider asking what to do when user new window is requested and requesting main window differs from global settings, and always copy geometry and state.

[ersi-dnd]

@Emdek that reminds me that we could consider asking what to do when user new window is requested and requesting main window differs from global settings, and always copy geometry and state.

And that reminds me that there are people whose new-tab popups (from e.g. target=_blank) open up in new windows instead. Sometimes those popups are heavily modified: The website wants to hide addressbar and limit right-click options. All this should be considered. The new window has to strike a balance between what the user should reasonably expect, what should be possible to configure, and what website scripts can do.

[Emdek]

@ersi-dnd, yes, this one of reasons for these concepts, I could allow them to hide Navigation Bar and allow to reshow it the same way as Opera did, using toggle to allow to show it again, toggle that is going to be shared with sidebars (that optional toggle edge). ;-)

[ersi-dnd]

@Emdek I could allow them to hide Navigation Bar and allow to reshow it the same way as Opera did, using toggle to allow to show it again, toggle that is going to be shared with sidebars (that optional toggle edge)

It could be a general option when hiding toolbars: Either hide completely or collapse into the minimised thing that expands on click. For example Seamonkey (and former Mozilla suite) never really hides toolbars, but collapses them.

Something like Interface/HideToolbars (list, hide | collapse)

[Emdek]

@ersi-dnd, it will be generic option, per toolbar / sidebar.

[midluk]

8733deab8b3a27846c572215dcf68dc8d83e6746, which seems to be part of this work, has broken address bar focus on new tabs for me (legacy QtWebKit).

[Emdek]

@midluk, yeah, quite possible, but should be easy to fix.