On Tue, Oct 4, 2011 at 9:52 AM, Gustavo Sverzut Barbieri <
barbi...@profusion.mobi> wrote:
> On Mon, Oct 3, 2011 at 11:06 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
> > Hey Gustavo!
> > Thanks for answering my email! It's appreciated.
> > However it didn't answer my questions, because basically, no, I'm not
> going
> > to implement a window manager for the PS3 :) Don't forget that all
> > applications/games will be full screen windows, and that 0.1% of people
> (a
> > lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so
> > having multiple windows is not a solution. I'm ok with single window
> apps,
> > and while I do want to have interoperability with existing EFL apps
> without
> > (or few) modifications, I mostly want something for new app development
> and
> > a clear API on how to change resolution and how to handle the situation I
> > explained.. most importantly, I'm not going to implement a WM,
> compositor,
> > wayland or anything fancy like that :)
> > I am not focusing on multi window apps, in my previous email, when I said
> I
> > used elementary_test, I failed to mention I only ran it with
> --test-win-only
> > to make sure only one window is created, so this is not the issue here.
>
> You're overlooking the problem. :-)
>
> 1 - The game content itself will run on the main Ecore_Evas that uses
> PS3 directly, not the inner windows. Less overhead... And likely it
> will use the GL bindings, as most games will use GL directly and not
> Evas. Then, to configure the screen they would use this API to set
> their best resolution.
>
Well, for new apps written for the ps3, I don't see a problem, you'd make
sure you do everything right, use a single window, set the fullscreen flag,
etc..
> 2 - Most apps will need to have some kind of multiple windows, like
> popups and so to extend/configure the game. These will likely bring
> the need for this "manager".
>
Not really.. I don't expect to just run or port apps from the PC which use
multiple windows.. on a TV it's just not doable..
don't forget that pretty much everyone will be controlling these with a ps3
controller and I don't see them switching from one window to another with
that, it just doesn't feel right.
If you look at eskiss, you'll see that's the kind of stuff I expect.. as for
popup windows, or even contextual popup menus, (or menus), those shouldn't
appear in a console app (but contextual popups still do work since they
don't create a new window).
> 3 - The manager should be simple. It's already possible right now,
> there is no hard code to do. You just manage windows as Evas_Object
> (Image) at the parent canvas, so window move =
> evas_object_move(window_backing_store, x, y). Resize, hide... are
> similar. Ecore provides such integration with
> ecore_evas_object_image_new(). What we need is to provide such engine
> for Elementary, instead of using your PS3 engine.
>
I know it would be pretty simple in theory, but then you start doing it,
then you need to add window decorations, then you test and a few use cases
don't work, and you end up writing a lot of code instead of the simple
"couple of lines" that you initially planned..
I also honestly don't see a point in doing that, at all, since
multi-windowed application are absolutely not my target here. So let's just
say it's "outside the scope of the project" :)
>
>
> > I like the screen_geometry_set and screen_modes_list, but I think they
> > should go into evas or ecore-evas rather than elm, because they might be
> > useful to people not using elm.
>
> Sure, likely the elm one is a wrapper over ecore_evas functions. When
> using my proposed engine, it would apply it to the underlying
> Ecore_Evas, for instance.
>
ok sure :)
>
>
> > E17 has a resolution config dialog, how does it get/set the screen's
> > resolution? I suppose by using xrandr or something like that? maybe we
> can
> > abstract that into evas directly, this way it would work on non-X
> backends
> > like framebuffer/ps3.
>
> it's Xrandr. But it's complex and every system is different. Unless we
> make a complex system that covers them all, they would still be
> per-engine. X11 would need modelines, etc.
>
ok, I don't know much about it, I'd just expect something where you can list
modes and set modes.. where a mode would basically be width and height,
maybe refresh rate too.
If you say there are more stuff that can (and should) be user-configurable,
then the mode_set could take one of the returned values from modes_list, and
that could be a sort of opaque structure
which can be cast into a common Mode object, and it would hold all the extra
parameters needed.
If modeline, etc.. are just settings needed by xrandr or whatever, but it's
not something that should be user-configurable, then you could just make the
logic of fetching the right values from inside the mode_set code.
For my first proposition, since I'm not sure I explained it right, here's an
example (in pseudocode):
-- Ecore_Evas.h --
struct EMode { int width; int height };
EAPI Eina_List *ecore_evas_modes_list (void); // Returns list of void *
EAPI Eina_Bool ecore_evas_mode_set(void *); // Item from the eina_list
returned by ecore_evas_modes_list
-- main.c --
Eina_List *l = ecore_evas_modes_list();
Emode *m = (EMode *) EINA_LIST_FIRST(l);
printf("Mode size %dx%d\n", m->width, m->height);
-- Ecore_X.h --
struct XMode {
EMode mode;
int refresh_rate;
int modeline;
void *other_options;
}
EAPI Eina_List *ecore_x_modes_list(void); // Returns list of XMode
EAPI Eina_Bool ecore_x_mode_set(XMode *);
Since the 'EMode mode' structure is the first element of the XMode
structure, then it can be cast into it without problems.
>
> > What I have done for now is use the fullscreen flag to decide whether or
> not
> > to call the resized callback with the full screen size (scale or resize
> > window). If we add the modes_list and screen_geometry_set functions then
> it
> > would fix a few of the issues I had.
>
> it may work, but it's just going around the problem :-)
>
Yep, for now it's a workaround until we decide on a proper solution to this
issue.
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
