Yeah, there's no X on the PS3, so I use ecore_psl1ght for the PS3. I mentionned framebuffer/PS3 because that's what I could think of as 'fullscreen only engines'. But this would also go for the X engine, like I said, an example is the classical game where you could setup the resolution you want it to run in (640x480 or 800x600, etc..) to control the quality/speed and it would auto-change the screen resolution.
On Tue, Oct 4, 2011 at 6:59 AM, David Seikel <onef...@gmail.com> wrote: > On Tue, 04 Oct 2011 03:30:26 -0400 Christopher Michael > <cpmicha...@comcast.net> wrote: > > > On 10/03/2011 10:06 PM, Youness Alaoui 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. > > > > > > 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. > > > > Agree with this...tho perhaps ecore_x is a better place ?? Then it > > would be available to ecore_evas or other apps outside via Ecore_X ? > > > > > 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. > > > > > ecore_x_randr_screen_primary_output_current_size_get > > ecore_x_randr_screen_primary_output_orientation_get > > ecore_x_randr_screen_primary_output_refresh_rates_get > > > > So on and so forth.... > > > > Hence why I think (with the above) that ecore_x would be a better > > place... > > Does Ecore_X work outside of X though? Youness mentions > framebuffer/PS3. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > > ------------------------------------------------------------------------------ > 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
