Programming Language Neutral Gui

view on wiki.c2.com
last modified: December 18, 2009

Some (mostly) language-neutral GUI engines, although the language-neutrality is always within constraints:

EditHint: Merge or move this list to RemoteGuiProtocols? Plus, the list does not belong at the top in my opinion.

Desired features:

Open Issues

(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 LiberatingConstraints 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 <SCRIPT/> and <OBJECT/> 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:

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('<gui:form title="My Form" visible=true width=500...>');

Or perhaps

guiXml(filePath, protocol='file');  // same as above
guiXml('<gui:form title="My...', protocol='string');
guiXml('http://www.myGuis.com/blah.xml', protocol='http');  // load from http

Specific attributes could be set this way in addition to the way described above. As far as what the XML protocol might look like, see RemoteGuiProtocols.

I suppose if communication is through XML strings then it is not language-neutral, but bound to XML. But it is meant to be used by multiple languages. Individual languages can perhaps map them to objects and other native language structures. Generally any "language neutral" protocol is probably going to be string-based to some extent, where queries, XML, and so forth are sent via strings. (A database-centric approach can also be devised, but I don't go into that here.) -- top

Tucking layout and config info doesn't make the gui language neutral, someone still has to write the layout program that reads those files... that's us, the programmers, and we use specific languages to do that work.

I would consider X protocol language neutral. But when you use X from your C or TCL, do you talk to X protocol directly? can you pass C pointer function to X network protocol so that it call you back? No, you can't. You are talking to X through at least Xlib. Using Xlib is no longer language neutral. It's only neutral in the sense that any one could write FFI wrapper over it. But by then they lose all the benefit of their language's semantic (unless their language is already C). X GUI is as language neutral as plain text file is language neutral. It's lowest common denominator of what everyone can do. We almost have language neutral language if all we say is "yeah" and "screaming NOOOOOO". By the way, would you consider being able to talk over network as language neutral? Then Java RMI will be language neutral, because anyone understand RMI protocol could make ruby talk to it (they already have RMI/IIOP though).

The X system is not well-tuned to deal with network latency generally found in HTTP. For example, if you are typing characters into a text box, if every character has to go to the server and back, the user will be understandably annoyed if they have to wait for HTTP to deliver them. Dealing with HTTP requires a higher-level framework where "typical" GUI tasks, such as typing of characters and changing focus, can be handled at the browser level without having to talk to the server for "little things" (unless explicitly asked for). Being HTTP-friendly is a definite requirement for any modern GUI system.

What does "Not well-tuned to deal with network latency" has anything to do with "Being language neutral" here? Performance and concept is different thing. Are you complaining Ruby is not OO because it's slow? Whatta heck.

HTTP is probably not going away anytime soon. Thus, a usable protocol/language should consider it's latency characteristics in its design. Think of HTML forms. It does not have talk to the server to display each character as you type it into a text box, for example. The client-side handles that (by default). X-Windows is not like this; it is more low-level. (It is possible that a GUI setup may opt to manage each character in some circumstances, but it should not be the default behavior.)

In short, X-Windows has latency problems and is too low-level.

Layout and event bindings are the least important part of an GUI. Both of those can be implemented in declarative markup, and thus in a "language-neutral" format. You cannot implement GUI behavior, which is to say the stuff that actually makes it an interface and not a picture, in a language neutral way. If top would like to present a demonstration, I'd be pleased to see it. I won't hold my breath, because the rest of this page shows typical ignorance of the actual implementation of current systems (X-Windows is not a language-neutral GUI engine by any stretch of the imagination....) and an insistence that what he needs to do (simple GUI controls and behavior easily pre-defined by an engine) is all anyone will ever need to do.

First, let's get the "rudeness" stuff out of the way. It was not me who characterized X-Windows. Second, I never proposed only "easy" GUI's. If you have a tough UseCase to present, be my guest. That is the more high-brow way to show how smart you (allegedly) are.

[I presume you won't mind if I delete this page and replace it with pointers to several of the many existing implementations of a layout and event binding language, then? You can move all your ideas to TopsPerfectLayoutMarkup or something.]

{I am not trying to dictate anything here, only encourage discussion and critical thinking.},

As far as behavior, I agree that the entire thing being declarative is not possible. I don't think I ever stated that. If I implied it (where?), it was accidental. The trick is to make the interface between the imperative code and the declarative parts as adaptable as possible to different languages, while keeping expressivity high. The general pattern to events that I observe is something like:

event X(info) {
   gav = getGuiAttributeValue(......);
   if (gav ...some_condition) {
     changeAttributeValue(foo.....)
     refreshSomething(....)   
   },
},

The NounModel should probably be in the GUI engine instead of in the target language. Thus, if one wants to have direct "OOP paths", such as formX.widgetY.attributeZ, then the target language adaptors would have translate between the GUI engine path and the language path.

Now where is that "getGuiAttributeValue" defined in? In C, in Ruby in Lisp? in all of them?

My assumption is that each language would have an adaptor library (unless they use the rawer XML form).

Does the value returned by "getGuiAttributeValue" get cleaned up? By GC, or manually for C/C++?

Isn't that an internal issue within the language? It is not bound to the GUI system. It is merely a local language copy of the attribute from the GUI system.

What's function signature of changeGuiAttributeValue does it require to provide type of the value? (changeGuiAttributeValue("formX.field1", "int", 1)). How will this function be called when the calling language does not support method overloading?

I assumed the GUI system would use strings. Conversion to specific language types would be taken up by the language or language-specific wrappers. It is similar to how databases deal with such issues. If overloading is the way to do it in a specific language, then so be it.

[This, by the way, is how all the existing systems do it. It's sup-optimal because it means it can only be implemented in languages with sufficient runtime introspection that they can do lookups by name. Most current systems also base themselves off the HTML "events as attributes" model, which makes it annoying to bind to an OO framework. Layout languages that don't include event bindings are easier to integrate. Integrating types is much more complicated, because there are very real technical obstacles to passing arbitrary types (especially objects) between languages. There's a number of protocols that address this, however, and some of them are even used in GUI engines.]

How will it notify error, returning error code or throwing exception? Being language neutral is as useful as trying to be Cross platform.

Maybe it can trigger an error event. How do database interfaces do it? Generally it will be something that language adaptor designer will have to deal with. Some languages habit to return codes and others to try-catch blocks.

How do you define the interface which is understood by all language semantic? trying to do that, you end up with very procedural interface. No function callback is possible,

Why are these a problem? Note that OO languages with higher meta abilities may be better able to provide an OO view.

event is done using client keep polling for event and dispatched as necessary.

Why is this so? That seems an implementation issue of the GUI engine, not the language anyhow.

Once someone build a higher level library over it, one will define more semantic to how each object in the system are suppose to interact. It become language independent GUI library. X is still language neutral, but it's UselessTruth IMHO. Yes I would say LanguageNeutralGui is possible, since we have CORBA, SOAP that is language neutral. It's always possible to create a GUI server over that port. But still, it will be as low level as X is.

I suspect X didn't expand partly because of the "HTTP latency" issues. Can you provide some examples of how a CORBA or SOAP GUI interface might look?

Look, my point is that it's how you define "Language Neutral" here. If you define it to be "usable by various language, even through wrapper library" then I have nothing left to argue against. By that definition, WIN32API is language neutral, POSIX is language neutral. Ruby is language neutral (you can write ruby wrapper, right?), everything accessible in binary form is language neutral cause you can write wrapper over it, heck even Machine code is language neutral. But it's as useless as defining that "Everything is something". To be language neutral, it's API and sematic [semantics?] must be usable by all implemented language.

Well, I perfectly agree that "language neutral" is a matter of degree rather than Boolean. The point is to explore those degrees. I am not claiming a final solution here, only kicking around ideas.

[It would be more convincing if you displayed any knowledge of the actual condition of GUI toolkits and the challenges involved in implementing them]

I like to define "Language Neutral GUI" in some way more useful than just to satisfy your desired to prove it so.

"Language neutral GUI engine, of which API differs from language to languages, which different object binding API (because data defined by GUI is just string), Where event handling differs from language to languages (unless one stick to messageloop-dispatch approach)" is possible, but it's useless definition game shit.

Now what makes DB interface different is that it's just the command. it's procedural where it's okay to be procedural. What you do with DB is to just issue the command to insert/update/delete the data from table, when you want and you are done with it. it's sequential separated actions. Now when you talk about GUI, it's parallel interaction, unless you are talking about console GUI. Languages have their own idea of how concurrent activity should work. You set up the interactive GUI view, you may get GUI event at any time, not just when you want to, and you get to display and handle series of various interaction, not just one fix series of SQL command. You may get valid or invalid series of interaction.

Think about it this way, When you are programming SQL you are commanding DB server what to do. When you are programming GUI, you are the one who was commanded to do something. It's always easier to be the one to command than the one that has to carry out the work.

The way I envision it is sort of like CGI: the event runs, changes state (such as GUI model), and then finishes. (However, unlike CGI, it is a messaging system rather than a document/page system). There are no lasting "global" variables and "global" objects, other than the GUI model. (The GUI engine may allow "hidden" variables to act as globals if needed.) Some languages fit that model well, and some don't. But, all languages can be made to fit it to some extent. I suppose some very static languages without any meta features may indeed have to have, or work better with a polling loop. Not the ideal perhaps, but not a show-stopper either. Nothing language-neutral is going be the cat's meow in every language. That is an impossible goal.

And by the way, many things you mention about in wrapper (how to indicate error, how to handle event, the data binding to GUI element) is what i think is needed for something to be call "GUI ENGINE", I want language neutral GUI engine, not Language neutral Dumb white board.

I am not sure what you mean here.

[I'm not the person you're replying too, but certainly to me an "engine" provides driving functionality and power. Markup doesn't provide extensibility or flexibility and, while useful in many cases, is not suitable as a generic GUI toolkit.]

It was related to how you responded to the question about how to handle Event, Error, Semantic with "It's what language-specific adapter writer has to worry." And what's left at your language neutral GUI level is "Post all data as string, Get event by keeping polling, event is just string (no higher level representation)", then it's not GUI engine, It's just X. It's dumb paint screen, it give no concept about data binding, event handling whatsoever. It's language neutral, but it's just language neutral screen server. If you want to advance the technology, think in higher level. 30 years ago one might consider Fortran/C high level language, not anymore so IMHO.

I never suggested app-side polling. I don't see where polling is an issue other than hidden GUI engine implementation details. The language does not have to worry about doing that. But, I still don't understand what your complaint is exactly. What exactly is being "dumb" and what does a smart version of it look like instead? The events are bound to the GUI items, not to the language. When a button is pressed, for example, the Gui eng finds the event program/code/snippet associated with that event and executes it (passing some gui environmental info). Some compromises will probably have to be made in order to make it language neutral, but I see none that are a major hindrance or burden. If you can show a major hindrance, I would be happy to consider it. If you have a better idea of what a lang neut api "should" look like, I would be happy to take a look. Please DontComplainWithoutAlternatives.

Perhaps what you are really suggesting is that the goal is impossible if one wants to use features of their favorite language. That I don't know. It depends on the language. But if that is true, then each language would need it's own GUI engine in order to provide the features and flavor that fit that language. That is not laudable goal if you ask me. There are probably about 50 languages in common use. We would need 50 custom-tuned GUI engines to make all happy, or at least families that tend to fit "kinds" of languages. Still, it makes the idea of language-neutral browsers difficult and is poor reuse. Perhaps some languages cannot handle EventDrivenProgramming driven by external frameworks very well, and they should be dumped into the legacy dump, or at least avoided if performance is an issue.

[Of course it's impossible to be language-neutral and still take advantage of language-specific features. That's why pretty much none of your language-neutral crap, on any topic, makes any sense. There's a reason we have multiple languages, after all. How familiar are you with existing GUI implementations? Do you know the technical obstacles in the way? Do you know how toolkits are implemented? There aren't very many - maybe a half dozen in common use. They all have bindings to multiple languages. We don't "need 50 custom-tuned GUI engines" - we have them.]

I don't see what having multiple languages has to do with GUI limits. I also don't know what you mean by the last part. Are you saying the existing GUI systems are satisfactory? The only technical obstacles are speed and bandwidth (bandwidth being another way to say "speed"). Outside of that, the sky is the limit. See SoftwareGivesUsGodLikePowers. (Well, I suppose that hooking it to existing languages is a constraint.)

"Having multiple languages" has nothing to do with GUI limits, but it has everything to do with being programming language neutral limit. You can have 3D GUI desktop, with Speech recognizing system and fully network transparent. But as long as it is Language neutral, you still have only dumb string puppet GUI, controlling through procedural language and event polling where data has no meaning (everything display just array or 3D point). It's the same problem with Programming language we have now, It's not that our PC is not powerful enough for most type of problem, it's that our programming language is not powerful enough to allow us to think of how to solve the problem clearly.

This sounds like it is turning into a language or paradigm PissingMatch. It may be true that strings and procedural API's are currently the best approaches to provide language-neutrality, but that alone should not stop us from using them. I have not seen enough evidence that they are sufficiently non-expressive to abandon. It may beat the HTML+DOM crap we have now even without being the ideal. In other words, be less crappy.

[At the risk of repeating myself, spending even a few days familiarizing yourself with existing toolkits would be a *really* good idea if you want to have intelligent conversation on this topic. -- ChrisMellon]

{I routinely ignore such insults. I've used lots of GUI systems over the years. It usually turns out to be your lame articulation skills, not my allegedly lacking tech knowledge that is the bottleneck. You just don't want to take the time to explain your complaints properly, believing that insulting my skills is a shortcut. This will probably turn out no different. You've called wolf too many times. Further, you seem to be focusing too much on implementation too early in the game. Let's define what the interface/requirements are, and THEN worry about how to implement it. If we define something that is not implementable, at that point it becomes an issue.},

[There's no insult intended. It helps if everyone involved in a conversation has basic knowledge of the domain involved, including the current state of the art. It allows for common ground in discussion. I'm not sure how my calling you on lacking knowledge of the state of the art is crying wolf, as to my knowledge you've never come back and stated that you actually do have such knowledge. If in fact you do, I'm glad to here it, and I suggest that you frame your ideas in relation and comparison to existing solutions in order to provide a context for comparison.

None of the issues on this page are new, and they all have existing solutions. If you know how people are currently solving these problems, you can provide much better feedback about what you think would be better solutions. If you are intentionally refusing to familiarize yourself with them, which seems to be what you're doing, then I don't see how you expect anyone to take what you have to say seriously. -- ChrisMellon]

The purpose of GUI engine is to provide higher abstraction to using the GUI. GUI engine is not all about GUI-layout, it includes Event-handing, data-binding. While it's true that every programming paradigm's smallest instruction must come down to one procedural command, It is not useful to use the library at that low level. I thought what we are talking hre is about "High-level concept GUI engine" where GUI engine is really an engine that facilitates programming. Or else I think we have no benefit of discussing this topic. Because at the end we have a procedural API which passed all data by string. So, by this definition, we already have language neutral GUI-engine, X, wxWidgets, Tk, WIN32API:GDI, heck most software in the world are then already language neutral, be it X, GCC, OGG encoder, DB, TCL/Tk or Assembly. We don't have to talk about its usefulness to the client language, as long as it can take array of byte and return array of bytes, it's language neutral. So why create atopic about something that's already achieved? Cool invention here, thanks for teaching me that, now clap your hand, you win your definition game here. And we gain nothing for software community. Why don't you create LanguageNeutralSocketLibrary, LanguageNeutralMachineInstruction, LanguageNeutralReportGenerationLibrary.

All of those language neutral library is already there, but IMHO they would be smart enough to not boast their library as so.

Well, for one I don't think that being procedural or string-based necessarily makes them "low level". But arguing over that would probably turn into yet another ParadigmPissingMatch. We've been over similar kinds of issues with SQL and databases. Most of the idioms for CrudScreens can be defined declaratively. This can be leveraged to reduce the amount of imperative processing that has to be dealt with by the app language. The imperative parts are the most difficult to share across languages. We cannot eliminate all possible language-specific issues, but by making as much declarative as possible, we reduce these issues. Good declarative-based systems are not "dumb". I reject your characterization without further evidence. -- top

[The fact that you have to pass SQL to a database instead of being able to create a query programmatically is one of my chief annoyances with existing database APIs. I don't think we've got an optimal solution there.]

There is some cost in not making the DB tightly-bound to a programming language, but there are also many benefits, such as not having to reinvent the wheel for each language so that vendors can focus on making the best kit. It is better OnceAndOnlyOnce.

[Smalltalk is the only language I can think of off hand that is even slightly widespread, has it's own GUI engine, and isn't capable of using another one. I'm not even sure about the third issue. Java could be another example, depending on how you look at it. Pretty much every other GUI engine can be used from a wide variety of languages. This is due in no small part to the fact that the vast majority of languages can call C library functions, and most GUI engines are either written in or expose a C API.]

But C api's are not latency-friendly over HTTP. Anyhow, it appears that somebody above seems to feel that language-neutrality is not a worthy goal if it hampers using one's favorite language-specific idioms. The thing is, developers often don't make that decision. Many businesses have shown they want LNG's by choosing web-based solutions over fat or proprietary desktop-centric approaches. I have seen it over and over and have converted client-centric tools to web-based solutions due in large part to (perceived) simplicity in deployment. They don't seem to care if development is slow and code messier. A manager is not going to care if you can't use re-entrant virtual closures or whatnot unless it outright stops the project.

Another issue is graphical GUI designers. One should not have to spend much time writing GUI code directly if there are nice tools to do most of it via visual interfaces. I was more productive writing most GUI items with (decent) visual designers than via direct code (such as hand-coded HTML) and many agree. A standardized interface/protocol allows the gui kit builders to focus on the GUI tools (visual and otherwise) rather than time on reinventing such over and over for each different language. The effort can be focused.

This current per-language GUI reinvention for the 30-odd common languages is a massive industry-wide violation of OnceAndOnlyOnce and strangely nobody seems to give a shit. If you demonstrate consolidation is not possible/practical without violating the laws of physics, then maybe it is worth ignoring this ugly mass duplication. Otherwise, stretch your brains, people! -- top

.NET

.NET tries to merge it into a compatible framework that all languages can access. Many agree that there are too many languages. Possibly the old way of linking DLL's together, or using COM is too hard for people. This is why more people are moving to .NET. Although many are still not moving to it. How do you bond scripting languages together with the same compatible sharing system without reinventing .NET? Possibly this is what Microsoft is betting on - the fact that people do choose many different languages, sadly - and not everyone wants to program in C or C++ obviously. Nor does everyone want to program in Java, and only Java. So .NET seems to be fulfilling your request of merging efforts. More serious programmers would consider .NET if it legally worked on Windows, BSD, Linux, and if it wasn't invented by Microsoft. Of course, if .NET was a bit more peppy, it would help too.. I find PAINT.NET extremely slow for all it does, as an example - no matter what benchmarks out there prove that .NET can be fast. In practice, it isn't too peppy for many applications.

.NET fails the "open standard" criteria. MS has a habit of trying to sabotage anything that threatens its desktop monopoly. But if .NET works well, it may spark ideas that can be copied but improved (assuming they are not patented).

What I tentatively envision is a messaging protocol (MP). Let's not get caught up in the language of these messages just yet. That is a later detail. Messages go back and forth between the gui engine (browser) and application. In the past the MPs were designed such that low latency was assumed. But if we want such MPs to work over the likes of HTTP and modems, then we have to do things a bit differently.

For example, take pressing/clicking a menu item or tab to switch screens (change focus). In the earlier MPs, clicking such would often result in a message going back to the app, and then the app would send the "change focus" message back to the gui. This does not work well in a high-latency environment. We don't need a long wait just to browse around to different screens/panels. One approach is to send programming commands in advance to do the focus changing at the browser. However, this carries with it security concerns and requires learning yet another turing-complete language. The second approach is to declaratively specify certain common actions such as focus changes without explicit messages being exchanged upon the event being triggered. Certain such declarative operations need to be identified. (Below under PageAnchor "pre_defined" is a draft list of such items.) Such a declaration may fit the pattern:

widget: Tab7
 event: on_click
  target_view_panel: myPanel   // "main" for top
  form: form34
result: give_focus

Keep in mind that this is not meant to replace all programming-bound commands. If we want our app to handle such an event instead of using the pre-defined declarative route, we can. The big difference is this approach requires a back-and-forth message round (latency). It might be set up something like this:

// GUI has been given this declaration:
       widget: Tab7
        event: on_click
       result: send_message_and_wait

      // app-side (pseudo-code)
      event on_Tab7_click(e) {
        ....
        if (record_count > 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.]

[See X Windows for an alternative. HTTP/HTML is *not* a RemoteGuiProtocol. It is a local interface to batch processing.]

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

Things which usually require client-to-from-server communication:

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]

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]

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:

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 HolyWars 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�.

The GUI Engine would handle all aspects of this interface.

It would pass information to languages in a non-language specific way (file, memory block, interrupt, 'open api').

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.

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:

<window name="winX" .../>   // declare window
...
<window name="another_window" .../>   
  <button name="but1" label="open window X" .../>  // declare button
  // bind a "click" event to but1
  <event widget="but1" action="click" inform="true">   
    <window name="winX" focus="true"/>
  </event>
</window>

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:

<window name="winX" original="true" .../>

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:

<event widget="but1" action="click" inform="true">   
  <window name="winX" focus="true"/>
  <send widget="another_window" children="false"/>
</event>

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:

<window name="another_window" height=123 width=456 ..... />

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:

<event widget="but1" action="click" inform="client, server">   
  <window name="winX" focus="true"/>
  <send to="client, server" widget="another_window" children="false"/>
</event>

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:

<event widget="but1" action="click" wait="server"/>

The server would then receive something like:

<message ...>
  <event widget="but1" action="click" wait="server"/> 
</message>

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('<window name="winX" focus="true">');  // 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:

<message sequence=47 from="GUI_browser">
  <window name="another_window" height=123 width=456 ..... />
</message>

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):

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.]

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 InteractiveSceneGraphs 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 ObjectBrowsers 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" CrudScreens 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
<rectangle id=rec1 x1=-1 y1=-2 x2=1 y2=2>
<circle id=cir1 x=0 y=0 radius=1.5>

// 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
<circle id=cir1 zorder=-1>
<redraw>

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 <z>'. 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".

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.

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

Loading...