Re: RAD, invisible components
- From: Stephan Bayer <stephan bayer web de>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: RAD, invisible components
- Date: Mon, 20 Oct 2003 22:12:48 +0200
Am Mon, den 20.10.2003 schrieb Owen Taylor um 21:34:
> On Mon, 2003-10-20 at 15:17, Stephan Bayer wrote:
> > Ok first,
> > the "improvements" i will discuss are only usefull for GUI builder like
> > Glade.
> >
> > In Tools like Borland Delphi etc. and now in Visual Studio.net there is
> > a partition in visual components and none visual components. In gtk and
> > Galde we have support for the visual part.
> > But in Glade is no support for none visual components (or i'm wrong),
> > like a database table connection or something like a socket component.
> > In the wide or near feature it would be nice to have such components and
> > this feature in Glade.
> > My opinion is that this is a big feature wich mainstream development
> > needs.
> >
> > I think we have two possible solutions for this.
> >
> > Solution one:
> > Gtk itself doesn't need this feature, but library's depending and
> > extending gtk maybe need this. So it would be nice if gtk includes a
> > class for this. Library use this class to derive from this and Glade
> > know that this is a none visual component. The component only needs a
> > property for an icon which the GUI builder display.
> > This solution would be the object orient way.
>
> There is no need for GTK+ declare something a non-visual component.
> If a GObject derives from GtkWidget, it is a visual component,
> and can be handled by code that knows how to handle GtkWidgets
>
> If it *doesn't* derive from GtkWidget, it is either:
>
> - A non-visual component
> - A visual component that needs special handling (think
> GnomeCanvasItem)
Thats right. But you mention it that glade at the moment only support
GtkWidget classes. Thats the nice at solution one, we do not need to
extend the fuctions if we derive from GtkWidget
>
> > Solution two:
> > We only extend Glade.
> > We add the posibility to add none visual components, by declaring this
> > in the glade3 xml files or so.
> > If this mailing list comes to the solution this would be the way we
> > should go, i'm then inform the glade list to implement such a feature.
>
> I'm sure they'll be delighted to learn of your interest in implementing
> such a thing.
>
> I don't think generic handling of non-visual components is all that
> useful, though there is clearly need in Glade for GtkTreeModel,
> GtkTreeViewColumn, GtkSizeGroup, etc.
mhhh ok,
GtkTreeViewColumn is not direct a none visual component.
In Delphi and other GUI builder this is implemented as a property expert
or something like this.
It's a editor which embede in the property editor and works with a
special property type.
None visual components have a list of properties like normal visual
components.
I would explain the advantages of none visual components.
e.g. you have a component wich handles sockets (client) connections.
You setup in glade the properties:
adresse = 192.168.0.8
port = 4638
type = tcp
You connect the event:
on-receive
And you only code the signal function on_receive the rest is handled by
the component.
Or another example. You have a datasource provider as a none visual
component. And you connect your entry's and other visual components with
this none visual component. From now on the entry's show the current
selected Datasource record.
Ok this is the feature for gtk, gnome and glade.
It would be nice if we reach this target.
If there are understanding problems about the concept or the need to
show how it works under delphi i could provide informations.
> There does need to be some improvements in libglade's interfaces to
> handle this, since it currently always returns a GtkWidget *.
>
> Regards,
> Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]