World: r3wp

Robert: I don't know, I'm not author of HyperNotes, Martin Johannesson 
is. However, he wrote to me, that current version of his list is 
little bit tricky and he's working on new version. So maybe the new 
version may be rewritten for RebGUI. If you like to have a look at 
my patched version of HyperNotes, just let me know.

The problem I see with the general get-face/set-face approach on 
panels is that values are ordered and unnamed. This makes maintenance 
a problem because, depending on how you deal with that data, you 
have to change things, be aware of the order of fields, etc. It can 
be a nightmare IME. Of course, I want a solution that minimizes my 
code, but I'm even more concerned about keeping it correct.

Gregg, I totally agree. And it's one of those things that drive me 
nuts in VID / View. Sorting faces for z-ordering etc. is really no 
fun. And I have no way to get a reference that's stable.

My standard approach is to write collect and display routines, which 
isn't so bad if we have a form framework that can do it intelligently, 
or generate the code for us.

;-) Issued the request to add this to rebgui.

The nice thing is, that if you create a set of faces that need to 
be collected/restored you don't have to use a zillion of face words. 
You specify them via flags.

Gregg: my code above fixes just that, uses name: value instead of 
just block of value.

The approach I'm looking at will flag widgets (via the options block?) 
with both a reference word and an [optional]  datatype specification. 
You will than have functions like:


 put-values my-display [f1: "Some text" f2: 3-Jan-2005 f5: $20.50]

 put-values/all my-display ["Some text" 3-Jan-2005 3x4 "Fourth field" 
 $20.50]
	get-values my-display [f5 f2]
	get-values/all my-display []


so you can put and get values either by reference, or just do the 
whole lot directly with a /all refinement. The optional datatype 
specification will force a conversion on the returned value. get-values 
will stop at the first failed datatype conversion, instead returning 
the widget reference word.


Still in the planning stage, so other / further suggestions welcome.

The interface should be compatible with SQLite, so that no block 
transformation is required. Getting data from SQLite directly to 
the GUI and back.

options block: Yes, good approach.

I expect /ALL only to use ALL widgets that have been flaged.

data-conversion: It would be nice if I can register a call-back function 
that is used.

Just had an unusual enhancement request from a customer of mine. 
As they fill in fields and areas on a form, they want the ability 
to press Ctrl+B to bold the contents of an entire field / area so 
as they can visually note and review what is important prior to clicking 
"Save" and moving to the next form. It would be fairly easy to add 
this to RebGUI (a Ctrl-B bold toggle), but would anyone else find 
this useful?

quite non typical ... I wonder ppl don't miss underlined accelerator 
keys, ctrl + tab to toggle between the tabs and clicking away from 
list-down to close :-)

Because those issues are important to IT folks and totally irrelevant 
to most real world users? ;) Most users don't even know they *can* 
drive a GUI via the keyboard, and if they click on a drop-list they 
*will* pick an item, even it's a blank "no selection" choice (I always 
have the first item of my pick lists as an empty string so users 
can easily click their way out instead of having to press ESC).


  As an aside, what most of my customers were complaining about, until 
  recently fixed, was the fact that drop-lists didn't scale to fit 
  the most items possible ... something no-one here even noticed! ;)

Need request-file/keep .. have to comment out rebgui's request-file 
because it lacks this.  Thanks.

Issue#47 ... raised by ... Graham. ;)

Ashley - that is simply rudiculous. I have 300+ users at my sight. 
Those type data into system. You really depreciate the fact how ppl 
use computer - the mouse is waste of time, totally ...

well, drop list is not good example of how to use gui via keyboard, 
I do agree :-) our users are not typical users maybe, as they come 
from terminal SAP R2historically, where there was no mouse :-)

my complaint to drop-list is, that it is kind of menu ... and in 
rebol it is driven via show-popup? And that is broken .... I am used 
to close menu by clicking somewhere else .... it happens occassionally, 
when I unintentionally press right mouse button etc., and I really 
don't want any option to be selected ..... so I just move mouse out 
of the menu, and do a left mouse press ... not so with rebol ....

ctrl + tab not even being trapped by rebol view engine is total fiasco 
and I was slammed for that one pretty hard ...

If the mouse is a waste of time for your users, then they don't need 
a GUI. Just deliver data entry functionality via a console type application. 
My users [medical] make extensive use of TabletPCs so no mouse / 
pen is a bit of a deal-breaker for me. ;)

the mouse is waste of time, totally

 ... so you don't use a mouse for file management (File Explorer) 
 or browsing? And of course you don't need one for Paint type operations? 
 Not everyone who uses a computer is doing pure keyed data entry. 
 Different strokes for different folks.


Anyway, I'm gradually adding keyboard support to RebGUI as time and 
REBOL fixes permit; but it's not high on my list of priorities.

File management? Ah no, you Windows users :-) I would really like 
to see a video, how one can work effectively using such sh*t like 
windows explorer :-) No, I do use Total commander, totally without 
single mouse press ....

and don't try to suggest type of application for my users :-) With 
our past system (now they use SAP R3 and they do complain), they 
used GUI Visual Objects based app - no keyboard, maybe unless they 
wanted something from menu - all forms plus grid were keyboard driven 
- they complained, if some form contained something requiring them 
to touch mouse ....

I am not saying anything - if it works for you, well then. But - 
it does not work for me. I point to the issue of weak keyboard support 
for years. And I know MANY ppl who comlain for rebol not being OS 
friendly. Just go into OS-X group and look what Geomol says about 
proper OS support. I think that ppl are forgiving to a bit different 
look, but not to non-os-compliant behavior ...

and as for browsing - yes, I very often use keyboard - to open new 
tabs (ctrl t), typing search phrase, pressing arrow down (=pointing 
it to google) .... or simply using "find as you type", enter, backspace 
for navigation :-) But that is available in Mozilla/FF

We have the Rebgui sources .. we can add support as needed if Ashley 
is too busy, or we can wait for his schedule.

If rebol doesn't support it ... better to hassle Carl instead.

we can't - what you do to switch between tabs, where os uses ctrl 
+ tab, = combination, which rebol does not catch under the hood?

I give up - I hassle them for years, meeting the barriers as Holger, 
or Gabriele, trying to explain me, that universal keyboard cross-platform 
manager is not easy to introduce ... well, I don't care, because 
I don't think, that rebol should support only the lowest common denominator 
of features ... it should play nice with the host os

is this relevant to RebGUI ??

If Rebol doesn't support it, then no point mentioning it here ...

it started with ctrl + B for bold .... so I mentioned I want ctrl 
+ tab, and ability to close menu clicking elsewhere ... at lest the 
second one is in our hands, but rather complicated, if I understand 
the problematics correctly

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 ...