Page MenuHomePhabricator

Improve image support in MVVM
Open, WishlistPublic

Description

The image factory allow for linking a filename with an item that contain an image. It currently is not looking for potential location where this image could be. It would simplify code a lot if we were to provide integration with something like Eina_VPath to automatically search for image in the data path of the application.

cedric created this task.Apr 26 2019, 2:01 PM
cedric triaged this task as High priority.
cedric moved this task from Backlog to Cedric on the efl: mvvm board.

Looking at this, I am wondering if the proper answer isn't to actually handle eina_vpath syntax directly in every file_set operation. @segfaultxavi, @bu5hm4n any idea on the subject?

That is already the case (efl_file.c:96).

However, i am not sure if we want to have something like implicit path searching for files. In case of a factory that searching should be very fast, looking into multiple directories if the path is there does not sound very fast.
It would also bring up the problem that a rendered image is not the expected one because of the same image name.

vpaths looks like a very convenient thing to have. We should also be consistent, so if we allow them in some APIs, we should allow them everywhere. This seems to be already the case, as @bu5hm4n said, right?

I don't think we should look for images in multiple places, though, that'll be slower and cause confusion.

The user only needs to do (in C#): object.File = "(:app.data:)/cool_icon.png";
Right?

If we want to go further and make things even easier we could define something like a "default data folder", and then the user could even skip the (:app.data:) part.
Something like:

some_factory.DefaultDataFolder ="(:app.data:)";
some_factory.File = "cool_icon.png";

This default data folder could be global, or per object, I dunno.

I don't know if that makes any sense :D

That is already the case (efl_file.c:96).

Oh, it was already done! I completely forgot about it.

However, i am not sure if we want to have something like implicit path searching for files. In case of a factory that searching should be very fast, looking into multiple directories if the path is there does not sound very fast.

This task is a bit misleading, at least from a logical point of view the file lookup should be done in the widget as it is a data provided by the Model and can change at any time. The question regarding implicit directory lookup is an interesting one. I can see usefulness in describing a series of directory to look at. If done inside Efl.Ui.Image, it would be expected that it takes slightly more "resource" to do the lookup, but that lookup list would be developer controlled.

My idea for implementing this would be to register an array of directory string on the factory, that will be automatically propagated by the factory on the image. The image would then do a lookup over that list every time a new file is set. What do you think of that?

It would also bring up the problem that a rendered image is not the expected one because of the same image name.

I don't know if that is a problem as long as the developer control the list of directory the application look through, no?

I don't think we should look for images in multiple places, though, that'll be slower and cause confusion.

I guess, I should drop that idea then.

The user only needs to do (in C#): object.File = "(:app.data:)/cool_icon.png";
Right?

Or : object.File = "${app.data}/cool_icon.png";

If we want to go further and make things even easier we could define something like a "default data folder", and then the user could even skip the (:app.data:) part.
Something like:

some_factory.DefaultDataFolder ="(:app.data:)";
some_factory.File = "cool_icon.png";

This default data folder could be global, or per object, I dunno.

I am afraid a global change would have a lot of side effect, but per object or maybe with a provider find. I dunno.

I don't know if that makes any sense :D

That is kind of my question too :-D

bu5hm4n lowered the priority of this task from High to Normal.Aug 29 2019, 4:11 AM

It was clarified that the basics here are set, details still can be improved later on. However, i think this is not anymore a high priority ticket?

cedric lowered the priority of this task from Normal to Wishlist.Aug 29 2019, 5:04 PM

I agree!