Bug 57433 - There is no border between the document and toolbar areas
Summary: There is no border between the document and toolbar areas
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ux-advise (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Mac OS X (All)
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-22 21:18 UTC by Emir Sarı (away)
Modified: 2015-11-27 14:22 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
Toolbar vs. Document (23.68 KB, image/png)
2012-11-22 21:18 UTC, Emir Sarı (away)
Details
Screenshot for bug 57433 - with default settings = rulers on.png (80.83 KB, image/png)
2012-11-27 12:44 UTC, Roman Eisele
Details
Screenshot for bug 57433 - with different Document background color (161.57 KB, image/png)
2012-11-27 12:48 UTC, Roman Eisele
Details
Rulers off in 3.6.4.1 (47.15 KB, image/png)
2012-11-27 12:49 UTC, Emir Sarı (away)
Details
Better screenshot for bug 57433 (211.51 KB, image/png)
2012-11-27 15:43 UTC, Roman Eisele
Details
Apple Pages Main Window, illustrating requested border (78.95 KB, image/png)
2013-10-12 17:20 UTC, Emir Sarı (away)
Details
4.2.0 beta1 Screenshot (84.96 KB, image/png)
2013-11-29 07:25 UTC, Emir Sarı (away)
Details
Proposed_black_top_toolbar (115.25 KB, image/jpeg)
2014-01-22 13:08 UTC, Armandos
Details
screenshot of where we are at as of 2014-05-01 (87.29 KB, image/png)
2014-05-01 21:27 UTC, retired
Details
LO 4.3.1RC1 rulers off (91.88 KB, image/jpeg)
2014-08-16 09:49 UTC, retired
Details
Apple Pages Main Window illustrating what is requested (104.74 KB, image/png)
2014-09-10 04:32 UTC, retired
Details
clip from LODev440 -- Writer no rulers, clear delineation (88.18 KB, image/jpeg)
2014-09-10 15:23 UTC, V Stuart Foote
Details
Screenshot of LibO 4.3.1 wearing a persona: no border between toolbar and document (159.93 KB, image/jpeg)
2014-09-22 01:55 UTC, Francisco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emir Sarı (away) 2012-11-22 21:18:55 UTC
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.
Comment 1 Roman Eisele 2012-11-27 12:44:08 UTC
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.
Comment 2 Roman Eisele 2012-11-27 12:48:42 UTC
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.
Comment 3 Emir Sarı (away) 2012-11-27 12:49:01 UTC
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.
Comment 4 Roman Eisele 2012-11-27 15:19:02 UTC
(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?
Comment 5 Roman Eisele 2012-11-27 15:30:41 UTC
@ 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!
Comment 6 Roman Eisele 2012-11-27 15:43:25 UTC
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.
Comment 7 Emir Sarı (away) 2012-11-27 16:34:37 UTC
I wonder who at first place decided to make the OOo toolbars white... If I just knew... My eyes. :(
Comment 8 Emir Sarı (away) 2012-12-09 03:29:06 UTC
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.
Comment 9 Roman Eisele 2012-12-09 14:19:11 UTC
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 ...
Comment 10 Stefan Knorr (astron) 2012-12-09 19:27:18 UTC
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)
Comment 11 Emir Sarı (away) 2012-12-11 08:24:37 UTC
Relevant: https://bugs.freedesktop.org/show_bug.cgi?id=56046#c6
Comment 12 Emir Sarı (away) 2013-01-12 03:16:54 UTC
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).
Comment 13 Emir Sarı (away) 2013-01-20 20:41:33 UTC
Any info about when can we get our border back? :)
Comment 14 Adolfo Jayme 2013-01-31 04:45:03 UTC
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.
Comment 15 Emir Sarı (away) 2013-04-10 10:50:16 UTC
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...
Comment 16 Rainer Bielefeld Retired 2013-04-16 15:30:21 UTC
Something went wrong here, this one has nothing to do with Bug 63585
Comment 17 Cor Nouws 2013-09-06 15:17:18 UTC
(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?
Comment 18 Emir Sarı (away) 2013-10-10 07:38:22 UTC
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.
Comment 19 Michael Meeks 2013-10-10 08:37:45 UTC
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.
Comment 20 Emir Sarı (away) 2013-10-10 09:12:57 UTC
@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. :)
Comment 21 Cor Nouws 2013-10-10 11:01:28 UTC
(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
Comment 22 Michael Meeks 2013-10-10 12:35:00 UTC
> 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.
Comment 23 Emir Sarı (away) 2013-10-11 08:52:56 UTC
@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. :)
Comment 24 Cor Nouws 2013-10-11 11:33:56 UTC
(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 :)
Comment 25 Emir Sarı (away) 2013-10-12 17:13:00 UTC
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
Comment 26 Emir Sarı (away) 2013-10-12 17:20:19 UTC
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.
Comment 27 Emir Sarı (away) 2013-11-29 07:25:28 UTC
Created attachment 89975 [details]
4.2.0 beta1 Screenshot
Comment 28 Björn Michaelsen 2014-01-17 09:58:38 UTC
(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.
Comment 29 Armandos 2014-01-22 13:08:32 UTC
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.
Comment 30 Emir Sarı (away) 2014-01-26 17:49:03 UTC
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.
Comment 31 Adolfo Jayme 2014-01-26 17:58:19 UTC
And the point of that rant was . . . ? Dude!
Comment 32 Tor Lillqvist 2014-01-26 19:57:37 UTC
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.)
Comment 33 Michael Meeks 2014-01-27 15:13:55 UTC
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.
Comment 34 Tin Man 2014-01-27 23:47:54 UTC
This bug should be fixed by drawing borders as described at https://bugs.freedesktop.org/show_bug.cgi?id=59329#c5 .
Comment 35 stragu 2014-02-13 23:04:00 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 36 tommy27 2014-05-01 08:51:44 UTC
@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.
Comment 37 Emir Sarı (away) 2014-05-01 11:16:56 UTC
@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.
Comment 38 tommy27 2014-05-01 19:25:25 UTC
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.
Comment 39 retired 2014-05-01 21:27:47 UTC
Created attachment 98316 [details]
screenshot of where we are at as of 2014-05-01
Comment 40 Robinson Tryon (qubit) 2014-08-16 01:02:03 UTC
(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
Comment 41 Adolfo Jayme 2014-08-16 09:21:01 UTC
(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).
Comment 42 retired 2014-08-16 09:49:36 UTC
Created attachment 104720 [details]
LO 4.3.1RC1 rulers off
Comment 43 retired 2014-08-16 09:50:53 UTC
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
Comment 44 retired 2014-08-16 09:53:08 UTC
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.
Comment 45 Emir Sarı (away) 2014-08-16 10:00:41 UTC
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 46 retired 2014-08-16 10:11:54 UTC
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 47 retired 2014-08-16 10:12:51 UTC
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 48 retired 2014-08-16 10:14:49 UTC
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 49 retired 2014-08-16 10:16:30 UTC
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 50 retired 2014-08-16 10:17:21 UTC
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 51 retired 2014-08-16 10:17:58 UTC
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 52 retired 2014-08-16 10:19:26 UTC
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
Comment 53 retired 2014-08-16 10:22:53 UTC
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.
Comment 54 Björn Michaelsen 2014-08-21 12:17:28 UTC
(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.
Comment 55 retired 2014-09-10 04:32:29 UTC
Created attachment 106022 [details]
Apple Pages Main Window illustrating what is requested
Comment 56 Robinson Tryon (qubit) 2014-09-10 12:20:23 UTC
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?)
Comment 57 Cor Nouws 2014-09-10 12:33:15 UTC
(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.
Comment 58 Adolfo Jayme 2014-09-10 13:48:18 UTC
This is not a MAB. Be serious, people. It is just a minor visual annoyance some are naysaying over.
Comment 59 V Stuart Foote 2014-09-10 15:23:46 UTC
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...
Comment 60 Emir Sarı (away) 2014-09-10 15:40:38 UTC
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.
Comment 61 V Stuart Foote 2014-09-10 16:19:09 UTC
As Mirek suggested in comment 34, border work being done for bug 59329 touched most of this.

Ahmad H., final status there?
Comment 62 retired 2014-09-11 14:18:30 UTC
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".
Comment 63 V Stuart Foote 2014-09-11 14:40:00 UTC
(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.
Comment 64 retired 2014-09-11 14:44:15 UTC
Again, I believe that is another bug and not related to this here. Just read the title and see it's not fixed.
Comment 65 Tin Man 2014-09-11 14:58:37 UTC
(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.
Comment 66 Francisco 2014-09-22 01:55:04 UTC
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.
Comment 67 Jan Holesovsky 2015-11-27 14:22:23 UTC
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.