World: r3wp

G4C TUT_MCListview

// ===========================================================
// A Multi Column (or Database) Listview..
// ===========================================================

WINDOW 126 90 367 373 "Listview"
	winattr style resize

xOnLoad
	// add some records to the listview & open..
	gosub #this AddRecords
	guiopen #this

xOnClose
	guiquit #this

// ===========================================================
// The listview
// - This is a normal MULTISELECT listview (the default).
// For this type to be triggered, you must double-click it.
// ===========================================================

XLISTVIEW 0 0 0 0 'The Title' "" var

	attr ID mylv
	attr resize 0022
	attr frame sunk

	// Give it a grid and allow the user to drag, drop & re-arrange
	// the lines - You can add more styles here..
	attr style grid/arrange/drag/drop/arrange

	// Add some columns. The first one we state with a '#'
	// in front to indicate we mean the 1st column.
	attr LVCOLUMN '#Item/width/120/TITLE/Description'

 attr LVCOLUMN 'Units/width/60/TITLE/Units/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Amount/width/60/TITLE/Amount/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Total/width/60/TITLE/Total/TYPE/number/JUSTIFY/RIGHT'

	// show the line double clicked..

 SetWinTitle #this 'SUM: $%Units x $%Amount = $($%Units * $%Amount)'


// ===========================================================
// This is a routine to add 100 records with various
// meaningless values to the above listview. Note how
// the fields can be used as normal variables.
// ===========================================================

xRoutine AddRecords
	local c

	use lv #this mylv

	// before we start, we HIDE the listview. This will
	// stop Gui4Cli from visually refreshing it every time
	// we add a record and will GREATLY increase the speed.
	// This will have no effect if the window is closed.
	// After we finish, we show it again..
	setevent #this mylv HIDE

	for c 0 100
		// add an empty record..
		lv add ''

		// Fill the fields with various values..
		%Item   = "This is Item $c"
		%Units  = $($c * 3)
		%Amount = $(($%Units / 2)*1000)
		%Total  = $($%Units * $%Amount)

	endfor

	// Show the listview again, refreshing the display..
	setevent #this mylv SHOW

// ===========================================================
// Right mouse button handling - Some menu choices..
// ===========================================================

xOnRMB


 QuickMenu -1 -1 'Select All/Remove selected/Add 100 records/#sepa/cancel'
	use lv #this mylv
	docase $$choice
		case = 0			// Select All
			lv select all
			break
		case = 1			// Remove selected
			lv delete selected
			break
		case = 2			// Add some records..
			gosub #this AddRecords
	endcase

this code sample show how multi column tables are treated using Gui4Cli 
;)

I think the menu code to popup menu must be retake in part to make 
the dropdown item alowing to put to it text + image icons :)

area style: Is it possible to add ctrl+cursor-left/right to jump 
over words? This would be nice and makes the area style mostly complete.

tabbing: How about a tabbing for "forms" and a tabbing WRT group-boxes. 
CTRL+TAB could jump out of the group box to the next field/group 
box and SHIFT+CTRL+TAB would jump backwards.

led: IMO it would be nice to have the same click-awareness as CHECK.

splitter: adding a richt-click to reset splitter to original position. 
If users have screwed up their layout ;-))

tab: IIRC someone state it already. A scroll-able tab-heading.

BTW: I'm just posting what I recognize while playing around with 
the TOUR. Great work so far!! Really looks very nice.

tab / group: Is the DATA part realy required as a structural element? 
What about this?

tab-panel [
	size 1000x300
	"Tab1" [...]
	"Tab2" [...]

The idea is to implicitly add a tab for each STRING! BLOCK! pair.
]

I never really like the implicit usage of FACE and other words in 
VID. Especially if not documented and those words are not very obvious 
to guess. I see that RebGUI uses the same approach:
	slider	[action [show-data p face/data]]

What about this?
	slider	[action [show-data p slider/data]]

This shows what kind of object we (implicitly) use.

