Bug 42082 (MacOS-UI) - [META] Make LibreOffice shine and glow on OS X
Summary: [META] Make LibreOffice shine and glow on OS X
Status: NEW
Alias: MacOS-UI
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Mac OS X (All)
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL: https://developer.apple.com/library/p...
Whiteboard:
Keywords:
Depends on: 33467 35361 35550 36799 41775 42000 42437 43894 44794 50278 50507 51733 51734 51735 52263 53282 53965 55922 56249 56932 57894 58472 60582 61768 62385 63094 63216 65972 67749 69383 71693 72490 72711 77444 81908 82039 83700 87130 89657 91400 92382 92383 92750 92909 96359 97841 98290 98513 98819 102018 103252 105803 106148 109062 112153 31525 36431 36448 37372 37453 38757 39007 39477 39983 41169 44621 coretext 46271 46609 49827 49853 49914 50506 52004 53320 55914 56046 56200 57256 59553 60440 60790 61646 61788 62054 65635 69358 76681 80939 81759 81876 90822 98233 99673 99784 100946 101905 106050
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-20 22:54 UTC by Sierk Bornemann
Modified: 2017-10-09 17:52 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sierk Bornemann 2011-10-20 22:54:19 UTC
“Create a User Interface so that LibreOffice becomes the users' choice not only out of need, but also out of desire”

Following and in free support on the credo of the OpenOffice.org Renaissance project:

OpenOffice.org Wiki: Renaissance
http://wiki.services.openoffice.org/wiki/Renaissance

OpenOffice.org Wiki: Renaissance: The Challenge
http://wiki.services.openoffice.org/wiki/Renaissance:The_Challenge


Better OS integration: use more OS/MacOSX/iOS native Cocoa-based core technologies and frameworks which are diamonds (!) on MacOSX and iOS and which just have to get picked up. Follow

Apple's User Interface Guidelines
http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html

with more passion. Current status concerning that in LibreOffice, OpenOffice.org and also in NeoOffice (which tries to make the best out of what OOo and LO deliver but which also has its limits and boundaries in trying to do so): a woefully "no passion at all", at least with more humility and regard to the platform itself and what it provides.

Headmost and a first step for the beginning: fix those issues addressed in the inherited and still not fixed OpenOffice Bug 98991

OpenOffice Bug 98991 - Remove Aqua Pinstripe background in dialogs 
http://openoffice.org/bugzilla/show_bug.cgi?id=98991

and

OpenOffice Bug 95430 - Improve OOO Cocoa integration into MacOSX, make it seamless 
http://openoffice.org/bugzilla/show_bug.cgi?id=95430
Comment 1 ryan 2011-11-20 17:11:34 UTC
I'm interested in helping on this and available. I'm going to send out an intro e-mail in the next 24 - 48 hours.
Comment 2 thackert 2012-01-22 06:32:42 UTC
Hello Sierk,
as this is a feature request (or better: an enhancement), I lower the importance as well as changing it to "enhancement". But I do not understand, why you are listening OOo related infos here instead in their bugzilla. Why should we change something, OOo has not changed yet? They have to change this first, so we can implement it as well ... ;)
HTH
Thomas.
Comment 3 Pedro 2012-01-22 06:34:48 UTC
I hope Project Renaissance will be a reality for all platforms ASAP :)

I do like this motto:

