World: r3wp
[!RebGUI] A lightweight alternative to VID
older newer | first last |
Graham 31-Dec-2007 [7285] | shift-tab taken for tab backwards |
Anton 31-Dec-2007 [7286] | I would avoid shift tab because it's typically used for ... exactly, tab backwards. |
Ashley 31-Dec-2007 [7287x2] | Uploaded build#112 with extensive changes. 1) scroll-wheel support added to scroll-panel (CTRL+Scroll to scroll the horizontal scroller) 2) set-values and get-values fixed (added support for scroll-panel and fixed a few bugs) 3) Added a new widget, pill, that is basically a box with rounded corners 4) Changed the look of tab-panel so that the current tab is same as page background and remaining tabs have a solid color 5) splash requestor now accepts a file! or image! (so you're not forced to provide a spec block if you already have an image) 6) Experimental new logo 7) Color management is being totally overhauled (I'll post separately on this topic) *** Do not sync this build if you want to retain the "old" look & feel *** |
RebGUI color management. The "old" RebGUI color management system evolved by adding new colors to ctx-rebgui/colors as and when a new color was selected. Many of these colors (e.g. button, tooltip*, btn*) were widget specific. In all, 15 colors were defined. In addition to this, a number of hard-coded colors such as white, black, coal, red and blue were scattered throughout the system. The effect of all this was to provide a means whereby *most* colors could be changed, but the design of a "theme" other than the default WinXP scheme was problematic. The new color management system rationalizes these colors down to a base set of 8, being: page text theme-light theme-dark state-light state-dark outline-light outline-dark with all existing "old" color references being converted to the "new" ones. page and text will usually be white and black (high contrast), with outlines being grey, and theme and state being variations on the same color. The updated request-ui shows how these themes can more easily be chosen (there is a drop-list beneath each of the theme and state groups that sets both light and dark to a similar color). This is still a work in progress, and I am basing the model (and color selections) largely on those described in the "Quilt design style guide"; and colors / ideas from: http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines http://library.gnome.org/devel/gtk/unstable/gtk-Resource-Files.html (styles section) A number of things have to come together to make this work: 1) Conceptual model: do we have the right tokens to reflect all color configurable aspects of the UI (e.g. is there a color word appropriate for a highlight selection, a heading, etc) 2) Are they named appropriately (e.g. is selected better than state-light?) 3) What colors should be used in what context? This last one is very tough. As a general rule I've followed the Quilt model and used outline-light for non-edit edges, theme-dark for edit edges and heading backgrounds, etc (you can find a crude list of usage cases under the new "Colors" tab of RebDOC). But what about a widget like button? It potentially has the following color states: Unselected theme-dark Focus theme-light Button-down ? and widgets such as sheet which might have: Headings theme-dark with page font/color text Cells page Edges outline-light Selected cell theme-light Forumla cell theme-light Cell that cursor is currently over and there are a number of ways of denoting this with color: as a background color change as a font color change as an edge color change as a combination of the above In short, there are a lot of ways of implementing this. What I want needs to be simple and consistent with as few colors as possible. Any suggestions (including links to good color management techniques / approaches) greatly appreciated. | |
Anton 1-Jan-2008 [7289x2] | That's a very positive development. A nice set of global named colours, which can be used by every widget. |
I think each widget should have its own named colours for its different parts, like "edge-unselected", "edge-selected". These can be set directly to the global named colours, like colour-themes/light/outline-unselected or to a function of that, eg: button/named-colour/edge-selected: does [desaturate 0.9 colour-themes/light/outline-selected] then button just redraws itself using its own named-colours. | |
Pekr 1-Jan-2008 [7291x2] | why is there any need to make it Quilt or web-anything like? Changes are fine, if those don't ruin overall design. I can't see anything what happened to button positively - it is now flat, one color box with not difference to box widget itself. |
Also - why the change to coloring all tabs? | |
Graham 1-Jan-2008 [7293] | latest checkout >> display "" [ sp: scroll-panel data [ field 10 "Hello" ] button "get values" [ probe get-values sp ]] do-events ** Script Error: foreach expected data argument of type: series ** Where: get-values ** Near: foreach widget face/pane [ if find [ area check check-group drop-list edit-list field group-box password rad... >> |
Ashley 1-Jan-2008 [7294x2] | Tab coloring - see Luis's comments from Thursday 25th above. |
get-values expects a grouping widget; so: scroll-panel data [field field] scroll-panel data [tab-panel data ...] work. For scroll-panel with a single non-grouping widget use: s: scroll-panel data [field] button [print s/pane/1/text A pain I know, but using scroll-panel for a single non-grouping widget would be pretty rare I'd think. | |
Graham 1-Jan-2008 [7296x3] | OK. |
I didn't actually have one widget in the scroll-panel - this was just a test :) | |
How about a 'clear-values accessor? | |
Ashley 1-Jan-2008 [7299] | Use set-values ;) The problem with clear is that it is context dependant, and could be: "" 0 none true false quite often the definition of 'clear-values would be more akin to a reset function; "restore these widgets to my app-defined set of defaults" ... far better to make it explicit with 'set-values then. |
Graham 1-Jan-2008 [7300] | That's what I did .. used set-values :) |
Reichart 1-Jan-2008 [7301x4] | I never clicked on Luis' second link in his post http://www.useit.com/alertbox/tabs.html Jakob Nielsen's Alertbox, September 17, 2007: Tabs, Used Right. |
Cool stuff, the good news is we do every single item correctly in Quilt. | |
Vertical tabs - What are anyone's thoughts on vertical tabs? They look cool, and I can see their use, but they strike me as...well...annoying, similar to my issue with Rotary (spinner). Rotating or obscuring information just seems not worth it. Here is an image of vertical tabs http://en.wikipedia.org/wiki/Image:Vertical_tabs_sample.png Coloured tabs - As to colouring tabs, interesting. I'm a big opponent of colours generally. One of the most common requests we get on our Calendar is to be able to colour meetings. We ARE indeed going to allow this, but I think it is better to keep things neutral. On the Mac, meetings are "categorized" into things like Work and Personal, each of which are given colour. This works well in "personal calendar systems", but this breaks down very quickly when working in a "collaborative calendar system". Who gets to decide the colour of something? What is "something"? As in, is it by project, by who is in it? By what it is (a meeting, a flight, a memo, a call, or other things people can put on a calendar now). All very tricky. | |
Whe nI say Mac, I'm speaking of iCal. An applicaiton on the Mac. Which is very nice looking, but breaks down with REAL use. | |
Geomol 2-Jan-2008 [7305x2] | My points of view is founded in usability, so Vertical tabs: They're not good, when the text is rotated, because it requres too much to read it then. Vertical tabs are good in a telephone book e.g., where each tab only has one letter: A, B, C, etc. Colours: I like colours, when it doesn't look like a painters palette. Done right, colours are very good to give info, so you don't have to read the text to understand. |
Jakob Nielsen does write many interesting things, like this about web functionality, he wrote in 2000: http://www.useit.com/alertbox/20000625.html Read it in general (and not so much about .NET, that's just one technology). It takes time to move the technology and people's behaviour, but I think, he has many valid points. | |
Reichart 2-Jan-2008 [7307] | I wonder if even ABC is too hard on the eyes. Perhaps that is the limit (one letter or number). |
Graham 2-Jan-2008 [7308] | set-values seems to require a 'show after this to update the display. |
Ashley 2-Jan-2008 [7309] | I'll add a show to it, along with a no-show refinement, next build. |
Rod 2-Jan-2008 [7310] | My first impression on the tabs is I would prefer the color effects of unselected and mouse over to be reversed. It seems backwards to have it go from the bold green to the faint green when you mouse over. |
Graham 3-Jan-2008 [7311x2] | I've got some drop down lists that are inside a scroll panel, but the bottom of the drop list goes beyond the bottom of the scroll panel. this means that I can not see the bottom of the list and because there's no keyboard navigation of the drop list, I can't choose the bottom choices. |
http://synapse-images.s3.amazonaws.com/drop-list-display-problem.png | |
Graham 4-Jan-2008 [7313x3] | Got this on clicking on the tree make object! [ code: 312 type: 'script id: 'cannot-use arg1: 'path arg2: 'none! arg3: none near: [pane/1/offset/y: pos pos: pos + ] where: 'show-node |
Nothing appeared in rebgui.log | |
I hope it's not because I've been adding to the tree/data ....! | |
Ashley 4-Jan-2008 [7316] | That would be it. Unlike other list widgets, which use a face iterator to only display visible faces, tree takes a brute-force approach and pre-builds the entire tree based on face/data. At runtime it uses face/data to work out where to position faces. |
Reichart 7-Jan-2008 [7317] | Can you point me to some screen shots of the newest RebGUI, perhaps a few examples from some applications using it? Anyone... Also, I will be finishing those logo examples today. |
Graham 7-Jan-2008 [7318] | I'm not sure if the latest is intended to be the latest as it were. A large number of graphic changes were made. |
Ashley 7-Jan-2008 [7319] | Correct, the look and feel is a work in progress at the moment. screen shots of the newest RebGUI ... I've created a snapshot release here: http://www.dobeash.com/RebGUI/rebgui112.zip Just unzip and run %tour.r and %RebDOC.r to get a feel for where things are at. |
BrianH 7-Jan-2008 [7320] | How's your resize support? The tour and RebDOC were too big for my screen resolution (1024x768) and the windows weren't resizable. |
Ashley 7-Jan-2008 [7321] | Resize works, but only %tour.r uses it at present. If resizing is enabled then the *minimum* screen size is set to starting screen size unless explicitly set via a refinement. Problem in this case is %tour.r has "grown" to 696x785 and %RebDOC.r is 800x829 (and I've not used 1024x768 for a couple of years now). I'll fix this for the next build though. |
Graham 7-Jan-2008 [7322] | Isn't Brian saying that the windows were too big for his 1024x768 ?? |
Reichart 7-Jan-2008 [7323] | Ashley, Very cool... After Dinner will make you a small log LOL clearly you need it. |
amacleod 8-Jan-2008 [7324] | Having trouble with the #HWLVXY codes. I have two group-boxes next to each other. When I resize the window They overlap. I want them both to expand in size "H" and "W" but not overlap. Is this possible? |
Ashley 8-Jan-2008 [7325] | No. You can however have this: display "Test" [ group-box "A" #HW data [field] group-box "B" #HX data [field] ] The resizing model is *very* basic and only supports one widget in a row / column resizing horizontally / vertically. |
Reichart 8-Jan-2008 [7326] | Ok, here are some other examples, and considerations when sized. For example, when you get small, the "hand" looks like the REAL hand on the screen, which could confuse people. So while it is fun at larger sized, it won't work once the pixels drop to less than 4x4 each (my guess). I think you might like the one in the lower right. It is very RACEY, the italics make it look "fast" and the black and red were something I think you requested. If you want me to try something special, or do a treatment like something else you have seen out there, just say the word. This one is a Qtask syndicated Folder. So any file we put in this folder from inside Qtask can be accessed by people outside of Qtask http://www.qtask.com/files.cgi?tab=sFolderList&uuid=YG82XF3CFW8AQ6W5NYTXV9NKE3QT So for example, since this came from the "REBOL SIG" project inside Qtask, Ashley, you can go into that project, and delete this file, which will effectively put it in the Trashcan, and this link will then point to an empty folder for people. |
Robert 12-Jan-2008 [7327x3] | Ashley, please bear in mind that laptop screens these days are: 1280 x 800. I can resize RebDoc, Tour because it's to high. |
BTW: RebDOC is very nice. | |
Looks that I have to backport a lot of stuff to a new RebGUI. | |
Graham 12-Jan-2008 [7330] | Ashley, did you note my problem with drop down lists in a scroll panel?s |
Ashley 12-Jan-2008 [7331] | I did. Correct me if I'm wrong but it's only a problem in scroll-panel's that can scroll vertically? Is there a real (as opposed to theoretical) usage case where you'd need a drop-list in a vertical scrolling panel? |
Graham 12-Jan-2008 [7332] | the screenshot is from my real application :( |
Graham 13-Jan-2008 [7333] | Just had a look at the source again ... as the droplist-mode for drop-list gone? We used to have the option of setting 'auto, 'middle, 'upward and 'dowward |
Ashley 13-Jan-2008 [7334] | Defaults to auto now, and has for some time. |
older newer | first last |