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 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 to the requested
> >>> >> screen even if not fullscreen. it's useful in multiple ways. of course
> >>> >> its a hint
> >>> >> - not an order. it can be ignored.
> >>> >
> >>> > Hmm... this is somehow close to what I proposed initially, but I think
> >>> > I wasn't that clear.
> >>> >
> >>> >> the question then is.. how to identify the screen. :)
> >>> >
> >>> > What about a struct, with (if needed) an ID, properties, and
> >>> > everything we can fetch from each screen/output? That would also
> >>> > remove the need for extra functions to fetch screen size, dpi, etc...
> >>>
> >>> The problem with a structure is that we need to figure it out quite a
> >>> lot in advance to have a stable ABI here. I think it is doable, but I
> >>> am not that sure. Don't forget 3D screen and reading distance if we
> >>> can figure it out at some point.
> >>
> >> if we create a screen OBJECT and make it an opaque handle.. we can extend
> >> until the cows come home safely... :)
> >
> > I like this one, though it will imply in more than just 3 extra
> > functions. It should be at least one extra function per
> > property/query.
> >
> > Anyway, can I follow this route?
>
> I think Eo will be overkill for this, so just opaque handle seems fine
> to me. Also note that I think an ecore_evas_screen_iterator_new would
> be nicer than returning an Eina_List, but that's just me and cosmetic
> at this point. So yes I think you can forward with that design.
i'm not so sure it would be overkill. in the end i can see us using screen
objects for a whole tonne of things - querying screen data but ALSO requesting
things like lock screen X or Y, turn screen X off, ask screen Z to rotate
etc. :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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=65839951&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
