Managing and/or configuring GUI's.

'''Topic Name Issue'''

[I generally think of "configuration" as performance tuning, setting OS-specific flags, fitting system into specific environment, etc. I am not sure "configure" is the right world, but am lost for alternatives right now.]

''Configuration is not performance tuning. Configuration is the storing and retrieval of metadata, ie. INI files, XML config files, setting connection strings, app specific settings like where to log to, etc...''

* MetaData is "data about data". This is not what is being discussed here.

[Am I the only one bothered by the use of "configuration" here?]

I can't help you if you don't explain what about the word "configuration" troubles you.

m-w.com defines "configure" as: "to set up for operation especially in a particular way <a fighter plane configured for the Malaysian air force>"

That definition obviously applies to what '''has been''' discussed, but there's no way for me to know how well it fits what you have in mind but have not succeeded in communicating yet.

["Configure" usually means to change or customize what already exists. When you "configure a server", you make adjustments for the local environment. You are not writing one *from scratch*. Yet, when you build GUI screens and widget layouts, you are creating this layout information from scratch. The layout did not exist at all before. I rarely or never hear, "go use VB or Dephi to configure a GUI for our new project."]

''The first time you configure the server (when you create the first configuration), it is still configuration. All of your examples (and your web site) talk about setting values that existing code will act upon. They don't discuss how to write the code that acts upon them. That looks like configuration to us.''

