After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 527094 - Allow the user to include glade files statically in code
Allow the user to include glade files statically in code
Status: RESOLVED WONTFIX
Product: anjuta
Classification: Applications
Component: plugins: glade
SVN TRUNK
Other Linux
: Normal enhancement
: ---
Assigned To: Anjuta maintainers
Anjuta maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-09 09:22 UTC by Tristan Van Berkom
Modified: 2012-07-26 15:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tristan Van Berkom 2008-04-09 09:22:27 UTC
many times, people dont want to distribute the actual 
glade file for ui security reasons, anjuta should provide
an option to take the step of creating a const char *glade_file = "...";
for the user.
Comment 1 Naba Kumar 2008-04-12 19:56:28 UTC
How will the user edit the file if it is inlined in source code? If it is put later in the project after everything's been done, then Anjuta can't really inline it at project creation time.
Comment 2 Tristan Van Berkom 2008-04-13 14:11:23 UTC
I would suggest using a separate file for the inlined glade file(s).
depending on how you want to save project data, maybe just keep the glade
file around and only generate the includable constant glade string
at project compilation time.

I guess its just a question of checking the setting at compile time
and optionally generating a file with the inline code, and changing
the new_from_file() generated line for a _new_from_buffer() line, if
you dont have support for swapping, changing already generated code,
then it would have to be an option you would be stuck with at project
creation time (although I think you could easily enough make a 
wrapper funcion anjuta_load_glade() and implement it differently in
a private anjuta generated source file accordingly, again at compilation
time depending on the setting).

my 2 cents.
Comment 3 Johannes Schmid 2012-07-26 15:23:52 UTC
After discussing with Juan we agreed that you should use GResources for that purpose as this is a cleaner, easier and more portable solution but build single file applications.

I mean, you can still extract GResources but you can also extract strings and if you want real security you will probably have to find another solution anyway.