• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Multi-monitor Systems

Started by demetrioussharpe, 2011.05.22, 19:48:19

Previous topic - Next topic

RobertM

Quote from: demetrioussharpe on 2011.05.24, 04:47:57
Quote from: RobertM on 2011.05.23, 22:32:52
Not particularly concerned if the current method works. That I am presuming should still be easily achievable by manually resizing the window across viewport. More concerned with (which OS/2 currently doesn't do) constraining a full screen request to a single monitor.

Ok, to be clear, you'd like the capability to make the app maximize, but be confined to just one screen?

Correct... (wow, that's a lot less wordy than my attempt). Comes in handy for watching videos... rather annoying having a video split across two monitors.  ;)

Question, how do you plan on handling full screen CMDLINE sessions?


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

warpcafe

Hi,

sounds like a plan. ;) Also this would solve a couple of possible annoyances I came across when thinking about how it would work.
I remember that when I was developing software, one of my usual lines of code went like

Quote"make window become centered horizontally and vertically" - pseudo code:

win.top = int ( ( screen.height - win.height ) / 2 )
win.left = int ( ( screen.width - win.width ) / 2)

I am sure almost every developer has some flavor of this code lying around... and I wonder what the impact will be when this is used, for instance, in a 2-monitor extended desktop setup...? Will the window appear 50% on right margin of left screen and 50% on left margin of right screen then? Will the virtualized driver/framebuffer handle this for the requesting applications automatically? Or is that already covered by the way how OS/2 works?

Feature request: (While we're at it... ;) )
One thing that really drives me nuts with an extended desktop (here: windows) is the following:
- you have 2 screens: A and B
- you launch a program and its window appears on screen A
- you drag the window onto screen B
- now you do something that causes a secondary window of the program to become opened (e.g. "open file" dialog)
-> ta-daa: This "popup" appears on screen A.

The problem is that if you look an the program window on screen B you hardly notice the secondary window at all.
I am not sure if that can be handled in an elegant way so that it becomes "transparent" to applications that they automatically stick to the screen they're currently being displayed upon... would be great though... :-P

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

warpcafe

Hi,

Quote from: demetrioussharpe on 2011.05.23, 20:07:26
This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?

Exactly.
That feature becomes available only if the video driver detects that
- there is more than one output device
- the desktop is extended
And then, the button is displayed on "active" titlebars only (meaning only the focused window has it)

However... this dynamic way of showing an additional button only for the focused window isn't mandatory for me - it would be OK to have it also on the "incative" windows (or "all" windows so to say). Not sure which way is easier to imlement.

One glitch however happens with windows that use their own style: While the button displays correctly on all windows that use the default theme currently selected, it overlays the standard button cluster (min|max|resize,close) of e.g. Google Chrome. I've attached a sample screenshot. And the additional button is not really aligned correctly even with the standard window styles... looks pretty much like a window handler "hack" to me.

Note that the feature perhaps is cool, however its implementation into the user interface is a bit... sluggish.
An "elegant" way of implementing this in eCS could be to provide this function in a way that the usual "enahncers" (XWP, eWP, eStyler) can make use of it. Example: "middle-button click on titlebar" or ctrl-doubleclick... or any hotkey combination like shift+ctrl+cursor-left... ;)

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Sigurd

Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:

  • Autodetect quantity of monitors

Hi,

it would like to have these feature as well! As you may have seen in my Youtube videos I am using a X200T (Tablet) notebook quite well with OS/2.

With Windows (XP, Vista or 7) there is a function to rotate the Display, as Martin describes. Even though it can use "auto rotation" as well, so it automatically jumps to the view depending in wich way the user moves the Laptop.

There is a hardwarebutton (below the screen) for Rotation availiable as well.

For me I would be very happy to have the possibility to rotate the screen and "by hand" would be really very good.
Auto Rotation is not necessary at all - even if it is quite cool :-)
Having the hardware button working for this would be great as well, because once you switch to tablet mode by Flipping the Screen around -it does lay on the keyboard and covers the keys :-( (You can see this happening almost in the end of my vidoe "The longest death in computer history" at youtube)
With Wim Brul we have been able to use the Stylus as a mouse replacement - and that is really cool by the way - it would be good to have a possibility to change Rotation by having a Mouse command defined so that this could be used with the Stylus.

I am really looking forward to see what will happen with your project. If I can be helpfull in testing "rotation" or something like this - just ask for!

Here a picture with Warp 4 MCP2 and the X200T



warpcafe

Hi,

looking at Sigurds scenario, again the solution wouold be to provide a "hookable" function that can be used by the enhancers.
OK, a hotkey will not make sense here because the keyboard isn't accessible. But even then, if someone comes up with a "mous gesture" handler for the enhancers, the function "rotate primary screen" could be assigned a gesture.

The most relevant part here for me is that the driver must be able to handle screen rotations separately for each physical screen.
That's quite some fiddling around the actual core task to have a driver :))

I strongly recommend to think about modularization of the tasks/features:
If one provides API calls to rotate screen(s), clone|extend dekstop, swap screen for a given window these could be made available to the next layer of user applications which would then make them available as mouse gestures, hotkeys or even -heck- launchpad buttons. In any way it saves the driver developer from having to hardcode everything in the first stage with roughly about 98,5% of users complaining that they prefer a different method for ... whatever.

Just my 2ct, cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

demetrioussharpe

Quote from: warpcafe on 2011.05.25, 11:12:43
Hi,

sounds like a plan. ;) Also this would solve a couple of possible annoyances I came across when thinking about how it would work.
I remember that when I was developing software, one of my usual lines of code went like

