mlhim-specs-dev team mailing list archive
-
mlhim-specs-dev team
-
Mailing list archive
-
Message #00010
[Blueprint cdd-overview] CDD Design Overview
Blueprint changed by Tim Cook:
Whiteboard changed:
- On Mon, Nov 16, 2009 at 12:53 PM, Tim Cook <timothywayne.cook@xxxxxxxxx> wrote:
- > Hi All,
- >
- > For those that may have built their own widgets and added them to Glade
- > I'd like to ask a question.
- >
- > I want to use the Glade machinery to allow users to build what I call
- > constraint definitions against a well defined reference model. There
- > will only be about 30 or so widgets and most of them are simply
- > adaptations of existing widgets. Containers, trees, lists, text boxes,
- > etc. but of course all the properties/constraints are different
- > (actually simpler than in Glade).
- >
- > So I would like to hide/remove the existing Glade widgets and leave only
- > my two libraries visible. Then in the XML I will write the names of the
- > classes from the reference model as well as modify all the property
- > settings according to each class as needed.
- >
- > So why do this? Well, it gives me a great starting point for people
- > without knowledge of a complex system to be able to put components
- > together in a way that makes sense to them in their domain. Gives me a
- > generic XML output that I can use to build classes for a variety of
- > programming languages that can be executed against this reference model
- > in each of those languages.
- >
- > Here is a (non-sensical) modified XML file just showing how I envision
- > the object (class) names being changed to match the reference model. I
- > didn't bother with the property names but you can imaging that they will
- > be modified extensively as well.
- >
- > I would appreciate any thoughts/commets/feedback on this approach.
-
- Hi,
- First of all, everything you want to do should be quite simple and require
- no modifications to Glade, except hiding the existing catalogs.
-
- Glade installs usually with at least the GTK+ catalog - and while practically
- speaking, you dont need to display this catalog in the palette, you do need
- the GTK+ catalog to be installed to do useful things with GTK+ derived objects.
-
- Basically, if you havent yet looked into the reference docs, the idea is that
- every catalog provides an adaptor class for any object that the catalog wants
- to introduce to the Glade runtime - so for instance, to leverage the code
- that does Drag/Resize in the GtkTable widget, you will want to derive from
- the GladeWidgetAdaptor that was subclassed for GtkTable.
-
- So I would suggest you start by creating your catalog with your GTK+ derived
- widgets and depend on the 'gtk+' catalog - when you are finished that part,
- which may only imply declaring the object types and disableing/hiding some
- properties, or could imply providing some of your own custom editing widgets
- (i.e. the property editor is subclassable and allows you to present
- the information
- differently than just flat properties, the class adaptor provides a mechanism
- to create an editor on behalf of the class)...
-
- Anyway that would be the juice of your work, hiding the installed GTK+ catalog
- from the palette could be a feature you maintain as a downstream hack/patch
- against Glade, or if its of any real use to others we could even develop some
- mechanism in Glade to hide widgets from catalog dependencies.
-
- Actually, you could even probably just remove the
- <glade-widget-class-ref> entries
- and <glade-widget-group> entries in the GTK+ catalog, which would result in the
- types getting properly introduced into the runtime, but no references
- to the widgets
- from the palette.
-
- Have fun :)
-
- Cheers,
- -Tristan
--
CDD Design Overview
https://blueprints.launchpad.net/cdd/+spec/cdd-overview