denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] scheme-gtk discussion


From: Richard Shann
Subject: Re: [Denemo-devel] scheme-gtk discussion
Date: Thu, 05 May 2011 10:06:50 +0100

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]