AltME groups: search

And hence - I will never take ANY position, if things are not outlined 
the way I need them to be ... one of the most important thing is 
- communication channel.

Pekr;  The User Group will follow Bob's Rules.  The name is Item 
1 on the agenda.

Open for debate and then (a possibly unfortunate side effect of democracy) 
the vote

of the assembly is the final word.  I'm suggesting [RIG], but lots 
of names will hit the 
floor before the vote.  :)

but what I can see is, that you have your own ideas of how to cook 
new VID, and I suspect you will do it, propose it, and let us stay 
in the strange position of "take it, or go away".

I repeatedly asked here, if such group works in other altme Worlds, 
etc., and was assured, that once there is a time, it will be formed. 
And I could also see, that guys as Henrik, Anton, would very much 
appreciate being in such group.

btiffin - does it need to be three letter acronym? :-) and btw - 
we should also follow the praxe, which means - maybe such a thing 
needs some spontaneous way to form itself. Currently we are few, 
and we kind of for user group here on altme, working closer together. 
I will reread your post towards the topic, to find out what is the 
purpose of the initiative ...

the truth is, that it si you, who started to talk about commiteee. 
And it is not imo fair to this group, because it was RT, who first 
outlined VID 2 group, as closed group of VERY FEW developers. And 
some of us, remembering Henrik, Anton, expressed their will to accept 
such group invitation ...

What I actually see is you collecting ideas, e.g. from Maxim, discussing 
some things, but admitting you will choose only some parts of eventual 
data-flow aproach, maybe without understanding whole Maxim's engine 
purpose? I don't really mind new VID being your or Carl's only decision, 
but what I would regard as being fair is - create some document about 
planned architecture, and let it run via 1 or 2 round of comments 
here. Actually, you prepared your original ideas in such form too 
IIRC.

... because, I would not like to see following happen - you design 
some quick solution, which will not cover past VID missing part, 
which will not be easilly addable, and surely you will not feel comfort, 
if ppl will complain. We were there, and the response was - well, 
VID was written in about a week, and why you don't write your own 
one GUI engine upon View?

i started to talk of committee - no, and i'm sorry if i was not clear. 
we need help with the implementation, and we surely need feedback 
with the design (although, i think that we got quite a lot of feedback 
on this in the past few years, and from rebgui, liquidgl, and so 
on), but i don't think i ever side that design decisions should go 
thru a voting process or something like that. design decisions come 
from carl. i can show him my, or anyone else ideas, and he will say 
yes or no (i'm simplifying but you get the idea). showing him 100 
different ideas is not going to work (we must get to something in 
much less than a month)

dataflow: me, carl, richard, nenad, max etc were sitting discussing 
this at the devcon, and nenad asked - i don't see what this is good 
for in practice. carl said, i'd just like the gui part of the thing 
- connecting widgets, so how big is liquid? max said at least 20k, 
to which carl said "too big".

 I think [small] domain-specific GUI's built on View are the way to 
 go.

 -- I agree 100%. Better for RT to give us good docs on how to build 
 those, than trying to build them all in house.


but there should be one more complete/robust one, which will serve 
for 

general" app development" -- There is. Today it's called VID. It's 
not perfect, can be very limiting, and has big holes (e.g. no focus), 
but it's there.


I think the point Gabriele made--that this is how Carl works, and 
we have to live with it--is very important. That's not an easy thing 
to do, but I think getting too many people involved will not work. 
I hope there is a small team of technical people, and that someone 
makes note of what has been requested. I don't expect perfection, 
but I don't think RT will ignore what has been said in the past either.

so, i've looked into the liquid source, i've looked into what max's 
demos etc., and i still can't find an example where we need 20k of 
code. i can do all of that in 2k of code (actually zero, since i 
already want it to be all event based). so, i'm not making a final 
decision here, but i expect carl to chose 0kb over 20kb, functionality 
being the same from his pov (connecting widgets automatically).

comments - we've been getting comments from here (and other various 
private groups) for the past two years or so... now we got to create 
it. i'll work as much as possible so that you guys have docs as soon 
as possible and before things are finalized, but we have to get it 
finalized by 30 june.

