AltME groups: search

Henrik, I just think (in the contrary) that we could get back all 
the constructed vertices just before rasterization, in a plain rebol 
block.
So that we could output any format we want easly (PDF, PS)

Remember that AGG has a neat design. All stages are pipelined and 
it's easly to interrupt it at any step.

Fighting at too many fronts at the same time is not a good idea.

Rebol's run time memory far exceeds any savings we might get from 
a small library

There will be plenty of ability to print, but surely there are smarter 
ways to go about that than by bringing in a huge monolithic library 
like Cairo.

As said, size is not the issue, but managability. The issue is to 
keep uniformity as far outward as possible in the rebol core. If 
possible, keep win32 printing as a small mezz library, like DocKimbel 
has done for R2.

(size is a side effect of managability)

How big is Cairo lib? IIRC it was over 1MB? I agree with Robert - 
let's finish what we have. Let's see, what enhancements we can get 
in. AGG is still a cool library, being used by MANY projects. Just 
becuase Mozilla honchos could not do any better and choosed Cairo 
as mostly a political decision (because of author's involvement in 
the project) does not mean Cairo is any better ...


Apart from that, and as Robert says - in future, we can eventually 
replace it.

I agree with not switching right now, but I also think we need to 
consider the benefits and how we mgith get PS/PDF support. I've though 
DIsplay Postscript was a great idea since NeXT. And if there's a 
way, for those who want to include it, to add it as an extension, 
we don't impact the core.

but there is 2 things differents ... you have the dialect draw wich 
gives access to the insertion of  drawn shapes into a VID face and 
AGG is the engine can then beanything
....

can opengl be  used the same extends as AGG hum ... opengl have a 
heavy mechanics and that's not suited in my opinion for 2D fast over 
face rendering

the thing is draw and so agg can be used on any widget  componing 
VID and that's a hugde constraint

what really sux with opengl are those  half assed IHM interface i 
know glut, x and w32 extension that allows the opengl rendering engine 
to recive user

events and then display  on screen in the particular area set for 
it.


Those interfaces are not 1% as fun as VID... Vid is total flexibility. 
we never did that in vid be you can imagine heavy animation using 
draw dialect on any kind

of preset styled face. I think carl tryed to show that with the animated 
sliding widget when you open a window in his R3 GUI demo.

for me doing 2D using opengl always apeared to me as using a nuclear 
bomb to kill a single poor tiny cute ant ...(ok ant isn't cute...)

things like transparency could be handled a way faster using opengl

ofcourse the software speudo antialiasing  u can find in AGG is just 
 a joke compared to  X16 antialiasing buffers that can be found on 
now in dayx accelarting video cards.

but in agg you don't have  a proper way to handle fonts who wants 
to have flat texels to represent is document or hundreds of  png 
files in memory ... and that where glut and other extensions try 
to give solutions but the réalisaton is in général ugly.

but in opengl  you don't have  a proper way to handle fonts who wants 
to have flat texels to represent is document or hundreds of  png 
files in memory ... and that where glut and other extensions try 
to give solutions but the réalisaton is in général ugly.

one thing wich is really needed is the ability to have transparent 
windows no border no title no background ... a lot of things fun 
could be done once having that

graham in general when it starts with cairon or anothing context 
... that's a bad sign  i mean rebol doesnt formally mention that 
...

the draw context in a face is always there ... it's embeded in it 
no need to say HEY YOU KNOW WHAT  NOW WE WILL DO A SQUARE IN THIS 
WINDOWS AND PUT SOME CONTENT in it using some engine

that's a cool concept to séparated things and make a dedicated widget 
that handle this rendering style and wich is mixed with common other 
widgets

so things like super posing the regular widget properties of a VID 
face and some specific draw of  another specific rendering engine

but i can be wrong the cairo context is maybe just a transparent 
back grounded abstracted widget you can clip to any face

on a fonctionnality ground cairo have good point

it embed an SVG engine ( even if i'm sure a rebol / agg one blast 
it ) support of freefonts  support of png (but only this image format 
where rebol works with jpg etc...)

i mean you can trop opengl rendering in a file why not traping it 
to a image buffer and then display it

that make me think are bezier curves like thing  you set a curve 
shape and you can draw anything to shape it

having multi layers means you can then  multi thread the rendering 
1 layer per thread  this will enhance the complexity of what we can 
display on screen  (think about rendering a webpage or a pdf document 
for example)

carl said multi thread multi pipe multi core sux for a scripted language 
async process is better

well the fact is cpu are multi threaded multi cored and so are the 
graphic cards when you render a document  with AGG only that the 
freaking CPU that does the whole rendering work for God's sakes, 
it's like the computing on the 90's ... ok it's passed it's done 
it's deprecated and over now we have 650MHz GPU multi rendering pipelined 
and  multi threaded multi cored CPU over 2GHZ per core that's a lot 
of power and why would rebol be the only one not exploiting that 
... And in the near futur (5 years to come) the GPU and CPU will 
be merged in a single chip high performance.

Just run a new instance of rebol for each core :)

