search

elelay / quodlibet-osx-bundle

QuodLibet as an OS X native application
5 stars 0 forks source link

menu integration #1

Closed lazka closed 9 years ago

lazka commented 10 years ago

See http://blogs.gnome.org/jessevdk/2014/09/02/gedit-3-14-for-os-x-preview/

Seems we need to port to GtkApplication and use GTK+ 3.14

elelay commented 10 years ago

yeah! the stuff about reproducible builds is also very interesting: I've also put the modulesets in tree, but have a manual list of commands to run in README...

elelay commented 10 years ago

do you intend to make a headstart at porting to GtkApplication?

lazka commented 10 years ago

Yes, I'll look into it. We also need to port to GtkBuilder and GAction first.

elelay commented 10 years ago

I'm by no mean a gtk expert, but do you have to use gtkbuilder to port to GtkApplication?

Also, there is the path of gtk-osx-application, requiring less changes: you create an Application, https://github.com/gpodder/gpodder/blob/master/src/gpodder/gtkui/main.py#L95 And pass it the menu: https://github.com/gpodder/gpodder/blob/master/src/gpodder/gtkui/main.py#L172

lazka commented 10 years ago

We use Gtk.Action and Gtk.UIManager for creating the main menu. Those got replaced by Gio.Action and Gtk.Builder afaik. And Gtk.Applicaiton only takes a Gio.MenuModel and no Gtk.Menu.

Gtkosx.Application looks easier, but you'd have to integrate: https://github.com/jralls/gtk-mac-integration/

elelay commented 10 years ago

I've a tentative patch using gtk-osx-application here: https://github.com/elelay/quodlibet-osx-bundle/blob/master/patch-quodlibet-experimental-gtk-osx-application.patch

issues:

I've made a new version of the bundle (3.2.1_2) including the patch. Get it from http://kerik-sf.users.sourceforge.net/quodlibet-osx-bundle/ as usual. Hope it's ok to publish a patched version like this. From now on if you prefer I can publish the patch and we discuss it before I publish a new version. On the other hand it's easier for you to test it that way... Let me know.

elelay commented 10 years ago

Hitting Cmd-Q will terminate quodlibet instantly, not letting it save current track, etc. Closing the window will save current track, etc. This is something unexpected for mac apps, by the way: they usually keep launched, and you can bring the main window back from a menu. This would have to be changed once we can properly quit via Cmd-Q or the Application Quit menu item. Meanwhile it's an easy way to quit QL properly.

lazka commented 10 years ago

(no mac around atm, will test later)

quit: what about calling app.quit() instead? shortcuts: ok patches: I don't mind. Maybe you can use current trunk instead of 3.2. It isn't that different, but allows me to make changes from there. I can link the builds on the download page if you want. You can also have commit rights to the main repo if you want.

elelay commented 10 years ago

quit: I think the gtk event loop is blocked when receiving the NSApplicationBlockTermination event, so neither app.quit() nor _gtk_quit() work: they are stuck and the application must be forced-killed.

shortcuts: I've restored the Ctrl modifier for controlling playback. I couldn't come with a good alternative. I'll look into the osxmmkey plugin (need to install pyobjc), which would allow the Play/Next/Previous keys to be used (when one has them on the keyboard, which is the case for current laptops but not 2005's keyboards).

There is now a bundle for 3.2.2. I'll switch to trunk from now on. Thanks for your offer: links from the download page would be cool. I'd like to put the contents of this repository in a subdirectory of the main repo. I'm not familiar with mercurial, though.

elelay commented 10 years ago

I've forked lazka/quodlibet on bitbucket as elelay/quodlibet.

lazka commented 10 years ago

Thanks.

What about returning True in NSApplicationBlockTermination and calling app.quit()? i.e. veto shutdown but do it anyway shortly after.

elelay commented 10 years ago

good point. I'll have to test that. using GObject.idle_add() should do the trick.