AltME groups: search

As far as the wish for a View/VID native solution goes, I wish that 
as well. Maybe it will be possible when the JIT compiler becomes 
reality to easily adapt Rebol's VID. 

It does not have to be complete like VID, a basic set of widgets 
will get you a long way.  

Other solutions are a really good thing too, but looking at GTK and 
myself I find it hard to find out how to get GTK on my mac. It is 
not a standard dmg file I can download and install and it works. 
Other GUI solutions require integration of their package or having 
the end user of your programs to find out how to get it running on 
their machine. That kind of thing can be a real showstopper to global 
acceptance.


I know Doc is working hard and has already stated he intends to come 
up with a VID like native solution. So we can let him focus and be 
silent ,or we can comment and discuss letting him know we do care.

it is a internal field to store text in VID widgets (its about word 
wrap I think)

But other engines you name are far from what View engine in fact 
is - system of gobs, etc. Widgets are VID. I still prefer not so 
much perfect VID, instead of overbloated stuff ...

There are plenty of possibilities here. 

Either port VID and have to deal with it's flaws and the history 
with it
or go the path of the RebGUI
or redo VID 

I have read somewhere that Carl expected someone to come up with 
something better than VID. 

I like VID yet it has its oddities, like when positioning elements 
using 'at. It could be improved in some of its behaviours, if you 
import it you may be hindered by this aspect, and it may get harder 
than restarting with a restricted base set of widgets.

RebGUI (alpha) and draft documentation available at http://www.dobeash.com/it/rebgui/


Only a few basic widgets defined at this stage, so don't try and 
convert your VID layouts across just yet! ;)


Being an alpha, the design is still settling down so feel free to 
question anything that seems wrong. If there's sufficient traffic, 
feel free to start a RebGUI group.

our point with ashley is to gatherring the VID widgets de effort 
into a single process

Since the very beginning of VID we have seen lot intent of widgets 
improvements make by pationnated people but we never take the time 
to enclose those work into a trully thinked system that's why we 
don't have a reable and durable widget design effort and RebGUI  
tryes to fit this need

Pekr layout is a dialectal parser so he treat the key work (consoming 
CPU and if you have a lot of widget to renderise like into a MD view 
area or a list it's a nightmare...) and the used widgets are the 
VID default ones with lot of unneeded thing ...

Gabriele, thanks for clarification. You are not the only developer, 
who thinks so.IIRC during older 1.3 initiative, Romano expressed 
just the same. It is probably a little bit difficult to introduce 
some conceptual changes for current VID incarnation. But that should 
be stated oficially. There are several of you - gurus, who could 
outline in few paragraphs, what way should VID2 (or VID+) go. One 
of my friends suggested me looking into (was it?) Gnome UI guidelines, 
as an example of how complete definition of widgets, behavior, etc. 
of such framework should look like ...

Sorry, Robert. There is something I want to announce. :-)


http://hmkdesign.dk/list-test.png<--- a picture of the list view 
I'm building.


Currently about half done and quite usable at this time: It's resizable. 
Values are stored as blocks of blocks. All columns can be sorted. 
Input columns can be filtered so you can show only some columns. 
Columns can be freely reordered (but not in the GUI yet). One arbitrary 
column can be resized.

It has the normal range of series manipulation functions available 
in REBOL. There is also possibility for inline editing, by doubleclicking 
a line. Changed values are automatically stored in the list. All 
such operations are "bundled" in the list view VID code and you only 
need to provide whatever functions needed to store the list data 
in an external place. If a text entry is too wide, it'll be neatly 
cut with ellipsis (...).

Filtering function, to filter input by rows. Also has a scroll-to-selected-line 
function.

It's about as fast as the current LIST in VID, since it really is 
LIST with just a whole bunch of extra functions to make general list 
views easy. There are functions possible for clicking and double 
clicking and functions for retrieving rows and columns.