....  becarefull there's a wolf in my name and those jokes it really 
don't make fun of them :)

So, if you created a rendering surface or whatever in Cairo, can 
you then ask another Rebol process to access it?

you have a specific area where you have your flash rendering embeded 
more or less into a  visual content rendered using a completly different 
engine and drawing method

was i more clear with that example (taht's the way GTK+ and QT link 
with opengl you have a specific squared area to clip your opengl 
rendering in  but  it's not mixed content

Graham in recent video card the GDI stack is not the most optimised 

they pushed walls to allow new things like the blu ray decoding to 
have a room and that have obviously an impact on the previous guys 
there and DX11 ...MicroSoft tod the whole word that GDI rendering 
was dead and that the only thing that matters was DX 11 rendering 
even for their widgets and desktop everyday rendering (aero)

let imagine you do a button you want to draw something on the background 
with AGG and then have the regular button borders and fonts to be 
applyed over  using AGG it's possible to have that effect  with the 
context phylosophy the VID button is a separated entity from the 
agg entity  you have the QT context the QT widgets display in it 
and the AGG widget is one of the few widgets you have but you can't 
mixe content ...

So, one could use AGG for somethings like a GUI and then use Cairo 
for display postscript

text is  a pain to handle that's why pango was created to serv the 
gilmp tool kit (GTK)

Function overloading (having a several variants of a function with 
the same name and different arguments) is a language feature available 
in many languages but not in C.

My status: Currently testing the dialog system prototype. This is 
ported from the VID Extension Kit and should allow for a large number 
of different dialogs. Still some work left to do, but have some basics 
working.

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


This odd looking dialog marks a few milestones from two days of work:


- Successfully create and open an email dialog created from a single 
style, which represents the content area.

- Successfully validate the content area from the validation information 
stored in the style.

- Successfully display validation result in the content area (the 
letters to the right of the fields show INVALID)

- Successfully block closing it, when it's not correctly filled, 
when clicking "Send" using a new DISMISS reactor.

- Successfully store the content in a way so that it can be returned 
in an object, when the dialog is finished or store a NONE/FALSE when 
cancelled.


The dialog is called by: REQUEST-EMAIL. It doesn't send any email, 
that comes later. The reason it looks odd is because the new resizing 
scheme requires some changes in how sizes are handled in styles and 
I haven't quite figured out how to change them yet.


We'll probably need some more prototypes, but all in all, this is 
a fairly good method of creating complete-featured dialogs quickly.

Isn't it just simpler to introduce a new type ... fpair for floating 
point par

And an fpair type would add a syntax ambiguity if we kept the integer 
pair type.

I don't think so... just need a few bits to be updated. The rest 
should fit.

besides, there will be a rather large extension to the GUI soon. 
it's not a good idea to work on docs now.

That is, the doc is a spec, which hasn't been reflected in code yet.

Just a quick question to further my understanding: is the Saphirion 
NLPP/Cost Analysis stuff already R3-based, or what GUI framwork is 
used for the Saphirion apps? (Henrik? Robert?)

I recall that Robert forked his own version a while back

yeah, it looked a lot like rebgui to me; but who knows, maybe you 
just imitated that style :) thanks for clearing that up!

I'd say much faster since there is a specific lightweight datatype 
for them

I do a lot of dynamically creating layouts .. I suspect it's related 
to that

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

All I can say then is that I do see a lot of rebgui errors if I use 
the gui too quickly

If I use the GUI in a sedate mode .. then no errors

if anyone has looked at it, do you think adding function as argument 
for the CLOSE reactor could be considered a security problem?

Henrik, I haven't looked at it, but if I guess right, you mean you're 
considering adding a callback ability to the window close function. 
Surely it would be a gui programmer who would be able to use this 
callback, right? You haven't programmed the close button to pop open 
a dialog for the end-user asking for arbitrary rebol code to execute 
with security off, have you? ;-)

