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

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?


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);

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

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

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.


Glade-users maillist  -  Glade-users helixcode com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]