Re: [E-devel] EFL sonames
On 11/08/2015 05:19 PM, Andreas Metzler wrote: > On 2015-11-07 Carsten Haitzler wrote: >> On Sat, 7 Nov 2015 08:18:55 +0100 Andreas Metzler said: > [...] >>> Jumping in, let me outline the question a little bit more extensively: >>> Let's assume I found that there is ABI breakage when upgrading >>> libfoo from efl 1.8 to libfoo from efl 1.15 while both releases of >>> libfoo shared the same soname. i.e. a binary built against >>> libfoo-efl1.8 will stop working correctly when libfoo is upgraded to >>> libfoo-efl1.15. If I reported a bug about this issue would you >>> consider it to be release-critical and would you resolve it by either >>> fixing the ABI breakage or bumping the soname? >> how does THAT mean there is an ABI break? it could simply be that >> there was reliance on undefined behavior that has now changed, or >> the app was LUCKY to not trigger a bug before and now it does. just >> because something used to work and now doesn't does NOT mean there >> is an ABI break. you don't know until you dig in and find out. > Hello, > > yes, you are right. I was trying to ask about a "real" ABI > break, i.e. public interfaces breaking and requiring a rebuild (or > even source changes) in reverse dependencies. > >>> (Obviously this implies that I generally would not usually find such >>> issues, since making sure that ABI breakage is avoided would be part >>> of the release process.) >> we actually run ABI reports every release (these check structures, >> actual function call signatures, symbols etc.). we don't break our >> ABI according to this > Ok, that is great, thanks. > >> (unless of course you rely on api documented >> to be unstable - eg like eo. that we document to be experimental >> and we do break it). > Which means that we should not ship the eo API in Debian. Well given how the libraries are intertwined that is probably quite hard, maybe you could split header files with unstable api such as the ones that include eo api's, from my understanding the eo lib itself is pretty much considered stable but the api thats generated from it hasn't been declared stable yet (someone will correct me if i'm wrong). Cheers Simon > However afaict e.g. elementary only provides an eo API since 1.13 and is > required by E. > > cu Andreas > -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL sonames
On 2015-11-07 Carsten Haitzler wrote: > On Sat, 7 Nov 2015 08:18:55 +0100 Andreas Metzler said: [...] >> Jumping in, let me outline the question a little bit more extensively: >> Let's assume I found that there is ABI breakage when upgrading >> libfoo from efl 1.8 to libfoo from efl 1.15 while both releases of >> libfoo shared the same soname. i.e. a binary built against >> libfoo-efl1.8 will stop working correctly when libfoo is upgraded to >> libfoo-efl1.15. If I reported a bug about this issue would you >> consider it to be release-critical and would you resolve it by either >> fixing the ABI breakage or bumping the soname? > how does THAT mean there is an ABI break? it could simply be that > there was reliance on undefined behavior that has now changed, or > the app was LUCKY to not trigger a bug before and now it does. just > because something used to work and now doesn't does NOT mean there > is an ABI break. you don't know until you dig in and find out. Hello, yes, you are right. I was trying to ask about a "real" ABI break, i.e. public interfaces breaking and requiring a rebuild (or even source changes) in reverse dependencies. >> (Obviously this implies that I generally would not usually find such >> issues, since making sure that ABI breakage is avoided would be part >> of the release process.) > we actually run ABI reports every release (these check structures, > actual function call signatures, symbols etc.). we don't break our > ABI according to this Ok, that is great, thanks. > (unless of course you rely on api documented > to be unstable - eg like eo. that we document to be experimental > and we do break it). Which means that we should not ship the eo API in Debian. However afaict e.g. elementary only provides an eo API since 1.13 and is required by E. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get mouse movement like a fps
On 7 November 2015 at 21:57, Carsten Haitzler wrote: > On Sat, 7 Nov 2015 12:07:41 +0900 Christophe Sadoine > said: > >> Hello, >> >> I want to freely move my mouse without being limited by the edges of my >> screen. Like a fps where I can move the mouse forever and my character turns >> on itself forever. >> >> How can I do that? > > x11 itself doesn't support this with core devices. wayland atm not as well. > this > is all about relative positioning devices and atm wayland is working on a > spec. > in x11 you COULD do this going right to the xinput devices. try: > > xinput test-xi2 > > for example. there has been an old hack in x11 - you grab the mouse pointer to > your window AND continuously every time a mouse event comes in... warp it back > to the center (ignore the event that results from the warp after this). this > means you will be able to get relative events from abs coords. Thanks, that is what I was trying to do and I found ecore_evas_pointer_warp. And it's good enough... -- http://indefini.org -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get mouse movement like a fps
On Sat, 7 Nov 2015 12:07:41 +0900 Christophe Sadoine said: > Hello, > > I want to freely move my mouse without being limited by the edges of my > screen. Like a fps where I can move the mouse forever and my character turns > on itself forever. > > How can I do that? x11 itself doesn't support this with core devices. wayland atm not as well. this is all about relative positioning devices and atm wayland is working on a spec. in x11 you COULD do this going right to the xinput devices. try: xinput test-xi2 for example. there has been an old hack in x11 - you grab the mouse pointer to your window AND continuously every time a mouse event comes in... warp it back to the center (ignore the event that results from the warp after this). this means you will be able to get relative events from abs coords. this of course is pure evil and the nice way is to do relative coord device handling. atm efl actually doesn't have any support for this at any layer. :) > My use case is a widget like the spinner. When I click it I want to > hide or change the cursor and let it stay on the same position. Then I > want to get mouse move events. > When I release the mouse, the cursor is reset and is at the same > position as before the click. > You can try this in blender it is exactly doing this. > > -- > http://indefini.org > > -- > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL sonames
On Sat, 7 Nov 2015 08:18:55 +0100 Andreas Metzler said: > Ross Vandegrift wrote: > > On November 4, 2015 7:48:53 PM EST, Carsten Haitzler > > wrote: > >>On Wed, 04 Nov 2015 11:54:43 -0500 Ross Vandegrift > >>said: > >>> Is there an official stance on sonames in EFL & friends? I see some > [...] > >>does this help? > > > Err, not really - I was wondering about when you guys would change a > > soname. Sorry for being unclear. > > > Looking over the history, I'd guess the plan is to leave them alone. > > But maybe an EFL 2.x would trigger a change? I'm not 100% confidant of > > that assessment. Just trying to figure out what to expect. > > Hello, > Jumping in, let me outline the question a little bit more extensively: > > Let's assume I found that there is ABI breakage when upgrading > libfoo from efl 1.8 to libfoo from efl 1.15 while both releases of > libfoo shared the same soname. i.e. a binary built against > libfoo-efl1.8 will stop working correctly when libfoo is upgraded to > libfoo-efl1.15. If I reported a bug about this issue would you > consider it to be release-critical and would you resolve it by either > fixing the ABI breakage or bumping the soname? how does THAT mean there is an ABI break? it could simply be that there was reliance on undefined behavior that has now changed, or the app was LUCKY to not trigger a bug before and now it does. just because something used to work and now doesn't does NOT mean there is an ABI break. you don't know until you dig in and find out. > (Obviously this implies that I generally would not usually find such > issues, since making sure that ABI breakage is avoided would be part > of the release process.) we actually run ABI reports every release (these check structures, actual function call signatures, symbols etc.). we don't break our ABI according to this (unless of course you rely on api documented to be unstable - eg like eo. that we document to be experimental and we do break it). > cu Andreas > > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > > > -- > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
