Created attachment 70461 [details] Toolbar vs. Document Hello, The first 4.0 alpha build has an annoying visual glitch: Toolbars do not have borders so they are indistinguishable from the document itself. Screenshot attached.
Created attachment 70658 [details] Screenshot for bug 57433 - with default settings = rulers on.png Thank you for your bug report! The problem is REPRODUCIBLE with the newest daily builds for Mac OS X, e.g. LOdev 4.0.0.0.alpha1+ (Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3; pull time: 2012-11-26 00:28:52). Tested on Mac OS X 10.6.8 (Intel). Of course, the problem visible on Emir Sarı’s screenshot (there is really no visible division between the toolbars and the document) appears only if the horizontal ruler is hidden (select “View > Ruler” from the menu bar). As long as the horizontal ruler is visible, it is easy to recognize the border between toolbars and document contents. See the attached screenshot, which shows the default settings (the rulers are visible by default). But because it is likely that some users *will* hide the rulers, there is still a problem, as Emir Sarı’s screenshot shows.
Created attachment 70659 [details] Screenshot for bug 57433 - with different Document background color The other variable from which the visibility of the problem depends is the “Document background” color. By default, it is *identical* to the toolbar background color, at least in LOdev on Mac OS X. (Maybe this is different on Linux/Windows, and this is the reason why there is this bug on Mac OS?) If you change the “Document background” color, the problem of visual discernibility between toolbars and document disappears -- see attached screenshot. But with the default colors, there is really a problem, as soon as the rulers are hidden.
Created attachment 70660 [details] Rulers off in 3.6.4.1 @Roman, Here you can see that even rulers off in 3.6, document and the toolbar is easily distinguishable from each other.
(In reply to comment #3) > Here you can see that even rulers off in 3.6, document and the toolbar is > easily distinguishable from each other. Yes -- and exactly that is the difference: * in 3.6, toolbar and document are *always* easily distinguishable from each other; * in 4.0, the distinguishability depends on the settings for rulers and document background color, and this is not good. When was this problem introduced? There is still a little border line between toolbar and document in: master~2012-08-21_00.09.17_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg The problem appears in: master~2012-08-31_04.36.39_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg I am sorry that I don’t have any master build between 2012-08-21 and 2012-08-31, but it may be enought to know that the problem was introduced in that timeframe Could it, e.g., be a side-effect etc. of one of Jan Holesovsky’s (Kendy’s) UI changes committed in 2012-08-23?
@ Astron, Jan Holesovsky, Thorsten Behrens: Hi Astron and Kendy (our UI experts), and Thorsten (our Mac expert), there is a little UI problem in the 4.0 builds, at least on Mac OS X (I can’t test daily builds on Linux and Windows): when the rulers are hidden, there is no visual differentiation between the toolbar and the main document area, because by default both have the same background color. (If you don’t understand what I mean, it is my fault: the problem is hard to explain with words, but easy to grasp; just see attachment 70461 [details] and you will understand what I mean). This problem was introduced between 2012-08-21 and 2012-08-31. Of course, the removal of the little border which separated the toolbar from the document contents in 3.6 might be intentional. My question to you, the UI experts: *Was* it intentional? * If it was NOT intentional, this is a bug and should be fixed. * If it WAS intentional, then the results are at least on Mac OS X a bit unlucky, because of the identical default background colors of toolbar and document; so this would need some improvements, too ... Please take a look at this issue and decide what to do about it. Thank you very much in advance!
Created attachment 70668 [details] Better screenshot for bug 57433 I hope this screenshot shows the problem even more easily, and makes clear *why* the new behaviour is bad and needs to be improved.
I wonder who at first place decided to make the OOo toolbars white... If I just knew... My eyes. :(
Still the same in 4.0.0.0 beta1. *sigh* Maybe I expect too much without contributing that much, but sometimes I am quite hopeless that LO on Mac won't get any better than its current state.
Hi Kendy, hi Thorsten, can you *please* take a look into this issue? It is just a cosmetic bug, of course, but the GUI of LibreOffice for Mac OS X looks worse (instead of better) with each release, and this little bug is the next important step towards an ugly and very unprofessional GUI. So, *please* take a look into it ...
I agree that this is a bit annoying, what's more is, I see a similar problem with the Adwaita theme (of Gnome 3.6) on Linux now. (Using a master build/4.1pre from this Friday)
Relevant: https://bugs.freedesktop.org/show_bug.cgi?id=56046#c6
And also please see that, even in 3.6.x, when I dock the toolbars to the side, docked toolbar has no border (4th screenshot).
Any info about when can we get our border back? :)
I think the toolbars either should be gray (to follow Mac OS X’s theme) or should use the same background gradient used under Windows. Both options would be a lot better than the current status quo.
I think I saw the same problem after installing LO 4.x into a computer of a friend (using XP). If there are no objections or counter information, I am changing operating system to: "ALL". Unless this is a feature, of course...
Something went wrong here, this one has nothing to do with Bug 63585
(In reply to comment #15) > I think I saw the same problem after installing LO 4.x into a computer of a > friend (using XP). > > If there are no objections or counter information, I am changing operating > system to: "ALL". > > Unless this is a feature, of course... I do see some tiny borders on Linux (Ubuntu) in 4.0.5. etc. Wasn't kendy the one who helped with changes in this area?
This is obviously being treated as a feature, and this is a terrible approach IMHHHHO. From 3.6 release notes: "General cleanup of the UI: 3D borders in rulers and status bars were removed, toolbars are borderless and have a subtle background gradient for improved look (Windows Vista/7/later only)" I cannot believe how such kind of a UI design rule can be ignored, it is unbelievable, really; how it is possible to present this as a feature, I really cannot understand. This is clearly a regression, very uneasy to eyes, causing eyestrain, indistinguishable UI from the document area, and looks awful, and someone is yet to comment on this. Unbelievable, really unbelievable. And then you expect people to use LibreOffice, yeah, sure. Sorry for the rant, but something has to be done about this IMHO.
Emir - I read the bug several times; it seems your concern is this: https://bugs.freedesktop.org/attachment.cgi?id=70461 That you can't distinguish the document from the toolbars. So some questions: is your theme tweaked in any way on the Mac ? or is that the default system colour ? ultimately if you set your own toolbars to the same colour as the document background (something that can also be set) then there is an issue. What I suggest you do is to dig out the patch that caused this, chew through it to work out what piece to revert, and suggest some minimal reversion to fix it. Failing that - adding a border around the main document area might do the trick too; this is something that anyone interested in this issue can do - the technical skill required is rather minimal I think.
@Michael, Here I'm attaching my LO Writer setup: http://i.imgur.com/VeZvs7J.png And below AOO 4.0.1: http://i.imgur.com/ef09mUY.png And NeoOffice: http://i.imgur.com/kpvXBhp.png As can be seen from the screenshots, LibreOffice has an UI which looks cleaner than both AOO and NO, but in any way it cannot give the eye comfort and depth perception which AOO and NO gives, thanks to their borders around the document and rulers. Clearly UI of AOO and NO looks way older than LibreOffice, but they are definitely more easy to glance and look at. In fact borderless toolbars look nice, indeed they do, but when UI is not distinguishable from the working area itself, it is a fatal UI error. This way LO looks like an unfinished piece of software - at least on Mac. I installed LO on a friend's PC lately, this issue bothered me there on Windows as well. This issue is not present on 3.6 (although it is mentioned in 3.6 Release Notes), and since this is a regression, I think it should be rather easy to fix (revert the patch?). Anyway, thanks for the reply, I hate getting attention by ranting, but sometimes it works. :)
(In reply to comment #20) Thanks for the examples > As can be seen from the screenshots, LibreOffice has an UI which looks > cleaner than both AOO and NO, but in any way it cannot give the eye comfort > and depth perception which AOO and NO gives,... IMO that is rather subjective and therefore can hardly justify the words you prefered to use in comment #18 ;) With at least the same right I could argue that the clearner interface is much less distracting atention from your work. OTOH, improvements may be possible. I think comment #19 gave some pointers for that ;) Cheers, Cor
> I hate getting attention by ranting, but sometimes it works. :) you got no more attention - I just replied stating the obvious :-) if it is a patch since 3.6 - then bibisect it out - that's at least a concrete action anyone can take to help isolate the issue. I can't imagine us returning to the old borders-everywhere approach, but of course we might try to do better in this case - particularly if there is a patch.
@Cor, What I actually mean is the simple perspective - when we put a ruler onto a piece of A4 paper, ruler is distinguishable from the paper itself - because it is on top of it, not on the same level with the paper. While working with LO, it is distracting, because it looks like it's all on the same level, toolbars, rulers - there is no depth sense. About UI cleanliness LO is already better than its counterparts, just needs polishing about this. Anyway, I'll try to bibisect the patch in my free time, and post update here. :)
(In reply to comment #23) > What I actually mean is the simple perspective - when we put a ruler onto a > piece of A4 paper, ruler is distinguishable from the paper itself - because > it is on top of it, not on the same level with the paper. I see what you mean. For me the little difference in color is enough, but I can immagine that that's not for all the same. > Anyway, I'll try to bibisect the patch in my free time, and post update > here. :) Nice :)
I think these patches might be related: http://cgit.freedesktop.org/libreoffice/core/commit/?id=264cf8bffa598326b255e352d4e4a7a791cf8409 http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd7382353d4c248a6d6f9d21401480ccc37e2b9d http://cgit.freedesktop.org/libreoffice/core/commit/?id=18ad2ef60ec192089dd5ac9a01e0ccefc8207c7d http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b10ef9fc39dc0251b03d6d9285bb86aab29abee For the ideal look, I've slightly modified the image in 3.6 Release Notes, more or less the ideal look should be like this, I've just added a border to the white area of the ruler as well. This way with the toolbar (viewshell) and the ruler looks distinguished from the document area. I didn't draw for the vertical ruler for the mock-up, but it should be the same as well. Here's the image: http://imgur.com/NO1YtOx
Created attachment 87519 [details] Apple Pages Main Window, illustrating requested border Also I think it would be better to make the ruler borders a bit darker, for providing better visibility like in Apple Pages.
Created attachment 89975 [details] 4.2.0 beta1 Screenshot
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Created attachment 92582 [details] Proposed_black_top_toolbar Might I suggest this, if we're going to be introducing a borderless top toolbar? Default black background and white/light flat icons. Refreshed UI and good distinction between document, application backgrond and top toolbar. Issues I can see from my proposal, though: * Good shade/brightness of black must be found (matched with a good shade of white for the icons) so it won't be tiring on the eyes. * Icons on sidebar should be grey flat, icons on toolbar white/light flat.
One of the finest examples of how to fix(!) one thing which ain't broke. Aside from the fact that white toolbar background is already a no-no from the OOo era, the situation could be easily improved with small distinguishing elements like borders and stuff. Anyway, I am tired of this stuff already, it is just a regression which could easily be fixed by a simple revert of patch, but if contributing people do not care about the regressions caused by their patches, or do not even take the 2 minutes to test them (which is the common case in most LO regressions as far as I can see) why would other people care? For example there is this Bug 73051, even number 10 is not fitting inside the box, let alone most font names, what is the logic behind breaking this? Another thing, styles dropdown even do not house any translations other than English, because someone made the styles dropdown thinner, or did not take the time to make it resizable, which would be the logical course of action if thought with good UX in mind. So as far as I can tell, LibreOffice became a playground on which some people play, but do not either think about the consequences of their patches, do not test them, or mostly forget that this software is used by millions of people. I really do not understand, there is no review mechanism especially for these type of patches. People just submit stuff, result is more and more UI regressions with each release, people saying "This thing looks shitty", and cringing QA people. Very nice. Really, I beg, please, if it ain't broke do not fix it. Please. Just my 2 cents.
And the point of that rant was . . . ? Dude!
Armandos: mockups without actual patches to implement them are extremely pointless in bugzilla. Sorry. (And I won't even bother discussing the idea in the mockup.)
Hi Emir, > One of the finest examples of how to fix(!) one thing which ain't broke. Well - opinions differ on how important the UX is and changing / improving it - which necessarily involves harming some use-case or other: which will eventually be fixed (and more so if people grapple with the code and/or submit patches). > Aside from the fact that white toolbar background is already a no-no from the > Oo era, the situation could be easily improved with small distinguishing Great - it is that very easy of easily improving it that makes this such a great candidate for a new programmer (such as yourself ?) - if you're interested in hacking on this [ and no simply reverting a change is not usually a positive contribution ], then I'd be happy to provide some code pointers & mentoring - get a build & see how it goes. > For example there is this Bug 73051, even number 10 is not fitting inside > the box, let alone most font names, what is the logic behind breaking this? Most likely it's just a bug - there is no logic to bugs; many of them are created by poorly coupled code whereby you change one thing and it has an unexpected impact elsewhere: the 'obvious' solution - "change nothing" doesn't lead to a terribly dynamic project :-) As with all bugs it needs to be filed, prioritised and ideally have fixes contributed. This one we can look at post FOSDEM in the UX hackfest perhaps. > Another thing, styles dropdown even do not house any translations other than > English, because someone made the styles dropdown thinner, or did not take > the time to make it resizable Kendy may be interested in that for the UX hackfest too. > which would be the logical course of action if thought with good UX in mind. AFAIK the style dropdown including previous of styles is a real UX improvement for people - done with UX in mind. > Really, I beg, please, if it ain't broke do not fix it. Sure - however opinions differ on whether LibreOffice is already the pinacle of design and usability :-) if you want things to improve, some transient regressions come with that. Thanks for reporting them ! that's good; however, please don't feel you're entitled to having your issues fixed on your timeline -unless- you provide code changes to go with them: if you do provide code changes, then I for one feel bad if they are not merged promptly :-) All the best.
This bug should be fixed by drawing borders as described at https://bugs.freedesktop.org/show_bug.cgi?id=59329#c5 .
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
@Emir San are you still affected by this bug with LibO 4.2.3.3? is that a MacOS specific bug? I do not reproduce it under Win7x64 where toolbar is grey and easily distinguishable from white document background even when rulers are toggled off.
@tommy27, Yes this is still reproducible, although the situation slightly improved with sort-of-native rendering of the toolbar and the darkened application background, a nice professional look of the application is still missing due to this bug. On Windows bug is still partially reproducible when toolbars are docked to the side of the window.
Ok I move it to the mab4.2 list since 4.1.x is EOL by the way I'd like to see a new screenshot depicting the actual situation.
Created attachment 98316 [details] screenshot of where we are at as of 2014-05-01
(In reply to comment #39) > Created attachment 98316 [details] > screenshot of where we are at as of 2014-05-01 That looks a lot better than attachment 70461 [details] or attachment 89975 [details]. Foss - could you take a screenshot with the rulers off? Thanks
(In reply to comment #40) > Foss - could you take a screenshot with the rulers off? FWIW, rulers on or off won’t matter anymore — both rulers and document background have the same color now (bug 51534).
Created attachment 104720 [details] LO 4.3.1RC1 rulers off
Screenshot attached. There are other remaining issues with the grey background at the top, but those are here: https://bugs.freedesktop.org/show_bug.cgi?id=80474
I'm setting this to WORKSFORME. Emir, if you have more input and or disagree please re-open and add your thoughts, but maybe we should continue with a new bug then to keep things lean and clean.
I am reopening this, because I still cannot see an actual border between the document background and the toolbar area. Colour differences do not count as an actual border. Worksforme still counts, but it is still not the way it should be, we should seek perfection, not workarounds.
Comment on attachment 92582 [details] Proposed_black_top_toolbar while I appreciate dark work environments, a good dark solution is totally out of scope currently and would require a major rewrite and effort to be done properly. so setting this to obsolete.
Comment on attachment 70461 [details] Toolbar vs. Document I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Comment on attachment 70658 [details] Screenshot for bug 57433 - with default settings = rulers on.png I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Comment on attachment 70660 [details] Rulers off in 3.6.4.1 I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Comment on attachment 70668 [details] Better screenshot for bug 57433 I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Comment on attachment 70659 [details] Screenshot for bug 57433 - with different Document background color I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Comment on attachment 89975 [details] 4.2.0 beta1 Screenshot I've just posted an up-to-date screenshot - let's go from there and try to avoid discussion on obsolete status
Sorry for the spam. Didn't know the cleanup comment for the attachments section would go into the main view of the bug. :( Back to NEW. Let's implement a proper border as is standard on OSX.
(This is an automated message.) Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Created attachment 106022 [details] Apple Pages Main Window illustrating what is requested
Briefly: - The layout in Pages (attachment 106022 [details]) and in current LO (attachment 104720 [details]) both look acceptable to me - Based on the usability of the current layout, I haven't been convinced this qualifies as a *Most Annoying* bug - The Design Team should give us some guidance here. I'll ping them (again?)
(In reply to comment #56) > - The Design Team should give us some guidance here. I'll ping them (again?) I've never been convinced that this is an issue at all. See comment 20 and comment 24. IMO it's no problem to see the ruler due to the measurement units, and is the appreciation subjective. But, that's still IMO.
This is not a MAB. Be serious, people. It is just a minor visual annoyance some are naysaying over.
Created attachment 106066 [details] clip from LODev440 -- Writer no rulers, clear delineation So, hasn't this ONLY been an OSX issue? It looks acceptable on current builds of Master on Windows. clip attached...
Fixing platform to OS X only, and removing MAB. I agree that this is not a MAB, but still a major visual glitch which needs to be fixed ASAP. And it amazes me that we are still discussing if this an issue or not. Please do not spam this thread, unless you have something to contribute to (code, anyone?), or if you lack basic understanding of perspective, vision, lighting, and concept of creating software interfaces.
As Mirek suggested in comment 34, border work being done for bug 59329 touched most of this. Ahmad H., final status there?
Also this is not a regression. Removing that keyword and adding importance: Enhancement. I say this is a UI bug. All OS X apps that have a top menu have that border. LO Does not so it's either ignorant to OS X specific standard design or it is a valid bug. I do not think it's fine as is. I think it is a minor UI bug which should be fixed, so LO finally become more visually appealing on OS X little by little. Adolfo saying " minor visual annoyance" but then again why not fix it? Is this such a time consuming fix? I wouldn't believe so. Please do not say "provide a patch" because although looking at the time I spend on LO, it would probably better be spent coding for LO, but I still do not have those capabilities :S Who is Ahmad H and why is he to decide on a final status here? Mirek suggested this would be fixed by fixing the bug referred to in comment 34. It obviously is NOT fixed. Mirek: can you please provide design departement's perspective on this? Since otherwise devs say "we think this is fine as is".
(In reply to comment #62) > Who is Ahmad H and why is he to decide on a final status here? Not "...here", assignee for bug 59329, read it.
Again, I believe that is another bug and not related to this here. Just read the title and see it's not fixed.
(In reply to comment #62) > I say this is a UI bug. All OS X apps that have a top menu have that border. > LO Does not so it's either ignorant to OS X specific standard design or it > is a valid bug. It's not OS X-specific. It's the case with Gnome's Adwaita theme as well. > I do not think it's fine as is. I think it is a minor UI bug which should be > fixed, so LO finally become more visually appealing on OS X little by little. Agreed. If we want a great UX, we need to be perfectionists. > Adolfo saying " minor visual annoyance" but then again why not fix it? Is > this such a time consuming fix? I wouldn't believe so. Please do not say > "provide a patch" because although looking at the time I spend on LO, it > would probably better be spent coding for LO, but I still do not have those > capabilities :S > > Who is Ahmad H and why is he to decide on a final status here? He's not to decide on a final status, but he did work on this a while ago, so he's acquainted with the code and probably knows about the reasons why the delineation wasn't included. > Mirek suggested this would be fixed by fixing the bug referred to in comment > 34. > > It obviously is NOT fixed. > > Mirek: can you please provide design departement's perspective on this? > Since otherwise devs say "we think this is fine as is". I can only provide my perspective, and perhaps other designers will chime in as well. Unfortunately, there's a pervasive indifference to UX problems within the LibreOffice community. (I'm not blaming anyone, though -- based on what I hear, the VCL toolkit is really off-putting, changes tend to be controversial, the UX team still needs to figure out how to be productive, and LibreOffice's business model encourages work on compatibility/features rather than usability.) If we ever want have widespread adoption, focus needs to move to UX. Refinements like this are a necessary part of that.
Created attachment 106637 [details] Screenshot of LibO 4.3.1 wearing a persona: no border between toolbar and document (In reply to comment #65) > (In reply to comment #62) > > I say this is a UI bug. All OS X apps that have a top menu have that border. > > LO Does not so it's either ignorant to OS X specific standard design or it > > is a valid bug. > > It's not OS X-specific. It's the case with Gnome's Adwaita theme as well. This bug can be also reproduced under Windows 7... but only wearing a Firefox Persona and not the default W7 look. Maybe this bug was introduced when the "new look" for W7, which imitates the uniform gradient between 2 toolbars without any separation.
This bug is old & there were various changes over the place in the meantime. Please let's close it, and if you are still unhappy with some aspects, please file new, separate issues. Please note that the look is different in OS X, Windows, and on Linux, and that mostly we try to mimic the look of the 'native' applications on those platforms. Thank you for your understanding.