Re: Design Considerations... Description versus Types...

[Suboner aol com]

> What's the problem? Is there any reason it matters that a widget is
> implemented in terms of more widgets?

Well, its modularity, what is the diffrence if I have a function that creates 
and connects an object and returns its root versus having an object that 
creates and connects other widgets? From what I can tell its simply to give 
access to subwidgets, like the dialog widget has 2 widgets which it gives 
access to through pointers, but what does that matter if you could simply 
create functions that retrieve these instead, or for that matter a template 
object with a hash table to retrieve it for you as requested. What is the 
diffrence of using libGlade or other library that loads an XML interface then 
having an GtkWidget object that creates the interface? Why does GLE have 
seperate Gtk types for each diffrent window, why not just have one widget 
that holds all of them  (GleShell, GleEdit, GleTE, etc)?

Its more benefitial then it is for solving problems. It organizes things 
diffrently, if Gtk alters its scroll bar widget, it has to hunt down to find 
out which other widgets depend upon it, and update those widgets. It could be 
as simple as looking in Scrolled window to make sure there are no bugs, but 
if you have many other widgets that use that widget internally, then you have 
issues to work out with them and you have to hunt them down. On the other 
hand, organization of this could be that you alter a widget you check its 
child widgets to be sure there are no problems, then you check the templates 
to see which ones use it directly or indirectly. You could just grep, but 
that does not solve problems where a user loads an glade or gle file which 
could be out dated or out of sync with the current Gtk release.

In some ways I agree with you, because if taken to its extreme, we would have 
data and relational functions. That is that we specify diffrent data, and the 
data itself is defined upon its relationships with other data. That is that 
32bits is defined based upon how its used, in that if you use floating point 
functions/instructions on it then its a floating point value, if you use 
integer functions/instructions on it then its an integer. A relational 
example is like for example having 2 integers and an array, we can have a 
picture. That is if we make the relationship (or connection) between the 2 
integers and the array as being width*height=size of array, then we have a 
picture, if we change the width variable the array changes, if we change the 
height variable then the array changes, if we change them both simultaniously 
then it changes the array size. This is extreme for todays computing power 
and level of programmer abstraction, but as things progress we will 
eventually be dealing with networks of data, which can expand and contract to 
increase performance and effeciency.

> A widget is any subclass of the GtkWidget base class that properly
> implements the abstract portions of the base class interface.

And what is a GtkWidget base class? And what is a proper implementation of 
its abstract portions, or for that matter how close do you have to be to the 
abstract portions in order to decide to be a widget or not? If it is for 
visual display should it then be a widget? If it takes input should it be a 
widget? Does having a GdkWindow make it or not make it a widget? So far it 
seems to me that anything can be made into a widget just by altering its 
property, and seeing the current object hierarchy it seems this is true. I 
could create an entire application as a GtkWidget (as many have before). And 
even more sticker what happens if someone changes Gtk so that GtkWidget could 
combine with other objects (multiple inhertiance), like the latest fad in C++ 
OOP, then you have objects which don't have to be widgets, why not create an 
entire OS or XServer that is inherited from a GtkWidget.

MFC and qt are both like this, they don't have the real meaning of modularity 
or relational data, and they even promoting inheriting from their window and 
widget classes when you use them. You want to create an window, you inherit a 
window, some even go to the extent if you want to create a button, you 
inherit a button. This is not modularity, this is dependance, and this would 
definetly increase the size of a type tree anyway you choose to look at it.