also includes:

struct @beta Efl.Ui.Image_Progress
{
   [[
     Structure associated with smart callback 'download,progress'.
   ]]
   now:   double; [[Current percentage]]
   total: double; [[Total percentage]]
}

struct @beta Efl.Ui.Image_Error
{
   [[
     Structure associated with smart callback 'download,progress'.
   ]]
   status:     int; [[Error status of the download]]
   open_error: bool; [[$true if the error happened when opening the file, $false otherwise]]
}

The progress struct seems okay, the error struct is weird and I hate it; if there's no error then the status should be 0 since that's how Eina_Error works (and status is an Eina_Error), and there should be no bool.

Also worth noting that these structs are emitted from io copier events.

Sorry, but the concept of Total percentage confuses me. Isn't that always 100 by definition?

If status is an Eina_Error, shouldn't the eo file reflect it? If it cannot, then I think we have a critical dependency here which needs fixing before anything else.

I am wondering if we could not get rid of Efl.Ui.Image_Error and just use Eina_Error.

As for total percentage, if I remember correctly it is to reflect the multiple step of loading the image. You could be on a 50% of the downloading, but there is still decompressing, uploading texture and so on, so total percentage might be 25% with no indication on time that it would take to do the other percent.

In T7873#137316, @cedric wrote:

I am wondering if we could not get rid of Efl.Ui.Image_Error and just use Eina_Error.

+1

As for total percentage, if I remember correctly it is to reflect the multiple step of loading the image. You could be on a 50% of the downloading, but there is still decompressing, uploading texture and so on, so total percentage might be 25% with no indication on time that it would take to do the other percent.

Then that needs a different name (and better docs). Even with your description it is still confusing :D

In T7873#137316, @cedric wrote:

I am wondering if we could not get rid of Efl.Ui.Image_Error and just use Eina_Error.

As for total percentage, if I remember correctly it is to reflect the multiple step of loading the image. You could be on a 50% of the downloading, but there is still decompressing, uploading texture and so on, so total percentage might be 25% with no indication on time that it would take to do the other percent.

According to efl io copier internals, the total value is always based on the size of the buffer, which in this case means that total should always be 100...

Alright, looking at this:

scalable seems like it should be reduced to T7927?
align feels like we could replicate with Efl.Gfx.Arrangement (and thus remove the property here)
drop we can leave as beta (or comment out entirely) for now since I think this probably isn't supposed to be in this class.

In summary, I think this widget can be reduced to a single icon_name property (which should be renamed to avoid conflict).

• scalable: hmmm.. there's a weird relationship there, since the docs say if $false, the internal image is not scaled up no matter what the scale type is.. So these two booleans seem to go further than the scale_type in Efl.Gfx.Image. Not sure if the implementation supports it, though.
• align: yeah, Efl.Gfx.Arrangement controls the alignment of the content inside the container so it fits nicely here. It also has a padding property that wouldn't be used.
• drop: it should go away, sure. We already have @beta events, but I am not sure how the mono docs react to them.

So this widget would be just a wrapper around Efl.Gfx.Image implementing a bunch of additional interfaces and providing an icon_name shortcut for file names? Seems about right to me.

Why do not we have image object? along side with image viewer/canvas
Almost all systems have image object, which is not directly related to viewing the image.

It contains:

• image Content
• image size
• image type / format
• load/save image

Then We can have ImageBitmap object, which contains bitmap of pixels when rendering image or manipulate or used for image processing

In T7873#139375, @segfaultxavi wrote:

• scalable: hmmm.. there's a weird relationship there, since the docs say if $false, the internal image is not scaled up no matter what the scale type is.. So these two booleans seem to go further than the scale_type in Efl.Gfx.Image. Not sure if the implementation supports it, though.

I think this can be squashed into the 'none' scale hint.

• align: yeah, Efl.Gfx.Arrangement controls the alignment of the content inside the container so it fits nicely here. It also has a padding property that wouldn't be used.

Padding could even be kept since it's pretty trivial to implement? Not high priority though.

• drop: it should go away, sure. We already have @beta events, but I am not sure how the mono docs react to them.
  
  So this widget would be just a wrapper around Efl.Gfx.Image implementing a bunch of additional interfaces and providing an icon_name shortcut for file names? Seems about right to me.

That's always been the purpose, we just had too many duplicated things.

In T7873#139381, @ali.alzyod wrote:

Why do not we have image object? along side with image viewer/canvas
Almost all systems have image object, which is not directly related to viewing the image.

It contains:

• image Content
• image size
• image type / format
• load/save image
  
  Then We can have ImageBitmap object, which contains bitmap of pixels when rendering image or manipulate or used for image processing

There is already efl.gfx.image (interface), efl.gfx.buffer (interface) and efl.canvas.image (class) for lower level image operations. This ticket is only for the higher level widget class.

