The issue is 1.20, there was some fixes in 1.21 to work with py3.7

Hi Simon,
I'm using only python3 since years, I'm not testing even more on py2.

Maybe this page can be useful for this task

Guys you are too fast for me to review :)

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.

add some more subscribers to keep this thread alive...

@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:

Great, thanks for taking care of the tutorial :)

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).

News on this issue:

Indeed D6860 fix the scroll-bar visibility and seems to restore the old behavior

hmm, the slowness of first show is indeed solved in the test and in other lists of mine that was affected.

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

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

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.

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.

@stephenmhouston there is no patch to post, you just need to revert rEFLfd82c2521ebb to test.

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

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.

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.

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.

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

@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?

I'm noticing now a break in my mediacenter most probably caused by the @jpeg patch applyed.

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.

I'm on the same side of @herdsman here: explicit is bettern than implicit!

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...

fixed by commit e9348193c4fd58fe2884c28248208e1a83240af3

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 :(

Some more info after a morning of digging in the systray code:

@raster: thanks, you are my hero !

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 ?

a little preamble: I'm not speaking about the bryce work, but just about the sandbox infra (as per thread title)

1. The main feature I miss in bryce is the ability to move/resize gadgets as it was before (without having to know obscure keybindings)
2. 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 :)

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).

As per today irc discussion:

what I need to check? I cannot see any commit from you in master nor in any branch of yours...

I wrote a new test in elm_test (Focus 6), it is pratically the same layout of my mediacenter and it have similar issues.

ok, the latest commit make it (quite) work.

Do you also have in mind how to deny the access to the restricted permissions on gadget runtime?
Otherwise a malignus gadget can just lie in the .desktop file to workaround the system you described.

de nada

Hi, packagekit use polkit to manage permissions, seems quite all distro is going in the direction of allow a local user to update already installed packages without a password.

The function object_from_instance() is rising a:

well... indeed it can be installed... but: it never changed in the past, and probably will never change in the future, so you don't have to copy on every releases. At least I never had to change it in edgar.

fixed by a10a1fa641260adbb9571d3899404b4474629b19

yes, a double click in that "half" state will UNshade the window

no idea from my side, I remember I fixed another one related to e_open but I never looked into this one