Re: Re: [Fwd: Questions on goo / samurui]

Andrew Sutherland <[email protected]> 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