World: r3wp

Agree fully with the color argument, if I say red I mean red. If 
I want a lighter red then I can always write code like:

	button (red + 0.0.0.128)

what do you think of Henrik's buttons/fields

 Buttons are a definite improvement over mine. Fields (and related 
 widgets like area, drop-list, password, etc) get interesting. Let 
 me start by saying that button is by definition a "graphically intensive" 
 widget. The basic view facets (text, edge, effect (non-draw)) only 
 let you do so much so to get buttons that look reasonable you have 
 to go down either the bitmap/effect or draw paths. Fine, I accept 
 that.


Field, and it's related widgets, are mostly textual and you can achieve 
reasonable results using standard text, edge, para and maybe a basic 
effect such as gradient. You can do all this in a dozen lines of 
code. Adding fancy draw effects, and ensuring that they scale as 
the widget is resized, adds significantly to code size/complexity 
and adds another feel over and above the basic edit/feel.


Now, you can be in the aesthetic camp on this one or the KISS camp. 
Does the current field look so bad it warrants such as massive structural 
overhaul? I think not. By all means come up with a better color combination, 
and use simple effects such as gradient that don't rely on setting 
and maintaining draw object sizes.


A few comments suggested that making changes with the current WinXP 
backdrop colors is problematic ... don't use them. If major aesthetic 
improvements require that a different default color set be used then 
design to that and if it all hangs together that will become the 
new default. I'm very open on this.


Another thing I have been thinking on is Window color and Widget 
color. Do we need the later? Another way to handle this (having a 
grouping widget such as tab-panel appear with a color different to 
the window it appears on) is to darken a grouping widget relative 
to its parent. This would allow nested grouping widgets (e.g. tab-panel 
within a tab-panel) to have visually distinctive colors, something 
the current implementation does not handle.

Why are Henrik's buttons so dark?  He says they are intended to be 
whiter.

yes, Graham, an appropriate color would be white for that button.

Ashley, I like the relative darkening/lightening idea. I've been 
mulling this idea for ages. People are going to complain that they've 
lost the ability to set the colour absolutely, though.

I haven't delved to deep.  The last cut of RebGUI I pulled out of 
svn causes a segmentation fault on my Debian Etch RC1 system.

>> do %tour.r
Script: "RebGUI widget tour" (16-Feb-2007)
Script: "RebGUI system" (18-Feb-2007)
>> q
Segmentation fault
[blue-:-dev]:~/gui/rebgui$

Note I did nothing other than start tour, and close it

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3

[blue-:-dev]:~$ uname -a

Linux dev 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Just so ya know.

Try:

	do %rebgui-ctx.r

then a simple display:

	display "test" [text "Here"]
	do-events

build#60 committed to SVN. Added Henrik's button widget with 2 minor 
modifications:

	1) Over color defaults to colors/over
	2) All of init inlined into the effect facet


The first change is self-explanatory, the second follows the principle 
that init should do as little as possible (facet code is evaluated 
once while init code is evaluated every time the widget is used). 
This change has one subtle side-effect, the "Refresh Display" button 
of %tour.r no longer works for all widgets (button in particular). 
This will be fixed in a future build.


One thing to note about the new button widget is its default size: 
15x6 instead of 15x5 units. This should not be a problem for most 
buttons, but may have spacing/alignment issues for inline buttons.


Note that the button change necessitated a small change to request-date 
which is now working again.

Ashley; The simpler test worked ok.  No seg fault.  Again, I haven't 
delved...yet.  Thanks.

Are tooltips fixed then?

Guess not .. still idling on 60% cpu with tour.r

They'll be fixed when the RAMBO detect face bug referred to previously 
is fixed. In lieu of that I made two changes:


 1) Optimized tooltip checking (saves about 5-10% CPU in the case 
 of tour.r)
	2) Tooltips now default to off


