AltME groups: search

So this is for group (us) to consider, and for Cyphre to implement? 
:-)

TRANSLATE is for Cyphre to consider. The rest is me and everyone 
else.

But generally said - we are still waiting for Carl to move View to 
command! interface and releasing the sources? Carl almost finished 
GUI docs, which is nice, but I still miss one doc - his pov on - 
where to go next - still some concept descriptions missing, e.g. 
his plan for layers, etc.

Yes, some things are a little odd in this respect: the docs state 
functions that don't exist, such as MAKE-REACTORS, but he hasn't 
said anything about whether he's modifying the sources. Once the 
View host gets released, many more people can work on their things.


For us, there are plenty of things to work on: Begin the implementation 
of a proper table, better dialogs and more styles.

those things you mention (more styles) can be done even in recent 
VID state? Do you regard architecture being stable? E.g. - I remember 
you (and me too) did not like max-size. But it is basis of Carl's 
resizing model calculation. So no fear of later changes on your side?

Playing with R3 GUI...I see panels and groups resize horizontally 
but is there a way to get it to resize vertically...or does that 
involve playing with the style code?

you, BrianH, and me :-)

but I am a lamer, not a coder, so I can only bug you with many questions, 
and point out some things I eventually don't like (and in many case 
I don't like them because of my wrong understanding of the topic 
:-)

What I did not like in the past was departure from multiple gob design 
and make-gobs, and limiting style to single draw block. But later 
on BrianH explained to me, that the design is ready to use multiple 
draw blocks (kind of original frames concept)

where my "experience" ends is event - mainly keyboard, editing. Rather 
difficult topic for me. So I am still eager to see, how keyboard 
navigation is going to be supported. This is BIG topic for me. Because 
as I already said in the past - users are forgiving non-platform 
specific look, but not behaviour. And I am a person using keyboard 
so much. So tabbing, accelerator keys, ability to swith tabs by ctrl+ 
tab (non trappable by REBOL at all) etc. - those things were not 
adressed yet ...

Well, the keyboard navigation in the VID Extension Kit is a much 
bigger hack than in the R3 GUI. That's thanks to a good design and 
treating the window itself as a style. There are still some issues 
with Carl's method of tab navigation colliding with mine. Carl has 
a tendency to work functionality that should be generic into a few 
specific styles. I don't really get why he does that, because it 
scales like crap.

So - there are still some design choices to make. And what I miss 
is discussion about those topic, unless we go too far, to later realise, 
we have to rebuild somehing because of new ideas ...

who has read the whole source code for the R3 GUI?

 ... I have, and my gut feeling is it could be made simpler without 
 much loss of functionality ... it just feels too "denormalized". 
 That's not intended as a criticism, but a statement of [my] preference.

( and on tooltip using AGG some cool effect can be done there ... 
 ( like a progressive fade away in time) )

widgets should be organised in my opinion in 2 categories the first 
one are the "most used ones" not every one will put a tree view or 
a menu in his main windows but everyone will put  labels fields and 
buttons to most of their applications

the second categories countains the set of high level widget wich 
include a lot of time of  developement and though about how to give 
them flexibilities and extensibilities  not to end with a list-view 
widget that is able to display nothing but text like in R2.  Those 
widgets and widget set should be able to evolve in time and ofcourse 
without impling a redistribution of the complete R3 view stuff.exe

i liked pretty much the idea of an advanced high end side widget 
library like REBGUI . It evolved so much faster than View in  last 
years. and the result is nothing to deal with the rough aspect of 
the basic VID

for example in viva-rebol.r project advanced side widgets take 95% 
of the source code lines writen ( and i compressed some of them) 
OK viva-rebol involve a new way to deal with text in an extensive 
and heavy way okay but still a hudge part of this project are nothing 
but one time used widget and that's a true waste!

Shadwolf - why don't you just read new VID3.4 docs? It is clear new 
VID does support creation of advanced styles, and IIRC Cyphre will 
do grid (table) widget for R3 ....

And you don't like the technic using masks ?

in photoshop, its like using the eraser to remove parts of a layer 
and reveal the bg. 


 what you say, looks more like adding a layer with a hole in it.  
 Do I understand your idea properly?

is that more obvious?

the next project must use R3 and the GUI, so the work starts there 
again

Maybe Lotus notes is looking good now, Maybe.... 

But I had so many bad experiences with that crappy app, in the past.
No respect of the GUI santards. (F5 to quit).
No drag and drop.
Lof of useless confirmation boxes.
Useful actions hidden in deepest menus I ever seen.
etc...
It was a pain in the ass just to write a simple e-mail.

