It might be good for mwm.v or image.v to have some type of it's own image storage mechanism. So that how images are handled when using mwm, is more similar to how other controls are handled or at least as convenient.
I guess the issue causes by gg. gg is clearing images when close. So image can not be reloaded.
Images is an exception in MUI. It's not handled by path directly. The path will not be stored. The path will be opened by gg. And the pointer will store the image. When the window was closed, gg is releasing the images. So i need to self-cache images or find a way to force gg to store these caches.
Yes, you correctly identified what's happening. You seem to have been going down the path of caching or storing the images with mwm, which might be another good way, after more experimenting.
A kind of problem with using gg specifically, in addition to mwm, is control of the images from that point. Making changes and handling the images, is different from what's done with the other controls. With the present example, manipulating or switching to different images, can possibly become confusing.
It might be better if the user doesn't have to import both gg and mwn, and can simply use mwm or image, which would also have has some type of image caching or storage mechanism. From the user perspective, it could be viewed as smoother or more convenient. Putting other options, like arrays or associative arrays for images in types (WindowConfig) might be something to consider as well.
Looking again at the related example, possibly also show another example with init_fn: being used to call a more easily identifiable separate function. The reason why this might could use another example, is to show: multi-window programs, using lots of different images, and/or switching among different images.
It might be good for mwm.v or image.v to have some type of it's own image storage mechanism. So that how images are handled when using mwm, is more similar to how other controls are handled or at least as convenient.
Yes, you correctly identified what's happening. You seem to have been going down the path of caching or storing the images with mwm, which might be another good way, after more experimenting.
A kind of problem with using gg specifically, in addition to mwm, is control of the images from that point. Making changes and handling the images, is different from what's done with the other controls. With the present example, manipulating or switching to different images, can possibly become confusing.
It might be better if the user doesn't have to import both gg and mwn, and can simply use mwm or image, which would also have has some type of image caching or storage mechanism. From the user perspective, it could be viewed as smoother or more convenient. Putting other options, like arrays or associative arrays for images in types (WindowConfig) might be something to consider as well.
Looking again at the related example, possibly also show another example with
init_fn:being used to call a more easily identifiable separate function. The reason why this might could use another example, is to show: multi-window programs, using lots of different images, and/or switching among different images.