On Fri, 19 Oct 2007 16:45:16 -0400
DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > Right now the code is still a bit rough and only the GTK hid
> > supports GUI from resource files.
>
> "only gtk" is bad. A solution that doesn't work with all GUI HIDs is
> not useful.
>
That's the current state right now, nothing is finished yet. However, lesstif
and text-mode happily ignore these resources, so you'll lose no functionality
right now.
> Now, if you made that resource part of gpcb-menu.res, and made it
> OPTIONAL, that would be a bonus for gtk without interfering with
> anything else (or making it difficult to add exporters without having
> to edit every single GUI out there).
>
I can't see why it would be logical to embed a layout definition for a
particular export plugin into the main GTK menu definition.
Adding a layout definition in a resource is completely optional, so if one
can't be bothered to add one someone else can.
> > Layouts can be made using vertical boxes, horizontal boxes, tables
> > and frames. It shouldn't be too difficult to implement notebooks,
> > but I saw no use for those right now.
>
> IIRC we've worked on this type of problem before. A better solution
> is to just put some hints in the attribute list (like a grouping tag,
> or a column split tag) and let the GUI worry about how to present it.
> Your .res file, for example, assumes GTK - Motif doesn't have the
> concept of a "labelled box", for example.
>
When I started working on this I thought of that too, but I discarded it due to
lack of flexibility, i.e. wrt listing command line options. It would not be
necessarily logical to list command line options the same way as they are
listed in a graphical layout.
I would have to dive into Lesstif to be able to understand the different
approaches of both toolkits, but there must be some way to combine both in one
definition.
> And the way to put space between things in resource files is to put a
> thing there, like we use "-" for separators you could use " " for a
> gap.
>
Could you please clarify? Instead of using a padding attribute?
> You could reduce the processing by using unnamed resources:
>
> hbox1 = {
> type=HBox
> test1 = {
> type=VBox
> padding=8
> vbox3 = {
> type=VBox
>
> {HBox
> {VBox
> padding=8
> {VBox
>
>
> or use well-known names:
>
> hbox = {
> vbox = {
> padding=8
> vbox = {
>
> Resources don't have to have unique names.
>
Ok, will look into that, seems like less typing and easier parsing, I like that.
> Also, you can convert resources to .h files (we do this for
> pcb-menu.res) and embed them into the program itself.
>
> You shouldn't need the type= as the attribute itself knows its type.
>
>
> _______________________________________________
> geda-dev mailing list
> [email protected]
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
