World: r3wp

My question is asked to the R3-GUI team and also to Carl

Jocko, the level of usability of Carl's demo was not satisfactory, 
and is lower than that now, since nobody cared to keep it compatible 
with the low level changes to the hostkit. That is the situation. 
Documentation - the same level of documentation exists (written by 
me), but Cyphre decided to publish it after the changes to the remaining 
styles using the panel implementation take place.

I will try to persuade him to publish it sooner, since I don't thing 
it is necessary to wait.

think

Docs about the system before the system is done would help people 
prepare, so their ideas will be ready by the time the system catches 
up. Plus, it's not so difficult to make minor changes to the docs.

Shadwolf said: "...so your idea of a working rebol community is a 
rebol community with 10 R3/GUI because 10 of us has different ideas 
on the topic."

I must say I have no problem having 10 or more R3-guis... it's always 
better than having none. Of course it would be nice to have at least 
the core shared, but you will not have it if you even don't try to 
propose something.

Regarding roadmap, I suppose a comprehensive graph style does not 
need much else than what is available now, as it would mostly rely 
on DRAW.

I think that talking a graph style, if we don't have tabs, tree, 
grid, is a bit preliminary. We need imo basic styleset, usefull to 
work with general DB apps, then we need more modern skin, and only 
then we need additional styles. We still can't see even concepts 
as accelerator keys being displayed, etc. :-)

But having a roadmap/plan, to answer questions as mine above, about 
what features are planned at all, would be usefull ...

The idea for the roadmap was to remove the need for RM Asset to do 
these styles ourselves later, when we are busy writing R3 end user 
apps, otherwise it could take a good 1-2 years before they would 
be publicized. The roadmap would be shaped around which styles are 
needed and which basic features need still to be implemented in the 
GUI.

That is understandable, for the styles ... but what about missing 
features? Will we add them, as needed? I mean e.g. - there was a 
discussion about the hilite/glow effect. One group of ppl wanted 
to have central abstracted behaviour, other ppl were talking about 
the per-style implementation, while there is third possible aproach 
- the mixture of both - central solution with possibe per-style override. 
Such things you need to account for, when writing your style, depending 
upon the decision about how it will be solved architecture-wise?

they will of course be added as needed. that's the best way to do 
it.

Henrik - when I scroll above, you created the list of windowing and 
more advanced styles needed. Could we get the list, which will be 
delivered with initial release? E.g. we know, that Cyphre was working 
on some grid engine, etc., so that devs can know, what they don't 
need to focus on?

Pekr, I can't be sure at this time, because currently the styles 
are worked on via immediate need for fixes for things like the SCRUM 
tool, which is partially why I couldn't complete the roadmap. It's 
probably fair to say that the styles currently present in the style 
browser will be completed by RM Asset, but that may change.


What I imagine is that some of these styles that I mentioned will 
be comprehensive, long running separate, autonomous projects. A style 
like graph will need a ton of features, possibly separated into substyles 
and it would hopefully not depend on anything, but low-level features 
in the GUI system. Someone like Maxim could do this as he knows how 
to do high performance graphics. A windowing system can also be run 
as a separate project. Each project could be immediately stored on 
github.


RM Asset can do everything ourselves, but in the end, this will just 
take much, much longer, perhaps an additional year, which affects 
everyone interested in the GUI.

We follow a very simple strategy: We develop what we need, step-by-step 
and immediatly use it. So, we are not going to develop anything that 
we might need later at the moment. And, we are not first developing 
all styles, add a ton of features and than do our apps. We develop 
the styles just to the point where we can use them and than stop 
untill we need more.

Henve, you all can wait and see what styles we will do. If you can 
make use of them too, good. If not, sorry.

Of course there will be some changes to the basic concepts, and new 
concepts will be done when we need them.

This might have side-effects of already build styles. We will update 
our needed styles.

In the beginning the chances are high, that the general & common 
styles that everyone needs are done because we need them too. As 
time passes, we will have a stable set of styles, that will cover 
90% of every app we will do. The remaining 10% well be done on-demand, 
project by project.

So, what Henrik did was to state those styles, we will definetly 
not work on at the moment.