Current limitations: No mouse over indication (can't make it fast 
enough). Only one resizable column. No keyboard navigation. No horizontal 
scrolling. No scroll-wheel support. It doesn't integrate 100% with 
VID yet. I'm using some of my own widgets and bitmap graphics from 
a pretty big GUI library. Stripe look, font and coloring is locked. 
No standard settings yet for the list view.

All code is about 250 lines.


Planning: Reordering columns via drag'n'drop. Column resizing, if 
I can figure it out. Format the font object conditionally from list 
input (make this line bold if the age column is > 45 years, etc.). 
Grid drawing. Images in list rows. And if I can get around to it: 
Single cell in-line editing ala spreadsheets. :-)

Give me one thing - decent keyboard support, add tree-view, better 
grid to Rebgui, redesign widgets to visually support in-focus state, 
and you are done! Then go and look at your "app" source - very nice 
dialect - you will NOT find anything like that anywhere. Very nice 
and readable code. The problem is, VID stopped 80% on its way to 
success - the rest, those missing 20% ruined it.

I want to be sure, new VID (Whatever it is called) will be fully 
keyboard ready, that widgets can be disabled/enabled, focused/unfocused 
and that all this is visually reflected ...

VID and RebGUI widgets don't have a 'loading now ..." state.  Perhaps 
they should

Hope VID+ has a way to dynamically disable/ghost out widgets ....

It's been many years since I've used an IDE, but I recall selecting 
widgets and placing them on a screen, setting the Z order, and various 
properties for certain events.  Isn't VID just a RAD tool for doing 
this in a dialect ...

Rebgui is an alternative to vid ... it has more widgets but is less 
flexibles

Cool, is Ashley re-working rebGUI for VID 3 or will it be redundant. 
I've never bean totally happy with a third party widgets (like Python 
+ vxWidgets) or Java + Mattisse etc

Normand thank you for your concern about MDP-GUI. AS MDP-GUI main 
author I can say that the one vindow rendering is one of my futur 
goals. By default Area are absolutly unable to handle ritch text 
..  Carl Sassenrath plans to add a new VID widget to do so called 
TDM... (But The double formating maybe very slow). MDP redering format 
pull us to have en extensive use of VID widgets capabilities I'm 
not sure even with TMD we could reach the same level of beauty. I'm 
making some research too on my side to  found a pretty way to transform 
redered widget to editable ones keeping there settings... But so 
far I wasn't able to produce a relevent soution in this issue :)

(don't forget that in vid you could do semi transparent widgets relatively 
easyly wich is not the case in glut  for example...)

Ashley that depends on the level of knowledge the interlocutor has 
in computing if it's a totally newbie I would take easy  images (button, 
lable, fields, images etc..) If he is more skilled i would use Widgets 
beacause widgets can have différents styles styles the common VID 
denomination is related in fact on customized face so the equivalent 
in vid for widgets is faces

but if we clone the VID widgets naming how to diferenciate the both 
engines ?

and i hope rebGUI will integrate new widgets that doesn't exist in 
common VID engine so

1) Terminology: I'm starting to gravitate towards Window, Face, Attribute, 
Widget and Feel.

2) Widgets: will have simple VID-like names; e.g. button, icon, image, 
bar, progress, etc ... I'm compiling a list of the required base 
widgets and will publish here for discussion when done

3) Facets document: updated 'restore, 'activate and 'edge/image descriptions

4) Vincent's 'progress widget ... exactly what I was after; added 
it to next build

Did I miss anything? ;)

Styles (and Stylize) are also a user-friendly way to get massive 
code-reuse, as well as being the widgets... maybe widget-styles (I 
have seen people say VID-styles before) or something like that could 
describe subsets of styles in use...VID is a package of styles...(just 
some outloud thoughts)

RebGUI uses the standard View face (25 facets) and 'data is not used 
by REBOL/View. VID extends this face by an additional 22 facets:

	state
	style
	alt-action
	facets
	related
	words
	colors
	texts
	images
	file
	var
	keycode
	reset
	styles
	init
	multi
	blinker
	pane-size
	dirty?
	help
	user-data
	flags


