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
No difference between the border of the apps
Color differences to distinguish which app is running
User Profile Reset: No
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.
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.