Gabriele, noone was thinking commitee aproach here imo :-) But IIRC 
we really talked about forming small group for VID+ era. I can't 
see anything bad on it. And I don't want to be there, because I know 
ppl here, I voiced what I need and I believe guys like Henrik, who 
are doing real-world apps know what we need in that respect ...

my wish is simple - I want VID like environment, with redesigned 
problematic parts - simply put, it should allow OS like apps creations. 
I don't mind skinning at all, but things like focus, tabbing, accelerator 
keys, disabling/enabling of elements, etc. And probably more general 
VID level event system on-* handlers instead of one engage func.

I hope RT will get input from both Henrik and Ashley because of their 
experience in building on VID and View. More importantly, both of 
them have provided *great* docs.

Something I sometimes do for RT is collect and sift community input 
for them analyze. I donh't know if they always read it, but I know 
they do sometimes. If people have input they think is important, 
I will be happy to collect it and submit it to RT.

I would prefer that RT would work on the foundation, rather than 
something quick and sloppy that tries barely to cover everything 
like VID does. We'll help with the upper layers of GUI element design. 
That's not design by commitee, but simply compartmentalizing who 
does what. With R3, I had expected the goal to have as small and 
efficient a core as possible, with the rest being open source. Carry 
that philosophy through with the GUI as well, so RT can do a fast 
and efficient basis for a GUI and let actual artists and GUI designers 
work on the GUI.


This way, if some of us want a serious GUI system, we can build that 
and if we want something very fancy and artistic, we can build that 
too and both will not compete with eachother, but supplement eachother 
instead. I hate to see double work done in such a small community.

you know guys, in a sense I already have a 100% working dataflow 
view.  and it took me 2 hours to build the whole gadget architecture 
on it and about 30 minutes to write my first integer field... and 
its all AGG.  and its 100% bug free.

cause all I'll need to do for R3 is replace my internal gob class 
(gel) with them and maybe how I detect the strokes and all.

I am busy (repurating from the lost week going to devcon, am working 
on my house, cause its sunny and want to release revault by next 
monday)

once that is up, I will work on releasing liquidGL and then elixir.

petr, that's what we want too and i think we have expressed that. 
if we haven't expressed that enough, let me stress it again.

I think I understand, why Carl wants some default foundation. This 
is the same reason why installer was introduced. He wants rebol to 
be adopted by masses, and hence he wants some default VID.

Gabriele, I only think there is a matter of miscommunication. Some 
time ago I joined a private GUI design group in here, which was called 
the official one for R3. I can't remember who started it, but a lot 
of people, including Pekr, joined up. So I started working on concepts 
for integrating an animation system into VID. I think people are 
a little upset, because it felt like RT were going behind our backs 
and wanted to pull R3 GUI in your own very different direction and 
disregard the work we did.

Being a REBOLer from a lot of years being not a guru, especially 
in the GUI area and having suggested REBOL to other programmers I 
wish to share with you my pov that, maybe, can explain the situation. 
The lack of documentation and the initial easyness of VID is a deterrent 
for programmers to adopt REBOL. In the last week I asked Anton for 
help with some VID and styles and he wanted feedback from me. He 
did a few things (an analog clock style and some adjustments to his 
scroll-tables) but make up his and my mind about some design details 
is still not over as need, POVs and uses of the same style can be 
very differents with two people involved (with one being the programmer 
and the other a little user like me). Imagine an as small as you 
wish group and try to figure out the time it needs to decide design. 
Put this together with the pressure of not taking too much time to 
release R3 before July and I think it should be clear why Carl has 
to stop asking opinions (after 2 years) and put more time on coding

official one for R3 - can you point me to any statement from Carl 
on that account? Also, i'm not really pulling to do this myself. 
i would be more than happy to have someone else doing it. you can 
talk to Carl and ask him to let someone else do it.

so, ok, what is the community's decision on this topic. i will stick 
to it and tell Carl about it.

Well I repeated Gregg's and some of Pekr's words. I was too slow 
in typing

I would like to be part of the team.  Just like Anton, I've been 
fighting my way inside of VID for years.


I'll be blunt The only thing I'd keep is the dialect concept while 
add glayout ish row/column layout which even Carl admitted is much 
easier to handle and "see".

all the other internals, well, I'd implement completely differently... 
and I'm not talking Dataflow here.

