World: r3wp

yes, i can move windows around the two monitors. i have this altme 
window in one monitor and other two on the other monitor.

... and if so, could we at least get some preliminary (one week before 
release) access to docs, to read some things and being prepared to 
jump on R3 more quickly?

i can have windows "in between" and so on. it's just one big framebuffer. 
if i do a screeshot, i get a big 3000x1000 image.

access to docs.... i can ask Carl...

really? (re screenshot) ... moving windows by accelerator keys was 
fine. I think that we will need to map win32 api, which will tell 
us about particular monitor set-ups ...

Add a meetoo for access to docs, even if it's a subset.

this is how linux sees my display:

SZ:    Pixels          Physical       Refresh
*0   3360 x 1050   ( 948mm x 303mm )  *60
 1   1680 x 1050   ( 948mm x 303mm )   60
 2   1280 x 1024   ( 948mm x 303mm )   75   70   60
 3   1280 x 720    ( 948mm x 303mm )   60   50
 4   1152 x 864    ( 948mm x 303mm )   75   70   60
 5   1024 x 768    ( 948mm x 303mm )   75   72   70   60
 6    800 x 600    ( 948mm x 303mm )   75   72   70   60   56
 7    720 x 480    ( 948mm x 303mm )   60
 8    640 x 480    ( 948mm x 303mm )   75   72   60
 9    640 x 432    ( 948mm x 303mm )   60
 10   640 x 400    ( 948mm x 303mm )   75   60
 11   512 x 384    ( 948mm x 303mm )   75   60
 12   400 x 300    ( 948mm x 303mm )   75   60
 13   320 x 240    ( 948mm x 303mm )   75   60
 14   320 x 200    ( 948mm x 303mm )   75   60

notice there is an invisible area under the second monitor (1280x26 
pixels).

interesting part is, when you rotate one of your monitors, the actual 
bix size is max of respective x or y axis ....

mainstream OSes do not support multiple monitors very well - they're 
mainly hacks. the way R2 and R3 work now, you only "see" the first 
monitor, but you can still move windows to the second one. this is 
not too bad, because windows get centered to the first monitor if 
you use center-face instead of being between the two monitors (which 
is bad, and some apps do that). so altme always opens on the first 
monitor, because it thinks the offset it saved in the prefs is offscreen 
if it was on second monitor.

not sure, but IIRC I was able to get Altme started on second monitor 
too. At new work I don't have two monitor set-up, so can't confirm. 
nVidia drivers offer you an option to save the proferences for particular 
apps/windows. But often even known apps as Adobe Reader did not switch 
properly between two monitors (ignoring orientation for e.g.), so 
icons on windows showed the window is maxed, yet it was not ...

nvidia drivers were maybe overriding the setting from altme itself 
about position.

yes, I used and a bit extended Gregg's keys dialect. I was able to 
shape and move windows by calling win32 api functions. I tried to 
wrapp also the monitor stuff, but if was upon my capabilities ....

Unless there is an R3 Window Manager is this not an issue completely 
under the control of the desktop window manager?  Wouldn't any attempt 
by REBOL to effect this just break the desktop control?

btiffin - I am not sure I want R3 to break anything :-) But it would 
be nice, if programmer would have easy option to investigate state 
of monitor set-up, and eventually decide where to send the window 
to.

So aside from being coded to be "friendly" to any exisiting multi-montor 
display managers, there isn't much REBOL could do...at least not 
cross-platform...in my humble and zero experience opinion.

i think the current behavior is better than many other apps. but 
it can be improved a bit. we'll see...

it could detect monitors ... they are often numbered 1, 2, 3 ... 
and their orientation, resolution :-) Then we could have 1, 2, 3 
etc panes to post our apps to :-) That is my very unexperienced opinion 
too :-)

Gabriele - you mentioned "skinning". Will basic VID3 design be vector 
based, or still bitmap based? And will it be upon "skin" just to 
skin existing element, or will skin include also code of how to draw 
the element?

well, then where is a window which is between two monitors?

it can't be in two panes at the same time.

i think, where windows go should be left to the user. what's important 
is that rebol does not try to center windows incorrectly, or to clip 
them to the first monitor and so on.

skinning is completely abstracted and you can have whatever look 
for the styles. currently we only use draw, not images, but some 
styles may require images. anyway it depends on the skin, vid does 
not care at all what you do.

ah, valid point, I do remember some Delphi app incorrectly centered 
itself between two monitors ...

I'd leave this up to a display manager.  That is until there is an 
R3wm  :)

re skinning - sounds well abstracted. The same goes for your mention 
of layout no caring about actualy rendering anything too ....

source of layout function is like 4 lines ;)

Taunting the bears again huh?  :)

Gabriele - one of your past discussion was also so called two-ways 
functionality. I mean - after you do layout in R2, from the "live" 
state, e.g. by moving UI element, get it back to layout. So once 
you relayout you loose that info. Could that be solved?

ah, so why is there layout at all? :-) Could Rebol code 4 lines be 
any usefull? Scary question with REBOL :-)

hmm, what do you mean exactly?

layout it is useful. you would probably not guess those four lines. 
:)

hmm, not sure - I just remember one discussion ... you have layout 
[button 100x200 "ok" [print ok]] ... then you e.g. programatically 
move or resize the button .... layout simply is here like a template, 
which generates faces. The reverse aproach is not here ... maybe 
it even can't ....

is one of those lines - "; comment - for compatibility reasons ...." 
:-)

so basically, given win: layout [something here]  you want to get 
back the dialect block from win?

not sure I want, not sure it would be usefull. It is just that I 
remember one product which claimed to do something like that ....

I have e.g. screen painter in mind ... but with screen painter you 
can save exact pixel position, not generating dialect at all ....

what if i tell you that it was the main objective of the second prototype? 
:)

:-) well, then I can tell that someone found it usefull. Now what 
is its practical use? :-)

should i tell you? ;)

btw - what did you mean by "new dialecting method of R3"? What is 
new on dialecting itself, if 'parse did not change yet?

there is another function to implement dialects. you will find out 
soon enough.

Just to split your thinking Gabriele, is the Beta going to have a 
REBOL/Core .so for us Linux people?  With enough docs to have a go 
at embedding in something like say a D program?

(i personally prefer parse, but the new one is more efficient and 
so better for simpler dialects like vid etc.)

beta will be windows only.

eh, so we got something else than 'parse? How can dialect be built 
without the parser?

docs on the DLL... i don't think Carl has written them yet.

DOH!  :)

... using new method is the answer probably :-)