r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Henrik
2-Jan-2011
[4908]
Plan: The plan at first is to prioritize what styles mentioned above 
should be written first. It's not a complex roadmap.


Docs: will have to update the status on those, but some are available 
in the r3-gui-src.zip file.
Oldes
2-Jan-2011
[4909]
First of all you should sync the host-kit imho.
Henrik
2-Jan-2011
[4910]
I've requested it (not my decision).
BrianH
2-Jan-2011
[4911]
The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.
Oldes
2-Jan-2011
[4912x3]
As I can see it, the Carl's A110 is very different from RM's version... 
you can even display image gob in Carl's version.
(can = cannot)
[I also wish Cyphre could comment his code... so far he was probably 
the only one who was reading it, but we should change it if we want 
go faster.]
BrianH
2-Jan-2011
[4915]
Right. Carl has been focusing on core issues for the last 3 releases, 
while the mostly unrelated GUI issues have been worked on by RMA. 
This was the best approach for 108-110, but we are due to make one 
of those checkpoints soon IMO.
Oldes
2-Jan-2011
[4916]
btw... many host-kit fixes are pretty easy if you know where to look... 
for example to enable image gobs in Carl's host-kit, one must just 
remove the temp_remove and replace:
	int gobw = GOB_CONTENT(gob)->size & 65535;
	int gobh = GOB_CONTENT(gob)->size >> 16;
to:
	int gobw = GOB_W(gob);
	int gobh = GOB_H(gob);

https://github.com/rebolsource/r3-hostkit/blob/4d3bdeaa77cf1ec7c5d97738509ecec4fdf4b7e7/src/agg/agg_compo.cpp#L594


And that's all... I really wonder why you keep the host-kit updates 
hidden. Even Carl was able to put it on github:/
Robert
2-Jan-2011
[4917x4]
We don't keep it hidden.
Carl is the one to release host-kits. He has full access to our code-base. 
As Brain said, from time-to-time RMA changes are merged.


IMO it doesn't make sense that we fork the host-kit and have two 
release in the wild.
We release a binary R3 with our stuff so that you all can use the 
RMA R3-GUI.
This is to let people directly use it without having to fiddle around 
with the host-kit.
Andreas
2-Jan-2011
[4921x2]
I don'tt see the harm in making your branch (and thereby, your changes) 
public.
No need to have "releases" or any of that, just putting up the source 
or a link to a repository would be fine.
Oldes
2-Jan-2011
[4923x2]
It makes sense... because I could save some time if I could work 
with your version or to be able make a diff between Carl's and yours.
And I was somehow thinking we want more than one man to fiddle with 
the host-kit... but maybe I'm wrong :) also we are probably almost 
out of topic here.. sorry for that.
Kaj
2-Jan-2011
[4925x2]
I have to say, it's gonna be pretty hard to port the GUI to other 
systems without the source
Carl challenged to port the graphics to OS X on Twitter, but that's 
fairly pointless in the current state
Pekr
2-Jan-2011
[4927x2]
Oldes - you should correctly name the problem - Carl imo did not 
touch r3 development for more than 2 months ...
... that is why nothing was merged ...
BrianH
2-Jan-2011
[4929]
And for a couple months or so before then he didn't touch the host 
kit or GUI. That is what "focusing on core development" means.
Pekr
2-Jan-2011
[4930]
BrianH: there is no need to "defend" Carl here. I don't need to speak 
in a way for anyone to feel comfort on not to feel comfort. Let's 
follow facts - no matter what HostKit allows us, there is still the 
need for Carl being involved. Oldes is right - repos should be merged, 
period, or it still feels like we are somehow blocked. Yes, RMA or 
anyone else can experiment at will, and this is cool about the HostKit 
indeed, but as you can see, some developers might get reluctant to 
waste their time, if repos are not merged for a long period of time 
....
BrianH
2-Jan-2011
[4931x2]
Not defending. We gotta do what we gotta do. I was there for a lot 
of the core development phase and involved with most of it, and it 
had almost nothing to do with the GUI or host kit. It was a major 
change that required a huge amount of work by Carl and me, probably 
the most extensive core change in the entire R3 project so far. We 
were glad that the GUI and host kit were being worked on separately 
so we could focus on this.
And by separately, I mean that even the GUI isn't really yet benefiting 
from the new module system. It's more than just syncing code.
Kaj
2-Jan-2011
[4933]
More epic than Unicode?
BrianH
2-Jan-2011
[4934]
Actually, yes. The Unicode changes had a lot of scope, but were still 
pretty shallow. The system structure was still the same. A107 was 
in many ways pretty similar to R2. We had planned for the A108 changes 
for two years, and a lot of the existing R3 code was written with 
that in mind, but to actually do it was a big deal. Plus, I've had 
to rewrite the module system from the ground up 3 times now, one 
of which took me 2 months and was never released publically.
GiuseppeC
2-Jan-2011
[4935]
As always things seem simpler when you look from the outside...
Henrik
3-Jan-2011
[4936]
Roadmap: Looks much harder to put together than I thought, due to 
varying stability/completeness issues with some basic styles. Will 
get back to this in a few weeks. In the meantime, releases of the 
GUI source will continue as normal. Cranking down the volume again....
Pekr
3-Jan-2011
[4937]
Are styles like tabs, grid, tree-view any close to release? Those 
are fundamental to any serious (mainly DB related) GUI developments 
.... I am asking, because I know that you kind of worked on something 
...
Henrik
3-Jan-2011
[4938]
There are many missing parts and a lot of bugfixes and changes that 
I know very little about, since I don't work with the lower level 
stuff. Some of the styles are already begun internally and it's possibly 
not a good idea to include them on the roadmap as community projects.

Also with the SCRUM tool, it probably needs to be finished, before 
we can tell what else is missing and that will not be a community 
project.


Each part mentioned above really needs to be done, but it was a lot 
less clear to me what exactly is ready in the GUI to do those things 
until some analysis today.
jocko
7-Jan-2011
[4939x2]
is not it possible to keep the compatibility with the Carl's demo 
and gui, which achieved a rather good level of usability up to A94, 
and which were rather well documented ? From this time, where alternative 
gui's were launched, we have nothing, apart from low level graphics 
programming, with almost no documentation.
My question is asked to the R3-GUI team and also to Carl
Ladislav
7-Jan-2011
[4941x3]
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
BrianH
7-Jan-2011
[4944]
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.
Oldes
7-Jan-2011
[4945]
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.
Henrik
7-Jan-2011
[4946]
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.
Pekr
7-Jan-2011
[4947x2]
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 ...
Henrik
7-Jan-2011
[4949]
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.
Pekr
7-Jan-2011
[4950]
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?
Henrik
7-Jan-2011
[4951]
they will of course be added as needed. that's the best way to do 
it.
Pekr
7-Jan-2011
[4952]
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?
Henrik
7-Jan-2011
[4953]
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.
Robert
7-Jan-2011
[4954x4]
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.