Agreed, and further: But that's precisely the point of this page, so I don't think it's a terminology issue: we understand about table-oriented GUI '''configuration''', but I don't think any of us yet understand what you might mean about table-oriented GUI '''creation'''.

I don't know VB nor Delphi, but my understanding is that GUI creation in those two languages is a purely procedural matter, involving neither OO nor your table-oriented approach, no?

''I've never used Delphi, but I have created GUIs in VB. It's not as OO as some languages, but I wouldn't call it procedural. It uses interface inheritance to define new widgets.''

[It is more a question of terminology than it is classifying the paradigm of such tools.]

Yeah. Whatever. Are you saying that you don't feel like saying how the table-oriented approach is used to create new widgets?

* You are changing the subject. Until hierarchical file systems are replaced by relational file systems, I will agree that OOP is better for packaging widgets. -- top
* ''What do file systems have to do with GUI widgets??''

* That's ok, we can work with this. Ok top, please explain two things (1) you use the word "packaging" now, whereas most recently we were talking about "configuration" vs "creation". What do you mean by "packaging" in this context? (2) Ok, let's say we're using the first version of the BeOS file system, which was actually an RDBMS (historical note: they removed some of its power in later releases). What would you then use this RDBMS for in regard to widgets?

** There is the issue of creating widgets, and using those widgets to create layouts. If combining widgets to create a layout is called "GUI configuration", then how come creating widgets is not called "configuring widgets"? As far as file systems, let's save that until after the terminology issues are addressed. -- top

** ''That doesn't ring a bell, where did someone say that that "combining widgets to create a layout is called 'GUI configuration'"? (Whether the statement is true or not seems to me to depend on context.)''

** I thought that is what was implied in the title. If not, then what exactly is and isn't "gui configuration"? There seems to be lots of confusion.

** Do you see the words "combine" or "widget" or "layout" in the title? Don't get bizarre on us here; "configuration" may or may not mean that, but it's NOT implied by the title. Anyway, granted the word "configuration" might not be perfectly pinned down at this point, so we can continue discussing it. To expand on this "combining widgets to create a layout": 

** It's bordering on being false, but it's in a grey area, since, as I said below, potentially anything and everything could be "configuration" in a purely declarative GUI language. However, outside of that strict context, that would be misusing the word "configuration". Combining widgets is typically part of "creating" a GUI. Laying them out is part of "creating" a GUI about 95% of the time, even though widget positions can be specified in e.g. X11 configuration, simply because that kind of configuration-based layout usually isn't smart enough. Thus e.g. Java has a multitude of smart layout classes, to dynamically do a better job of arranging widgets, and this is usually considered part of "creating", not "configuring".

** It's possible you might have some 100% declarative approach to creating GUIs, that is purely driven by tables, in which case the whole issue of trying to pin down the exact definition of "configuration" would be beside the point. Do you have such a thing? If not, give me some examples of what you '''do''' have that you think goes beyond the word "configuration".

** ''What exactly does "configuration" mean to you in this context, or any context for that matter? I would call my approach "declarative-centric". Nothing GUI can be 100% declarative, but there are certainly declarative tilts. "Declarative" is more specific than "configure" it appears to me. -- top''

** I just explained what it meant to me in this or any context until I was blue in the face, it's your turn now. It may well be appropriate to call your approach "declarative-centric", at least for parts of it...if I knew what it was. What '''is''' your approach?

** ''See DeclarativeGuiFrameworks. As far as your definition of configuration, I find it unclear. See "meta data" comment above.''

** [We mean the information you describe on http://www.geocities.com/tablizer/guitable.htm. That's configuration data. It tells a program the name of a widget, the window a widget "belongs" to, the type of the widget, the widget's coordinates, colors, caption, etc. It doesn't provide a way to make new types of widgets. It only provides a way to specify one type from an existing set of types. We keep asking how you create new types, but you never answer.]

** Like I already said, lets deal with the title/definition issues first, before adding yet more layers to the confusion.

** [You can deal with the title issue by explaining how you create new types of widgets. It can't be that hard to explain, can it?]

** ''I am sorry, but I don't see how they are related. For the sake of argument, assume new widgets are created with OOP.''

** Ok. And then what, are you agreeing or disagreeing that the things listed in tablizer/guitable.htm are "configuration"? If you are disagreeing, and saying they should instead be called "gui declarations", then at least for the moment, I'm ok with that terminology. Either way, where does that leave us at this point in the discussion?

** ''I don't know if there are any new conclusions introduced. This subsection was an issue raised about the title for the most part. If I am the only one who seems bothered by the title, then I guess I will go with the crowd. For crowds determine terminology for the most part.''

''Top has never felt like saying how the table-oriented approach is used to create new widgets. I've asked repeatedly, but he always says that's not something "application developers" need to do. He even suggested off-shoring that task.''

He was being a real tease, I actually thought for a moment that he was going to explain.

If the absence of an explanation continues for any extended length of time, that will make refactoring the text a lot easier. ;-)

* Like I already said, given the current state languages and file systems, I will tentatively agree that OOP is the better way to package reusable GUI widgets because they tend to fit a "device driver" pattern. See ExtrapolatingDeviceDrivers. Maybe in the future if/when TOP techniques become more mature, this may change. (See CodeOrganizationAlternatives). But, creating widgets and using them to build user interfaces are, or can be, very different issues. -- top

* ''Only in simple applications are the acts of creating and using widgets different issues. Most applications have custom GUI widgets that are used in more than one context. That calls for creating a new widget, and its very common in my experience.''

* Well, that differs from my experience. Do you have specific examples? Someone brought up a calendar widget, but I showed a link to an existing commercial one. Further, my suggestion does not exclude the possibility of creating plug-reusable widgets. It just might be with a different language and/or tool. Unless you want to marry your browser apps to Microsoft, one has to be careful about getting too creative anyhow with fancy widgets.

* ''A data format selection field, customized file chooser, calendar widget (in case I don't want to buy one), a browser dialog that looks similar throughout the application but has n variations each with specialized controls and displays. Who said anything about browser apps or Microsoft?  I'm talking about general GUI application development.''

* Most of these are or can be "pop-up" thingies such that they all share the *same* screen. Even with the calendar one can reference the same pop-up screen. If it is in more than one spot, then I create a "date" type in the framework. OO'ers would probably complain because I would have to update two case statements to add it to the framework (one in the "display" action, and one in the "validate" action), but that is not a big deal, and probably a worse-case scenario. I can bring up an "add a new action" scenario to make polymorphism require changes in multiple spots if you want to get into another change-scenario visit-point-counting fight. I need more info on your morphing dialog box example.

* ''And I need more info on how you create and customize widgets. What else is there to say?  Imagine a dialog box that let's the user lookup information. It's used to look up user info, part info, distributor info, schedule info, whatever. All of the different variations use the same layout (so the user doesn't have to learn more than the minimum) but vary the fields that can be entered, the valid search options, the way results are presented, etc.''

* What is the same and what is different? If dialog boxes look different than non-dialog boxes, then perhaps add a column called "isDialog" in the "Window" table.

* ''Read what I wrote again. The layout (look and feel) is the same. The specific controls are different. Do you know what a dialog box is?''

* As I understand it, a dialog box is a small, modal window without a resize border.

** It may or may not have a resize control (I think most things should unless there's an overriding reasons not to, having been frustrated too often with unresizable widgets). Here's a definition from a glossary that seems reasonable: 'A small window which appears on the computer screen that either requires that you perform an action, select an option, or provides you with information. For example, dialog boxes ask you questions like, "Do you want to save this document?" or "Are you sure that you want to exit this program?" '

* But to use those as a look-up screen is perhaps not appropriate GUI design. I would use them only for simple things that won't require going back and forth to compare information with other possible screens.

** That's an intelligent comment, since it is in fact a common problem to not have sufficient information to deal with modal popup dialogs. It's a digression, though, because the simplest ones don't have that problem (e.g. "Reboot now? y/n" may not need any context)

* In fact, many IS-A classification systems in GUI leads to problems in GUI's in my observation. One can easily encounter borderline and cat-dog situations.

** ...which goes back to the heart of one of your primary OO criticisms. Yes, sometimes that's true. I don't see what it has to do with the current subject of dialogs, though, it seems like a non sequitur.

** ''It is about how to manage "variations on a theme", which OO tends to do with DeltaIsolation. I assume that is what you are proposing, but I could be wrong. ''

* Thus I think I would rather leave the Modal attribute and canResize attribute independent of each other.

** I think that's my preference, too, but again this seems like a non sequitur.

* ''The user wants them so the user gets them. They want them all to look and behave in a similar fashion, but they want different controls and result presentation. How will you provide that? (This has nothing to do with model or resize attributes. We aren't discussing the GUI design or requirements, but how you would implement this design. It's just an example of the need for customized widgets that occurs in GUI app development.)''

** I have not seen a specific need for a "widget" here. The simplest ones can be function/method calls like they are in JavaScript (alert(), prompt(), etc.). Something more complicated or customized would be just a regular window/screen/form. Again, if you want an easy way to specify a standard look-and-feel such as colors, then one can make it an attribute/field of a Windows entity record, such as "isDialog=true".

*** For reference: A Sun glossary defines widget as "a reusable user interface component such as a button, scrollbar, control area, text edit area, and so on". Some widgets are simple, others are complex (a text-edit widget is complex, since it contains sub-widgets such as a scroll widget, text area widget, etc, as an integral part).

** ''The dialog box is a widget. Windows, screens and forms are widgets. I'm not talking about colors (they are part of it), but the general layout and behavior of the dialog. These buttons go here, those buttons go there, these fields go here, when I do this that happens, etc.''

** I guess I am not understanding exactly what you are requesting. Perhaps we should try a specific UseCase(s) instead. I was envisioning a (new) property of windows, called isDialog. In a typical "attribute browser" (called different things in different IDE's) for a given window, there would be a checkbox titled "Is Dialog?". If one clicks the "Is Dialog?" checkbox, that window then has dialog-box properties/behavior when it renders. (Note that it may override other attributes, such as canResize, isModal, etc.) See "example 7" below.

** ''I'm not talking about a single property for windows, but a set of similar dialog boxes. Assume that someone has already written a dialog box widget. We want 5 different dialog boxes that share general layout, operation and presentation but each has different details. One has 3 input fields, one has 2, one has 3 groups of 2 input fields with logical operators between them, one shows the results as a table, the other as a tree, etc. All of them have different labels and all of them look up data from different sources using different rules.'' 

** Why won't my solution handle this?

** ''I didn't think you'd provided a solution yet. Do you mean the "WINDOW ATTRIBUTES" table above?  I don't see how it addresses the issues. How do I move the input controls from the top left to the bottom right on all the dialog boxes?  How do I say that a specific dialog box uses a tree control to show the results and all the rest use a table control?  How do I say this dialog has 3 input fields, this other dialog has 2 input fields, yet another has 3 groups of 2 input fields with logical operators between them?  How do I keep from duplication code and configuration data while doing all of this?''

** Okay, I think I see what you mean now. One approach is to make the first screen, and then copy it's configuration (?) data for alternatives. This may seem like a violation of OnceAndOnlyOnce, but generally using a DuplicationRefactoringThreshold of less than about 4 repeats for screens has not proven very useful in my experience, and I usually have not exceed that. Tweaks tend to diverge further over time. The second approach is create a "template" screen with the common stuff on it. Then in the "on-load" or "pre-load" event put whatever differences there are going to be. Keep in mind that one can create, alter, clone, etc. GUI layouts during run-time (although in some cases you need to issue a "refresh" command to show changes). It is just a database (perhaps a NimbleDatabase) with all the usual database operations available.

** ''Our 5 dialog boxes violate even your standards for OnceAndOnlyOnce. That leaves the "template screen", which is a new widget. That's why we need to create new widgets and use them. Polymorphic inheritance can solve the gross problems of shared behavior. Aggregation can solve the rest. How would you solve those problems?''

** I would like to see more specific requirements because I am a bit skeptical. I will agree that in rare cases polymorphism may make things simpler, but one cannot know in advanced. Thus to make everything polymorphic just in case you are right is not logical. Again, SoftwareDevelopmentIsGambling and polymorphism is not a good horse in my opinion. The real world does not change in a tree-wise shape. It just plain does not. No TreeCop forcefield has been identified. Besides, cloning an existing screen and modifying is considered prototype inheritance by some. OOP is just designed to do it in a language instead of in a database. And if you do that, you lose language-neutrality.

** ''We don't have to know anything in advance. We know right now that we need these 5 dialog boxes. Please show us how you would share behavior between them.''

** I would need specifics to consider the best potential route. For one, to study the pattern of differences. There does not appear to be a whole lot of similarity based on your rough descriptions. By the way, if we are not going to care about future change patterns, as you seem to roughly imply, then simply use clone-and-alter. That way we don't have any parent that is too coupled to children to make changes fragile. We can change each screen without worrying about a parent's interface or implementation.

----

Example 7

     WINDOW ATTRIBUTES
     Title........["Employee Number Lookup"]
     Width........[800 ]
     Height.......[400 ]
     resizeAble...[Yes]
     isModal......[No ]
     isDialog.....[No ]
     etc... 

(Example moved from above because of nesting formatting problems)

----

X11 uses an app-defaults directory and/or a per-user .Xdefaults configuration file, which allows setting the attributes of 100% of the widgets in an application: position, text labels, foreground/background color, you name it.

* I should have mentioned that this info is (to oversimplify a little) taken from those config files and stored in a per-system database -- not a fancy RDBMS, but still, a database. Individual X11 apps (or more typically, the widget libraries they use) don't parse the config files, they query the database.

This is as opposed to things that cannot be set via configuration: the widget toolkit chosen requires custom programming per toolkit (e.g. Motif). Each individual widget chosen requires custom programming (e.g. a background canvas versus a slider). And the interrelationship between widgets requires custom programming (e.g. the main window contains 12 buttons, each of which contains a text label).

More programming, not configuration: Typically the majority of GUI events are handled automatically by the widget toolkit skeleton, with appropriate events being translated into widget-related function callbacks as appropriate. E.g. if a textbox has focus, it will potentially receive a callback per keystroke, to allow the app to capture the keys typed into the widget.

However, the details are up to the widget set. If some widget set is particularly clever about something, e.g. allowing reparenting of a widget or allowing redirection of events/callbacks, then it may support putting those things into the configuration Xdefaults as well.

So there isn't an absolutely sharp line between what can be configured versus what must be programmed, however, if 100% of the GUI can be specified by configuration, no programming needed, then one has a purely declarative GUI language, which is a different paradigm.

As far as I know, currently no such purely declarative GUI language is used standalone; they simply record design decisions made e.g. interactively in a GUI Wizard or some such.

''Perhaps the title topic should then be "declarative GUIs" or "The declarative portion of GUIs". I am still bothered by the use of "configure" here.''

Only if it's 100% declarative, which no one has been talking much about. The examples that I give above, such as specifying a background color, are indeed classic kinds of "configuration". But feel free to expand on what makes you feel uneasy.


------------------

'''Table/Database-related GUI techniques'''

This has been a controversial topic. As of 2004-May-6, it is clear that GUI '''configuration''' can usefully be stored in tables/databases; everything else is still being argued about.

	* http://www.geocities.com/tablizer/guitable.htm (Table-oriented GUI's)

	* http://www.geocities.com/tablizer/webstif.htm  (Web state)

	* FoxPro 2.5 and 2.6 stored GUI elements in tables, I would note, but I was not very happy with their implementation. I also noted that version 5 had some event columns it appeared, but have not verified where they are used.

** Do you happen to know what language those versions of FoxPro were written in? ''
*** {I don't see why it matters to an applications developer}''  
*** It matters to the application developers who wrote FoxPro. Do you know or not? 
*** {No. I don't know. It appears we have a different def of "application developer".}  
*** FoxPro is an application, isn't it?
*** {I generally know "application developer" to mean somebody who develops custom applications.  Programming FoxPro itself I would call SystemProgramming. "Programming tool developer" may be more fitting to the FoxPro makers.}
** When you say it stored "GUI elements" in tables, did it store their code or just their configuration data in tables?  Were those GUI elements treated as objects per the NygaardClassification? 
*** ''{Please explain. Note that I don't consider FoxPro the ultimate GUI system, both before and after it was OO-tized.}''  
*** Read NygaardClassification on OOP. Are FoxPro's GUI elements regarded as a physical model, simulating the behavior of real or imaginary parts of the world? {I suppose ALL GUI's are "regarded as" modeling push-buttons,  dials, and paper of old-style machines and desks. That is what GUIs inherently are.}  
*** Then by Nygaard's definition, FoxPro GUIs are OO. {That is too wide a definition IMO. That is external requirements and has zilch to do with code organization.}  
*** I don't see how "NonOopGuiMethodologies" has anything to do with code organization. It sounds like you're talking about storing GUI parameters in a table, not how code is organized. 
*** {I am making a distinction between what the user sees and what developers/designers/DBAs see. OO is rarely defined by what the user sees. Tables can also store references to procedures/functions. Thus, they can be a key part to the organization of GUI-related information. The "big picture" of event management, associations, and prioritization may almost all be in tables, for example. If we go all the way, we could make a TuringComplete event system in tables, but that's probably going too far in practice. A mix more like 80% in tables and 20% in code compared to what OOP would do is more like it.}

One criticism sometimes given against table-centric GUI techniques is handling a wide variety of attributes. One solution is an AttributeTable, another is perhaps "dynamic relational" (MultiParadigmDatabase).

-----

''How do you specialize GUI widgets in a non-OOP GUI methodology?''

"A kind of" or "A type of" is pro-sub-type design, which I generally don't subscribe to. (See ThereAreNoTypes and LimitsOfHierarchies.) Generally the approach I take is to view widgets as a series of "features". You pick and choose the features you want. For example, take the "combo box" from Visual Basic. It is like a pull-down list, but also can act as a free-form text input box. The hierarchies commonly used look something like this:

* Widgets
**Text Box
**List Boxes
***Drop-down List
***Combo Box

But actually the combo box is really a hybrid between the drop-down list and a text box. Logically a combo box is the sum of two sets: text boxes and list boxes, and not a hierarchy. (But the hierarchy is probably too ingrained so in practice I would probably not use that approach in a framework. QwertySyndrome.) A combo-box is really a text box that HAS-A drop-down list option, but most frameworks make it an IS-A. As a hierarchy, it violates OnceAndOnlyOnce because leaf "combo-box" shares tons of features with "text-box".

''That isn't the question, though. How do you specialize GUI widgets in a non-OOP methodology?  Let's say the API provides a combo box. I want to make my own specialized kind of combo box. How do I do that?  (If the phrase "kind of" offends you, think of it as once I've chose the features I want, I want to re-use them.)''

Actually, I would view a combo-box as being two different widgets: a text-box and a "look-up widget" of some kind that populates a particular box. Look-up buttons can incrementally grow increasingly complex, such as including a QueryByExample form, and thus looking to being change-friendly, perhaps we should just consider the drop-down list as a stripped-down look-up screen. But then again, trying to be generic may complicate things. Thus a widget called a combo-box may keep things conceptually simple for newbies. A UsefulLie if you will. Actually combo boxes are not common enough to justify a dedicated widget perhaps. This is why HTML form standards don't include one. Thus, as long as we can make something that acts like it using other parts, we perhaps don't need a specific widget for that. As far as packaging it so that "combo-box" is an option in our IDE, that depends on what the IDE looks like. In other words, the answer seems to depend on what you wish the interface/API to look like from the '''application implementor's point of view'''. Thus, I probably cannot answer your question without looking at a specific app designer UseCase. Specifically, what are you trying to reuse?

''You aren't answering the question. It doesn't matter how you view combo boxes. Someone gave me one. I want to specialize it. Let's say I want to add a an animation to it that responds to mouse movements. The details don't matter. How would I do that?''

The details *do* matter. I cannot describe how to implement such without knowing what the base graphic primitives are. And, many GUI IDE/APIs simply don't have the capability to do that. I assumed you don't want to get into the individual pixel level here, but I could be wrong.

