Gui Configuration
Gui ConfigurationManaging 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...
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?
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. ;-)
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.
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.
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:
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.
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:
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 "StoreConfigurationInaRelationalDatabase". 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]]
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.
[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 DocumentOBJECTModel, 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 StoreConfigurationInaRelationalDatabase.
[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.
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.
Don't forget that subroutines are also to avoid copy-n-paste.
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.
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.
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.
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:
<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 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 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
EditText of this page
(last edited August 27, 2014)
or FindPage with title or text search