Comments on: REBOL 3.0 GUI Path

Ok, here's an important note...

The graphics system of REBOL 3.0 is more powerful and leaner than prior REBOL versions. It will be fantastic for creating GUI's, presentations, applications, games, and demos. It should be possible to create hundreds of graphics objects, but without the same memory overhead required in prior versions.

Now, in order to make the upper layers of the GUI (e.g. VID) faster and leaner, those layers must be reimplemented using new methods. Fortunately, there's not a lot of code invovled here, so the process should not take too long. However, it is not a small job either, and the project must begin fairly soon.

Improvements

We will need to take this opportunity to improve the built-in GUI system. Here are the areas of improvement:

The Project

I've not yet decided how the GUI will be created. The most likely path is to rebuild along the lines of something that already exists. I am not opposed to using a GUI system design that has been done outside of RT (e.g. REBGUI?), as long it can meet the above requirements and the licensing is suitable.

I would like to assemble a small team for this project, probably three or four people in total (including myself). And, it is critical that all of us share the same design goals and optimal coding practices.

The project would begin just as soon as we have the lower layers of the REBOL 3.0 graphics system up and running. (Later in May, I hope!) It is likely that we would begin before the event system is finalized, but that should not slow things down.

Your thoughts and comments are appreciated.

34 Comments

Comments:

