Name spaces definition for embedded images

[rossanoparis]

Wouldn't it better to define a name space for embedded images by using the class name?

Instead off

namespace wxue_img
{

perhaps this way would help to maintain unique namespaces among project classes

namespace myclassname_img
{

Another observation is related to the code defined in class header, I think it could be moved on top of implementation file.
Just before the function wxueImage()

namespace wxue_img
{
    // Images declared in this class module:

    extern const unsigned ....
}

// Convert a data array into a wxImage
inline wxImage wxueImage(const unsigned char* data, size_t size_data)

What's the reason to define it in header file?

[KeyWorksRW]

The problem is that as a dev, you don't know where that embedded image is going to be created. It might be created in your class, or it might be created in a different class that uses the same image, or it might be created in the global Images file. wxUiEditor ensures that the embedded file is only created in one location no matter how many times the image is used. By using a global namespace, it ensures that at any time during the lifetime of a project, the image can be added either to another class or to the Images file without having to change any code that uses it.

Just as an aside, if you use the same image in two different classes, where the image gets embedded depends entirely on the order the classes appear in the project file. Should you choose the Sort Forms command, you might find that the image is now created in a different source file. The only way to prevent it from ever moving around based on the project form position is to place it in the Images list file.

[rossanoparis]

Thank you for the explanation.
You are right of course.

Please I dont whant to annoy you or, even worst, being unpolite.
But, something more could be achieved, let me try to explain what I'm thinking about.
As I've already said, your point of view is formally right; eventough the obtained code is lack of style.
For example I'm forced to be careful about images name, because they can't be same; I could have different images called "close" but with different content ...

All you've written can work, and indeed it is working ...
Despite that, I'd like to force you a bit, to look a step forward and try to evaluate if what I'm going to explain could be achieved
It would be wonderful in my opinion.

You should introduce a concept that could be similar to a kind of "resource file" for the entire wxUI project and this file must be included in all single wxUI class into the project.
The content of "resource file" are mainly images, just to begin, but in future probably you will feel like to introduce SVG files, Sounds, HTML files, Texts, PDF Files, ecc ...

In this scenario while a user is designing the UI, she/he could choice to get the resource from the local class or from the shared "resource file".
All I've written regarding the "local" class remain valid and the name space for resources should be called as
namespace myclassname_img ...

Regarding the shared resource file could be something like:
namespace myuiproject_img ... raster images
namespace myuiproject_svg ... SVG files
namespace myuiproject_waw ... WAW sounds
namespace myuiproject_mp3 ... MP3 sounds
namespace myuiproject_html ... HTML code
namespace myuiproject_txt ... Cimply texts
namespace myuiproject_pdf ... PDF content

What do you think about my point of view
Was I able to feed your imagination? :)

[KeyWorksRW]

There are a couple of ways to end up with an identical variable name for two different image files:

1. Same filename, different directories. Allowing for multiple art directories is something I want to add in the future, and that will potentially make the problem worse. The other factor that will have to be dealt with is when there are duplicate filenames in different directories which really are the same image.

2. Unique filenames which don't use valid variable name characters (for C++, Python or Ruby). That includes UNICODE filenames as well as normal ANSI filenames with characters that are valid for a filename but not for a variable name (such as parenthesis). The algorithm wxUE uses is supposed to at least minimize name collision but doesn't guarantee it.

For both of these, my plan is to support an alternate_name property for images. The alternate name can be any valid variable name you want, including using a namespace. The property is already in place, though I think it only shows up in testing versions (if it is showing up, I'll need to remove it from the 1.2 release, since it doesn't affect code generation yet).

The alternate name approach is essentially what Windows resource and XPM files do -- the filename can be whatever you want, but the dev decides what variable name to use to reference the file.

wxWidgets supports a compound document file format via its zlib library. One approach I have thought about is that as an alternative to embedding files, you could simply list the files you want to be in the zlib archive, and wxUiEditor would create that file when you request code generation. That does require shipping one extra file in addition to your program, but that's still preferable to shipping multiple files and/or directories. I want to avoid something like wxFormBuilder which ships 198 files in 16 directories versus wxUiEditor which ships a single file. Like the resource file you mentioned, you could put anything you want in there. I should be able to support aliasing, like the Windows resource file does, so that you don't have to use the full path to the file when you reference it.

Of course, creating the zlib file has its own set of issues. Most people won't want the file under source control management, because as a binary file, any time it changes the entire file will get added as a diff. Generating it during the build process avoids that problem, but the question then becomes what tool is used to generate. Using wxUiEditor is a security risk since you can't easily verify that the output file only contains the source files you requested. There are other tools that could generate it, but they aren't a secure as the standard compiler tools, so again it may not be a security risk companies are going to want to take.

I do realize that having wxUiEditor create embedded images, particularly SVG images where it uses the zlib library is also a risk, though it does avoid the source code management issue since the file is embedded in base64, so diffs are just to the changes in the individual image.