Design Considerations...

[Suboner aol com]

I've been examing Gtk+ for quite some time now. Making my own widgets, and 
suggesting changes, looking for something usefull to do when I can. But for a 
change I would like to start a discussion about architectural design and 
consideration for future change. So feel free to add or comment on things I 
have to say.

As I understand it, the interface is a kind of port, or way to connect to 
something else. An example is, our (human) interface to the physical world is 
our sensory system. There are 2 aspects to an interface, input and output. 
Input is considered monitoring or passing of information. Output is 
considered feedback, response, reaction, or result of the input. On both 
sides of the interface are logic operations on the information passed, in 
this way input and output are loops, or rings. A logical operation may just 
be to transfer information exactly as it is, which if it keeps looping is 
really a way memory works (I recall reading that neurons do looping as a way 
for humans to memorize). Gtk+ is a gui software tool, its primary focus (as I 
would understand it) is a way for applications to take input and give visual 
output, a section of the interface possibilities of a computer (of which 
there can be many).

The input and output are more integrated in Gtk+, which is not that good of a 
thing because it limits the modularity and flexibility of it. The output is 
the graphics, the input is the mouse keyboard and any additional devices 
there may be (a timer is a form of input into the software). With input 
devices some require focusing, such as the keyboard. The mouse is commonly 
used in partitioned screen space with an imaginary cursor so its easy to make 
things integrated, and lower level APIs make it even easier to be forced into 
integration. The problem with to much integration is that you lose simplicity 
of creating skins (one big image with clickable parts). If you guys impliment 
skins in Gtk+ in a more seemless way you will probably understand better how 
closely graphic objects (like buttons) be integrated with input objects (like 
screen partitions). Another way to look at this is that there may be 
instances when you want to use an input object but not draw a button object, 
or times when you want to draw a button object but not have it take input 
(that does not seem likely but its not out of the question), or one final way 
is that someone comes out with a special kind of input object or a special 
kind of button object (a 3d button for example).

Creation, Maintanance and Manipulation tools. Creating interfaces seems to be 
done quite well with GLADE, but it strongly depends on a source code 
programmer to finish the job, the next step is to make an environment that 
allows users to create GObjects and connections with out having to touch a 
line of code, or to start creating a large enough library of components that 
users can simply connect them together like legos in order to create an 
application, or form new ways for their applications to comunicate. 
Maintanance and manipulation is something I hear alot about in linux, in not 
having to reboot in order to make changes to the system, an interesting 
concept that would be even more interesting to stop an application and to 
alter its internal wiring (connections and interface), and to be able to 
extract information when the application is in an unstable state by allowing 
someone to view an applications objects using an application browser, or to 
add more objects inside of an application as needed.

There are many problems with language that true visual programming may solve. 
Firstly there is major arguements over which language is better (C vs C++ vs 
Java vs Perl vs Python, etc) or when to use which language, some of these 
things are simply syntax quirks and nothing more, others are about 
simplicity, but with simplicity we get other problems. For example C++ and 
Java object oriented programming have their problems, the simplicity of the 
way they work creates complexity in design decision, when creating a graphics 
library, you will probably create line drawing functions and other 
primitives, but then what happens when you add beziers, or when you add some 
other kind of curves or spline drawing functions that are not supported by 
hardware or are not present in the graphics library, do you inherit a special 
version of the graphics library just to add new functions, or do you add the 
functions to the data objects (a bezier function with a function to draw 
itself to a graphic object). So expandability and where to put which function 
is a problem. The way things should work is that you have data objects which 
the only functions that are attached to them are to maintain them, but 
functions that sit between more then 1 object are treated outside of objects. 
I'd say Gtks signals are very similar to this and fit quite well as being 
that, but of course its done in C with wrappers and implementations in C++ 
(redundancy), the diffrence is more in how you look at something and not so 
much in what it does, it would seem to make sense to remove the redundancy by 
having a system which internally uses diffrent means to store the logic while 
outputting this as C, C++, perl, java, visually, or other means to which 
someone wants to view and manipulate code, so internally it would have to be 
uniform but allow for external manipulation. The visual representation will 
be more benefitial to those who may not know how to program so well but can 
connect the dots, and know 1 + 2 = 3, but may also give seasoned programmers 
a new way to work, or a new way to look at things simply but complexily as 
needed. A library for dynamic creation of code would be an interesting 
feature to see in GCC or other project.

But I believe I am side tracking from this a bit. I'm currently working on a 
simplified GUI builder (and eventually I'm hoping more simpler way to 
construct *complete* applications like legos, and create objects as needed) 
more simplified then GLADE but I noticed that Gtk is not quite up to the 
needs of this quite yet. If you examine GLADE you will see that GLADE has to 
be aware of all the kind of objects in which it must deal with, for example 
replacing children widgets requires GLADE to know what type of container an 
objects parent is, the object itself should know how to handle and replace 
its children more so then GLADE. Another thing to look at is that GLADE has 
to know what type of object you want it to create, because some objects will 
cause page faults if you simply tell it to create an object with no knowledge 
of the objects initial parameters (GtkScrolledWindow and GtkViewport seem to 
be the ones to do this), objects when created should assume that they were 
created intially with out any more input. The other thing is type utilities, 
such as registering and initializing types so that all types can be 
initialized automaticly (and it should work both ways in that creation of an 
object registers its type), and another usefull utility that is partially 
there is browsing the type hierarchy, or else its assumed that the only types 
are from "void" to "GtkObject" and their children. There should also be extra 
type information (as needed) for getting min and max values and for getting 
Enum value names.