Hello, Current white toolbar backgrounds and toolbar structure do not follow OS X design guidelines. White colour does not look and feel native. And it is not even consistent with the other LibreOffice UI element backgrounds like Sidebar and rulers. On the other hand in most Mac applications toolbars are unified with the window bar, although it would be hard to make this approach work with LibreOffice since LO toolbars are all customisable and dockable to the other sides of the main window. Possible approaches: 1. Use only native OS background drawing for all UI elements, including Sidebar. Keep the current customisable LO toolbar structure. On this approach Window Bar would still be separate. 2. Unify the Standard toolbar with the Window Bar as in most Mac applications, keep the other toolbars customisable, dockable to other sides of the window. 3. Keep customisable toolbar structure, but instead make toolbars unify with the window bar when docked to the top. I don't know if this would be technically possible or not. My opinion goes for the third, since I like docking the standard toolbar to the sides, and using vertical screen space. This sounds very much like a vapourware, but at least some discussion and brainstorming would be helpful for future references.
I thought the request to make toolbar background gray was already reported?
(In reply to comment #1) > I thought the request to make toolbar background gray was already reported? I think you are referring to Bug 56046, which consists only changing the toolbar background colour, and overall theme colours in general. But this issue is about using native code to draw toolbar background, and changing the UI style.
Emir: Unfortunately the report does not help somebody who does not have an OSX computer :-( Can you please put here a screenshot of the current situation on OSX + example of your preferred solution (eg. screenshot of an existing application)? If I am not mistaken, OSX uses a gradient of some sort - do you know what are the start and end colors in the gradient? Thank you!
So I guess something like http://www.technobuffalo.com/wp-content/uploads/2013/10/Apple-iPad-5-Event-Mac-Updates-OS-X-Demo-002-1280x720.jpg is wanted here, vs. the current http://easyosx.files.wordpress.com/2011/05/libreoffice_calc.jpg right?
The gradient varies a bit between Snow Leopard and Lion. Firefox uses these: http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsNativeThemeColors.h The problem with simply applying a gradient is that Mac OS uses a single gradient behind the top toolbar and the title bar. If we use the native title bar and draw the native gradient behind the toolbar as well, the result is relatively ugly. It'd be nicer if we could draw the title bar ourselves or if we drew the top toolbars natively, but I assume that would be too much work for too little gain. So, if we have to draw a toolbar background, I'd suggest to go a different route and try to fit the toolbar to the document area. The toolbar gradient from bottom to top could be #f3f3f3, #f6f6f6 at 94%, and #e6e6e6 at the top (shadow cast by title bar). The toolbars not docked at the top could have a simple #f3f3f3 fill. The toolbar separator would consist of 2 1px lines: #fafafa as the inner highlight, #d5d5d5 at the very edge.
Mirek: Thanks, this was most helpful! I believe there must be a way to be able to draw a single gradient - Firefox does that too :-) Unfortunately I have no OSX machine to be able to experiment - anybody who would like hack on this is much appreciated, I'd give him/her more code pointers. From what the Firefox is doing, the most interesting pieces seem to be DrawNativeTitlebarToolbarWithSquareCorners: http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsNativeThemeCocoa.mm#1801 and the code around that. I guess we have to set some special flags to the window itself too, like using setStyleMask: or something from: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html Definitely experimenting here is necessary; so I am hesitant to mark this as EasyHack - but if somebody with Mac is around, I can help from the LibreOffice side :-) - please poke me on irc.freenode.net, channel #libreoffice-dev, I am 'kendy' there.
@Kendy, sorry for the late reply, and I see all questions have been answered nearly. A recent idea which just occured to me: In Cocoa applications, window bar is a toolbar itself. But this is just one toolbar, it would not be possible to put LO toolbars in this area, and it would not make sense from a designer's point of view. What we can do is, create this toolbar area, and make it totally customisable, like in other Mac applications. So the user would add whatever button from whatever toolbar he wants, and organise his workspace. http://i.imgur.com/jpre5ta.png Below the window bar and to the sides user can dock whatever toolbar they want. Personally I like docking the toolbars to the sides of the window, it looks neat. http://i.imgur.com/yjJvPwm.png - http://i.imgur.com/CjS2wgw.png And the gradient issue: - As far as I know, OS X draws the gradient automatically according to the operating system, since Snow Leopard, Lion and Mountain Lion have different gradients, so it would not be a problem. Also sidebar background should be unified with the dockable toolbars as well. Personally I'd love to see this as an EasyHack also.
It is a great approach to change the UI elements backgrounds in the toolbar. However; I would like to just recommend, that an existing feature like customise toolbars in LO, should remain and stay as it is fantastic for new users to LO and new users in general for viewing and using icons in LO, these options can be set easily as, customise toolbars, show icons and text, and show only icons, and show icons only as text, should remain as in the toolbar options in LO. I hope LO does not disable this functionality when designing toolbar layouts and backgrounds as it is has occurred in other applications on mac like the web browser on the mac OS and other web browsers from google and opera.
Created attachment 88981 [details] Pencil UI Another very successful cross-platform UI, from Pencil UI design software. Although it is not 100% Mac-ish, it is very intuitive and successful, therefore I believe it represents a very nice example for LibreOffice to follow. I loved the on-mouse-hover sliding toolbars…
@Nicholas, Do you have any comments about what could be done in terms of design and adapting current LO UI to Mac standards?
The ideal option for obtaining a Mac-native interface is to fork the UI code and use NSToolbar. Whether that can feasibly be subclassed and made 'draggable' to the sides or not, I don't know (whereupon it would revert to the current appearance).
Of course we know that the ideal would be to use native NS* stuff. What we don't know is who would provide the resources to do such work.
Initially wouldn't it be a good start to fork the current Aqua code as Nicholas said, so that whoever wants to play can play with it? I am not sure if this would make sense from a technical point of view, but I think it would serve as a nice playground. And the code would be there for anyone who wants to hack on it.
Created attachment 93369 [details] Proof of concept CoreUI More info at https://bugzilla.mozilla.org/show_bug.cgi?id=668195
Comment on attachment 93369 [details] Proof of concept CoreUI By mistake, Joren uploaded a wrong patch when in a hurry :-( Joren - can you please upload here the correct one?
Created attachment 93396 [details] Proof of Concept patch Lets retry :-)
As CoreUI is a private (unstable, undocumented) framework it can't be used by an app in the Mac App Store, so the new code should be ifdeffed based on HAVE_FEATURE_MACOSX_SANDBOX (we asume that building LO as sandboxed is done iff building LO for distribution through the app store.
According to the comments, https://bugzilla.mozilla.org/show_bug.cgi?id=668195#c10 achieves that without using CoreUI; so I guess we'll want to change it at some stage to use this 2nd approach. At the moment, there are 2 remaining pieces * the header has its own gradient * there are white frames drawn around the toolbars. The 2nd problem could be solved by something like: diff --git a/vcl/osx/salframe.cxx b/vcl/osx/salframe.cxx index 6b236d6..e592649 100644 --- a/vcl/osx/salframe.cxx +++ b/vcl/osx/salframe.cxx @@ -1301,6 +1301,9 @@ void AquaSalFrame::UpdateSettings( AllSettings& rSettings ) rSettings.SetStyleSettings( aStyleSettings ); + // don't draw frame around each and every toolbar + ImplGetSVData()->maNWFData.mbDockingAreaAvoidTBFrames = true; + [mpNSView unlockFocus]; } Joren - can you please try it? If it looks good enough, I'll push it, and build on top of that, so that we don't lose the work done so far :-)
Joren De Cuyper committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c7e6080519014f1fb345ed25e2f12c9a043b3ae fdo#69358 Introduction of native Mac OSX Toolbar, based on CoreUI 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.
After the patch, the toolbar uses the same colour gradient as the window bar, but it is still separate; the gradient of the window bar doesn't continue straight into the toolbar, like it does for "native" applications.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a315454f349469923490e4116806ee19263849b8 fdo#69358: Avoid discontinuity in the gradient of window bar and toolbar 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.
Joren De Cuyper committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=062b3a5def5ec25813cabae5d292b45a589d72e4 fdo#69358 only draw native style when toolbar is docked on top 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 Kendy. Great work, so I don't want to be a buzz kill... Being a Mac user for some years, I'm not sure this change will be welcomed by all... Definitely worth getting some UX input (with a strong Mac user focus). Most 'native' gradient/toolbars are for Apps with half-dozen icons on a static, simple toolbar. The current LO 'look' is probably what's expected by many users of a productivity app IMHO...
Created attachment 94111 [details] screenshot1 LO gradient
Created attachment 94112 [details] screenshot 2 other osx apps gradient
While I applaud this move, I think we all agree it's not finished yet. This would be an important and welcome change for all LO OSX users. Currently LO looks very non-native. I've created two screenshots. 1 LO, 2 other OSX apps. Not sure what exactly differs but I assume the best solution indeed would be to use native elements where possible. Otherwise chances are LO will stick out like a black sheep :P
The Pencil UI is awesome. If LO was close to that, that would be crazy good. Currently in LO the title bar and the top menu are separated. That is not the case for other OSX apps.
@Foss: related to separate titlebar and toolbar: we are aware of that. This are just the first steps. Documentation about toolbar design etc: https://developer.apple.com/library/mac/documentation/userexperience/conceptual/AppleHIGuidelines/IconsImages/IconsImages.html#//apple_ref/doc/uid/20000967-TPXREF102 and https://developer.apple.com/library/mac/documentation/userexperience/conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-SW9 :)
Well, I want to thank everyone who made the first steps about this, very much appreciated indeed. Just some observations; -It seems that gradient only matches the window bar colour when the window is inactive, in other cases clearly there is a difference in the colour/gradient. -Gradient loses its colour sometimes, regains it back when mouse-overed. But only in the dimensions of the button. I think everyone observed this. Hope these issues would be resolved till the time for the first RC. Thanks again everyone who's involved in this.
So it seems the patch “Avoid discontinuity in the gradient of window bar and toolbar” had no effect whatsoever…
I wonder how does LO look under OS X Yosemite.
(In reply to comment #31) > I wonder how does LO look under OS X Yosemite. Don't know, but I sincerely hope that the Base UI changes get the same graded background as the other apps because my last master build on OSX looked pretty ugly...
I think LibreOffice will keep the current gray, since it uses modified code to get the native look; I saw a Firefox screenshot which looks unchanged, and LibreOffice uses the same code in portions.
(In reply to comment #29) > -It seems that gradient only matches the window bar colour when the window > is inactive, in other cases clearly there is a difference in the > colour/gradient. LO RC 3 on OSX 10.9.4: even then (when inactive) it doesn't match. :( > -Gradient loses its colour sometimes, regains it back when mouse-overed. But > only in the dimensions of the button. I think everyone observed this. LO is shorty before shipping 4.3.0 RC 3, shortly before shipping date of Final Release 4.3.0 according to the release plan: https://wiki.documentfoundation.org/ReleasePlan/4.3#4.3.0_release. These issues, notably this particular issue (Gradient loses its colour sometimes, regains it back when mouse-overed. But only in the dimensions of the button) *really* should be ironed out *before* this coming public release. Otherwise it leaves a *very* awkward and unprofessional because half-baken impression to the public. > Hope these issues would be resolved till the time for the first RC. Thanks > again everyone who's involved in this. +1
I would revert this for 4.3. Also I have a hunch that this causes MAB bug 80939 (which affects Retina displays) due to the use of a private API.
Whenever this issue has been solved, there is another native toolbar issue in bug 80474 that should be looked into.
Since release for 4.3 is near, I also think this should be reverted either. Better late than never.
(In reply to comment #30) > So it seems the patch “Avoid discontinuity in the gradient of window bar and > toolbar” had no effect whatsoever… With my limited technical knowledge, I don't think it is possible to reach this without a complete overhaul of the OS X UI code. Also the current patch only mimics the native appearance, not providing one.
Created attachment 103751 [details] Latest situation on OS X
The toolbars now look much worse than in 4.2.5! Just like Emir's screenshot shows. This is a big regression on the UI on OS X. Please fix it or revert it before 4.3.1.
Native background rendering on OSX not working on Spreadsheet.
Created attachment 105693 [details] Toolbar rendering in OSX is weird. Toolbar rendering on OSX is strange under the following conditions. Sequence: Open LibreOffice. Click Writer Document on Left sidebar. Click File, New Spreadsheet See attachment for a picture. System: 15 inch MacBook Pro Mid 2012 Intel i7, 2.6ghz Intel HD Graphics 4000 along with Nvidia Geforce GT 650m 16gb Ram OSX version 10.9.4 Occurs on LibreOffice 4.3 and 4.3.1 using Native background rendering on OSX. (No Theme)
(In reply to comment #42) @az_pchelp--you have set yourself as Developer assignee, I don't think you intend to do that ;) Also, you've set a couple of attachments as obsolete--they are not, please don't make such changes unless you really understand our Bugzilla process.
*** Bug 83700 has been marked as a duplicate of this bug. ***
The implementation from comment 21 sorts out the original issue, and bug 83700 is actually a follow-up to make it look even nicer. If you are still seeing the misbehaviour from comment 42, please open a new bug, this is not expected, and was not showing with the patch from comment 21.