Building RKWard on Mac (continued from private discussion)

[Thomas Friedrichsmeier]

On Thu, 08 Jun 2017 15:58:23 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
> The easiest thing to ensure icon support would be to add
> $prefix/share/icons to the icon theme search path explicitly when you
> start the UI, at an appropriate and sufficiently early location.

For the record: You'll also have to specify a theme name to use.
QIcon::setSearchPaths() and QIcon::themeName().

Which of course adds a rat-tail of problems, such as supporting primary,
and fallback themes, user preferred themes, etc.. At least if you're
looking for more than the quick-and-dirty.

> I
> would of course advise to install the osx-integration package,
> because with that you also get full colour palette and font role
> support. Esp. the latter should make the application look a bit
> better because you no longer get the fallback to the standard 13pt
> Lucida Grande system font.

Ok, disregarding the fonts and all, and focusing on the icons, only:
Sweet. So that works without adjustments to the code. _But_ can I just
depend on this, then? Or won't this interfere with pure Qt apps, once
again?

For our binary standalone package, we won't care. But for playing
nice with MacPorts I'll have to go the search paths + theme name route
outlined above, in addition, right?

I wonder: Would it be feasible to create something (a framework?) where
I can simply write:
  MagiKPlatform::doAllThatPlatformSpecificStuffToGetSaneKDEBehavior();
and be done with? Including all fonts, icons, dbus, whatever comes up
now or in the future?

> > I would have expected to get a null QIcon(), i.e.
> >   QIcon::fromTheme("nah-thats-wrong").isNull() == true  
> 
> Isn't that the same as an empty icon, in practice?

In use, yes, but it would make it easier to diagnose the error
condition. Essentially isNull() vs isEmpty().

> > I don't get to see the issue (probably it's a race condition), so  
> 
> Do you get rbackend showing up as a generic non-GUI application
> (terminal icon) with a very curious menubar when you activate it?

Umm, no? OSX 10.9, here.

> > could you try: The best place might be rbackend/rkrinterface.cpp
> > lines 327-342. The main window widget can be obtained using
> > RKWardMainWindow::getMain().  
> 
> Doing that from the backend wouldn't work on Mac, the only thing
> that's currently supported is activating the entire application from
> with the application itself.

That's still in the frontend process. Just the backend as seen by the
frontend, so to speak. The directory layout may not be all that
helpful, indeed, but part of the problem is that backend and frontend
processes share some of the same code (think of it as the protocol), so
it's not trivial to come up with a clear layout.
 
> Anyway, I just remembered I still had a .Rprofile lying around that
> did some probably naughty things tailored for R 2.1 or so at the
> latest. Removing that file solved the issue.

Ok.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20170608/b4d0b867/attachment.sig>