Sometimes I make releases without compile testing.
- User Since
- Jan 24 2013, 12:55 AM (343 w, 1 d)
I missed this somehow.
Looks pretty good
I suppose I'm okay with a one-time config upgrade for this case. But for future cases then it should work as I described.
No, that's the specific case that D9708 fixed.
This needs doc cop review. I'm okay with it.
I think I may have fixed this case with D9708?
Historically in EFL projects we've just added keybindings based on version changes, e.g., version X adds keybind Y, so add Y to the config when doing the X upgrade. This change would add back bindings which have been manually deleted by users. Instead, the bindings update function should just copy the system config (and then not destroy the system config unnecessarily) for the config version being upgraded for.
Seems good overall.
There's not actually a single change to src/tests/elementary/spec/efl_test_multi_selectable.c in this patch which has any relation to the rest of the patch despite the changes being significant. Can you break this out?
A small but significant nit: there's no specification in the doc about what happens if end is greater than the total number of items. In _range_selection_find you handle this by verifying the end marker for the range and erroring if it isn't found (without making the change). This seems like probably not what app developers expect, and it certainly is not specified in the docs.
I think the list -> array should be broken out into a separate patch (using git-phab). Also some other minor nits. Seems fine otherwise though.
@smohanty Are you doing anything after those calls? You might accidentally be triggering an edje recalc that reapplies the default class.
I've removed this functionality entirely since there is currently no demand for it and we aren't able to come to an agreement.
remove configurability of styles
do not access data outside of main thread lock
I suppose we can agree to disagree on a number of things here. I don't see continuing this discussion as productive on any level.
This patch continues to dereference the parent pointer in the thread outside of proper locking, which means it is potentially dereferencing a garbage pointer. In addition to my previous comment regarding access of delete_me outside of locks, this patch also dereferences parent outside of locks, which can (and sometimes is) a garbage pointer.
Yea tbh this doesn't actually fix the issue even if we disregard the previous issue that I cited. I've prepared another patch which avoids it entirely.
scalable is gone, drop is @beta (and we can ignore it). All that's left is icon.
My issue with a property for this is that then it seems like this opens up the possibility of having this sort of property in more places. I don't think we want to end up with properties to set styles for internal objects anywhere, as they should generally be using the same style as the widget. This is a special case where the internal widget should not be using the same style.
I smashed align out. I wonder if we could do something with efl.file to replace icon in some way.
There's no notes in the patch which added this, so I think we can just assume that it was a mistake.
I don't see a particular reason why it should be @protected other than preventing people from potentially footgunning themselves by overriding it improperly.
This is a very poorly named macro...