Summary: | Implement different border colors depending on the LibreOffice app launched on Windows | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | William Gathoye <william.gathoye> |
Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | arnaud.versini, heiko.tietze, vsfoote |
Priority: | medium | ||
Version: | 6.2.4.2 release | ||
Hardware: | All | ||
OS: | Windows (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=133736 https://bugs.documentfoundation.org/show_bug.cgi?id=154472 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | 113388 | ||
Bug Blocks: | 103303, 112525 | ||
Attachments: | Windows borders of MS Office 365 apps running on Windows |
Description
William Gathoye
2019-05-22 12:29:57 UTC
Created attachment 151591 [details]
Windows borders of MS Office 365 apps running on Windows
This would require native code for client side decorations. And as with bug 113388 still no compelling reason to do so. It follows that this is => WF That aside, moving UI controls (and color by the module in use would be just a UI control) into the application frame has some appeal, but cross platform implementation *and maintenance* makes it unappealing. Color only controls are not acceptable UI design, with a11y implications--and this becomes just visual theming/decoration. Pursuing it would be chasing another Microsoft gimmick. IMHO => WF Actually form my understanding of the issue, we don't really need client side decoration. The Win32 function to open a window is already here in the VCL. It just needs an additional argument (in a polymorphic/additional optional argument way) to get the module we are in. Then, we "just" change the border color using a simple initialized C structure. SetSysColors should do the trick IMHO, but I need to check how to synchronize the value between LibO apps. https://stackoverflow.com/a/34279011/3514658 Not an urgent need but if William wants to implement it there is no objection from UX I'd say. Besides using the default LibreOffice colors of course. So removing UX. Caolan, could you take a look here and provide William a codepointer for the upcoming hackfest please. Windows in LO are represented by the SalFrame class. There is a 2nd type of "window" for native client areas (used for stuff like video overlay in Impress). That code for the Windows OS is is in vcl/win/window/salframe.cxx and vcl/win/window/salobj.cxx. But reading the stackoverflow link, it doesn't look that easy, because now you would have to paint the whole decorations yourself, which probably would require the implementation of bug 113388. OTOH I don't understand why bug 113388 is closed as WONTFIX. If someone manages to implement this, I don't see a reason to not merge that into VCL. Or is there some compelling design reasons not to support this? But getting this to work consistently on all platforms might be quite hard. Looking into Firefox code might be a good starting point there. |