[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [Fwd: Questions on goo / samurui]
Andrew Sutherland <sombrero@ai.mit.edu> schrieb am 12.10.02 00:43:42:
> (Note: This is being copied to the list for all to "enjoy")
>
> No need to worry about bothering me! I'm quite happy that anyone is
> trying to use SamurUI at all. I apologize for not responding; I
> actually read it and then started to talk to Jonathan about what you
> said, then I promptly got distracted by something and ran off. If I
> fail to respond in the future, feel free to remind me as many times as
> needed :)
>
> Your request to be able to invoke Goo with some command-line arguments
> is reasonable; I'll see what I can do to get Jonathan to add that.
> However, in the meantime, you can pipe some stuff into Goo to
> accomplish what you desire. Specifically, you would do the following:
>
> echo "(use mystyff/test/foo)" | ./g2c
>
> We are hoping to clean up the development process for UI's so that
> quitting isn't required (or at least recommended) so much.
>
> I don't think (present "Hello World") is going to work anytime soon.
> To be honest, I'm not sure why it doesn't work; I think the problem is
> that it is assuming that your presented object will have an
> interface-view (iview) associated with it, but my quick perusal of the
> code prompted by your e-mail suggested it should not have an issue
> with that. In general, however, the SamurUI strategy is to bind
> things through getters and setters, which would preclude passing in
> constants in most cases. I agree it would make a cute hello-world,
> but I'm generally wary of languages/UI's claiming everything important
> can be done in one line of code (or less!).
>
> All of your 4 "How can I's" are quite reasonable, but I'm going to
> turn all of them around again and ask you what you're trying to do,
> rather than just assume that you should be able to directly call all
> of those things.
>
> SamurUI has a number of layers going on:
>
> 1) Traditional GUI Layer. Constructs windows, buttons, etc. Binds
> callbacks to buttons etc.
>
> 2) SamurUI the magic factory with default bindings.
>
> Most of the questions you ask seem to operate in the #1 space, which
> I'm only really building because I need it to do my artsy, dubiously
> useful #2 stuff. Basically, I guess I'm trying to reinvent CLIM
> without knowing all the stuff CLIM did, and certainly without trying
> to put in the same level of effort. Addressing your specific points:
>
> 1) The only reason I could see to modify a label is if you were using
> it as a feedback mechanism. For example, a label in a status-bar,
> etc. Running with my current design style, it seems that I should
> internalize status/feedback mechanisms. The mechanism could work
> in a similar fashion to the way master/slave communication works.
> Specifically, you would create a feedback object (ex: progress bar,
> label, etc.) by providing the default feedback 0 or "" I suppose,
> and then giving the communications channel it should use a name.
> When you create an object that presumably will have or emit
> feedback, you wrap it with a communications channel to use. A
> rudimentary example:
>
> (imethod <app> copy-something me ...
> ...
> (emit-status (/ i 100.0))
> )
>
> (iview <app>
> (columns "Copy Progress: " (slave-status 0.0 copy-progress))
> (master-status copy-something)
> )
>
> 2) So I actually should create these at least for the thing GTK
> wrapping first, but let's get to how these fit into the SamurUI
> world. For files, colors, and fonts, it seems that what should be
> happening is that I should be defining default bindings that
> trigger these, as well as base classes as needed. So I would
> create a <document-file> class, that would bind to a text-box with
> a "browse" button that brings up the file dialog. The actual
> opening and saving would be done by you... you'd just have the
> filename. I'll cave and say that we should have a way to trigger
> the dialog though, which would probably be just the think GTK
> wrapping way. Colors and fonts would be same deal... there would
> be a default binding for displayed color and font objects, but
> again, there will be direct methods you can call if you just want a
> font or color returned.
>
> 3) There's obviously a need for this, but I would appreciate knowing
> what it is you want to do with these. You can probably (present
> ...) multiple times right now and get multiple top level windows.
> In fact, you can probably present while it's running and create new
> ones on the fly. A new modal-present could probably be introduced
> which would work similarly to present, except of course the window
> that appears would be modal. (And could be called in a method, or
> what have you.)
>
> 4) Again, there needs to be a way to do this with the thin GTK
> wrapping which will be done in a pseudo-getter-setter technique,
> but the SamurUI proper solution would ideally not involve this kind
> of procedural GUI control. I suppose the way I see this going is
> to use the constraints interface (which is currently supposed to
> let you bound spin-boxes for numbers) to let you specify that a
> given control should only be active under certain situations. That
> would presumably cover the case you have in mind. Of course, I
> want to avoid making the "elegant" approach much harder and
> laborious a process to use than just programatically calling (set
> (gui-enabled bob) #f). Of course, a little extra work might be in
> order, given that properly stating the constraints that express
> whether or not a control should be enabled can save you big, and
> works a lot better than having you code enabling disabling code all
> over the place. (And it's good abstraction too I suppose; keeping
> the interface code in the (rapidly growing) interface-view.)
>
> Er, so I think that covers it all. I should note that I'm probably
> not going to be able to get to most of these things for 1.5 - 2 weeks,
> and that you should feel free to implement anything you want and send
> it to me. I probably will be somewhat fussy about things I put in the
> 'fancy' SamurUI proper, but anything that adds functionality will
> definitely go in the thin GTK wrapping. (Which sounds like what you
> are looking for primarily anyways.)
>
Not necessarily. These are just the things I'm looking for in a gui library :-)
It's just that it is more easy to think in convential gui terms instead of thinking
of the conceptually easier but also more unusual samurui ways :-)
By the way at the moment I haven't got Internet at home though it will maybe take me some more time to answer / react to your emails.
Cheers
Bene
________________________________________________________________
Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr!
Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13