[KDE/Mac] OSX/CI: konversation still fails to run properly

[Jeremy Whiting]

Rene,

I'm not sure what sort of strings trigger the menu role heuristics. In
konversation's settings menu on linux I see 4 entries that start with
"Configure" namely "Configure Shortcuts...", "Configure Toolbars...",
"Configure Notifications...", and "Configure Konversation...". Is that what
you mean? On OS X it is putting the "Configure Konversation..." one in
konversation -> Preferences as I expected, not sure what those QCocoaMenu
warnings are about.

On Mon, Feb 23, 2015 at 3:09 PM, René J.V. <rjvbertin at gmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150223/8f3e35f1/attachment-0001.html>