Ridcully 5-May-2006 14:47	:) style vs. widget -- as you say somewhere, words are very important. now, why use 'style' for a thing everyone knows as a 'widget' ? besides that, i very much appreciate the effort for a new gui system. as for skins: i think it would be better to have a good looking standard rebol skin. look at apple - they have just one skin, and every one tries just to copy it. every skinnable application or window manager or whatever, has an "aqua" skin. so why not create a unique "rebol skin" as cool or even cooler than aqua. this would also make it easier to optimize the gui as you do not have do consider how things will look like in other skins.
GreG 5-May-2006 15:09	Will it be still possible to use low level graphic objects? like equivalent of faces? If yes, I'm impatient to know details!
GreG 5-May-2006 15:15	I'm also curious to know what will make the new graphics system better than the former one; if this can be explain.
Brian Hawley 5-May-2006 15:22	A layout manager might be nice. I know there's a layout dialect right now, but I was thinking of something that would react to resizing of the window by fixing the layout to match. Just an idea.
Gregg Irwin 5-May-2006 15:32	One of the old VID update projects generated quite a lot of thought and code. Romano (and someone else, too) built a resizing system that should be analyzed. I don't have a problem with the word STYLE, since CSS and stylization is really what it's used for. It's a good word. The faces *created* from styles--think of styles as abstract--could be called "widgets" or "controls" I suppose, but "widget" is also used for small apps, like in Konfabulator. I don't have a problem sticking with FACE. Keyboard handling and focus are the two main issues I have with VID. It's very hard to create keyboard driven apps. We should consider accessibility as well.
Gregg Irwin 5-May-2006 15:40	I would also like to see consideration given to data oriented apps that need to display and collect data. Whether it should be a higher level dialect, or could be done with a facet or two and some support functions, I don't know, but making it easy to write that kind of app would be great. It also ties to the set-function/typed-object blogs. i.e. don't design these features in isolation from one another.
Edoc 5-May-2006 15:52	I don't know if this is on the table or not, but I'm also in favor of plain-speak. If most people know a visual element by a certain name, use that name, don't introduce a new name. For example, a name such as "guide" is short, but sometimes its better to use terms that are familiar to users (perhaps even "HR"), even if the established names are less than ideal. This caution applies beyond VID, of course. The power to name is an important thing, but you're usually better-off not reinventing-- or renaming-- the wheel. Glad to hear about the GUI work. I thought RebGUI was pretty dang impressive as far as looks go.
Jean-François 5-May-2006 17:09	:) About VID; I would like it to be easy (even for beginners) to make direct manipulation interface (CAD, DRAW) etc. Oldes had something to say about that. About the naming; sometimes it is better to use new names to "warn" people of the difference in concepts. If you use the same name, people start with their previous definition of that word which can create misunderstanding.
Ingo 5-May-2006 17:53	I hope that "rich-text" will be supported in 3.0?
maximo 5-May-2006 19:27	well, I've been implementing GUI APIs for years now (glass, glayout, liquid glass) and what we really need, IMHO, are more and lower level events. key up/down, middle mouse, caps key handling, etc. Borderless popup windows which do not interupt event flow (tk implements them pretty well) is also a must if we are to do real popup menus. the new leaner face is also welcomed.
maximo 5-May-2006 19:32	I like current naming scheme, its very precise semantically and is different enough to warn people that these aren't OS knobs and dials.
Edoc 5-May-2006 19:32	:) A little story about naming... Here in the US, there's a popular coffee shop called Starbucks. Starbucks insists on naming it's coffee cup sizes "Tall", "Grande", and "Venti" and not "small", "medium", and "large"-- the terms used overwhelmingly throughout the nation to describe beverage sizes. After going to Starbucks a handful of times, of course you can easily adjust to the translated sizes-- but it's an annoyance and totally unnecessary. It's a friggin' cup of coffee!! You need to be very sure what you're naming is distinct and unique and warrants a new name, or you end up chipping away at the users tolerance. Names like Face, Facet, Feel, etc. may be great, consistent names. But are they really so different from analogous HTML behaviors-- which everyone knows-- that it's worth a new name? In some cases it may be, but in many I think it's not worth it.
Anonymous 5-May-2006 23:10	I'm in !! If I'm not in the team, I'm gonna go crazy.
Anton Rolls 5-May-2006 23:10	That would be me.
Sunanda 6-May-2006 5:17	Please give some serious thought to adding stuff to make accessible applications. In a web browser application I can (depending on browser): -- resize fonts, change colors independent of the application -- replace images by an alt or title text describing them -- easily list all the clickable items on a page -- use access keys to perform common operations -- have the text spoken to me by a screen reader. These days, it is increasingly important to be able to deploy applications that can be used by users who have various handicaps. Please make VID a world class environment for doing that.
Dave Cope 6-May-2006 10:13	:) My wish for 3.0 GUI is a table/grid/tree style/widget/control. Something simple to setup and point some data at. Sortable columns, re-sizable columns, headers, row highlighting etc. Very exciting reading the progress for 3.0. More power to your elbow Carl!
Dave Cope 6-May-2006 10:16	:) p.s. I would also like to support the previous calls for accessability also.Thanks.
Dave Cope 6-May-2006 12:56	:) p.p.s I would be happy to take part in any usability testing for the GUI or help with conceptual design.
Goldevil 7-May-2006 6:41	Yes, we need more "widgets" (table, grid, tree,...). With Rebol I make software faster than with other languages in any point but GUI. Why ? Just because if I need a tree widget, I have to create it ! Remarks about new version of existing widgets : - dropdown list box that can display a long list (ex: countries) with automatic selection with keyboard. - tree widget - The text-list must be able to accept a key-value pair for each line. What's displayed is not necessary what I want as field value. - The text list must handle two lines with the same label (I hate when both are displayed "selected" when I click on one of them) - Every body use the term widget (even in rebol world we are a majority). - Skins are very important ! I don't need 20 skins packaged with rebol (A cool rebol skin is enough). I want to make an application that's looks like any other apps on the operating system. All the graphics must be replaced by something I want. It's irritating far a Mac USer to see an application with a strange GUI like WinXP. It's irritating for a WinXP user to see an application with an aqua GUI when every other application on his desktop has the "fisher price" look of WinXP. Only Linux users are less irritating by this. With Rebol 2.3.2, I use the skins built by Etienne Alaurent. I had to modify it but it works well. It gives me cool widgets (tree,...) and some look&Feel (including WinXP and Aqua) But, these skins must not be included in rebol/view directly. Rebol must have his own look&Feel (simple as REBGUI) that permits everything "out of the box". That the spirit of Rebol. But It must be easy for programmer to change the default backround, colors, font, buttons,... to adapt it to his needs. PS: keyboard driven applications are important not only for accessibility but also for "power user". When I'm working on accounting, I want to type hundreds of invoices without switching between mous and keyboard. PS: Rebol 3.0 will be GREAT !!! Good work seems to be done at RT.
Petr Krenzelok 7-May-2006 9:01	:) Carl, could you please blog a bit about lower level Rebol3 View layers? How events including keyboard will work, blitting, view plug-ins, rich-text, what changes are planned for the face object, etc.? As for View 3.0, I suggest to move to rebol native windowing system, because if view/new opens new native window (dialog), we are doomed for products like browser plug-in, where it will be regarded being a pop-up and some ppl used to add-block products will feel uncomfortable about rebol escaping their pop-up blocking mechanisms ... Thanks, -pekr-
Henrik 7-May-2006 19:52	I'm not the best system designer, so the design of the system would not be left in my hands, but I know I can offer and implement artwork and graphics design and better consistency between all GUI elements to give the user a proper experience that doesn't feel "cheap" or haphazard as is the case with the current View. This counts both for artwork done with vectorgraphics in DRAW or plain bitmap graphics. I can do both. I have implemented TAB-VIEW and LIST-VIEW for View 1.3 and would be happy to do some work towards a real professional GUI for REBOL 3.0.
yeksoon 7-May-2006 19:52	:) I want better event handling and layout managers. As far as skin is concern, we can have a default REBOL skin... and have a XP (maybe Vista) or Mac skin that we can easily download and switch to from within /View Additional skin can definitely be a community effort. .. eg Motif, KDE, CDE etc Just to add-on, i18n support :)
GreG 8-May-2006 10:36	What we really need first is an efficient graphics system. Then, for the GUI layer, it's something very important too but we can adress it from many different ways. As a result, we may not all agree on what should be done... I'm also wondering if the GUI layer should not be just a 3rd party script made by the community like RebGUI, Glass, ...
Goldevil 8-May-2006 11:09	Another thing about GUI. When the gui speaks only in pixels this is sometimes limitative. When resizing windows we usually needs to resize some panes inside but not all panes (usually icons stay unchanged but the main content area is resized). How to handle that ? The same rebol application could be run on various screen sizes from a PDA screen (320x320 pixels) to dual screen 19inch screen (2560x 1024 ). I think about a chat software or a RSS reader. Buttons, fields, icons cannot be huge on a PDA or tiny on a big PC screen. To reduce the work of the developper, the future rebol GUI could maybe accept sizes and positions not only in pixels but also in %. Or, better, Rebol/view could accept virtual coordinate and convert it on the fly on real screen coordinates. I just say to Rebol/view that I use a 1600x800 pixel screen and it convert everything event if the software runs on a 1024x768 pixels screen. I'm not a specialist in this domain. Maybe others can speak about that.
Marco 8-May-2006 11:09	:) My wish for 3.0 GUI is to have in addition to common style, tab-panel, table and tree style. I would like also dynamic layout and resize policy at the face level (low level). Currently, VID offer 2 layout policy (ACROSS and BELOW) and faces are placed and sized once during by the layout function. I like very much the BORDER layout policy available in Java AWT. To have dynamic layout and resize capability, I believe that like in Java, we should have layout, constraint, index, minimum-size and maximum-size property at the face level.
Henrik 9-May-2006 13:32	I'm not sure whether this is too lowlevel, but I'd like to see event throttling. I have a 2.6 Ghz Celeron WindowsXP PC which apparently samples the mouse pointer very quickly, around 200-250 Hz with a cheap logitech mouse. I also have a 500 Mhz Celeron Linux laptop which doesn't sample mouse input that quickly, but the laptop runs most REBOL programs much faster, because the event system doesn't drown in mouse movement events. Running REBOL programs on the Windows PC usually becomes incredibly slow if the graphics can't be completed faster than the interval between mouse events. The ROAM object explorer in the Viewtop, for example displays a colored bar in the list over the pointer. When moving the mouse, the bar chugs along 1-2 seconds after the mouse pointer. The GUI is not responsive because it's flooded with mouse position events. This can be somewhat averted by ignoring mouse events for X milliseconds inside a FEEL for a face, but this is cumbersome to define and needs to be adjusted according to how fast your faces are SHOWn. Beginners shouldn't need to take this into account, and endusers shouldn't need to be aware of how fast their mouse samples the pointer position. Perhaps a global throttle that says: 25 or 50 Hz and no more and then allow it to be adjustable per face, like RATE. Maybe my PC could have some driver defect, but it could be a general thing for some PCs. I suspect this could also be useful in cases where the keyboard repeat events floods the input system.
Gregg Irwin 9-May-2006 17:46	RT should look at how Gabriele and Romano's eat-events system works. That is, discarding events that can be safely ignored. I agree, though, Henrik.
Volker 12-May-2006 9:27	My wish: Event-transparent faces. I want an editable text with lines and arrows on top, and crrently the lines would block all events.
Normand Leclerc 18-May-2006 9:41	:) Path to the Widget objects: I hope the new system will enable to adress the widgets by variable name instead of the actual face/pane/1/... It is very intuitive to name the widgets by variable names. That is the way to do it. Now it is not possible to use our widget's name as a valid path: Id: pane [Surname: field 200] adressed by Id/Surname/text. From my point of view, this actual design choice is cumbersome (face/pane/1/...) and should be changed. We don't have to guess the naming convention, the naming convention should be the name of the variable path in the object as created by the programmer. So a field text value in a pane containing two buttons, an area and a field shoud be adressed by mycontextname/mypanename/myfieldname/text. Rebol is appealing for its intuitive simplicity. It should be done there also.
mike 27-May-2006 6:31	:) talk about being irritating, just give them their original names :) Gadget and MUI funny that so many people are commenting on this GUI blog, but are not doing anything to make the simple GUI's that many shell apps could really benifit from for instance. XMLTV with a collect and display. any No. of encoders to take a Mpeg2 file and produce an AVC file of preset sizes etc. client/server GUI to control VLC server and client modes. just a few to think about, but many more. thanks to thoughs of you that have done your part in the GUI for real users, youknow who tou are, the rest well if you can code rebol , step up and show what you can do, 1 hour a day for a few days isnt a lot to most. without the GUI apps people just look at rebol and shrug...........
Mark 20-Jun-2006 5:28	The cutting edge for UI are interface elements which animate, sliding on and off the screen, expanding and contracting in a fluid manner, fading in and out, etc. Check out some apps built in Flash and/or Laszlo to see how much this can enhance the user experience.
mike 4-Dec-2007 19:19:06	time to forget Rebol and its coders it seems. after all this time , and still not one single GUI for any mainstream or useful apps like the XMLTV its clear the most able rebol coders just arnt interested in making any GUIs of any level for the masses to see and use.... shame.
Henrik 5-Dec-2007 12:32:56	Mike, so you haven't read anything about VID3 yet?
gui developer 14-Apr-2008 13:31:34	One measure of the new gui system might be how easy it would be to implement various MS/Mac apps (The GUI piece Specifically), Outlook/Explorer/ITunes, etc. For rebol to find a larger audience I think it will need to pass as a "native" looking app alongside other MS/Mac/ apps.

Post a Comment:

You can post a comment here. Keep it on-topic.