[Glade-users] Generating classes, but no instantiation in glade--

[khuisman nortelnetworks com (Ken Huisman)]

Why not change your UI a bit and have each of the configurations
be a subtree on your tree and then on the right only show things
at the appropriate context, i.e.:

-USB Mouse          
  |
   - config 1

-USB Camera
  |
   - config 1
   - config 2


and then in your window on the right, if they
click on config 1 in the tree they would see the
config related info for config 1
and if they had clicked on the usb device they
would only see the usb level info

you could do the same with the endpoints.

this would make your window on the right side of your
screen much simpler, and the tree would do what a tree does
best - show the hierarchy of the data.

just a thought...would that work for you?

Ken


Ansel Sermersheim wrote:
> I've been getting up to speed on glade and glade-- by playing around
> with writing a utility to enumerate the USB bus and display it
> spiffily.  (I had some old C++ code sitting around that parses
> /proc/bus/usb/devices under Linux).
>
> I've run into a bit of a design difficulty.  I have a paned window.
> On the left is a DeviceTree (derived from Tree), displaying the
> current USB topology.  (same as e.g. windows device manager).  This is
> easy - I had glade-- generate it as a seperate class, and wrote some
> bridge code in the initialisation to populate it.
>
> On the right, I have a DeviceFrame (derived from Frame), with Labels
> inside it displaying data about the currently selected device.  Now it
> gets tricky.  A single device may have one or more Configurations,
> each of which has one or more Endpoints.  So, if I click on a simple
> device, say, a mouse, I should see something like this:
>
> +-USB Mouse------------+
> | Vendor ID: xxxx      |
> | Product ID: xxxx     |
> | ...                  |
> |                      |
> | +-Config 1---------+ |
> | | Power=11mA       | |
> | |                  | |
> | |+-Endpoint 1-----+| |
> | || Type: xxxx     || |
> | |+----------------+| |
> | +------------------+ |
> +----------------------+
>
> Whereas, if I click on something like a USB Camera, I want something
> more like this:
>
> +-USB Camera-----------+
> | Vendor ID: xxxx      |
> | Product ID: xxxx     |
> | ...                  |
> |                      |
> | +-Config 1---------+ |
> | | Power=55mA       | |
> | |                  | |
> | |+-Endpoint 1-----+| |
> | || Type: xxxx     || |
> | |+----------------+| |
> | |+-Endpoint 2-----+| |
> | || Type: xxxx     || |
> | |+----------------+| |
> | +------------------+ |
> | +-Config 2---------+ |
> | | Power=15mA       | |
> | |                  | |
> | |+-Endpoint 1-----+| |
> | || Type: xxxx     || |
> | |+----------------+| |
> | +------------------+ |
> +----------------------+
>
> A sensible way of doing this seems to be to create each level of
> frames as a seperate class.  Give DeviceFrame a vector<ConfigFrame *>,
> and ConfigFrame a vector<EndpointFrame *>, and have them dynamically
> populate/prune these lists when a device is selected. (Obviously, each
> of them will get an hbox as well to which the children will be added.)
>
> (If there's a simpler, cleaner, more sensible way to do this, please
> let me know.)
>
> However, this doesn't work.  No matter what I try, I can't get glade--
> to _not_ generate code that does e.g.
>
> ConfigFrame * configframe;
> configframe = manage(new ConfigFrame);
> configframe->show();
>
> in DeviceFrame_glade.cc thus leaving me with an undesired child that I
> then have to destroy if I want to be able to add my own widgets in the
> space.
>
> I'm looking for a way to say 'Generate the class for this widget, but
> do _not_ instantiate or reference it from the parent widget, because
> I'll do it at runtime from derived-class code.'
>
> The only way I can get this to stop is if I create a new top-level
> window, and put the ConfigFrame in it.  Then since it is no longer a
> child of the DeviceFrame, the DeviceFrame will not attempt to
> instantiate one.  However, this is kind of clunky from a GUI design
> standpoint.
>
> This leads to two top-level windows that are never used, because they
> only serve to give me somewhere other than the current window in which
> to put a child window I want to generate classes for.  In this project
> it's not too bad, because I've just got one main window & an about
> box, but in a larger application it could get very confusing.
>
> If I were to try to add this to glade, where do I start looking?  I
> assume I'll have to add support for generating the option tag in glade
> proper, and have glade-- look for that tag and avoid generating the
> corresponding code.  If someone could point me to the relevant bits of
> code, I'd be most obliged.
>
> Thanks,
> -Ansel
> --
>
> _______________________________________________
> Glade-users maillist  -  Glade-users helixcode com
> http://lists.helixcode.com/mailman/listinfo/glade-users