Sometimes I make releases without compile testing.
- User Since
- Jan 24 2013, 12:55 AM (334 w, 4 d)
It gets unset at the point of being swallowed:
It's planned, but I'm doing something else right now.
I agree that it seems like align could be handled using align_hint.
I think maybe I am not understanding this: what exactly are you proposing?
I think if we are going with a priority system then the most bespoke one should be the highest priority. This would mean cb > values > string.
align_priority is (iirc) a way to specify how you prefer the popup to do layout if it is constrained. We may want to copy/research xdg-popup semantics for this (which I also wrote) since they're a bit more robust.
Fri, Jun 21
Is there anything specific that you don't understand?
This seems like it's just continuing to add more bandaids and workarounds rather than being a prescriptive solution. Is there a reason my ownership proposal would not solve this issue?
There's no docs about it because this is efl.
Thu, Jun 20
Just brainstorming here, but it seems like what we actually want to provide info about is the ownership of events. In the case where the scroller is being dragged, the scroller can be said to own the next mouse-up event, yes? So then for this case it may be useful to add a method of setting an owner property to a sequence of events by allowing it to be set on the input device object: sort of like a "grab". It could look something like this:
It does seem weird to have both.
You can just land this series yourself
Uhh this still fails to apply?
Actually this no longer applies...
A+ for adding the test
This should probably have a unit test?
This seems like it should have a unit test?
But those are for the individual properties and we're talking about the combined property...
Oops, I misread.
No, I meant this as in 'answer these questions in the commit log'
I'm just not sure we want to use zone here, but maybe that's only me. @segfaultxavi what do you think?
Wed, Jun 19
It's used in the code now, so there must be a reason for it...probably.
This seems okay to me other than the doc typo. It needs a real commit message, however, to explain the purpose of the patch.
This chart https://i.imgur.com/QONVIyz.gif
Maybe we need to approach it a bit differently then. Things like packing an object into a box or setting hints during construction should always work (and they do without this patch), but also I think it's important that e.g., efl_text_set should always work on an object. So it may be the case that I need to improve edje internal caching somehow to allow "pre-setting" text and swallow parts or something...
Tue, Jun 18
My first reaction is that this sounds awful to use and is massively overengineered, but I'll sleep on it.
I'm not sure we want to use the word special here since it's just strings? I really would prefer something like format_string_array but then that's misleading because format string is an actual programming term...
Yea I read this before I saw the format ticket comments.
You're just mad because we have all the best memes.
Maybe table_cell instead of position? Feels weird if that has a setter since then there's pack and table_cell_get. Isn't there some kind of interface for calling on packed subobjects for things like this? Maybe there should be one?
I think something more like format_values would be a better name, in keeping with format_ namespacing?
I think it's a corner case. This should be handled through the callback I think, if I'm remembering correctly how that works.
Do we want to perhaps rename range_min_max to range_limits?
As @bu5hm4n has said, I think it's a clear indicator that the API is useful enough to keep if application developers are interested in using it during this evaluation period.