Problem with gtk-doc
Hello! I have problem with gtk-doc. I configured it in my project an everything was fine (i had object hierarchy etc.). Now I added two new source files which decalre two new objects. Gtk-doc sees these new source files, it added symbols to *unused.tx file, but it did not build new documentation pages for them. Morover since I added new files gtk-doc doean's add new symbols to documenattion, even if there are in old files. -- Cya! Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with gtk-doc
hi, Quoting Tomasz Jankowski [EMAIL PROTECTED]: Hello! I have problem with gtk-doc. There is [EMAIL PROTECTED] I configured it in my project an everything was fine (i had object hierarchy etc.). Now I added two new source files which decalre two new objects. Gtk-doc sees these new source files, it added symbols to *unused.tx file, but it did not build new documentation pages for them. You add new types to the *.types file and new api to the *.sections.txt. If its a new section (new type) you add it to the *.sgml file too. *types and *-sections.txt can be autogenerated all the time by gtk-doc if your happy with that (see gtkdoc-scan --help). Morover since I added new files gtk-doc doean's add new symbols to documenattion, even if there are in old files. ??? -- Cya! Tom Ciao Stefan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Fwd: gnome applet w/ bash
well thank you so much for the help you gave me i created my first gnome applet (there is also a cpu graph) and it looks very good! M@ On Mon, 2007-11-05 at 23:50 +1100, Michael Lamothe wrote: Oh dear, #include sys/utsname.h struct utsname name; uname(name); printf(%s\n, name.sysname); printf(%s\n, name.nodename); printf(%s\n, name.release); printf(%s\n, name.version); printf(%s\n, name.machine); Thanks, Michael On 05/11/2007, Matteo Landi [EMAIL PROTECTED] wrote: On Mon, 2007-11-05 at 22:55 +1100, Michael Lamothe wrote: Hi Matteo, I'm not following. What box? A GtkBox? What row? they are just examples Have you thought of using Glade to do your UI work? the fact is that i've started working with gtk two days ago because i was interested in make a gnome panel monitor, and in the tutorial i've found, i create a panel with the bonobo inititialization.. i dont know if i can do this even with glade.. Talking about the spawn, i think the problem is due to the command itself (uname) that at the end print a \n; So i gotta throw away that char from the string to obtaine a one line label, isn't it? M@ Thanks, Michael On 05/11/2007, Matteo Landi [EMAIL PROTECTED] wrote: ok ok that worked, but the output is the same as before... just try to create a box with two labels inside: one createt with label = gtk_label_new (foo); and the other created with label = gtk_label_new (std_output); i got the foo one middle aligned and the second placed on the top of the row.. am i wrong? M@ On Mon, 2007-11-05 at 22:06 +1100, Michael Lamothe wrote: Your pseudo makes no sense, how can you pass a char * into parameter 2 of g_spawn_command_line_sync() when its a gchar**. This worked for me, gchar* std_output = NULL; g_spawn_command_line_sync(ls -al, std_output, NULL, NULL, NULL); printf(std_output); Thanks, Michael On 05/11/2007, Matteo Landi [EMAIL PROTECTED] wrote: Tnx i think that the first one is the function i'm in need of; by the way i cant' make it work, and my gnome panel crashs everytime i run the applet, so i think there is some problems with memory: well, i've got: const char* data (as argoment of a function) char *std_out (created in the function) g_spawn_command_line_sync(data, std_out, NULL, NULL, NULL); is this call right? i think not...but why?? tnx again M@ On Mon, 2007-11-05 at 15:21 +1100, Michael Lamothe wrote: Hi Matteo, There's a few ways to do this, two of which I'll tell you now. Hopefully, you can change your application to use these functions instead. Firstly, there's the g_spawn_ set of APIs designed for this. I think that something like g_spawn_command_line_sync() will do exactly what you want. Basically, GLib calculates and allocates the space required. The documentation mentions nothing about freeing the allocated strings afterwards but I imagine you will have to free the standard_output and standard_error parameters with g_free(). Secondly, if the spawned program is meant to run asynchronously in the background then you'll need to use something like g_spawn_async_with_pipes(). I don't think that this is what you want because you were talking about having to allocate the length of the output. Thanks, Michael On 05/11/2007, Matteo Landi [EMAIL PROTECTED] wrote: thank you very much, that solved one of my problems. here is the second: i'm using a pipe to catch the output of a specific command and store it as a label in the panel; the problem is that if the array containing the output is smaller than the output itself, the line is cut, and the applet is show all middle aligned; if the output is bigger, i get the label splitted in two lines: the first one containing the entire output, and the second one is empty. How could i solve this? maybe with dynamic allocation of memory, but in order to know the output width size, i gotta insert a while that overload the applet isn't it? tnx in advance for the help M@ On Sun, 2007-11-04 at 13:33 +1100, Michael Lamothe wrote: Hi Matteo, Look at g_timeout_add() or the new gdk_threads_add_timeout(). Thanks, Michael On 04/11/2007, Matteo Landi [EMAIL PROTECTED] wrote: hi all i'm a
Vector drawing question.
I'm considering writing something like a simple vector drawing program, but I'm very new to GUIs, so I'm having trouble finding where to start. I think I want a GdkDrawable. If I gdk_draw_line(), say, is there any way for me to recognize when the user clicks on it? When something else overlaps? Is there a way to move it? Or do I have to keep an internal representation of what's visible and every time there's a mouseclick, search through all things that might be on the screen to see if the mouseclick is inside one of them? Tk has tags, and operations to find tags near a mouseclick, move tagged items, etc. Qt has QGraphicsScene which seems to have ways to recognize when a user clicks on something (though, I don't know Qt, either). What's the mechanism to do this in gtk? Should I be looking at some other toolkit or package for this? Vadim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Fwd: gnome applet w/ bash
Tnx i think that the first one is the function i'm in need of; by the
way i cant' make it work, and my gnome panel crashs everytime i run the
applet, so i think there is some problems with memory:
well, i've got:
const char* data (as argoment of a function)
char *std_out (created in the function)
g_spawn_command_line_sync(data, std_out, NULL, NULL, NULL);
is this call right? i think not...but why??
tnx again
M@
On Mon, 2007-11-05 at 15:21 +1100, Michael Lamothe wrote:
Hi Matteo,
There's a few ways to do this, two of which I'll tell you now.
Hopefully, you can change your application to use these functions
instead.
Firstly, there's the g_spawn_ set of APIs designed for this. I think
that something like g_spawn_command_line_sync() will do exactly what
you want. Basically, GLib calculates and allocates the space
required. The documentation mentions nothing about freeing the
allocated strings afterwards but I imagine you will have to free the
standard_output and standard_error parameters with g_free().
Secondly, if the spawned program is meant to run asynchronously in the
background then you'll need to use something like
g_spawn_async_with_pipes(). I don't think that this is what you want
because you were talking about having to allocate the length of the
output.
Thanks,
Michael
On 05/11/2007, Matteo Landi [EMAIL PROTECTED] wrote:
thank you very much, that solved one of my problems.
here is the second:
i'm using a pipe to catch the output of a specific command and store it
as a label in the panel; the problem is that if the array containing the
output is smaller than the output itself, the line is cut, and the
applet is show all middle aligned; if the output is bigger, i get the
label splitted in two lines: the first one containing the entire output,
and the second one is empty.
How could i solve this? maybe with dynamic allocation of memory, but in
order to know the output width size, i gotta insert a while that
overload the applet isn't it?
tnx in advance for the help
M@
On Sun, 2007-11-04 at 13:33 +1100, Michael Lamothe wrote:
Hi Matteo,
Look at g_timeout_add() or the new gdk_threads_add_timeout().
Thanks,
Michael
On 04/11/2007, Matteo Landi [EMAIL PROTECTED] wrote:
hi all
i'm a complete newbie in developing with gtk, but yesterday i had an
idea about develope a gnome panel which could substitute conky..
In fact i'm in need of a panel that simply display the output of a bash
script..
well, after have googled a bit, i found a guide for implementing gnome
applet and here is the result
#include string.h
#include panel-applet.h
#include gtk/gtklabel.h
#include stdio.h
static gboolean on_button_press (GtkWidget *event_box, GdkEventButton
*event, GtkWidget* label){
if (event-button != 1)
return FALSE;
else {
FILE* fp;
char line[160];
fp = popen(~/scripts/allin1, r);
fgets( line, sizeof line, fp);
pclose(fp);
gtk_label_set_text (label,(const char*) line);
}
return TRUE;
}
static gboolean my_applet_fill (PanelApplet *applet, const gchar *iid,
gpointer data){
FILE* fp;
int pid;
char line[160];
GtkWidget *label;
fp = popen(~/scripts/allin1, r);
fgets( line, sizeof line, fp);
pclose(fp);
label = gtk_label_new (line);
gtk_container_add (GTK_CONTAINER (applet), label);
g_signal_connect (G_OBJECT(applet), button_press_event,
G_CALLBACK
(on_button_press), label);
gtk_widget_show_all (GTK_WIDGET (applet));
return TRUE;
}
PANEL_APPLET_BONOBO_FACTORY (OAFIID:my_applet_Factory,
PANEL_TYPE_APPLET, Conky Porting, 0, my_applet_fill, NULL);
what i'm asking for is how could i refresh the label of the applet after
a fixed period of time... (now the applets refresh when mouse-clicked)
tnx in advance
M@
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 17:17 +0100, Alexander Larsson wrote: On Wed, 2007-11-07 at 17:07 +0100, Xavier Bestel wrote: Can you think of a good name for the new unified library? Stick it in glib. But if you really want to split, please avoid base or foundation or the-mother-of-everything, everyone wants its project to be called like that. It can't go in glib, because glib doesn't link to gobject, and thus you can't use GObjects, GInterfaces, signals, etc. I misunderstood you. I thought you wanted to do another module with libraries inside. Just an added library, inside the glib module is fine. As for the name ... base or foundation makes me think it's even below glib itself, whereas they seem to be quite evolved objects. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Wed, 7 Nov 2007, Morten Welinder wrote: nobody has to use this syntax. you can stick to the ever simple: g_assert (foo bar); however if you want the value of 'foo' and 'bar' be printed out, instead of just the value of (foo bar) which would be 0 or 1, then there are no other means than using something simialr to: g_assert_cmpfloat (foo, , bar); No other way? You just need to think outside the box^w^wcpp. How about a pre-cpp filter that looks at the source code, finds the g_assert, and does a little creative rewriting? how about that? bad. we don't use a preprocessor like moc before cpp+cc. if we did, GObject would look a million times different. people are coding such a thing after the fact these days though, look at vala to see how it looks like. also, for some out of the box thinking, see: http://blogs.gnome.org/timj/2007/07/14/13072007-switch-on-strings-in-c-and-c/ Morten --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 17:07 +0100, Xavier Bestel wrote: Can you think of a good name for the new unified library? Stick it in glib. But if you really want to split, please avoid base or foundation or the-mother-of-everything, everyone wants its project to be called like that. It can't go in glib, because glib doesn't link to gobject, and thus you can't use GObjects, GInterfaces, signals, etc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 17:45 +0200, Xan wrote: On Nov 7, 2007 5:35 PM, Alexander Larsson [EMAIL PROTECTED] wrote: The idea is that this library would contain non-ui stuff that applications want but that requires GObject, so they can't be in glib. Various names for this library has been thrown about: gfoundation, gbase, gplatform Would it be again one module and multiple so or only one so? If it's the former, how does it improve things? If the latter, what about people interested in gio but not in gsettings (for example)? (Maybe I'm missing something, but the benefits are not really clear to me) The general cost of not using part of a library are very low. The parts not used are just not paged in. However, the cost of using two libraries are larger. At least 4k unshared memory per library, and one extra hash lookup for *any* symbol to resolve. It also means that if at some point the various libraries need to call each other there won't be any complicated interdependency and ordering issues. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
Matthias Clasen matthias clasen gmail com, Tue, 6 Nov 2007 13:12:02 -0500 On 11/1/07, Tim Janik timj imendio com wrote: - we provide an extended set of assertions for strings, ints and floats that allow printing of assertion arguments upon failures to reduce the need for debugging: g_assert_cmpfloat (arg1, cmpop, arg2); g_assert_cmpint (arg1, cmpop, arg2); g_assert_cmpstr (arg1, cmpop, arg2); used like: g_assert_cmpstr (foo, !=, faa); g_assert_cmpfloat (3.3, , epsilon); g_assert() is still available of course, but using the above variants, assertion messages can be more elaborate, e.g.: ** testing.c:test_assertions(): assertion failed '(3.3 epsilon)': (3.3 0.5) This syntax strikes me as not particularly elegant and a pretty severe clash with C syntax. I don't think I can get myself to insert random commas into expressions like that. How about this instead ? g_assert_with_message (foo not smaller than bar, foo bar) While I am overly exited about the possiblity of a general testing framework in glib I have problems with the current syntax: g_assert_cmp* (arg1, cmpop, qrg2); Any IDE supporting syntax highlighting (the real kind - with red underlining when you don't close braces or forget semi-colons etc.) will likely choke on this non-C syntax, as will many more advanced code-introspection tools. A toally different thing is that JUnit has method that asserts that two floats/doubles are within a specified range of each other (ie. equality testing for floats/doubles). How about: g_assert_cmpfloat_delta (arg1, arg2, delta); g_assert_cmpdouble_delta (arg1, arg2, delta); Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
Hi, It may not be clear to everyone on the list the structure of GIO and GSettings; we had a discussion with Ryan about it on Monday. (I am not 100% sure GIO works the same as GSettings, so I'll talk about GSettings.) Applications use GSettings, which includes an interface for storing preferences, and also defines the schema file format and loads the schemas at runtime. However, GSettings does not have a backend that actually stores settings. This is provided by the dconf module, which includes the on-disk data format. Apps should never have to use dconf directly, unless they are something special like a gconf-editor equivalent. I think GIO/gvfs are the same, right, where GIO is just interfaces, and gvfs provides an implementation? Apps would not link to gvfs directly? In the settings case, the backends might include dconf (which is a dbus/dvalue based thing), a simple GKeyFile type backend, and/or a Windows registry backend (used on Windows only of course); presumably all of these are still in the separate dconf module and not bundled into GLib? The idea is the same for GIO, right, where gvfs provides the actual implementation? Or is there a simple plain local IO backend in GLib itself? Would GSettings have the simple just a file backend in GLib itself? Does it really make sense to have things in the GLib tarball if there's no backend that comes with GLib - why not just put the interfaces (GIO, GSettings) in the gvfs or dconf packages? Answers I can imagine or that you've already said: - a single .so allows GSettings interface to use GIO interface, or vice versa (since they are both just interfaces, is this likely?) - 1 dso instead of 2 slightly more efficient - the plan is to include a simple fallback implementation in GLib, though GNOME apps aren't expected to use this dbus binding lib === Another library to consider in the overall plan is a dbus glib binding; for the moment we stuck the main loop integration in an additional tiny little lib packaged with dbus (yay extra link time!) but in principle eventually we'd also have an actual binding library. This binding library should (imo) be a dependency of gtk for sure, and would probably make sense as a dconf and gvfs dep, though since they are being written today before there is a binding library, it's not clear we'd ever bother to rewrite. Anyway, the dbus binding lib is not analogous to GIO/GSettings because it does not have this interface/backend split - it would have a hard dbus dep right in the API. It would also not be used in the gtk.h interface, while GSettings and GIO will be. I guess the dbus binding lib is more analogous to dconf and gvfs - which have dbus deps themselves. On the other hand, the dbus binding lib is not a dlopen()'d module or backend at all, it would just be a plain lib. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 16:35 +0100, Alexander Larsson wrote: What do people think about these ideas? Does it make sense? Either people bitch because glib is too big, or they cry because gtk+ has too many dependencies. I prefer less deps = less pain at build- time, less packages in distros, less versions interactions. Can you think of a good name for the new unified library? Stick it in glib. But if you really want to split, please avoid base or foundation or the-mother-of-everything, everyone wants its project to be called like that. Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Merging gio into glib
I talked a bit with Ryan and Matthias on irc about the possible plans for merging gio into the glib module today. The original plan was to merge gio into glib as a separate library that links to libgobject, then use that from gtk+. The idea behind this is that by shipping it as part of glib we make it easier to build the stack (no need for yet another module to be build before gtk+), and to make the stack more unified and coherent (same namespace, not looking like a grab-bag of different libraries). On the negative side, it will make glib (the module, not libglib.so) larger, which some people don't like. However, at this point Ryan brought up his work on GSettings. It would also make sense to ship in a similar fashion as a separate shared object in glib. I then started talking about some serialization APIs that I worked on for use in gio. At that point its starts looking a bit weird and inefficient with all these separate libraries in glib, and we started considering uniting these things into a common library. The idea is that this library would contain non-ui stuff that applications want but that requires GObject, so they can't be in glib. Various names for this library has been thrown about: gfoundation, gbase, gplatform We also discussed moving parts of gio into libglib. These are the functions I think make sense to move: char * g_format_file_size_for_display (goffset size); This converts a file size to a translated human readable string. char * g_uri_unescape_string (const char *escaped_string, const char *illegal_characters); char * g_uri_unescape_segment (const char *escaped_string, const char *escaped_string_end, const char *illegal_characters); char * g_uri_get_scheme(const char *uri); char * g_uri_escape_string (const char *unescaped, const char *reserved_chars_allowed, gbooleanallow_utf8); GString *g_string_append_uri_escaped (GString*string, const char *unescaped, const char *reserved_chars_allowed, gbooleanallow_utf8); These are functions related to escaping and unescaping strings in uri-escaping-style. What do people think about these ideas? Does it make sense? Can you think of a good name for the new unified library? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: One library, one .so file, one pkg-config file. I'd say do a hybrid: separate pkg-config files, single .so. You can even create .so symlinks, making it a build-time option to include a feature in the gwhatever.so or build a separate .so for it, and applications simply don't care. When that infrastructure is added, you can even have glib, gobject, and gmodule in the same .so too, or have separate ones. It's similar to what Qt does these days btw. Main problem with such a thing would be that applications will not be enforced to list all their used modules in their Makefile. To fix that, and to avoid polluting the namespace unnecessarily, each glib module will have its own header directory. So if you don't list gio in your Makefile.am, you can't include gio.h. If you think about the above layout, its separating the abstraction of what is a module from what happens to be going into a .so, and I like that distinction. I probably ask for some libtool support to make it easy to implement such schemes. You want libtool to do the symlink part for you... -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: On Wed, 2007-11-07 at 17:45 +0200, Xan wrote: On Nov 7, 2007 5:35 PM, Alexander Larsson [EMAIL PROTECTED] wrote: The idea is that this library would contain non-ui stuff that applications want but that requires GObject, so they can't be in glib. Various names for this library has been thrown about: gfoundation, gbase, gplatform Would it be again one module and multiple so or only one so? If it's the former, how does it improve things? If the latter, what about people interested in gio but not in gsettings (for example)? (Maybe I'm missing something, but the benefits are not really clear to me) One library, one .so file, one pkg-config file. glib as the package (ie: what's in the tar file) would then contain 5 libraries: glib, gobject, gmodule, gthread and gfoundation (or whatever). Each of these would have their own .so and their own pkg-config. Hi Ryan, what about overriding GSettings with a different backend (LDAP, Tracker etc)? Will GSsettings use pluggable modules like GIO or will the library need replacing for another backend? If the latter, then GSettings would need to sit in its own library surely? Also I prefer the name gplatform as its really intended for platform stuff jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Wed, 2007-11-07 at 09:15 -0500, Morten Welinder wrote: Note, that the filter should preserve line numbers, i.e., never remove and never insert newlines. Otherwise error messages with line numbers would drive you crazy. It could also just use #line pre-processor directives: http://gcc.gnu.org/onlinedocs/cpp/Line-Control.html -- Bye, -Torsten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
nobody has to use this syntax. you can stick to the ever simple: g_assert (foo bar); however if you want the value of 'foo' and 'bar' be printed out, instead of just the value of (foo bar) which would be 0 or 1, then there are no other means than using something simialr to: g_assert_cmpfloat (foo, , bar); No other way? You just need to think outside the box^w^wcpp. How about a pre-cpp filter that looks at the source code, finds the g_assert, and does a little creative rewriting? That would be a ten-line perl script. Plus some Makefile magic to hook it up. There would be no extra run-time penalty and the compile-time penalty would be near-zero. Note, that the filter should preserve line numbers, i.e., never remove and never insert newlines. Otherwise error messages with line numbers would drive you crazy. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 13:32 -0500, Behdad Esfahbod wrote: On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: One library, one .so file, one pkg-config file. I'd say do a hybrid: separate pkg-config files, single .so. You can even create .so symlinks, making it a build-time option to include a feature in the gwhatever.so or build a separate .so for it, and applications simply don't care. When that infrastructure is added, you can even have glib, gobject, and gmodule in the same .so too, or have separate ones. It's similar to what Qt does these days btw. This is a very interesting idea. And in fact, I think we could implement this in a backward and forwards compatible way, at least on linux. I did a simple test (see attached file) with creating libstuff1.so and libstuff2.so then linking test1 against these with -lstuff1 -lstuff2. Then i created a libstuff1.so containing the code from both stuff1 and stuff2 and made libstuff2.so be a symlink to libstuff1 and linked test2 in the same way. It looks to me like: 1) test1 and test2 look the same, at least wrt shared library dependencies 2) both binaries work in both the two separate libs and one lib + symlink case 3) in the one lib + symlink case we only load the one lib once This leads me to belive it should be possible to create a configure option for glib such that libglib, libgmodule, libgobject are in the same libglib.so file, and with symlinks for gmodule and gobject. This setup should allow all old binaries to work as they used to, plus apps linked against this setup will continue to work in systems using the old setup. Pretty sweet! As behdad said, there is a risk of people not linking to all the libs they need, but that could be fixed by splitting out the headers into separate dirs, enforcing correct use of the pkg-config files. test_libs.tar.gz Description: application/compressed-tar ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Little documentation patch
Hello, Here is a little patch against gtk+ 2.12.1 documentation : gtknotebook.sgml : corrected some mistakes (noteobook - notebook) and wrong references (gtk_notebook_enable_popup - gtk_notebook_popup_enable) gtkradiobutton.sgml : changed @group to @radio_group_member where needed Please let me know if anything is not as it should be in this patch. Regards, Olivier. gtk_2_12_1_doc_notebook_radio_button_v1.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote: glib would need dbus as a build requirement for this to work (needs the dbus types), and the glib header for the function would have to be separate (with a separate .pc file for it) so that it can include dbus.h, but it would work, and avoid an extra library. And if you squint and ignore the implementation details it would be quite easy to use. Just link to glib and dbus, then call the function. Assuming the scheme I wrote about in my other mail, this is nothing different. Yet another glib module. Lets call it gdbus. By default, glib build will put it in a separate .so, same for gthread, probably gmodule, and any other glib module that has external dependencies. But there will be configure options to build them all in one .so, or build them all separately, or add/remove on a one-by-one basis. What's the problem afterall to have libglib.so depend on dbus on fedora? It's the distributor dealing with the headache. It's transparent to applications. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Nov 7, 2007 5:35 PM, Alexander Larsson [EMAIL PROTECTED] wrote: The idea is that this library would contain non-ui stuff that applications want but that requires GObject, so they can't be in glib. Various names for this library has been thrown about: gfoundation, gbase, gplatform Would it be again one module and multiple so or only one so? If it's the former, how does it improve things? If the latter, what about people interested in gio but not in gsettings (for example)? (Maybe I'm missing something, but the benefits are not really clear to me) Cheers, Xan We also discussed moving parts of gio into libglib. These are the functions I think make sense to move: char * g_format_file_size_for_display (goffset size); This converts a file size to a translated human readable string. char * g_uri_unescape_string (const char *escaped_string, const char *illegal_characters); char * g_uri_unescape_segment (const char *escaped_string, const char *escaped_string_end, const char *illegal_characters); char * g_uri_get_scheme(const char *uri); char * g_uri_escape_string (const char *unescaped, const char *reserved_chars_allowed, gbooleanallow_utf8); GString *g_string_append_uri_escaped (GString*string, const char *unescaped, const char *reserved_chars_allowed, gbooleanallow_utf8); These are functions related to escaping and unescaping strings in uri-escaping-style. What do people think about these ideas? Does it make sense? Can you think of a good name for the new unified library? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 17:45 +0200, Xan wrote: On Nov 7, 2007 5:35 PM, Alexander Larsson [EMAIL PROTECTED] wrote: The idea is that this library would contain non-ui stuff that applications want but that requires GObject, so they can't be in glib. Various names for this library has been thrown about: gfoundation, gbase, gplatform Would it be again one module and multiple so or only one so? If it's the former, how does it improve things? If the latter, what about people interested in gio but not in gsettings (for example)? (Maybe I'm missing something, but the benefits are not really clear to me) One library, one .so file, one pkg-config file. glib as the package (ie: what's in the tar file) would then contain 5 libraries: glib, gobject, gmodule, gthread and gfoundation (or whatever). Each of these would have their own .so and their own pkg-config. The benefit is that we remove some linker overhead and also make it easier to add new things to our below GTK platform in the future instead of making a new library every time. Additionally, there is no real penalty if you want to use gio and not GSettings since many others on the system are probably already using GSettings and it's all in shared memory anyway... GTK+ would then depend on gfoundation. GTK+ is going to consume the GSettings and gio interfaces, so the alternative is to have GTK+ depend on them as separate libraries (either inside or outside of the glib tarball). In the outside glib case it complicates the build of our platform and in the inside glib case it results in a tonne of libraries inside glib that each cause additional linking overheads. Hope that clears up the intention a bit. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 21:46 +0100, Alexander Larsson wrote: On Wed, 2007-11-07 at 13:32 -0500, Behdad Esfahbod wrote: On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: One library, one .so file, one pkg-config file. I'd say do a hybrid: separate pkg-config files, single .so. You can even create .so symlinks, making it a build-time option to include a feature in the gwhatever.so or build a separate .so for it, and applications simply don't care. When that infrastructure is added, you can even have glib, gobject, and gmodule in the same .so too, or have separate ones. It's similar to what Qt does these days btw. This is a very interesting idea. And in fact, I think we could implement this in a backward and forwards compatible way, at least on linux. I did a simple test (see attached file) with creating libstuff1.so and libstuff2.so then linking test1 against these with -lstuff1 -lstuff2. Then i created a libstuff1.so containing the code from both stuff1 and stuff2 and made libstuff2.so be a symlink to libstuff1 and linked test2 in the same way. It looks to me like: 1) test1 and test2 look the same, at least wrt shared library dependencies 2) both binaries work in both the two separate libs and one lib + symlink case 3) in the one lib + symlink case we only load the one lib once This leads me to belive it should be possible to create a configure option for glib such that libglib, libgmodule, libgobject are in the same libglib.so file, and with symlinks for gmodule and gobject. This setup should allow all old binaries to work as they used to, plus apps linked against this setup will continue to work in systems using the old setup. Pretty sweet! Yep. Thanks for the test case. The actual implementation would be a bit more involved, because of all the symlinks that ldconfig creates, but I'm sure it can be made to work. As behdad said, there is a risk of people not linking to all the libs they need, but that could be fixed by splitting out the headers into separate dirs, enforcing correct use of the pkg-config files. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging gio into glib
On Wed, 2007-11-07 at 22:30 +0100, Alexander Larsson wrote: It will mean that applications linking to libglib will suddenly pull in more dependencies however. Thats not something that really happens with e.g. gobject, and for gmodule the extra library is from glibc. For instance, isn't glib used on the Fedora initrd these days? That would mean we'd have to add dbus to the initrd too. It's always a tradeoff between more .so's and more unused dependencies. Sure one can leave gdbus out of the main .so. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GInterfaces and API Stability
I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. I'm hoping this is just one of those oops, never thought of that kinds of issues and the gtk+ and atk maintainers will avoid extending these stable interfaces going forward. It's a significant binding support issue. -- Mike Kestner [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib branched for 2.14
I have just created a glib-2-14 branch which will continue to receive bugfixes and produce 2.14.x releases. The work that we expect to land in trunk soon is the gio work that Alex' has been working on for a while. He sent out a mail outlining our merge plans earlier today. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-07 at 20:47 -0500, Matthias Clasen wrote: On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote: I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. I'm hoping this is just one of those oops, never thought of that kinds of issues and the gtk+ and atk maintainers will avoid extending these stable interfaces going forward. It's a significant binding support issue. Well, I have certainly considered C ABI compatibility to be the main deciding factor when making such decisions. I'd say if C# interfaces are inflexible like that then mapping GObject interfaces directly to C# interfaces was probably wrong. One option that a language binding would be have would be to map the extension of a GTK+ interface into GtkBorkable/* original version */ GtkBorkable212 extends GtkBorkable /* new version with new methods in 2.12 */ A bit ugly, but I tend to agree with Matthias that further narrowing the small set of places we can extend GTK+ while preserving ABI/API compat is not a good idea. - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH]: Fix SIGBUS in JPEG handling on RISC
From: Owen Taylor [EMAIL PROTECTED] Date: Sat, 03 Nov 2007 21:16:38 -0400 On Sat, 2007-11-03 at 15:50 -0700, David Miller wrote: Alternatively, we can say that GTK+ knows better and simply block out such dumb platforms at the top-level configure :-) Plus you don't want to trap it's going to be slow and might even fill up the user's logs. (This used to be a problem on Alpha Linux long a Grep for ' 8' in the gdkpixbuf sources and you'll find a small fraction of the other places where we go through effort avoid unaligned access. I'm glad that people agree with me. :) Meanwhile, could someone please apply my patch so that this bug gets fixed? Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote: I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. I'm hoping this is just one of those oops, never thought of that kinds of issues and the gtk+ and atk maintainers will avoid extending these stable interfaces going forward. It's a significant binding support issue. Well, I have certainly considered C ABI compatibility to be the main deciding factor when making such decisions. I'd say if C# interfaces are inflexible like that then mapping GObject interfaces directly to C# interfaces was probably wrong. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