I mean in making it as "open" and obvious as the face object is.

decision - difficult to say .... some form of more involvement, better 
organisation of efforst. Last two weeks I exchanged two emails with 
Carl. My opinion is, that we need to start working on several parallel 
fronts. DevBase, DocBase, new RT's site structure (both .com and 
.net). We don't know anything concrete about those. And those are 
importan - we need to start to think too, how to structure docs, 
if/how we allow them to be translated, etc.

it seems that the face is very well tought out, and with a simple 
guide you can grok most of its cincepts in an evening.

May I suggest to give a timeline to the decision and discuss and 
"fight" about it between the small group (choose your preferred discussion 
"place") and, as Gregg suggested, collect the resulting deliberations 
to be submitted to Gabriele and Carl?

VID internals are so obscure and limiting that in most parts, its 
easier to replace them than hook ourself in.

It would be nice if RT communicated to us in here, we who are very 
interested in working as closely as possible with RT, but cannot 
do work directly on the core, on what it would be a very good idea 
for us to consider building.


Like: "RT thinks you should look at building a GUI system" or "RT 
would like you to build a test case suite for R3" or "RT would like 
you to work on making OpenGL work well with REBOL as a dialect like 
VID" or "RT would love to see you building protocols for this and 
that kind of communication" or "RT needs a very good multithreaded 
webserver, that can handle X users" and have those efforts officially 
endorsed by RT, similarly to how MUI eventually became the GUI of 
choice on the Amiga to build your applications on. Perhaps put out 
hard specs and see if anyone will pick it up.


Right now, many efforts feel like they are there, not because RT 
felt they were a good idea, but because some individuals thought 
they were good ideas. Most of us here speak highly of our own ideas, 
but without much dialog with RT. AltME feels like it's the only non-RT 
effort that is endorsed by RT and perhaps also Cheyenne. Such directions 
would also mean that perhaps a lot of people would flock to the same 
official project, rather than starting 2-3 separate projects.

I personally don't see the rush for view in R3.  frankly, no one 
in the community (or outside) will be wanting to fork their "serious" 
development on it, until a little bit of testing and all.

he has all the skills, the drive and the perfect personality ... 
someone who can tell Reichart to STFU and make Reichart laugh... 
well has impressive communication skills and intuition  :-D

hehe pekr and me in the same room will have that effect usually. 
 ;-)

I really want it to be constructive, but the lack of Carl's communication 
is problem even for future imo. Some official organisation as rebol 
user group might work, as it could be more readable to Carl. I suggested 
him via email, that one hour per month or two of guru session here 
would help to keep spirit high .... it can fantastically motivate 
ppl ... and those motivated here can motivate down the way to the 
computing world ...

My main question is why the rush?  why not let the community come 
up with a few example prototypes, why not let people like cyphre 
take care of the low-level architecture and make it as perfect as 
I know Cyphre can make it.

Well, generally I vote for - Anton, Henrik, Ashley, Volker, Maxim 
to form a close group to Gabriele and Cyphre, and discuss new VID 
- basic concepts ...

and why not give people like Anton, Ashley, Henrik, me and others, 
the chance to try out the proposed technology first.

I would hope that Anton will be included in any discussions on View, 
GUI planning. He knows it inside and out, and has been a great help 
to me through many GUI problems.

Maxim - whatever, but my undestanding is, that Carl really does not 
want all your technology. Start a dialect - start closed group of 
few named persons and at least outline solution - publish agreed 
or problematic bullets .... the rest will add opinion ... meet once 
again, close design doc, ---> implement

that will not take much time, and Gabriele might feel safe, that 
his implementation or proposal adresses most of wishes ...

I fear that noone will understand deep DF thoughts, and that novices 
extending GUI might feel once again lost, like they were when looking 
at VID internals for the first time :-)

hum, I am an expert at VID... I have rewrote the wake event from 
scratch, I don't use ANY of the popup code for modal windows, etc 
and I'm still mystified by how VID's design came to be  ;-)

but when you see how it scales and how easily it can tackle the most 
complicated tasks, then it starts actually being much more simple 
than coding all the stuff by hand... that is the problem.

yes, and its part of the angst.

Gabriele, it's probably a matter of:

