World: r3wp

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.

And, RebGUI has shown to be asolutly perfect in this. It's simple, 
efficient, and comfortable enough to write big apps. My app's code 
base is about 400K now, than we add 190K RebGUI, and some other stuff. 
So overall the  pre-processed script is about 1MB in size.

Robert - 400K? That is monstrose, in REBOL terms, isn't it? What 
is reaction of your users to non-OS compatible app? Just curious 
...

forgot to add smiley to "monstrose" :-)

Well, the app is quite complex.

I have never been asked about non-OS like GUI (I think that's what 
you mean). They like the app and it's simple design.

Still having problems with tooltips. I've cut & paste your tool-tip 
code from XPeers and I still get 60%+ CPU use with tour.r. Where 
can I grab a copy of your rebgui.r that you tested with?

Also your modified tour.r. Thanks.

Is there a suitable widget that can simulate the messages list here? 
 I built one before for Vid based upon DideC's code ...

Isn't Ashley making a Chat widget?

Not that I am aware of.

Petr: the Detective is around 750k once preboled. And I better not 
tell you how big Qtask is.

I've got a few scripts that live in the several hundred kbs... in 
fact GLayout now weights in at 180k (far too much of that being comments 
and history ;-)

gabriele: does the 750k count all the sdk libs themselves?

Ashely, Gabriele and Romano did a RTF style

It says it should work with an face with text in it ..

Would it be possible to use it in Rebgui?

http://www.colellachiara.com/soft/Libs/render-rich-text.r

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

Ok. Noted.

Max, yes, but that is probably under 100k.

Ashley, you will find it in the RebGUI directory on xpeers. That's 
the code base we use. Just log in, and take a look at projects/rebgui. 
That's our distribution.

BTW: Can we somehow align while you do RebGUI 2? I want to follow 
the new release and provide our code to it as well.

Ashley - Cyphre was supposed to strip tree vidget from drop-tree 
IIRC. Dunno the status ...

I was on xpeers recently .. didn't see a rebgui directory.

Projects/RebGUI

IIRC I saw some tree stuff. But didn't tested it yet. But will need 
it soon.

I didn't see it initially, then rebol-link started doing an update.

Now I have hundreds of these requesters coming up 


The file framework/libraries/gui.r was modified locally and a new 
version from the server is available. Do you want to create a backup-copy 
of the local file?

Must be some timezone problem.

Just say no, normally it's stopping after a couple of files. Or disable 
the requester in the options (IIRC it can be configured).

finished now .. it was about 50 files or so that I had to do this 
for.

Some nice looking charts you have there Robert.

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

I'm looking at adding a simple format mask attribute to RebGUI for 
editable widgets such as field, area, edit-list and drop-list. Basic 
idea is that if a bitset! exists in the spec it is assigned to a 
new 'mask attribute which is checked prior to every keystroke that 
would insert a char into the text attribute. This would allow specifications 
such as:

	display "Test" [
		field (charset [#"0" - #"9"])
		field digits
		area no-special-chars
		field phone-chars
	]


and has the advantage that the code resides within the RebGUI edit 
feel and can be used by any editable widget. Specification, as above, 
is also natural as bitset! is not mapped to any other attribute and 
is a natural mapping for character edit masks.


If an invalid char is encountered then the keystroke will be discarded 
and perhaps the field can blink or flash as a visual cue?


I'm also toying with adding a datatype! attribute to the spec which 
would be used like:

	display "Test" [
		field digits integer!
		field digits-and-seperators date!
	]


and create an on-unfocus trigger that tries to "set-text self form 
to-datatype" and blanks or blinks the field on failure (and prevents 
leaving the field).


Need to nut out exactly how this would work, but the question is, 
is this useful for folks; or is it more trouble than it's worth (given 
that it is not a fully fledged edit mask solution).

ashley, maybe you can find some inspiration in this: http://www.hmkdesign.dk/rebol/vid/docs/vid-field.html

spelling: "sep*a*rators"

It's a good idea - except the flashing and blinking should not be 
default. I think that is only necessary for specific cases.

Well, how do you provide a fully fledged edit mask solution ? Since 
folks could implement it many custom ways, I would provide a callback 
function when key input events are received. The user's callback 
function return value can indicate whether the key should be accepted 
or not. (it could return the character that should be inserted or 
none!)

When a bitset is provided, then the callback is set to a bitset masking 
function.