Re: [E-devel] Add ability to show/hide mouse cursor
Il giorno ven 8 feb 2019 alle ore 17:41 Carsten Haitzler < ras...@rasterman.com> ha scritto: > On Fri, 8 Feb 2019 17:27:18 +0100 Davide Andreoli > said: > > > Il giorno ven 8 feb 2019 alle ore 16:50 Carsten Haitzler < > > ras...@rasterman.com> ha scritto: > > > > > On Fri, 8 Feb 2019 13:41:06 +0100 Davide Andreoli < > d...@gurumeditation.it> > > > said: > > > > > > > Il giorno ven 8 feb 2019 alle ore 12:16 Boris Faure > ha > > > > scritto: > > > > > > > > > Hi :) > > > > > > > > > > I know we're about to close EFL 1.22 and I might be too late to > make > > > > > this request. > > > > > > > > > > In the foreseeable future, I'd love to make Terminology hide the > > > > > mouse over cursor after some delay of it not moving. Sadly, > elementary > > > > > and EFL in general, lack an API to do so. I've opened ticket > T7646 to > > > > > add that to EFL (I have not produced the code to make it possible). > > > > > This feature has been requested in Terminology about 4 years ago > and > > > > > we failed at delivering it. > > > > > > > > > > > > > Indeed this is a longstanding request, rage and epymc implemented > > > > some "hacks" to hide the mouse cursor, and they do not always work > > > > as expected. So a + from my side. (I'm not willing to implement this > > > myself) > > > > > > I'm not so sure it's a hack. We have APIs to set mouse cursors on > specific > > > widgets in elm. If the mouse is over that widget the cursor for that > > > widget is > > > shown. A global "don't show pointer" is also a hack in that it is brute > > > force > > > and you can't make it vary depending where the pointer is in that > window so > > > you are then using the current method to be more specific when needed > > > anyway > > > and then having to figure out the interaction now between 2 properties > > > rather > > > than a single one. I'm not sure other solutions are going to be less > of a > > > hack > > > in the end. > > > > > > i also haven't noticed it being unreliable. > > > > > > > It is not unreliable in rage because rage is simple (in terms of widgets > > hierarchy). > > In epymc there can be lots of other widgets that appear and disappear on > > top of > > the videoplayer widget (like dialogs, subtitles text, multimedia > controls, > > notification, etc). > > The "hack" I have done is the same as the rage one (a trasparent widget > on > > top of the stack, > > with cursor blank) and it not reliable: sometimes, quite randomly, when a > > new widget > > is created (below the transparent one) the mouse pointer is show again. > > That doesn't justify a special blank cursor api/mode. that means there is > a bug > in cursor-per-object handling and it would affect any custom cursor set on > an > object. :) > > > And frankly a transparent widget on top of all just to hide the mouse > > cursor is what > > I call an hack. > To keep this thread alive: Qt have implemented the feature requested: QGuiApplication::setOverrideCursor(QCursor(Qt::BlankCursor)) ... and it is not bugged :P > > > > > > > > > > > With the blank style terminology could do it over everything, over > just the > > > terminals (leaving the ptr to appear in the settings and other > controls), > > > on a > > > specific terminal only, or just do the "put a button above everything" > > > method > > > etc. ... > > > > > > > cheers > > > > > > > > > > > > > > > > > > Is there something I can do (while not making the patch to EFL > > > myself) > > > > > to make this feature come sooner to EFL? > > > > > > > > > > Thanks > > > > > > > > > > -- > > > > > Boris Faure > > > > > Pointer Arithmetician > > > > > ___ > > > > > enlightenment-devel mailing list > > > > > enlightenment-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > ___ > > > > 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" > -- > > > Carsten Haitzler - ras...@rasterman.com > > > > > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > 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] [EGIT] [core/efl] master 02/02: Revert the env object because it's broken portability - please redo
Hi,
On 2/13/19 11:00 AM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 12 Feb 2019 22:05:06 +0100 Marcel Hollerbach said:
>
>> Here is the try to get a technical discussion:
>
> let's solve these before landing, shll we? if they were just bugs i would have
> fixed them, but as there are "bugs by design" it needs to go back to the
> drawing
> board.
Yes, that is why i am sticking things into review, and tbh. a ownership
discussion is nothing that sends back things onto the drawing board :)
>> 2.:
>>Yes, this is a design decision for now, the string that is forming a
>> command is not taken care of, reason for this is, that in most usecases
>> that i have seen the strings are eitherway allocated on the stack of the
>> function, or are global (argv) and are also not heap allocated (in our
>> meaning). If this does not work out in other usecases, then i can
>> happily agree with a patch to change that :)
>
> rethink ownership. but what you have is wrong. i have examples where they are
> generated on the stack with multiple args .. so parent does have to allocate
> space and cant use a single fixed size buffer. if ownership goes to the array
> consistently then it's at least consistent (and the api consumes the array
> entirely including strings), but it's not like this. i brought this up and it
> was not addressed before landing the patch.
Can you write some pseudocode? Because your example suites perfectly
well what this is written for.
You have:
- Allocated strings on the stack,
You do:
- Allocate an eina_array
- Add all your stack strings into it
- Pass it to the function
- Be happy with it.
>> 4.: this will be fixed :)
>>
>> For anyone new to this discussion: This is about getting the abstraction
>> of environment variables / command lines away from our generic task
>> interface and get them into something which stands more alone, so it is
>> more usable.
>
> let's get ownership sane and consistent. the env one is ok in that regard,
> though i need to see the impl for the same env object when its NOT the global
> (u e.g. create or duplicate then modify it).
>
> i still don't like it s its extra code/work for the caller for sure, but it
> seems you guys all want to make efl worse to use from c. i'm beginning to
> re-evaluate if i wish to use efl in future as it marches on in this direction.
> i'm distinctly unhappy about it.
Yeah, i even pinned a giant poster over my bed "Make C hard to use" so i
really believe in it.
No, but honestly, i am not trying to make life in C harder. Moving the
POV from the amount of
chars per API call, into something like usage range of our abstraction
shows you that efl_task is now usable in a wider range, and even efl_env
is more powerfull than before. Further more, compare the bindings code
before and after the patches, you will see that the code integrates much
nicer now, while its a little more (expressive) code in C.
Greetings,
bu5hm4n
>
>> Greetings,
>>bu5hm4n
>>
>> On 2/12/19 9:26 PM, Carsten Haitzler wrote:
>>> raster pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=d6294fa22b88187e44391c1c8ca64b1ebdf14533
>>>
>>> commit d6294fa22b88187e44391c1c8ca64b1ebdf14533
>>> Author: Carsten Haitzler (Rasterman)
>>> Date: Tue Feb 12 20:11:44 2019 +
>>>
>>> Revert the env object because it's broken portability - please redo
>>>
>>> setenv and unsetenv are not portable. i explained to you at fosdem
>>> there are issues and it's why i used putenv in the original
>>> implementation and even though it's a pain (the string tou pass to
>>> putenv is a pointer used literallt from there on in and you get it
>>> from getenv, thus making ownership a pain -this is a libc issue we
>>> can't readily solve). use putenv like the original code. then put it
>>> back in. vtorri now has windows porting issues with the setenv use. i
>>> knew there was a reason that still existed...
>>>
>>> in addition your in_sync stuff is broken. psuedocode:
>>>
>>> // assuming BLAGH env is not set to anything here
>>> c = efl_core_env_get(global_env, "BLAH");
>>> ...
>>> putenv("BLAH=10");
>>> ...
>>> c = efl_core_env_Get(global_env, "BLAH");
>>>
>>> i will get NULL in both cases for c ... but i should get "10" for the
>>> 2nd in reality. reality is lots of code across application code and
>>> libraries will at times mess with the environment. it has to work with
>>> this. the prior implementation did work with this.
>>>
>>> Revert "ecore: here comes a env object"
>>> This reverts commit 2373d5db5b4cd5dfe139aa2a10017ef61b28b5ce.
>>>
>>> Revert "efl_task: remove env from this object"
>>> This reverts commit c3d69f66a69c0def357a5c373a13343e1c01ff5d.
>>> ---
>>> header_checks/meson.build | 3 +-
>>> meson.build| 1 -
>>> src/Makefile_Ecore.am | 7 +-
>>> s
Re: [E-devel] [EGIT] [core/efl] master 02/02: Revert the env object because it's broken portability - please redo
On Tue, 12 Feb 2019 22:05:06 +0100 Marcel Hollerbach said:
> Here is the try to get a technical discussion:
let's solve these before landing, shll we? if they were just bugs i would have
fixed them, but as there are "bugs by design" it needs to go back to the drawing
board.
> Problems you have pointed out:
> 1. Portability
that is just a bug, but it's combined with #2 below
> 2. Ownership
> 3. Pseudocode example
> 4. strdup into a const char*
yup. a bug plus a design issue - what should it be? who should own the
result? strduping here is probably NOT a good idea.
> 1.:
>Free/Openbsd meanwhile has setenv,
> (https://www.freebsd.org/cgi/man.cgi?query=setenv&sektion=3&manpath=freebsd-release-ports)
>Windows has setenv etc. due to evil, and vincent pointed his "issues"
> out in https://phab.enlightenment.org/T7693, where i still fail to see a
> reason why this fails.
i remember over the years needing to use putenv instead of setenv. multiple
times. so i've made it a policy to stick to putenv.
> 2.:
>Yes, this is a design decision for now, the string that is forming a
> command is not taken care of, reason for this is, that in most usecases
> that i have seen the strings are eitherway allocated on the stack of the
> function, or are global (argv) and are also not heap allocated (in our
> meaning). If this does not work out in other usecases, then i can
> happily agree with a patch to change that :)
rethink ownership. but what you have is wrong. i have examples where they are
generated on the stack with multiple args .. so parent does have to allocate
space and cant use a single fixed size buffer. if ownership goes to the array
consistently then it's at least consistent (and the api consumes the array
entirely including strings), but it's not like this. i brought this up and it
was not addressed before landing the patch.
> 3.:
>For the next time i would love to see a testcase, if you would have
> gone the path of a testcase, then you would have seen that this actaully
> works ... :)
oh indeed you're right - i was reading the code and missed the setting in_sync
to false at the end of _sync(), though the implementation will be fairly
expensive to set env's to do this sync every time u set or unset something. it
probably should directly putenv() and appropriately find and free or modify the
shadowed ptr for that env string only rather than brute force sync.
> 4.: this will be fixed :)
>
> For anyone new to this discussion: This is about getting the abstraction
> of environment variables / command lines away from our generic task
> interface and get them into something which stands more alone, so it is
> more usable.
let's get ownership sane and consistent. the env one is ok in that regard,
though i need to see the impl for the same env object when its NOT the global
(u e.g. create or duplicate then modify it).
i still don't like it s its extra code/work for the caller for sure, but it
seems you guys all want to make efl worse to use from c. i'm beginning to
re-evaluate if i wish to use efl in future as it marches on in this direction.
i'm distinctly unhappy about it.
> Greetings,
>bu5hm4n
>
> On 2/12/19 9:26 PM, Carsten Haitzler wrote:
> > raster pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=d6294fa22b88187e44391c1c8ca64b1ebdf14533
> >
> > commit d6294fa22b88187e44391c1c8ca64b1ebdf14533
> > Author: Carsten Haitzler (Rasterman)
> > Date: Tue Feb 12 20:11:44 2019 +
> >
> > Revert the env object because it's broken portability - please redo
> >
> > setenv and unsetenv are not portable. i explained to you at fosdem
> > there are issues and it's why i used putenv in the original
> > implementation and even though it's a pain (the string tou pass to
> > putenv is a pointer used literallt from there on in and you get it
> > from getenv, thus making ownership a pain -this is a libc issue we
> > can't readily solve). use putenv like the original code. then put it
> > back in. vtorri now has windows porting issues with the setenv use. i
> > knew there was a reason that still existed...
> >
> > in addition your in_sync stuff is broken. psuedocode:
> >
> > // assuming BLAGH env is not set to anything here
> > c = efl_core_env_get(global_env, "BLAH");
> > ...
> > putenv("BLAH=10");
> > ...
> > c = efl_core_env_Get(global_env, "BLAH");
> >
> > i will get NULL in both cases for c ... but i should get "10" for the
> > 2nd in reality. reality is lots of code across application code and
> > libraries will at times mess with the environment. it has to work with
> > this. the prior implementation did work with this.
> >
> > Revert "ecore: here comes a env object"
> > This reverts commit 2373d5db5b4cd5dfe139aa2a10017ef61b28b5ce.
> >
> > Revert "efl_task: remove env from this object"
> > This reverts commit c
