Hello Tuomo! I think Vis is a great idea and would definitely want to use it, if Vis came into existence. Not only does your motivation for Vis match some opinions of mine (WIMP is not really useable, no UI is good for everyone), I even feel a need for something like Vis every day I work at a computer - both as a (power) user and as a developer.
* As a user I feel myself wanting to change the UI of most apps I work with (even though I have chosen those apps carefully). * As a developer I want to spend as few time, energy and lines of code on UI programming as possible. Not because I don't care about the UI (on the contrary!), but because it tends to consume as much time as solving the actual problem. [It has been noted before that application programming and UI design are entirely different, but are both very demanding. Seperation of the two has been an objective for a long time. But modern GUI libraries don't really allow for this, even considering efforts like GTK's Glade. Vis would certainly aid in seperating the two and seems like the most promising approach I have heard of.] After first reading your paper I have two things to remark concerning your proposed Vis API: 1) Where to store application data? As I understood it, Accessible data is supposed to be stored with/managed by the Vis library. I do not think this is a good idea. As a developer one spends a lot of time on creating data structures. I want to develop my data structures/classes with the facilities my chosen programming language provides, not via the UI library. Especially if I hope to reuse my classes in another application. Also, the application is proably going to access the data more often the UI library/the user so it is logical that the data should reside with the actual application. So, I will store/manage my data where and how I want in any case and if I have to store the accessible part of my data with Vis, I will copy it to Vis Accessibles whenever necessary. Thus, a lot of data is present twice in memory. And additionally I have to keep track of when to update Vis' copy of my data. My proposal on how to solve this: provide Vis with callback functions that Vis' can call to retrieve the Accessibles whenever it becomes necessary. I predict that with most applications and UI-modules, most of these callback won't even be called during a given session. [Example: GTK2's table widget requires all of the table data has to reside in a custom GTK2 data structure. Even if the table has 1000 entries but only 10 can be rendered on screen the application has to fill in all 1000 entries - which is in most cases a tremendous waste of performance.] 2) State-full applications. With many applications the current state of the application determines the Commands available to the user. This can be a choice made due to UI considerations: vi's modes are a feature of vi's user interface. (Consequently you intend to have Vis abstract the 'C' of the MVC paradigm.) However, some applications are inherently state-full: Their having a state is not merely a UI decision. Consider TeXmacs (a editor for LaTeX-like documents): you can only insert greek or calligraphic letters when the caret is inside a math-range - and the UI changes accordingly when you enter a math-range. Likewise in a vector graphics program: your choice of actions depends on the kind of object you have selected. How do you want to the application to communicate to Vis which kinds of states it has and how these states are reflected in the available Accessibles? Just toggleing the "enabled" attribute of an Accessible does not seem good enough to me. Well, it's past time I stop writing ;) I really hope Vis is actually realized, I am even willing to help making it happen. What are your plans on how to proceed? Cheers, Felix