Quote"make window become centered horizontally and vertically" - pseudo code:

win.top = int ( ( screen.height - win.height ) / 2 )
win.left = int ( ( screen.width - win.width ) / 2)

I am sure almost every developer has some flavor of this code lying around... and I wonder what the impact will be when this is used, for instance, in a 2-monitor extended desktop setup...? Will the window appear 50% on right margin of left screen and 50% on left margin of right screen then? Will the virtualized driver/framebuffer handle this for the requesting applications automatically? Or is that already covered by the way how OS/2 works?

Feature request: (While we're at it... ;) )
One thing that really drives me nuts with an extended desktop (here: windows) is the following:
- you have 2 screens: A and B
- you launch a program and its window appears on screen A
- you drag the window onto screen B
- now you do something that causes a secondary window of the program to become opened (e.g. "open file" dialog)
-> ta-daa: This "popup" appears on screen A.

The problem is that if you look an the program window on screen B you hardly notice the secondary window at all.
I am not sure if that can be handled in an elegant way so that it becomes "transparent" to applications that they automatically stick to the screen they're currently being displayed upon... would be great though... :-P

Cheers,
Thomas

I don't think it depends so much on the framebuffer, as it most likely depends on how the GUI is designed. In some OSs, the GUI would default to trying to start the window at the top left corner. For some, it's the center of the screen. If these defaults are not wanted, the app designer is usually able to specify where they'd like the window to appear at initially. You may actually be dealing with a product of app designer didn't expect the desktop to ever be so big, so the window always opens in the first screen.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: warpcafe on 2011.05.25, 12:14:57
Hi,

Quote from: demetrioussharpe on 2011.05.23, 20:07:26
This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?

Exactly.
That feature becomes available only if the video driver detects that
- there is more than one output device
- the desktop is extended
And then, the button is displayed on "active" titlebars only (meaning only the focused window has it)

However... this dynamic way of showing an additional button only for the focused window isn't mandatory for me - it would be OK to have it also on the "incative" windows (or "all" windows so to say). Not sure which way is easier to imlement.

One glitch however happens with windows that use their own style: While the button displays correctly on all windows that use the default theme currently selected, it overlays the standard button cluster (min|max|resize,close) of e.g. Google Chrome. I've attached a sample screenshot. And the additional button is not really aligned correctly even with the standard window styles... looks pretty much like a window handler "hack" to me.

Note that the feature perhaps is cool, however its implementation into the user interface is a bit... sluggish.
An "elegant" way of implementing this in eCS could be to provide this function in a way that the usual "enahncers" (XWP, eWP, eStyler) can make use of it. Example: "middle-button click on titlebar" or ctrl-doubleclick... or any hotkey combination like shift+ctrl+cursor-left... ;)

Cheers,
Thomas

I'm sure that something can be worked out that'll be less of a visual distraction!
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: Sigurd on 2011.05.25, 13:47:08
Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:

  • Autodetect quantity of monitors

Hi,

it would like to have these feature as well! As you may have seen in my Youtube videos I am using a X200T (Tablet) notebook quite well with OS/2.