I'd like to know how they seem to work for Robert as the code was 
a 100% cut & paste job from his. I suspect the key is to run it under 
windows and ensure that not only is Task Manager up but that the 
RebGUI app (tour.r in this case) is in the foreground. I noticed 
that clicking between a running tour.r and Task Manager (with tooltips 
on) makes a big difference between the reported CPU usage. Perhaps 
Robert is only seeing the later (or is running it on hardware that 
obscures the problem ... I'm on an old Pentium M 1.1GHz here).

Ashley, I expect the next element to complete to be field.r. If you 
want to inspect the code, please.

Tooltips: There is really no balck magic involved. If I activate 
my app and do nothing, the CPU is ideling. No users every reported 
any problems yet.

can you provide a small demo of your rebgui with tooltips like this?

Simplest way is, log into XPEER and take a look at D:\rebol\link\xpeers\users\cyphre\tooltip-test

To use our latest RebGUI version, just create a distirbution from 
projects/rebgui and use this rebgui.r file instead of the one included 
in the test directory.

Could you please run %tour.r against your version of rebgui.r and 
report the CPU usage? I suspect the problem relates to the number 
and depth of widgets within a display. %tour.r is an extremely complex 
single display app in that regards.

Ashley;  (If you are typing at me...) CPU usage is negligible; loading, 
interacting, exiting.  All widgets snappy.

He was talking to Robert.

However, if you are able, can you check on the cpu usage while running 
tour.r ?

Furthermore, don't make me click on the little tiny arrow to the 
right of the edit box before you pop up the combo: let me click anywhere 
on the combo box. This expands the click target about tenfold and 
makes it that much easier to acquire the target with the mouse pointer.

http://www.joelonsoftware.com/uibook/fog0000000249.html

Is this a reasonable thing to try ?

I think yes. I don't like combo boxes where I have to click on tiny 
arrow or radio buttons where I cannot click on text (in VID radio 
vs radio-line). I don't want to perfect my aiming, I just want to 
select an option.

Anyone have an example of how the drop-tree works?  This brings up 
a drop tree but can't figure out how it is supposed to work yet


display "drop tree test" [ drop-tree data [ "root" [ "item1" [ 1 
2 3 ] "item2" [ 4 5 6 ] "item3" [ 7 8 9 ] ]] [ pri
nt face/text ] box 40x60 ] do-events

What's the "standard" keystoke(s) to make a drop-list appear? Down 
arrow?

think so.

on a Windows OS I thought it was the Alt-Down Arrow

Time to clean up radio-group and drop-list. With radio-group I'm 
contemplating getting rid of all the ID code and making it default 
to:

	data [1 "Opt 1" "Opt 2"]


if no option is selected. You'll still be able to start with no option 
selected (either by specifying none or 0), it's just that having 
no option selected by default is confusing to new users.


For drop-list, I want to fix some of the remaining bugs and add the 
two changes discussed above; clicking anywhere in the area to activate 
the drop list and pressing DnAr to activate it by keystroke. The 
first change could really confuse folks used to changing focus by 
mouse click so I'm thinking of making it an option, say "options 
[click]". Comments?

I have hundreds of templates in use that rely on the current behaviour 
 ... for radio-group

If you do change it I will just have to keep the old version

RebGUI expert needed on REBOLTalk:
http://www.reboltalk.com/forum/index.php/topic,739.0.html

Done.

radio-group: Ok, we are going to give our version a new name. As 
I still think, our approach is much more advanced WRT code maintenance 
and flexiblity. So, we have the choice.

I keep investing into RebGUI and it will continue, but at the moment, 
I think we drift to far away. IMO it doesn't make sense to have two 
forks. I really want to backport/merge things but for this I need 
some help.

Gregg: drop-tree works like a menu system.

display "drop tree test" [
	drop-tree data [
		"root" [
			"item1" [ item-1-action-code]
			"item2" [ item-2-action-code]
			"item3" [ ]
		 ][root-action-code]
	]
]

That's it.

Further: http://trac.geekisp.com/rebgui/wiki/WidgetList#drop-tree

Sorry, you need to use the ACTION keyword before an action-block.

Robert, did you get a chance to do the tool-tip test with tour.r 
against your version of rebgui.r? If so, what was the CPU reading 
and what value did you have for tool-tip-delay? As I mentioned before, 
I think tool-tips are dying on 'find-face when the display is sufficiently 
"complex".

I think we drift to far away

 ... depends on the extent to which you have changed/enhanced core 
 RebGUI functionality (e.g. rebgui-*.r scripts). If most of your changes 
 are isolated to new/enhanced widgets then there is really no drift; 
 you can plug your widgets into the standard RebGUI engine and it 
 will all work. If you want to keep your changes in sync then I suggest 
 2 simple practices:


 1) If you need a version of a standard widget (e.g. radio-group) 
 to do things that are app or design philosophy specific then create 
 your own widget instance and suffix it with an identifier, say XP 
 for XPeers in your case (e.g. radio-groupXP). Suffixes are preferred 
 over prefixes as the alphabetical sort order of the widgets determines 
 their load order which may affect dependencies ... see text.r and 
 label.r for examples of this.


 2) Only keep and maintain a divergent Widgets directory ensuring 
 that your widgets continue to work with the standard RebGUI engine 
 (i.e. rebgui-*.r scripts). If you need the base engine enhanced (e.g. 
 to support tool-tips or proportional resizing) then let's isolate 
 those changes and get them into the base distribution.