@zmike I mean, I can not see abstract class to present Image class, canvas is related to view image. but I think there should be Image class to manipulate and interact directly with image object.

For example in other systems:

UIImage
https://developer.apple.com/documentation/uikit/uiimage?language=objc
UIImageView
https://developer.apple.com/documentation/uikit/uiimageview?language=objc

NSImage
https://developer.apple.com/documentation/appkit/nsimage?language=objc
NSImageView
https://developer.apple.com/documentation/appkit/nsimageview?language=objc

Image
https://developer.android.com/reference/android/media/Image
ImageView
https://developer.android.com/reference/android/widget/ImageView

Image
https://docs.microsoft.com/en-us/dotnet/api/system.drawing.image?view=netframework-4.8
PictureBox
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.picturebox?view=netframework-4.8

In T7873#139388, @ali.alzyod wrote:

@zmike I mean, I can not see abstract class to present Image class, canvas is related to view image. but I think there should be Image class to manipulate and interact directly with image object.

EFL is a scenegraph UI system, not a direct rendering/paint oriented system. This lead to some different behavior. For example, having an image class that you give to an image painter make sense in paint oriented system, but in a scenegraph system the library itself will do all the work of opening the image (asynchronously if requested), deduplicating it and then drawing it when needed. This task is about the higher level of abstraction that Efl.Ui. namespace is about. We are not considering direct rendering API as part of the first release of EFL unified API.

@cedric Thank you for your comments :) and explanations. And I am sorry if it bother you

I think Image object should not be part of rendering system (this is the idea), for Image properties (viewing is not part of image properties),properties should be like ImageType, ImageSize, ImageData,

For example if want to save jpg image as png image, So I think the part related to loading image into canvas then save image from canvas, has some waste process(user does not need it).

I think even for some other SceneGraph systems image is presented (I did quick search) like in https://codedocs.xyz/openscenegraph/OpenSceneGraph/a02446.html where It have image object.

I am used for look at things from user perspective (Like Tizen developer), he compare library with other similar framework like UIKit or Android

We are not considering direct rendering API as part of the first release of EFL unified API.
This make me excited a lot forward next releases

I smashed align out. I wonder if we could do something with efl.file to replace icon in some way.

scalable is gone, drop is @beta (and we can ignore it). All that's left is icon.

The icon property seems pretty related to images so I think it fits nicely here.
It could be moved to Efl.File if we added a mechanism similar to eina_vpath, but that looks more inconvenient for the user, no?

In efl_ui_image.eo there exist two structs (Efl.Ui.Image_Progress and Efl.Ui.Image_Error) that do not seem to be in use anywhere.

Alright, we'll keep it here then.

The structs aren't currently used, so they can be marked explicitly as beta for now?

Why not remove those structs? I think errors were absorbed into Eina.Error but I dunno about the Progress one.

The progress one is supposed to be for image downloading events I think. It's actually used internally iirc but isn't in eo.

I think this looks fine by now ?

@zmike @segfaultxavi @bu5hm4n

Hmm. I'm worrying of implementing "Efl.Player" interface (T7877) from this class.

It only implements "playable" and "play", and they are only small parts of the interface,
and I think this interface is something not for GIF player but for Media player.

Could we cut off the relation with "Efl.Player" by changing the property name (or creating new interface for these "playable" and "play") ?

Right now this only works for starting the playing of edje objects, where i do not know if this is even required, as the edje object will play by itself, and freezing the edje object will have the same effekt, as telling the object to pause

What do you think of keeping the efl_player interface beta for now, this would mean that the player interface is not visible to the outside world / c# bindings, but the code can stay as it is right now, and we still can improve that later on.

There was also more talk with @Hermet about the player interface for the animation player widget, which would also require a few adjustments, as of right now, noone implements the full interface, mute and volume is never implemented, so there is also more to check for efl_player.

In T7873#141062, @bu5hm4n wrote:

Right now this only works for starting the playing of edje objects, where i do not know if this is even required, as the edje object will play by itself, and freezing the edje object will have the same effekt, as telling the object to pause

What do you think of keeping the efl_player interface beta for now, this would mean that the player interface is not visible to the outside world / c# bindings, but the code can stay as it is right now, and we still can improve that later on.

There was also more talk with @Hermet about the player interface for the animation player widget, which would also require a few adjustments, as of right now, noone implements the full interface, mute and volume is never implemented, so there is also more to check for efl_player.

This is probably fine?

I agree to keep efl_player interface @beta.

efl_part ? I was talking about efl_player :-D

In T7873#141212, @bu5hm4n wrote:

efl_part ? I was talking about efl_player :-D

Sorry! I just modified my comment :)

This needs implementation of Efl.Gfx.Image and Efl.Gfx.Image_Load_Controller.

Just for posterity, this has implementations of the above-mentioned interfaces.