World: r3wp

I prefer non OS look, own style, which will identify rebol app. Definitely. 
All claims of otherwise I find false and unsupported by reality check. 
But I don't probably want my app to behave differently keyboard, 
focus wise, etc. Could be tough to achieve, as I remember OS-X has 
its own specifics :-(

re OS-X - I mean complete behavior of app in regards to system, docking 
etc.

pekr, "is there a concept of window in new VID? As I said - I would 
like to have one."


I don't really know, as I haven't looked at this part of VID3. Windows 
are different from GOBs. There are "Window GOBs", but I don't know 
exactly what that means.

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

graham: the dialect is different, because it uses new dialecting 
methods from r3. also, the layout is intended to be abstract rather 
than concrete (ie you don't normally specify the size of things). 
the rendering is fully up to the "skin" and not to the layout dialect.

petr, you can't say what resizing is missing before knowing how it 
works. :)

petr, the plugin is a different host, in the normal host windowing 
MUST be left to the os.

Gabriele - re posting screenshots, I thought the same - if I would 
not see a screenshot, I would have nothing to complaing about :-)

Gabriele - why you think it must be left to the os?

so you want altme to open up some big window and have altme windows 
inside it?!?

Think of ViewTop for e.g. It is like desktop. Why not to have VID 
level windowing? Not as a default, but as an option?

give me one single reason to have vid level windowing (it's just 
a style away to be possible - the system does not care at all about 
how "windows" are implemented)

yes to Altme, why not? It is just layer, the only difference is, 
that dialog box does not appear on the OS taskbar ...

I am starting to think of R3 View as na OS desktop, so ... :-)

ie. i can make a "screen" panel style and a window style.

yes, that is what I meant .....

it would help plug-in at least ....

i think that in the case of plugin it's the host code that has to 
handle this. you should not have to change your app to work in the 
plugin.

Gabriele, do you (or other in the R3 dev team) know about GLUT? It 
may be a fast way for you to have e.g. key-up events on all platforms.

(although, of course, the environment is so different that the app 
may need to handle it as a special case.)

geomol, i'm sure cyphre knows about it, but i don't think we're going 
to explore that anytime soon. we have key-up for control, shift, 
and so on already.

ctrl tab  supported? :-)

ok, I was thinking, it might be a shortcut to many wanted features, 
until the final code is found for the different platforms.

i haven't tried ctrl tab

it was not trappable in R2 iirc ....

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.