World: r4wp

Curious too about time frames for file access, network protocols, 
2D drawing API, sound, etc.  Are those things on the horizon yet? 
 Looking forward to when you can port higher level things like mysql 
dialect, games demos, etc.

You answer makes me want to send you more money :)

You -> Your

:-)


File and network I/O: should be done for Christmas (maybe alpha state 
for networking). I will provide then HTTP client/server support shortly 
after. Expect more network protocols to come in Q1/Q2 2013. 2D/sound 
will be part of the work on GUI, so will happen later in 2013. Mysql 
support through networking: I will very much like to have that, as 
Postgresql support too. Expect them before summer 2013 (or maybe 
before for MySQL, if I need it for a killer Red demo). ;-)

Pekr: that is the kind of "killer-demo" that we need to make Red 
reach out developers far beyond REBOL community.

BTW, functions support should be finished this weekend, then I will 
work on object! and error! implementation new week.

new = next

Now after observing development of several GUI systems, there are 
always some particular things I find wrong with them: They were designed 
with small details in mind rather than the big picture. This means 
that when a developer uses a GUI system, he'll find that some things 
are easy, while others are very hard. For example, none of our GUI 
systems are particularly designer friendly, meaning that building 
a skin requires a programmer with artistic skills. There are not 
many of those around and that's a real problem. Saphirion's R3 GUI 
was derived from Carl's work in a way, where several parts were rewritten, 
because they didn't scale enough for real-world GUIs. The rest of 
the work has been about beefing up the R3 GUI to handle what is needed.


Development often seems to go in isolated sections: Building styles, 
building a layout engine, event handling, skin system, animation 
or whatever, without a properly coherent view on the whole thing. 
We talk about how we have a really nice feature, but that feature 
may not mean much, if it's not functioning in a coherent way with 
the rest.


If I were to restart VID Ext Kit as a new GUI system, I would rewrite 
it top down: Start with an application with the simplest, purest 
GUI description and write the GUI system down from there. I would 
recommend that a GUI system for Red needs to be written like that, 
starting as early as possible and let it grow downwards instead of 
upwards with a real application in mind rather than some neat demos.

In short: Write apps and pretend we have a complete, perfect and 
luxurious GUI system with no work-arounds. Then write that GUI system.

red-system question:
which is the difference between pointer! [byte!] and c-string! ?

It would be great if the GUI system used a combination of vector 
and bitmap rendering for widgets. Vector drawing could be used for 
initial drawing or when a GUI was re-sized. Thereafter, the widgets 
could cache their bitmap (if so configured). Maybe I'm stating the 
obvious and this is already how things are planned to work.

Henrik:I agree with your way of thinking, that is the kind of pragmatic 
approach I take often too when designing any dialects or even APIs. 
For the Red native GUI system, I will prototype it with the first 
big Red app I plan to write: the Red IDE.

which is the difference between pointer! [byte!] and c-string! ?


C-string! points to a stream of bytes terminated by a NUL character, 
while pointer! [byte!] has no such requirement.

AdrianS: for a View-like engine, it would makes sense, but such approach 
suppose that you are building all the widgets yourself, while what 
I want is use native or third-party widgets. We've experienced in 
the last decade with View, how difficult it is to come up with your 
own complete set of widgets with good look'n feel.

Some of you might not have noticed but Red is maturing fast, it justs 
lacks I/O support to be already usable for building small scripts/apps. 
So, even if it is still in alpha stage, we need to come up with a 
plan for building a good user-oriented documentation (there is already 
someone working on the Red formal semantics description). I do not 
want to rewrite the REBOL/Core documentation, but a lot of core concepts 
and datatype will be identical, so, what do you suggest we do for 
documenting Red?

A couple of observations: I would think that the slow going with 
View had a lot to do with the size of the community as well as an 
architecture that didn't easily permit the use of vector graphics, 
preferably designed using external tools, for drawing widget states. 


