Re: Glade: big plans with no hands

[Tristan Van Berkom <tvb gnome org>]

On Tue, Jul 21, 2009 at 4:36 PM, Tristan Van Berkom<tvb gnome org> wrote:
> On Tue, Jul 21, 2009 at 4:27 PM, Tristan Van Berkom<tvb gnome org> 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.