Ok, so ecore_evas_visible_set and ecore_evas_visible_get? As for the return value, I was thinking of using it for apps that would require a cursor but it can't be shown (like for example on phones that wouldn't support having a cursor at all), then the app would need to know and draw one itself. Doing the trick in ecore-evas directly is a good idea, but if there's an engine that doesn't support changing the cursor's bitmap for example (think about framebuffer for example, no cursor support I suppose?), so returning FALSE to the set would be a good way to say that we can't do any tricks, and then visible_get would tell it if the engine does show a cursor (no cursor, can't fake one, do it yourself, has a cursor, can't change it to transparent, change your UI accordingly). You probably have more insight on this than me though, so let me know what you think.
KaKaRoTo On Wed, Sep 7, 2011 at 9:42 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > On Wed, Sep 7, 2011 at 10:08 PM, Youness Alaoui > <kakar...@kakaroto.homelinux.net> wrote: > > That's a good idea. the PS3's GPU also has a special command to hide/show > a > > cursor on screen, and I was planning on doing an API for it in > > ecore_psl1ght, but it would be better to integrate it directly into > > ecore_evas. I think an API like the one in ecore_x would be good, but > return > > a boolean instead of void, this way you can report errors (for engines > that > > don't support it, or for the ps3 where it wouldn't work if you don't > supply > > it with a cursor bitmap first). > > So, what do you think about this API : > > > > EAPI Eina_Bool ecore_evas_cursor_show(Ecore_Evas *ee, Eina_Bool show); > > > > If agreed on, should I just go ahead and add it to Ecore-evas? > > visible_set() would be more EFL-like. With visible_get() to pair. > > I wonder if the return will be of any use... if the user must do > something else, then just do it in Ecore_Evas. For example, if you > don't support turning off the cursor, do some trick, like transparent > bitmap. > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
