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

[<rb...@ce...>]

On Mon, 18 Jun 2001, Jay McCarthy wrote:

|  i probably just seemed to load faster because is it less to load and all.
| about the event passing - i havent really looked at the code , just the debug
| messages - and what it appears to me it does is.... in base packages you've
| defined handlers for certain events, these events are called by actions in the
| UI. i think this is really cool because it does a few things -
|  A) simple, ui independant feature base. a gtk ui and a curses ui can call the
| same event just as easily - that will be really cool for having it run in
| different environments
|  B) it also allows some sort of "server" which recieves events from the client
| UI programs - either throughout a local machine or on a network - this would
| all stuff like - file locking and multi site live developement and maybe other
| cool ideas like that
|  C) preferably events will be easy to define, so by just writing a new event
| handler you can add functionality to the program - and since the backend
| handles all events the same GOE could be expanded to the stars and it wouldn't
| care.
|  D) users could redefine which events get called by various UI operations -
| from things like redefining what key Copies to redefining how the open file
| button works - or rather adding a new menu/button item and defining the event
| that gets called
|  I dont know if this is how events work, but if it isnt maybe their current
| implementation can be expanded to fit that idea in somehow.

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.

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.

|  speaking of playing nice - i think we should design GOE with the ideals of
| expandabilty and user freedom built into everything - i'd like to think of GOE
| more as a developement/organization environment/platform and our perl-ish stuff
| is just one way to implement it and utilize the structure it defines.
| everything should be easy to replace or extend in anyway. although i dont
| aspire to be a webbrowser/mail/news/coffee maker like EMACS - they still have
| the right idea of putting the power in the user with internal programing and
| what not

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.

|  the intelligence i think is the most vital part - we can offer quick 'skeleton
| functions' for interacting with other languages, but it may also be useful to
| make some sort of "wizard"-ish thing that will guide a long a user and either
| let them select a function/object to call/instantiate or browser a library and
| pick something out and also allow to write the function right there - then once
| the user input part is finished you just click generate code and you get some
| quick wrapper code - i think that would be cool and useful in lots of
| situations - and if it were done right it would be easy to add new supported
| languages and what not....

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

|  i agree that multilingual dev/imp is a great way to go. i'd like to rephrase
| my thoughts on the OO stuff - what i was really getting at was that there would
| supplied (and a way to write) parsers for any given language which would look
| at the structure of the code and organize it in anyway that the
| user/parser_writer saw fit - examples are inheritance tracking, break down of
| functions, collapsable if/while/for/case blocks (like a lot of windows editors
| have, but i haven't seen a *nix editor with), or maybe a way to build a
| tree/map/graph of all the functions a function calls so that you can visually
| see how a program will interact with the rest of it.
|  i want goe to help those who are lazy or just unorganzied understand their
| programs better and perhaps have a more efficient way to write them with the
| "big picture" in mind - without having to do all that breakup/visualization by
| hand or symbolically.

Yes.

|  i agree, it really gives you a chance to think of everything you could
| possible want done for you when you were organizing a software project. one
| thing i think might be cool as "module" would be associating email addresses
| with objects/files/projects/functions so that an email address of the
| maintainer of a class (stored in some sort of metadata) can be emailed simply
| with right click->email maintainer - maybe even have the program/test run on
| the aspect of the project and send off a bug report formatted in some special
| wayu - i think that would be really neat. and if you wanted to expand on that
| idea, you could have some sort of database/messageboard associated with a
| project so that people/users/developers could comment on parts of the program
| right as they were writing code/debugging it/running it - right from the same
| window - that may be a cool thing to play with

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 :)

|  i definately think it would be important to draw from other people as much as
| possible and allow hooks for others to intergrate GOE into their own projects -
| if not only because it would take to long to reimplement some stuff but also
| because it would be an easy feat if the intergration system was designed in the
| best way possible. (i support fully the vim idea, btw - Vi rucks)

BTW I need to change all the comments that say it is GPL to say it is
licensed like perl (dual). Just a note to self.

|  i can't wait to see it once it's in the cvs repository

Its in there now :)

|  on the event chaining scheme you talked about.....
| A) i agree that is is really good because objects that dont need an event dont
| hear about them - however, does this imply that an event is only sent to one
| object at any level in the heirarchy? obviously it goes to multiple as it
| travels down the chain but can it go to more than one from a given point?
| B) i dont know how this would support the idea that i mentioned earlier about
| events... this is more like a functions says what it wants to look for an those
| events are generated up the chain - and then something else starts the event -
| while this is good it makes it harder to probe and find out what all the events
| that are being handled are, you would have to query every object in the system
| - but maybe thats what we want? you say you dont like a global list, but i
| think maybe a global list would be useful because it would be a single place to
| look, a single place to modify, and you could have it echo the event to any
| situation where it is sent to.
|  the global list could be implemented as some sort of "lookup" table where you
| have on one side the event and on the other side... events that it triggers and
| functions that should get called when the event happens, ie....
|  open_button_push -> file selection dialog() , new code editor()
|  save -> write_to_fs() , update_cvs(), structure_changed!
|  structure_changed -> reparse_project()
|  make sense? do you think that that is unneccessary and able to be down with
| the event scheme you have currently?

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.

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 :)

--Brock