Created attachment 186880 [details] Color Bar in Sidebar I opened the Color Bar and tried moving it to the right side of the Workspace hoping the color tiles would form a long vertical column. The shape of the Color Bar remained the same, but somehow it got to the right of the hide/reveal Sidebar line. It now takes up a large portion of the screen with a huge area of gray beneath it. I can’t find a way to move it. The Document Foundation Wiki said: "You can also dock and undock with Ctrl + double-click, when the cursor is in the gray area." When I did this, the Color Bar disappeared. When I tried to go to View in the Menu Bar to reopen the Color Bar, the dropdown menu was gray with no text. This was true of all menus. When I tried to close the program to restart it, the "Save Document?" dialog was also gray with no text. Thankfully, I knew Tab + Enter would choose so "Don’t Save", so I was able to close the Draw document. When I opened a new Draw document, the menus were still gray with no text. Surprisingly, a text document in Writer had visible text in the menus. I had to use Restart in Safe Mode and choose “Reset to factory settings>Reset settings and user interface modifications” to get the menus working properly again in a Draw document. That didn’t solve the Color Bar problem, however. The Color Bar still opens in the area to the right of the Hide/Show Sidebar divider as in the attached image.
I can see the use of docking the color bar above or below the sidebar or the Pages pane, in which case it makes sense for it to hide with them and have the same width. However it should: - utilise the space as efficiently as possible, wherever it is docked, i.e. "reflow" the grid depending on how much space it has; - be possible to make it remain visible when using the full height and the sidebar or Pages pane are collapsed, like other toolbars (in my opinion). I can't reproduce the issue with greyed out menus, which might be Windows-specific. Could we keep this report focused on the issues with how space is used and where the color bar docks itself, and open a new report about the grey menus, with a screenshot? Please also paste here the information copied from Help > About LibreOffice. Thank you. Repro in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and OOo 3.3, so it is inherited.
Created attachment 186884 [details] About LibreOffice information
(In reply to Stéphane Guillou (stragu) from comment #1) > I can see the use of docking the color bar above or below the sidebar or the > Pages pane, in which case it makes sense for it to hide with them and have > the same width. > > However it should: > - utilise the space as efficiently as possible, wherever it is docked, i.e. > "reflow" the grid depending on how much space it has; > - be possible to make it remain visible when using the full height and the > sidebar or Pages pane are collapsed, like other toolbars (in my opinion). > > I can't reproduce the issue with greyed out menus, which might be > Windows-specific. > Could we keep this report focused on the issues with how space is used and > where the color bar docks itself, and open a new report about the grey > menus, with a screenshot? > > Please also paste here the information copied from Help > About LibreOffice. > > Thank you. > > Repro in: > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > and OOo 3.3, so it is inherited. I've added a new attachment with the About LibreOffice information.
The active focus grabs for the Color Palette... dialog are at the edges--depending on os/DE they can be tricky to grab to drag-n-drop reposition. However, there are additional docking points for the widget. Keep dragging right and it can be positioned below or above the SB deck. When positioned to anchor above or below the SB deck, the widget (.uno:GetColorTable) will honor the SB collapse, and will follow behavior of 'minimumwidth' expert config. See attached animated gif of draw session with 'minimumwidth' set false, also works with it set true but the SB deck is blocked from narrower value--stops at minimum. But the Color Table picker will follow. Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 186894 [details] screen capture while repositioning and docking the color bar Color Palette dialog the 'minnimumwidth' expert config value is set 'false' allowing SB to shrink beyond minimum widget width control stop.
The widget frame is a bit tricky to grab, but on Windows builds it can be grabbed and undocked. The color table Color Palette dialog can also be docked to left side, inboard of the page sorter, or above or below it. The dialog will adjust width when being docked. Room to improve the "grab", and IIRC there are issues with some of the os/DE. Otherwise this is a => WFM
When I did Ctrl + Shift + F10, I finally found the Color Bar near the top of the screen. I was reduced in size so only the C and the X for closing the Color Bar were showing and both were gray and almost transparent. At least I will no longer feel the need to go into Safe Mode. When I drag the Color Bar to the right and a large gray outline appears to the left of the Hide/Show divider, I expected the Color Bar to be placed there when I released the mouse button. However, the Color Bar is placed to the right of the Hide/Show divider and the X for closing it disappears. Similar behavior happens when the Color Bar is dragged to the left of the Workspace.
Created attachment 186904 [details] Screenshot of colour bar in Inkscape 1.2.2 (In reply to V Stuart Foote from comment #6) > The widget frame is a bit tricky to grab, but on Windows builds it can be > grabbed and undocked. > > The color table Color Palette dialog can also be docked to left side, > inboard of the page sorter, or above or below it. The dialog will adjust > width when being docked. > > Room to improve the "grab", and IIRC there are issues with some of the os/DE. > > Otherwise this is a => WFM I agree that the widget behaves as expected when docked above or below the sidebar or Pages pane. However, especially for something called a "Color bar", space should be better utilised: - when full-width horizontal, the cells are very wide and there is a tiny scrollbar, when it could instead fit all the colours in two rows of squares without needing a scrollbar that is small to the point of inusability. - when full-height vertical, the number of columns should change depending on how wide the bar is (and reduce the width if there is plenty of vertical space to use, so there is minimal unused grey space). I understand that palettes have a fixed grid size, which makes it look nicer when hues are aligned, but consider alternatives like the attached screenshot of Inkscape 1.2.2, with in my opinion a significantly improved UI: - single row of squares - uses full width of window - dropdown to change palettes - two buttons to go up and down if there are overflow colours in the palette. On top of that, I agree with OP that it should be possible to have a vertical Color Bar that is independent of the visibility of the Sidebar or the Pages pane. I think this ticket needs to stay open even if focusing only on the docking location and the efficient use of screen real-estate, ignoring the drag-and-drop issues.
(In reply to Don Matschull from comment #0 and comment#7) > The Document Foundation Wiki said: "You can also dock and undock with Ctrl + > double-click, when the cursor is in the gray area." > > When I did this, the Color Bar disappeared. When I tried to go to View in > the Menu Bar to reopen the Color Bar, the dropdown menu was gray with no > text. This was true of all menus. > When I did Ctrl + Shift + F10, I finally found the Color Bar near the top > of the screen. I was reduced in size so only the C and the X for closing > the Color Bar were showing and both were gray and almost transparent. Question: Does the .gif file I'm attaching to this report reflect your description above? (recorded on Windows 11, issue reproducible with 7.4.6.2, 7.5.2.2 and e.g. 7.3.7.2)
Created attachment 186920 [details] only the C and the X for closing the Color Bar, menus gray
(In reply to nutka from comment #10) > Created attachment 186920 [details] > only the C and the X for closing the Color Bar, menus gray That's pretty much it except the X for closing the Color Bar was gray on mine rather than red so even harder to see.
Reproduced. Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded There is a definite bug in handling the <Ctrl>+<Shift>+<F10> undock/dock toggle short cut for the widget. The default size and location is to upper left of desktop at a minimum size showing no color swatches and just the os/DE frame controls. The undocked widget can be located and resized to show some part or all of the color chart while undocked. And that undocked resize persists in profile for subsequent use, along with the docked position as above. So it needs a better initial default placement and size when toggled undocked. With 7.5.2 build no issue with the empty menus shown.
Created attachment 186924 [details] Color Bar widget dragged to bottom w/ top 2 chart rows showing Looking at this with a clean user profile, the initial launch of the Color Bar places it docked to right of Draw canvas with the tall wasted space. That is maybe not the best spot to attach. However, a <Ctrl>+<Shift>+<F10> undock applied against default user profile places the widget frame outside the LO app frame--coordinates seem to take y-offset from top edge of the LO app frame, but the x-offset looks to be about 15px against the left edge of os/DE "desktop" frame. But as noted the defaults for the size of the widget are too small and show no labeling or any of the color swatches, just the app frames controls (i.e. the close button). The undocked floating default *needs* to be tweaked and is a true bug. Otherwise, as in the clip the docked color bar can be attached at bottom and height adjusted to show just 2 rows w/scroll bar to show the tints & shades--maybe that might be a better default docking configuration--kind of the OOo tradition.
If I remember well, the colorbar behavior was changed sometime ago in LibreOffice. At the beginning, it was just like it is still in OpenOffice (see attached screenshots), which is better IMHO.
Created attachment 187200 [details] Colorbar docked at bottom in LibreOffice Impress
Created attachment 187201 [details] Colorbar docked at bottom in OpenOffice Impress
(In reply to Roland Baudin from comment #16) > Created attachment 187201 [details] > Colorbar docked at bottom in OpenOffice Impress I can confirm that squares were used in OOo 3.3, which was a lot more usable in my opinion. Better have a separate bug about it, marked as a regression.
(In reply to Stéphane Guillou (stragu) from comment #17) > (In reply to Roland Baudin from comment #16) > > Created attachment 187201 [details] > > Colorbar docked at bottom in OpenOffice Impress > > I can confirm that squares were used in OOo 3.3, which was a lot more usable > in my opinion. Better have a separate bug about it, marked as a regression. See Color bar discussions (meta bug 115112) but the old Color bar tb was replaced with reuse of the palette widget. And then default docking position changed from the bottom dock to a side dock for bug 115087 -- that was not a completely successful change as a height appropriate docking under the left side pages/slides panel would have been more effective. Bigger issue is the inability to directly change the color palette during use bug 120230 which would allow drawing work flows with colors other than our RGB tints and shades of standard color theory. Part of that fix would be ability to toggle the palette from fixed grid (that stretches now) into linear runs filling the "bar" (docked horizontal or vertical) with color swatches closer to square, but otherwise leave the palette grids unchanged.
I'm a bit lost what is being discussed now. Regarding the docking I could imagine some header that makes it easier to grab the docked toolbar. Ideally with a context menu to (re)dock similar to the "ctrl+f5"-sidebar. By the way, on Linux/kf5 it's impossible to dock again, see bug 64438, and Windows users may run into trouble as reported in bug 92122.
(In reply to Heiko Tietze from comment #19) > I'm a bit lost what is being discussed now. >... The issue *here* is simply the undocked palette color picker dialog's assigned size and position on os/DE "desktop" frame, our side the LO "app" frame. 1. initial *size* of the palette color picker dialog, it takes a default minimum by os/DE rather than its full size (recall similar adjustments were needed for undocked SB deck). 2. initial *placement* of the undocked picker dialog is not correct, position should be calculated within bounds of the LO app frame on the desktop, not arbitrarily out on the desktop. 3. once sized and placed, record to .XCU user profile until resized/reposition. Rework of the palette color picker (support h/v linear sequence alternative to fixed grid holding palettes) is valid enhancement but unrelated to this implementation bug in the UI.
s/our side/outside/