''You assume that I just want to configure existing widgets and that I don't want to create my own or customize existing ones. You're talking about using tables to store configuration and I'm talking about using OOP to write software.''

[That's non-responsive. This isn't 1985; there should be no question of pixels. Assume some widget toolkit at the least; if you need to pick one that supports the operations you need or are required by the problem statement, do so.]

''It doesn't matter what year it is. Sometimes we have to get into the pixel level, but that's not the topic at hand. No toolkit I pick will have all of the components I need. None of them are that complete. They provide the basics, but it is up to me to refine them.''

Let's try this. Assume we use a table-driven architecture. Generally you will have some tables that describe the attributes of the widgets. Let's assume our framework supports mouse-related image attributes for (at least) the combo-box button such as default-image, mouse-over-image, on-click-image, etc. If we want to put in an animation (such as an animated GIF) in place when the mouse is over that button, we simply change the attribute to reference the animated GIF image.

''But the combo box doesn't have an animation. I want to add that. I know how to add the flag to enable it. I need to add the behavior the flag will enable. How do I do it in your hypothetical non-OOP GUI methodology?''

What "flag"?

''The flag you just described: "...we simply change the attribute...". That attribute is a flag. It enables the animation. I'm not asking about how to enable/disable the animation. I'm asking how to take a combo box that has no animation and specialize it by adding the code to load and render the animation.''

* It was not a Boolean flag. A check/combo box is generally going to have a down-arrow button on it (at least in Windows). When you click that button (image), it changes appearances briefly. Thus, most likely there would be images (bit-maps) associated with it and it's various stages. In this case I am assuming that our GUI can use animated GIF's for that purpose so that we '''don't have to implement animation from scratch'''. That is a reasonable possibility.

''It doesn't matter. A value in a table will not add new behavior to the widget. All it can do is configure existing behavior.''

I am still not clear on what you are asking. I am using off-the-shelf animated GIF's, not implementing movement myself here.

''But I'm not asking what you're doing. I'm asking how I would specialize a combo box.''

I better let you build the UseCase instead of me guessing what you have in mind. No GUI system I have ever seen is 100% extendable at the app side.

''You've never used XWindows, MFC or Swing?  They are all 100% extendable at the app side. They all allow me to take an existing widget and specialize it.''

At some point you either have to live with or workaround its limits or wait until somebody codes at the pixel level in say C++, which may not be possible if we have to work with an existing protocol on multiple platforms.

''No I don't.''

Sometimes one can fudge things with enough fiddle-faddle. For example, I once worked with a GUI system that had no double-click, in part to be compatible with Macintosh (or was it X-Windows?). I found a way to implement double clicks by counting and timing single clicks.

''Good for you. Now how do I specialize GUI widgets in a non-OOP methodology?  Your argument seems to be that inheritance hierarchies are either wrong or overkill, but you're arguing from the perspective of someone who configures existing GUI widgets. I'm someone who writes new GUI widgets. Inheritance is used for this task because it simplifies the act of writing the code. Before I used OOP for this I used procedural modules that roughly emulated classes. That's how XWindows works. The GUIs we're describing co-evolved with object oriented programming for good reasons.''

Maybe at the lower levels OO is better that, I don't know. (WhenToUseWhatParadigm) I generally have not gone into the direct implementation/OS-level of GUI's, so I won't claim experience there. However, I still don't find your animation example very illustrative of the benefits of inheritance (above). That does not mean I discount them at a low level, but have not seen their benefits demonstrated thus far.

''It's the low level you're complaining about, though. The class hierarchy you described above came from that level. Your first statement on this page talks about "implementing" GUIs, but then your links describe configuring GUIs that have already been implemented. OO GUI APIs give you the power to describe entirely new GUI components based that use or extend existing GUI components. We can hide that power and only provide the ability to configure existing GUI components, but we can't pretend configuration is a substitute for implementation. -- EricHodges''

