Avoiding fragmentation with a rolling release

[Dmitrijs Ledkovs]

On 4 March 2013 15:34, Evan Dandrea <evan.dandrea at canonical.com> wrote:
> On Mon, Mar 4, 2013 at 1:16 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
>> Evan Dandrea [2013-03-04 11:24 +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
>

I myself also segfaulted python a few times by calling GtkStyleContext
and or CssProviders the /wrong/ way when using GI.
For me the other caveats are lack of documentation look-ups, one has
to guess how it would be called in C api and look that up and then
translate to semi-pythonic dot notation, test the gi call in ipython
and only then use.
This is hardly rapid development. gtk-doc is so good, why cannot it
generate recent documentation as previously was available with pygtk?
If dbus-api gets auto-generated docs, why doesn't python?!

Glade is imperfect, it crashes a lot and doesn't support many features
that are available in GtkBuildable api. Furthermore glade preview at
times can be out of touch with reality since gtk will render the app
differently at run time.

It's unintuitive to write model-view-controller apps in gtk/GI/glade
and doesn't appear to be the default style of writting applications.
I'm not sure if it's a deficiency of all UI toolkits and I haven't
played with QtQuick yet. But for example scientific visualisation
toolkits e.g. Mayavi2 with TVTK and TraitsUI make the separation dead
easy and allow to play with views/controllers with a mock model easily
for rapid design and coding. The fact that QtQuick has explicit
states/transitions built into the UI on the first look makes it far
more attractive. I should play with QtQuick more.


>> 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).
>
> 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?
>

Qt "standard library", C++ stdlib, and boost / stl templates offer a
lot. And most C libraries can be used directly in C++ without writing
OO bindings. Together it seems like we are making the scope wider of
available platform libraries / APIs which previously was not available
in python-gi model. Popular libraries tend to have multiple bindings
in python, with slightly different APIs, with various degrees of
completeness and  uptodateness.

Regards,

Dmitrijs.