[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] OSX/CI: konversation still fails to run properly
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-02-23 22:09:24
Message-ID: 2728417.jFRborlIR9 () portia ! local
[Download RAW message or body]

On Monday February 23 2015 10:37:31 Jeremy Whiting wrote:

> Yeah, that seems to be because the dbus files are wrong on OSX looking here
> it looks like the
> /usr/local/share/dbus-1/services/org.kde.kglobalaccel.service file has
> Exec=/usr/local/bin/kglobalaccel5 but kglobalaccel5 is a .app and is in
> /Applications/KDE/kglobalaccel5.app instead of in /usr/local/bin. If we
> update the .service file to point to the right place it should work. Not
> sure how we can make that "fixed" for all the various .service files we
> install in different frameworks, but that is probably the solution.
> 
> In fact I just tested. I changed manually the kglobalaccel.service file to
> have Exec=/Applications/KDE/kglobalaccel5.app/Contents/MacOS/kglobalaccel5
> and it launched kglobalaccel5 just fine, gave no warnings on the terminal,
> and left kglobalaccel5 in the dock (that should probably be changed to not
> appear I guess).

Actually, kglobalaccel used to be built as a regular, non-bundle application.. That's \
one reason I had to patch the code to make it behave like an agent (= don't appear in \
the dock) ... and that I only did because it was one of those unwanted apps that kept \
appearing there (in the dock) without my explicit benediction.  There ought to be no \
reason it is now built as an app bundle. I don't think it ever presents a dialog or \
other widget, it just needs a connection to the window server in order to handle \
keyboard events.

> 
> As to how to make these changes permanent when building the .services files
> with cmake I'm not sure, how was that done with kde4 based macports stuff?

Not, I think. It's possible that some patches were made "post-destroot" in MacPorts \
Portfiles, but I have in fact never looked at that.

> > > void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu
> > item is already in a menu, remove it from the other menu first before
> > inserting

That one is due to Qt's heuristic guessmatics trying to decide which menu actions are \
assigned to About, Preferences and other OS X menu items. I tried to make the error \
message more useful (print the incriminated menu item/action) but I don't know if \
that patch made it to my +KDE variant of port:Qt5-mac-devel (yet).


> > > - sound doesn't work

Did you install Phonon (phonon4qt5), with a backend and all the stuff the backend \
requires?

> > > While clicking around more and more of those QCocoaMenu::* warnings
> > appeared on
> > > the console.

Who wrote this, in fact?

> > > I guess this is an OSX issue wrt menu roles, which René was working on
> > in the
> > > last while.

Yes, as I said I think it is. I haven't been able to prove that yet, though (didn't \
try too hard either). That said, the message is about a menu *item*, not a menu \
*action* (QAction) that's already associated with a menu. So it could be some other \
Qt-internal glitch, though I cannot recall seeing it in pure Qt5 apps.

Does KF5 Konversation have multiple menu entries with names that share a common \
string and if so, is that a string that could trigger the menu role heuristics?

Cheers,
R.
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic