World: r3wp

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

First of all you should provide a doc how to stylize basic gui items 
like button, slider, etc.

Btw... the main problem I see is, that current R3 is not able load 
PNG24 image. If I would like to do own GUI, and or game in Rebol, 
I would like to use semitransparent images. (I know that there is 
a lot of people who don't like bitmaps, but I see bitmap usage useful). 
I can load any image to Rebol using ImageMagick, but that is not 
a way we want to go... IM is too large to be used as common Rebol 
way how to deal with basic images.

Good thing on embracing a superwindows concept. I've wanted that 
for many years

Just be careful to make it as simple as possible, because it's already 
a complex concept in itself

Kaj, yes that is correct. My own idea is to simply have behavioral 
variants of ordinary windows with slightly different keyboard navigation. 
With any luck, it can also be usable as a generic window manager 
for a general desktop. Each style can present its own layout mechanism, 
and I expect that the window management style simply provides that.

Oldes, I suppose PNG24 loading are done with media loaders/types 
(?). We need Carl to finish those, but those are not as high priority 
yet for the apps that RM Asset are building. Perhaps they will be.

I know... I just do what I can.. to point out that we are missing 
something, what I consider as a basic functionality.. http://issue.cc/r3/1812

We cannot expect many people starting to use R3 View when they will 
not be able to load basic image.

But the missing doc for the gui is also big issue for me (but it 
was already promised by Cyphre to provide it)

I think this is on its way. It's very much needed.

We will provide a developer guide for styles to get you started and 
some styles are included in the current release as well.

The thing is, the more speed we gain, the faster all this stuff will 
become useable by all of us. And, it's the necessary basics that 
need to be done to make R3 useable for GUI development.

And don't forget to make builds for platforms other than Windows 
available as well.

Yep, we will do as well. OSX and than Linux.

New http://94.145.78.91/files/r3/gui/r3-gui-src.zip


This one seems not to be as stable with the tests, and the style 
browser won't run, but offering it anyway.

The old version from 24-dec-2010 for diff is available at:

http://94.145.78.91/files/r3/gui/r3-gui-src-002.zip

Henrik, could you start a page on DocBase with you plan for R3GUI. 
It will soon be lost if it remain on AltME.

Also - there was plan to release docs, could those be placed somewhere 
too?

if ready, of course ...

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.

First of all you should sync the host-kit imho.

I've requested it (not my decision).

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.

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.]

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.

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:/

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.

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.

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.

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

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 ...

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.

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 
....

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.

More epic than Unicode?

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.

As always things seem simpler when you look from the outside...

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....

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 
...

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.