World: r3wp

Yesterday I had a phone call with Christian Ensel and we talked about 
how to add more eyecandy to RebGUI. As the RebGUI architecture is 
becoming more and more stable, how about thinking about a simple 
and lightweigth skinning system?

Our idea was to seperate the visual aspects of the widgets into something 
like an own LOOK context. We don't want to made the current widgets 
much more complex. Then RebGUI loads the rebgui-widgets.r and rebgui-look.r 
and you either get Mac, Win or whatevery style you want.

Ashley, do you think this is possible or will it be to complex?

That's a pretty good approach actually, much like the way locale 
is currently handled. Also fairly easy to implement now that metrics 
/ colors / effects have been centralized. I'll look at adding this 
to the next build.

my vote - go for it ... apart from solid grid/table style, it is 
a bit uniformly (XPish) looking, although latest global changes + 
effects ability helped it ...

guys - but what about solving that event problem - I noticed that 
in VID, you are able to close pop-up menus by clicking elsewhere 
... in Rebgui not .... I thought it is View low level problem, but 
now it seems it is not ...

0.4.1 is out and is predominantly a maintenance release. From a REBOL/View 
console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r

Main changes include:

	- set-sizes, set-colors, set-fonts added to global context
	- CTRL-A fires action in text-list / table 'multi mode
	- radio-group, led-group, check-group now auto-size vertically
	- layout now handles false (logic!) correctly

 - effects, sizes and colors can be loaded at startup via like-named 
 dat files (simple skinning system)
	- Minor documentation updates to reflect above changes

Pekr, I promise I have this on my list; I'd like to do so, too! But 
the problem with events is that you'll have to deal with problems 
in any event ;-)

WRT to look'n'feel, yes, I think that since most RebGUI widget largely 
depend on draw blocks, it should be possible to put them in the LOOK 
context Robert already mentioned. And by splitting one draw block 
in up to a hand full at most even for complex widgets, with some 
luck you may also make code even more readable and maintainable than 
it is already by seperating e.g. init-only, redraw on every REDRAW 
and redraw on resize stuff into named blocks, which together build 
an effect as in [draw [...constant drawings ...] draw [... state 
dependend stuff ...] draw [...etc...]] I have this in some experimental 
widgets I build to examine and get used to RebGUI done this way without 
noticeable loss of performance. With the EFFECT/DRAW/17: BLACK and 
EFFECT/DRAW/31: 2 * UNIT-SIZE approach one has a hard time to understand 
what's going on a week after you wrote some widget and carves his 
widgets into stone since one will never be bold enough to make only 
modest changes to the drawing sequences later ...

Iiiik, who is it complaining on lengthy draw blocks here and building 
up sentences like these at the same time ...;-)

Finally, Pekr, since I know you're really concerned because of the 
current pop-up menu behaviour, you may happen to have an oppinion 
on how over events for e.g. buttons are to be handled while a menu 
is currently open, too. I think I don't like them to change their 
look by simple hovering, because that would suggest that one click 
will be enough to trigger a button's action. 


But do you think that it shouldn't work this way, too? Or do you 
like the first click next to a menu should make the menu go away 
AND trigger the button instead of getting eaten? I haven't really 
made up my mind on this, and I think that even some well know user 
interfaces are inconsistent in handling this (even though I've never 
studied that systematically, just writing from memory).

On the draw block comments I agree 100% ... I'd like to refactor 
*all* draw block code into a central container where it can live 
side by side with SVG code [once we have RebGUI support for that].

next update - can we change request to rebgui-request-*

I prefer "click-through", the single-click is not eaten. I get really 
annoyed when my click events are eaten just for some application 
refocus.

Looks like there's a start http://trac.geekisp.com/rebgui

