@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

ok, I got the same error while building on the rpi3 with arch linux installed.

Not that I see so much difference with doc strings disabled,
here the generated C files goes from 511628 lines to 508292

Indeed the problem is the elementary module that is huge,
the only idea on my mind atm is to split again the module as it was before the merge, but It's quite a huge task to do :(

the commit indeed also fix epymc, and now the event behavior seems more correct to me (mouse-move only if the mouse really moved)
thanks @raster

a long standing bug in my mediacenter is now fixed :)

@jpeg Isn't possible for a theme to use an image as bg instead of a rect?
can your automatic discover work with an image? maybe a png image with just some pixels transparent?

I have added one for you ;)

Same for me, here seconds goes from 01 to 60, instead of 00-59

The issue is still there :(

Putting some more info, and some more pressure on @singh.amitesh :-)

any idea how this class inheritance should be done in bindings?

For the moment I'm not a fan of the idea: 1 style = 1 class

+1 for the remove of "Factory" from the name

indeed, you can make it an option: something like "Always spawn the wizard on startup" (on by default)

1+

bu5m4n is right, this is not a bug, it's intended.

Sure, but typing out super long function names like this (with multiple--sometimes unnecessary--parameters) is a pain. Being able to do EXPAND(obj) instead of evas_object_size_hint_weight_set(obj, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND) is obviously a huge improvement for something which is used constantly.

Shouldn't all this live under the Efl.Gfx namespace?
or we have plans to support some kind of non-graphical animation/interpolation?

I agree, the Efl.Ui.Window.Standard should be removed from the Eo api.

https://phab.enlightenment.org/phame/post/view/188/python-efl_1.19.0_release/