World: r3wp

I'd redesign that widget later to use completely square buttons.

dumped the 3D groove, which simplified the draw block somewhat

button.r updated

I can see very small problem with hiliting, but that might be deeper 
rebol bug? Go to requestors, try to select some date ... the button 
stays hilited, unless you move mouse over it once again ...

I see your bug and raise you one fix. :-) (I think it's a poker term)

:-)

early field.r uploaded. have to go out for a bit...

ok ...

field.r improved a bit.

Interesting to see those old styles :)

field.r updated again. working a bit on password now.

password.r uploaded

its funny cause through all those years of working on glayout, I 
never really took the time work on the actual aesthetics, that was 
not the point of GLayout... and since its built over VID... well 
we can effectively rework all and reuse most VID styles.


  somehow, I find, with the looks derived from henrik's previous tests, 
  where very close to what I would have done myself (hehe henrik and 
  I have to meet at devcon... I think we'd have much in common) Glayout 
  has found itself a simple yet elegant look.  The latest version have 
  started to work a bit more towards looks, and now the highlight is 
  used throughout, so one can change one line and switch  the default 
  golden color to anyone... I'm trying out grey blue these days.

sorry to cut in... but you where all talking about a subject I like 
so much.  I wish I had more time to make GLayout flashy... alas, 
like Anton, I work more on the the actual featureset and api, allowing 
anyone a vast array of tools he can reuse in his styles...

(end of involuntary GLayout intrusion  ;-)

Henrik - nice, although I don't understand what you are upto with 
fields/password-fields. The thing is a bit tricky. Overall, I started 
to like field with thin borders (not like ugly VID ones with border 
of 2x2, that is just so old-days)

But, imo, if you want to change fields, it should be on pair with 
drop-downs etc., which do use field too ... and if you put fields 
into tab, group-box, those would need change too imo ...

btw - I like Cyphre's fading group-box styling - http://www.xidys.com/cyphre-styles.jpg.
That fade-out should be possible with new draw even more. And maybe 
it could be used even for your field effect :-)

but OK, your button is definitely better than initial Ashley's attempt. 
Well, IMO, but I think most would agree here? I will let you adapt 
further some styles and let's see how feel of RebGUI changes in  
general ...

small glitch - go to Grouping\Panel .... resize the screen to make 
it wider. Name field gets strange color problem ...

yes, I noticed. I forgot whether the field was originally supposed 
to stretch there?

field.r updated with a slightly better defined edge

hmm, I work on rather old notebook right now, but the top border 
is much darker than other sides of the field, making the almost invisible 
to me ...

ok, do you have a bright background? does it look better on a medium 
gray?

I would finish button first - making it taller few pixels? Then move 
on to tabs maybe .... group box and panel - do you like them rounded? 
I am not sure what my own answer is :-)

Henrik - if I look into grouping\panel, then field looks nice on 
the cyan background ...

I think I'll leave button for now, because I don't really know what 
else to add to it yet. I will probably go around all elements over 
time and when I reach the last one, I'll start going over them again 
for more polish.

I also feel like doing a bitmapped theme. It's easier to do.

yes, overall I like the button. It is just that I agreed with you, 
that it should be probably a bit taller :-)

button is now a bit deeper than before causing visual problems.

Also, if you try and change the button color in tour.r, it remains 
quite dark gray.

Ashley, what do you think of Henrik's buttons/fields ?

I like Henrik's buttons better, maybe just coloring could be a bit 
more "mild"(?), so that blue is not actually so much blue etc. :-)

Pekr, that's a bit of a dilemma, since tour.r just makes example 
buttons. If you want to create esthetically pleasing buttons, don't 
use primary colors. The point is really that you can if you want 
to. I don't personally really like that you are not able to create 
buttons in exactly the color you want with BTN in VID.

that might be valid point, Henrik ...

not being able to use exactly the color you want, could cause problems 
if you are trying to match a specific color in the background of 
your GUI.

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?