- What will he trust us to do?

- Does he have specific things that he would like to see done with 
R3?

- Does he expect that it has to be paid work, or voluntary work? 
Because I think he would easily be able to find volunteers as long 
as projects are small, focused and beneficial to as many R3 users 
as possible.


For example does he plan to build his own IDE for R3? Does he plan 
to make R3 run natively on PCs himself or Amigas or Macs? Because 
if we can get a straight "no" or "yes", we could act accordingly.

it could have, but I realised in the end its simpler and much easier 
to "get"  its like functions upside down.

I fear just one thing - that if new VID is not conceptually sufficient, 
new stuff gets build upon it, and then we will be reluctant to changes 
because of compatibility problems.

It's never been said anywhere, if the june/july release will be alpha, 
beta or final 3.0 version (and I don't expect the later), so I'm 
not afraid that some early prototype of new VID that will be released, 
will be also the final version. R3 final may come later enough to 
fix those problems.

max, petr, all your comments so far can be summarized as, you don't 
trust me and Carl with coming with a good enough design. Can I tell 
this to Carl?

so you trust me and Carl but you fear the design will be bad?

Gabriele I think that he's more afraid that he (or anybody else) 
cannot comment your and Carl's design. I think he just wants that 
whater you come up with won't be final, but will be open to suggestions 
from community.

Well, you can raise such summary against me, as I know others "talk 
is cheap" arguments, and I rarely produce any code anymore, but that 
just shows your disrespect to Henrik's and other's concerns ...

and changes, real open changes.

i think both of you said that you fear that the design will be rushed 
and not good enough.

I've said it above, its not "good" that I want.  its "open", "extensible", 
and I mean that from the inside.

As I understand it, people are just afraid that their suggestions 
will end up in a trashcan and not that you and Carl cannot design 
it well.

Please don't shot me as I must quickly step out my home: VID was 
designed in 1 week but its limits have been under our and RT eyes 
for years I don't think the newly designed VID/whatever-it's-called 
will be done ignoring the errors of the past. Propose your needs, 
collect them and submit them to Gregg or Gabriele to be told to Carl

allowing me to use a gui and open it up in OpenGL, activeX, if I 
have the need/resources/time to provide it.  I mean to be able to 
extend the whole engine so I can skin it without needing to rebuild 
100% of the gadgets, etc... many of the things we spoke at the devcon, 
but more too.

this started with me saying that I wanted to have more people to 
comment on VID

 - nice, but you also said that some interest group or comitee won't 
 take us anywhere (which may be right), so people may fear that nobody's 
 listening to them (and I think someone will agree that lack of communication 
 is biggest RT problem)

And why? Because it already happened in the past.

if I may suggest something you (and Carl) should write a document 
about new VID internals (how it will work, what it is going to support) 
- no code required in this phase. Then please release this document 
and have others to comment it. Then rewrite the document according 
to proposals you like and then someone should start to code, be it 
you, Carl, some RT outsider....whoever best fits the task.

FYI;  The informal Bob's Rules of Order time limit runs out on the 
REBOL User group

proposal tomorrow.  I think there is some consensus, and reading 
this it really looks

like a formalized Executive Summary would be beneficial to everybody. 
 Even if it

never gets read at RT, it'll let the community vent steam and brainstorm. 
 Expect 

an Agenda for the formation of a formal group on Saturday.  First 
meeting here on

Sunday-Monday-Tuesday.  I've tagged Bob's rule at 72 hours of 'floor' 
time,
(unless voted on and changed) after the organization forms.

let them shortly review and discuss general direction ... once agreed 
upon, close the door with Cyphre, buy lots of pizza and don't come 
out, unless you are ready with first prototype :-)

how is this different from what i said in the beginning - i want 
people to look at my vid as soon as i have something to show and 
get their comments.

Gabriele = my VID = actual implementation already, no? Because - 
I looked at your former proposal/doc, and I am not sure I agreed 
to abstraction which was put into it ...

I'm going so side with Gabriele on this one.  Partly because it seems 
he is being

ganged up on at the moment, and I think it is the best interest of 
the common good to

let stuff roll and then discuss, rather than discuss and let roll. 
 (Given some trust of
good thorough work of course...)

