Created attachment 132137 [details] Floating toolbar is not created When you drag and drop the menu to select the colors and make it make a floating toolbar, it is not created. It closes. It happens in all the programs of the suite.
tested under Win8.1 x64 not reproducible using LibO 5.2.5.1 reproducible using LibO 5.4.0.0.alpha0+ Build ID: 5bb5a9dacb84ec14f7148a5a5d9ba38b7e9f1039 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-02-17_23:30:45 Locale: it-IT (it_IT); Calc: grou status NEW regression, needs bibisecting added to Color Picker metabug @Leandro please tell your O/S
This seems to have begun at the below commit. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks bcdf4ea1ba4e6e9d1dbc89aec66fe57c89945634 is the first bad commit commit bcdf4ea1ba4e6e9d1dbc89aec66fe57c89945634 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Nov 7 22:23:35 2016 +0100 source 64a708cba9b954afe3331f63c58218eb53b3d0ce author Caolán McNamara <caolanm@redhat.com> 2016-11-05 20:28:27 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2016-11-07 21:04:50 (GMT) commit 64a708cba9b954afe3331f63c58218eb53b3d0ce (patch) tree ddc1bea3b63f32a1c6d377c1d1dd7aee0803fb70 parent f01c49c4a89ecad2376fd0023625186e5cac642e (diff) Revert "Reverts a commit series that cripple windows ci." with addition of... - svxlo-SvxColorListBox + svxcorelo-SvxColorListBox This reverts commit db380aab1063e8a5e40111c40ee9f7921aa82601.
As an aside the "undo" window is the same as this except it has always been like this and it has variously failed to work on various different platforms at different times cause of the complexity of making these sort of things floating.
(In reply to Caolán McNamara from comment #3) > As an aside the "undo" window is the same as this except it has always been > like this and it has variously failed to work on various different platforms > at different times cause of the complexity of making these sort of things > floating. Sorry... Is it a problem that the user can float the undo list? Because as a user I find it great to always have it in view to be able to control what is going to be undone. I do not think it's annoying but an option for users. Sorry for the English. I use Google.
floating undo menu when undocked under gtk2 will auto close since forever, the whole floating thing is inconsistent across platforms
Usually expanded widgets are not floating. I would make them sticky to the parent and collapse when the focus is lost. However, the feature is quite comfortable, though we have alternative workflows like per sidebar or extra toolbars. The borders widget becomes an own floating control and remains visible until explicitly closed. So we should go one of the two ways and either have the floating option for all dropdowns or never.
(In reply to Heiko Tietze from comment #6) > Usually expanded widgets are not floating. I would make them sticky to the > parent and collapse when the focus is lost. However, the feature is quite > comfortable, though we have alternative workflows like per sidebar or extra > toolbars. The borders widget becomes an own floating control and remains > visible until explicitly closed. So we should go one of the two ways and > either have the floating option for all dropdowns or never. [ES] La lista de colores siempre se convirtió en florante en versiones anteriores. A partir de que implementan una nueva versión dejó de funcionar. [EN] The color list always became floated in earlier versions. Since they implement a new version it stopped working.
*** Bug 112412 has been marked as a duplicate of this bug. ***
Making the tearoff mechanism itself work shouldn't be hard, as the only thing needed is to reparent the widget to a different FloatingWindow with the right WinBits, so that we can avoid setting problematic WinBits on the initial popup window (like WB_OWNERDRAWDECORATION which creates focus and placement issues under gtk3/wayland). All existing popups which allow tearoff were already converted to work that way via svt::PopupWindowController + DockingManager (e.g. Bug 109309). The problem here is that the color widget is .ui based, and sadly it results with some layout problems with the current DockingWindow + DockingManager code. So far all my attempts to make it have the right size and not flicker or change its size randomly were unsuccessful. But I keep trying, so I'm assigning that bug to me for the time being.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad769c30d2a709786a769f75fa5e04b33edf0809 Adjust DockingWindow layout calculation, tdf#106762 prep It will be available in 6.0.0. 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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f1e01fc89ca5d5f03d172f038e2310ba2ac5580 Support non-ToolBox popup case in DockingManager, tdf#106762 prep It will be available in 6.0.0. 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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bd418a6b8253a9d725981743a0375e2c8bb911e rptui::OToolboxController becomes unused, tdf#106762 related It will be available in 6.0.0. 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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e867b197540cfc8b75bb1108c8bcd7a0ff65d347 tdf#106762 Base SvxColorToolBoxControl on svt::PopupWindowController It will be available in 6.0.0. 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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf9360e6f5e38c9de3b38d9748a84d4d1c5067f9 tdf#106762 Keep the previous m_xColorWindow lifecycle It will be available in 6.0.0. 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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10e5729fb07d6b4c66182596bd86734d0ab386b9 tdf#106762 Avoid warning when opening and closing the color picker It will be available in 6.0.0. 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.
Hi Maxim, Thank you very for this fix. I tested it on my own master build and it works as expected. Did you see that LO seems to create two different color picker objects depending if you use the formatting toolbar or the sidebar. At least it is what it is suggested to me when I see that each color picker remember its own last used color. I don't know if that should be called a bug or a feature because some user may be interested to have 2 memorized colors when he changes paragraph background color or font color. Anyway setting as verified fixed. Best regards. JBF
*** Bug 114784 has been marked as a duplicate of this bug. ***
*** Bug 115991 has been marked as a duplicate of this bug. ***