The Boston summit is well underway, time for some update on what is happening.
Day 1
Around 20 people got together Saturday morning and, after bagels and coffee got together in a room and collected topics that everybody was interested in working on. With Christian in attendance, gnome-builder was high on the list, but OSTree and gnome-continuous also showed up several times on the list.
Our first session was discussing issues of application writers with GTK+. Examples that were mentioned are the headerbar child order changing between 3.10 and 3.12, and icon sizes changing for some icons between 3.12 and 3.14 . We haven’t come to any great conclusions as to what we can do here, other than being careful about changes. GTK+ has a README file that gets updated with release notes for each major release, but it is not very visible. I will make an effort to draw attention to such potentially problematic changes earlier in the cycle.
Another kind of problem that was pointed out is that the old way of doing action-based menus with GtkAction and GtkUIBuilder has been deprecated, but the ‘new way’ with GAction, GMenuModel and GtkApplication has not really been fully developed yet; at least, there is not great documentation for migrating from the old to the new, or for just starting from scratch with the new way. The HowDoI‘s for this are a start, but not sufficient.
After the morning session, Richard Stallman came by and spent an hour with us, discussing the history of free software, current challenges, and how GNOME fits into this larger picture from his perspective.
In the afternoon, we had a long session discussion ‘future apps’, which is hard to summarize. It revolved around runtimes, sdks, bundling, pros and cons of btrfs vs ostree, portals, how to get apps ported to it, what to do about qt apps. This thread covers a lot of the same ground.
I managed to land GType statistics support in GObject and GtkInspector.
Day 2
Over breakfast, we talked about the best way to communicate with a webkit webview process, which somehow led us to kdbus. Takeaways from this discussion:
- We (GNOME release team) should push for getting all users of webkit ported to webkit2 this cycle
- We should create a document that explains what application and service authors and distributors need to do when porting to kdbus
After breakfast, we started out with a live demo of gnome-builder, which looks really promising. Christian is reusing a lot of existing things, from gtksourceview over devhelp to gitg and glade. But having a polished, unified application bringing it all together makes a real difference!
As this session was winding down, I started testing a GNOME 3.14.0 Wayland session with the goal of recording as many of the smaller (and larger) issues as possible in bugs. The result so far can be found here. While I reported a long list of Wayland issues today, all is not bad. It was no problem at all to write this blog post in a Wayland session!
Thanks to Red Hat and Codethink, who are sponsoring this event
We haven’t come to any great conclusions as to what we can do here, other than being careful about changes.
Easy fix: Write testcases. If they get accepted, we’ll make sure they won’t break. My rule is (and probably will be in the future): Stuff that isn’t tested is free for everybody.
What a coincidence, I’ve just been spending part of this weekend porting an application away from GtkUIManager. It’s been a bit of a struggle to be honest.
I think in the way of documentation what would have helped most is the following:
– most of all, more explanation in the GtkUIManager docs (https://developer.gnome.org/gtk3/stable/GtkUIManager.html) about how to write the same things that you could do with GtkUIManager in the new-school code
– explanation of when to have an “app.” and when to have a “win.” prefix on your actions
– what g_menu_item_set_attribute() is for – I found out after quite a lot of googling that that’s how you set accelerators on menu items, and I suspect that that’s also how you set other things like icons on menu items, but I don’t believe the available attributes are documented anywhere in the API docs
Another wish-list feature would be the ability to put together your GMenuModel in Glade, instead of in code.
I’d love to help by providing patches for the documentation, but I can’t really do that yet, as I haven’t figured out how it works.
“Conethink” 🙂
Thanks for the summary!
You’ve spelled ‘codethink’ as ‘conethink’, though 😉