WRT Red, it makes sense to use native controls in order to get off 
the ground quickly, but the UI subsystem should allow for owner drawn 
controls. By allow for, I mean that these should be able to exist 
side-by-side with native controls, and, if defined using a vector 
source, widgets should do bitmap caching at the appropriate times 
for better performance. I guess what I'm saying is to please think 
about how owner drawn widgets would fit into whatever is the initial 
implementation.

Great explanations Nenad! My apologies if sometimes I seem to ask 
for the known things.. 


For the documentation we need a Red marker pen and mark the REBOL 
documentation where appropriate for Red.

I took a little time (just 5 minutes LoL) to see if I could find 
a starting point for the documentation extraction script from the 
suggested makedoc2.r script but 'parse is not my best REBOL skill.


Besides graphics and a killer application as Pekr described, having 
CGI support for Red can bring a lot of attention to Red too imho. 
(And this could bring financing Red up too when Red programmers are 
making money making websites using Red.)

I agree with Henrik 90%. The hard part is picking the target app 
and important elements. A game, or modern app with animation elements 
is a very different target than an "efficiency above all" business 
app. One of my failed attempts with REBOL was to get Carl, for just 
this reason, to identify a target audience. It guides your design. 


In the case of a Red/REBOL GUI, maybe there is no single design or 
dialect. Making small apps simple is hard to match to the needs of 
complex apps. If you're writing database/CRUD apps, wouldn't it be 
great to have a toolset designed just for that? That same toolset 
won't work well for games though.


I think using an IDE as the first target app is a *fantastic* idea. 
It covers a lot of areas, including the possibility of building on 
an extensible app framework (something lighter than Eclipse :-), 
files, documents, workflow, tool integration, customization, and 
many UI elements. And *we*, developers, are the target audience.

VID gets a lot of things right. Let's not forget that.

If Carl is going to open source the R3/3 documentation, can't we 
just add a Red section ?

Or add to the existing wikibooks stuff?

Docs are always a hard question. I have always appreciated the docs 
that Carl and others spent time and care creating; the old Core manual 
appeals to me. Wikis are good for many things, though I seem to lose 
or confuse wiki logins more than other accounts, and their presentation 
rarely impresses me. It's an easy way to make things open for contributions 
though.

Of course, I prefer REBOL data, with makedoc being my preferred markup 
format. I don't know if Carl's WIP wiki is worth asking about, or 
another wiki engine or site would not lock us in too much. Some of 
us did some work on a wikimedia interface for R3 docs, which didn't 
get far. And I have a wikidot site we can play with if people want.

I also like EasyVID and the other active document and lab tools.

REBOL data, tags, and a way to push and pull. That's all. :-)

also the help system can be sent to a wiki

There are two main types of documentation, reference docs and guides

I'm looking forward to making Red versions of my tutorials and examples 
scripts.  Those will be guides - someone else will need to focus 
on reference docs.

I am thinking about a reference documentation. How to do it without 
rewritting REBOL/Core documentation?

If Carl is going to open source the R3/3 documentation,
 I haven't read anything about that.

I have some cool ideas about guides too, mainly for first steps with 
Red and how to clearly explaining concepts to beginners, but I have 
issue imagining a reference documentation content different from 
REBOL/Core docs.

So, can we do a better than REBOL/Core documentation? Can we present 
the same content in a radically different (better?) way?

(By REBOL/Core documentation, I'm referring to the "old Core manual" 
as Gregg said)

About the tooling, a wiki approach + makedoc format makes sense to 
me.

Well, as for me, it is easy as that - f*ck off native controls :-) 
What does that really mean today? I have really no intention seeing 
GTK or other crap. Either use your own GUI, or HTML, that's almost 
the only standard, which will prevail anyway. We should ask ourselves 
- how relevant is e.g. the Gnome GUI guide? And who cares in the 
big picture? So - for easy embedded stuff, just give me a small GUI 
system, for bigger picture, give me a  HTML5. I e.g. don't understand, 
why Kaj tries to port something like Enlightenment. I really miss 
the big picture. Who and why should ever use it? For personal purposes, 
or some specific stuff - why not, but that's not imo a strategic 
direction ...

