On Wed, Oct 5, 2011 at 7:59 PM, Gustavo Sverzut Barbieri <
barbi...@profusion.mobi> wrote:
> 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.
>
Yes, that's what i did originally, but this caused the elm_win_resize to not
be called (see first email about that issue), that's why I was forced to
remove that fullscreen flag.
>
>
> >> 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 :-)
>
Yes, ps3 apps will have ps3 specific code, what my issue with screen res and
fullscreen was, was that I didn't want to write a guide that says "if you
want to change resolution, you need to unset the fullscreen flag, resize the
window, then set the fullscreen flag back".
>
> 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.
>
Not really, a "portal" can work quite well with a single window, as for a
browser, it's windows, yes, but you'd have a different way of accessing
them.. the thing of having windows with decorations and using a mouse to
move and 'focus' from one window to another is very desktop specific and not
very joystick/joypad compatible.
>
>
>
> >> 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.
>
Very nice! On the PC it runs quite well, I've tried to test it on the ps3
(not sure you saw my msgs on IRC), but it doesn't work that good though, the
screen isn't refreshed, mouse cursor doesn't change/work, and there's no
decorations.. still no idea why there would be no decorations.
However, all you've seemed to address was the multi-window issue (which
wasn't one of my initial concerns tbh).
Here are again the questions that I had in my first email which are still
answered.
- Is there a way to tell the engine to stretch/scale/keep aspect ratio,
using the current API, or should I set an engine specific option ? (all
seems to point to engine specific option)
- Should I send two resize callback (one for the requested size followed the
screen size) or a single one (final resolution) when a resize is requested?
(I suppose only one is needed)
- How can we fix the issue where the window gets resized between the call to
_new and _callback_resize_set? Have the callback_resize_set call the
callback right away with the current resolution ?
- How should I decide on whether to scale or not the window (call the resize
callback with the current screen or leave it as is and just scale the
window) ? (fullscreen flag seems to be a good idea here)
- How can I handle the min/max properties on a window ?
- What side effects does the maximize and fullscreen flag have other than
engine specific, for non-windowed systems ? (fullscreen flag seems to make
the elm_win_resize a no-op, not sure if those flags mean anything else)
>
>
> >> > 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
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