and provides 'user-data as it uses the 'data facet itself. RebGUI 
widgets use 'data as the "interface" attribute (e.g. setting a progress 
bar's value) and may define additional facets for internal use on 
a widget by widget basis. The idea is to make best use of the 25 
available View facets and not have every widget using 47 facets regardless 
of whether it needs to or not! ;)

Pekr and every one have to understand that starting a sutch project 
from scratch (white page) is a true challenge.In french scene we 
have an example of a heavy skinnable widgets library that became 
deprecated because several reason in witch there is no one to take 
in charge the continuity of the lib and that's pretty difficult to 
make a relevent work while we don't know what could be the VID futures. 
This library is interdependent of VID so while we don't know how 
Carl plan to extend it in futur it's hard to make up plans to maintain 
it.  The name of this lib is libskins v3 witch was made by Etienne 
Alaurent.. What I want for RebGUI  is that every one can participate 
on it apporting  he's hown ideas to it but conserving the main project 
lines. I think Ashley is totally in this mood and try yet to make 
documentation around RebGUI concepts. In futur one posible idea to 
simplify the documentation elaboration could be to use the rebol 
french scene douwiki.Every people that creates a modification significant 
to RebGUI would write the related documentation directly to the dokuwiki 
this way the documentation task that had to make Ashley would be 
lighter. Ithink as Ashley have the "code vision" he must take in 
charge the code merging and releasing (that's yet what he do actually 
;) ). If we want RebGUI to be maintained and constently adapted we 
must  work as a team. This allow us to have more knowlege and more 
inovent ideas in the topic ;)

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

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

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

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

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

Well  In fact I figured out there was lot of problems with my first 
 port of the arrow and arw widgets made by Chris & Gregg  initialy 
for VID/AGG. So now it's mutch better I solve all existing problems 
in my first implementation.  I made lot  of code cleaning. I let 
implementation samples in commentary and comments maide by initial 
authors ;). Can be found here: http://shadwolf.Free.fr/arrow-RebGUI-port.r

Robert: LED-Group attributes can be changed at runtime with:

	led-handler/pane/2/data: true
	led-handler/pane/2/text: "Test"
	show led-handler


but the specification (number of LEDs and orientation) is fixed at 
specification time. I have no plans to change this.


Pekr: Most folks are familiar with WinXP, it is something to model. 
The basic RebGUI color scheme is controlled by less than a dozen 
words, and arrow / chevron / other is fully inheritable; but the 
"look" (e.g. tab shape and active shading) is hard-coded in most 
cases. So the answer is that you can easily change the cosmetic aspects 
of the UI but not the fundamentals.

Gregg: known issue.


Volker: Not sure which way you mean. If you want to contribute new 
widgets that work with both VID and RebGUI then I'll be spending 
time optimizing them for RebGUI which will break their VID compatibility. 
If you mean that you want to make the RebGUI widgets work under VID 
then feel free to do so with the widgets I have authored. For other 
widgets, please contact their author(s).

IMO this complicates the RebGUI widgets unecessarly. It would be 
nice to have a wrapper for RebGUI widgets that make them VID compatible. 
But than only as a oneway. RebGUI -> VID not the other way.

Nice, I understand what you want to do now ... create a GAL (GUI 
Abstraction Layer) that enables RebGUI widgets to be used in VID 
with zero RebGUI changes. Interesting to see whether you can get 
it working the other way (VID -> RebGUI) as painlessly! ;)

sorry, correction (some VID widgets need a block as parent face) 
:

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 
;)

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!;)

Another issue:  Excuse me if this has come up before..  

The archetypal View face has some of its facets set to none, which 
makes using VID styles alongside RebGUI more difficult (because the 
VID-based styles are not expecting those facets to be changed.)

Suggestion: create widgets/rebgui-face and encourage widget creators 
to make from that.

... simplest widget ever ...
 How much is there to write about?

	widgets: make widgets [my-widget: make face []]

Or am I missing something? ;)


