World: r3wp

and no i am not talking about an edit-list. And is not an auto-fill 
per se routine. More like a keystroke capture routine so that it 
would do a search on the list  = )

Luisc: usually, drop-lists don't work well with big lists - it's 
quite hard on long lists to select something without mistakely closing 
the list. A classic text-list is far more suited for anything longer 
than 10 elements. A 60 items drop-list will raise a lot of problems: 
if the widget is too low on screen, most of the choices will be hidden.

Unless your droplist widget adds a scrollbar when there are more 
elements than you specify space in the widget for, like in Windows.

the combo-box? yes but it's one of the more complicate, buggy and 
error-prone interface in Windows. it's like a popup textlist associated 
with an editable field. (had painful moments with it in Visual Basic)

I'd have to agree with you if that error-prone complaint is about 
the usability of that kind of control once it's implemented. Still, 
is there a better way of doing what it does? The Mac way perhaps?

Yes about usability. It's a all-in-one widget: one can use it to 
replace menu, lists, simple requesters (like the fonts and colors 
selection in MSWord), toolbars, auto-complete fields, etc. So it's 
mostly a shortcut to put more widgets (or compact them) in a window 
and can be confusing for users: what will happen if I select something, 
write in the field, click outside the list, click inside on the left, 
on the right, hit enter? It's a full requester in one widget: you 
can do the same with a request-list -like requester with ok/cancel 
buttons.

Vincent i understand what you are saying and i totally agree with 
you. It is not a big issue all i am trying to convey is that if you 
have a non-editable field with different choices it would be easier 
for some of us  to select those choices with the keyboard instead 
of the mouse.

when you select the language for windows installation, and the timezone 
etc, they use these very large unwieldly drop lists :(

Oh, I hate that. Even worse, most of the time you can speed up the 
process of selecting from a dropdown by typing the first letter of 
your selection, but all of the time zone selections start with ( 
so that speedup doesn't work with them.

Luisc we have 2 item in fact edit-list to handle large data with 
some useful stuf like list vertical scroller and auto-fill field 
This is what you want. And the drop -list widget that is for handle 
tinny list of data :)

Luisc so what you need is yet planned and it's called editor-list 
not drop-list ;)

ah! thank you shadwolf   = )

your welcome ;)

lastest version of my work on Listview widget is available here http://shadwolf.free.fr/rebgui-list49.r

as shown is the example programmer hav only to give to list-viewdata: 
field the new list content then make a show listview to see the chages 
made on the listview.

I'm going to work some days on MDPWiki Project so during this time 
I want you to make me lot of comments and suggestion on listview 
widget. Once  I'm done with MDPwiki I will retake all the comments 
and suggestions and add them to listview ;)

sugestion can be new widget types, bugs reports etc...

Can we prefix all files required for a valid distribution of RebGUI 
with regbui-* please? Makes adding it to existing frameworks etc. 
much simpler.

Robert normally rebgui files are disigned to be placed into a sub 
sub folder

in your main script you put a do %sub-folder/gui.r and that's all 
;)

sometimes its easier to put all in one folder. you see all at once, 
no need for tools to recurse, and ios uploads more easily.

i would like something short, rg- or such.

How about a merge of all RebGUI files into a single file called %rebgui.r?

for me the packagin way is insignificant ;) must be done has the 
people perfer having several files is more easy to see what is integrated

packaging: I vote for it. What's up with the requestors? Are these 
always needed? If possible we should find a way to pack those things 
together that are always needed and let the rest be optional.

Prefix rg- is OK with me. But remember, people don't know what rg- 
means, and rebgui is only four letters more but hundreds of questions 
less. Never shorten things just to shorten them... semantic is the 
key.

rebgui needs to be easy to use: Just copy, load and use. :-)) That's 
what I like about it.

Now that makes for a really nice slogan, Robert: "only four letters 
more but hundreds of questions less". It's as true as that of the 
well-known picture, which says more than thousand words. Comes down 
to: One word says more than thousand letters ;-)

Regarding scrollers and sliders in RebGUI: I examine a strange behaviour 
here. If you grab a knob near it's edge (left/right for horizontal, 
top/bottom for vertical scrollers) and drag it, you'll notice how 
the mouse pointer's offset to the knob changes relative to the amount 
that the knob changes it's offset from the scrollers boundaries. 
I haven't seen something like that in any of the (not so many) UIs 
I've came across, so I'd suggest that this gets fixed to conform 
to what people are used to.

The current implementation may even cause "knob flickering" if you 
grab a knob positioned at the top/left end of a scroller at the knob's 
bottom/right end. The knob then jumps noticeable.

Christian they have been yet fixed that was worst before hehehe (I 
know what I'm talking about it was me who fix preveious  scroller 
grabbing  problem...)

the problemis when you work with related data... Why the grab button 
jumps ? Because the event/offset so the mouse pointer offset id converted 
to be relative to the slide/scroll bar ...

when you meke a click on the grad button the event offset retrived 
is related to the 0x0 and Maxgrabbutton_xxMaxgrabbutton_y so you 
need to make a convertion algorithm to make this event/offset value 
related to a position on the grabbutton/parent-face and in this process 
you lost some précision.

I give the closest solution to the perfect one but to say you the 
truth I'm not a VID guru I only try to adapt the calculation made 
by Carl into his scroller VID  widget. But has the construction of 
the REBGUI scoller/slider widgets are different from the slider/scroller 
VID ones that explain why there some knobing effect :).  But I think 
we have 90% of the method and for a VID guru solving the knobbing 
effect is jut a question of spending like 3 minutes on the problem 
;)

Ihave an other example of those related calculation method with the 
toc-panel in MDP-GUI and MDP-Viewer. When you click on an entry in 
the toc you have in the viewing pannel the title that appears in 
the middle of the viewing pane and not in the top of the viewing 
pane ...

why becaus the viewing area is not the same item than the content 
area has you have a interdependent relation this complicate the calculation 
method...

the effect I gey is title on is well well displayed and more we advance 
in the title more we have them showed on the bottom of the viewing 
pane... it's like a falling effect ;)

Some time ago I did precise scroller calculation. You have to include 
size of dragger into it etc.

I tryed a port for MDP-Viewer to RebGUI system and what I can say 
is that lot of thing are missing...

list of what are missing for porting MDP-Viewer to RebGU:

- capability to branch a custom feel block to the main widget (display 
block!)

- capability to add a pane: [] to a rebgui box widget

- scroller redrag ...

(but scroller redrag is not very important it's just an indice to 
the vision area representation in the whole real content)

Is the idea to completely replicate the functionality available in 
VID, to surpass it, or to provide a cut down gui ?

Most of this is [hopefully] answered here: http://www.dobeash.com/it/rebgui/


While VID provides a nice set of styles to work with, RebGUI aims 
to provide a rich set of [functionally complete] widgets to work 
with. The specification syntax of RebGUI is similar to that of VID 
as:

	1) They are both built on top of View
	2) The VID specification syntax is near optimal

 3) I wanted to be able to swap between View / VID and RebGUI coding 
 without *too* much of a mind-set change!;)

yep and we have to keep in mind that VID is about 5 years old and 
rebgui is about 2 month old ;)

As Shadwolf has done a super job to get the MDP-Browser (that's how 
I want to name it) done, based on Ashleys base, I want to playback 
the result to the community. And IMO we should take this project 
to stress-test RebGUI because it's quite complex.

I agree ;)

but this can be done with MDP-GUI if MDP-browser is a commercial 
dedicated product