I'm testing some GTK+ examples.
At some given function, a reference to some path of a XML file appears in
C code. It explains that the code in C is reading the XML content to
later compile it to be usable from the C code:
static void
example_app_window_class_init (ExampleAppWindowClass *class)
{
gtk_widget_class_set_template_from_resource (GTK_WIDGET_CLASS (class),
"/org/gtk/exampleapp/window.ui");
}
I can understand what is happening here, but not how is it reading the source XML? window.ui, in this case. Because the repo has no folder
as they mention (/org/gtk/exampleapp/).
So, in my function I expect to do something like:
static void my_style_window_class_init(MyStyleWindowClass *class) {
gtk_widget_class_set_template_from_resource(GTK_WIDGET_CLASS(class),
"window.ui");
}
All my XML content is in the same folder as *.c and *.h files. This is a testing decision and have no other meaning.
The _from_resource() part of the function name indicates that the path /org/gtk/exampleapp/window.ui is not a filesystem path, but rather a resource path. Resource paths tie into a feature of GLib called GResource which allows you to embed binary data inside a program or shared library.
You would write an XML file to describe what local files map to what resource paths, and then as part of your build process, you would convert that to a C source file with the glib-compile-resources tool. You then build that C source file into your program. The full details are on the page that I linked in the first paragraph.
(Note that these are not the same as the embedded resources in Windows executables, which use a different technology altogether, but work in similar ways.)
If you want to load something from a file, GLib and GTK+ and other libraries built on them provide a _from_file(), _from_data(), or _from_stream() alternative to the _from_resource() function. _from_file() reads the data from a file directly. _from_data() reads from memory. _from_stream() reads from a GStream, which is an object-oriented I/O endpoint defined by GLib in its GIO module. The function name suffix is optional; it varies.
In the case of gtk_widget_class_set_template_from_resource(), the equivalent provided is gtk_widget_class_set_template(), which follows the _from_data() pattern of reading from memory. The memory is stored in a GBytes object, so you have to read from your local file into the GBytes.
It's an oldie and the question seems answered but I'd like to take a direct approach and place solution - turns out that we can substitute this line
gtk_widget_class_set_template_from_resource (widget_class,
"/org/gnome/gtksourceview/tests/ui/test-widget.ui");
with this line to make the code work.
if (g_file_get_contents("test-widget.ui", &contents, &len, &err) == FALSE)
g_error("error reading test-widget.ui: %s", err->message);
bytes = g_bytes_new_take(contents, len);
gtk_widget_class_set_template(GTK_WIDGET_CLASS(klass), bytes);
Related
I'm trying to understand how I can create a ".config" file containing a bunch of parameters to later use to set up the variables in my C project on Unix.
I created my ".config" file using sudo nano test.config and wrote some stuff inside such as:
#N is this
N 10
#p is that
p 0.002
#T is this
T 10
Now that I did that how can I read its content and use it to initialize my variables?
The several answers to this question explain how to parse that config file, but you could use standard parsing techniques (perhaps your own recursive descent parser) or Glib's lexical scanning or key-value pair parser (or use something else). You certainly should define and document (perhaps using EBNF) what is the format of that textual configuration file (and what the various entries there represent: for example, if that configuration file refers to other files, how do you handle spaces in such file paths, etc....). A common (but not universal) convention is to consider as comments so skip any line starting with #.
Another question is how to get that config file while running in an arbitrary working directory. You just need to build the absolute path of your file (for fopen(3) or open(2)), e.g. with
char configpath[100];
snprintf(configpath, sizeof(configpath), "%s/.test.config", getenv("HOME"));
You could test before that getenv("HOME") is not NULL, but in practice that is very unlikely; see environ(7) and getenv(3); and the case when it gives a very long file path is also unlikely; you might test that snprintf(3) returns a count less than sizeof(configpath) or use asprintf(3).
You might use other functions, e.g. glob(3) or wordexp(3) to get that file path (but you probably should stick to snprintf or asprintf with getenv("HOME")...).
You might consider instead embedding some scriptable interpreter like lua or guile in your program (but that is a strong architectural design decision). Then the configuration file becomes some (Turing-complete!) script.
BTW, there is no need to use sudo to edit that configuration file (under your home directory), and you might decide to also read some system-wide configuration under /etc/
I'm creating a library to provide access to another library.
The library in question is a vendor, so not everyone should access this library.
One solution to do so is to put the library on a specific group (AIX) and then put everyone that can compile using it in the same group.
This solution don't works here because there are a lot of new people coming in and out, and the user that compiles (Its a process that do this operation) is not the same as the user that can access the code.
The solution i'm trying to archive is.
Every application have an pattern on their directory.
/Aplications/Group/...
So i can get the Group using the folder when the program runs.
What i am trying to do is.
Create a library that checks the directory and then loads the library using (loadAndInit) the dlopen function on AIX that already loads all the symbols, so i don't need the dlsym.
The problem is, i want to put the binary code of the library i want to load inside my source code.
WHY: Because if App -> Lib (Loads) -> Vendor, nothing can limit the developer from doing an link by hand or compiling by hand the App -> Vendor.
And the structure that call the compilation process cannot limit that.
What i have tried.
Convertlib
FILE* file=fopen("vendor.so", "rb");
int c;
do{
c=getc(file);
if(c > 0)
printf("\\x%02x", c);
}while(c!=EOF);
Then i have a little script that puts the output of this file as a
char *lib=(char* (malloc(sizeof(char) * /* lib size */));
lib="/*output of the Convertlib*/
Then i try to load it using fmemopen, so i dont create a temporary file just a file descriptor inside my process area.
To load it i do
FILE* vendorLib=fmemopen(lib, /*libSize*/, "r");
char path[50];
sprintf("/proc/%d/fd/%d", getpid(), fileno(vendorLib));
loadAndInit(path, 0, "");
If i call directly a lib (i have it to test) and dont load using the hex formated library it works.
But as i converted my binary code to hex and i'm trying to load it, it dont work.
Should i convert back to load it on the memory and use it as an library again?
This seems the only solution to work with, as the library is a vendor i cannot change it and it is the only way i see to limit the access because we have here more than 1000 programmers
I solved it using
printf("\x%02x", thechar);
Inside the getc loop
So i wrote it inside a memcpy then i copy to the memory so the binary file is stored as HEX data.
Works perfectly
I am writing an app in C and using Glade3 to make the GUI (and GTK builder).
Glade 3 doesn't allow C code generation anymore (which I understand the reasons for), but now all applications need to have the XML file hanging around the compiled app like an annoying .dll file. Does anyone have any knowledge of project to create C code for it, or how to embed the XML file in the code itself? I imagine this could be done, but it would be a pain I bet.
What you probably want is:
gtk_builder_new_from_string(const gchar *string, gssize length);
https://developer.gnome.org/gtk3/3.10/GtkBuilder.html#gtk-builder-new-from-string
Just stringify the glade3 xml file (in GtkBuilder format) and include it as a string.
It is still possible to use glade-2.12 to generate gtk2 code and then port it to gtk3; however if you are going to do that it may be worth it to simply modify that version of glade to output the gtk3 syntax directly.
Is there a C library function to get the extension of file? I know that I can design a function on my own to get extension after '.' but not all files are stored with their extensions when we read them.
So you'd like to get the type of a file? Maybe the command 'file' in Linux is what you want. You can check its source code.
The file command in Linux uses a library called libmagic (don't confuse with libmagick) to check the 'magic' bytes in the file itself to determine the likely content type.
The library is fairly cross platform, it's well documented, for example here:
http://linux.die.net/man/3/libmagic
I am trying to understand the different file extensions for the pfxplus powerflex database. Could someone please help telling me briefly what each file is for?
.k1
.k2
.k3
...
.k13
.k14
.k15
.fd
.def
.hdr
.prc
.pc3
Data files:
OK, so .dat is the data file.
.k1 -> .k15 are index files.
These are the critical data files for runtime. (Combined with filelist.cfg or pffiles.tab similar to define what files are available overall).
.fd is the file definition, needed for compiling programs
.tag (which you did not mention) is needed only if you need to access field names at run time (such as using a generic report tool)
.def is the file definition in human readable form, and is not needed by any process but is produced so a programmer or user can understand the file structure.
Run time:
The .ptc files are the compiled threads interpreted by the powerflex runtime.
The .prc file is a resource file that is used at runtime in conjunction with the .ptc file - it defines how a character based program is to look in a gui environment in "g-mode". It was the cheap way to upgrade character based programs when windows first started getting popular usage.
.hdr and .pc3 escape me at the moment, but are vaguely familiar - .hdr is probably another data file used with compression or special field types for later versions of pfxplus. .pc3 may in fact be the .ptc files...