AltME groups: search

Cyphre - re RMA Asset's hostkit release - is also exe distro updated?

Cyphre, the freetype issue, is this useful to steve solie? If so, 
he should be notified immediately.

Cyphre, ok

Steeve - and where's your REBOL clone? Nowadays it seems all REBOL 
gurus are coming with one. Should I expect Ladislav and Cyphre enter 
the game? :-)

Cyphre has his JIT thing, but am not sure how far he has come with 
it.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Can't wait for when we get back to GUI :-) Hopefully Carl is back 
to Host Kit soon, so that View will be adapted to command! interface, 
and its source released, in order for Cyphre to proceed ...

I agree with Max on this. Hopefully he'll get to start on those changes 
soon along with Cyphre.

cyphre unfortunatly  win32API is abandonned on vista and  seven (widows 
6 and 7) so the font rendering is not good look at the picture here 
that shows the differences

there is something regarding 'drop that may cause crashes. this will 
be fixed, when cyphre gets around to it.

Shadwolf, those are low level things, so Cyphre is the one to bash, 
if it doesn't work everywhere. :-) With any luck the R3 GUI shouldn't 
have any need for adapting to various OSes and hardware.

Cyphre, Henrik, Ladislav and I are going to pic up the current VID34 
code and drive it forward. Our goal is to get it into a shape that 
it can be used to build apps.


We will try to sync with Carl about our steps to avoid that we fork 
away. Overall we want to solve the current stuck situation and move 
forward.


Our goal is to make VID34 useable for big apps. Focus is neither 
minimalistic nor "can be used by a child". This will be for the big 
boys. But still simpe to use and providing a bunch of features you 
need to make enterprise applications.

IMHO, Henrik has stepped up as project manager for R3VID.  Cyphre 
is still interested in helping out on the low-level AGG AFAIK.   
Others, like me, will definitely chime-in when it starts being more 
organized, if only to implement Styles, themes and stuff like that.


But we need the next host released... and AFAICT, that is one of 
the main projects of Carl right now.  At least, I hope it is.

probably very preliminary, but could this be kind of the design we 
are heading for? Looks clean, simple, yet nice enough. IIRC Cyphre 
used similar theming (blueish) for his styles-pack:


http://www.zive.cz/ShowArticleImages.aspx?id_file=423472159&article=141664

good to hear Carl is documenting his ideas for the GUI. Is Cyphre 
already doing some low-level work? :-) Is there actually any priority 
for low level work? E.g. unicode display, better cross-platform font 
handling, draw improvements, transparent top windows, etc.?

Cyphre is down with the flu right now and a sporadic internet connection 
due to snow, so I have no immediate status of what he's doing, other 
than waiting for the host kit, but what he's shown me, based on a 
separate AGG build, shows that there are a lot of ideas for what 
to do.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

Cyphre - are you sure?

Cyphre, I'm not sure if this is relevant, but timers under OSX are 
currently broken, so wait will eat CPU no matter what the wait period 
is. Maybe something broke in the last few versions?

cyphre, your system is similar to the R2 globs engine in spirit.

Cyphre - do you understand, what Max wants? And for us dumb - would 
it be a benefit, to have "draw elements"? :-)

Max - try to define simple usage case, and possible syntax, so that 
Cyphre can see, how your aproach differs, because it seems to me, 
that with few enhancements Cyphre outlined above, Cyphre thinks current 
implementation can already do what you are asking for ...

I think that Cyphre just tries to understand your aproach, nothing 
more, and that he is really open to any ideas ...

Steeve, but were you succesfull to use this technique in real world 
case? I tried to use it for the DRAW demo but it doesn't work well.

Try: do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes-2.r


-try to move mouse over the window..you should see quick 'MOVE'  
events  eing logged in the console

-if you select any object using the mouse the loop is starting to 
do something usefull and from that time I could get only about 3 
MOVE events per second which is very slow. To me it looks like the 
event port blocks during execution of the code inside the WAKE handler.

But if I use the same code inside FOREVER+WAIT cycle the events are 
comming much more frequently.

(Using time events)

Cyphre, By reducing the number of objets to draw (10 objects) I have 
a really smouth animation taking less than 2% of UC when an object 
is rotating, and growing to 20% maximum when the object is actually 
moving.
Meaning your clipping technic has a  low effect on perfs.

Sorry, Cyphre, not Henrik

It is still a very silly way to do what Cyphre is doing, more consistently, 
by just using a FOREVER loop with WAIT.