"Create a User Interface so that LibreOffice becomes the users' choice not only
out of need, but also out of desire"
Comment 4 Roman Eisele 2012-05-31 02:15:21 UTC
The Status should be NEW, of course ... because we are still in the dark middle ages ;-)
Comment 5 Björn Michaelsen 2012-10-14 14:20:00 UTC
at best this is a meta bug, as it is way to broad and unspecific.
Comment 6 Roman Eisele 2012-10-16 12:29:15 UTC
(In reply to comment #5)
> at best this is a meta bug, as it is way to broad and unspecific.

A good idea! So we should begin to add bugs to “Depends on” here?! Not all bugs specific to LibO on Mac OS X, of course, but bug reports and enhancement requests about 
* better OS integration (“use more OS/MacOSX/iOS native Cocoa-based
  core technologies and frameworks”)
* and IMHO also UI bugs which make LibO look foreigh/outdated/unprofessional
  on Mac OS X.

I do not know if this will help much (what we *really* need are more *developers* with interest in and knowledge about Mac OS X, to fix these bugs ;-), but at least for us QA guys this meta bug may be useful -- and for the developers, too, if they will come some day ...
Comment 7 Emir Sarı (away) 2012-10-19 18:48:46 UTC
Started adding relevant bugs/enhancement requests under this thread.
Comment 8 Nicholas Shanks 2012-11-26 21:44:27 UTC
The way to achieve this is to make compiling and building on Mac OS X a no-brainer operation. Then developers like myself will spend a weekend fixing your Mac code instead of getting frustrated at being unable to build the app.
Comment 9 Emir Sarı (away) 2012-12-10 23:31:50 UTC
Relevant: https://bugs.freedesktop.org/show_bug.cgi?id=56046#c6
Comment 10 V Stuart Foote 2013-04-04 15:28:35 UTC
adding bug 49853 bug 55914 bug 60790 and bug 62054 -- all for basic Cocoa keyboard accelerators that don't function correctly.
Comment 11 Emir Sarı (away) 2013-04-05 01:18:32 UTC
Already three rows of a selection of OS X bugs. :)
Comment 12 V Stuart Foote 2013-05-05 16:22:42 UTC
adding bug 46986, mishandling of HyperLink placement in writer
Comment 13 V Stuart Foote 2013-05-06 13:17:40 UTC
adding bug 36799 for printing when envelope embedded in document, a bug mab3.6
Comment 14 Don't use this account, use tml@iki.fi 2013-06-24 08:25:47 UTC
So is this bug turning into another MAB-style metabug?

In my opinions, it makes sense to add as dependees here more specific enhancement requests. Not bugs that are simply bugs (even if OS X -specific).

Nicholas: When did you last try to build LibreOffice on OS X? It *should* be a no-brainer now. Have you read https://wiki.documentfoundation.org/Development/BuildingOnMac ?
Comment 15 Don't use this account, use tml@iki.fi 2013-08-03 17:33:52 UTC
Not that I expected anybody to care for my opinion. So apparently "make it shine and glow" means simply "fix bugs", and not "make it use more Mac-specific functionality" (like iCloud, Versions, full-screen etc)?

As such I don't understand then what the difference between this metabug and the MAB metabug is. Or do we need a separate metabug (this one) for Most Annoying Mac-specific bugs?
Comment 16 Emir Sarı (away) 2013-08-03 18:36:43 UTC
IMHO,

I agree with Tor's previous statement, this thread should only be for Mac-specific enhancement requests, but in addition to this - 

It would make more sense if we could start a wiki page like Mac specific hacks, and create a kind of roadmap, and making it convenient for people who would like to contribute to OS X code. This could be like `replace this API with the newer this API`, `get rid of this dependency`, or `add this library` kind of things with necessary code pointers. 

And some of the bugs here already require big overhauls in the Mac code as far as I can see with my limited technical knowledge, instead these, creating Mac specific hack threads would make more sense I think.

Following this approach would also help to ensure LO uses the latest OS X technologies, solving bug in bulks, and thus giving a better UX experience.

