From: Tom Sawyer Date: 2002-07-20T21:47:14+09:00 Subject: GUI's and the Rouge, Part 1 i just discovered Rouge. a very ambitious project to say the least. it is interesting that i have just now come across Rouge as i have just given up on effectivly attempting to do the very same things that Rouge hopes to accomplish. it is disappointing. i put numerous hours into the project and personally am very saddened that i felt that i must abondon it. but i came to a number of realizations that make such a project, while not impossible, exteremly difficult, and doubtfully worth the effort. for starters there is the GCF problem. to be truly effective in the attempt to offer native support for a variety of platforms (QT, GTK+, win32, Cocoa, to name the major 4) the Greatest Common Factor must be the base line for the widget set. this means that any widget one kit supports that the others do not, a "composite" widget must be created for each out of available widgets to achieve the same functionality. in effect then you end up with a huge number of widgets to create and maintain. were talking about a very very large project! secondly, one then must consider cross-functionality. if widget A in toolkit X does not function the same as widget A-ish in toolkit Y, then how will one map the two? at this level it will probably be very difficult, most likely impossible, to "composite-out" excatly the same functionality. thus some feature of widget A and/or A-ish are bound to be unavailable. even if you deal with these first two daunting tasks, you then come to the issue of bindings (this is actually related to the second problem but deserves its own mention). each toolkit exposes its bindings differently. a perfect mapping will again be impossible, but worse the code complexity of creating a single binding model (the controller?) that then effects the underlying native binding model in a consitent manner will be a major coding endeavor, if it is even possible. again somethings are goign to have to left out. this alone is a serious project in and of itself! finally, in my opinion, the most ruby-esque/POLS gui should be able to mixin, such that the mixed object automagically interfaces with the gui. that would be THE feature of a dream ruby gui. but it turns out to be all but impossible. first, because most gui toolkits take control of execution (a la Tk.mainloop) all subsequent processing has to be handed over via the passing of pre-built closure procs. this simply make for a lack lust design neccessity. your subsequent applications are going to be full of a lot of ugly code. but what makes the hope of automagical communication between ruby object and gui even more daunting is the fact the =() is not a ruby method or to be more proper, there isn't a determinate syntatical distinction between assigning a variable which becomes a new object versus simply replacing the value of that object. there is no way then to callback on reassignment. thus you are forced to create seperate constructs for effecting your object's instances alongside the gui's. so that is my assesment of the hopes and dreams of the rouge project. while not impossible, it is a task of such huge proportion that it would take many many man hours to complete, and even then it will not be ideal. its too bad, such a thing as Rouge would be a developers dream indeed. but do not give up hope! i will follow up this post later with what i think may be a much better approach... ~transami -- ~transami _(")_ dobee dobee do... \v/ ^ ^