Page MenuHomePhabricator

Efl.Gfx.Image
Closed, ResolvedPublic

Description

interface Efl.Gfx.Image
├ (P) smooth_scale
├ (P) scale_method
├ (P) can_upscale
├ (P) can_downscale
├ (P) ratio
├ (P) content_region
├ (P) border_insets
├ (P) border_insets_scale
├ (P) center_fill_mode
├ (P) stretch_region
├ (P) image_size
├ (P) content_hint
├ (P) scale_hint
├ (P) image_load_error
├ (E) image,preload_state,changed
├ (E) image,resized

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
bu5hm4n created this task.May 3 2019, 11:32 AM
bu5hm4n triaged this task as TODO priority.
zmike moved this task from Backlog to Evaluating on the efl: api board.Aug 29 2019, 7:49 AM

We probably need this since it's used with image.

The event names need to be tensed, ratio probably needs a rename to aspect_ratio?

Agreed, and ratio should be aspect_ratio for sure.

More change proposals:
border --> border_size
border_center_fill --> center_fill_mode

Small question

(p) image_size, does it mean original image size, or image size after applying ScaleType ?
I am asking this, because sometimes user need to calculate scale-factor for image. (origin vs current)

As the documentation says: This represents the size of the original image in pixels

I suggest small Idea
Property to read scale_factor (Width, Height).

zmike added a comment.Sep 2 2019, 5:45 AM

More change proposals:
border --> border_size

Maybe border_insets or something? This is a pretty bizarre property...really wish it could just be specifying the solid region's geometry instead.

border_center_fill --> center_fill_mode

Approved.

image,resize needs to be image,resized and have size event info...

Now that I think about it, the other events are wrong too. They should be at minimum preloaded and unloaded. I'm wondering whether preloaded makes sense though. Why isn't this just loaded?

Taking it even further, if we have load and unload, why not just have load_state,changed or similar and just pass a bool?

border_insets sounds about right, since that's what this property is.

All events should be in the past tense, sure. I would need to know what the preload event represents, though.
Why do we have preload and unload, instead of just load and unload? In that case, the load_state, changed would make a lot of sense.

zmike added a comment.Sep 16 2019, 7:00 AM

preload is supposed to mean that the image data has been loaded and can be displayed. In a sense, this is an image domain specific term (i.e., "image preloading" is a thing), but for the purposes of this API, preload and unload are opposing states. I suppose maybe preload_state,changed would be the most accurate, or perhaps even preload,changed?

Thinking more about it, we use the ,changed suffix for events when there's an associated property. I think it would be weird to use it in this case.
When's the unload event emitted, anyway? do we have an unload method?

zmike added a comment.Sep 16 2019, 8:11 AM

unload is called internally when the image's data is unloaded (e.g., if it's being reloaded) and can no longer be displayed.

We use changed when a state has changed. This seems like a state?

Yeah, but it's an internal state, not accessible through any property. Anyway, no point in discussing it any further since I have no strong opinion on this, either way works for me.
I prefer preload_state,changed over preload,changed, though.

zmike added a comment.Sep 16 2019, 9:37 AM

My thinking is primarily that anyone who is interested in a preload event is also likely to be interested in an unload event, which means they need 2 event subscriptions. More event subscriptions = bad.

I already greenlighted thiiiiiiiiiiiiiis :D

I'M TRYING TO DOCUMENT IT FOR WHEN SOMEONE GETS ANGRY LATER WTF

This is done ?

zmike updated the task description. (Show Details)Sep 23 2019, 6:17 AM

OP updated

zmike moved this task from Evaluating to Stabilized on the efl: api board.Sep 24 2019, 9:53 PM
zmike updated the task description. (Show Details)Sep 25 2019, 7:28 AM