Your VID edit styles sound interesting, but I'm looking for a more 
universal solution to "field input masks" and "field input validation". 
Something that would let me define a telephone number mask for example.

should have the option for area widgets though as in VID.

graham needs a good relevant stable and easy to set tooltip system. 
Some time later i proposed a style tooltip hudgly over ridding the 
common VID styles adding a way to set tootips on normal VID widgets

stick for new styles. if i could use widgets in vid, i would do my 
styles with rebguii. (also need a bsmall version, a few 10 kb then. 
i guess without dictionary would be enough).

And more. In VID you can quite easily add a face to another face's 
pane, whereas in RebGUI you sometimes want to add (or replace) a 
particular widget in a display with another (there is little need 
in RebGUI to add faces to a pane as these low-level details are taken 
care of by the widgets themselves).

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

Having converted (or at least used as a starting base) a number of 
VID styles to RebGUI widgets I've observed that the final code is 
40%-60% smaller (YMMV) and easier to understand in that most of the 
logic resides in the widget itself (i.e. it is self-contained). But, 
once the code to be converted reaches a certain size where I can 
no longer 'grok' it in a single reading (about a hundred lines for 
me) I find it easier to code from scratch. ;)


I'd also break it into two separate widgets: grid and list-view, 
and look at the minimum function set each requires (KISS).


Simplest way to start is to read all the doco under 'RebGUI Documentation' 
at http://www.dobeash.com/RebGUI/then look at the source code of 
a few widgets (start with something simple like %button.r then move 
onto %table.r which shares a lot in common with list-view).


If you run into any brick walls (or find yourself asking, "why oh 
why did they do it that way?") just drop a note here. ;)

If you have a large left box, how do you then align the following 
widgets so that 'return aligns to the left large widget?
In VID you set a ruler thingy ...

How hard would it be to write a LAYOUT function that will transform 
the RebGUI layout into a HTML page?

 Dynamic or static conversion? I think it's possible to map most VID/RebGUI 
 styles/widgets to CSS and HTML with Javascript required for a few 
 of the more complex widgets; so reproducing simple layout forms online 
 is trivial, more complex apps with tab-panels, etc a whole lot harder.


This reminds me of some of the R&D work I was doing with IBM back 
in the early 90's. Layouts were IODEFs (Input/Output definitions) 
where you hooked a data source (e.g. DB, Terminal, Webpage) to an 
output target (e.g. Screen, printer, Webpage) with zero application/logic 
changes. The entire app was stored in a code repository across a 
couple of simpe DB2 tables. Anyway, I digress.

It's a problem as tabbable and focus usually go hand-in-hand. Button 
had the same issue, and required quite a bit of hacking to get it 
working. Other non-focusable widgets have the same issue (e.g. check 
and radio-group). Keyboard navigation has been an issue for RebGUI 
(and VID) for quite some time ... just ask Pekr ;)

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

Pekr, using rebface instead of rebview will make a big difference 
as rebface excludes VID and all help text is stripped out. On OS/X 
I get the following:

REBFACE
>> stats

== 2085621
>> recycle
>> stats
== 1911437

REBVIEW
>> stats
== 6260880
>> recycle
>> stats

== 4810174


You can also create a custom RebGUI build that excludes widgets you 
don't intend using (see http://trac.geekisp.com/rebgui/browser/create-distribution.r
) which will save a few more bytes. Lastly, make sure your app does 
not use any unneeded images (e.g. a background image when a simple 
draw effect might suffice).


Even with these measures you'll only be left with about 3MB free 
... but 3MB is better than 1MB.

Out of interest, the memory figures on OS/X using rebface are:

	rebface	1.8Mb
	VID		3.2Mb after loading %view.r
	RebGUI	3.5Mb after loading %rebgui.r


but these are for the respective defaults (VID apps often require 
additional patches/fixes and styles, RebGUI apps rarely use *all* 
the default widgets). I should also add that RebGUI (or indeed VID) 
have ever been fully profiled and optimized.

