World: r3wp

GIDI: "Graphical interactive dialect interface"

not great

We could as well call it GDI, it is already known in MS world :-)

I suggested GINA, but don't remember what it stands for :-)

DVI .... dialected visual interface

DVI is already hw inteface, isn't it?

that's called overloading :)

:-)

There is SilverLight, MoonLight, Flash, we planned FireSide, SideLight, 
or something like that - but that is more for a product name, than 
to call some subsystem ...

RebolLight

Doesn't it sound like kind of product? Express, Light, Demo?

yeah

But why not, would be fun - I am proud of REBOL :-)

REBOLight

Thermite ?

flash in a pan :)

isn't thermite explosive? :-)

yes, it creates flashes

so, we have a product that is capable of creating flash like graphics 
and better.

Or we can call it similar to Flash - Fresh, or reFresh

nah ... want something different and better

If GIDI is revolutionary, we want the ParadigmShift :-)

The tough thing to appreciate is that VID is a general-purpose entry/mid-level 
dialect.  R2/VID has been in the wild for 6yrs(?) now and we have 
certainly gone through periods of isolating key weaknesses, but we 
all have a tendency to have had starry-eyed visions for what VID 
should be.  The practical gets mixed in with the possibility when 
it's time for action.


I think the community would be better served with a strong VID alternative 
(not as a slight to RebGUI which does very well acheiving its stated 
aims) not bound by Carl's constraints for the entry level language, 
and open (as in open) source with very clear aims.  It has to be 
independent and perhaps needs to span R2 and R3, at least initially. 
 We have the capabilities, resources and talent to do it, but instead 
try to hammer these ideas into VID.


This isn't intended to be a rallying cry -- it's just my assessment 
based on observation and involvement.  Such an undertaking would 
have inevitable difficulty overcoming the differing visions of interested 
parties.  Conversely, it's within us to create an enduring, enviable 
framework...

Graham, you have an interesting way of working

However, many discussions about development methodologies are comparing 
apples to oranges

The iterative way of developing with lots of feedback, nowadays described 
in Extreme and Agile Programming, is very suitable for user applications 
and solves a lot of problems there

However, it's not suitable for systems programming, where you don't 
mold your design around user requirements, but around the requirements 
of hardware and underlying system software layers

REBOL is clearly systems software, a middleware layer that aims to 
bridge between lower level systems and frameworks for basing user 
applications on

Its design requires much more knowledge and experience of the system 
than most people, even REBOL programmers have, contrary to user applications, 
where the user is by definition the top expert

well the mear problemfor comunication is the monolitic way to think 
.... 1 guy working = stability of the way to work but fluctuant communication. 
And teh problem  can be there is not much to communicate about too 
. several guys working = code harder to stabilise but more easy to 
communicate each time you have a new thing done or a new idea popping

that remembers me how we started rebGUI with rebol community ashley 
and me. First ashley and me  were working on MakeDoc and MakeDoc 
Pro dialect to VID renderer we emulate each other alot and from this 
exange born the constatation that common VID face set was not adapated 
to usual GUI  or big amount of face handling. And from that constatation 
Ashley proposed to make rebGUI  wich we presented as a major enhancement 
to VID layer keeping the main idea alive "KEEP IT SIMPLE". Ashley 
proposed the community to share idea or suggestion and on every single 
widget the community proposed we got a discution and code proposition 
to achieve this goal.

sure the most of the work was lets say the assembly and diffusion 
part of rebgui was still done by 1 guy Ashley wich have the main 
vision of the project and was our guarant to get end edged library 
usable by any one but many were the  contributors and that leads 
to a really dynamic work i remember on the very beggining of the 
project a new version of rebgui was available every 2 weeks.

hum crhis the main problem is the interface betwin the common REBOL/VID 
and the side way external VID like dialect (but not using VID) developed 
by the community and promoted by the communnity. All the rebol communication 
is to say  you download only rebol VM  and you are done read for 
work.

REbGUI is working on top of VID not remplacing it and remplacing 
VID is yet another step of difficulties. As I said befor the only 
way to remplace VID would be to make a DLL and then a bridge to make 
the "user code" able to use it and that means a more complexe way 
to share your sofware

but that rebirth the ask i done about the "external modules" handling 
if we see rebol as a full opened virtual machine with an easy way 
to handle module then network, vid data etc are just modules and 
anyone can take them work on them enhance them or correct them share 
is news and rebol recentralise the works to make an official  release

this way rebol is hum thought more a module manager and a mean idea 
of was software programming is than a monolitic virtual machine wich 
I call the BIG black box able to do anything but with a big mistery 
regarding how the thing are internally done.

and maybe that would be more fun .... but most of the time we will 
be then discussion about C/C++ code than rebol code ... and maybe 
that's not the topic of our community

when I see the actual enthousiasm form google desktop applet and 
opera widgets developpement I really think rebol have his spot all 
ready in computing industry

if we look closer to this page  http://dev.opera.com/articles/view/creating-your-first-opera-widget/
 that clear VID dialect is really more powerfull

but on the redering result we can say VID2  compare tu opera widget 
is ugly and that not reflecting all the power of VID2  and that's 
truely pissing me

and yes i want to be able to use VID2 power to do sharp and beautyfull 
interface with rounded border window and this means being able to 
deal with tranparent windows background

there is 2 ways to see a window and it's content the first 1 is the 
all made container the window is a set of default widget a tittle 
a status bar etc.... or you see it as a transparent rectangular area 
where you put other common widget . Maybe the true power of VID2 
 and by extention the true power of the rebol dialecting would be 
to think the window as a transparent rectangular area and then have 
2 kind of super widget able to get user input and deal with event 
able  to render draw AGG instruction and this widget will be the 
base for a design of all the widget

and VID should be able to use all common interface like systray or 
always on top

What is all the power of REBOL good for, if the whole project is 
pretty much missmanaged?

well rebol power is to not have to manage the project ^^

I have done alone in less than a day serveral things that in other 
language would have took me weeks  with several other guys

I am speaking about R3, not REBOL projects ...

yeah .... Pekr you are right .... and that's not a new issue I remember 
it took like 1 year to get rebol 1.3  VM  but  if we look closely 
rebol is not only built for windows and that's pretty complexifying 
the rebol developement process ...  since all REBOL VMs have to produce 
the same on all platerform from 1 single code you have to lower the 
specifications and possibility  the ground ones wich will feet to 
some less designed OS .....

for google desktop and opera widget that's clear they limited their 
OS to windows  MOSX  and linux those 3  OS having the same kind of 
inferfaces

they are different but what can get in result is close