It seems I may be at odds with Pekr's view.

I really take Henrik, Ashley, Anton and Max as ppl, who use rebol 
in various areas of real-life apps, or at least have deep enough 
knowledge of VID internals to help you ...

Brain - my view is based upon endless RT's promisses and non delivered 
things, concepts, which are published, and then silently disapper, 
etc., sadly ... The basic road block being a communication.

And I would like to warn us, upon my experience of team leadership 
here, that if some formal rules are not set for the future, we will 
not handle the situation.

it means more communication... look, Gabriele actually is speaking 
with us... and IS here every day.

Yep.  And a formalized group may address some of that...may be not, 
but I think it'll be
worth the effort.

the power

 is still way too centralised. New ppl will come. And that is why 
 I asked Carl even about concepts like DevBase, DocBase, BugBase, 
 localisations, communication principles with userbase, etc. - but 
 that is different topic ....

Pekr;  Yep RT has promised things...but (and this is where being 
out of the computer

biz for seven years may be of benefit to me) it seems things are 
really starting to
accelerate.

just one last quick note: I think that having a look at MUI will 
be good - MUI resizes buttons automatically to fit the text in, there 
are no absolute coordinates. Someone may think, that absolute coordinates 
are good (bitmap graphic-heavy people), but absolute coordinations 
are PURE EVIL, at least from internalization/Localization POV. And 
if the GUI is not made with internalization in mind from the beginning, 
it's not possible to add it later (if it was, there won't be about 
forty people resing every button in Vista for every language edition 
manually)

And Pekr;  If the design include points of extensibility, thats where 
"we" get to play.  :)

Gabriele that's good. It's just that this is one thing that is nor 
adressed in current VID, RebGUI etc and it would be really great 
if new VID will have this from the begining. Take it just as a wish 
:)

otherwise, we should just port current vid and add a few things in 
the dialect.

IIRC think carl really likes the simplicity and power of GLayout's 
proportional sizing engine.

its a prototype so yess the *code* has some ugly bits... but the 
layout concept is very agile, and makes tidy guis with little effort 
and understanding needed... its acutally much simpler than current 
vVID.

And sorry Pekr;  I get my verbology wrong sometimes...  Wasn't meant 
as a diss.

I actually think, along with this heated debate, things are going 
to accelerate and

we are going to have more chance to get our hands dirty than any 
of us may be able
to handle.  It's going to great.

my point earlier was I'd like R3 to have time to actually try out 
different approaches, have them working code, let the community try 
out, maybe even create different propositions and take the time to 
use and have fun.

but having a june 30 date just allow a single track to move along 
so... I understand why/how you are approaching the whole thing... 
and yess I think you are courageous for asking openly here.

Maxim;  That can be good...but it can also be dangerous.  Everyone 
here is too smart
and has too many good ideas.  May become overwhelming.  :)

And I don't mean too smart in a bad way.  The computer IQ in this 
forum is off the scale

just asking people about what they want obviously collides... everyone 
has different needs and POV.

the best things will stand out, IMHO, and ususally, there is a way 
to make them cooperative.

liquid was implement in such a fashion... basically I took 3 engines 
and merged them.  each one was incompatible, but had great indivual 
traits which stood out...  so a bit of tought allowed me to merge 
about 120kb of code into 20k of code, and in all, it acutally does 
more than the 3 did own their own.

And when I say that...it is only the "user community" assembly.  
Design is a seperate

issue.  The REBOL User group will only let us clear the noise down 
to a point form
executive summary...

As I can see it, we follow related, but slightly different topics 
... first one is actual VID implementation and the way of project 
coordination, the second one is more general - setting communication 
channels with RT sooner than later, because if new ppl come, we will 
sink under once again ...

imagine thousands of new users asking questions towards rebol and 
its direction and desinger not being available ... as for me, I want 
to work closely with rebol evangelist person ...

the same contradiction than what is occuring here happened, but I 
got insight, and the final result allowed me to have a clear picture 
of what to propose to Carl.

and I am pretty sure the final will appeal to most who are working 
on module like api code.

Let the snowball start rolling down the hill...and we can either 
get bowled over or direct

it.  That may be our part.  Again I'm coming solely from a desire 
to be an 'end-user'.