But in order to achieve this we need developer input to create these threads.
Comment 17 Nicholas Shanks 2013-08-04 08:44:01 UTC
(In reply to comment #14)
> Nicholas: When did you last try to build LibreOffice on OS X? It *should* be
> a no-brainer now. Have you read
> https://wiki.documentfoundation.org/Development/BuildingOnMac ?

Yesterday I built LO using a checkout from about Thursday evening GMT, following those instructions.

Two unit tests failed:


~/Projects/LibreOffice/core/sc/qa/unit/helper/qahelper.cxx:436: Assertion
Test name: ScExportTest::testMiscRowHeightExport
equality assertion failed
- Expected: 529
- Actual  : 556

~/Projects/LibreOffice/core/sc/qa/unit/subsequent_export-test.cxx:521: Assertion
Test name: ScExportTest::testSheetProtectionXLSX
assertion failed
- Expression: xShell.Is()

Failures !!!
Run: 11   Failure total: 2   Failures: 2   Errors: 0

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE            # for exception catching
export GDBCPPUNITTRACE="gdb --args" # for interactive debugging
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_sc_subsequent_export_test

make[1]: *** [~/Projects/LibreOffice/core/workdir/unxmacxi.pro/CppunitTest/sc_subsequent_export_test.test] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [build] Error 2
mars:core nickshanks$ 



Am now trying again with an updated code pull, in case it was just a broken HEAD I grabbed.

TOR: is there an extant MAB meta for Mac? Please add me to the CC list if so.
Comment 18 Emir Sarı (away) 2013-08-04 13:33:21 UTC
@Nicholas,

It would be better to post development related issues to the development mailing list, libreoffice@lists.freedesktop.org.
Comment 19 Don't use this account, use tml@iki.fi 2013-08-04 16:46:34 UTC
There is no MAB bug for Linux and none for Windows, why would there need to be one for Mac?
Comment 20 Don't use this account, use tml@iki.fi 2013-08-22 05:38:32 UTC
I don't think the bug #68274 enhancement request is anything we (I use "we" in the meaning "we that actually so far have worked on the code") are going to bother with. "We" see distribution through the App Store as a much more important goal, and the App Store already has an update mechanism. We don't have resources to spend on implementing and debugging a separate update mechanism just for nightly builds. It's much more important to spend resources on the actual OS X specific features in the code.
Comment 21 Emir Sarı (away) 2013-08-22 05:58:30 UTC
(In reply to comment #20)
> I don't think the bug #68274 enhancement request is anything we (I use "we"
> in the meaning "we that actually so far have worked on the code") are going
> to bother with. "We" see distribution through the App Store as a much more
> important goal, and the App Store already has an update mechanism. We don't
> have resources to spend on implementing and debugging a separate update
> mechanism just for nightly builds. It's much more important to spend
> resources on the actual OS X specific features in the code.

Actually this is nicer to hear. But I've thought that distributing an application in App Store requires sandboxing, and strictly getting rid of all the Java and Python code, in addition the requirement of strict Cocoa coding. Wouldn't this break compatibility with LO on other platforms?
Comment 22 Don't use this account, use tml@iki.fi 2013-08-22 06:13:43 UTC
Those are technical problems that can be solved. It is not entirely sure to me if it is also prohibited to enable an *optional* use of Java. After all, Java is not used for any really essential features. (And for Python, we include our own Python, so that is not a problem.) (We could also build and include an own Java, I think there are suitably licensed ones.)
Comment 23 Emir Sarı (away) 2013-08-22 06:43:16 UTC
(In reply to comment #22)
> Those are technical problems that can be solved. It is not entirely sure to
> me if it is also prohibited to enable an *optional* use of Java. After all,
> Java is not used for any really essential features. (And for Python, we
> include our own Python, so that is not a problem.) (We could also build and
> include an own Java, I think there are suitably licensed ones.)

Great news! Thanks for the enlightenment. :)
Comment 24 Emir Sarı (away) 2014-10-29 17:06:16 UTC
Limiting my QA field for the moment, since my Mac only supports 10.7.5, therefore unable to run LO 4.4/master. Hoping to return in the near future.
Comment 25 V Stuart Foote 2014-11-12 20:41:12 UTC
Note from today's 2014-11-12 Design team meeting on use of Sifr as default for OS X builds--noting that it should blend well with 10.10. Also, some discussion of inverting for use as High-contrast.

Please comment to Design ML, or TDF RedMine Design project.

Stuart

=-=-

* Making sifr default on Mac (Steve, Jay)

    + with Mac OSX now having flat icons, it would be useful to have sifr as default
    + how iWork Pages looks now - http://i.imgur.com/P5X7FSt.jpg
    + we should want to promote the icon set build by LibO, as Mac OSX is a good starting spot
    + sifr incomplete - is there a technical solution for the missing icons?
        + like change the colors of the HiContrast to something gray? (Kendy)
        + does not look like it is possible to use it that way (Steve)
        + Writer by default already complete (Steve)
            + and the fastest evolving icon theme (Steve)
    + Sifr icons improvements - https://redmine.documentfoundation.org/boards/1/topics/35?r=439
    + conclusion: Let's do it for 4.4
        + if too problematic for people, can revert for the final release (Kendy)
        + fixing / introducing new icons in the beta phase is not an issue (Kendy)
        + could post a note to https://bugs.freedesktop.org/show_bug.cgi?id=42082
AI  + Will do the switch (Kendy), Steve can test then, has a Mac
    + any plans for Sifr to work as hicontrast? (Heiko)
        + Sifr uses one color, the rest is handled by transparency (Jay)
        + easy to do this programatically then :-) (Kendy)
            + just to change this color to any other on the fly - white for Hicontrast eg. (Kendy)

=-=-