Jaime has kindly agreed to host RebGUI as an SVN / Trac project and 
our intent is to open up both the code and documentation to full 
collaborative development and revision control (as a large number 
of people have requested in private correspondence to me). A fair 
bit of work is required before this can "go live" (I still need to 
familiarize myself with these "new" technologies), but I'd hope to 
have something in place within a week. Full details will then be 
announced.

ChristianE - just don't complicate things and do it the way other 
OS compliant apps do it - there is no need to come up what we think 
would be the best, because the next guy may not like it anyway ...

Hi Pekr, I don't understand, sorry. I think that even OSes are inconsistend 
there. My personal taste would be some event eating, but I have what 
others like. 

Actually, I'm used to one single OS Windows, forgotten how Intuition 
did such things on Amiga and know nothing about Unix, Mac and such. 
That's why I'am asking how OSes do it.

Promising much too much here: "but I have what others like" = "but 
I have no idea on what others like". Sorry.

well, so we have altme, even with file-sharing, and we are moving 
to clumsy web methods? :-)

Pekr, I presume you have lots of experience with this tool to make 
this comment.

Ashley (and others): As RebGUI is designed to stay short and clean, 
chances are, that users want to do own custom styles which aren't 
subject to become part of the standard distro but rather be added 
on a per project basis. With the latest change to e.g. SET-SIZES, 
I for now don't see how to do that in a compatible manner:


In case a user likes to have his widgets respond to unit- and font-size 
changes as the standard widgets do it looks like one has to patch 
SET-SIZES, or am I missing something? You reset all standard  widgets 
there in one central location, which is very elegant, but it looks 
as you have no chance of knowing about styles added later with 

        CTX-REBGUI/WIDGETS: MAKE CTX-REBGUI/WIDGETS [... new widgets here 
        ...] BIND IN CTX-REBGUI 'SELF


May I suggest some mechanism in the widgets FEEL, something like 
RESET or RESIZE, which simply get's triggered from within SET-SIZES 
for all widgets. A RESIZE feel function would have the benefit of 
keeping simply size-changing-related calculations out of the usual 
REDRAW which I'd prefer to be reserved for rapid state changes thru 
user interactions and content changes.


Then, in SET-SIZES you'd simply do some FOREACH WIDGET/WIDGETS [WIDGET/FEEL/RESIZE 
WDIGET NEW-SIZE WIDGET/FEEL/REFONT WIDGET NEW-FONT] 


On the other hand, I'm sure you had good arguments on why not to 
feature an explicit resize and refont mechanism. But me I never understood 
why e.g. RESIZE wasn't in VIEW/VIDs shared FEEL contexts, too, and 
now I'm facing kind of a deja vu with RebGUI ... ;-)

Currently, every widget has to be prepared for window-, unit- and 
font-size changes at any time when redrawing. I'd expect them to 
be handled easier and even faster if they'd be slightly more explicit. 
But, as I've said, I may be missing the point here. Eventually you'd 
simply suggest to do 

	redraw: func [face action event] [
		if face/size <> face/old-size [face/feel/resize face]
		if face/old-sizes <> sizes [face/feel/rescale face]
		if any [
			face/font/old-font <> face/font
			face/font <> face/old-font
		][
			face/feel/rewrite font
		]
		:
	]

But it would be kind of boring to so in every single widget.

(Just thinking out loud)