slightly OT: With all those widgets now. Where is VID still "better" 
than RebGUI? Are we are missing anything?

Robert: VID isn't better imho.

:-) Ok, now I know what to use for my "new" projects.

Isolation/encapsulation of particular styles (widgets) functionality 
may mean simplyfying the situation, as we can see with RebGUI, althought 
it is not as feature (widget) complete as VID is ...

Rebol is so much free-form, that with something like VID, componentised 
(shared) feels, etc., you can get yourself into trouble and VID starts 
to look like a bit bloated, although it is really to say such thing 
about anything rebol related ...

What I am really pedant upon is proper system-like "behavior". I 
mean mainly keyboard .... I would like RebGUI having good tabbing 
functionality, even nested one (although now I don't know if other 
IDEs you program your apps in allow it, but imo yes) - imagine having 
table/grid on your screen, but also few fields and buttons. I want 
to shift focus to grid, and then I want arrow keys, insert, delete 
key to work in terms of grid, not whole form. Then there should be 
kind of "escape key", which will jump-off the grid and focus will 
be on whole form ...

Dunno if I am clear about what do I mean, but maybe ability of getting 
focus to group-box should be enough, it it provides focus isolation 
described above ....

Robert

 1) Widget observations: all noted. LED is the read-only functional 
 equivalent of 'check used for things like system status displays, 
 etc

 2) Tabbing (basic version) is slated for 0.1.8, more advanced features 
 will have to wait until the base widget set is complete.

 3) DATA is a required structural element to ensure widget specific 
 initialization is performed by init *not* the display function.

 4) Implicit face usage has two big advantages: a) allows you to cut 
 and paste code between widgets; b) different widgets can share the 
 same code.

 5) RebGUI still lacks a few of the more complex list / table / menu 
 / treeview type widgets.

 6) Re: new projects. RebGUI is still ALPHA and the basic design may 
 fluctuate as the requirements of more complex widgets becomes clearer. 
 I wouldn't be building any commercial applications based on it quite 
 yet (not until it goes beta at least).

Pekr

 1) Also remember that VID was created against a much earlier version 
 of View, and that it is only recently that View functionality has 
 stabilized. One example of this is the extensive use of 'draw by 
 RebGUI compared to VID.

 2) Tabbing, like key mapping, is less of a technical issue than a 
 convention issue; but my aim is to be able to "drive" all RebGUI 
 widgets both with and without a mouse (although the priority is to 
 get the mouse behavior right first).

Once widgets get more complex, will they share any code, or will 
there be strict encapsulation, so that each style is fully self-contained?

I see a funny behaviour with the check widget. Left-clicking, as 
fast as I can, is no problem. Right-clicking fails sometimes. It 
seems, a fast double-click isn't noticed.

Nice job though! :-)

Pekr: code will be shared where it makes sense, and it will be made 
obvious (i.e. no hidden or subtle dependencies).


Geomol: It's a windows specific problem (probably trying to access 
a context menu or something first). I noticed this a while back when 
mapping left / right mouse clicks to zoom in / out ... works fine 
on Linux though.

in all cases REBGUI is a good enhancement yet to VID :)

it includes yet more usefull widgets and less memory usage than VID

but it's a 1 month alive project Ashley and Vincent have done most 
of the work alone so if ppl will give a hand and help ashley concretly 
by apporting code things could advance faster

apporting code to any project is hard I understand this but a first 
step (what I try to do ) is to apport yet existing bunch of code 
that are fitted to REBGUI Ashley takes then the role of merger and 
last adapter. I hope this free some time for him  to focus on work 
of the engine.

So do we want to use the global event system so that we can have 
modal and auto-closing dialogs or does someone know another way to 
accomplish it?

you can't at the same time search for yet existent widget try to 
adapt them and in the same time try to work on the enhancement of 
the engine ;)

Ah, come on!  Haven't you ever heard of multi-tasking? ;~>

Ammon messaging (LNS) but that means LNS yet is disponnible and to 
redo profundly the main system of exchange

event ;)