And slow, so slow

E.g. browsers solve this by allowing to open tabs in their own windows 
and putting windows back into tabs.

Henrik - will your site with screenshots become available again? 
.... and ... should we await some new creations in upcoming weeks?

Screenshots will be available when there is something to show. Worked 
out a few bugs regarding tab navigation yesterday and there is work 
being done on the basis for a grid system that will be used for tables, 
dropdowns, menus, etc. Someone has been added to the list of developers, 
as I don't have much time right now to do GUI work. He may speak 
up if he wants to. :-)

I just wish one thing - things to not add layers of complexity. The 
initial VID work was imo really nice, and I hope it will not complicate 
much ...

Depending on what will be worked on next, we might delve into testing 
schemes. We want the R3 GUI to be easily testable: Fire random events 
at a GUI window and collect errors and crashes and also generally 
record and playback UI events to tell what a user did.

And what about menu? How is this being done? I mean - pop-ups? Carl 
still have not expressed, what he had in mind for layers, or did 
he?

That someone is me and in this exact minute I just finished auto-completition 
for the text-list. Yea! :)

We are currently checking out how far we can get and what stumbling-blocks 
we might hit to collect some experience.

Goal is to create all internal tools with R3 now (we call them Level-2 
= L2 tools) and build the Level-3 (libs, frameworks, extensions, 
...) in parallel.

Is it by any chance planned to add HTML rendering to R3, maybe as 
an extension? (probably not but I'm going to ask anyhow because I'm 
horribly rude) There are some cool apps that mix native GUI widgets 
with HTML content, gitx for example. Would be neat to do this with 
Rebol too. And I'm sure, often enough an app you write is going to 
offer export as HTML, being able to show a preview of the output 
while you are editing the data adds a nice touch to an app.

I tried to look at webkit and its pretty daunting.  the api also 
isn't documented at all...

I wanted to sarcastically write that it's probably documented in 
small tidbits on one of the commiters' blogs but then I checked and 
that's really where some of the docs are.

python has a non console mode binary and it crashes if any stray 
print is performed...

dunno about HTML5 Canvas, but browsers contain SVG, and there were 
some attempts to do REBOL-2-SVG converters. There was some incompatibility 
in how gradients are specified, but that could be added to our kernel. 
I am sure Cyphre has more to say here ...

I prefer tea :) Also right now I'm investigating password style and 
then will move to tabs.

Henrik - is there any resolution to resizing system? I know that 
we both objected to max-size element for e.g., and IIRC there were 
some proposals of how to either fix current model, or replace it 
with different one. Have you made any decisions in that regard yet?

didec windows console is boring and ugly now that i show agg could 
deal  pretty stuffs with text in color why don't we HTMLize our console 
and bring some new way to experience console direct code flow coding 
cause that was the strong point of R2 and that's the actual weak 
point of r3

help or a way to start step by step evaluation or stop it   and a 
way to look at your data stacks or organisation like in anamonitor 
.. this advanced  console then  could be done in view dialect and 
be a show room to the view dialect capabilities

all those years i sharpen my own way  to code in rebol in a more 
professional way ... and that was done basing my self  on the few 
spare tools the rebolers bring  but it would be nice to have this 
effort through years continuated to show that the rought aspect of 
rebol evolved alot ans that now all you really need to do rebol is 
rebol and i think we all shown that in rebol light weight wasn't 
synonimous of  poor ideas oe small capabilities*

one of my dream regarding the developement of applications in rebol 
was to have a way to select a bunch of your code in your text editor 
and hit run by step  to see a step by step excution of that bunch 
of code  in  order to underfstand what rebol is doing closely when 
he clone data  h

personaly one of the hardest part in rebol is the memory management 
and maybe that's part of the reason i don't understand the way parse 
works

Pekr about you gui library 2 comments yes it has all the widgets 
i expect and so much blue are you sure ?

gram for tab panels they shopuld be able to stick together in line 
when needed and show one content at a time  and able to be extracted 
from the line to exists in their own lonely window like it's done 
in most of webbrowser now inh days

Shadwold - I don't understand what are you asking, but if you are 
asking if I like mild bleu gui, then I have to say - yes. I am bored 
by old Amiga and NeXTStep grey look - Fedora, Vista, Windows 7, FaceBook 
login-page, all got it right ...

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

Pekr, you need traversal code to move back and forth relatively in 
the tree.

