Bug 73151 - Gallery and Styles&Formatting should open in the Sidebar
Summary: Gallery and Styles&Formatting should open in the Sidebar
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: medium normal
Assignee: Samuel Mehrbrodt (allotropia)
URL:
Whiteboard: target:4.4.0
Keywords:
Depends on:
Blocks: Gallery Sidebar-Styles
  Show dependency treegraph
 
Reported: 2013-12-30 13:11 UTC by Samuel Mehrbrodt (allotropia)
Modified: 2023-01-12 14:46 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Navigator, Gallery, Styles&Formatting still in its own window (385.00 KB, image/png)
2013-12-30 13:11 UTC, Samuel Mehrbrodt (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Mehrbrodt (allotropia) 2013-12-30 13:11:16 UTC
Created attachment 91331 [details]
Navigator, Gallery, Styles&Formatting still in its own window

In Writer the Navigator, the gallery and the Styles&Formatting window are integrated in the Sidebar.
However, when you activate one of them via the menu/toolbar/shortcut, they still open in its own window (see attached screenshot).

That brings some confusion. I suggest that they would always be opened in the Sidebar.
Comment 1 Cor Nouws 2013-12-30 13:54:20 UTC
Hi Samuel,

(In reply to comment #0)

> That brings some confusion. I suggest that they would always be opened in
> the Sidebar.

Could be that people like to have behaviour diferent from the side bar for F5 and F11 ?
Suggest to have a good discussion on this on the UX-list, related to other discussions / ideas on the side bar, styles and formatting and such ?
Comment 2 Samuel Mehrbrodt (allotropia) 2013-12-30 14:10:48 UTC
Adding UX-Advise to CC.

Can you have a look at this issue please?
Comment 3 Cor Nouws 2013-12-30 20:54:55 UTC
If I may:
- separate availability of Styles and Formatting and Navigator allows for
  - having both open simultaneously (together with panes for gallery, etc etc)
  - floating (undocked) window
  - having one docked left - independent of ...
Comment 4 Cor Nouws 2013-12-30 20:56:07 UTC
Nevertheless, when discussing the improvements we want in de Side Panel, I do not object to look at possible changes in the current situation of course
Comment 5 Heiko Tietze 2013-12-31 09:27:41 UTC
Different actions to show sidebars floating or docked? Sounds like bad usability, if I got you right, because it mixes enabling and kind of visualization. 
I suggest to always show the header for sidebars to indicates its features. This could be an improvement to the Navigator but must not be shown with the standard toolbar.
The default state of 'major relevant' toolbars should be docked, which might be Samuel's intention. Some other 'minor relevant' toolbars are shown rather floating by default, e.g. Extras. I guess the actual behavior, some toolbars are docked right now others are not, is done by hard coding.
Finally, keep in mind that sidebars are very handy for widescreens but with a 4:3 15" display I'd like to see all text. So my conclusion is to keep it as it is but store last user setting (cf. ticket #55087).
Comment 6 Tin Man 2013-12-31 12:39:19 UTC
This is one of the problems that the sidebar brings -- now there are two Navigators, two Galleries, and two Style panels. The benefit of individual panels is that two can be open at a time, while the Sidebar includes features not found in individual panels.

Ideally, the panels unique to the sidebar would be turned into separate panels, and panels in general would be allowed to be stacked into tabbed groups, much like panels in GIMP (or Adobe's tools).
Comment 7 Cor Nouws 2014-02-03 17:12:18 UTC
@mirek: listening to our discussion today, I would suggest to close this one as 'Wont'Fix' ' ?
Comment 8 Stefan Knorr (astron) 2014-02-03 20:06:59 UTC
Wait wait wait ... I'd rather keep the sidebar version of these than have a mess of panels. You won't be able to process too many panes at once anyway, so why bother? The sidebars docking mechanism is soo much nicer.
Comment 9 Cor Nouws 2014-02-03 23:14:44 UTC
Hi Astron,

(In reply to comment #8)
> Wait wait wait ... I'd rather keep the sidebar version of these than have a
> mess of panels. You won't be able to process too many panes at once anyway,
> so why bother? The sidebars docking mechanism is soo much nicer.

Really people will have the Navigator & || Stylist open and then also do stuff in the side bar...
My comment #1 was mentioned to be a retoric question :)
Comment 10 Tin Man 2014-07-25 11:00:06 UTC
I'm sorry if my comments have postponed a solution -- the current situation is really unacceptable.

Unfortunately, it seems that no ideal solution will be worked out soon, so I propose making all relevant buttons (including toolbar buttons and menu items) open the sidebar pane rather than the panel equivalent.

If it's easily implementable, we could have an advanced option for showing panels instead of sidebar panes.

If there's a problem because some people need two panes at once, we'll get that feedback and we'll work to split up the panes in question (or work out a better solution).
Comment 11 Samuel Mehrbrodt (allotropia) 2014-07-25 12:27:05 UTC
Sounds good :)
That means we need to enable the sidebar by default.
The question then is, if we should not rather remove the affected buttons from the default toolbar since we have them in the sidebar?
Comment 12 Tin Man 2014-07-28 20:49:38 UTC
(In reply to comment #11)
> Sounds good :)
> That means we need to enable the sidebar by default.
> The question then is, if we should not rather remove the affected buttons
> from the default toolbar since we have them in the sidebar?

Ideally, I'd love to see the sidebar tab strip gone and have the buttons for the individual panels moved to the toolbar, but in order to do that, we would need right alignment for toolbar buttons. (Incidentally, iWork Pages does this: http://cdn.altrn.tv/s/9cc6a0dc-8fbd-433f-95f4-c0fa4cfb6a15_5_full.png)

I guess the best thing to do now, though, is remove the toolbar buttons and show the sidebar by default. However, the "More..." entry in the style picker, certain keyboard shortcuts (e.g. F4), and some menu bar items still need to be remapped. It might make sense to have a "Sidebar" submenu under "View", listing the individual sidebar panes.
Comment 13 Samuel Mehrbrodt (allotropia) 2014-07-28 21:49:14 UTC
I'm not sure a submenu for sidebar panels is a good idea. Not every panel has a menu entry. Also how would you hide the sidebar then?

I implemented the Impress part for the navigator and gallery. Every action that opened a floating window before shows now the corresponding sidebar panel. If the sidebar is hidden, it will become visible.
https://gerrit.libreoffice.org/#/c/10582/
Comment 14 Samuel Mehrbrodt (allotropia) 2014-08-06 07:09:26 UTC
It seems that it is a common case that the navigator and the Styles&Formatting window is open at the same time (see bug 81902 e.g.). Word also has the navigator on the left side by default.
So I think we should still allow the navigator to be in a floating window (until the multiple sidebars are supported at least). I suggest to remove the navigator icon from the toolbar and have it only in the menu (which would open the floating window) and in the sidebar.
What do you think about that?
Comment 15 Cor Nouws 2014-08-06 14:15:17 UTC
(In reply to comment #10)
> I'm sorry if my comments have postponed a solution -- the current situation
> is really unacceptable.

Unacceptable for who?

> If there's a problem because some people need two panes at once, we'll get
> that feedback and we'll work to split up the panes in question (or work out
> a better solution).

I feel really uncomfortable with this approach!
You already have feedback from people that work with more panes.
So you deliberately start to break this .. PLls DON'T
Comment 16 Jean-Francois Nifenecker 2014-08-06 16:30:49 UTC
Professional writers make most of their writings on big documents. They also use advanced tools that were created just for helping manage big documents: the Navigator and the Stylist. Hence, both *must* be present at once on the screen, in anchored state, of course.
The current SideBar has some niceties and could be a nice support for the two panes we're discussing here. But it lacks the capability of displaying both the Navigator and the Stylist at once. Not having this feature while dismissing the "traditional" Navigator and Stylist panes will make professionals uncomfortable. This would cause plenty of useless mouse clicks (hint: keyboard shortcuts would be a nice enhancement btw) which would break the user's workflow.
Comment 17 Tin Man 2014-08-07 12:55:24 UTC
(In reply to comment #16)
> Professional writers make most of their writings on big documents. They also
> use advanced tools that were created just for helping manage big documents:
> the Navigator and the Stylist. Hence, both *must* be present at once on the
> screen, in anchored state, of course.
> The current SideBar has some niceties and could be a nice support for the
> two panes we're discussing here. But it lacks the capability of displaying
> both the Navigator and the Stylist at once. Not having this feature while
> dismissing the "traditional" Navigator and Stylist panes will make
> professionals uncomfortable. This would cause plenty of useless mouse clicks
> (hint: keyboard shortcuts would be a nice enhancement btw) which would break
> the user's workflow.

As I said, the ideal solution would be to have detachable panes in the toolbar -- the same approach that GIMP, Inkscape, and Adobe CS programs take. It'd be great if you could find someone to work on that.

The compromise that I would suggest, then, if we must have the individual panes as well as the sidebar, is to put the panes into "View > Floating Panes" (and remove them from the toolbar).
Comment 18 Jean-Baptiste Faure 2014-08-08 07:55:04 UTC
For me this bug report should be seen as a duplicate of bug 33223.

Best regards. JBF
Comment 19 Samuel Mehrbrodt (allotropia) 2014-08-18 15:55:11 UTC
(In reply to comment #17)
> The compromise that I would suggest, then, if we must have the individual
> panes as well as the sidebar, is to put the panes into "View > Floating
> Panes" (and remove them from the toolbar).

Would it be ok to keep *only* the navigator in a floating window and remove the floating windows for Gallery and "Styles and formatting"?
That way users can have "Styles and Formatting" and the Navigator open at the same time, but we still can start taking the sidebar seriously.

Sure in the long run we should enhance the sidebar to allow docking etc. But that is really a lot of work (compared to this task).

(In reply to comment #18)
> For me this bug report should be seen as a duplicate of bug 33223.

Well if you do the development for bug 33223 then you can close this one. If not then I'll implement this as discussed here because it's way less work.
Comment 20 Cor Nouws 2014-08-18 17:52:51 UTC
(In reply to comment #18)
> For me this bug report should be seen as a duplicate of bug 33223.


Isn't this bug much more specific?
Comment 21 Cor Nouws 2014-08-18 17:56:42 UTC
(In reply to comment #19)

> Would it be ok to keep *only* the navigator in a floating window and remove
> the floating windows for Gallery and "Styles and formatting"?
> That way users can have "Styles and Formatting" and the Navigator open at
> the same time, but we still can start taking the sidebar seriously.


Interesting thought. Also there is an bug report to bring Styles prominent in the side-bar. 
So opening the Styles&Formatting in the side bar ánd changing the Font/Paragraph props pane so that it enhances the use of styles can conflict maybe?
Comment 22 Niklas Johansson 2014-08-18 19:01:10 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > The compromise that I would suggest, then, if we must have the individual
> > panes as well as the sidebar, is to put the panes into "View > Floating
> > Panes" (and remove them from the toolbar).
> 
> Would it be ok to keep *only* the navigator in a floating window and remove
> the floating windows for Gallery and "Styles and formatting"?
> That way users can have "Styles and Formatting" and the Navigator open at
> the same time, but we still can start taking the sidebar seriously.

I think that it sounds like a great idea, it is probably the best that we can do at this point at least. Personally I prefer my navigation panel to the left so I'm probably a bit biased. ;) But I'd also like to add that navigation panels is normally located to the left, at least in the programs I use.
Comment 23 Jean-Baptiste Faure 2014-08-19 20:11:40 UTC
(In reply to comment #20)
> (In reply to comment #18)
> > For me this bug report should be seen as a duplicate of bug 33223.
> 
> Isn't this bug much more specific?

Yes, the current bug decide for the user what is the best for him. I prefer a solution more versatile which give the user the ability to adapt the UI to its needs and taste.
I agree that my proposition requires probably more work to be implemented, but once that is done, you can do what you want with sidebar and the toolbars.

Best regards. JBF
Comment 24 Commit Notification 2014-08-24 11:27:49 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4558b508141af16d335f45a0f12bdd34521e944

fdo#73151 Make better use of the sidebar



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 25 Samuel Mehrbrodt (allotropia) 2014-08-24 12:01:56 UTC
I've implemented some of the ideas that were discussed here, see commit message: 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4558b508141af16d335f45a0f12bdd34521e944

To be done:
* Remove the Styles&Formatting dialog, always open it in the sidebar
* Show the Sidebar in Calc&Draw by default (icons only) and remove Navigator, Gallery and Styles&Formatting buttons from toolbar

Currently the sidebar in Writer is shown by default (expanded) since I have not yet found a way to show only the icons by default.
Comment 26 V Stuart Foote 2014-08-24 16:07:14 UTC
Samuel, *,
(In reply to comment #25)
> I've implemented some of the ideas that were discussed here, see commit
> message: 
Great! Hope to give it a test drive tomorrow.

Might I suggest though that with this refactoring, and with Thomas A.s work on assigning an actual default SideBar Tab today, http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3ebe3e3dcdb89b7713641241f7d431352ba8c5f now would be the perfet time to also change the ordering of the Tab bar and make the "Styles & Formatting" tab the first listed and the default SideBar "Content Panel". 

This would help de-emphasize the direct formatting fostered by the "Properties" tab and panel when it becomes the second tab listed and is no longer the default.

And fyi--below is the link to the correct nomenclature for the SideBar UI elements as implemented over on AOO from the Symphony contribution. As the LibreOffice source uses these conventions as well it helps to stay consistent: https://wiki.openoffice.org/wiki/File:SidebarNames.png
Comment 27 Thomas Arnhold 2014-08-24 17:41:58 UTC
Stuart: Good explanatory link! As you are at it: "Styles and Formatting" itself would is a Deck. As "Properties" is a Deck, and "Character", "Paragraph" and "Page" are the Panels :)

For further discussion of the default Deck, see Bug 65351.
Comment 28 Michael Meeks 2014-08-25 09:33:37 UTC
AFAICS the legacy 'gallery' thing is reasonable to remove in favour of the side-bar. Wrt. the icon strip down the side of the side-bar, that is just a waste of space AFAICS - having that either in a nearby toolbar [hard], or in a horizontal 'tab bar' style toolbar at the top of the side-bar would make much more sense (to me).

There are a number of functions already available in that code (interestingly) and not enabled that may be worth playing with.

Personally - I'm also rather of the view that the ability to un-dock side-bar panels would be rather useful =) hopefully that would provide a single place to find this stuff for most users, and not hinder power users [if someone is interested in working on that ;-]. You can concieve eg. corner-case use-cases of creating documents with a ton of duplicate images in them where it'd be nice to quickly insert gallery content, and useful to format it too without switching sidebar thingits all the time =)
Comment 29 V Stuart Foote 2014-08-25 13:33:18 UTC
(In reply to comment #28)
> Wrt. the icon strip down the side of the side-bar, that is just a
> waste of space AFAICS - having that either in a nearby toolbar [hard], or in
> a horizontal 'tab bar' style toolbar at the top of the side-bar would make
> much more sense (to me).
> 

Only problem there, is that while the Tab Bar UI could be rotated horizontally, and its width dynamic (taken from width sizing of the TitleBar and Deck) it would need horizontal slider to expose the Tab icons for all decks--would get kind of ugly. Oriented vertically, it is fixed but not too obtrusive.

> There are a number of functions already available in that code
> (interestingly) and not enabled that may be worth playing with.
> 

Yup, when Andre Fisher did the port for AOO of the Symphony contribution he didn't get too far removed from the original functions--but provided a lot of framework for later enhancement.

> Personally - I'm also rather of the view that the ability to un-dock
> side-bar panels would be rather useful =) hopefully that would provide a
> single place to find this stuff for most users, and not hinder power users

Currently the whole Side Bar can be un-docked but that UI frame can not be duplicated--the decks are only linked to the one frame. It would be much more functional if all of the decks could be un-docked, each into their own frame. Support for multiheaded systems would be much improved. And power users would be happy to have option of continuing to work as in the past with Navigator, and Gallery floating.
Comment 30 Tin Man 2014-08-25 13:54:12 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Wrt. the icon strip down the side of the side-bar, that is just a
> > waste of space AFAICS - having that either in a nearby toolbar [hard], or in
> > a horizontal 'tab bar' style toolbar at the top of the side-bar would make
> > much more sense (to me).
> > 
> 
> Only problem there, is that while the Tab Bar UI could be rotated
> horizontally, and its width dynamic (taken from width sizing of the TitleBar
> and Deck) it would need horizontal slider to expose the Tab icons for all
> decks--would get kind of ugly.

Using a right-aligned toolbar instead would solve this problem.
(Incidentally, iWork does this: http://alt2cdn.blob.core.windows.net/dist/s/9cc6a0dc-8fbd-433f-95f4-c0fa4cfb6a15_5_full.png . "Format" and "Setup" are the "tabs" here.)
Comment 31 Samuel Mehrbrodt (allotropia) 2014-08-25 17:13:15 UTC
A problem with having the buttons in a (right-aligned) toolbar is that the toolbar always stays in the same place, but you can move the sidebar to the left e.g.

I think the current situation (vertical tabs) is the best compromise.
Comment 32 Yousuf Philips (jay) (retired) 2014-08-26 23:17:57 UTC
Tested it in writer and it looks good, except that navigator isnt activating the sidebar yet.

Thanks for removing those least used buttons which i had already recommended in my toolbar proposal (bug 81475), as it gives way for the addition of useful buttons like inserting an image (bug 82822), footnote (bug 83117) and comment (bug 83118).

Daniel had suggested a mockup of the tab button appearing in the toolbar area - http://i.imgur.com/uvEVi5w.png - though i think it should actually be part of the sidebar and elements being able to pull out of the sidebar, like in photoshop and gimp.
Comment 33 Samuel Mehrbrodt (allotropia) 2014-08-27 08:02:10 UTC
> it looks good, except that navigator isnt activating the sidebar yet.

@Jay: That's intentional, see comment 16.


> Daniel had suggested a mockup of the tab button appearing in the toolbar area - http://i.imgur.com/uvEVi5w.png - though i think it should actually be part of the sidebar and elements being able to pull out of the sidebar, like in photoshop and gimp.

Being able to pull out elements from the sidebar is a long-term goal. It will take some time to implement and is definitely too big for me. So we try to make the best out of the current situation.
The tabs need to stay with the sidebar since you can move the sidebar to the left and the tabs need to move also.
Comment 34 Yousuf Philips (jay) (retired) 2014-08-27 10:37:32 UTC
@Samuel: Sorry didnt completely get it when i read it the first time but do get it now. :)

So why not have the navigator dock by default in the left side, as i've seen screenshots from a number of users where they docked it this way. Also there was a discussion recently in bug 83026 and most agree that navigation elements are fine to be docked on the left. Users will still be able to undock it if they want to have it floating.
Comment 35 Commit Notification 2014-09-03 08:49:16 UTC
Thomas Arnhold committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae218332b13a82e13f1a9a9f0fb79ef76a51ce39

Related: fdo#73151 bring ZoomToolBox back



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 36 Commit Notification 2014-09-03 08:49:34 UTC
Thomas Arnhold committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b27bca82a3afc98746b5170e1c4cba3f779ab79

Related: fdo#73151 bring DesignerDialog back as invisible button



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 37 Yousuf Philips (jay) (retired) 2014-09-03 11:29:23 UTC
@Thomas: you forgot to bring back the separator as well which was next to the designerdialog button. :)
Comment 38 Thomas Arnhold 2014-09-04 22:28:31 UTC
Jay: Thanks for the hint :)
Comment 39 Commit Notification 2014-09-04 23:23:13 UTC
Thomas Arnhold committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=040a59e513b6435fb39bfecad9a54b3283216d0e

Related: fdo#73151 bring DesignerDialog separator back too



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 40 Gerry 2014-09-22 06:15:32 UTC
Hi, I have a question regarding the move of styles and formatting into the sidebar: My workflow working on long documents is to have the navigator docked to the left side and the styles&formatting (& formatting) docked to the right side. Hence, for long documents it is not user friendly to be forced to have both in one sidebar. I assume that this workflow is common for everyone who works on long documents.

Will it be still possible after these patches in this bug report to have these functions separated, i.e. one on the left, the other on the right side? Or do these patches block this workflow? If so, please consider this user scenario as a relevant one.

Thanks!
Comment 41 Samuel Mehrbrodt (allotropia) 2014-09-22 07:55:47 UTC
(In reply to comment #40)
> Will it be still possible after these patches in this bug report to have
> these functions separated, i.e. one on the left, the other on the right
> side? Or do these patches block this workflow? If so, please consider this
> user scenario as a relevant one.

Yes, multiple users use Writer this way and we have decided to leave the Navigator in its own Window. So you can place it where you want as before.
Comment 42 Commit Notification 2014-09-24 17:59:55 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=473ed449a4b6f550dc1af47a07c6e0ef243a98b2

fdo#73151 Always open Styles&Formatting dialog in the sidebar



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 43 Commit Notification 2014-09-25 09:03:17 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=89ecdc47e14e3be7fe939b5e76985b9531fcfb42

Revert "fdo#73151 Always open Styles&Formatting dialog in the sidebar"



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 44 Samuel Mehrbrodt (allotropia) 2014-11-05 08:26:57 UTC
Closing this - if there are still issues with this please open a new bug.
Comment 45 Mike §chinagl 2015-01-22 11:10:48 UTC
This bug fix comes with LibreOffice 4.4 and is mentioned in the release notes (https://wiki.documentfoundation.org/ReleaseNotes/4.4) 

Now enabled by default in Writer, in addition to Impress (where it was enabled since 4.2). Also, the Sidebar now combines the functionalities of the old “Gallery” and “Styles & Formatting” floating panels, removing a lot of UI redundancy.
Comment 46 Daveo 2016-10-23 12:46:54 UTC
This change is the total antithesis (opposite) of what I and some of my clients want. I would have proposed a user selectable/definable option, instead of this "all or nothing" approach.

Should I reopen this, or submit a new RFE bug?
Comment 47 V Stuart Foote 2016-10-23 13:22:48 UTC
@Dave, *
(In reply to Dave Barton from comment #46)
> This change is the total antithesis (opposite) of what I and some of my
> clients want. I would have proposed a user selectable/definable option,
> instead of this "all or nothing" approach.
> 
> Should I reopen this, or submit a new RFE bug?

Please do not reopen, never helpful. Rather submit a new concise description of what is perceived as useful. And more importantly describe how UI would function relative to the current defaults of Gallery and Styles & Formatting resident as Sidebar decks?

If simply a desire to have each open as independent decks, and more than one visible docked or undocked (as the old src dialogs had been)--that is open as bug 85905

Otherwise looking forward to your new RFE and reviewing its description.

Stuart
Comment 48 Daveo 2016-10-23 16:00:27 UTC
(In reply to V Stuart Foote from comment #47)

Thanks Stuart. I had missed this in my Bugzilla search and have now added my thoughts/comments there.