Avoiding fragmentation with a rolling release

[Martin Pitt]

Hello Evan,

Evan Dandrea [2013-03-04 15:34 +0000]:
> > "From exceptions to segfaults" is quite a harsh exaggeration.
> 
> >> from gi.repository import GdkX11
> >> GdkX11.get_default_xdisplay()
> [1]    10593 segmentation fault (core dumped)  ipython
> 
> >> import gtk
> >> gtk.gdk.display_get_default()
> None

Right, that's what I call "harsh exaggeration" -- this is a
constructed corner case which would almost never happen in practice
(you would import Gdk or Gtk instead or in addition, and then it
works), and the pygtk example is not even the same thing -- "import
gtk" in pygtk2 does exactly what prevents the crash with GI in libgdk.

If you would write a binding yourself in C++ to use it in your QML
project, how would this prevent you from getting this crash as well?
(Which happens in the library you are binding to, not in GI)

> Also:
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/950087

Right, that's the thing which could either be fixed in GI and
annotations (with some effort), or be papered over with some
overrides.

As PyGObject maintainer I know very well how many bugs and problems
there are still in GI, and I know the associated problems. But none of
them are an actual technical barrier; if some company wanted to market
this as an app developer API, one could turn this into something
really nice with not too much effort (like one person fulltime), as
almost all of the problems have been solved already (even for
documentation: all the ideas are there, the tools exist, it's just
missing the final mile of integration and polish).

> Now one can argue as you did in the latter bug report that the developer is
> doing it wrong, but this is the sort of problem that did not exist with pygtk.
> 
> I think it also speaks to the problem faced whenever you mechanically generate
> bindings. These are not Pythonic. For someone versed in that language, writing
> Object.new() is entirely alien.

As Robert already said, it's fine to write overrides for that kind of
thing, if you want to go the extra mile to be more
Pythonic/JavaScriptic/Vala-ic, etc.. We do that for a lot of standard
libraries already, and it's still two magnitudes easier than writing
the whole language binding yourself.

> > But what do we get from switching from GI to QML? We won't have bindings to a
> > great many libraries at all any more, and now have to go back to writing C++
> > stubs for those. I. e. exactly the problem that GI already fixed.
> 
> That of course assumes we pick Python as the language for graphical
> applications and services. Last I checked, it wasn't the fastest thing going on
> an ARM processor. And the system requirements should bar it from ever being
> used for a long-running (ubuntuone-syncdaemon) or frequent process (Lenses).

Fully agreed, I wasn't actually advertising to use Python for daemons.
If you remember, I routinely yell "nooo!" whenever we got yet another
Python lens, and someone proposed writing the sensor daemon in Python.

For a simple app, Python or JavaScript should be just fine, though.
QML is interpreted as well after all.

> Developers of all stripes have written over 700,000 applications for iOS in
> Objective-C. What's so bad about telling people that they should write C++ with
> UI in Javascript?

I was rather thinking we would advertise QML for app development, not
Qt/C++ directly.

I have a number of reasons to not recommend the casual software
developer to learn and use C++, but I suppose that will easily end in
another endless debate. :-)

But if you complain about finding the odd corner case of segfaults
when using the native API of a library through GI, how is this going
to be any better if suddenly the application author has to use _all_
of the native C APIs from C++, without any of the conveniences and
safety nets that GI annotations and scripting languages provide you?

> > But I guess in the world of mobile apps which mostly deal with web access and
> > local rendering there are much fewer requirements to local APIs.
> 
> Agreed. If you're writing something that's effectively a webkit window with
> extra glue to talk to the notifications system, address book, and so on, your
> use of the system APIs will be minimal.

Indeed. But if only use that, why bother at all and don't just write a
web app with some pieces of JavaScript which talk to the local system?
(indicators, D-BUS services, etc.) For this kind of application it
seems even less prudent to dig out a C++ book and compiler.

> Well, I was hoping that we could put a few stakes in the ground and say that
> careful API cultivation and nurturing was something we really care about. Build
> it into the process so that we don't blindly pull in the new hotness in a year
> or two. Start making acceptance of new API methods into the core platform
> require full test coverage, full higher-level language support (if we've said
> we care about any), and complete documentation in the canonical source
> (developer.ubuntu.com) with examples.

That sounds like a laudable goal indeed.

Out of interest, is there some kind of "bindings repository" for QML
as well, where developers can share their bindings to particular
libraries that they wrote and need?

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)