And, I don't see a problem if we have 2-3 different implementaitons 
of the same style. First, the code can be merged, we all learn more 
which patterns are good for style development and the whole GUI will 
be much better challanged from different POVs.

That makes absolutly sense ....

Release the docs asap then, so that other have more than just source 
codes to study from ...

We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

Oldes  thank you for quoting me outside it's contexte to serve your 
purpose that quote is  a reply to Kaj proposition to do my own R3-GUI.

You are welcome, I was just trying to move your chat to appropriete 
channel (not "tech news"). Sorry that I missed your sentence has 
bigger context.

this quote implies any comunity work have to be based on a first 
step which seek the compromised best solution... which fundamental 
step wasn't done with the R3/GUI since their purpose is not to manage 
a  compromised vision of  R3/GUI edicted by the community but it's 
just to implement on top of the design edicted by Carl. In the actual 
design the least I can says is that you will need at least to do 
the work three time to support Win32API , X11 API and Quartz API.. 
+  any other windowed api. Knowing you are only 5 guys in RMA is 
it stupid to notice that and from this try to get the better solution 
the one that will give you best chance of success ?

the point here is the dialect edicted by carl can be adapted to any 
other library so why not considere taking a library already ported 
to the 3 main OS. Wich we would have the full sourcing and the would 
even in a shrinked version of it to save us the pain to do X times 
the work X being the number of  OS we want the R3/GUI on ...  and 
this  will too avoid us compatibility issues...

And I thoght the reason why we make gui in REBOL is not to need different 
gui for each system. I totaly don't understand your toughts.

do for a R3/GUI we need the whole GTK+ or the Whole QT ? first of 
all lest analyse the way R3/GUI interface to win32 API it doesn't 
use that whole api specification it's limited to the ground management 
and rendering fonctions.

Oldes you play dumb ?

No... I really don't understand you.. or I miss something.. there 
is someone working on native guis?

oldes Rebol GUI is just an interface on top of  your local system 
windows management  API.

you have you windows manager API (win32, X11, Quartz)  then a brigde 
called the dialect that will parse your rebol files commands imputs 
and translate them to signal and calls to trigger the proper data/ 
functions calls to your window manager API

Are we talking about same GUI? What I know Rebol gui does not use 
any native api and there is nobody I know working on it.

so yes the goal seeked is for the rebol programer to have a transparent 
and portable API in rebol to make graphical user interface. But on 
the ground level you need to adapt the C code to your OS window management 
solution... With some specific tweaks for example on linux you are 
not obligated to have X11 started so you linux rebol/view -hostkif 
R3/GUI- have to detect if the X11 server is run and if it will be 
able to display things or warn you it can't

sorry to contradict you oldes but can you explain me what is that 
?  taken from r3-hostkit/Sources/src/os/win32/host-windows.c

// Create the window:
	window = CreateWindowEx(
		WS_EX_WINDOWEDGE,
		Window_Class_Name,
		title,
		options,
		x, y, w, h,
		parent,
		NULL, App_Instance, NULL
	);

same file at the begining #include <windows.h>

this looks to me like a lot of call to the win32 API  OLDES  !!!!

my point is instead of having to do this interface 3 times for windows, 
linux, macOS X  why not  take the time to discuss the probability 
to do it with another library that could be use as it  on the 3 main 
OS ...

that's window... that's not eaqul to gui for me.. and I really don't 
understand what's the point.

of course you must do this for each OS, there is nothing like only 
one solution.

Oldes that's because you are not aware that all your R3/GUI calls 
need to be displayed on your screen  and that rebol doesn't handle 
that part ? and that the same for the mouse / keyboard events...

you display just what you draw using any graphic lib, like AGG at 
this moment.

oldes there is .... using GTK QT or wxwindows or even glut... or 
any other library that is already ported to those 3 OS and there 
is alot...

sorry I give up.. why I would like to use something like old GLUT 
just to display empty window?

but as R3GUI only need the basic fonctions of those API and not their 
whole thing  then adding them full seems dumb ...until you considere 
the runtime libraries of those libraries are already integrated by 
default in linux...

win32 api is older :)

lol that point is just bumb justification to a bad choice oldes ... 
anyway not you are me will take any decision here since the project 
isn't in our hands