it was designed to be a rebgui widget  that was the prototype for 
table widget long time ago and a play for me on an amazing and very 
VID Topic " widget auto compositing subwidgets" widgetwriting widgets 
that's so neat  ^^

RebGUI was created only because VID wasn't up to the task. damn right 
ashley but nothing guaranty us the VID next set of widget will be 
hum more reliable (to not say more usefull ...) but still VID remain 
 a powerfull things so with our without cool widget set from base 
since VID stay a powerfull base and draw still remains too it's still 
possible to make a set of widgets more hum .. more to feet our taste 
and needs ?

R3 is not for tomorow ( or maybe Carl done some crazy amount of work 
in the night and gets all ready for tomorow morning ???) so rebGUI 
still has a couple of years to go on ^^ and as a matter of fact i 
prefer i good VID /DRAW  system with no widget than lot of widgets 
with a not extendable dialect what makes all the interrest of VID 
is therefor the high flexibility of it and it's relative simplisicity 
and that aspect have to remain and even been enhanced

however main goal of rebGUI was to provide a cool widget enhancement 
library for VID propose a "example" set of widget people want to 
use the most in their software ( well that list of widgets can be 
found in any advanced graphical library such as GTK+ winap32 aqua 
QT WxWindows Tcl/tk etc...)

I do understand your point of view, which is - you try to keep Rebgui 
to its original idea. But - VID styleset is not real alternative 
to R2 GUI navadays, so refusing more complex widgets, especially 
in the case where noone really pushes anyone to use them, is escaping 
my understanding.

hence no further ability to mix VID with RebGUI
 ... correct.
promise of 

much lower" memory requirements, but the opposite is true" ... not 
quite. A lot has been added, in particular 4 inline images, without 
noticeably increasing memory. Also remember that many of the improvements 
(reduced dependency on View/VID mezz code) will only be apparent 
when using RebGUI with enface/rebface (tour.r uses 13,817Kb under 
rebview here, and 11,223Kb under rebface). Lastly, reduced memory 
usage is not apparent with tour.r as it doesn't reuse a lot of the 
same widgets (i.e. tour.r is a good reflection of "base" memory usage 
not runtime memory usage). If I find the time I'll knock up an example 
that demonstrate runtime memory differences.

In VID you specify the feel directly, in RebGUI you let the widget 
worry about these low-level implementation details. None of the default 
widgets need to pass mouse offsets back to the application, so if 
you need to do this then creating a new widget is the way to go. 
Having said that, I could always add another action handler (on-anything 
face action event) which would fire instead of the above case statement 
(i.e. handle the event as in VID or let RebGUI delegate it to the 
appropriate handler).

ok but with new vid  in R3  what will be the future of rebgui ? ashley 
do you plan to keep rebgui as an enhancement and laboratory ground 
for new kind of widgets design in the new VID ? Or does the new VID 
will kill  rebgui ? What will be the link betwin R3/VID and rebgui 
do you think some of the fun widgets from rebgui will be adapted 
by default in R3/VID ?


If you remmeber i asked this like 1 year ago to carl and didn't get 
any reply...

dunno - but AJAX is imo just proving the idea of rich apps we do 
have with Rebol. If not, they would be satisfied with browsers and 
few widgets as is :-)) So AJAX is just kind of rebol aproach inside 
browser. Let's make proper plugins, improve VID and bye bye AJAX 
:-)

What had Carl in mind? We have just slides of his presentation, some 
mention of Confabulator, thousands of widgets, VID redone, top window 
transparency etc. Anything concrete?

I also miss answer to the question about VID - well, maybe I did 
not ask it - what is the plan with VID? :-) Konfabulator kind of 
widgets was mentioned, but nothing concrete ...

Hmmm, I don't see anything that exactly nails this topic.  Clearly 
this about UI, VID, widgets, ease of developement.   Perhaps...

You can .. but it's hardly ideal with the poor state of Vid widgets

I go along with your comment about the state of VID widgets.

