MyOODB seems to be a one-guy project for small applications. No
documentation yet, it is kind of learning by examples and/or reading
the source code.
It seems to me that dbfo (another java oodb) seems more reliable. It
has a company behind it, has some documentation and it seems that I
don't need to modify my classes in order to use it. Although it is not
embedded in an application server like zodb, it doesn´t seem hard to
use. I will start experimenting with it.
Sergio
On Tue, Nov 17, 2009 at 7:19 AM, Tim Cook
<timothywayne.cook@xxxxxxxxx> wrote:
Hi All,
I wanted to share the very encouraging response I received
from the
Glade list. Sergio, I hope your investigation of MyOODB is
going as
well.
Cheers,
Tim
-------- Forwarded Message --------
From: Tristan Van Berkom <tristan.van.berkom@xxxxxxxxx>
Reply-to: tristan.van.berkom@xxxxxxxxx
To: timothywayne.cook@xxxxxxxxx
Cc: Glade Users <glade-users@xxxxxxxxxxxxxxxx>
Subject: Re: [Glade-users] Abusing Glade? :-)
Date: Tue, 17 Nov 2009 00:22:23 -0200
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
--
***************************************************************
Timothy Cook, MSc
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == (upon request)
Academic.Edu Profile: http://uff.academia.edu/TimothyCook
You may get my Public GPG key from popular keyservers or
from this link http://timothywayne.cook.googlepages.com/home
