Re: Bug 687752 - work with theme authors



On Fri, 30 Nov 2012 21:08:19 -0700
Michael Torrie <torriem gmail com> wrote:
[snip]
> If, for example, a
> light-weight rescue distro wants to have a widget toolkit on which to
> make apps, what do you recommend? Part of what made GTK2 so wonderful
> is that it was easy to use PyGTK and hack together a light-weight,
> standalone app that did something useful.
> 
> I'm only a casual developer, and I love using GTK (2), because it is
> just portable enough for my needs.  Much of what I would do in the
> future I could see targeting small pseudo-embedded computers.  Say ARM
> with a touch screen (no I don't want to run android), perhaps running
> only an X server, with no udev, no systemd, and a single app.  GTK3,
> with support for touch and multitouch would seem to be a good
> candidate for targeting a GUI to such an environment, if it were
> light and platform-independent like GTK2 (read: not tied to Gnome).
> I don't need or wnt Gnome's many layers.  And if GTK3 can't fill my
> needs, that's okay; there are options, though none as nice as GTK's
> api.

It is quite unusual for a gtk+/gnome developer to read this news group
and so acquaint himself with the views of users, so kudos to Benjamin
for that.  Having said that, I think part of the problem is that this
thread (and the bug number to which it refers) is about theming, not
about gtk+ as such.

The part of Benjamin's post which sums up the current discomforture is
his extending this to gtk+ itself, with his remarks that "It means
[application developers] can't rely on things staying the same or having
a stable base to build on.  Things keep changing.  You can't just write
something for 3.0 (be it an application, a shell plugin or a GTK theme)
and expect it stay working that way forever."

This is kite flying.  It has always been understood that gtk+3 theming
and the gnome shell API (and to that you can also add introspection) are
not stable and still under heavy development, with a view to eventually
becoming stable but (like Saint Augustine) not yet.  To the application
developer this doesn't usually matter.  The shell is irrelevant to gtk+
application development.  And theming is normally for the environment,
not the application.  A gtk+3 application written for gtk+3.0 and run in
an environment (such as gnome) with a standard theme such as Adwaita
will look pretty much the same in gtk+3.0 as in gtk+3.6.  If an
application developer does happen to use theming to create an individual
application "look" for her particular application then she is stuck
with gtk+2 at present, but (i) such applications are in the vast
minority, and (ii) that is not really what theming is about.  Note also
that gtk+2 is still maintained, and given its use by the
not-really-gtk+-application behemoths such as firefox and libreoffice,
going to remain so for some time.

The main case where what I have said is not true is the one not
previously mentioned, namely introspection.  pygobject is pretty good
about working with gobject-introspection, but gjs less so.  Anyone
writing a javascript application using gjs with the introspection
bindings available with gtk+-3.0.0/gjs-0.7 has probably had to carry
out work on it if now using it with the latest bindings with
gtk+-3.6/gjs-1.34.

I could be wrong, but I do not think that (excluding themes) there is
any real chance of gtk+ ceasing to retain API and ABI compatibility at
the C level within major versions.  It would be contrary to the
currently stated mission and policy and I do not think the gtk+
maintainers would accept it.  And the fact remains that the number of
gtk+ applications out there which are not formally part of the gnome
stack, or do not use any specific gnome components, far exceeds
(probably by a number of orders of magnitude) the number of
identifiably "gnome" applications (those, say, in the 'core' and 'apps'
directory of the gnome ftp site).

If such breakage were to happen, the gtk+ maintainers would have failed
their users and I and many others would be highly disappointed.

Chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]