Re: [Goe-dev] Replies....

[Jay M. <ja...@ke...>]

On Wed, 20 Jun 2001 16:34:02 -0700 (MST), <rb...@ce...> said:
>
>  After reviewing your comments and meditating upon it a bit I think that I
>  am going to make a semi-global event list. But I haven't done it yet.
 i commented on this below....

>  The only thing that doesn't happen now (or when I do the global ones) is
>  part D. I'll expand upon that another time.
 that isn't really necessary for testing just yet, and it seems simple enough
to implemented.
  
>  Indeed, one of the thoughts in the back of my mind is that perl is the
>  glue, and it should be so flexable that it should be easy to replace even
>  at the very core. Or even just pieces of it should be replacable.
>  
 that is definately what i was getting at!

>
>  And make it as transparent as possible. If the programmer doesn't need to
>  see the wrapper code they shouldn't have to.
>  
 agreed

>
>  Yes, but at the same time avoiding bloatware. No need to have a full
>  embeded emailer (if we wanted a simple pop up would work, but we could
>  also just call their email client with some defaults for sending it to the
>  right place). And communicating with other programs for chat instead of
>  being too embeded. Or... just making these things optional :)
>  
 exactly, we could do something similar to how browser to mime types (or even
use them) and then have ways of saying 'run this program: ' or 'run this
function:' (although by function it would be more like, call this event -
because we want to be going with the event scheme - its more flexible anyways)
- so that way we have a base to build on (MIME) - a way to extend GOE to bloat
ware (calling events) - but the events may even call other programs anyway
(after formatting input maybe?) - i dunno, but do you get my drift?
 it would be really neat, and would really a whole lot on the event mechanism -
so it would be important to get that solid and stable and in a really good
state.

>  This convinced me of a more-global list. By that I mean that I might make
>  it a class-variable in Goe::Object, which everything inherits from,
>  instead of a true global. You can look at what I already did for the local
>  event version (in Goe::Browser2::Base) and see that I already do a lovely
>  lookup table.
 that seems like a good idea, because that way things that cant get events wont
be able to change it at all. i checked out the lookup table of the current cvs
and i had two questions -
 a) can the callbacks/events be passed arguments? that seems like it would a
good idea. something to design the new one with in mind - the way i see this
being worked around now is the a variable is written to the object's structure
and then the callback grabs it - this is all well until you want that data to
be available to other objects... unless you have them request it from the
object . i dont know what you think is the best way to go about it - either way
will work just about the same (passing to the function is more flexible, but
having the function request from the object follows more OO standards (although
requires functions to be writtten) - i dunno)
 b) it doesnt appear that the callbacks/events can signal passing other events
(either to the same or a different object) - unless they call a function which
would then call the event. i think that this could be useful - but it wouldnot
have to be implemented on it's own. you just write a callback function that can
be passed an object and an event and it hands it that - so that way it
accomplishes the same goal without extra logic/data overhead.

>  Browser2 is to the "browsing" stage, but cannot commit changes or other
>  essential things (like adding methods and such), but it is fun to look at
>  anyway. Feel free to add anything you like, I don't think I'm going to
>  work on it this evening at all anyway. Have fun :)
 i dig completely. i think ill start thinking about the best way to go about
adding stuff.....

some random comments -
 1) you may have noticed i end alot of sentences/paragraphs with "i dunno" -
this is because it is just my rambling brain thinking out loud about possible
ideas. the way i see it the more ideas we generate, whether good or bad, will
only provoke more ideas (or sharpening of current ones) - and the more ideas
floating around the more likely hood that there will be some real rad ones!
 2) something that i do alot when i write programs in spare time and at work is
i write a generlized engine/platform/other_buzzword that has data (normally
formatted in XML.... its a buzzword, yes, but its convient) - that will
instruct the engine on how to operate. i can imagine that making goe along
those lines would be a really interesting exercise/experiment - dream with me
now....
 <ui>
  .... gui objects ....
  <object>
   <type>button</type>
   <event>save_current_file</event>
  </object>
  .... gui objects ....
 </ui>

 <event>
  <id>save_current_file</id>
  <callback>save</callback>
  <arg>#(current_file)</arg>
 </event>

 ------------
  subnote: #(var) is just a short hand/funkd up way of referring to some sort
of variable.... just for quick demo-ing
  notes - is this a good idea? maybe..... the UI description may be a little
over the top - but getting most of the data/description out of the program into
the configuration can only do good for the configurability of the system. the
only thing it can really hurt is developement time and initilization execution
- but it will enable someone to take the goe system and write something ontop
of it more easily....
 just an idea!

Browser2 is cool and this event stuff and other ideas are rad. nice job.
im out like a light

- je'

-- 
Jay McCarthy <ja...@ke...>
aim / aim \ irc
rasarasda / emontapartimejob / feelicks 
www.brunswickrecords.org/~jay/

13~[3357939278861]!
-|[PFDCKHPYVHMJL]|-
}~[897HK8FL3VCY9}~[