Re: [Fwd: Questions on goo / samurui]

[Andrew Sutherland <sombrero@xxxxxxxxxx>]

(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.)

Andrew
sombrero@ai.mit.edu