I wanted it for dialogs, and correctly, it's just another option, 
since CLOSE offers the ability to set a value (logic!, block!, word!) 
in the window face, as the window is closed. The SUBMIT reactor allows 
a call-back.

I guess that SUBMIT and CLOSE both offering it won't make a difference, 
security wise.

now that I think of it, I'm not sure how much good it will do to 
add callbacks to CLOSE, since CLOSE for dialogs is meant to give 
a fixed way out of a dialog.

Hmm yes. If ever a dialog's close button does not simply close the 
dialog, I'm probably going to wish that the designer had found a 
better way to program the gui.

You need a close reactor to do the save-your-stuff prompts.

these aren't apps, but dialogs. dialogs have different behavior and 
use a short life cycle. the behavior for application windows is different 
and requires, correctly, management of the close action.

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

thanks Henrik - such a short summary is absolutly perfect to keep 
us informed. I will ask in 2 weeks the same question :-)

Resizing news: the latest state is, that there are two "container 
styles", the first one being a group - a layout in which graphic 
objects are arranged into either rows or columns, not necessarily 
into *both rows and columns* at the same time, the second one is 
a panel - a layout in which graphic objects are arranged into both 
rows and columns at the same time.

yes, I've suggested calling PANEL a TABLE instead, since it more 
clearly defines how it lays things out.

If it's not clear, the GROUP style produces this flow:

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


If you turn that 90 degrees, you'll see that it's like how newspapers 
arrange columns, so I would want to find a familiar DTP term for 
it.

Henrik, sorry, this is a misunderstanding

ok, backpedalling a bit :-)

Do you have a picture for the other orientation?

The style uses a LAYOUT-MODE attribute, which determines the preferred 
orientation.

It may sound a bit cryptic, but LAY simply exactly states that we 
are going to somehow layout the elements

Summary: in a group, objects are arranged into lines, that are handled 
depending on the LAYOUT-MODE as either rows or columns

btw - why "panel" is not fitting anymore? I can see no problem in 
using a panel name for what you described ...

(currently called a "group")

You still do not know *what is a group*

I mean *what is a group now*

Ah, so you changed the meaning of a group style?

just look at the box arrangement, and you'll see that you can draw 
a straight line between them in one direction, but you can't in the 
other. that should be enough.

So, this is how these two styles work, and there was a question, 
whether the names "group" and "panel" were appropriated.

I would stay with recent naming them - both names kind of represent 
a "container" kind of a meaning. It is a documentation thing imo.

Like a chess-board.

Petr, just don't care about it. Suggest a good name :-)

If we will not find better use-case for a Panel style, then let's 
stay with panel. If not, use Board instead ...

Panel is a good name. All of these are pretty arbitrary when applied 
to a GUI system. Pick something traditional like Group and Panel, 
that sounds nice.

Bolek got hurt in an accident, which is why he was not so active. 
He should be back in business in a couple of days.

Must be okay if he's back in a couple of days?

Remember, whatever name we choose will be written out a lot. The 
two main layout styles will show up a lot in user layouts. So short 
is good.

I agree.
But I have some ideas for making a very general layout mechanism.

It looks to me that the layouts above can be expressed by two nested 
levels of arrangement.

Remember, the goal is to be able to write layouts with as little 
style information as possible, just the style names, data and options. 
Keep the need to specify sizes to a minimum, colors never. The layout 
dialect is for app programmers, not graphic designers.

To give you an example, I would be the target market of the layout 
dialect. I am not a graphic designer, nor should I have to be. And 
you don't want me picking colors.

(It seems dubious to me that a graphic designer wouldn't be interested 
in layout, but I can understand the merit of separating the specifications 
for colours and the specifications for layout.)

HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)

I think it should be possible to make a style like that, if you really 
want it. (Most of the time, you don't want it, but when you do, you 
do.)

Most of the time when a programmer thinks that they want to specify 
colors, they are wrong.

No, I specifically disagree about that. If I want a style to be forced 
red, then I want it forced red.

I agree, most of the time the programmer doesn't want to think about 
it, and it's best to get the colour from a theme. BUT, WHEN YOU WANT 
A BUTTON ALWAYS RED, YOU WANT IT ALWAYS RED!!!!

You are a graphic designer then. We are assuming that the "programmer" 
and the "graphic designer" and the "style designer" could be the 
same person in practice, but the roles need to be kept distinct even 
when the same person is doing them.

That means that styles get functional names, not graphical names. 
Layouts should make sense if the user is color-blind. It is up to 
the theme designer (which may also be you, in a different role, or 
it may be someone on a theming site) to decide colors.