You should be able to create and maintain your own widgets without 
worrying about divergence as most of the design effort should be 
going into the functionality of the widget(s) themselves. If your 
widget needs specific changes/enhancements to the base engine then 
we need to sync those changes at the point you need them. Trying 
to retrofit these after the event, and after multiple divergent engine 
changes, is going to cause problems as you've discovered.


From my end, the 3 major changes you should probably try and work 
back into your fork are:

	1) UI settings: mostly confined to rebgui-ctx.r

 2) rebind func added to all widgets prior to init and rebgui-widgets.r 
 enhanced

 3) tab-panel rewritten to operate significantly more efficiently 
 (tab-panel.r and associated rebgui-edit.r changes)

A word on my design philosophy, which might help determine whether 
you can live with the standard widgets or not.


I like widgets that are small, efficient and satisfy the majority 
usage case. I want to be able to look at a widget I or someone-else 
wrote and "grok" it quickly. When I rewrite a widget I'd like to 
make it simpler and more efficient. Let's look at tab-panel as a 
case in point. It now does everything I'd reasonably expect it to 
do:

	1) Multiple tabs
	2) Auto label size determination
	3) Automatic widget size and resize
	4) Supports Tab actions

 5) Options to start with another tab selected and fire the initial 
 action


The code is simple, clean, efficient and weighs in at just over a 
hundred lines. I can look at it and "grok" it in a couple of seconds. 
But there are many additional things it could do:

	1) Ability to add/remove tabs at runtime
	2) Ability to rename/reorder tabs
	3) Handle case where tabs > available display width


But you get diminishing returns when you implement functionality 
to support these operations as they don't constitute the major usage 
case, and you can code most of them at the app layer by treating 
the tab-panel data block as a block of data that you can manipulate 
and display (via an unview/redisplay sequence).


But what about the third point, where the tabs don't fit? Isn't that 
a problem? No, that's an app design issue. It's no different from:

	display "Test" [
		text 10 "Some long text that doesn't fit"
		radio-group 20x5 data ["Option 1" "Option 2"]
		drop-list 15 data ["Some long text that doesn't fit"]
	] 


You have to allocate sufficient space for your widgets to render 
correctly. If you need to render volumes of data that won't fit then 
use area or a list type widget (e.g. text-list, drop-list, table, 
grid, etc).


My aim is to progressively review and rewrite each widget to conform 
to the above design philosophy, starting with the simpler widgets 
and leaving the more complex ones till last. I'm about half way through 
at present.

And that is something I am not sure I agree with. For me, the widgets 
should be "trouble-free".  If tabs don't fit, there should be arrows, 
or drop-down menu, which should allow you to scroll imo ....

The same goes for menu. When I was testing for Cyphre (his stylepack), 
I pushed Cyphre to solve menu resolving screen position, to enable 
it to always fit the screen = menu displayed always to be visible.

Simplicity is good, but what is your point here actually?

I don't care if particular style has hundred or thousand of lines, 
if it runs fast, is trouble-free, I don't really care for how many 
lines of code it contains.

And I can guarantee you, that once the style is "over-simplified", 
it can just piss-off ppl. Just look at list-box, allowing you to 
scroll-under the border. The style is small, yet I I am not able 
to fix it myself, and I don't want to care - I just want to use it.

So - that is just my perspective, perspective of user :-)

Tour: Sorry guys for being late with this test. After making some 
minor modifications to get tour.r to run with our version and adding 
a TOOLTIP to the password page "Some Text" field I can say that I 
don't see any CPU usage.

It's not noticeable at all.

The value for TOOL-TIP-DELAY I use is 0:0:1

forking: Ok, adding specific version of widgets is OK for me. Even 
we really should avoid this. But anyway, I seem to be the only one 
seeing a problem with the standard radio-group thing.

We take a look at the three major changes you have mentioned.

And my philosophi lies between Ashley and Petr. I'm in more favour 
to spend time designing simple widgets that have a hughe feature 
set. Because than, my app development times are reduced radically. 
Hence, thinking once at the widget level, saves you factors of time 
on the  application level.