For me, it isn't about the current state of VID widgets that are 
built-in--though a better UI toolkit for more advanced apps would 
be *very* welcome--it's about how easy it is to do other things, 
and do them all in one (very nice) language. I also tihnk we're still 
just scratching the surface of REBOL, in part because it's hard to 
build things to share, and not as easy to build larger systems. When 
our mindset is in small apps, there's much less benefit in building 
big frameworks, and even reusable components to some extent. i.e. 
it's often easier, today, to write things ad-hoc, rather than building 
up a library and environment for larger scale development.

but that is not the point. I just first could not follow, how they 
work with widgets, and then I found out - they have separated code 
and widget definitions. At first it looks strange .... it is like 
having 'feel(s) , event maintanance, app logic, without seeing what 
actually you are working with. But I do understand, why they keep 
widget defs outside in external file, which is kind of simple (as 
VID is), with static positioning - it is very easy to import to visual 
GUI builder ....

About the new VID widgets look&feel, Carl stated at the DevCon that 
he would like to have something between Windows and OSX widgets look. 
So, I think that we could submit our own graphic design propositions 
to RT. A big image with a static example of each class of widgets 
would be enough I guess, "live demo" would be even greater. For the 
VID engine design, I'm trusting Gabriele's skills and his ability 
to gather the best ideas and feedbacks from the community. Anyway, 
if you don't like the upcoming new VID, nothing is stopping you to 
make your own one ;-).

for now it seems that VID is just a bucket to randomly throw widgets 
in at your own whim. this should of course not go away, but higher 
level structures would be nice to have. there could be Dialog, Two-pane, 
Three-pane, Preferences (which provides a list in the left side and 
switchable pane in the right side).

why? it's simply adding a layer above VID to guide how to handle 
certain dialogs and multiple groups of widgets. it doesn't have to 
be more than a few kb's of code in total.

.... and ... not sure it is possible or if it would be vital, but 
Chris requested future VID being CSS like, simply put that widgets 
would be separate from styling. But not sure it is possible. The 
trouble is, that once layout is decomposed into view objects, there 
is no way back. There is nothing like DOM ....

Use CSS 2.1 styles on widgets. Create widgets ("classes") in VID-the-sequel 
and render them to Rebol or XHTML + Javascript. That way you can 
mobilize the entire web community to get a UI that renders both to 
a RIA and to the web.

I saw vID 3 use filler to organize the widgets