No, because every GUI style can load/save itself. Such emitters just 
need to be done once. Every gui element belongs to a record. So, 
it's easy to say: save customer and that's it.

Yes, we are doing the first basic styles to create our internal apps 
we need. As soon as this is stable and proofed to be useable, we 
will release the GUI lib.

We take VID34 AS-IS and patch the code-base. So it's easy to find 
the differences. Most things we try to add non-intrusive. So you 
load an additional file and get new functionality.


The styles are all "self-contained". If Carl wants it can all be 
integrated into VID.

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issue

 - actually no, they should not be that, and this is quite a misconception 
 that you want this level of control in most apps.


It's what prevents us from creating complex forms in minutes, where 
you don't have to think much about how the form interacts with a 
database.


When you think of it, most of the code you write, when writing boring 
business apps, and beyond writing styles, is writing, and worse: 
debugging and testing such code. Wouldn't it be nice to have this 
built into the GUI, all debugged and tested for you?

It would be really good to get Carl cooperating
 - yes it would be. And you probably know how to do it? ;)

what Robert describes also sounds like something they could easily 
adapt to have a web viewer for.   a bit like a .net approach where 
you can build tools and distribute them in different architectures, 
suiting client needs.

Persistent GUI state will allow an application to save its state, 
be suspended or shut down, and be restored later, all automatically 
in response to system events. Windows 7, Androis and iPhone OS 4.0 
all have facilities for triggering this kind of event in applications 
in response to power management or (for Windows 7) reboots. This 
will make it possible for us to write REBOL apps that will resume 
after an intentional shutdown by the system.

Basically, if all your apps support this then it will be safe to 
turn on Automatic Updates and let your computer reboot itself if 
necessary, at least on Windows 7 (and maybe Vista).

Brian, yep, exactly. And it's not only about suspension. Think about 
logging of at one system and again on at an other while taking over 
your app session and GUI state on this system to continue your work.

Pekr but it's blue and blue drives me more crazy than i'm already 
...

gray is just the color that hurt monitors and eyes the less .... 
 i hate white on my screen it burns my eyes so much..

And Carl could release a beta, It's a nice opening

IMO this could be doen by using different actors and reactors based 
on platform ID. Either it's all included or pre-processed. Maybe 
it's even possible to load a module with all the actors and reactors 
for the specific platform.

james, it may be that you are running a98 or a99. the GUI will currently 
only run on a97 and below.

Yes, well, currently I need to finish another project, so GUI development 
could be faster, but Cyphre and Rebolek are working on it. At least 
it's moving. Proper resizing is the topic now.

was a fix for size-text in R3 ever done?  IIRC 97 and below returned 
incorrect width values

the developer states that his technique gives better results than 
Cairo and AGG

... and even more deeply ... the world goes HTML5, what do we do 
about it? :-) (I know there is still place where R3/GUI will be usefull)

as for the question re. HTML5, I'm not sure what the solution could 
be - maybe an embedded Webkit and a REBOL graphics dialect that generates 
JS?

and HTML markup, of course

Maybe there could be an alternative graphics framework at some point 
that could include WebKit modified to allow for the embedded browser's 
renderer to execute both JS and a REBOL dialect, the value of REBOL 
could become evident by way of conciseness, integration with full 
REBOL (and all the benefits that would bring).

The morphic AA looks nicer though I wouldn't see any big difference 
if the pictures were shown separately to me. Also I haven't found 
any details..just couple of screenshot comparions with Inkscape. 
The author is not mentioning a word about preformance etc. As Pekr 
said AGG have already good quality and imo there will be 'slight' 
visual difference between Morphic unless you start comparing pixels.

Also don't forget there is not only antialiasing in play. AGG uses 
very vell written vector graphic 'framework' packed with features. 
All the new algorithms presented in recent years are still missing 
that part.

But I agree. If Morphic(or whatever else) will offer faster&better 
quality AA it should be possible to write custom rasterizer/renderer 
module(simmilar as the special Flash rasterizer) so it can be used 
inside AGG framework.

here's the thread where he announces the new project and he mentions 
performance to some degree:


http://forum.world.st/The-Morphic-3-project-td2239971.html#a2239971

re HTML5, JS vs Rebol etc. I personally don't want to use Rebol instead 
of JS in a browser. It would just make me feel Rebol is crap :). 
The problem is not in the language (JS is not so bad imo) but in 
the (X)HTML/CSS/DOM design and implementation. That's the real source 
of almost all the Web dev frustration IMHO.

we don't notice detail as much in image drawing, but in graphics 
and slow moving pictures, AA is a killer

