I think perhaps the first step would be to change the GtkDrawingArea widget with the similar widget that allows widgets to be placed in the drawing area. I put a TODO note about this on the website, but now cannot find it, and I cannot find the name of the widget in the gtk docs :( But what it said was there was a slight speed penalty, so not to use it unless you needed to place widgets on the drawing area. As machines get faster all the time I expect we usefully do this - it would mean we could place dialogs onto the drawing area instead of using toplevel windows or having fixed boxes where they can appear. Richard On Wed, 2011-05-04 at 21:28 +0100, Richard Shann wrote: > jjbenham> "We would probably need radio button, range widget, file > selector widget, textentry, dropdown box," > > I think you have to start with the containers/vboxes/hboxes and whether > they are to be presented as toplevel windows or within some pre-existing > part of the denemo window. > So you would be passing to C a specification of the types of things that > you wanted creating. This would be a scheme structure (a list of lists > of lists... of widget types) > > And C would then construct a return value which would be a similarly > structured list where the widget's value as input by the user would be > held. (Many widgets, e.g. the containers would have no user-provided > value, while a file selector widget would return the filename selected > etc). > > Nils and I continued the discussion on irc - the above is to some extent > the product of the conversation the transcript of which I give below > Richard > ... return values would need to be specified too, but it is less clear > to me, without actually tackling it how that would be done - how you > would return data that widgets acquire from the user. > <rshann> It is a fair sized project, with most of the work being to keep > it small but useful. > <Nils^> rshann: how is it different what data the dialogs return > compared to the current state? > <rshann> well we just have a single piece of data being returned, but we > will want to pack several widgets getting various values from the user > <Nils^> except from forcing the scheme scripter to use a scheme data > structure such as pairs and list there is a scheme modules do handle > multiple return values > <Nils^> but maybe its not so bad to keep return values clean allowing > only one scheme data structure > <rshann> yes, that is what I had in mind. > <Nils^> thus a gui window is just another function. one function, one > return value. > <rshann> In C you then have to construct this scheme list > <rshann> yes, the return value is a list (ie general structure) > <rshann> its contents would reflect the widget that had been sent (the > widget itself being sent as a list of lists of widgets) > <Nils^> you mean each widget returns its own part of a return list? > <rshann> the structure of the list representing the spatial structure of > the widgets (which widgets are inside which, and whether horizontally or > vertically) > <rshann> they will be doing that inside the C code, the C code has to > assemble all the return values and put them back into a scheme structure > <Nils^> this sounds logical, although I don't think it is needed in > daily scripting work. But better to have it > <rshann> Well, I think it might be quite serious work > <rshann> there are c-functions for each scheme function > <rshann> so I suspect it can all be done (creating complex scheme > structures using C) > <rshann> but I don't think it is trivial > <Nils^> I don't think its trivial either. But that does not make it less > important > > > > _______________________________________________ > Denemo-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/denemo-devel
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