Yet again a suggestion I agree with 100%. ;) By way of explanation, 
the current system evolved from being completely static (all metrics 
/ colors known at object creation) to one that included dynamic offset 
/ size changes (#HWXY directives) and only just recently dynamic 
control over metrics / colors (and as indicated with the previous 
discussion on centralized / shared draw blocks - it still has some 
way to evolve).

Graham - first- I was just making fun without even looking into the 
site, watch the smiley (altough I noticed I am overusing them). OTOH 
I really don't like wiki systems, because most of the time, they 
are not UI clean for me ... it exposes its interface all around. 
The site provided though seems to have nice design ...

The first step to getting the collaborative documentation up is to 
migrate the widget specific documentation across; and this gives 
us the opportunity to reformat and expand upon the content. But what 
template to use? If you have an opinion on this then cruise along 
to http://trac.geekisp.com/rebgui/wiki/WidgetList#areaand click 
"Edit this page" to play around with the content and formating of 
this single entry (area). Once we are happy with the format I'll 
use it as a template to bring across all the other widget descriptions.

Can you make it so that each widget drills down to the source for 
that widget?

In the works. I've already restructured the source by removing each 
widget (from %rebgui-widgets.r) to its own <widget>.r file under 
a new %widgets/ directory. Next step is to create a link to each 
source file under its matching WidgetsList Wiki entry.


I've also created a monolithic script (striped output from prebol.r) 
which resides at: http://www.dobeash.com/RebGUI/rebgui.zip


The intention at this stage is to have multiple source files that 
can be collaboratively worked on, with a "build" every so often to 
merge them into a single script for easy access / deployment (not 
everyone will want to grab the source from SVN). The fact that each 
widget resides in its own source file now makes it very easy to "plugin" 
additional widgets.

I guess this means that other widgets that have not been "approved" 
can be uploaded .. but not included in the final distribution until 
finalised.

svn can also be setup to allow alternate distributions ...

Yes to the first question, with six widgets not making the cut (I'll 
upload them later):

	area2 (area plus horizontal scroll ... does not work correctly)
	auto-fill (needs to be reworked)
	list-view (code needs a bit more work)
	spinner (not completed)
	icon (awaiting SVG renderer code)
	svg-tool-bar (awaiting SVG renderer code)

Alternate distributions: let's keep it simple for the moment ...

How to clear the text in a title group?


title-group/text: copy "" show title-group doesn't work as junk is 
still left on the screen, and there's no title-group/text/line-list 
attribute to set.

also, tried title-group/pane/text: copy ""

Added a reproducible defect into the trac ...

this is a temporary "fix" for line 549 in rebgui-edit.r

if none? caret: caret-to-offset face view*/caret [ return ]

title-group: show-text works with the body, while you can do a:

	insert clear tg/pane/text "New title"
	show tg


to change the title. Note that this will not cater for a change in 
number of lines.

Hmm.  I'll still getting garbage characters in the main text area.

Can you reproduce the problem with the title-group in %tour.r?

Yes.

I named the title-group tg, and I have a button "clear" [ set-text 
tg "" show tg ]
It does not clear the text cleanly.

That's odd. Changing "" to " " works fine (I tried copy "" but no 
luck). At least it's easy to reproduce! ;) I'll take a look at it 
over the weekend when I get some time.

I've made a trac defect entry for this issue.

I put up some preliminary changes to the modal popup handling for 
RebGUI. By manually replacing the original files (but keep them in 
a safe place!) with


 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-widgets.r

 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-dialog.r


you should be able to try them. You'll notice a different and more 
common behaviour of drop- and edit-lists. For the existing styles 
as can be found in the tour script, I haven't experienced unexpected 
results so far. But I'm curious to hear if incompatibilities arise 
in more complex applications that need to be addressed.

Oh, what silly bugs I left in my code! So, don't take it too serious 
for now ...

Graham - not sure if the problem with the clearng of text area but 
most often I almost always set line-list to 0 each time I clear a 
field  so that might be the issue your seeing.

In this case, there is no line-list attribute :(

huh? every face has a line-list attribute.

line-list is the culprit. Replace the 'show-text and 'clear-text 
functions in %rebgui.r with the following:

show-text: make function! [
	"Sets a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/focus
][
	face/line-list: none
	insert clear face/text form text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	either focus [ctx-rebgui/edit/focus face] [show face]
]

clear-text: make function! [
	"Clears a widget's text attribute."
	face [object!]
	/no-show "Don't show"
	/focus
][
	face/line-list: none
	clear face/text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

ashley, are you still interested in list-view?

Yes, but it's still evolving isn't it?