tabs: we already are able to switch between panels and need a button 
panel for doing this.
grid: big job and cyphre has already volunteered. :-)

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.

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

Well, it will allow Cyphre (or others) to work on View kernel. But 
as for VID, the work could continue in theory even without the above 
mentioned work?

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

Cyphre is looking into it. The box model may use some enhancements.

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.

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.

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.

Cyphre is working on this, yes.

the box model Cyphre is working on is unlike R2View, it's more similar 
to CSS.

hmm, those are low level changes, so Cyphre is doing it his own code 
branch, or does he have code synced with Carl?

render - well, there are different ways to do it, you must ask Cyphre 
how exactly he's going to it.

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

resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).

Wow, if you and Cyphre almost gave up...

@Gregg:  when I imagine Ladislav and Cyphre working like that on 
code, I picture a slow motion movie scene with epic music  thumping 
in the background, lots of dramatic cuts between close up face shots, 
etc...

Resizing prototype working well, both Cyphre and I like it.

Posted 5 shots:

http://rebol.hmkdesign.dk/files/r3/gui/212.png


from 212 to 216. I think they need some explanation from either Ladislav 
or Cyphre.

Thanks to Ladislav and Cyphre.

(Cyphre was pretty sure, it was not possible)

I am not asking about the math - I trust you and Cyphre to make the 
math absolutely perfect. I am at the moment asking about the semantics 
of the resize model

Cyphre ... do you know the answer to my question?

Cyphre, is the layout framework pluggable in any way? Could it be 
replaced with a different model? I'm just thinking how layouts are 
done in Java where there are quite a few different layout managers 
available and one size doesn't have to fit all. Here are some options:


http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

http://rebol.hmkdesign.dk/files/r3/gui/220.png


220 to 225 shows the resize engine in use with globally set borders 
with quite good pixel accuracy. the border style should be possible 
to set globally according to cyphre in a similar way as in VID, of 
course without the artistic limitations of VID.

twitter: Successful branch: Cyphre can do R3 builds now, including 
native graphics extension module.

some refinements to the resizing model, by ladislav and cyphre as 
well as some documentation, so I can learn how it works. no new demos 
at this time.

Steeve, Cyphre probably understands that better than me, but I assume 
this means some level of hardware acceleration possibility of DRAW 
transformations. :-)

Steeve, ignore me. I just don't understand your original statement. 
Cyphre would understand it. :-)

Steeve, but this is still Cyphre territory :-)

- Cyphre is implementing remaining DRAW commands in hostkit.
- Ladislav has been working on resize code for a bit

- I'm studying whether it's possible to replace arguments for reactors, 
an esoteric, but necessary part of dialogs.

Regarding the names: Cyphre thought, that the "table" name should 
be reserved for something even more "specialized"

small status update:


Not much happening on the release/testing side. Bolek found a nasty 
bug in MAKE-FACE, causing FACETS to be lost. Cyphre and Ladislav 
continue to work on resizing and Bolek is working on styles. When 
the styles are properly adapted to the new resizng scheme, I can 
test the new dialogs properly.

And Cyphre is working on the richt-text part to work with the new-hostkit.

not yet, but I know Bolek and Cyphre are working hard in the background 
to complete the resizing system.

sure:


Robert - DB interface, messaging, state machine, cracking the whip
Cyphre - Resizing, low level AGG, rich text, host kit interface

Me - Dialogs, form validation, database interface, reactors, messaging, 
state machine help system
Bolek - Styles, resizing
Ladislav - Resizing, state machine


The above is basically what needs to be done for the first customer 
app.

I just hat a short chat with Cyphre about this. And on Windows & 
Linux the glyph outlines are used to render the fonts.

Cyphre hasn't talked about that, but that is probably next. I don't 
know exactly how many parts are left.

cyphre... seems like the best plan, for the best quality font rendering 
on any platform  :-)

Cyphre - what's next on your part? Effect pipeline?

bounty: This won't cover the total-costs, but it's an additional 
sponsoring from the community that Cyphre can work on it.

Graham: regarding the 'updating GUI from network protocol' question

I have found some older scripts I did and quickly added the progressbar 
to it so you should see how it works.
You can download it from here:
http://www.rebol.cz/cyphre/scripts/r3/net/client.r3
and
http://www.rebol.cz/cyphre/scripts/r3/net/server.r3


just run server and client on localhost and press enter in the client 
console to see how the server shows the progress of upload.

Cyphre, the server link gives a 404