a stronger link betwin "networking" and "visual" modules ??? hum 
that's like if Carl was preteneding we can't already do that !!?? 
What VID (or what ever called (turtle, springler, widlets reblets, 
reboing, rebelistic-view-system,widbol)  needs is a better Interface 
Human machin a better set of functionnalities  to reflect the most 
of the visual capabilities of now in days computers and a better 
set of widgets.... (call it cosmetic (code and rendering) and performancies 
to be short )

wellwhat amazed me is the community message was (as far my poor idiot 
brain understood it ) "We need VID  with more widgets closer in the 
look and capabilities of what can be done with other widgets libraries, 
better performancies and a bette way to handle user/machine interface 
. And Carl reply by okay VID2  is a trash lets change all .... I'm 
not sure the reply feets with the ask. But maybe our   ask was too 
much short ended vision and Carlplans on a bigger plan but that can 
only telled by him

Most people were not able to build new widgets for VID.

well with vID2 we done a MDP Makedoc  renderer so doing HTML  one 
is not so hard with actual VID but the fact is MD GUI  and MDP GUI 
 gots a big lack of widgets for the none document rendering part 
wich I will call the IHM (menu bars, tab-panels, ability to resize 
easyly the whole content  or part of it   and that what lead us to 
do rebGUI ... to enhance that aspect.)

VID was already simple  in comparasion to what are the other libraries 
I don't know if you ever tryed to deal with transparencies with raw 
X llibrary that pain in the head number 1  ^^.   Well i'm not against 
simplifying the system but first how does the industry shape their 
GUI 99.9 percent of the time the GUI  is build using a GUI designer 
and the only thing you have to do is set thru the GUI designer interface 
the settings for the widgets you graphically picked and organised 
then you have to write the call back code... Then to take your example 
back with the hyperlink people then don't code they only format text 
en even then most of now in days forum like PHP BB  use javascripted/pugined 
rich text area  to format their  text you push a button it insert 
the text the way you want. and some of them on the php engine level 
are able to recognize http:// footage to build on the fly the hyperlink 
without requiering any tag adding by the user .... I'm not sure separating 
the way you organise the widget to the way you configure them will 
lead us to more easy way

I make most of my decisions from how physical buttons, knobs and 
materials appear, how light affects them and try to approximate that. 
I don't have a plan for the finished look as I prefer to make things 
up as I go along and look at the whole thing when it's done to see 
if some parts don't fit together. Then I change the remaining parts 
until they fit together. But the point is not to approach it as a 
physical device as a whole, like this:


http://www.synthtopia.com/content/wp-content/uploads/2008/02/nusofting-drum-machine.jpg


It's only to help discern between different types of widgets in an 
interesting and recognizable way. Since the beginning of MacOSX, 
I've looked at their UI and wondered what materials it would take 
to build their user interfaces, if it could be physical. There seems 
to have been careful thought about physical appearance or they actually 
built a real physical model of the user interface as a starting point. 
I think that's one part of what makes it interesting and attractive 
to look at.


Before OSX, UIs were largely either like the drum machine or they 
were mostly cartoony symbolic abstracts of real life elements, like 
AmigaOS, Windows or early MacOS. The original VID fits under that 
category too.


With the VID3.4 skin, I wouldn't mind if a button reminds you of 
the button on the photocopier or on the dashboard of your car in 
a realistic way, without being impractical.

If we are concentrating on VID, perhaps we need to locate the most 
common widgets and see if there any dificulties in creating them 
... like Pekr's split windows

an help to create widgets in vid ?

i have a stylesheet where i created my personnal widgets in vid

I think that VID is nice. Dialected aproach is the way to go, that 
is for sure. I would be OK, if VID would fix some things as - tabbing, 
cursor change, accelerator keys, visual focus representation to widgets, 
disabling/enabling (for business wide widgets), resizing, methods 
for drag & drop etc. Look e.g. at VID's feel - it was abstracted, 
that you have central storage of "feels", but was that abstraction 
used to any good by anyone? I like self-contained styles/widgets 
of rebgui better.

let imagine you do a button you want to draw something on the background 
with AGG and then have the regular button borders and fonts to be 
applyed over  using AGG it's possible to have that effect  with the 
context phylosophy the VID button is a separated entity from the 
agg entity  you have the QT context the QT widgets display in it 
and the AGG widget is one of the few widgets you have but you can't 
mixe content ...

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

Pekr no i never coplained cause i didn't got some half made work 
in progress to test ... I just complain to get the direction to know 
what would be the futur and to know the agenda ... that's all !!! 
 I don't caore of host kit i don't care of the widgets anyway if 
it doesn't fit my taste I'm grown anough  to do my own widgets anytime 
like i did with R2 /VID

I would probably agree, if I didn't have other experience with the 
VID Extension Kit. The trick is to make the focusing mechanism flexible 
enough to handle all situations. We are not building a GUI that handles 
specialized situations. We are building a GUI for large business 
applications with dozens of windows, hundreds of widgets and tons 
of forms. We absolutely do not want to have something like focusing 
being a special case per style as other than a special option.

I know I'm a freak  and that most of my asks / comments are shaking 
you in fear but is there any rebol3  dicussion group   in  google 
WAVE ? 



How could such a tool help us  to get a better link with carl or 
maybe on some specific point  get a better help fro the community.


For example i don't feel able to make a whole R3/Vid alone but i 
feel like to contribute apporting ot R3/VID what i do best some widgets 
 and as i'm not alone able of it maybe a goo emulation can be created.

Impresive Kaj can you do us a set of widgets in SDL or just the smallest 
possible VID and the widgets will be designed later