User Details
- User Since
- Jan 27 2013, 3:07 PM (523 w, 1 d)
- Availability
- Available
Feb 27 2022
seems correct, I will include this in the upcoming 1.26 release and in the 1.25 branch soon
Sep 24 2020
Apr 29 2020
Apr 12 2020
Great!
thanks
Apr 11 2020
great, I can confirm the fix
Apr 10 2020
Mar 19 2020
great, now we have two different working workarounds
Mar 18 2020
can you try using clang instead of gcc? like @rbtylee suggested
Oct 6 2019
Aug 31 2019
Great, I committed the fix in commit 1d5202f866e0
Aug 28 2019
hmm, I think the issue the is quite simple here and caused by the logic of counting available pakages. The code is in e_mod_packagekit.c around line 27
the module is counting available updates based on the type, the code is:
Jun 2 2019
PythonEFL version must always be in sync with EFL.
The 1.22 release build normally against efl 1.22
May 5 2019
Seems good to me
Thanks for taking care :)
Apr 27 2019
worksforme
thanks !
Apr 26 2019
I think, this was solved. Please reopen if it still apply
Apr 23 2019
Indeed, works for me!
Feb 6 2019
The issue is 1.20, there was some fixes in 1.21 to work with py3.7
Feb 5 2019
Hi Simon,
I'm using only python3 since years, I'm not testing even more on py2.
Dec 20 2018
Maybe this page can be useful for this task
Nov 28 2018
Guys you are too fast for me to review :)
Oct 29 2018
ah, yes, the issue is visible also resizing the window, It's the first time I try to resize the window.
The bug is also visible when you press one of the button to perform the animation, so I don't
think thi is related to window resize. Seems more like swallows are not in sync.
Oct 28 2018
add some more subscribers to keep this thread alive...
Sep 26 2018
@devilhorns: This issue is present in stable efl since the first day of the 1.21 release, cannot be related to the recent animator changes
here a screenshot of the issue:
As you can see the home icon in the squared button is out of place while animating
Sep 2 2018
Sep 1 2018
Aug 29 2018
Great, thanks for taking care of the tutorial :)
Aug 28 2018
The behavior you see is correct, size_hints are meant to size and position the object itself, not it's content (in this case you are aligning the text object bounding box).
Aug 26 2018
Aug 22 2018
News on this issue:
Aug 17 2018
Indeed D6860 fix the scroll-bar visibility and seems to restore the old behavior
Aug 4 2018
hmm, the slowness of first show is indeed solved in the test and in other lists of mine that was affected.
Jul 21 2018
Jul 13 2018
There was already a wiki page for this: Efl 2.0 Todo, items there should be merged here and the wiki page should be deleted. Otherwise we continue to scatter info around
Jul 12 2018
This does indeed fix T7121.
Just to be pedantic I would have used EINA_TRUE/FALSE instead of 0/1 to make clear it's a bool and not an int
Jul 11 2018
I digged this issue for some hours now, I tryied all the existing tests (both C and python) but none show the issue.
no, not with any test, just with epymc. Seems related to elm_list, this evening I will check all the elm_list tests around.
Jul 10 2018
Jul 9 2018
Indeed hiding the frame instead of the progressbar fixed the issue, thanks for the advice, I fixed the code.
I gave up on using the elm focus in my media center some weeks ago, I wrote a custom focus handling instead.
I gave up on using the elm focus in my media center some weeks ago, I wrote a custom focus handling instead.
Apr 28 2018
Apr 24 2018
@stephenmhouston there is no patch to post, you just need to revert rEFLfd82c2521ebb to test.
Apr 22 2018
I now tested the behaviour in all last 9 release, using the visual test elementary_test -to "genlist group tree" as per rEFL558f4c36ac7f
EFL 1.12 -> Flat EFL 1.13 -> Flat EFL 1.14 -> Flat EFL 1.15 -> Flat EFL 1.16 -> Flat EFL 1.17 -> Flat EFL 1.18 -> insane EFL 1.19 -> Flat EFL 1.20 -> Flat
Apr 21 2018
I think we just need to revert rEFLfd82c2521ebb and adjust the test case, I can do both as I already have a correct test to use.
Apr 20 2018
I spent the last week studing this issue and setting up 9 virtual machines to test the behaviour in the last 9 stable releases of efl and elementary (a really long and annoying task!).
This is the test used to prove that T5938 is wrong.
Apr 14 2018
Ok, I run an extrapolated version of the test on current git (without my latest commit) and on 1.20.6
You can see the source I used here: F3025190
so what you are saying is that the test you wrote works on stable 1.20 ? I don't think so...
hmm, there must be some difference on how epymc and empc use the genlist group feature. The test case @zmike wrote assume a behavior that is different from the one I was getting in efl 1.19 and 1.20... I'm a bit confused now...
@zmike ah, you right, the test is failing now, sorry I didn't know there was a test for this.
Apr 13 2018
This changes behavior again - not just preserving legacy - so not exactly a simple patch and not exactly a good idea to just yolo push change behavior - you should have posted the patch here first and let others review. That said -- As long as no other apps are depending on the ordering your are changing , and as long as nothing is broken, it will probably pass.
I restored the old behaviour with commit rEFLf0a0da9f449b
Apr 12 2018
@stephenmhouston I agree with you in the case of a tree genlist, while I was talking just about groups.
maybe I wrote the graph wrong, as your last comment seems non-sensical to me, I try again:
The point is that the new behaviour of item_next_get() seems wrong to me.
Really we want item_next() on a group item to return the next group item instead of the normal next item?
Apr 11 2018
I'm noticing now a break in my mediacenter most probably caused by the @jpeg patch applyed.
Apr 7 2018
Why do you want to have the type encoded ? Where does it help you to know the type of a entity while writing code?
I'm replying only to this first question because I think this is the focal point of this discussion:
having the type of the class in the name does not help while writing code (for all the reasons you already mentioned) but help
new developers to understand and orient himself while LEARNING efl and all the classes that we are going to provide.
Apr 6 2018
I'm on the same side of @herdsman here: explicit is bettern than implicit!
Apr 2 2018
when it freeze I see this last error:
Re-opening this... as I found 2 new issue:
This one is somehow related to in-theme focus highlight.
If you switch to normal focus highlight (epymc/data/themes/default/elm_extension.edc:627) the issue go away,
You can at that point see a different issue where the first genlist item is not highlighted on fist show.
well, I still have the random jumping when scrolling long lists...
Mar 16 2018
Mar 11 2018
fixed by commit e9348193c4fd58fe2884c28248208e1a83240af3
Feb 24 2018
Some update on this: I just added the ability in test_focus6 to move the focus by API, that is what I'm doing in EpyMC, but it works as expected in the test so... this is not my issue :(
Feb 18 2018
Some more info after a morning of digging in the systray code:
Feb 17 2018
@raster: thanks, you are my hero !
Feb 9 2018
WHAT THE FUCK ?? Stop changing the priority to "Pending on user input" !!!!
pending on user input.... :/
I read again the report-bug document and the only thing I missed seems to be:
can't you reproduce this issue ?
Feb 1 2018
Jan 25 2018
Jan 24 2018
a little preamble: I'm not speaking about the bryce work, but just about the sandbox infra (as per thread title)
Jan 23 2018
- The main feature I miss in bryce is the ability to move/resize gadgets as it was before (without having to know obscure keybindings)
- I was comparing sanboxed gadgets to Edgar gadgets (not modules written in C). So my point is valid, and (trust me) edgar gadgets are much more easier that sandoxed ones.
Sorry, but I really have no idea how the same performance and easy-of-use of edgar can be obtained with the sandbox infra.
I only have one clean solution for this problem, and it's already coded and perfectly working: it is called edgar :)
Jan 22 2018
I don't like the idea of the underscore prefix as suggested by @barbieri: in python the obj.__xxx__ notation i used with a really clear definition: all of them are special methods that are automatically called by the language in specific case, fe the obj.__str__method is called when you do print(obj), the obj.__init__ is called when you create an instance, the obj.__gt__ is called when you do obj1 > obj2... an so on. A really clear and explicit definition, while our eo.name is not special in any way, nor it's different from efl.net.tech.name. I also cannot find a rule/definition to underscore eo.name... at least without underscoring all Efl.Object methods (_parent, _comment, _del, etc).
Jan 21 2018
As per today irc discussion:
Jan 19 2018
what I need to check? I cannot see any commit from you in master nor in any branch of yours...
Jan 5 2018
I wrote a new test in elm_test (Focus 6), it is pratically the same layout of my mediacenter and it have similar issues.