World: r3wp

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.

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.