I do remember the times when Win95 came. All the world was claiming 
- your apps need the menu, a toolbar, etc. Free style Amiga like 
apps were a dirty world. Now, 15 years later, such aproach looks 
archaic, laughable. The time has changed. Let's target mobile platforms.

And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...

Pekr, the look is only crap, because I don't have time to work on 
the skin yet.

So you're saying don't use native toolkits and don't do your own 
GUI? ;-)

And appearance really is quite separate from the underpinnings.

No, it is just how you understand it. After 15 years, I still can 
see similar mistakes ....

I would never want my app to look like GTK, easy as that. Maybe because 
I have zero intention to do Linux native GUI app. Linux, in a big 
picture (desktop), is irrelevant. Alway was. Who claims otherwise, 
lives in separate reality :-) Mobile will prevail classical PC sales 
very soon (if not already). Own GUI, for small niche, might be good. 
But - it has to have attractive design. The situation with Saphirion 
was, that the substantially rewritten Carl's engine. Nice enhancements, 
resizing and other stuff. But I NEVER understood, why the look was 
so totally unattractive. You see, Henrik once again claiming the 
old stuff, which was the basic reason of a failure. Design is a separate 
animal, which was supposed to come later, which could be done by 
anyone, which "just" needs material system which never appeared, 
etc. And result for me (as a sigle person)? Carl's GUI desing attracts 
me by some 60% more, just because of look. Once again - look sells 
...

In fact, what I think is, that Saphirion was really close to the 
GUI engine, which adressed most of what we wanted to solve by VID2 
to VID3 transition. It was just not polished. And because of that, 
ppl did not find it attractive enough to play with. And that's a 
real pity. Anyone doing native platform GUI will make me to close 
that demo at first sight, easy as that. Doc is in kind of difficult 
situation - as we can see, many former/recent rebollers are still 
interested in View like engine. The same reason why Doc dismissed 
LLVM in Carl's blog post, the same reason many will dismiss attempts 
to link to GTK, Enlightenment, etc - I don't want to use 5+MB crap 
...

which 

just" needs material system which never appeared, etc." - the material 
system should be included in the current Saphirion release.

...for easy embedded stuff, just give me a small GUI system, for 
bigger picture, give me a  HTML5


So what do you propose for the GUI, that will allow it to look good? 
i.e., what is your constructive suggestion, rather than criticizing 
all the wrongs of the past.

Petr, if you pay me enough, I might refrain from doing the GTK+ and 
Enlightenment bindings :-)

Gregg - my constructive suggestion is to orientiate on the platforms, 
which have a future. Is that an AmigaOS (to which R3 got ported as 
a paradox), is that a BeOS? Is that even a Linux? I would vote - 
Android, iOS, WP8, BB10. If new players with new potential appear, 
let's add them. How many of us would ever need to do a real native 
Linux app? And Linxu, is a big name here.

So - it might seem, that I contradict what Doc wants. I think I don't 
do so. He wants to be native on those above platform. And that makes 
sense. But - are those above platforms done in GTK? Enlightenment? 
Look at Microsfot - I just yesterday was watching their 5 hours of 
SharePoint plus Office 2013 presentation - most of their new stuff 
is becoming - HTML5. They are even scratching Silverlight for the 
typical desktop ...

My suggestion, then, is to make a list of target OSs, prioritize 
the value of a GUI on them, and propose the best GUI solution for 
each.

Would you be willing to set up a checklist for that Petr?

Pekr: you don't get the right picture. When I mention "native widgets", 
I am mainly referring to the ones provided by each OS, which is what 
most users expect to find in an app for their OS, and what most developers 
wants, is to provide a consistent experience for users. So, actually, 
such approach will be lighter then /View, because the OS provides 
you with everything you need. In the case of Linux, GTK is the main 
standard and it is built-in many distros, so that is the one we will 
probably use for Linux target and you don't need to provide it with 
your app.