On Wed, Oct 5, 2011 at 6:41 PM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> 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..
note, there is a check in elm_win.c that forces all FB windows in
fullscreen, maybe you can add that to your as well.
>> 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).
I understand what you mean, but we're not talking about the same
thing. Games will have to support specific bits for PS3, for instance
they will have to know the mode they can achieve some FPS... In an
ideal world it's not required, because API would abstract it... but in
an ideal world the game would run well enough in all resolutions and
this is not required as well :-)
anyways if you're creating some kind of portal (eg: homebrew market),
or using a browser (ie: ewebkit port) then you'll need multiple
windows, or will have a huge work.
>> 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" :)
Done and in SVN :-) 1.5 day of work... but WM is far from good. I'll
not change this as it's not in my future needs, but I guess you guys
can create at least a nice theme for it.
>> > 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.
Agreed, but you'll need to specify an engine name, or call specific
apis like ecore_evas_{X,SDL,....}_modes_list().
But we still need to handle some properties... at least width, height,
bitdepth, refreshrate and rotation? What does SDL provides? It may be
a good start point.
--
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
