Some (mostly) language-neutral GUI engines, although the language-neutrality is always within constraints:
* MozillaXul + XpCom (Used by Mozilla and the Gecko rendering engine)
* UNO (Used by OpenOffice.org)
* COM/ActiveX (Used in many Microsoft products, famously in VB)
* Avalon, once released? Accessible via any .NET language
* XForms, while not really a "GUI engine" as I would use the term, seems to provide what Top is looking for on this page.
* TIBCO General Interface (http://www.tibco.com/devnet/gi/default.jsp)
EditHint: Merge or move this list to RemoteGuiProtocols? Plus, the list does not belong at the top in my opinion.
----
Desired features:
* Language neutral - Easy to port API's and/or use markup with many different languages
* HTTP-friendly - Usable over HTTP and reasonably latency-friendly, such as not requiring each key-stroke to travel both ways before a character appears, as found on HTML forms.
* Minimal reliance on client-side scripting or execution, but still has such ability if desired.
* Targets mostly business CrudScreen''''''s, since the existing standards are fairly good for e-brochures.
** Top clearly has an agenda. I'd want something good enough for distributed videogaming, so I could put everything from CrudScreen''''''s to full-blown map-based applications and tele & videoconferencing on it. I.e. an InteractiveSceneGraph language, and an associated browser.
** ''You have a video-gaming agenda.''
** Incorrect. I have a "low-latency distributed-system updates plus 3D and audio and new input devices beyond the limited keyboard+mouse" agenda. This requires design towards optimization and caching support as well as some very flexible and mutable scenegraphs. It just happens that targeting distributed videogames gives me everything I want: any solution "good enough for distributed videogaming" will handle everything else by necessity.
*** ''I disagree. Biz-friendly widgets are hard to get right. A gaming company wouldn't have any motivation to do them right. Making prettier explosions and sparkling blood is not going to help get a decent TableBrowser.''
*** I'm not asking a gaming ''company'' to create a ProgrammingLanguageNeutralGui and you aren't asking businesses to do it either - you've tossed the idea to the open community for a reason. And Biz-friendly widgets aren't especially difficult; video-gaming systems that provide interactive HeadsUpDisplay''''''s (meaning most of them) invent such things repeatedly. Such things are used for a variety of purposes, including inventory management and status summaries. There is much more to videogames than prettier explosions and sparkling blood.
*** ''Anyhow, let's agree that we need better GUI and graphics standards for many different uses. Biz use is one of many.''
*** Certainly.
** ''Java applets should be good enough for teleconferencing because the interaction is limited once started.''
** And Javascript+AJAX+HTML should be good enough for your CrudScreen''''''s. That doesn't make these into satisfactory solutions.
** ''So far they are not good enough. If they someday prove good enough, this may change.''
* Open standard
* Include an event-handling vector language (nice to have, but not a requirement). This could also be used to add custom features not part of the standard widget set.
Open Issues
* What measurable benefits, if any, would 'programming language neutrality' presumably offer?
* How is neutrality measured or qualified? What constraints on the GUI language is implied by 'programming language neutrality'?
* Can it be done, or to what degree?
* Compared to known alternatives, how do the alleged advantages of 'neutrality' stack up? Is it worth doing?
* How likely would it be to have something like JavaScript and plugin-objects hacked in atop of it, thus defeating the 'neutrality' concept? How often would these be used?
** ''Please clarify "hacked in". Ideally, and orderly approach to interacting with app languages would be devised. If many feel a need to "hack" lots of back-door links and intrusions into the guts, it may be a symptom that some feature or interface is lacking.''
** By 'hacked in' I mean that they aren't designed into the system in such a manner that they interact in an orderly manner with all elements processing the language (e.g. if javascript and plugins were "designed in", then CascadingStyleSheets would influence them, too). I agree that hacking in links is a symptom of missing features (MissingFeatureSmell). The question, though, is whether the "missing features" can be fixed in combination with 'declarative' and 'language neutral', or while maintaining a distinction between 'GUI language' and 'app language'.
* Will it use API's or a markup language or an InteractiveSceneGraph language or something else?
* How to handle CoordinateVersusNestedGui - Support both kinds? What about ZoomableUserInterface?
* How to handle real-time updates
** ''such as how often or when to refresh?''
** Polling is one option, but is a very inefficient option in terms of both performance cost (bandwidth, message counts) and final performance (latency between update and seeing it). That is, it is the most expensive and worst performing of the practical options. Subscriptions and events are a better choice for both performance cost and performance, but are more complex for implementation. Thus, the question is different than 'how often to refresh'; it really is 'how to handle real-time updates'.
** ''For most actions, a refresh is only needed when a button or menu is pressed (if designated to wait for it), which would probably be a typical POST transaction in HTTP. Polling may be sufficient for the rest of the cases. I envision that a given event, such as "on-click", is designated either "wait" or "no wait" at the client side. "Wait" means it waits for a response from the server (hour-glass) until it receives a response, which may contain a REFRESH command.''
** I must strongly disagree. It would be far more ideal to be able to, say, see updates to WikiWiki and CRUD-screens and forums in real-time as other people interact with the resources each document represents. And that's even before we're working with more interactive GUIs. Are you imagining a world where the user is the major source of updates that are useful to observe? Sorry, but that world died shortly after the Internet was born.
* How to handle enough separation of content and presentation to support non-standard output devices (e.g. small mobile phones, screen readers for the blind) and styles (some equivalent to CascadingStyleSheets).
* How or if it can take advantages of particular app language features.
(Similar lists are given below. This topic needs a refactoring.)
----
This page is mostly Top arguing with people again.
''I am just trying to collect ideas, definitions, etc. about the concept. I did not mean to start arguments. I find it an interesting topic to ponder. Many GUI's seem too tied to languages, and I wonder if that is an inherent need, or bad industry habit. If you don't find the topic interesting, then simply don't read it or contribute. Generally, arguments are a sign that the topic needs further exploring, clarification, etc. Whether you like my content style or not, you have to agree that the topic is an area left wide open so far. -- top''
It'd be nice if when you collected ideas and definitions you paid more than passing interest to what other people were saying, then. The topic is NOT an area left wide open - the way you phrased it and named it made it an oxymoron to begin with. The argument here was not one over the fundamentals of GUIs, but with you and your redefinition of/misuse of terms. There is no such thing as "Language neutral GUI engine". There is no such thing as a language neutral engine at all. Computers just don't work like that. You *must* have a common protocol for calling into each other, which *always* requires explicit support at both ends of the channel. Happily, there is a de facto standard calling convention, which is C. What you seem to want is a standardized GUI declarative language. This is fine if your needs are limited to the functionality provided by whoever designed your markup language. HTML is an excellent example - you can extend it via DHTML. But you can't implement DHTML in any language you want - you must implement it using one of the languages supported in the browser. And the browser must explicitly support and allow you to do so. This is not language neutrality!
''First off, I am not proposing (only) a markup language. The interaction would be an important part of it. Second, as described below, '''"language neutral" is probably not a Boolean concept, but that is not a reason to not try to reduce dependence.''' Nor do I think C bindings are necessarily the way to go, since one cannot easily bind across HTTP, for example. But if you can show it absolutely necessary, then we've learned something. By the way, which alleged definition are you bothered by? I do agree that we may need to create some working definitions to avoid confusion.''
You cannot have an interactive environment and still maintain anything resembling "language neutrality". What part of this is so hard to understand? Spend a few minutes thinking about ways to implement the concepts you're thinking of and you'll see what I'm talking about. By the way, it's pretty trivial to wrap C function calls in SOAP and tunnel them over HTTP. It can even be mostly automated. Of course, the same applies for pretty much any RPC wrapper. And, as a defacto standard, a C API is as close as you can get to "language neutrality". The term is still ridiculous, but I'll assume it means "accessible as easily as possible from the most languages".
''If you have specifics of how to do it right or proof that it cannot be done, then please present those specifics. Your criticisms are not specific enough for me to use or to change my responses with. I will happily fix my suggestions if you provide the proper details. I've been thinking about language-neutral HTTP-friendly GUI approaches since about 1996 and have mentally tested my ideas on the various projects I worked on since that time. True, that's not as good as a live test, but DontComplainWithoutAlternatives. The point is that I reject your claim that I've not thought about it carefully enough. You have yet to point out a *specific* flaw that is not fixable.'' -- top
The *specific* flaw that is not fixable: the 'neutral' is impossible. Even mostly declarative 'markup' languages like HTML require considerable framework to be used from any given language or platform. Further, existing GUI languages have repeatedly proven to be insufficient for interactive designs - a fact that observed by examining the need for plugins, hacking in scripting languages, etc.
An alternative: take the exact opposite approach. Create a rich language that supports mobilizing code to reduce latencies and improve interactivity and specialize caching to the domain. Instead of shunning rich language features because their implementation isn't friendly to a given language, accept that you'll be implementing and porting frameworks across the common platforms and languages. With the 'neutrality' constraint released, focus on LiberatingConstraint''''''s more useful to achieving rich user interfaces. Such constraints include capability security to allow rich mashups without loss of privacy, distributed transactions to allow composition of remote services without race-conditions, separation of content and presentation to support the handicapped, requiring ZoomableUserInterface with level-of-detail to reduce bandwidth consumed by objects not under immediate attention, demanding termination guarantees and confinement and type-safety for certain classes of operations in order to allow a variety of optimizations, and in general support minimal-latency real-time updates to observed objects as other users interact with them.
The cost of this alternative is that it is ''slightly'' even more unfriendly to one-off implementations compared to, say, one-off HTML processor that neither reads nor introduces and blocks.
To answer this cost, one implements and ports a framework and the associated protocols to the different platforms and languages that demand it.
That, to me, is a fully acceptable payment for a richer GUI.
------
[context missing due to unknown change]
Well, that's one way to do it. Functions and declarative approaches are more portable across languages in my opinion and good GUI engines should be language neutral. But, I don't want to turn this into a "my GUI framework can beat up yours" battle. There are already topics on that floating around here somewhere. -- Top
''There's no such thing as a language neutral GUI engine. The absolute best you can do is serialization to a common file format (HTML, for example) which is displayed by the engine, but you then give up *any* sort of expandability or dynamic functionality not built directly into the engine. When people say "language neutral", they usually really mean "has bindings for the language I prefer", which usually (but not always) is the same as "is written in C"''
I disagree.
''Oh, so there is a language neutral GUI?''
I have not seen an actual case, but feel it is possible.
''Oh, so now you agree, and contradict your previous statement. Make up your mind top, either there are or aren't language neutral GUI's.''
I don't see a contradiction. And, your tone is unnecessarily combatively.
The possibilities to explore are:
* Is it possible?
* Does it exist?
* Are the concessions to make it neutral worth it?
* If full-neutrality is not possible, then are compromises possible and usable?
'''Doesn't X-Windows almost do it?''' Let's explore some possibilities.
First, although I don't like "path-oriented" GUI's, I won't rule them out because I don't want to get into that debate here. Plus, my preferred approach (not described here) can still work using paths. Thus, there is a path to each widget and each attribute. Here are some example API's:
x = getAttrib('formX.textBoxFoo.content'); // get value of text box contents
setAttrib('formX.textBoxFoo.content', 'Hello Neutral World!');
refresh('formX'); // draw in our changes
But most of the GUI setup would be done using XML or some other text protocol. For example, to load a GUI model, we might have something like:
loadGuiXml('root/guiModels/myGui.xml'); // load a file
guiXml('');
Or perhaps
guiXml(filePath, protocol='file'); // same as above
guiXml(' 200 and my_boss_is_not_drunk_today()) {
giveFocus(view_panel="myPanel", form="form34")
}
}
This does pretty much the same as the first example, but allows complex logic in between and has a latency cost.
-- top
----
'''This is start of HTTP related discussion'''
Many of the existing GUI kits like Tk and X are not HTTP-friendly. A "modern" GUI kit needs to have "latency-assistance" features so that things doable in "declarative mode" or "local mode" are implemented that way. This for both response speed issues and web security issues.
[HTTP is a stateless, transaction based protocol and is inherently poorly suited for the streaming interaction required by a GUI. It's not a failing of existing toolkits. Also, I find your usage of the word "modern" to be suspect, since you are clearly talking about a theoretical concept that suits your needs rather than actual, existing code.]
Streaming? Most GUI activities do not require streaming.
[ALL GUI activities require streaming. Your confusion is natural, though, because you're only familiar with a certain environment and are assuming it's limitations apply in all cases. HTTP is unsuited for streaming, therefore applications which operate over HTTP ensure that all GUI actions occur on the client.]
What is an example of a typical, common GUI action that "requires" streaming?
[Every single user interaction involves a stream of events passing back and forth between the interface hardware, GUI engine and the display manager. Obviously, making every single one of these operations an HTTP request will result in an unusably slow application. This is why it's not done.]
* No. In the vast majority of biz forms I observe, most activity does not require immediate server-side interaction nor complex client-side scripting. Most communication activity only needs to happen when a "submit" or "save" button is pressed. Other things that don't necessarily require immediate server attention, such as changing screen focus when an icon or tab is pressed, are listed below. These can be indicated declaratively. I have studied this issue fairly well.
[See X Windows for an alternative. HTTP/HTML is *not* a RemoteGuiProtocol. It is a local interface to batch processing.]
* HTTP puts constraints on a GUI system.
* ''Yup, that's what I said. ''
* Then why did you mention what HTTP/HTML is not?
* ''I did not write that above. Somebody else did. -- top''
As far as "my needs", it is not my needs, but the industry needs. '''The industry as a whole''' has decided they want the easy deployment of web-based apps. I agree that certain tasks, such as playing games or editing movies interactively would not be appropriately over HTTP (as it exists now). But we shouldn't dismiss HTTP just because it does not allow every possible need. I am hoping we can identify operations or features which can work over HTTP (latency-bound) and those that can't rather than take an all-or-nothing approach.
[It's nice to finally meet someone that can speak for "the industry". Unless you meant to say "my employer" , or, more likely, "the current buzzword in the IT trade magazines is". A couple years ago the buzzword was "B2B web services" and that didn't exactly dominate the planet. Web applications are very popular for special purposed internal things, the sort of thing you and I get paid to create, but they're hardly the sum of the industry.]
{My observation is that companies are shifting away from fat-client custom apps and moving toward web-based custom apps. If this differs from your observations, then lets just AgreeToDisagree.}
Things that can be done in local declarative mode:
PageAnchor: pre_defined
* Draw screens, or at least "specify" them because "hidden" items may not need to show immediately.
* Navigate between widgets and screens. This includes both user navigation and buttons or events that change focus.
* Rudimentary validation: Validation based on "types" or templates. Personally, I like templates. For example, "999-99-9999" for social-security numbers. "#" is used for general numbers, including those that can have negative signs, and "A" for "token" characters, such as 0-9 and A-Z, and "X" for anything.
* Context-sensitive block-out or hiding - There's often a need to hide or make read-only features that depend on a given selection option. Some kind of set-oriented association mechanism can be used. This requires a lot of attributes to set up declaratively, but is do-able.
Things which usually require client-to-from-server communication:
* Complex validation
* Complex show/hide decisions (beyond what is described above)
One perhaps may claim that these are really "web issues" only, but HTTP is ubiquitous enough now that I don't think a modern GUI can be without it.
[The fact that there is no "modern GUI" over HTTP rather belies this theory of yours. Regardless, you might want to take a look at the XForms standard, which gives everything you seem to desire in a GUI although widespread implementations are probably at least a few years away. This speaks directly to my concerns about your apparent disregard for doing your own homework.
As a final note, this last section really belongs in TopOnWebApplications, or NewWebApplications, or something, because you are *not* talking about GUI engines in general, but specifically about web forms. -- ChrisMellon]
* If HTTP does not matter, then X-Windows already fits the bill more or less. But the industry is moving steadily toward HTTP for good or bad. However, if a good GUI kit exists that works over HTTP, '''then it could also work client-side.''' Thus, '''your dichotomy between HTTP and non-HTTP is premature'''. You assume an HTTP-friendly standard would not be effective for desktop (fat-client) use also. -- top
Why are you assuming the default is low-latency?
[Where did I do that?]
{I had that impression. If that is not the case, then any proposed standard should be usable over HTTP, since it is quite popular. If a standard ignores or does not work well over HTTP, then it seems logical to ask why. -- top}
As far as '''XForms''', the last time I took a look it was a rather bulky interface and a bit client-centric. -- top
[In what way? It's not any bulkier than XHTML, it's even less client centric because the standard defines a standard way of doing data exchange. In any case I thought you were one of those "damn the performance" kind of guys]
* It is a bulky interface/protocol as far as complexity. I'll try to collect some specifics to post.
There is also XUL and XWT. There is even my pet protocol, SCGUI.
[XUL is already in the list at the top of this page, although I don't think anyone uses it remotely. In fact, I'm only aware of one project that uses it at all, aside from Mozilla. You can add XWT (which I'm extremely unimpressed with) and SCGUI (which I didn't know about) if you want.]
''I suggest changing the topic of the page to HttpFriendlyRichClient, since Top seems to focus more on the HTTP/HTML format thing than the GUI engine part. -- AnonymousDonor''
Note that I don't care about HTML here. It is HTTP that is the issue, because '''HTTP is becoming the de-facto message transport standard for good or bad'''. As far as a topic rename, I guess that depends on how ubiquitous you see HTTP. I won't balk at such a name change. -- top
''ProgrammingLanguageNeutralGui name suggests that it's contents should be about how to implements ProgrammingLanguageNeutralGuiEngine. Which is oxymoron by the reason we discussed above (every library accessible through C API is Language Neutral). You seem not to be interested in the feature of GUI engine (Event/Binding). But after the line "'''This is start of HTTP related discussion'''", the discussion makes me believe you are concerning about Stateless/Stateful Gui engine. Which is in no way related to LanguageNeutral issue. You can change the topic to ModernGuiFormat if you want; But No, HTTP/Statelessness/XUL has nothing to do with Being LanguageNeutral. Being able to display on Browser is not LanguageNeutral about, that's Cross Platform thing.''
''Personally, I don't even view HTML as language neutral GUI engine. It's document format, that's all. Every language can produce document of all format, there's no uses to call document language neutral.''
I am still not quite sure what you are getting at. How about we study some '''goals''' instead of dwell on definitions. These goals may not be reached perfectly, but we can explore ways to get a "good grade" is as many as possible:
* Make it easy to use the GUI engine/protocol with a multitude of different programming languages.
* Usable over HTTP without explicit compile-time bindings, etc.
* ?
-----
'''HTTP Text Messaging Starting Point'''
How about we first assume that communication to the GUI Browser will be through HTTP's GET and POST protocol. In other words, text messages (plus a URL). Let's call this the GTPOH - Gui text protocol over HTTP, for now. Now, like CGI, over time wrappers were built over it to make it more palatable. Early adopters will use GTPOH rather directly, perhaps with a sample wrapper in a chosen language(s). Over time, language-specific wrappers may be created that use language-specific features more effectively than the earlier "flat" wrappers.
Thus, we can hopefully get away from language-specific thinking right now and focus on GTPOH and how it builds and manages GUI's. The language-specific thinking just seems to induce HolyWar''''''s about paradigms and languages, leaving us stuck in philosophical tar.
-- top
----
In my opinion ...
The language neutral GUI would allow manipulation of graphics �G� and respond to mouse and keyboard �UI�.
* No disagreement there.
The GUI Engine would handle all aspects of this interface.
* I am not quite sure what this implies. What kinds of things are you trying to avoid?
It would pass information to languages in a non-language specific way (file, memory block, interrupt, 'open api').
* We need to explore that these are. There is no one-size-fits all. Many languages don't have direct HTTP connectability, for example, but that does not prevent an API from hooking into it.
The GUI Engine would also be able to receive data in the same way.
Isn't this what most windows managers do?
All that is needed is to divorce the design, layout and programming of the GUI from the language used to write the non GUI parts of the application.
Take a look at Labview.
* For what purpose? Labview is an application language also.
The GUI IS the Language (almost).
-- AnonymousDonor
''That seems kind of the reverse that is being explored in this topic.''
{Please clarify}
--------
'''Markup Language?'''
How about we explore a markup language approach. I am not necessarily proposing it, but we may learn something by looking at the strengths and weaknesses.
One issue is event handling. Should the markup code even care what an event is? For example, I am not sure we really need "onClick='function_name'" kinds of things. An event handler can chose to process or ignore what it wants to. In other words, everything the user does is a potential event; but whether something listens to or responds to a given event is another matter. It is like watching parts go by on a factory assembly line where you can chose to grab a given part or ignore it.
However, if we look at the latency issues (and perhaps bandwidth limits) raised by the likes of HTTP, then we may have to pre-label which events are "sent" so that the communications stream is not overwhelmed by every mouse or keyboard movement. And we may need to define common/standard handling rather than make a round-trip to the server each time. Some of this was already addressed above. For example, clicking a button to give focus to (open) another window can be predefined declaratively.
Change handling is another tricky issue with markup languages. How does one insert and delete items after the original was rendered? It can be tricky to address something inside a markup syntax tree. The DOM tree is a flipping mess if you ask me. One approach to handling such is to not allow adding or deleting elements, but instead allow some to be hidden or "silent", and then activate or deactivate them as needed. However, this may impose annoying restrictions.
Further, as described under CoordinateVersusNestedGui, some items seem to work better with coordinate-based GUI's. Ideally, we should have the option of using coordinate or nested layouts for any given window or panel. (These are often called "layout managers" in GUI systems.) Coordinates are possible with markup, but may not be the ideal approach.
Note that unlike HTTP+HTML, I propose divorcing document refreshing from message sending. They should be orthogonal.
-- top
----
I added TIBCO General Interface to the list. It's an AJAX framework and development environment used for creating web interfaces for applications that expose their functionality via web services or other communication modes based on HTTP and XML.
Recently I've been working on several projects where I found the combination of Hibernate, XFire and TIBCO GI to be an extremely effective way to both rapidly develop applications and provide a ground level for further business logic implementation. Basically, this combo lets me get the CrudScreens out of the way ASAP and concentrate on the difficult stuff. -- IvanStojic
------
Here's how I might go about it if given funding. First, design a proof-of-concept "GUI browser" that can be defined and controlled largely declaratively. For example, let's assume XML. (I am not a fan of XML, but nobody gets fired for proposing XML [NobodyEverGotFiredForBuyingMicrosoft]). Then make sure it is possible for the browser to send a complete description of a GUI configuration (layout) back to the server or controlling program.
Then devise a way to allow it to send partial configuration info back so that the server or processing program does not get flooded for each little event. First, lets introduce events.
Included would be actions that are easy to define declaratively. For example, a given button can tell a given window to have focus (pop to front). The XML or markup may look something like:
// declare window
...
// declare button
// bind a "click" event to but1
Note how the event changes an attribute that is already available to windows in general. If a name is already defined, then any new tags with the same name is assumed to be changing its attributes. This keeps things simple. Perhaps there can be an "error if not original" attribute somehow if we really want to prevent such. Example:
The "inform" attribute tells it to let the process/server know that an event happened. However, it does not wait for it. Remember, this focus change is '''all declarative''' and the GUI browser takes care of it. If instead we put 'wait="true"', then it would wait for the process/server to respond, perhaps with an hour-glass cursor. (One could call it synched versus asynch communication.) If we wanted to send information about the configuration, then we could do something like this:
This tells it to send a "dump" of all the attributes of "another_window", but not the children (nested widgets). The process/server would simply receive back the XML of the tag with current attributes:
If we had 'children="true"' instead, then it would also send all the containing widget configurations.
In many current systems we have a mix of client-side processing and server side processing. Perhaps we should modify the above tags as follows:
Note the "inform" and "to" attributes now. (I am incrementally adding to these to hopefully keep it clear.) We can notify one or the other or both or none.
The communication with the client and the server is purely via XML (or similar markup language). This protocol would not define language API's. If a language vendor wants to create API's that wrap the XML, that is perfectly fine. However, it is not a requirement.
Here is how the above window focus behavior could be done server side instead. This would be the event definition originally given to the GUI browser:
The server would then receive something like:
Parsing the XML on the server, we know that button "but1" was clicked. Our code may resemble:
function handle_message(xml_obj) {
tag = xml_obj.findByAttribValue("event","widget","but1");
if (tag.found && tag.attrib['action'] == 'click') {
return(''); // request window focus
}
...
}
Another feature would be an optional event sequence counter to make sure nothing gets lost. For example, the server's XML packet for the above event may resemble:
The server may also send a sequence. If sequences get out of whack due to communication problems or other errors, then perhaps the browser can display a warning message with the user option to refresh. The browser-side behavior perhaps could be set via tags that specify one of these behaviors for each destination (client and server):
* Ignore
* Display warning with optional refresh
* Display error message with "quit" or "refresh" options
* Display error and quit (refresh not attempted)
Or, define our own dialog box and actions.
-- top
----
There used to be DisplayPostscript (in the NextStation) which was a very ProgrammingLanguageNeutralGui. But it wasn't really a remote protocol. Every OS GUI is really a ProgrammingLanguageNeutralGui but these aren't really 'simple' (at least not simple enough to be described by a markup language. Personally I think that a interactive variant of TeX would make a great ProgrammingLanguageNeutralGui (and would make for really simple WYSIWYG).
''Amazing. A whole page of this and not one mention of DisplayPostscript.'' - very recent comment moved to this more appropriate location.
[Does that force people to use the PostScript language though, or send PostScript commands?]
It would make DisplayPostscript the back-end language for display purposes, which would then be viewable by a common set of browsers (and printers).
[Not that this would be terrible, but this would mean it isn't really ''language neutral'' since one couldn't use just the native programming language he enjoys. Possibly it is a pipe dream to have a full language neutral GUI - for example, how is Fortran, Forth, or Cobol going to interface into this programming language neutral GUI without sending another language over a pipe? A programming language neutral GUI might end up like SQL where another language is invented and then it becomes a mess in our programs to generate the SQL. But we must KeepAnOpenMind.]
* ''I dispute that using SQL is a mess. It could be improved somewhat over what it is, but its otherwise successful and I've not seen any significant standardizable alternative approaches.''
* I have two questions regarding your competency to make that statement: (a) have you actually read the SQL standard (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)? (b) exactly which other options have you analyzed and decided were not standardizable alternative approaches? (i.e. have you even looked, or is that "I've not seen" just a statement founded in ignorance?)
* ''I thought you were criticizing the SQL string embedding process, not so much SQL language syntax itself. As far as the SQL language, please refer to SqlFlaws. ''
* Be careful when you say "you". You, it is not the "you" that you think, you! This wiki is written by several people.. not just one person. These comments are coming from ''different'' people. In other words ''not just one person disagrees or agrees''. Careful then. That's why some choose to remove signatures, because wiki threads are so confusing and the quotes become mis-attributed.
* ''I fail to see how lack of signatures is an improvement. If you don't want to use signatures, may I recommend SixThinkingHats to create "local" identifiers to help keep things strait. And "regarding your competency to make that statement" is rather rude. RudenessDoesntWork.''
* It is perfectly reasonable to ask you about your competency when you back your statement up with comments like "I've not seen" and "I dispute", but without any logical support. You are, after all, appealing to your competence. I believe it would be extremely rude of you to make such comments without being competent to make them - sort of like someone crashing a wedding when they don't even know who is getting married. It seems, however, you chose distraction tactics over answering the question. Many of the SqlFlaws you waved your hands to gloss over are also flaws in the context of building SQL string commands (e.g. the issue of nesting).
You're correct: fundamentally, it literally and logically impossible to have a truly 'language-neutral' GUI because, no matter what, you (at some point) must serialize a message that determines which pixels ultimately go to the monitor and which inputs the user must provide in return. And that message will, trivially, be in a language, which will thereby no longer be 'language neutral'. The best we can possibly do is create a common back-end language for InteractiveSceneGraph''''''s that is more flexible than HTML and that possesses better optimizations, cache-semantics, and features for the ways we wish to use it (e.g. remote CRUD screens, distributed 3D videogames and remote object control (low latency requirements), distributed tele and videoconferencing, capability security, greater accessibility for non-video interfaces and blind or deaf people, more support for force-feedback inputs and a greater variety of inputs than keyboard and mouse, more flexible client-side 'styling' and transformation of both presentation and interface/input, etc).
ProgrammingLanguageNeutralGui won't happen. It '''can't''' happen. Much better would be to go for a powerful open standard for the GUI - perhaps one that uses a more table or data-oriented scenegraph than the current approach (in which scenegraphs are largely tree-based hierarchical). And one could aim to make this scene-graph language, or at least critical portions of it, easy to build and manipulate from a few popular programming languages. But that's as close as one can ever get. And I expect that successive generations of HTML and potentially ObjectBrowser''''''s will move closer and closer to it.
''The goal is a continuous goal, not a Boolean one. No standard would make everyone 100% happy, but an imperfect standard can be better than the lack of a standard. The current situation sucks.''
{Top, how does XUL differ -- in concept if not implementation -- from your notion of a ProgrammingLanguageNeutralGui?}
So far, its reasonably close, although I've not tested it heavily. However, on the practical side, there is no way in heck that Microsoft is going to support it in their browser, because they see it as a competitor to their browser languages.
{But that, of course, is a political issue rather than a technical one, and few of us here are in a position to directly influence what Microsoft does or doesn't do. Would you say the ''concept'' of XUL meets your definition of a ProgrammingLanguageNeutralGui?}
My initial impression from a few years ago was that it relied too much on a scripting language for activities that could be defined declaratively. It also seemed to focus more on web pages than on CRUD idioms. -- top
''Huh? Web pages are CRUD screens.. a wiki has a little edit box and page where people create, read, and update content. A web forum also allows people to create, read, update, and delete. Crud can be considered a meaningless BuzzPhrase.''
Web standards have not been very effective at creating "heavy-use" CrudScreen''''''s in my experience. The available widgets and the interaction between them is either not powerful enough or not reliable enough. I suppose we could create a list of crud-friendly GUI features to avoid miscommunication. Maybe another day. -- top
{Perhaps you should define and implement a PLNG. In the late 80s, I developed one in-house to run on PCs and dumb terminals (via UNIX curses), as part of a suite of tools for developing custom record-keeping and bookkeeping applications (mainly inventory systems, payroll, billing, etc.) Most interfaces could be defined entirely declaratively, with the optional ability to invoke custom C functions in response to certain events or to generate non-standard interfaces. It was quite effective, though outdated by today's standards, and used a compile-time code generator (emitting C code) rather than a run-time interpreted language. A modern equivalent could be useful.}
--------
'''Definition of PL-Neutral'''
Give me a continuous and measurable definition for 'programming language neutral', and perhaps I'll agree with the first half. For the latter, I agree: the current situation, which was created by evolutionary forces, could be much better.
''SQL and HTML are examples of PLN (programming-language neutral) languages. However, they involve embedding a task-specific language (database and web page specs) in an app language. I would include lang-in-lang as qualifying for PLN. But, I'm not saying L-in-L is the only way to go. RegEx would also be a case of L-in-L.''
Which properties make SQL and HTML programming-language neutral? SQL is a language used in programming as much as any other. Is it that they're domain-specific? Or that they aren't TuringComplete? If there was a turing-complete query language, could that be a PLN? Are you saying it's because you build statements of the language from within another? If I put together strings of C-code inside Haskell, would that make C code L-in-L and therefore a PLN? I find your claim here somewhat dubious. Are you just drawing whimsical lines in the sand, or is there a method to your madness?
''Let's not turn this into a definition battle. Let's focus on getting something decent for remote GUI's but usable in different app languages '''as much as possible.''' If we don't achieve GUI neutrality nirvana, let's at least avoid the problems we have now. One step in the right direction is to make as much of the GUI '''declarative as possible'''. In other words, let's isolate what *can* be readily controllable via attributes and very simple commands. Behavior-intensive stuff may be a cross-language problem, but if we can reduce that aspect, then we are closer to the goal. -- top''
The idea that 'declarative' is usable in more/different app languages seems to me a highly dubious one.
''We'll just have to disagree. In working out how GUI system would work with many different languages, my declarative approaches integrated better in my opinion. I couldn't find a behavior-centric approach that integrated well. If you can find one, please present some examples.''
PostScript, SDL, OpenGl, are all supported by a wide variety of platforms and languages, and are behavior-based. Declarative might useful to achieve certain other features (including composition and transformation as per mashups and CSS, ''and automated optimisation''). Declarative is sometimes a bit more secure/confined than app languages, and security is a critical feature for GUI developers accepting remote code; that is, shipping HTML is a better choice than C even if it just came down to security reasons alone. But each of these - composition, transformation, and security - can be achieved in non-declarative approaches. But, relevantly, I have not seen any evidence to believe that declarative is somehow more 'portable'. That seems to be an idea you've latched onto based on some sort of cursory and unscientific analysis you performed years ago.
''PostScript is a language more or less isolated by itself. It does not have a lot of interaction, at least not in its regular form. If it has or was used for more interaction between an app and itself, then it would be easier to compare for this situation. It's just, "here's a list of pen movement commands. Perform them and then print a page."''
[Actually, PostScript is a powerful, somewhat FORTH-like programming language with strong support for graphics and font manipulation. It has traditionally been used for display and printing purposes, but there's nothing inherent in it that would prevent more general application. I know of at least one case where a general-purpose proof-of-concept was implemented on an HP printer, with the user sending input via the parallel port and receiving output in the form of printed pages.]
''But to compare with GUI's, individual components (lines, curves, words, etc.) would be addressed and changed. Addressing and categorizing the "components" would have to be dealt with effectively. In short, it practice it has mostly been only tested as "output only". A pen-up/pen-down language does not natively have addressable components. A noun-centric language would be a better fit than a verb centric for such. Perhaps it can be used that way if certain extra info was added, but that's not where it's been heavily tested.''
[Its applicability to interactive GUIs has certainly been tested. See DisplayPostscript.]
''How is interactivity dealt with? For example, both of the following draw a rectangle and a circle. At first the rectangle is "under" the circle, but we want to change that on an existing "live" drawing.''
// DECLARATIVE PSEUDOCODE
// IMPERATIVE PSEUDOCODE:
pen up
pen to x1=-1 y1=-2
pen down
draw rectangle to x2=1 y2=2
pen up
pen to x=0 y=0
draw circle radius=1.5
''In the above declarative, the order drawn defaults to the order listed. Same with the imperative. However, if we want to change the order of the shapes, we change the "z-order", that is the depth level, in the declarative version:''
// sent after
''This puts the circle "under" the rectangle, which defaults to a z-order of zero. (z-order is the primary sort and definition sequence is the secondary sort if z-order tie.) How to do so on the imperative version is likely messier.''
I'm not certain how it is you think changing the z-order of two shapes is particularly relevant to interactivity, but in the procedural approach one would simply associate a z-order translation with the current drawing context procedurally (as a command), which would then affect further drawing commands - something like 'pen to layer '. The underlying implementation would probably support a finite number of layers per drawing context, and would simply flatten them together when ready. That, at least, is how I've seen it implemented. It doesn't seem "messier".
** ''Remember, we are *changing* an existing drawing. I'm not asking how layering is done on static drawings. I invite you to show your pseudo-code.''
** I suppose I should have made that more explicit. Changing the drawing in this case is the same as changing the variable and redrawing. If is a global value, this could be manipulated directly. If is a computed variable, then it would either be constant or depend indirectly upon one or more global variables. In general, procedural approaches redraw the entire scene when variables change, though a lot of optimization occurs in determining which areas of a screen don't need to be drawn. In general, variables may also contain more code (i.e. procedures as variables), which allows for some pretty flexible composition.
** ''I assumed that the procedural language had no "z". The "layering" is determined by the order drawn. It thus does not need a "z", nor layers. If you want something "on top", you simply draw it last (or after what's on the "bottom" of it). If it has layers, then that's a declarative concept, meaning the language is partly declarative, and thus we are comparing lemons to oranges, both citrus. My criteria are generally that if X can be done procedurally, then that's how a "pure" procedural language would do it, and visa versa. In practice most languages/techniques are some hybrid. It's a matter of what they emphasize. Also note that the declarative approach I shown is kind of like OOP without methods. -t''
** It isn't unusual for procedural graphics languages to have more than one zbuffer. But you know what they say about assumptions... makes an 'ass' out of 'u' and 'me'. Many languages (including DisplayPostscript and OpenGl) go a bit further than that and allow full 'contexts', where not only does an area get its own z-buffer, it also receives its own brush-type, color, rotation, and translation information, thus allowing for some fairly efficient DeltaIsolation when issuing updates or moving the shapes around. As far as the 'partly declarative', I don't think many people would agree with your use of the language, there, or the implied statement that this is somehow 'more' 'partly declarative' than other procedural languages. Imperative languages have variables. Procedural languages, as sometimes distinguished from Imperative, also have local variables and a call-stack (allowing recursion and such). Z-buffers and contexts fit in quite well as variables. Updating one or more z-buffers followed by a 'blit()' command seems pretty darn procedural to me. It is my impression that you're aiming for a NoTrueScotsman fallacy: "if it works it ''must'' be declarative!".
** ''It's not clear to me which "assumption" you are complaining about.''
** You use the word 'assumed' only once in the statement to which I was replying. You'd do well to assume it was that one. (Probably DeleteWhenRead both of these statements.)
** ''I meant the *example* will assume, not languages that you mentioned.''
** How does that make your assumption any better? Is it your intent to assume a crippled *example* procedural language - one that doesn't even reflect the ''commonly available'' procedural techniques - then compare ''that'' to your declarative approach?
** ''I dispute them being procedural.''
** Indeed you do. I note your HumptyDumpty definition of declarative that you invented on the spot and wrote into your 'book' just so you could raise aforementioned dispute. I don't believe your dispute has any merit.
** ''It was not a definition. See below.''
** ''I agreed that some of the mentioned languages may have declarative features.''
** That's funny. I don't remember proposing that the mentioned features have any remarkably declarative features, so how could you 'agree' to it? Are you agreeing with yourself? What '''I''' said is the opposite: I suspect that most people would '''reject''' your claim about a system being 'declarative' merely by virtue of it having multiple z-buffers.
** ''If there is a layer or a context and it is "addressable" and has attributes that can be changed, then in my book it is "declarative".''
** I don't have a copy of your book - and don't want one. Other than you, I've never heard anyone call 'addressable' components 'declarative'. Pushing contexts around like pieces of paper and playing with z-buffers like cellophane sheets would be considered OOP if it was done by commands to the objects and they had to move/draw themselves, but manipulating them in a context with sequential commands in response to global and computed variables is classic procedural.
** ''However, I will agree that the distinction can be blurry and that hard boundaries are either hard to find, or have too many exceptions. But we often have to create fuzzy abstractions in order to communicate. If one can change "attributes" of "things", then generally it is declarative, or at least "declarative-oriented". I vaguely remember a topic that debated the diff between "declarative" and "imperative". Maybe if we find it we can prevent a duplicate LaynesLaw battle. ;-)''
** Why attempt to overload the already overburdened 'declarative'? Why do you insist on communicating with others using definitions that exist only "in TopMind's book"? Why not use the "fuzzy abstractions" that already exist for the concepts you're discussing?
** Sigh. Perhaps you should come up with a features list. Focus on language-features that are measurable objectively if your disgust for formality keeps you from making them boolean-qualified. Order the list of features by what TopMind's book says is the order of relevance for ProgrammingLanguageNeutralGui. Call that something other than "declarative" - actually, try to avoid using any words already usurped by the technical jargon - and we can avoid a LaynesLaw battle. (page anchor: a more productive path)
** ''It's not "usurping". It is not defined clearly enough as is and I don't think it is possible to define it clearly enough because each language can invent its own little world with new rules. DataAndCodeAreTheSameThing. It's fairly easy to project one as the other. For example, adding accessors like set/get can turn a declarative interface into an imperative one, at least in name.''
** Is it your goal to take a word you believe is not defined clearly enough and toss an entirely new interpretation into the mix and thus confuse things even further?
** ''What exactly makes it "new"?''
** The fact that you can't point to anyplace but TopMind's "book" that has a definition of 'declarative' that would put "addressable and has attributes that can be changed" into the declarative category. Or am I mistaken? Can you find me a "not new" definition of declarative that supports your claim?
** ''Where is this official definition that lacks any room for subjective interpretation? Your response assumes one exists. Otherwise, DontComplainWithoutAlternatives just so that you can argue about arguing. And please, none of that "intent" crap of yours.''
** Huh? I do not assume an 'official definition' of declarative exists. What I said is that, of all the programming definitions of 'declarative' out there - except the one you made up - I know of none of them that put "addressable and has attributes that can be changed" into the declarative category. Can you point to one that clearly gives you that much room for "subjective interpretation"? Actually, and more relevantly, can you honestly say you're using ''any'' established definition of 'declarative'? I think not. Cut it out with this HumptyDumpty crap of yours.
** ''Re: "I know of none of them that put...". That is because such is a *specific* manifestation of declarative. Pure functional programming, for example, is often described as "declarative". However, the def itself does not explicitly list functional.''
** Then find me the definition for which this is a *specific* manifestation. Sigh. Whatever. It seems you reaaaaally want a LaynesLaw battle, because you're '''still''' fighting to use words in ways I'm not willing to read them. It doesn't even matter whether one of us is 'right'. And it could all be miscommunication (I ''really'' don't see how your 'pure' approach of drawing to one z-buffer then issuing a "showpage" is somehow 'less' declarative than drawing on many z-buffers then issuing a "showpage" that collapses them one atop the other, but perhaps you're imagining something else). Please consider (page anchor: a more productive path).
** ''I'm not sure what you mean here. The imperative version I used had no explicit level buffering. The order drawn determined what is "on top" of each other, similar to a physical drawing/painting where one has to put bottom layers on first (barring some nasty scrubbing or erasing tool). ''
** So? And? You already have 'screen' buffering, which by any measure is simply a single z-buffer. It seems like your logic is: "okay, if we instead have a stack of z-buffers that we procedurally manipulate and another 'pen' variable indicating to which one we're drawing, '''definition and logic magic happens here''', and because of this the relevant aspect of the language is declarative not procedural anymore". Now it's time to point me to the definition and expose the logic that makes this magic happen. URI. Book title and Page number. It should be easy, at least if you were being honest when you said this "is a *specific* manifestation of declarative." My guess is: you were lying through your teeth. But I'm willing to be proven wrong.
** ''The existing definitions are subject to interpretation. I cannot provide any objective Boolean-answer test because none exist. That's just the nature of the beast. We cannot pretend like clinical precision exists when it doesn't. You are displaying artificial anal-ness.''
** '''Which''' existing, established definition is subject to this particular interpretation? Nevermind. You have now confirmed that you were, in fact, lying through your teeth and now you're HandWaving to cover it up.
** ''They ALL are subject to interpretation (of some kind). I challenge you to find one that is not. And if you do, please move it to DeclarativeDefinition or the like. Further, you haven't shown that the "noun with attribute" model has obvious imperative features. You only have to find one to attach some doubt to my determination.''
** I don't care about subject to interpretation "of some kind". It isn't even relevant if they are, because being subject to interpretation of some kind ''does not imply'' being subject to interpretation of a particular kind. Find me an established definition subject '''to the particular interpretation''' to which you're subjecting it. Your HumptyDumpty games with language and logic are unacceptable. And if you want a similar example: "Pen up". Noun, modified attribute, directly from your 'pure' imperative example. "Pen to buffer 3" "swapBuffer 3 4", etc.
** ''Exactly! One can *interpret* nouns as verbs and vise versa as described in DataAndCodeAreTheSameThing. EverythingIsRelative. It's all "in the head". I'm just the messenger. If that bothers you, I'm fricken sorry, dude.''
** When you're done dancing around like a punch-drunk fool who scored a touch-down victory in the wrong end-zone and hasn't realized it yet, feel free to point me to an established definition of 'declarative' that is subject to the interpretation that "nouns and verbs make it declarative". And, perhaps, tell me which point you think you won.
** ''I have not found any definition that is objective enough to perform Vulcan-passable logic on. Now if your argument is that "one cannot talk about country music until they first objectively define country music", then please say so. Your position is wishy-washy. Take the common "what versus how" definition. That can be bent any which way. There is no objective and consensusly accepted algorithm that can take a lang def and spit out an either/or answer.''
** My argument is more similar to: "You haven't convinced me this Pop music is actually Country music simply, and your declarations that it's true in your book, your pointing out that the two musics probably blend somewhere, and so on seem like sophistry and HandWaving to me." Even if I agree there are no hard lines between Pop and Country, or between White and Yellow, or between two seasons, and so on, I consider it your fallacy every time you say that the two can't be distinguished. Declarative and Procedural actually have a stronger distinction than Country vs. Pop: what vs. how can be layered, but cannot be blended.
** ''Discussion being moved to DeclarativeImperativeDefinitionDiscussion.''
** And I'll believe it's "easy to project" from one thing to another when you can give me 100% free (in space and time and programming effort) views and indexes and queries in an RDBMS. At the moment, my belief is that translation and projection are pretty damn substantial tasks. Ignoring their relevance seems to me like eating some topsoil and spinach seeds then declaring you've had your vegetables.
** ''This topic is not about RDBMS.''
** True, but I'm quite excused from going a little off topic after you started rambling about how "DataAndCodeAreTheSameThing" and how it excuses your abuse of language. The above is in response to your claim about how "it's fairly easy to preject (sic) one as the other". It is not easy to project. The idea that views are insignificant is not one with any merit. If the idea that views are insignificant, cheap, automatic, etc. did have merit, then views in RDBMSs, transformations, translations, and related computations would be insignficant, cheap, automatic, etc. They aren't. Reductio ad absurdium. Q.E.D.
** ''If I said something pivotal objectively wrong, then you are welcome to prove it using semi-formal logic.''
** If I said: "Pigs fly", could you disprove it using logic? You're free to try; maybe I'll learn something. All I know how to do is point out fallacies and approaches to thinking that are well proven to lead people to bad conclusions. For example, your most recent statement was a suggestion that I should bear the burden to disprove your claims, which is ShiftingTheBurdenOfProof. As another example, I recently pointed out your StrawMan attacks in FileTreeMeetsRelational. A logical person would understand these to be errors; you, however, think of 'straw-man attacks' as 'points successfully defended' (ignoring that it wasn't a relevant point), and you've already expressed your opinion in ShiftingTheBurdenOfProof. I can't convince an irrational person of anything. You'll go on believing what you wish, truth, logic, established language, etc. be damned.
** ''Please don't spill over spats across topics if not necessary.''
** Please stop making it necessary.
** ''It's not necessary.''
** And pigs fly.
It is clear your understanding is heavily influenced by the DocumentObjectModel. I won't knock DOM - it and related models such as SceneGraph ''are'' among my own favorites for reasons related to delta isolation and style-transformation (''not'' portability). But I think you need to work with a few other models before you can start arguing which ends up 'messier' in final implementation, especially when the implementation you're talking about is usability across languages.
''I am trying to illustrate points, not simply claim I am smarter than X.''
I appreciate the effort, but when it comes to illustrating that 'declarative' is more usable/friendly across application languages, the topic of manipulating z-ordering of a couple drawn shapes seems to be unrelated. I think I'd appreciate your efforts ''more'' if you were aiming to illustrate ''clearly relevant'' points.
----
'''Use in Native Language?'''
When people ask that they can use the GUI standard in their "native app language", how much integration is needed? Suppose the standard was some kind of markup language. If you didn't want to use the markup language directly, wrappers could be created for the native app language. Whether these wrappers could take advantage of all your favorite native language features is hard to say though. I expect some kind of compromise would have to be made. It's hard to be a generic standard and fit the style of multiple particular app languages at the same time. That's the usual case with standards. But I feel it would be worth it. (I know, some of you said you don't care what I feel. You don't have to repeat it, I already know you love my guts.) -- top
-----------
While Top is focused on Declarative PLNGs, I think we could do a very good and flexible job by pushing for more powerful and secure support for distribution of mobile code (e.g. ObjectCapabilityModel security), and direct access to OpenGl viewports (+sound ports) as output and a collection of abstract input devices that may be subscribed. This can be supported by a framework that can be ported to different languages.
The ability to distribute code to both sides of the link would do a great deal to allow optimizations wrgt. network chatter. Support for powerful security and additional protections for the machine (no consuming all resources), the application (no deadlock), and one's privacy (i.e. a page mashup shouldn't mix up which details go to which server), however, are necessary before people will feel particularly comfortable with offering sufficient power to the distributed code. EeLanguage is powerful enough on the security end, though we'd also benefit from a language with greater support for optimizations and automatic distribution.
There are plenty of challenges where a more declarative language still helps a lot: support for accessibility by the blind and/or deaf, intelligent integration of mashups, support for some equivalent of CascadingStyleSheets to allow changes in presentation or to make 'mashups' consistent, intelligent mapping of input devices based on current focus of user, ZoomableUserInterface, etc. I'd consider it a GoodThing to tackle these problems, and solve them well, and perhaps a declarative solution at some stage in the processing would help us there.
However, even if higher-level declarative concepts form the lowest 'layer' for the viewport and InteractiveSceneGraph, I don't think we'll '''ever''' escape the need for effective distribution of secure, optimizable mobile code in a GeneralPurposeProgrammingLanguage.
''I agree that some kind of "local scripting" or behavior plug-ins will be a popular option, but most of the common "behaviors" can still be defined/applied declaratively. This also makes it easier to not hard-wire the spec to a particular programming language. And, what you describe is fairly close to Java's GUI approach, with it' sandbox model and all.''
A few behaviors can be declaratively defined. We can try to make those the common behaviors, I agree. But I'm not convinced that it is ''worthwhile'' to do so, nor am I convinced that it "makes it easier to not hard-wire the spec to a particular programming language". I think your approach of aiming for 'declarative' is an utter waste of effort when one will later be hacking in a scripting system around it that will be the "popular option" anyway. One would be much better off with a coherent "particular programming language" that just happens to have some high-level commands (or even just access to a standard browser-provided object or API) that allows many common "behaviors" to be expressed as one-liners.
* ''Your viewpoint is noted. Some organizations, especially those interested in higher security, may only want to use the declarative abilities of the GUI standard, doing more of the processing on the server, and living with slightly longer lag-times because of it.''
* Security is a concern, which is why it was mentioned in the first paragraph, and the second, and mentioned EeLanguage. However, I do not believe "declarative abilities of the GUI standard" offers greater security than you can obtain with ObjectCapabilityModel, and what measure of security it achieves is gained by sacrifice of flexibility and performance - unnecessary sacrifices upon the altar of "I really can't be bothered to search the wide space of design permutations for something that avoids these sacrifices and still offers security". Organizations interested in higher security would rather obtain it without giving up on flexibility and with minimal loss to performance, and certainly ''don't'' have their hearts set on limiting themselves to declarative GUI behaviors.
* ''ObjectCapabilityModel has not been field-tested enough for my tastes.''
* Lol. I suspect, based purely on my belief that you're a stubborn old coot, would be that you don't think it will be 'field-tested enough' until hearing about object capability model through layman outlets (i.e. well after intelligent technical experts believe it has been field-tested enough). Hearing about it through layman channels may happen within the next few years, as the next generation of JavaScript and DOM is based on capabilities in order to better support secure page mashups. ObjectCapabilityModel overcomes the privacy issues that are protected today by JavaScript's current, and rather severe, limitation of only sending AJAX messages to the originating server. The preliminary work in this vein is called 'caja' and was performed by Google. Caja enjoys usage today protecting the users of Yahoo! Application Platform. Anyhow, reflecting your original statement: ''basing security on some misguided belief that declarative is inherently more secure has '''repeatedly''' been proven false infield-tests (SqlInjection and the aforementioned privacy issues for mashups, just to name two examples) - which is far too often for '''my''' tastes.''
** ''This not the place to (re) evangelize OCM.''
** Sure it is. It relates to the goal of flexibly supporting GUI stuff in a portable way that is "reasonably latency-friendly, such as not requiring each key-stroke to travel both ways before a character appears, as found on HTML forms".
* ''And I do not wish to tie a GUI system to specific paradigms and syntaxes. Otherwise, one's goal is no longer a ProgrammingLanguageNeutralGui, and thus is another topic.''
* We've already discussed at length your failure to provide any reasonable definition of "programming language neutral". If by "programming language neutral" you mean "portable to a wide variety of different languages and platforms", then discussing the possibility of using a common language tied to specific paradigms and syntaxes is perfectly on-topic so long as portability is covered. If by "programming language neutral" you mean "declarative", despite the tenuous-at-best association between portability and declarative nature, then perhaps your goal is 'DeclarativeGui' and thus is another topic.
* ''Like I said, it's a '''matter of degree'''; something most formal definitions don't tackle well. (See DefinitionOfLife for an example of a def of a common concept with a similar problem.) The general descriptive metric is that one can rely less on their app language to do or handle "typical and common" GUI stuff. And, without resembling an app language itself.''
* You said it was a 'matter of degree' in your typical EverythingIsRelative manner, but '''you still failed''' to provide a reasonable definition when called upon it (asked for a 'continuous' definition to describe that 'matter of degree') at the topic area titled "Definition of PL-Neutral". Your most recent 'descriptive metric' tosses aside concerns for portability in favor of: if it has some high-level primitives for common display operations, it's closer to neutral. Does 'PL-Neutral' more or less mean 'high level' to you, now?
* ''Portability? Please clarify.''
* Your earlier words were: ''Language neutral - Easy to port API's and/or use markup with many different languages''. Problem for you is that declarative (by the commonly accepted definitions) fails here.
* ''As far as a general definition of "declarative", I did not invent the term. If this discussion depends on a clear definition of "declarative" to continue, then let's work on that first at DefinitionOfDeclarative. Related: DeclarativeGui. -t''
* You did not invent the term, but you certainly set out to re-invent it. But the definition of "declarative" was not at issue in this discussion. The definition of "PL-Neutral" is. The only reason "declarative" gets involved is that you're pushing an agenda. It looked to me like you were attempting (illogically) to assert that "declarative" implies "Easy to port API's and/or use markup with many different languages". Hah! You try it. You finish implementing TopsQueryLanguage yet? You even started on an API?
* ''Let's try this: do or handle as much typical and common GUI idioms and patterns as possible without being (or needing to be) TuringComplete. -t''
* I suspect by "not TuringComplete" you really mean "provides a guarantee of termination" (which it isn't implied by merely being 'not TuringComplete'). And a guarantee of termination IS a nice guarantee to have for many purposes. So is totality (= terminates PLUS freedom from error). So is determinism (= result same for every run). Hmmm... are there any other guarantees we might like? security, perhaps? It might be a bit difficult to properly port an insecure PL-Neutral GUI to a secure language, after all. Perhaps what you're aiming for, fundamentally, is PrincipleOfLeastPower?
* ''Yes, I generally agree with PrincipleOfLeastPower for this because I believe most want a better standard GUI system, not a new programming language, and not a weird academic experiment, but with the caveat that it also be comparatively easy to integrate with app languages. -t''
* Sorry, I don't follow. In fact, I suspect that achieving PrincipleOfLeastPower pretty much implies a 'weird academic experiment' relative to what is available today.
Anyhow, I was not suggesting a "local scripting" system. I don't think it a totally bad thing, but it was not what I was describing above.
I suggested mobile code + direct access to viewport (and other ioport) resources, and possibly allowing a declarative solution at a stage in the processing (e.g. that might be compiled down into the viewport code). There are more than a few differences, wrgt security and automated optimizations and ''especially'' interactivity with external systems, between embedding scripts in a declarative InteractiveSceneGraph that will be called based on user behavior vs. putting arbitrary complex service objects near a viewport that can BOTH react to user-behavior (and update external systems appropriately) AND receive messages from the outside (and update the viewport accordingly). You've been proposing a "static" model for documents. I want a "live, dynamic" model for data-fusion documents + games + video-conferencing + command-and-control and so on.
And, yes, Java 'applets' and their sandbox have many superficial similarities. However, we could still do much better; there are many 'API' choices to make for how such 'java objects' interact with the browser and with one another. Support for navigation, composition, zooming, level of detail, user-focus, etc. must be built into the API for both the ObjectBrowser and the objects... features related to the sort of composition and mashups and navigation we wish to perform. Java objects and applets lack the sort of uniform or global address space necessary for composition, browsing of remote systems, etc. Mobility for java objects in applets is also limited. There is some little ability to download new code based on current interactions (well, I'm sure you can do it, but it is ''painful'', whereas it should be easy - even implicit and automatic... as easy as referencing or creating an object), and there is even less ability to go the other direction and inject servelets back into the servers in order to optimize one's communication with them. Support for bidirectional mobility would allow display configurations to automatically optimize interactions with servers, performing mashups and data-fusion and navigation between them.
----
See also: RemoteGuiProtocols, EventDrivenProgramming, NonOopGuiMethodologies, GuiMachineLanguage, GuiMarkupProposal
----
JuneZeroEight AprilZeroNine
CategoryUserInterface