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.

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.

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"

The Status should be NEW, of course ... because we are still in the dark middle ages ;-)

at best this is a meta bug, as it is way to broad and unspecific.

(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 ...

Started adding relevant bugs/enhancement requests under this thread.

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.

Relevant: https://bugs.freedesktop.org/show_bug.cgi?id=56046#c6

adding bug 49853 bug 55914 bug 60790 and bug 62054 -- all for basic Cocoa keyboard accelerators that don't function correctly.

Already three rows of a selection of OS X bugs. :)

adding bug 46986, mishandling of HyperLink placement in writer

adding bug 36799 for printing when envelope embedded in document, a bug mab3.6

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 ?

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?

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.

(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.

@Nicholas,

It would be better to post development related issues to the development mailing list, libreoffice@lists.freedesktop.org.

There is no MAB bug for Linux and none for Windows, why would there need to be one for Mac?

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.

(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?

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.)

(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. :)

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.

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)

=-=-

(In reply to V Stuart Foote from comment #25)

This was OBE. At 2015-06-03 Design Meeting:

    + Sifr icons now fall back on breeze icons as breeze is more complete
        + The styles are quite different and this looks poor in Mac. (Adolfo)
        + unfortunately it is so with any fallback (Jay)
        + and breeze is closer than any other fallback (Jay)
        + the best would be to finish the Sifr theme :-) - designers appreciated! (Kendy)
        + breeze on mac - https://bug-attachments.documentfoundation.org/attachment.cgi?id=116255
        + looks good! (Heiko, Jay, Kendy)
            + let's switch to that for the RC - and if there are complaints, revert (Kendy)
            + some general concerns about breeze, but in this case it seems to look & work well (Heiko)
            + conclusion: let's switch to that now on OS X, and if there's push-back, revert
 
=-=-=

So, Sifr for 4.4, then Breeze 5.0 -> current.
https://cgit.freedesktop.org/libreoffice/core/commit/?id=816941f1396b79eba2dc3b46c6cffb53835ee923

=-=-=

Current bug 116693 to restore Sifr is under review, and Breeze, or possibly the new Colibre icon theme, is a better choice for default icon theme on macOS than Sifr--which ends up a bit too heavy in weight and needs additional maintenance.

I would make Elementary the default icon theme in MacOS since it fits more the MacOS aesthetic.

About icon themes I would choose Colibre for OS-X cause of one reason "documentation and support".

I'm very happy that LibreOffice offer different icon themes and I also understood that for Linux users it is very important to have a consistent desktop, but in "real life" maintenance and support are more important. Have an online help, LibreOffice Books, Support Hotline, ... and everywhere they show different icons it can be very confusing for the users to understood that an icon will look different in different icon themes. If a user by a LibreOffice book, the user is interested in learn how LibreOffice work. Should be the first chapter in a book how to change the icon theme, cause otherwise it will be difficult to read/translate the book.

From my point of view it will be very professional to have on Windows and OS-X the same icon theme. I don't have a Mac but I don't think that the icon theme will that much out of place.

Can we include bug 133369 in this list? It concerns a UI issue with windows that move together when they shouldn't, which can be quite annoying when using LO on macOS.

This meta bug became a dumping ground for all sorts of Mac issues and not only about UI. I cleaned up the list of dependencies and changed the alias to macOS-UI-polish.