in GLASS I had to take AA off in some text sizes for the font I am 
using.   some letters looked bold and some didn't.  On some letters 
with round corders (like S, g, D) the AA changes the width of the 
line so much its annoying to read.

isn't cleartype patented and illegal to use in USA unless we have 
a license from MS?

AdrianS: I don't think you can convert the Web people to Rebol easily 
just by replacing the JS in a browser. Better to build some 'cool' 
product based on Rebol with modular interface so people can play 
with it and build own 'gadgets' using dialects etc. I believe there 
are still some 'oportunities' to do it on misc embedded systems but 
first you need HostKit source and fully abstracted Rebol dll versions 
compiled for such systems.

people are also impressed when I build a parse dialect in ten lines 
in 5 minutes and show them that its actually spitting new structured 
data out of other data.

I don't mean the actual framework code, but the code that defines 
the UI and interaction for a specific application.

when we'll have a webkit REBOL plugin, then I (and hopefull others) 
will be able to do a real-time web dev software using the remark 
framework.

it might actually be easier to look at the chrome source code and 
starting from there!

Hosting Webkit wouldn't help here: The whole point to HTML5 etc. 
acceptance is that people don't have to install another program - 
they can just use their existing web browser. Hosting Webkit would 
only help us if we want to display existing web browser code; it 
wouldn't be necessary for generating code to run in Webkit, because 
the copy of Webkit that people would be displaying your GUI in would 
usually be a separate program, often on a separate computer. And 
HTML/JS/CSS is just text - we can generate text already.

Native Client would be an interesting way to get REBOL into a browser, 
particularly once they get the portable version up and running :)

that's what I mean... but it also means that we could build nice 
web dev tools using R3, which could cross-compile as desktop and 
web apps.

Small status update:


Working on resizing now, particularly proper pixel accuracy and getting 
rid of all blocks. Ladislav and Cyphre are working on a good algorithm 
here.


This will also create a change in how styles draw gobs: Currently 
a gob defines mostly only the draw area of a face and then spaces 
between gobs are used to create paddings. This is efficient, but 
it makes drawing things outside a button, like blurred shadows very 
difficult. So instead, the gob now constitutes both the drawn button 
and its padding. A side effect is that spacings between gobs are 
now always pixel accurate, because they now rely on the draw block, 
rather than the resizing engine.

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons. But perhaps this can be automated, don't know yet.


Furthermore, there will be keywords available for DRAW blocks to 
easily locate a corner or a center of the draw block.


Overall, these things will make it much easier to write draw blocks 
for styles.

IT seems god, but in the same time, i'm not sure I like this "clipping 
area" of events thing.

A "silly" idea : could use one gob for the drawing, and another one 
in front of it clipped to the "usable" size for the event tracking 
!?

Cyphre has a good idea on how to do this, and it probably involves 
an extra gob. As a side effect, it might be possible to define a 
bitmap mask to get pixel precision accuracy for click events.

yep, the low-level engine over which glass is done.


I was confirming that its a good and simple way to go forward for 
R3 too.

the gob size is supposed to be nice like in 210, but the border moves 
in and out randomly per side per gob.

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons.

  ..... I am not sure I can understan, how it is done. Is another gob 
  used to define click-area?. Carl reduced VID to one-style = one-gob, 
  and it was clear it can't work for more complex style, you had to 
  "switch" drawblocks anyway. Now if I understand it correctly, we 
  are back to kind of  "border" aspect of R2? 


I still liked maybe more complex but also more flexible way of Gab's 
VID, where one style was compound of more gobs, if needed ....

Pekr, after working with multiple GOBs for a single face, I think 
it's simply easier to just work with one GOB and a set of draw blocks 
on top of it. Otherwise you get many small parts.

You render all visible faces to a bitmap. Each face has different 
color. The you just read mouse coordinates and do a PICK on the bitmap. 
That way you know exactly where the event should end. That's the 
bitmap mask.

sorry for so many questions ... I am just interested :-) I hope more 
guys gets interested too, and even join the testing phase and style 
creation process :-)

What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.

Also - with the change to the "box model" and introduction of "material" 
system, will it be any easier to adapt the overall GUI look?

Not yet. Carl has entered the resizing discussion and there is not 
yet an outcome.

Resize system has been worked intensely on by Ladislav and Cyphre 
for the past few days.

hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)

I expect your world being private one right? No web-public output 
at least, so that we can at least passively read some discussions, 
and kind of "influence" it from here? :-)