World: r3wp

yes, i get event/key: #"^-" and event/flags: [control]

Gabriele - re plug-in - it is different kind of app. But I would 
hate any single window to pop-up, even for simple dialog. And I mean 
to that extent, that I would ban such app, or it would be blocked 
by some add-block kind of extension anyway.

(i'm on wine though.)

ok, that is good to hear, ctrl tab is used for switching between 
tab in tab style ...

petr, i think the plugin host should never open new windows, but 
that depends on the plugin developer.

ok, but if you think about your app, you need dialog box, right? 
And what did currently R2 plug-in did? It popped-up in front of your 
browser ... that is not good. So to avoid this, you need something 
like windowing styles directly in VID level ....

no, you need the plugin to open its windows inside the window it 
has available.

But you are right that it can be solved by creating such styles ...... 
have you seen portals? Big ones? E.g. websphere? User has one website, 
and it has kind of small windows (javascript probably), which can 
be moved, resized, maximised, minimised ....

VID does not even need to know about it.

r2 plugin is just wrapper around view.

back later...

it is not clear to me what you mean. How can you open one window 
inside another one, not being a different window in the same time?

oh, well, next time i'll forbid people from posting screenshots. 
:-)

 <-- OK, that's it, I won't say anymore about R3 until after beta 
 :-)

Pekr, in the plugin, you specify an initial window which appears 
in the browser. You are not allowed to open new OS-level windows, 
therefore if you want to open new windows they must be VID-level 
windows. How do you do that ? You add faces to the first face's PANE, 
 start calling them "windows", and use code such as Cyphre's SWIS 
system to implement it. Simple as that.

Petr, Windows allows having windows inside windows. but even if it 
did not, the host code can easily emulate them using the same code 
that handles gobs and so on (that is, no extra code to write).

i don't think, users should have to switch between using view many 
times or one view and adding window faces to the pane. the host code 
can do this easily enough: the screen-gob isn't the screen anymore, 
but it becomes the plugin window, and the "window gobs" you add there 
create virtual windows inside that.

Henrik, it's ok to talk imho, it's just funny to see people start 
complaining before we even show anything. :)

Gabriele, I understand the fear completely and it can be a little 
frustrating to be kept in the dark for a little while longer. :-)

Anton - that is exactly what I am saying - VID level windowing. But 
what Gabriele suggests sounds like something else.

Does SWITCH need a /case refinement like we have in FIND and SELECT?

Gabriele - has anyone tried new View on multi-monitor display? It 
is imo good to keep that in mind, as R2 was not much friendly here 
....

Under R2 it would just need to propagate the refinement to SELECT 
(which is a bit of a pain of course). Worth asking for R3 though.

John;  I'd vote yes for a case sensitive refinement for switch.

... as for multiple screen, my experience is as follows. Under Windows, 
multimonitor set-up is an ilusion. You can find it out, once you 
use e.g. VNC and connect to such a remote desktop - you can easily 
see one big screen. The interesting part is - even if one of your 
displays is moved 90%, it is still one big box of x*y size.


So, in regards to REBOL, I think it would be vital to being able 
to identify multi-monitor set-up, and not one big screen face. My 
expectation is to have screen-face having two (or more, according 
to active monitors) or more subfaces - desktop windows ....


It would be good to get correct behavior in that regard from the 
very beginning ....

Sound like a complicated thing to support on all platforms.

hmm ... maybe we should at least have some strategy. Simply we should 
be prepared that screen-face is not screen face, but kind of desktop-face 
.... it should be indexed [1 [screen here] 2 [screen here]], it would 
be on pair with how driver identifies primary and secondary monitors. 
Not sure all drivers do it the same though, I mostly use nVidias 
.....

so my suggestion is, that screen-face should be a holding block, 
container, not face itself ...

Petr, I have two monitors here, one 1600x1050 and one 1280x1024. 
screen-gob size only reports the first, but I hope we can add support 
for things like these soon enough (not for beta).

about it being i single big box - it is so on linux too, and i'd 
assume it would be so in all OSes that have legacy to maintain, but 
it depends on the desktop mode too.

hmm, if you have two monitors, maybe you could try "a trick" :-) 
try to place your window "off-screen" and watch, if it appears on 
secondary monitor? :-)

btw - will there be release this week, or is it going to be postponed?

petr, is ok if screen gob is just one when it is one for the OS too, 
we just need some way to know the size of the monitors.

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