RE: [rgui-dev] project proposal

[Curt Hibbs]

Thanks for the extensive post. Let me digest this first, and then I will
respond.

Curt

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of
> Thorsten Roggendorf
> Sent: Thursday, December 12, 2002 5:07 AM
> To: address@hidden; address@hidden
> Subject: [rgui-dev] project proposal
>
>
> Hi,
>
> I'd like to propose thinking about a project, that is somehow related to
> GUItopia. This Email consists of six parts:
> - Where did I get the idea?
> - What does it have to do with GUItopia?
> - What's the idea now? What's the potential?
> - First ideas on how to approach the problem
> - Pitfalls, Gotchas and other Maladies
> - closing remarks
>
>
> Where did I get the idea?
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> I am working on a simulation of six legged walking machine in a
> university. The simulation is parameter file driven. For some time now
> (about two years) I am thinking about adding a GUI to the app. I did not
> really have the time or the motivation to start coding on it though.
> About two weeks ago, I started coding. The thing that got me started was
> the first release of the ruby bindings for the gnome2 stuff which
> intrigued me. My gui will heavily depend on the gnome2-canvas.
> I started digging through the heavily loaded api and started creating my
> own meta-api for common tasks that I would face, especially regarding
> the canvas: making canvas-items interactively movable and furnishing
> them with popup-menues and mouse over tooltips.
> My design goal was maximal simplicity of usage. I wanted all that
> overhead flexibility taken from me and put in useful defaults. The
> ultimate aim for something like that would be to preserve all the
> flexibility but don't show it to client programmers if they don't need
> it.
> When I had some usable code I asked on the ruby-gnome2 list if they had
> a place where such wrappers could be thrown - a kind of toolbox for
> beginners or RAD. They pointed me to GUItopia and locana.
>
>
> What does it have to do with GUItopia?
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I looked at GUItopia and was stunned. The interface design is of amazing
> beauty and functionality. The use of mixin modules "reminded" me of how
> I add popup, tooltip and movable functionality to my canvas-items.
> GUItopia shines by having a couple of interface-concepts unified and put
> into the big picture in a consistent manner. I think the potential of
> wrappers like this is enormous. You got the interface right and that's
> why I'm writing to you. I think, that idea might be yet extendable,
> though.
>
>
> What's the idea now? What's the potential?
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Today every bozo can code a gui when he brings some persistence and
> chooses the right toolkit for his skills. A couple of years ago this was
> quite different. Gui programming was in the arcane realm of advanced
> programmers. GUItopia tries to bring gui programming to yet more people,
> which in itself is a great feat.
> But todays coding problems have moved on from guis. All major desktop
> environments that are here to last feature a couple of things: gui
> toolkits, registry like fascilities for parameter storage *and*
> components (COM, bonobo ...). Successful projects on all Desktop
> environments usually use the whole power of these features. But
> especially the components still remain arcane arts. I don't think that
> has to be this way.
> Ruby does have the potential of bringing that power to less skilled
> hobbyist programmers. The GUItopia interface design points in the right
> direction.
> I'd like to propose a new paradigm for a hypothetical toolkit project:
> The client programmer has to provide one interface definition. The
> meta-API backends then automatically generate the interface required in
> the current context: parameter file (or registry) evaluation,
> commandline parameters passed on execution start, a full fledged command
> line interface, a GUI *or* a CORBA/COM/(what does KDE use?) interface,
> or an (language binding?) API.
> Usage of these interfaces can be combined: Another application can start
> the program as a component (e.g. using CORBA) and ask it to start
> another interface (e.g. the gui) which the calling application then
> embeds somewhere.
> If such power could be brought to unskilled hobbyist programmers, the
> impact on free software could be very significant. That, I assume, was
> the original intention of the people who developed free component models
> (e.g. Gnome and KDE). The problem with these projects is, that the
> C-APIs are far beyond the grip of unskilled programmers. Ruby has the
> potential to change that and GUItopia points out the direction to go.
> .NET (MONO) tries to achieve something a bit similar, but it's still in
> its infancy and I doubt it will bring salvation to free software. Even
> today many, many Gnome projects spring up that don't use C but Python -
> for obvious reasons. We know ruby can do a better job.
>
>
> First ideas on how to approach the problem
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The proposed paradigm requires substantial effort to implement. I don't
> think everything required could be achieved by a single person or a
> small developer team. Some important tasks are already started or even
> partly complete in GUItopia though:
>
> - usage of simple yet extremely powerful programming language that can
>   be easily learned by unskilled programmers and is fun to provide
>   motivation for hobbyists
> - complete seperation of API-frontend and implementation backends
> - implemention of some backends (for GUIs)
> - definition of a clean and simple API that's accessible to unskilled
>   programmers
>
> What remains to be done:
>
> The API might have to be changed. The API needs to use an abstract
> metaphor that can be used to describe any kind of interface. GUItopia
> currently uses the GUI-metaphor. Maybe that is no bad choice. I don't
> see yet how the GUI metaphor can be translated into a command line
> interface, but I think it can already be easily translated into a CORBA
> (or COM or ...) interface: A checkbutton is a setter method for a bool,
> an entry is a setter for anything, a scale is a setter for numeric
> values. Buttons are method calls that make the app perform some action
> and so on.
> But maybe the GUI-metaphor produces too much overhead. One idea is to
> assume that every interface can be represented in a tree like fashion:
> - class inheritance trees for CORBA/COM/(...) and APIS
> - packing hirarchy trees (packing stuff into nested containers) in GUIs
> - commonly known command line interfaces usually represent very shallow
>   trees since they come from procedural programmers - I don't think that
>   has to necessarily be that way, though.
> The task of e.g. a gui backend would be, to do the right thing for the
> right tasks. Think LaTex for gui layout. The task of creating the actual
> gui (or any other interface) is taken completely out of the hand of
> client programmers, which is a good thing (tm). Let programmers express
> their ideas and let "professionals" care about gui layout. There are
> layout guidelines for Gnome, KDE and Windows. One could even imagine
> different layout backends for different environments that makes the app
> fit in seamlessly everywhere.
> But if that is possible, then what is all that "overhead" in common gui
> APIs meant for? I think much or most of that "overhead" is necessary to
> provide flexible interfaces that adapt to the needs of users.
> Thus the whole trick would be to provide a general, abstract (treelike?)
> interface definition that can dynamically change (!). What GUIs do is
> just show that part of the interface to the user that he currently needs
> and to hide stuff that could potentially harm the application in the
> current context. These dynamics are useful in complex applications but
> they should be optional for simple ones. That would also be a very
> useful paradigm for all other interfaces (think error mesages for CLIs
> and exceptions for Component models and APIs), and can in principle be
> expressed in an abstract fashion that does not rely on the GUI metaphor.
> Maybe the best Metapher would be ruby itself. Any common interface
> structure (treelike or otherwise) can be expressed in ruby. Ruby also
> includes all major higher abstraction mechanisms in modern programming
> languages (except for dedicated functional programming, but even that
> can be achieved). And Ruby presents them in a coherent fashion. The job
> of the meta-API would then be to force good design on the client
> programmer, without taking too much flexibility from or imposing him to
> learn too much new stuff for using the API. The API could provide a
> collection of base classes from which to derive interface elements, plus
> modules to provide common functionalities. The interface definition
> would start with one instance of some class (the toplevel window or the
> "main" class of the CORBA/COM/API/... interface. That instance would
> nest other Elements (accessible data and methods). The job of the client
> would be to order the interface in a treelike fashion. He can use the
> provided functionality from the API-provided base classes and modules to
> bind callbacks to events in the interface. The API must also provide
> infrastructure to seperate the interface from the program core.
> This would allow programmers to express interfaces in the most natural
> fashion possible (at least natural for programmers).
>  I think it can be done in Ruby, but in few other languages ... if at
> all.
>
>
> Pitfalls, Gotchas and other Maladies
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The task of implementing such an idea can be broken down into three
> mission critical parts:
> - designing a useful API
> - implementing the interfaces
> - bringing the implementation to a usable performance
> The whole thing stands or falls with the API. If the API is good, the
> project can succee - otherwise not. The implementation is a huge task
> and the performance issue makes it huger yet. I think the only sensible
> way to cope with a task of such dimensions is, to implement everything
> in ruby until there is a working system. The system must then be
> profiled and performance critical parts ported back to C/C++. When
> designing the original ruby implementation, one should stick with
> conservative design and always keep in mind that the thing one is
> currently coding might have to be backported. The system should be
> broken down into as many independent parts (components?) as possible.
> Achieving complete unification of interfaces is probably not possible. I
> think object oriented (treelike) command line interfaces might not be a
> bad idea at all. But it's probably difficult to interpret the whole
> power of e.g. CORBA interfaces as a GUI. How do you pass three arguments
> to a method (= button) on execution?
> And yet again: The presumable effort of implementing such a huge system
> makes the project look broken right from the start.
>
>
> closing remarks
> ^^^^^^^^^^^^^^^
> I am not a professional in any IT stuff. My programming skills and my
> experience are pretty limited. Something like the proposal above may
> have been proposed before. If so, what became of it? I know the scope
> and effort of implementing something like this is huge. I doubt that it
> can be done. I am not sure if the potential is as great as I assume it
> to be. The thing just came to my mind and I wanted to hear other
> people's opinions. You are here because you feel a need for something
> like GUItopia. My proposal takes GUItopia to another level. The new
> reading would be "Grand Unified Interface topia". That's why I'm asking
> you of all people to express your opinions.
>
>
>   Cheers
>
>     Thorsten
>
>
>
> _______________________________________________
> Gutopia-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gutopia-dev
>