World: r3wp

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

I think the rebol developing process would first be enhanced if once 
for all we say we are in 21 st century therefore we focus on OS of 
this century  ^^

then we say rebol and it's main dialects should be able to use 100 
% of functionalities of those OS

and third we say ok we can put all in rebol therefor we design or 
think a way to easy extend it keeping for the extentions the rebol 
coding way

and third we say ok we can not  put all in rebol therefor we design 
or think a way to easy extend it keeping for the extentions the rebol 
coding way

Shadwolf:


- development has to be vital. There is IMO noone contracted right 
now. Gabriele, Cyphre, simply noone. Cyphre has not fixed deep View 
bugs for some 4 months or something like that

- there is nothing complicated about cross-platform nature of R3, 
as right now, kernel is imo not under development

- according to available info, VID should be the focus now. And maybe 
it is the focus. But it is not communicated. I hate those periods 
and they do happen once in something like 2 years, last one was probably 
during the rebservices period, which were not finished btw anyway. 
So - the blogging about Vista being broken or California fires is 
good, but look at frequency of R3 blogs. If it will not change, I 
recommend to remove personal blog from REBOL.NET, as it gives overal 
impression of RT breeding wine, instead of coding. Not that I have 
anything against personal life or wine :-), but can you imagine some 
system integrator, potential investor or tech.company willing to 
use R3 in their cell phone would look at REBOL.NET blogs? It seems 
to scream for - "... but where's the development happening"? And 
once again - all is about communication imo. If VID3 is in some stage, 
one blog per week would not hurt - whatever - principle explanation, 
simple glimpse of code, a screenshot, whatever ....

there used to be a running joke in my workplace that whatever startup 
company i got excited about was doomed to failure.  Be Inc. with 
BeOS (focus shift), Constellation 3D with their Flourescent Multilayer 
Disks (FMD) (factory bombed in start of Palestinian intifada), and 
now Rebol?


Each of the technologies was/is paradigm shifting in their field 
but through mismanagement, mishaps and miscommunication something 
along the way seems to get lost and the excitement they originally 
engendered fades from the public eye. 


If, in the case of Rebol3, it simply is too much work for one person 
- then perhaps now would be the time to open such areas as View development 
(the underlying system) and advertise to the 'World' "Come, see what 
you can do!".


Personally, I'd love to see Cyphre's work with View taken that one 
step further and translated into OpenGL and all that entails.  Not 
everyone today is looking to use Rebol only on their embedded devices 
;)

You know how it goes. In order for View to be opened, the DevBase 
needs to be finished. In order to finish DevBase, rebservices redesign 
is planned, etc., etc.

The biggest block to finishing DevBase was that my time to work on 
it went away for a few months. That should be changing soon.

The rebservices portion of DevBase works just fine, and once rebservices 
are finalized (changed? rewritten?) DevBase will be able to adjust 
with little difficulty. The main block we ran into in DevBase development 
was disagreement on the UI, and other factors we don't need to get 
into here.

The main block to View being opened is not DevBase, it is that the 
core design of View isn't done yet. REBOL has a lead designer - we 
don't do design by committee. The rest of us refine the design and 
make really cool stuff based on the foundations, but the lead architect 
is still Carl.

but why, when the core design for View isnt done yet is Carl even 
thinking on working on VID?  Surely we need a View before VID is 
even feasible?

He is making adjustments to View to make VID feasible. Shortcomings 
in the core were causing shortcomings in VID.

VID is the goal. View is the means.

Also, it looks like the new VID may be more integrated than the old 
one.

I always looked at REBOL as a general programming language, but it 
seems that's no more a goal to reach (if it has ever been in RT's 
plans). I know that it has been marketed as a "messaging language", 
but I thought that  it would evolve more as a pure programming language. 
Maybe I have a wrong POV on REBOL from the beggining. I always looked 
at VID/View being a good addition to the language, but not a vital 
one. Now that such high-level features have become top priority, 
I wonder if Core3.0, with all the features we're waiting for since 
years, will be completed and stable before 2010...I'm not sure that 
I'll wait that much.

I'm a bit impatient myself Doc.  I think they should not worry about 
VID for release but worry about what VID will be built off of - hence 
VIEW instead and they can always release VID as a module later if 
needed.

I shouldn' t use the word impatient because I think that anyone that 
is waiting on R3 has obviously displayed patience.

I always looked at REBOL as a data structure manipulation library 
with language implementation tools built in. Also, it bundles some 
useful languages with it. My only significant View app has been DevBase 
- aside from that I have just used it for code generation, batch 
processes and server side stuff.

I didn't even write most of the View stuff in DevBase, just adapted 
Carl and Henrik's code. :)

I have written several VID based apps but I'm usually finding myself 
more in need of features that the /core lacks.

I've stopped working on the products built with REBOL I was planning 
to release. The future of REBOL as a standalone programming language, 
has become too uncertain for me. I'm working only on Cheyenne and 
MySQL driver, because I use them daily, but I don't think that I 
will invest more time and energy than that on REBOL. I've already 
started searching for alternative solutions, including resume working 
on a clone or a derivated of REBOL. In the past, I've stopped working 
on a clone because, the release of the plugin interface for REBOL 
was supposed to be imminent. That was 3 years ago.

Doc, I'm also looking for an alternative to REBOL for mostly the 
same reasons.  So if you find something that appeals to you, please 
share the information.  I know very little about the strengths and 
weaknesses of other languages and hope other developers can chime 
in on their experiences.

I've mostly gone in the opposite direction, doing more and more with 
REBOL.

I guess it's because I'm getting more and more skilled with dialects 
and try to push myself to improve my skills in REBOL, so when it's 
about tool building, for me it's also about pushing myself to write 
the most elegant tool possible. Also I just get plain depressed when 
moving to PHP, javascript or similar to do work there. I can't get 
back to REBOL fast enough. :-)

When I work in other languages, I generate the code using REBOL half 
the time.

Well, REBOL has influenced me quite a lot too. I don't want to get 
back to an inferior tool, but I don't want to use a closed-source 
programming language anymore (unless it is backed by a *big* software 
company).

Hum alternative to rebol is a n old idea but since today no one went 
in this process as far carl did. If we really want to wirte our own 
REBOL-Like VM  that means the same thing than for REBOL main dev 
 in fact .... ORGANISATION people who will work each day some hours 
on the project. REmember guys the pyramids in Egypt or in mexico 
have been done stone by stone past 3000  years and they are still 
up today. This to point the fact we all have side things to and starting 
from scratch  the writing of a REBOL clone implicate a true implication 
and not from only 1 guy.

DocKimbel, it's interesting with big companies... what if REBOL had 
been invented by Carl while he was with Commodore?

I think the problem is that Carl doesn't seem to have the resources. 
 Even if he had the resources they would have to have the CARL-WAy 
of development to achieve his vision for REBOL.

I LOVE REBOL  that a fact but rebol is a hum how to say that without 
hurting Carl .... not achieved. Carl start things and never finish 
them and that ends to an incomplete picture and the fact that rebol 
is considere as a cool toy but not as a professional thing.

Software has never being a major business for Commodore AFAIK.

really in french community we got the spirit VM project who died 
because lackk of interrest

I love working in Rebol for GUI apps.  Development is fast and I 
can do most of the things I want with the raw view.  Sure, I could 
go back to grinding out interfaces in C++/C#/VB/<insert lang here> 
but it would lack the simplicity and flexibility I am used to with 
Rebol.  Unfortunately, most of the time i am now using Rebol for 
'what if' and concept work because of many underlying issues with 
the draw subsystem preclude serious development work.