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. 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". 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 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. > 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. > 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 :-) -- 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
