Glade: big plans with no hands

[Tristan Van Berkom]

Hello Desktop Hackers,
  Since as usual I was not available to be barking insanities at
palm trees at GUADEC this year, and also since Javier Jardón made
the amazing contribution of redoing glade.gnome.org[0] for us
in a much more simple and modern way, I was motivated draw out a
roadmap[1] to a very achievable future of Glade.

So, why am I writing to you ?
  I felt it was my responsibility to share with you what is really
bearly in our grasp, but I cannot do for GNOME by my self this year.

To tell you the truth, I think we can provide a development environment
for GNOME that really beats other platforms, I think we can achieve the
level of object class integration available in other modern designer tools
I've seen recently (tools with rigid and restricted platforms such as Xcode's
ObjC or Flash Creator's Action Script), except in our case, we can bundle up
any GObject based UI toolkit and custom widget type in a generic way
using our new introspection framework, most of which is already
cross-platform portable code; and on top of it you can use the language
of your choice (am I missing something here or doesnt that beat
everyone ? I'll let someone else figure out why it costs > 40MB to install
Glade on OSX, Im sure thats just sillyness though).

So, if you are just curious and want to know what kind of nonsense I would
be blabbering to the palm trees this year had I been at GUADEC, give 'er a
read for the hell of it, if it interests you please comment, if there
is interest
in this kind of thing we can try to organize it and make these items happen,
its not all that hard work in the end, personally I have to step back and
work on bugs and regular features unless others step in.

Thanks all for your attention ;-)

Cheers,
        -Tristan

Note, this might come up as a double-post; classic email/ML mismatch sorry.

[0] Many thanks as well to the Nemiver team for letting us use the design,
and Rafael (pachi) Villar Burke for helping us translate it into python.

[1] Ive split the attached document into items on a hypothetical
roadmap for Glade: http://live.gnome.org/Glade/Roadmap
_______________________________________________
gnome-devtools mailing list
gnome-devtools@...
http://mail.gnome.org/mailman/listinfo/gnome-devtools

[Tristan Van Berkom]

On Tue, Jul 21, 2009 at 4:27 PM, Tristan Van Berkom<tvb@...> wrote:
> Hello Desktop Hackers,
>  Since as usual I was not available to be barking insanities at
> palm trees at GUADEC this year, and also since Javier Jardón made
> the amazing contribution of redoing glade.gnome.org[0] for us
> in a much more simple and modern way, I was motivated draw out a
> roadmap[1] to a very achievable future of Glade.

And ofcourse the attached document is...


_______________________________________________
gnome-devtools mailing list
gnome-devtools@...
http://mail.gnome.org/mailman/listinfo/gnome-devtools

[Tristan Van Berkom]

On Tue, Jul 21, 2009 at 4:36 PM, Tristan Van Berkom<tvb@...> wrote:

> On Tue, Jul 21, 2009 at 4:27 PM, Tristan Van Berkom<tvb@...> wrote:
>> Hello Desktop Hackers,
>>  Since as usual I was not available to be barking insanities at
>> palm trees at GUADEC this year, and also since Javier Jardón made
>> the amazing contribution of redoing glade.gnome.org[0] for us
>> in a much more simple and modern way, I was motivated draw out a
>> roadmap[1] to a very achievable future of Glade.
>
> And ofcourse the attached document is...
>

Ok with no shame, I present you the same file with a fancy cute ".txt"
extension
because mail readers can be garbage at most times.

That will be all :)

Cheers,
           -Tristan

1.0 In depth support for custom widgets
=======================================

1.0 Rationale:
==============

Currently Glade supports custom widgets by way of letting the user
introduce a catalog and optional plugin for their custom widgets,
this has been great to allow integration of customized portions of
the UI, easing things like integration of a GstVideoSink or MozView
widget into your application directly, or integration of GTK+ based
toolkits to be run on a kiosk or a hand held device.

After recently being hired to do some work that happened to involve
using IDEs I realized that today that just doesnt cut it.
Simply put: its not important or a challange anymore to integrate a
mozilla or gstreamer widget into the Glade catalog, people want to
derive widget classes from thier interface directly and easily,
not because they want to use an exotic widget... but just because
they can write more encapsulated and reusable code, presumably better
code than when using the currently popular technique of connecting
to signals and playing god with every single element of the UI from
a main application logic object or workspace.