With Windows (XP, Vista or 7) there is a function to rotate the Display, as Martin describes. Even though it can use "auto rotation" as well, so it automatically jumps to the view depending in wich way the user moves the Laptop.

There is a hardwarebutton (below the screen) for Rotation availiable as well.

For me I would be very happy to have the possibility to rotate the screen and "by hand" would be really very good.
Auto Rotation is not necessary at all - even if it is quite cool :-)
Having the hardware button working for this would be great as well, because once you switch to tablet mode by Flipping the Screen around -it does lay on the keyboard and covers the keys :-( (You can see this happening almost in the end of my vidoe "The longest death in computer history" at youtube)
With Wim Brul we have been able to use the Stylus as a mouse replacement - and that is really cool by the way - it would be good to have a possibility to change Rotation by having a Mouse command defined so that this could be used with the Stylus.

I am really looking forward to see what will happen with your project. If I can be helpfull in testing "rotation" or something like this - just ask for!

Here a picture with Warp 4 MCP2 and the X200T




Though, I'm not sure what effect my implementation of these features will have on your tablet, I look forward to providing them in the hopes that someone will be able to tie them to the actual hardware within your device.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: warpcafe on 2011.05.25, 14:09:52
Hi,

looking at Sigurds scenario, again the solution wouold be to provide a "hookable" function that can be used by the enhancers.
OK, a hotkey will not make sense here because the keyboard isn't accessible. But even then, if someone comes up with a "mous gesture" handler for the enhancers, the function "rotate primary screen" could be assigned a gesture.

The most relevant part here for me is that the driver must be able to handle screen rotations separately for each physical screen.
That's quite some fiddling around the actual core task to have a driver :))

I strongly recommend to think about modularization of the tasks/features:
If one provides API calls to rotate screen(s), clone|extend dekstop, swap screen for a given window these could be made available to the next layer of user applications which would then make them available as mouse gestures, hotkeys or even -heck- launchpad buttons. In any way it saves the driver developer from having to hardcode everything in the first stage with roughly about 98,5% of users complaining that they prefer a different method for ... whatever.

Just my 2ct, cheers,
Thomas

My plan is to put this virtual device within EMIT3D.DLL. It will be the lowest layer within that dll, so it'll talk directly to the video drivers. It's presence should not change anything for the driver writers, because it will communicate to the drivers through the same interface as was already planned for the drivers.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Quote from: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.

Ummm... wow! If I'm following you correct, that means true full-screen to windowed (or vice versa) switching, simply by reassigning the output. Nice!


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.25, 22:39:07
Quote from: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.

Ummm... wow! If I'm following you correct, that means true full-screen to windowed (or vice versa) switching, simply by reassigning the output. Nice!

Basically, yes. But, as always, the devil is in the details.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

jep

#27
Hello,

the first two images show how pointer movement between two screens can be handled.
It's very confusing if the pointer doesn't appear on the second screen right next to the exit point from the first screen.

The rest of the images show a few 3D-CAD images that I modeled some time ago.

Missing images:
CRT Monitor
Monitor and projector
Monitor and TV
Monitor and Laptop
...?

//Jan-Erik

demetrioussharpe

Quote from: jep on 2011.05.28, 09:37:54
Hello,

the first two images show how pointer movement between two screens can be handled.
It's very confusing if the pointer doesn't appear on the second screen right next to the exit point from the first screen.

The rest of the images show a few 3D-CAD images that I modeled some time ago.

Missing images:
CRT Monitor
Monitor and projector
Monitor and TV
Monitor and Laptop
...?

//Jan-Erik

I can't promise that you'll be able use an extended desktop on multi-head setups that use displays without identical resolutions.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

jep

Yes, I guess it would be a bit of a challenge to create something like that on top of everything else.

I hope you all understood the purpose of the red line(s) in the first two images!
The red line(s) show where the user can't exit one view and enter the other and where to move the mouse pointer by hand as the arrows show.
Only the overlapping length of the adjacent sides can be used for the mouse pointer to go from one monitor/view to the other.

Another interesting feature would be to set/switch which monitor should act as No 1 and the next as No 2 etc to allow e.g. laptops to use a large external monitor as the primary display
Several of our developers where I work use that feature when they're sitting in the office.

//Jan-Erik