Multitasking in rebol yes we have Francois Jouen  that done a multitask 
system in REBOL script

Multi-tasking...  Was making a about your comment that you can only 
do one thing at once.

I, for example, am working on porting my drop-down style and at the 
same time working on adding a refinement to Display to handle modal 
auto-closing dialogs...

in the LNS big picture it's says that LNS is the base systeme for 
VIEW 2.0 etc so why not associate carl to the discution and see what 
he plan for View 2.0

My point is can we go very far taking abstraction of the RT plans 
?

or do we prefer by this work to convince people

that rebgui is good and if RT think it can even improve it . That 
could be good for them to retake it and improve changing it more 
profundly then substituate it in the VM since retake the VID and 
then rework it completly...

Well, from my POV...  Carl intended to have us build dialects that 
are better than VID.  There have been several attempts so far but 
none of them have made it far enough to actually be ready for mainstream 
usage.  I think that if we can actually produce a solid dialect that 
outperforms VID in enough areas then Carl will want to add it to 
the language or maybe even replace VID with it.

so we need to improve rebgui to dialectise it but I am affraid this 
apport a slower renderer and a more  consumtion

I'am very badd in dialects so I can't be of any use all my dialectal 
creation approche was learn thru makedoc it's good but not enought 
to imagine and write a vid like application

Global Event System: looks like 'menu has to use it, and I don't 
know if we have a real alternative. One thing I've added to 0.1.8 
is a 'keep function that lets you specify what widgets you wish to 
use and sets to none everything not used by those widgets ... so 
if more complex widgets require global events then so be it.


Contributed code: I prefer simple code (that may need to be enhanced) 
over complex code (that may have to be pruned).


Multi-tasking: The RebGUI engine is 90% where it needs to be so I'm 
spending most of my time on widget integration at the moment.


View 2.0: We have to work with what we have, although I have made 
a concession to the future [AGG] with regards to RebGUI's use of 
draw in preference to image + effects.


Dialectise RebGUI: It would be relatively easy to make the specification 
more VID-like by having each attribute specified with a distinct 
datatype (and moving duplicate datatypes such as an 'offset pair 
to a keyword such as 'at) but you pay a big price in code complexity 
and efficiency; and I'm not convinced that inferred attributes ("this 
is a 3-part tuple so it must be a color, while this is a 4-part tuple 
so it must be a span") make code legibility and maintenance any easier.


None of this is to say I can't be convinced otherwise, this is why 
RebGUI is still ALPHA. ;)

Contributed code: sure but yet existing amazing thing wasn't thinked 
to be added to RebGUI so If we want a good time average and retake 
yet existing widget. I think it can be seen as an omage to those 
ppl that spent lot of time try to implement this widgets. If we find 
a way to include them it's like we have a parternity and a real look 
over what exists in the rebol free community that"s a king of concretisation 
and that allow us to improve faster I don't think pruning ctx-menu 
is slower that redone the work from scratch ;). And As I say earlier 
that shows our consern and attention to what exists in rebol free 
community ;). Like "Thank you man you give us this widget now look 
what we can do with how it grow and how it became self dependent. 
If your still want to apport to it or have some ideas on it to share 
with us your very welcome" :)

Personally, I think it would be very cool to have a non-RT GUI dialect 
that was better than VID, but just as flexible.  I wrote VID in very 
short period of time, and it was disigned for more than what it is 
typically used for.  For example, VID is written in such a way that 
it makes it easy to write something like the Layout script -- because 
you can return to the original VID source code from the face itself.

In other words, VID is bi-directional.  Dialect -> Faces -> Dialect.

Most programs do not require that, so various fields of VID are not 
necessary.

Nice to see you here carl  ;)

Good to be here. Had a few minutes extra, since there is a huge storm 
going on in this part of Florida, and everything is runing behind 
schedule.

If I had a lot more time, I would be doing a lot more work on VID, 
because the few missing styles are really annoying. So are the few 
areas like moded-dialogs that need more work..... as does the default 
text editing code.