1.1 Implementation (Glade Catalog Updater using GObject Introspection)
======================================================================
The Glade catalog describes a set of GObject types that are to be
mentioned in the Glade palette, up to date this catalog has always
been written by hand and updated by hand - now that we have releases
of gobject-introspection; not only do we have the opportunity of
automating things like updating targettable versions of newly introduced
properties and signals and deprecation data (every GTK+ release I have
to go over the list by hand and mark the "deprecated" and "since" data),
we also have the possibility of generating usable catalog completely
from GIRs with the restriction that we have usable editors for object
classes found in the GIR (object classes that do not derive from GtkWidget,
can only have thier properties and signals setup but not appear in
the workspace currently).

The Catalog updater should respect a simple api such as:

GladeCatalog *glade_catalog_new_from_gir (const gchar *gir_path,
                                          GError     **error);

and also to update catalogs:

void         glade_catalog_update_from_gir (GladeCatalog *catalog,
                                            const gchar *gir_path,
                                            GError     **error);

Then we can either compile a program against the core library or just add
command line options to Glade to create new catalogs or update existing
catalogs with introspection data.

1.2 Features
============
Now assuming we have the frameworks layed out discussed in the previous
section, we can move on to implement fancy features, what we are going
to want to add, we could go about it a few ways with a few UIs, this is what
I have in mind right now:

    * There will be a clean separation between catalogs loaded at init
      time by Glade (installed catalogs or catalogs loaded via the
      GLADE_CATALOG_PATH environment variable).
    * When the user edits a project, every object gets a new attribute in
      the property editor, the "Implementing Class" field.
    * User Implemented classes will be shown in a special portion of the
      palette and will be a part of the project data.
    * A User Implemented class can also optionally be attributed a
      gir by the User
    * If a User Implemented class has introspection data available (i.e.
      it has a valid gir with the "implementing class" name listed and
      parented by the correct ancestor type); then the user can also edit
      any added properties or signals that were found for that class in the GIR.

1.3 GtkBuilder
==============
The way GtkBuilder works we should be able to just work around it,
although it would be nice to tell GtkBuilder that an "Implemented Class"
is assumed to exist and doesnt need to have its catalog version asserted.


2.0 Splitting out the GTK+ dependency
=====================================

2.1 Rationale
=============
Currently we are seeing some interesting toolkits emerging around
GObject and GNOME, Clutter being the obvious first in sight,
also the various cairo based canvases out there. Cutting out the
core properly, probably honing down the api a little as well,
will allow us the final measure of flexibility to build plugins,
editors and frontends completely in Clutter or other GObject using toolkits.

2.2 Implementation
==================
Glade was originally designed for plugability of widgets, and the
option to embed into IDEs, right now we have an almost GTK+ independant
core library in Glade, with a large GTK+ specific backend and a
small frontend using GTK+ to interface with the core. Basically all
that remains to be done is create api to externalize the internal
GTK+ based editors that are provided to edit objects in the core.

This would mean that a base toolkit library would be responsible
for creating the GladeInspector (widget tree), GladeEditor (the main
object property editor), GladeSignalEditor, GladeDesignLayout (the workspace area)
and the GladePalette. These could become interfaces provided by the
core to be implemented by base toolkit plugins (i.e. a hypothetical NBTK
plugin would not have to implement editors, such as the GNOME plugin
inherits most of its functionality from the GTK+ plugin).


3.0 Better signal support
=========================

3.1 Rationale
=============
Over the years with the current implementation of signals througout
libglade years until today, signals in Glade files have never been
useful in serious applications, mostly because you have no real
control on the user data.

3.2 Proposal GtkBuilder side
============================
To fix this I propose we add the "user-data-type" property to
the "signal" tag definition in the GtkBuilder format, allowing for
more types than the base "GObject" type; it should be easy enough
to insert a generic GValue parsing routine, allocated strings and
GBoxed values lifetimes could be attatched to the lifetime of the
instance emitting the signal.

The GtkBuilder format also needs <signal> attribute "swapped" to
indicate whether to swap the user data or not, this must unfortunately
be TRUE by default for "user-data-type"s of GObject or derived
(for backwards compatability reasons).

It would be particularly interesting to add api to GtkBuilder such as:

void gtk_builder_add_symbol (GtkBuilder  *builder,
                             const gchar *symbol_name,
                             gpointer     symbol_location)

This could allow us to add another different attribute to the
signal tag, <signal ...symbol="yes">, and allow the user to provide
named symbols to be passed in as user data at load time.

3.3 Glade side
==============
The Signal editor has forever needed a rewrite.

It will now need to offer control on the user-data-type,
optionally enable user-data field based on if a type is selected, and
also allow control on the "swapped" attribute.

_______________________________________________
gnome-devtools mailing list
gnome-devtools@...
http://mail.gnome.org/mailman/listinfo/gnome-devtools