Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli antogno...@gmail.com
wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
i think this way is nicer. add a new api that sets a requested/hinted/desired
screen on a window and THEN if u fullscreen it this requested screen is
passed along with the fullscreen request to wayland. in x it can be another
atom/hint on the window and the wm can decide what to do. a screen hint in wl
and/or x11 could also be used AT the time a window is mapped (shown).
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli antogno...@gmail.com
wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
i think this way is nicer. add a new api that sets a requested/hinted/desired
screen on a window and THEN if u fullscreen it this requested screen is
passed along with the fullscreen request to wayland. in x it can be another
atom/hint on the window and the wm can decide what to do. a
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the
second, etc? Or maybe allowing to specify something like always the
biggest one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
i think this way is nicer. add a new api that sets a
requested/hinted/desired screen on a window and THEN
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler ras...@rasterman.com wrote:
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as
fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set
API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display.
Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API
that
allows to set the preferred output, and then when fullscreen_set
is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the
second, etc? Or maybe allowing to specify something like always the
biggest one in area, or the widest one, or whatever... any
thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
i
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:58 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr
said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as
fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set
API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display.
Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API
that
allows to set the preferred output, and then when fullscreen_set
is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred
to.
Using an (unsigned) int, where 0 is the first output, 1 is the
second, etc? Or maybe allowing to specify something like always
the
biggest one in area, or the widest one, or whatever... any
thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows,
x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we
can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current
output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking
about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ?
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 11:58 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr
said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as
fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set
API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display.
Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API
that
allows to set the preferred output, and then when fullscreen_set
is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred
to.
Using an (unsigned) int, where 0 is the first output, 1 is the
second, etc? Or maybe allowing to specify something like always
the
biggest one in area, or the widest one, or whatever... any
thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows,
x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we
can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current
output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking
about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ?
Re: [E-devel] Monitor/output parameter for fullscreen
On Fri, 1 Nov 2013 10:16:20 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 11:58 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
ras...@rasterman.com wrote:
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr
said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
antogno...@gmail.com wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not
support specifying which output/display/monitor should be used
as fullscreen. However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set
API? Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID
*did) /* NULL = unset */
the current version remains and sets on current display.
Alternatively we could just move the window to another display
before making that fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will
use the first output. But that's up to the compositor to choose so
far, unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API
that allows to set the preferred output, and then when
fullscreen_set is called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind
of general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred
to. Using an (unsigned) int, where 0 is the first output, 1 is
the second, etc? Or maybe allowing to specify something like
always the biggest one in area, or the widest one, or
whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call
them, like zone, etc), they should return their properties such
as size, position (?), capabilities (3d/stereo? color? what do we
have here?) and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows,
x11, wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the
first monitor, not both.
same as above, this should be based on current window (if there
is a window handle) or the first one (if there is not,
alterntively we can state it will refer to screen the mouse is
over, but I guess this is incorrect and makes everything less
predictable).
Well, that API has no argument, so it just assumes the current
output. For a given window, one could use
ecore_evas_screen_geometry_get, and that indeed will be attached
to a given display, but only after the Ecore_Evas has been shown
first (at least on Wayland, if I'm not wrong).
What about a common API to select which output we are talking
about, that must be called before any call that would refer to a
specific output? The problem with this is that it would make
code very wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of
another display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for
different monitors, but I've seen discussion about future work on
this on Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a
presentation tool might offer a way to choose in which display to
have a fullscreen view of slides while the notes/timer may be
fullscreen on another).
Why not just a
Re: [E-devel] Monitor/output parameter for fullscreen
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
--
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Rafael Antognolli
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor/output parameter for fullscreen
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli antogno...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
--
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli antogno...@gmail.com
wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
--
Cedric BAIL
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL cedric.b...@free.fr said:
On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli antogno...@gmail.com
wrote:
On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com
wrote:
Hey everyone,
Our current API for setting a window as fullscreen does not support
specifying which output/display/monitor should be used as fullscreen.
However, wayland does support it.
Would it make sense to have such parameter in the fullscreen_set API?
Or should it be a wayland-only API?
I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
NULL = unset */
the current version remains and sets on current display. Alternatively
we could just move the window to another display before making that
fullscreen, no idea if this is okay.
Yeah, current version sets on current display (the one where the
non-fullscreen window is already displayed), unless it's the first
time that the window is going to be displayed. Otherwise it will use
the first output. But that's up to the compositor to choose so far,
unless we explicitly specify which output to use.
For the latter case, how would we do that? Maybe exposing an API that
allows to set the preferred output, and then when fullscreen_set is
called, it just uses that one?
I'd say we need to make this in one go, unless we want some kind of
general assignment to one display (not just for FS mode).
OK...
There's also a need to specify how the output should be referred to.
Using an (unsigned) int, where 0 is the first output, 1 is the second,
etc? Or maybe allowing to specify something like always the biggest
one in area, or the widest one, or whatever... any thoughts?
We'd need a way to enumerate the displays (or whatever we call them,
like zone, etc), they should return their properties such as size,
position (?), capabilities (3d/stereo? color? what do we have here?)
and some string to make it easy to debug.
we have the handle to it, so it can be windowsystem agnostic
(Display_ID *, which can be implemented differently for windows, x11,
wayland...)
So you are proposing that we change a good portion of our API to be
aware of multiple displays?
That reminds me that we still have another problem. APIs such
ecore_wl_screen_size_get() return only the screen size of the first
monitor, not both.
same as above, this should be based on current window (if there is a
window handle) or the first one (if there is not, alterntively we can
state it will refer to screen the mouse is over, but I guess this is
incorrect and makes everything less predictable).
Well, that API has no argument, so it just assumes the current output.
For a given window, one could use ecore_evas_screen_geometry_get, and
that indeed will be attached to a given display, but only after the
Ecore_Evas has been shown first (at least on Wayland, if I'm not
wrong).
What about a common API to select which output we are talking about,
that must be called before any call that would refer to a specific
output? The problem with this is that it would make code very
wayland-specific :-/
how so? just use the opaque handlers and abstract stuff in there.
OK, so you suggestion is something like:
Display {
ID;
size;
position; // might be some info from xrandr, like right-of another
display, etc, if that is even possible
capabilities (3d/stereo? color?)
dpi (I'm not even sure if we can query different DPIs for different
monitors, but I've seen discussion about future work on this on
Wayland);
}
And then change/add some APIs to refer to a specific display when
setting things?
change is impossible at this time (abi/api stability) and cumbersome
for most apps that don't care.
Indeed.
then we must add new apis for those apps that care (ie: a presentation
tool might offer a way to choose in which display to have a fullscreen
view of slides while the notes/timer may be fullscreen on another).
Why not just a ecore_evas_screen_set/get/list() set of functions that
will affect the screen attached to a window for all coming request on
the pointed Ecore_Evas window ? That will limit the number of function
we add and will not make the API to ugly in my point of view.
i think this way is nicer. add a new api that sets a requested/hinted/desired
screen on a window and THEN if u fullscreen it this requested screen is
passed along with the fullscreen request to wayland. in x it can be another
atom/hint on the window and the wm can decide what to do. a screen hint in wl
and/or x11 could also be used AT the time a window is mapped (shown). ie if set
before window is shown, then wm (or wl compositor) may assign the window
Re: [E-devel] Monitor/output parameter for fullscreen
On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli antogno...@gmail.com wrote: Hey everyone, Our current API for setting a window as fullscreen does not support specifying which output/display/monitor should be used as fullscreen. However, wayland does support it. Would it make sense to have such parameter in the fullscreen_set API? Or should it be a wayland-only API? I'd say a new function fullscreen_at_display_set(Display_ID *did) /* NULL = unset */ the current version remains and sets on current display. Alternatively we could just move the window to another display before making that fullscreen, no idea if this is okay. For the latter case, how would we do that? Maybe exposing an API that allows to set the preferred output, and then when fullscreen_set is called, it just uses that one? I'd say we need to make this in one go, unless we want some kind of general assignment to one display (not just for FS mode). There's also a need to specify how the output should be referred to. Using an (unsigned) int, where 0 is the first output, 1 is the second, etc? Or maybe allowing to specify something like always the biggest one in area, or the widest one, or whatever... any thoughts? We'd need a way to enumerate the displays (or whatever we call them, like zone, etc), they should return their properties such as size, position (?), capabilities (3d/stereo? color? what do we have here?) and some string to make it easy to debug. we have the handle to it, so it can be windowsystem agnostic (Display_ID *, which can be implemented differently for windows, x11, wayland...) That reminds me that we still have another problem. APIs such ecore_wl_screen_size_get() return only the screen size of the first monitor, not both. same as above, this should be based on current window (if there is a window handle) or the first one (if there is not, alterntively we can state it will refer to screen the mouse is over, but I guess this is incorrect and makes everything less predictable). What about a common API to select which output we are talking about, that must be called before any call that would refer to a specific output? The problem with this is that it would make code very wayland-specific :-/ how so? just use the opaque handlers and abstract stuff in there. -- Gustavo Sverzut Barbieri -- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