yes - still not solved problem of occassional wrong path dispatch 
of Apache in ClearOS :-(   .... Cyphre, you better put it directly 
onto rebol.cz domain ....

I think that's what Cyphre also argues .. to use a transform

Sorry, you lost me at "inherit". I'll have to let Cyphre chime in 
from this point.

again, I'd have to look at the AGG rasterizing pipeline to see how 
it functions, but the only procedural overhead is in how it inherits 
its origin at each gob.   


it might even be impossible from the get-go, based on how the actual 
rasterization is performed.  


in Flash this would be impossible.  but IIRC past discussions with 
Cyphre, we use a different rasterizing process, which would allow 
the whole idea.

And with that added option, how simple is it to check the gobs to 
make sure the option isn't specified? Multiply that answer by the 
number of times that check would need to be added to code. That is 
why you lost me at "inherit". But if you can convince Carl and Cyphre, 
go for it.

Cyphre, I agree; it's already so easy to flip the y-axis in REBOL.

Cyphre and other :  LOL so it's all about monney ... your are a bunch 
of liars and pretenders ...  and you think how much it will take 
to get  R3 done ? Even if i give you ten thousand dollars i'm absolutly 
sure rebol will remain your last priority ...

Cyphre, you GUI update inside a network looks similar to what I did 
... but which didn't work!  Ok, time for me to try again.

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

Cyphre has been out of town for the past week and has not yet reported 
back on his progress, and he's also focusing on many host kit issues 
that need to be solved.

Steeve, that's a lowlevel bug that Cyphre wants to fix. it's in the 
queue.

Cyphre's and Ladislav's private queue

I get some leakage in the fields - strange chars .... IIRC someone 
already pointed out the issue, anc Cyphre suggested some solution 
- can't remember now ...

Cyphre says the bug is due to a missing box model. Will be fixed 
soon.

Robert - this is OK with me. In the past, I worked with Cyphre, Romano, 
to do personal testing ... lot's of errors and misconceptions caught 
on my side. In such early phase, I might cause a flood, so if you 
want, I might stop for few more releases ...

so - if anyone wants - Cyphre, Rebolek, I can test privately in early 
phase, and report privately too, to not cause much of the flood here 
.... or I can simply shut-up for a while :-)

the issue is set to be solved in this week's sprint, by cyphre, but 
we'll see if he makes it.

later, Cyphre will come up with some modifications to draw blocks 
for styles, so we can use positional keywords that work together 
with the box model, so it becomes easier to create draw blocks.

Small status update:


Cyphre has completed first version with keywords for draw blocks. 
This means you can now use the vertices of the box model for coordinates, 
instead of tediously calculating them inside the draw block.

http://94.145.78.91/files/r3/gui/240.png

metrics: I'm not sure what's being considered here. Cyphre may have 
something in the works.

OK, I can test personally. In the past I worked privately for Romano, 
Cyphre. We can concentrate upon some more concrete stuff. You can 
say just few points, like - new area, please test. And I will do. 
Recently Henrik releases new version without telling what has changes, 
just 21KB was added :-) That is really difficult to estimate what 
changes should be tested :-)

I just think that the work is running in multiple levels (native 
- Cyphre, styles - Rebolek, high-level - Henrik), and at some point 
in time, it will all settle down and merge together ...

Aha, sorry, I guess, that I did not read the latest questions from 
Bolek/Cyphre

Bolek +1 - Don't use GRID for these names, unless we call it a canonical-grid. 


Christian, I thought of across/below as well, but understand Cyphre's 
reasoning.

Panel 1

 or "group 2" give little meaning to the numbers. H and V prefixes 
 make things clear, but...


groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.
 


What are the use cases for each style? Is it accurate to say that 
PANEL is for cases where you want things neatly aligned, and GROUP 
is for cases where alignment isn't important, and tighter positioning 
based on face size is desired?

Any other point of view, how Cyphre's code could be interpreted?

I've actually not used either, Pekr just asked for other interpretations 
- and that's how I first read Cyphre's code.


Pekr:  Elements divided by number, rounded up (with final column 
simply containing the remainder) is how I would do it...

well, I thought we should really have a native for this ....  where's 
Cyphre's JIT compiler??

This does it without using a temporary word....and it should work 
even if the counter name is not amenable to Cyphre's path notation 
(ie you are using something more exotic that strings for counter 
ids, or are using an older version of /Core).
   b:  next find/skip head b "a" 2 b b/1: b/1 + 1
Just remember to reset ....
   b: head b
....once in a while:)