Bug 125443 - Implement different border colors depending on the LibreOffice app launched on Windows
Summary: Implement different border colors depending on the LibreOffice app launched o...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 113388
Blocks: Desktop-Integration Titlebar
  Show dependency treegraph
 
Reported: 2019-05-22 12:29 UTC by William Gathoye
Modified: 2023-03-30 17:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Windows borders of MS Office 365 apps running on Windows (111.75 KB, image/png)
2019-05-22 12:30 UTC, William Gathoye
Details

Note You need to log in before you can comment on or make changes to this bug.
Description William Gathoye 2019-05-22 12:29:57 UTC
Description:
Right now, on MS Office, in order to distinguish more easily which app is running, the border of the app is different depending whether we are running Word, Excel or PowerPoint. The border are respectively blue, green and orange.

I think this should be a feature we would offer as well.

Pay attention, this has nothing to do with the Firefox persona feature we have been supporting. The Persona feature is only changing the background of the area between the borders and the document area, so the area behind the toolbar when using the traditional LibreOffice user interface.

Steps to Reproduce:
1. Open a LibreOffice specific app like Writer on Windows
2. Have a look at the windows border

Actual Results:
No difference between the border of the apps

Expected Results:
Color differences to distinguish which app is running


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 William Gathoye 2019-05-22 12:30:41 UTC
Created attachment 151591 [details]
Windows borders of MS Office 365 apps running on Windows
Comment 2 V Stuart Foote 2019-05-22 13:24:03 UTC
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
Comment 3 William Gathoye 2019-05-22 13:35:02 UTC
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
Comment 4 Heiko Tietze 2019-05-22 14:19:42 UTC
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.
Comment 5 Heiko Tietze 2019-06-18 14:54:21 UTC
Caolan, could you take a look here and provide William a codepointer for the upcoming hackfest please.
Comment 6 Jan-Marek Glogowski 2019-07-05 16:02:40 UTC
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.