[I think it's quite obvious that top only configures existing systems, and doesn't know how to write the systems he's learned to configure. Top, the OO guys you're arguing with know how to write "new" systems, they write those tools you use, since you can't do that, you really don't have a leg to stand on when trying to criticize how things are done. You can't do any of the GUI stuff we're discussing with a database, because databases are just data, the best it can do is act as a big really really flexible configuration file, but it has to configure something... that something is what we're talking about, and that something is probably written in OO, because it's the most flexible way to do it. All those tools you use... query analyzers, dbadmin tools, databases, ide's, etc... those are all applications, and most are probably written with OO, so when you say application developer... we consider those applications. You seem to think application developer just means "custom business software" written with existing components, but that's not what it means to most of us. Custom business software is but one small section of what we consider "Applications". You wouldn't have widgets to configure if it weren't for us OO guys writing them for you, so what exactly is it you're complaining about?]

Let's first make a distinction between the "view" of the custom application developer and the GUI engine implementer (GEI). You seem to be implying that if OO is good for the GEI, then it is *also* good for the custom app developer. It is this "jump" that bothers me. I won't battle you at the lower end because I have insufficient experience there, but would still like a more explicit example. I would like to see some sample code rather than just take your word for it. Using DeltaIsolation to "extend" things has a lot of practical roadblocks, such as the "overriding 1/3 of a method" problem. But, DeltaIsolation is still possible with functions.

''That's not the proper distinction. Custom application developers need to change the behavior of an existing widget or create a new kind of widget.''

I am envisioning an '''attributes + events''' (A+E) model. Most of the GUI is defined by setting attributes.

''Change "defined" to "configured".''

Events are triggered over the course of interaction, and these events process information and/or change GUI attributes as they go along. Nobody has found a show-stopping/slowing flaw in this model so far. It is true that one may have to add new events or new attributes to handle new widgets and so forth, but that is mostly the frame-work and/or GUI engine builder's issue, not those using the GUI system to build custom software. But to use new stuff is still just a matter of adding more attributes and/or events. Making A+E creates more layers to alter for new stuff, but that may be one of the trade-offs for having it more language-neutral.

''None of this has any bearing on the reasons OOP is frequently used for GUIs.''

If you are suggesting that A+E is not powerful enough to actually build tools like VB and Delphi, not just use them, I won't dispute that. But A+E can nicely be part of such a tool.

''VB and Delphi let you customize widgets. How will you do that with A+E?''

The main benefits of A+E are that attributes and relationships between them are language-neutral. An OO approach cannot fully provide that without making compromises.

''Sure it can. See .NET and XWindows.''

Recap of A+E benefits:

* Attributes in a "sharable-structure" make it more language-neutral
* Boat-loads of event code is easier to track in a database than as a huge blob of source code
* Querys and off-the-shelf tools can be used to view and manage all those attributes

''All of which can be achieved by storing the attributes and events used by an OO program in a relational database. You're still talking about how and where the configuration data is stored, not a "GUI methodology". You could do this with procedural code, functional code or object oriented code.''

That is why it is called a NonOopGuiMethodologies. Perhaps you would prefer naming this ParadigmNeutralGuis or the like?

[You're still only talking about configuration data, nothing you've proposed is a GUI methodology. A+E is nothing more than configuration data, doesn't matter where you store it, it's not building a GUI. We're talking about building GUI's and you're talking about configuring them... can't you see that?  You can't build GUI's with databases, you can only configure them. To build them.. you have to program.]

''I'd call it "S''''''toreConfigurationInaRelationalDatabase". That's what you seem to be proposing. There's no methodology, it isn't isolated to GUIs, and it isn't related to any particular programming paradigm.''

[[As an onlooker I'd have to say that at this point Top has lost the argument; despite several apparent attempts to squirm out of it by making the focus hazy again, he's been pinned down pretty clearly here. And I have no axe to grind, I was interested in learning what sort of declarative-vs-procedural approach he had in mind. -- DougMerritt]]

* You are not clear enough about what I "lost". Clarity is lacking. I'm not even blaming it on anybody at this stage, we are just having a communication problem. Give me a specific scenario. I cannot state generalities yet because any assumed design involves tradeoffs. I can make a table-centric system that is TuringComplete and can control any pixel anywhere at any time. Because it's TuringComplete, '''it can do ANYTHING''' you can in any other language or paradigm (assuming sufficient hardware power). If you ask, "can you make it do X like I do in system/paradigm Y?" The answer is ALWAYS yes. But the key is how or if we go about it. To avoid making an overly-complicated thing that takes forever to learn, we may trim features down or decide which features we make easy and which harder, and/or build layers such that the common things are on the first layer, but one can "break into" deeper layers for more control and customization for the things that don't fit the base layer, possibly OS-specific needs if desired. We may not be able to diddle individual bits at the highest levels, but if we need to, we go into the deeper layers as far as needed.  The '''layered approach''' is probably what I'd follow. As a rough target, 80% of a typical GUI may be able to use table attributes alone; another 18% a combo of table attributes and custom programming, perhaps in JavaScript; and 2% that cannot make much use of the tables and needs OS-specific or app-language-specific coding. -t

* {Seems to me you're just babbling here -- and interjecting random numbers to make it seem like a considered evaluation -- in a rather pathetic attempt to plaster over the fact that you've soundly lost the argument.}

[I second that, he's not proposing anything new or interesting, just "S''''''toreConfigurationInaRelationalDatabase". -- RamonLeon]

The "interface" to the GUI engine is via tables.

[No, it's via code, there is no GUI engine that works directly from tables.]

''Tables may be the "interface" to the pre-defined widgets. You haven't shown how tables will support the creation of new widgets, the specialization of existing widgets or their re-use and distribution.''

* I would have to look at a specific example, because you seem to be using OO-centric terminology, which may not translate one-to-one to a table-driven or attribute-driven approach. If one always does X in OO it does not mean that the equivalent is always Y in another paradigm. The equivalent could be Y in some cases and Z in others.

* Perhaps there is some confusion over the clause "new widget". You seem to be thinking in terms of OOP's "new" statement, or OOP inheritance or something. That's why I wish to study use-cases so that language or paradigm-specific terminology can be weeded out or generalized. Again, I tend to approach this from a "has-a" standpoint, not an "is-a" standpoint. --top

* ''I think the confusion may be yours.  Your correspondents are trying to get you to answer a straightforward question:  Using your table-oriented mechanisms, how do you create a new '''kind''' of widget?  For example, assume you have a table-oriented interface to a collection of widgets consisting of textbox, drop-down combobox, list box, textarea, scrollbar, checkbox, radiobutton, button, menu, image, popup menu, label and grid.  Now, imagine the requirements specify that you provide a reusable "volume control", i.e., a widget consisting of a circle (knob) with a surrounding numeric scale and a movable tick on the circle.  How would you create it using your table-oriented mechanisms?  In OO languages, this would typically involve straightforward inheritance from a 'widget' base class that provides functionality common to all widgets (i.e., a volume control IS-A widget); plus composition of (say) multiple images and/or labels to provide the scale, circle, and tick (i.e., a volume control HAS-A scale and a knob with a tick); plus 'volume control'-specific code to lay out the numeric scale, etc., handle user (mouse/keyboard/touch) input and appropriately change the tick position.  You can do that without explicit inheritance, but it typically involves either re-inventing inheritance-like mechanisms to obtain the common-to-all-widgets functionality, or duplicating code.''

* "Kind" implies a hierarchical categorization of widgets and hierarchical reuse, which is limiting. (See ThereAreNoTypes) If you have a single GUI parent class, a table-oriented interface can have a very similar interface to it. The advantage is that it's not tied to a specific programming language. Programming in a specific language may be required to implement some requests, but hopefully only a minority. And other languages could potentially still use those. The idea is to make GUI's be a service (GuiService), not a language-specific API. -t

* As far as a custom volume knob, the table oriented interface could send the mouse pointer position to a custom control and the control could return an updated image based on the mouse coordinates. Whether each image update needs to go through tables depends on the architecture. For speed purposes, it may be better to an in-RAM table "copy" of the initial table would be kept, perhaps with an optional "refresh" step[1]. See NonOopGuiMethodologies for a diagram. Tables don't have to be disk-bound. As far as settings specific to a particular custom widget or widget family, an AttributeTable could be used for such if DynamicRelational is not available. -t

* ''So... Your table-oriented solution to the custom widget problem is a... Custom widget. Somewhere?  The rest leaves me in utter bafflement.''

* No, only the sub-parts not provided already. Something somewhere has to implement the rotating knob, for example. Using OOP does not make such magically available without coding. Things like obtaining the mouse coordinates and displaying the supplied (updated) image don't have to be built from the ground up. In other words, what are you comparing it to? How would OOP make less implementation work? The round knob case doesn't really show-case the potential flexibility. A '''combo-box of images may be a better example''' because I don't pre-associate combo boxes to a "text-box" sub-type, like a typical OO library would. You'd have to start from scratch because you are locked onto a branch such that a chordate cannot have an arthropod (compound) eye. (A real Creator would use mix-and-match sets, not the limiting tree of Darwin.) '''No combo of widget parts is pre-limited''' based on a taxonomy. I'm using "set based" inheritance, not tree-based. Everything can be put with everything else. A widget can have text and it can have an image and it can have both (image behind text). One can build buttons with this and checkboxes with this and text boxes with it, etc. An "image" (having) widget can have a pull-down handle (triangle) just like a combo-box. Why pre-limit it based on tradition and habit. Fsck tradition! Think in sets, not trees. Implementation concerns may limit certain combos, but this is an implementation issue, not an interface (library/protocol) issue. -t

* ''"Using OOP does not make such magically available without coding."  Indeed.  That's my point.  You appear to be suggesting that a table-oriented approach simplifies creating new kinds of widget.  It doesn't.  Eventually, inevitably, you will have to code something.  At that point, you can code in an OO language and you're done, or (apparently) you can code in an OO language '''and''' produce additional "code" using your table-oriented approach.  Trivially, the former is simpler than the latter because it is one programming step instead of two.''
** The point of tablizing it is not so much to avoid coding actual behavior, but to manage and package complexity and provide language neutrality. Although, it could reduce re-coding by allowing different languages to implement widgets such that you don't have to use the native app language to re-implement widgets already implemented in other languages. COBOL could potentially implement a widget used in an Eiffel app and vise verse, for example. (See GuiService.)
** ''I suggest you create a tech demo that clearly illustrates how "tablizing it" will "manage and package complexity and provide language neutrality".  Simply stating it as given, I'm afraid, is unconvincing.''
** I'm afraid I cannot do that anytime soon. However, if you think about how to go about language-neutrality and GuiService, you will likely come to similar conclusions.

* ''"I don't pre-associate combo boxes to a "text-box" sub-type, like a typical OO library would."  I don't either.  Straw man.  Good widget libraries present a combo box consisting of a widget and an arrow to pop up a list of widgets.''
** It's not a straw-man because if you use a "reference-based" approach to provide flexibility, then you lose the advantage of OOP, and start to need something to track and manage all those references. OOP gets ugly there, and one ends up needing or re-inventing a database of sorts to do it. If you have a dozen references, then code-centric approaches may be "good enough". If you have thousands, then you need something more powerful. You are attempting to compete with a database by becoming a database. A fancy "object browser" looks a lot like a navigational database browser. GreencoddsTenthRuleOfProgramming.
** ''Sorry, you've lost me completely.  No idea what you're trying to convey.''
** Your object model is growing so complex and large that it's perhaps time to consider managing it with a database instead of a giant pasta wod of object references. As someone once said, "Any problem can be solved by adding another layer of indirection". Sure, but the hard part is managing all that indirection. -t
** ''Still don't get it, sorry.  Code isn't a "database" and doesn't benefit from "managing it with a database," whatever that means.  I don't manage "object references", either.  I write classes.  The machine manages object references and, I guess, "all that indirection."'' 
** Maybe you have a powerful brain that allows you to memorize where thousands of widget instances and classes are in text code files. My brain is not. I can't handle TooMuchGuiCode. I need a tool that helps me search, re-sort, sift, filter and study patterns of masses amount of GUI-related information. My brain needs help. -t
** Further, you haven't described how your shared GUI engine is going to work with diverse languages. I can't easily use Swing with Python, for example. Databases have allowed '''shared services across languages''', so they may also assist doing the same with GUI's. -t

* ''"'Kind' implies a hierarchical categorization of widgets and hierarchical reuse [...]"  No, it doesn't.''
** Yes it does.
** ''I have several different kinds of ice cream in my refrigerator.  Does that imply a hierarchical categorization of desserts?''
** Kind "child" of "parent". What's the "of" for?
** ''Huh?''
** Never mind. It would probably be a long messy LaynesLaw debate.

What carries out the actions and executes events is immaterial to that user (app developer). 

[No it's not, they have to write it. They have to decide what the interesting events are, and hook them up to custom written functions that do something, like Save for example.]

It is a black box to them. Think of an HTML form with some JavaScript. (The HTML is roughly equiv to the tables and JS to the events.) The creator of that HTML and the JavaScript does not know or care whether the browser uses C, C++, or Gerbils to run the HTML + JavaScript. It may run on multiple browsers written in multiple languages and multiple paradigms. That is an implementation detail. If OO is better for writing the browsers themselves, so be it. As a custom application developer, It does not matter to me. 

[A browser is an application, but I get your point. Regardless, can't make heads or tails of that paragraph.]

It is "here is the spec". You create GUI commands/attributes based on this spec. Because OO, functional, p/r are TuringComplete, they can all be used to carry out that spec for the low-level implementation. '''One is writing to a specification, not a paradigm'''. (This sort of relates to my question below about how does a DOM user tell if DOM is OO?)

[Because the only way to access the DOM is via it's OO api. You can't use it and not know it's OO.]

''There are procedural APIs for DOM.''  

--Where, DOM, that stands for DocumentO''''''BJECTModel, it's OO by it's very design, name, and implementation?

''Yes, DOM was envisioned as an object model, yet there are still procedural APIs for it. You can get APIs in C, RPG, PL/SQL, etc. It's just like XWindows in that way. It uses object oriented programming techniques but they can be exposed via procedural APIs.''


HTML + JavaScript-events: 

 .....HTML.------------------*
 ............................|
 .........................Specification.----------.Implementation
 ............................|
 .....JavaScript events.-----*
Attribute and Event Tables: 

 .....Attrib.Tables.---------*
 ............................|
 .........................Specification.----------.Implementation
 ............................|
 .....Event.Code.------------*

(Ignore the dots. Used to reduce TabMunging)

Your argument seems to be that OO is best for implementing the specification (far right node). Is that the limit of your claim? I can't tell.

[I can't even tell what you're trying to say, but from your little legends there... I still don't think you understand how all this stuff even works.]

I don't know how else to explain it. But, it is perfectly logical. Can somebody help out perhaps? One writes GUI information against a specification and NOT a particular programming language (other than the events). It is that simple. 

[OK.... do you not understand that the DOM is the Specification, it already is that language neutral thing you're calling Specification. The DOM is a specification, that is implemented slightly differently by each browser, but is mostly the same.]

The most important difference between OO and many non-OO GUI systems is that the attributes and state are stored independent of language objects. It is not "in" the objects of the language being used, but rather an independent data structure. The independent data structure is a database, or is treated more or less like a mini-database. 

What I don't know about DOM is if the structure is in the language being used, or independent of the language. Thus, if we have:
    windowA.documentB.formC.selectBoxD[itemE].selected = true; 

[OK... that is JavaScript, but windowA.documentB.formC.selectBoxD[itemE].selected is a DOM path to the DOM objects, take away the ; and it's now VBScript, but accessing the exact same DOM object. The DOM objects are independent of any language.]

I am not clear as to whether this talks directly to a JavaScript object path, or is translated to a DOM path. Does the above change a JavaScript structure (set of dictionaries), or does it change a DOM structure? Thus, if another language, say a Java applet, wants to change "selected" back to false, would it be talking to a JavaScript object path or a DOM structure path? (Or some weird combination of both)

[It changes a DOM structure, several languages could be talking to the same DOM structure. But the DOM isn't a database, nor anything like a database, it's an object structure(a running object model), not a datastructure.]

''DOM data is a tree (acylcic graph) structure. A document has a root element. A root element can have other elements. Elements can have attributes. Object oriented programming languages make the coupling between DOM data types (elements, attributes, lists of those) and their operations explicit. You don't have to use an object oriented programming language to traverse, generate or manipulate DOM data.''

[Those DOM objects are more than just a graph, they are an actual object model, with methods and behavior not just mere nodes and attributes, and the DOM is inherently OO, slapping a procedural API on top doesn't change that, it just dumbs it down.]

''The methods and behaviors don't have to be in the same class as the data. It's convenient to organize the code that way, but not necessary. Nothing is "dumbed down" by de-coupling them.''

[Correct, it doesn't have to be, but it is because of that convenience, it�s smart to do it that way. That convenience is what makes it easy to use, so I disagree, changing that is dumbing it down IMHO.]

''I manipulated object models in procedural languages for several years. It was a pain in the ass. But I'm not convinced that object oriented programming is "the" smart way to do things. I've never seen a functional API for DOM, but I wouldn't be surprised if it was "a" smart way to do it.''

Please clarify the difference between an "object structure" and a database (not necessarily relational, nor persistence-enabled). 

[The object structure has behavior, it's more than the data contained within it's shape. Databases are just data, they don't have behavior. The object may change color when the mouse goes over it, or move and run away from the mouse for example, this isn't something you're going to do through the database. Events on a GUI happen too fast to be routed through a database, thus objects directly interact with other objects live. If a button chases the mouse around the screen, do you have any idea the number of events that get fired off to make that happen?  You simply can't do that by saving events to a table and then processing them, its not even rational to think so.]

I agree that there has to be an "engine" that processes the attributes and displays/handles them. But whether such is implemented via OOP or some other technique one cannot tell in DOM. 

[window.close() say's "window object" "close method", no matter what language you call it in, that's an object.]

Again, how can one tell for sure that DOM uses OOP. What is an example of a dead giveaway? In other words, yes DOM has data-structures and an "engine" that acts on the data-structure, but I have yet to see that it does or must use OOP. 

[It's not that it does or must use OOP... it is OOP. Document is an object, window is an object, every piece of the DOM is an object.]

Where is the sign of integration of data and behavior that OO is famous for? When one executes the following JavaScript:

   window.close()
As far as one can tell, DOM might be executing something like this:
   closeWindow(path="window")
Or, more general:
   this.is.a.path.thingy.methodX()
can be translated into:
   methodX(path="this.is.a.path.thingy")
  
   Or

   executeMethod(method="methodX", path="this.is.a.path.thingy") 
We have operations (such as "closeWindow") and the node or path in the structure being operated on. There are many ways to implement that, and OOP is just one.

[There are certainly many ways to possibly implement a DOM... none of that is relevant, since its implement with OOP already. this.is.a.path.thingy.methodX is an OO call any way you slice it.]

That is JavaScript, not necessarily DOM. As far as I am concerned, it is not really different than a file/folder call such as:
    delete /foo/bar/deleteme_txt
We could dress it up in OOP such that it would be:
   foo.bar.deleteme_txt.delete()
It is just "paths and operations". Nothing special, nothing new to OO.

As far as speed, I am talking about business GUI's, not game development. Whether DB's are too slow for cutesy stuff is another topic or sub-topic. Save it for AreRdbmsSlow.

[Business GUI's need that speed too. Business gui's have tons of little event related behavior that can't go through a database. Collapsing/expanding windows/tables/divs, appearing and disappearing elements like buttons or menu's. Dropdown menu's that slide out or in, all event related OOP type stuff that wouldn't work if processed through a database call. You honestly gonna tell me that every time you hover a menu... you make a database hit to see how to process that event? Get serious.]

I used to create Clipper pop-up menus that read from tables. Even on a 386 they were generally pretty quick. And it cached stuff in RAM such that on subsequent calls it did not have to go to disk. Any structure that does not fit all in RAM or not used in a while is going to be cached anyhow, regardless of your GUI technique. FoxPro used to store its GUI attributes in tables also, and I think it still does to some extent. Machines are getting faster and faster, allowing us to use more high-level and cleaner abstractions, such as relational. The days of pointer webs are numbered. Navigational structures are the Goto's of attributes and relationships. I find them ugly in a similar way I found Goto's ugly. If you like Goto's, I mean data pointers, that is fine by me, just don't force it on everyone else.

''Your Clipper menus read their configuration from tables. I seriously doubt they went to the table every time the menu changed. You're still talking about S''''''toreConfigurationInaRelationalDatabase.''

[What is it you don't seem to grasp about the difference between configuration storage and behavior?  Those clipper popup menu's read their configuration from the tables... but their behavior came from code, not from tables. Relational is not a higher level cleaner abstraction than code. Relational is good for one thing, data manipulation, period, code is required to anything else. Menu's are code, grids are code, widgets are code, relational and code are not competing technologies. Why must you always try to pit the two against each other as if it's one or the other?  Relational theory has zilch to do with GUI's, you can't write anything with relational theory, SQL let's you manage and query data, that's it, apps consist of a thousand things above and beyond querying of data. You need both to do anything useful and scaleable, they aren't competing!  [Gratuitous rudeness to Top deleted. Chill, guys.].]

And [I disagree, and claim you have no evidence--rudeness edited]. DataAndCodeAreTheSameThing. Code is simply data to an interpreter/compiler, and machine code is data to the chip. [Removed text that didn't make sense with insults above removed.] Like I said before, heavy-duty TOP starts to feel like interpreter building, just a custom-purpose interpreter.

* Somehow I missed it. Yes, code and data are dual. How does that apply here? Which table data becomes, in some sense, something like interpreter code? -- dm

** YEEEEESSSSSSS Yes Yes! Now you are ''starting'' to get it. The transition line between "powerful TOP" and an interpreter is '''blurry'''. We can have say 0% percent in tables and 100% in code, 50% in code and 50% in tables, or 100% in tables and 0% in code by making an "interpreter" process table-based instructions. The best mix is about 85% in tables and 15% code I would gauge. The biggest diff between TOP and most OOP is that TOP uses relational relationships while OOP uses navigational relationships. And TOP does not assume any special relationship between verbs (such as events) and nouns (objects) such as buttons. If a one-to-one association between nouns and verbs is best for the domain spot, then we can make it one-to-one. If the best choice is one-to-many or many-to-many, then we do that. OOP doesn't readily allow that, at least not without getting ugly and messy. Many-to-many is known to be ugly to manage and grok in OO. And OO does not give us out-of-the-box tools to search, sort, sift, filter, count, graph, report on, etc. all those relationships and info. Nor easily save/serialize it to disk or across the network etc. You can hand-add all that into OO, but it would be Green-Codding (GreencoddsTenthRuleOfProgramming). -t
** [MentalMasturbation reached orgasm?]
** Tablegasm :-)

* ''For a simple example, the following code could be converted to a Menu table instead, with columns such as "sequence", "title", "on_select_script".''

  addMenuItem(1, "open file", "openFile()")
  addMenuItem(2, "close file", "closeFile()")
  addmenuItem(3, "rename file", "renameFile()")
  ...

''That adds 3 menu items to one menu. Now how do you reuse that menu in multiple situations?  How do you specialize it?  How do you avoid duplicating that code?  How do you specify which menu you're adding those items to?  And how do you declare the behavior invoked by those menu items as data in tables, which seems to be what you're claiming.''

* See below
* ''Below where?  You haven't answered any of these questions below.''

There are two fundamental questions that you guys keep failing to answer:

* How does one know for sure whether a "GUI system" is OO or not? I want a clear-cut Boolean test, not fuzzy Nyggard-meets-Freud crap.

** Heh...that's funny. But it turns out that most categories are fuzzy, this is not unique to OO. Modern epistemology fixes problems with traditional IS-A relationships (A dog IS-A furry mammal with 4 legs -- is a shaved 3 legged dog really a dog?) in terms of category prototypes and degrees of well-matchedness to the category prototype (which may also be a centroid/moment/center of gravity in the N-dimensional vector space supporting it). Seriously.
** ''There is no way and end user can tell if an OO was used to write the GUI. OOP makes it easier on the developer.''
** I meant API/IDE user.
** ''The programmer can tell that the GUI API is object oriented if it provides bindings to an OO language and allows OO programming techniques. Why do you ask?''
** What if it provides non-OO bindings also?
** ''Then it also provides non-OO bindings. Again, why do you ask?''

* What is a specific example of OO "extending a widget better".

** ''"class a extends widget". What is a specific example of your non-OO GUI methodology extending a widget at all?  That's the question that started this section. "How do you specialize GUI widgets in a non-OOP GUI methodology?"  You've never attempted to answer that as far as I can tell.''

** Call a different routine. The new routine may or may not call some existing stuff similar to the old one. Overriding a method is pretty much all-or-nothing. You cannot override 1/3 of a method without refactoring the interfaces.

** ''But the widget may have 30 routines. How do I tell the compiler that these 7 are the one I want to change?''

** Sorry, but I don't understand the question. We don't use the compiler to edit stuff. That is not its job.

** ''We aren't talking about "editing stuff". We use the compiler to translate source code to machine code. We use the source code to describe the application we are creating. How do I describe a new widget that differs from an existing widget in specific ways in your non-OOP GUI methodology?''

** DeltaIsolation has too many limitations to be practical. Anyhow, provide a specific example with pseudo-code (below) and I will show you.

** ''It's practical enough that I use it every day. I've provided pseudo-code. You have not.''

** I am sorry, but I don't see your example. Perhaps give it a name such as "Example Sandra" or the like so that I can text-search it.

** ''Here's my example again: "class a extends widget".''

** All the possible features of a GUI widget are not well-modeled as a tree. '''Trees are limiting'''; they limit GUI design and creativity. VariationsTendTowardCartesianProduct. You just seem mentally hard-wired to the OO way of managing variations on a theme. It's right back to the is-a versus has-a argument. -t

In terms of this discussion, though, I think that it's pretty much purely the notion of inheritance that applies. If you can create a new widget that inherits and extends a previous widget's API/interface and its implementation, then (a) that's OO for the purposes of this discussion, I believe, and (b) it's a win to do so, since it allows OnceAndOnlyOnce and avoidance of CopyAndPasteProgramming in creating the second widget. (Others may disagree, of course. -- dm)

''Don't forget that subroutines are also to avoid copy-n-paste.''

* Certainly. Many paradigms are founded on subroutines. Make them side-effect-free and add pattern-matched invocation, and you get modern pure functional paradigm of ML-family languages such as Haskell. OO is also founded on subroutines, but where invocation is selected by the type of the first noun in the parameter list. Etc. And further, subroutines can be used to emulate any other paradigm; one can do OO programming in C, for instance, but one must do various things by hand rather than having the compiler help out. That doesn't mean that there's only one paradigm in existence, though.
** I will agree that if changes go with a "subtype grain", then OO will be more "automatic". However, my observation is that often, perhaps usually, it doesn't. Remember, I keep saying that the world does not change in a tree-wise fashion as I observe it, but inheritance expects it to. We went round and round this already at SwitchStatementsSmell and PolymorphismLimits. It all seems to come back to you guys seeing the world through subtype glasses while I don�t. Professional philosophies/taxonomists generally conclude the same thing.

''Have you ever used the C API for XWindows?  Try that for a year and then tell us why you wouldn't rather have objects. It isn't the world that forms trees, it's software developers who form trees. We do that because trees provide a convenient way to structure behavior.''

How do you know it is the only way to "structure behavior"? So far I only see ArgumentFromAuthority. C is a crappy language. Anything in C is hard. But CeeIsNotThePinnacleOfProcedural. Things like lack of named parameters drive me bats.

''I never claimed trees are the only way to structure behavior. I said trees provide a convenient way to structure behavior. I know that because I (and many others) have done it both ways. I'm not talking about the C language, I'm talking about writing GUI code using a procedural API.''

''If you want some rectangular graphic objects to have height and width and allow resizing, it makes the code simpler if that behavior can be described in one class that other classes extend. I've done it both ways, with and without inheritance, and inheritance makes the process of writing code simpler.''

I would like to see example code where this is the case. Often OOers remember the times when OO works and conveniently forget change patterns that OO made harder. I don't know where this FilterSyndrome comes from, but it exists.

''For example code, see just about any OO GUI API. Smalltalk, C++, Java, Delphi, etc.''

''You have never addressed those issues. You've never shown a simpler way to solve those problems. You say it's "personal preference", but you're the only person I've encountered with your preference and I don't think you've ever written this sort of software.''

I never claimed it was objectively simpler. I suspect it is mostly subjective. If you have any evidence that any paradigm is objectively better, then let's see it. Subjectivity cannot be objectively demonstrated, but objectivity can be, by definition. Thus, unless you agree that the differences are subjective, the burden of evidence is on you. Make sense? It might be that at the lower levels OO may be shine. I am pretty much suggesting the division of GUIs into high-level and low-level. An app developer will mostly use the high-level, and consult a GUI expert for lower-level tweaks. It is similar to VB programmers versus C++ COM programmers. The first focused mostly on the business logic, while the COM guys made custom UI thingies when VB couldn't do it. (Actually, the GuiComponentIndustry replaced many in-house COM guys.) Anyhow, until somebody provides a specific example of OO making "extension" better, we won't get anywhere.

''No, the burden of evidence is on you. You'll have to show me a better way, not just claim that one exists. I've written GUI code in procedural languages with procedural APIs. I've written GUI code in OO languages with OO APIs. The OO was easier. I provided a specific example of OO making "extension" better. You provided no example of procedural/relational allowing "extension" at all.''

* It was not specific enough. How about some pseudo-code. Note that I claimed it was "not objectively worse", not that it was objectively better. Those are not the same thing. The claimer of objective betterment has the burden of evidence. You can't escape that.

* ''Here's some pseudo-code:  "class a extends widget". You won't even show how it's objectively possible, never mind better or worse. How do I extend a widget in your non-OOP GUI methodology?  How many times will I ask before you answer?''

** It would be nice to see slightly more detailed pseudo-code for both the OO and non-OO approaches; some concreteness could help. See comments near VariationsTendTowardCartesianProduct above. 

Hmm, what would be a really clear example...someone fill one in here, I don't have a GUI class hierarchy references at my fingertips right now to jog my memory.

------

'''Units Scaling'''

Somebody brought up the issue of percentage-based units versus pixel-based units. Although there are probably many ways to do it, I would probably include a "unitType" column in the Forms entity table. The values in the various widgets would be interpreted based on the unitType of the containing form. The interesting thing to note about this technique is that one could issue a query to re-scale from one to the other without depending on the IDE because we are using a regular relational engine to manage our tables. We don't have to anticipate all the possible fiddlings because we have the power of relational queries at our finger-tips for such changes.

As far as "flow-based" or "nested" GUIs like HTML, I am not a fan of those for data-entry forms. But it is possible represent trees with relational tables. See CoordinateVersusNestedGui.

''Unfortunately, the "unit" problem is more complex than simple scaling. Much of the complexity results from the inherent nonlinearity of both human vision/perception and also display and input technology. This is particularly apparent with text, resulting in the various "stroke font" technologies (TeX, PostScript, TruType, PDF, SVG, etc). For any given font face (Times Roman, for a trite example), the relative proportions must be very different for an 8 point, versus a 24 point, rendering of comparable legibility. These problems are compounded when rotation and quantization error is taken into account. For example, a 1-pixel horizontal stroke looks significantly bolder than a 1-pixel diagonal stroke, because the effective dot-density is 70.7% of a horizontal or vertical line. The result is that computation -- in some cases, '''lots''' of computation -- has to be done when size and resolution change. And don't forget that some display technologies (specifically CRT screens and printers) have non-square pixels.''

Text is always a sticky situation. Generally in the end it is visual trial-and-error. Many companies want to jam as much as possible on a single screen, and visual fiddling is the only practical way to achieve this. One interesting approach I have yet to see implemented is to supply a bounding box for a given text element, and the GUI system sizes the text to fit within that box (could be smaller, but not bigger). If by chance it can't be made to fit, then have a little tag one clicks on to see the whole text, or perhaps a roll-over tag.

''Yup. And the dilemma is whether to specify that bounding box in pixels, radians (the visual arc subtended), or some absolute distance measurement like mm, in, or pt. When a graphic designer is doing the work (which in my experience always leads to superior results), absolute distance seems to work best. Then, an outline or stroke font is almost always more pleasing, especially since anti-aliased text looks better. And within a particular font family, the proportions of each glyph are differ non-linearly with point size. All in all, well beyond the sort of thing possible with a table-driven lookup process. A good graphic designer will see and work with similar factors in non-text graphic elements -- the same forces are at work, its just harder for mere mortals to see (in comparison to text).''

Since a table-oriented approach is a super-set of, or at least TuringEquivalent to an OO approach, I don't see this as a have-versus-not-have issue. I don't know what graphic designers do, but I am sure there are many ways to fiddle with text that most actual GUI designers never consider. I am talking mostly about "regular use", not ideal billion-dollar-gold-plated-budget projects. TeX is a declarative system, I would note. OO is anti-declarative for the most part. By the way, I disagree that anti-aliasing is inherently better. I turn it off if I can. It might look prettier, but it is harder on the eyes, at least my eyes.

''Graphic designers are professionals who specialize in visual communication. Nobody is talking about "ideal billion-dollar-gold-plated-budget projects". The Boston-area contract rate for Graphic Designers is $70-90/hour, comparable to area programmers. The differences in legibility between anti-aliased and non-anti-aliased fonts have been quantitatively measured for decades and don't have anything to do with "prettier" or "harder on the eyes".''

[You're being too hard on him. Yes, they've been measured, and yes, they're more legible, but perhaps you hadn't heard...it's also been demonstrated that, under many conditions, they are indeed "harder on the eyes" -- they can cause eyestrain, because the image is more blurry, which causes the visual system to try to find a way to focus better, which is impossible, so there's just more tension in the eye muscles. Whereas non-anti-aliased fonts have nice sharp edges that do not muck about with the visual system in those ways, even though legibility is lessened. It's a tradeoff.]

{Let's just agree that it is '''subjective'''. Studies of aggregate complaints are not necessarily going to apply to each and every individual. ''And so you'll design your programs based on your specific experience, as opposed to the aggregate?'' No, ask the customer.}

''[Doug, do you have a citation on that? In any case, the issue here isn't just anti-aliasing, though it tends to come for free. The issue is how many different pixelmaps have to be precomputed and stored to accommodate the various permutations of screen resolution, pixel geometry, color intensity, and so on for even the simplest graphic. The industry didn't settle on outline fonts ala PostScript because they thought they were "pretty".]''

[I don't have a citation handy, but note that what I'm thinking of applies to lower-resolution such as display screens at 75dpi with smaller fonts, not huge fonts (e.g. 30 point) nor high resolution (e.g. 300dpi), where anti-aliased is pretty much '''always''' a win.]

[I suspect the following misunderstands several of his points, too, but I imagine he'll address any such right away. :-) -- dm ]

''I'm certainly '''not''' going to get sucked into the "table-oriented" argument. God knows "Turing Equivalent" has '''nothing''' to do with this discussion. Similarly, I haven't the foggiest clue of what "declarative" or "anti-declarative" has to do with any of this. A rendering of a particular glyph of a particular font is non-linearly different for an 8-point versus a 24 point face. A glyph that looks "normal" at 12 point looks "bold" at 24 if linearly scaled. When a typographer creates a font, they create a variety of different faces and weights for the various sizes. If you have persuaded yourself, or can persuade a client, that pre-computing all the possible outcomes of all the possible permutations is "better" (whatever '''that''' means) than computing it as needed, then by all means go for it. I would suggest, though, that you first of all learn more about what graphic designers do (since you profess to not know, and it matters in this case) and second of all do some order-of-magnitude estimates of just how many table lookups you're contemplating.''

Oh, so you are saying that "tables are too slow". Why didn't you say so? How about first we do a survey on how many current GUI engines do complex "font math" (excluding stuff farmed off to the OS).

''As I said, I don't have a dog in the "tables are too slow" race. You build your user interfaces (graphic or not) from tables, I'll build mine with my graphic designers. We'll each achieve whatever commercial (or otherwise) success we achieve. Fair enough?''

What exactly are we comparing here? When a graphic designer is done, what does the electronic result look like?

----------

OO GUI systems tend to be tied to a specific language. If you untied it, then you would end up with a NavigationalDatabase more or less. For example, DOM (DocumentObjectModel) seems to be tied to JavaScript to some extent. I don't think it would be easy to hook a statically-typed OOP language into DOM, because of DOM's dynamic nature. Java or Eiffel, for example, would have to treat DOM more or less like a database.

''You just don't have a clue what you're talking about do you?  I hate to sound mean, but you seem to write oodles of text and yet nothing comes out, your hatred of OOP wreaks in everything you write, yet you don't even seem to understand what the hell you're talking about. ''

If I am, I am not aware of it. Perhaps I am the stupid ignoramus that you make me out to be. If so, I am not aware of it, and an internal "self-diagnostic" does not show any significant problems. Sometimes there are communications difficulties, but that is only because English is not the best tech language or one or both of us are simply not conveying thoughts clearly enough.

''Like I said, I'm really not trying to be mean or anything, but I think you don't really have a firm grasp on the topic. I think you should really listen to what some of these people are telling you and study the topic some more, you are way out of your element here, and I apologize for being so blunt above.''

''The DOM has nothing to do with JavaScript, the DOM is a library to manipulate HTML documents, JavaScript is but one language that can access that library.''

You are perhaps right. I thought DOM was influenced by JavaScript, but I may be mistaken. My point still stands regardless. What shaped it is historical only. It is what it is. Any GUI system that is not tied to a specific language is more or less a database of some sort, or at least accessed like a database, usually a NavigationalDatabase these days. The DOM interface is basically a navigational interface. Note that navigational systems are not necessarily OO.

[You're confusing tree structures with databases again.]

Would "big structure" be better? It is still:

    Language <-------> Structure <--------> UI Display

Not conceptually really much different than: 

    Language <-------> Database <--------> UI Display

(With an API or query language in between for the language to talk to the structure/database)

The thing is, multiple languages may have to talk to the structure. For example, Java, VBscript, and JavaScript may all want to talk to the same DOM model. At that point it starts to be like a lite-duty database rather than a "structure".

''The DOM is not a database, not comparable to a database, and not like a database. The DOM is a structure of objects representing the objects displayed on the screen. The "DocumentObjectModel" is a structure of active live objects, that have behavior, and interact with the user, interact with each other, its not a database or anything like a database. In fact, the "DocumentObjectModel" is the UI, are you now saying the database is the UI?  Also, databases don't talk to UI's, and your Language <-------> Database <--------> UI Display would really look more like Database <-------> Language <--------> UI Display.''

* Even if one were to implement UI calls as part of a StoredProcedure, one still has to write the StoredProcedure in ''something''. That might look like HostLanguage <--> Sql <--> Database <--> ??? <--> UI. What would be a good choice for a StoredProcedure language?  The HostLanguage is an obvious choice if you use a NimbleDatabase...

* On something like IE, DOM cannot be "the" UI because it has to go thru Windows API's.

* Re: "The "DocumentObjectModel" is a structure of active live objects, that have behavior, and interact with the user". How does a user of the DOM API's know if it is OO or not? Yes, something carries out action based on attributes set in DOM, but that does not necessarily make it OO. I have seen nothing yet about the DOM interface that is clear evidence it must be implemented in OO. (See above)

* There seems to be some confusion above about the relationship between the database and the final UI. I don't know how to clarify it in a single paragraph. I may have to work up an example.

----
Is IBM's CUA still around? If so, it should be included
-----

Why on GodsGreenEarth does the issue of OOP/non-OO have ''anything whatsoever'' to do with such issues as font anti-aliasing and the like?   Why is it even mentioned on this page?

''Good question. Perhaps it deserves its own topic. My impression was that it is implied that relational engines are too slow to handle certain kinds of font calculations.''

* What, are the fonts (typeface descriptions) ''themselves'' stored in a RelationalDatabase?  Even TopMind is too smart for such UniformityUberAlles... sounds like a StrawMan that someone erected to me.

** ''If speed is not an issue, then why not? Vectored fonts have to be stored in some kind of structure. However, because such information does not change much, I don't care either way. Note that I did not originate the font issue. Thus, if there is any perceived or real mallice in mentioning fonts, it is not I to finger. -- top''



'''Basic Menu Table Example''' (continued from above)

  Table: menuItems
  ------------------
  menuItemID   // could be auto-number or pneumonic
  parentRef  // parent itemID, null or zero for top
  sequence  // Float - order in the menu
  itemTitle
  onSelect  // script or code reference to run upon selection

  Table: window
  -------------
  windowId
  menuItemRef // reference menuItems table
  windowTitle
  ...

To reduce tying our sample system to any one language, lets assume we send XML for any actions. (One may want to wrap the XML with their favorite language. I will not assume wrapping here.)
 
  <openWindow id="window7">

In our event cells (such as "onSelect" above), one might have something like:

   // open foo window
   if (zaz == grazz) {
     guiXML('<openWindow id="window7">');
   } else {
     guiXML('<messageBox value="Sorry, zaz is not correct">');
   }

''What is this supposed to demonstrate?''

Somebody wanted more details, so I supplied them. They wouldn't supply specifics, so I thought I would try to spark something.

''You're still demonstrating how to store configuration in a relational database. I think we all understand that. These questions remain unanswered:''

* ''How do you reuse that menu in multiple situations?''
** It is data. You reference different menu roots/tops in different situations. See the "window" table schema.
** ''Sorry, window has nothing to do with the topic. You need a menu table and a menu item table. I can see how you define one menu and several menu items, then reference the menu in multiple situations. Is that what you intend?''
** You are right. We need a Menu table. I was thinking of another approach, but it has too many downsides.
* ''How do you specialize it?''
** For what? Example please.
** ''I have a menu with items A, B and C. I want to make a specialized menu with items A, B, C and D, and another with A, B, C and E.''
** I think for menus it is better just to copy them (content) rather than try to reference them. They tend to grow apart over time. We could have a many-to-many association to reference given menu sets from multiple areas, but I don't see a real need for such.
** ''I didn't ask how to copy them. I don't have to copy them with OOP. I shouldn't have to copy them with any other technique. If they grow apart over time, so be it. Right now I want to reuse the code.''
* ''How do you avoid duplicating that code?''
** I have yet to see a need to duplicate anything here. We are just feeding a different ID to the same routine/utility.
** ''We haven't seen duplicate code because we haven't seen how you specialize widgets yet.''
** Covered below
** ''Where?''
* ''How do you specify which menu you're adding those items to?''
** It is a tree. You can reuse sections/branches if you want or you can reference different ones. I suppose we could have an "application ID", but it may not be necessary. For the sake of these examples, lets assume that each app has its own database.
** ''You lost me here. What does application ID or database have to do with specifying which menu the items appear on?''
* ''How do you declare the behavior invoked by those menu items as data in tables?''
** Lets assume it passes the script snippet in "onSelect" back to the app language to do an "Evaluate()" on it. Generally there will be an "event" dictionary array that provides useful information to the snippet if it wants to use it.
** ''So you don't really declare the behavior as data in tables, you declare it as code and store the code in tables.''
** Yes. It is roughly analogous to HTML that as "onClick" attributes in HTML tags. However, repeated behavior can often be converted/refactored into attributes. For example, if we have a lot of code that says "if blank(item) then warning_message", we can create an "isRequired" flag attribute instead.
** ''Creating an "isRequired" flag doesn't convert or refactor behavior into an attribute. The behavior (i.e. what the computer should do when isRequired is true and what the computer should do when isRequired is false) is still code. I'm asking how you propose to organize that code so that it isn't duplicated and how do you specialize that behavior when needed.''
** "Specialize" is OOP thinking and essentially hierarchical (DeltaIsolation). It's not a powerful enough concept. "Good enough" for some cases, but not the ideal. There are different ways to handle "variations on a theme", and which I'd suggest using depends on the situation. -t

Note that any attribute can be set with XML similar to:

  <setAttrib window=[window ID] widget=[widget ID] attrib=[attrib name] value=[value]>

If there is an operation that is done often, then one can make a shortcut wrapper for such. If setting a window attribute, then widget-ID is not needed -- top

Top.... none of that is building a GUI, it's configuring one. Everyone on this page is talking about building new gui widgets, and you're talking about configuring existing gui widgets. Your code demonstrates that you are using an existing menu system, your code does nothing but configure it. EVERYONE else is talking about the actual menu itself, how it was built, what paradigm was used to build it, alternative approaches to building them. We don't give a crap how they're configured once built, we're programmers, and it's the building of the menu itself that interests us. You keep trying in vain to show us your way, and what you fail to see is that we understand your way, we understood your way years ago when we first started programming, but we've moved far beyond just simple configuration of existing widgets that someone else wrote. 

People here are talking about building widgets, not about using someone else's widgets. I don't know how else to say it, several people keep telling you we're not talking about where to store the configuration data, and you keep offering up your configuration approach. In all likelihood, that menu you are using is an OO menu, so it doesn't fit with the page topic. If you want to participate, show us something that is a menu system, that isn't programmed in OO. Databases are totally not relevant to this discussion, nor are tables or anything else you've shown, because that's all configuration. Your arguing with people and your the only one not in on the actual topic. Would you feel better if we say OO gui's are often configured via a database?  Big whoop, any first year programmer knows that, it's just data, doesn't matter if it's in an INI file or and XML config file or a relational database, it still has zilch to do with building the components that are used to make GUI's. 

You like procedural so much, show us procedural code that actually makes a menu system, or a button or a textbox or a dropdown list, hell, show us anything other than how you configure existing systems, because we don't care about that. The truth is I don't think you can, I think as usual, you're in way over your head in this conversation and simply don't understand what most of us are talking about. So I'll give you a sample... you need to extend the textbox widget to make it a datetextbox that has a popup calendar beside it and only allows valid input between specified ranges and formats the date while the user types it?  Now show me how to do that with a table?  That's what Doug's talking about when he asks about how to specialize it? That's what we all mean by building GUI's and that's what I think you don't seem to grasp. -- AnonymousDonor

First off, I would probably look for an existing product instead jumping directly in and re-inventing the wheel. Example:

http://www.infragistics.com/products/classic/calendarwidgets.asp

It is called "reuse". Perhaps building or distributing a calendar widget like the above from scratch would be easier under OOP. However, it is not something an application developer has to do very often in my experience. In the past, such was either a one-off need that I would create out of existing components, or there was a commercial component from the GuiComponentIndustry available. Thus, the chances of needing such a custom widget in multiple spots AND there not being a commercial one available are rather small. It appears the more likely it is to be used in multiple places, the more likely it is a generic need that has already been filled. If neither of these were the case, then I would go ahead and include a hand-built one into the framework, perhaps even having to add new case statement entries in multiple spots (The Horror!). I perfectly agree that under SOME conditions OOP makes some changes easier. But they are generally infrequent, and don't counter the down-sides of OOP. SoftwareDevelopmentIsGambling, and the polymorphic horse does not win often enough.

Also, I am generally approaching this from an application developer's perspective, not a widget builder's. You seem to think that actual packaged widget builders are somehow more dignified or "high-level". Personally, I think widget building is more likely to be offshored because generic widgets can be described relatively easy in specifications and are not as close to the end-user.

''I'm an application developer. I also build new widgets. These are not separate job descriptions. There's no way I'm going to offshore a simple task like making a new kind of frame or combo box. It isn't worth the trouble to bill an offshore developer for (at most) 20 minutes of work.''

You guys keep talking about how behind all the wonderful tools we use is usually OOP or should be OOP. That may indeed be the case. Maybe database engines are best written in OOP also. I don't care because I am a custom business application developer. I don't see where OO helps more than it gets in the way from this perspective. Perhaps we should split this topic into high-level GUI issues and low-level GUI issues. 

Further, OOP makes it harder to have language-neutral GUI protocols. Separating behavior and data simplify making something cross-language because data is more transferable than behavior, and intertwining them drags them both down to behavior's limitations. -- top

Ok, so we seem to have reached a certain degree of agreement here, and identified differing concerns.

'''Attempted summary.''' Top is concerned with "high level" issues, in other words, use and configuration of widgets. He advocates reuse and avoiding reinventing the wheel by e.g. buying commercial widgets. He thinks that a need for truly custom widgets is rare, and that widget builder's are in danger of off-shoring.

OO advocates seem to agree that tables/databases are useful for widget configuration, but may wish to argue about how often truly custom widgets are needed and whether they're going to be off-shored.

The OO side of the argument has largely been concerned with the question of creating new custom widgets, which Top here labels "low level", so it would appear that a lot of the conversation has been at cross-purposes.

Top then returned to more general themes about OO. At this point it seems quite possible that 100% of the table vs OO discussion could be moved to a page with a title that doesn't include "gui methodologies", to be more descriptive.

Earlier Top also raised several times the well-worn theme that there is no perfect hierarchy, which I agree with, but thinks that this means that OO inheritance hierarchies therefore have more drawbacks than gains, which most of the OO crowd disagrees with. (Note that the LOC and Dewey Decimal Systems also face the problem of being imperfect hierarchies, yet are still quite useful for libraries).

''It is not so much hierarchies but polymorphism and encapsulation in this case. Widget makers pretty much just follow a protocol instead of inherit existing functionality I suspect. -- top''

Top however has made some fairly rare concessions: that OO may be good for a number of things...but not for the "custom business applications" he develops.

My response to this is that 99% of the work on OO and OO-related Design Patterns occurred in that context, not in e.g. systems programming nor scientific programming, so this seems dubious -- and in any case diverges from the previous topic of this page.

''In my opinion Design Patterns are an (failed) attempt to solve the messes created by OO. At least GUI widgets somewhat follow the simplicity of the device driver examples found in TextbookOo. Low level GUI stuff tends to fit device-driver patterns, and that is why OO may be helpful there. Each widget is like a little device. Design patterns seem to write off that simplicity. But I suppose that is another topic. ''

Lastly he says "OOP makes it harder to have language-neutral GUI protocols". I don't think I understand this, although I have a couple of guesses as to what that might mean.

''I will see if I can articulate this better.''

Anyway, it seems like we can shift the perpetual tables vs OO argument to a new page on this note, yes? After which, any material not transferred to the new page would in short order be game for refactoring on this page - very little of the argument probably should survive here, rather than being moved.

-- DougMerritt

''Thanks for your attempt to summarize. I disagree with some of it, but it appears you made a good-faith attempt to be even-handed, so I appreciate your effort. -- top''
---------------------
Footnotes

[1] In the custom round volume knob example, if the GUI is being partially controlled over the network (such as a GuiService), then it may not be realistic to manage such a control from a server because of latency. To get a reasonably-smooth animation of a turning knob as the mouse drags would require approximately 10 send/receive update cycles per second. Obviously, it's not realistic to rely on such frequency over a typical network. (X-windows suffers from a similar problem.) Either we rely on an existing widget, such as a slide-bar control, or have a mechanism to download the implementation to the client GUI system. -t

''As an author of widgets, I can state with confidence that your concerns -- at least in terms of distinct behaviour between a volume knob and a slide-bar control -- are largely unfounded.  A volume knob is not appreciably different from a slide-bar control, and indeed the two may well share a common parent class that defines most of the functionality for both.''

I think you misunderstood my point. The slide-bar is a common "built in" widget in most kits (at least the non-lite versions), meaning it comes out of the box in most cases. If we have to implement a custom volume knob and update the animation across the network, then we can't use the built-in one.  I suppose one could implement a generic "range control" interface, but how to handle the animation across the entire range can be tricky. If you say pre-define a "rotation" action, then a given image of a knob can be rotated, but there are at least two problems with this:

* A: One has to anticipate all motions up front when building the interface in order to make the "motion-type" a parameter. This may limit the motions. If somebody later thinks up a shrink-and-grow range widget, or a pump-up-or-flat ball widget for a sports motif, or a Michael-Moore to Ann-Coulter morph for a progressive-to-conservative range knob, they can't use the existing motion-types unless one can predict and implement them all up front. It's expensive and anti-YagNi to try to forecast all possible motions, and probably futile. Some could be formula-driven, but then you have to find a way to make the formula interface and interaction be language-neutral.

* B: Simple rotation of an image looks artificial on many types of knobs. The highlights tend to stay at the same angle, not the angle of the volume/range change. Sure, this can be anticipated before release, but then you have an expensive BigDesignUpFront. And other range animations may have related shading problems, but with different motions. You can't solve it in the general sense.


There are at least two approach to complex slide-range widgets: use some mathematical transformation, such as Rotate and Scale on an existing or calculated image, or present an animation series for 0% to 100% (normalized). You may need several dozens or more of such "movie frame" images for a "clean" animation transition and sufficient precision. The formulaic transformation approach complicates the multi-language interface goal, and the animation approach can be a bandwidth hog if not managed carefully. I'd lean toward the animation approach.

A basic slide control probably just re-positions a fixed "knob" image against a fixed back-ground slider "rail" image rather than have a different image of the entire slider for each level. The knob itself stays the same throughout the entire range, other than position. But this won't work for fancier designs, thus you are not correct. (One could implement a basic slider with using an animation frame for each range, but it's not the most resource-efficient way to do it.)

''I think you misunderstood my point.  In good OO-based widget kits, you can quite trivially inherit the volume knob from the "built in" slider or from the slider's "built in" parent.  I have done this several times, with different kits.  It's not difficult -- certainly nowhere near as difficult as your speculation appears to make it.''

Please present an example, such as configuring the pump/flat sports ball slider. You seem to be making an unstated assumption somewhere. Inheriting "magic" is easy, the hard part is implementing it. 

''You want me to post a gaggle of Java code?  A volume knob is easy. It's a dynamically-drawn circular scale around a static circle with a dynamically-drawn tick for a knob.  There's no "magic" to it.  Don't know what you mean by "the pump/flat sports ball slider."''

----
''Staying with the volume knob scenario for the moment, how would this work as a GuiService? How would the service work with different languages? If everything is born and dies in Java, things are relatively simple. But I'm tossing that convenience into the trash for now.''

It would be straightforward to define a protocol by which GUI definitions and activity could be communicated to and from the endpoints in some client/server architecture.  Essentially, the X Window system does this.  You could probably build a language-neutral GUI system along the lines of GuiService using CORBA.  However, I question its value.  It's far more common -- and perhaps justifiable -- to use native GUI code plus domain functionality on the client side (e.g., HTML5/Javascript), with an application-specific application protocol (often built using JSON or XML) to communicate with an application-specific server (written using Java, C#, PHP, whatever.)  This allows you to manually optimise overall application performance by locating application functionality where it belongs:  Presentation and user-interaction stuff on the client side; data processing on the server side; and minimised data transfer between them.

Far more interesting, however, would be to create a general-purpose distributed application development platform, and associated language, to support automated optimisation of distributed functionality in general.  Why limit yourself to just the GUI?  Rather than specifying that the GUI runs over ''here'' and everything else runs over ''there'' and ''this'' is the protocol between them, you would specify the application in its entirety as an application-architecture-neutral definition.  The optimiser would then decide -- in a manner invisible to the developer, and probably entirely at run-time -- what code runs where: on clients, on servers, on you-name-it.  A benefit of this approach would be the possibility of targeting a multitude of run-time platforms and architectures with a single application definition.

''Your solution appears to be continue client-side-centric GUI's. X-Window suffers latency problems over HTTP because it's too low-level. And, I don't believe in the value of distributed applications for most apps, I have to say, other than maybe as an emergency spare or load balancing. Security and configuration is simpler if you can limit which server(s) stuff runs on. Configuration effort and security are bigger costs/problems than CPU cycles in most apps.  App tools are not commoditized enough to have them hop servers willy-nilly yet. ''

I don't know what "client-side-centric" means.  You seem to suggest a return to a classic, centralised, "mainframe-and-terminals" architecture, which is fine for certain problems but only scales well in limited directions.  Distributed architectures generally scale in more directions.  However, developers currently need to be aware of the architecture in either case.  What I propose is elimination of developer concern for architecture, because that should be the automated optimiser's problem.

* ''I'm not sure what you mean by "mainframe-like". Mainframes never had GUI's. If you mean like OracleForms, then perhaps. They came somewhat close to getting it right, actually. And, I don't know what kind of "scaling" you have in mind. What problem is "distributed" a solution to? Distributed adds new problems that centralization and semi-centralization doesn't have to worry about. Unless there are clear benefits, why suffer its downsides?''

* I mean mainframe architecture, i.e., centralised and monolithic with dumb or "smart" terminals.  Most conventional Web apps are that, of course.  Essay question: Are there more similarities than differences between (a) conventional Web-based applications, and (b) mainframe infrastructure using 3270 display terminals?  Discuss.

* Distribution only adds new problems if you use the wrong tools.  Or, you distribute the wrong stuff, i.e., you have poorly-considered architecture.  As I noted above, an architecture consisting of HTML/CSS/Javascript+Browser on the client and PHP|C#|Java|Ruby|C++|Whatever + SQL on the server works quite well.  However, it does involve an awkward collection of languages.  Therefore, I argue that HTML/CSS/Javascript and PHP|C#|Java|Ruby|C++|Whatever + SQL should only be emitted by the compiler or interpreter of an architecture-agnostic application development language.  No one should have to write in such horrors, except the implementer of the architecture-agnostic application development language, of course.

* ''I don't believe it's trivial to add distributed to the feature list. If it was, sure, toss it in. If not, let's make sure we really need the benefits it gives before taking up drawbacks and complexities it introduces. And a "master compiler" that generates the HtmlStack etc. languages automatically would probably run into version problems on both the client and the server. It may generate version X Ruby, for example, but the actual server(s) is using version X+1 or the like, and crashes. It would probably be simpler to make a new browser or browser plug-in in my opinion; almost like open-source Flash. I'm skeptical one could herd that many languages.''

''The problem with HtmlStack-based solutions is that there are too many languages involved, and too many client version variations. It's language and version overkill. It's generally easier to tame servers than clients. And it wasn't originally designed for GUI's. I agree that for custom widgets that fat-client approaches may be necessary to get decent performance on the client, but for most business-oriented apps, I see no reason that an HTTP-friendly over-server protocol can't be provided to do at least 95% of a typical GUI. Desktop GUI's have been around for almost 20 years now: we know what's needed and what works as far as GUI techniques and standards for biz apps. Most of the changes have been eye-candy fads.''

I agree that HtmlStack-based solutions suffer from a festoonment of languages.  My proposal offers a more general and broader solution than yours, with potential for greater flexibility and performance.

''Perhaps have it so that if the client can't implement a fancy volume knob, then allow it to use a generic slider in its place. For example, if the server detects that the client is Internet Explorer 8 or 9, it's safe to use the fancier slider/knob, but for the rest of browser-space use the generic slider. Another reason to switch off or block client-side custom widgets is security. See NtcSecurityRant.''

Such decisions should be left to the automated optimiser.

''Maybe when true AI finally comes out and taps the Universes' black holes as an energy source; and it can then test all the product versions for every combination.''

If that works for you, great.  I'll probably stick with having the compiler emit a few appropriate "if (navigator.appCodeName == ...)"s in the Javascript.

''And how would the compiler know that a feature has a bug in it for a feature combo only needed by your company?''

Huh?

''If an "optimizer" was smart enough to detect bugs and propose work-arounds, then it would probably be AI. Otherwise, how would your compiler know that putting more than 4 volume knobs on the same row happens to crash Opera version 6?''

It wouldn't, until a human recognises the problem and puts appropriate rules in the compiler's optimiser.  It's the same way programming language compilers currently deal with processor-specific issues.

''That's seems a bit too specific and "twiddly" to hard-wire into a "compiler". How would one keep it up to date with all newly-found display bugs for multiple vendors and versions? It would possibly be cheaper to pay Opera to fix it. Plus, we'd be behind the fixes too.''

Fine.  It was merely an example.
----
See also: TablesAlreadyExistInOop, TableOrientedGuiDiscussion

NovemberEleven