Windows g_socket_create_source problem
Hi everyone.
I am having some trouble combining Lua Sockets with GTK+. I'm interested
in integrating waiting for socket events in the main event loop, which
means using a GSocket-type GSource.
I think I am on the right track: I'm creating a Lua Socket, getting the
file descriptor (which is a normal fd/SOCKET), create a new GSocket
using g_socket_create_source, and attaching a callback that should fire
on data available on the socket.
The problem is that once the callback fires (i.e., when I send something
to the socket), it keeps on firing like craaayzaay, even if no data is
present on the socket. This means that the second time the callback is
called, the blocking socket will block the main thread. If I return
FALSE instead of TRUE from the callback, the first event is received
correctly, the gsource is cleaned up, but of course no other events will
be received after that.
Am I missing something or have I hit some winsock-related bug? This is
my first foray into GTK+/GLib territory, so one might never know :)
I'm using the GTK+ Windows binaries found at gtk.org (GLib 2.22.2).
Thanks,
Daan Nusman
PS. here's some source code. The addSocket function is called from Lua with
the file descriptor of the socket as argument.
//
// GTK+ networking bridge
// data associated with GSource callback
struct LuaSocketData
{
lua_State* L; // the lua state that owns the callback function
int m_CallbackRef; // this is a reference to a Lua function
};
// destroys the LuaSocketData (assumes lua state still exists..)
static void LuaSocketData_destroy(gpointer data)
{
LuaSocketData* luaSocket = (LuaSocketData*)data;
luaL_unref(luaSocket-L, LUA_REGISTRYINDEX, luaSocket-m_CallbackRef);
}
// called when new data (or error) arrives on a Lua Socket.
gboolean __cdecl onLuaSocketReady(GSocket *socket,
GIOCondition condition, gpointer
user_data)
{
LuaSocketData* luaSocket = (LuaSocketData*)user_data;
lua_State* L = luaSocket-L;
if(condition == G_IO_IN)
{
printf(callback to lref#%d\n, luaSocket-m_CallbackRef);
lua_getref(L, luaSocket-m_CallbackRef);
// this calls Lua, which does a recv on the socket.
if(lua_pcall(L, 0, 0, 0))
{
printf(callback error: %s\n, lua_tostring(L, -1));
lua_pop(L, 1);
}
}
else
{
__asm int 3 //DebugBreak(); TODO
}
return TRUE; // continue receiving events
}
/*
Lua function that inserts a socket into the GTK+ event loop.
Lua params:
- 1) socket fd (use mySocket:getfd())
- 2) callback function, to be called when new data is available on
the socket
*/
static int addSocket(lua_State* L)
{
int sockFD = luaL_checkint(L, 1);
// what condition to call the callback on
GIOCondition condition = G_IO_IN;
// create new socket from the lua socket/fd
GError* err = 0;
GSocket* gSock = g_socket_new_from_fd(sockFD, err);
if(err) luaL_error(L, %s, err-message); // fixme: memleak
// Insert notifications into message loop,
// with special user data remembering the callback.
GSource* socketMessageSource =
g_socket_create_source(gSock, condition, NULL);
LuaSocketData* luasocketdata =
(LuaSocketData*)g_malloc(sizeof(LuaSocketData));
lua_pushvalue(L, 2);
luasocketdata-m_CallbackRef =
luaL_ref(L, LUA_REGISTRYINDEX); // store function
luasocketdata-L = lua_getmainthreadstate(L);
g_source_set_callback (socketMessageSource,
(GSourceFunc) onLuaSocketReady,
luasocketdata, g_free);
g_source_attach (socketMessageSource, NULL); // add source to main
context
g_source_unref (socketMessageSource);
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Windows g_socket_create_source problem
I think I am on the right track: I'm creating a Lua Socket, getting the file descriptor (which is a normal fd/SOCKET), create a new GSocket using g_socket_create_source, and attaching a callback that should fire on data available on the socket. Please note that the GSocket API is quite new, and it is possible you are the first person to ever try it seriously on Windows. Problems are to be expected. Then throw in a weird language biinding in the mix (which might, or might not, be partly to blame), and the number of people able to help you goes way down. You should file a bug, and attach a *minimal* but *complete* free-standing sample program in plain C (i.e. no Lua stuff). --tml P.S. Does the gtk-win32-list still exist? I thought the consensus was that it is unnecessary and can be dropped. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Windows g_socket_create_source problem
Hi Tor, thanks for your speedy reply. Tor Lillqvist wrote: I think I am on the right track: I'm creating a Lua Socket, getting the file descriptor (which is a normal fd/SOCKET), create a new GSocket using g_socket_create_source, and attaching a callback that should fire on data available on the socket. Please note that the GSocket API is quite new, and it is possible you are the first person to ever try it seriously on Windows. Problems are to be expected. Then throw in a weird language biinding in the mix (which might, or might not, be partly to blame), and the number of people able to help you goes way down. You should file a bug, and attach a *minimal* but *complete* free-standing sample program in plain C (i.e. no Lua stuff). I've followed your advice, and in the process created a test app that can run using both native GSocket sockets and low-level sockets. The GSocket sockets work! However the low-level sockets (and, by extension, all sockets from other socket libraries) do not. I have a feeling that this is because of the win32_unset_event_mask (socket, FD_READ); call in g_socket_receive() in gsocket.c(1651). However, I cannot call that function from my own code because it is private to GSocket. Windows itself automatically resets the associated windows event handle selected with WSAEventSelect when recv is called, so that should not be the problem. A solution might be to clear those GSocket flags after the callback has returned instead of the g_socket_receive function? For now, I think I will just use the GSocket recv and pass that data on to Lua, instead of having Lua do the recv call. Anyway, the test app can be found here: http://matrix.re-lion.com/temp/main.cpp It waits for UDP messages on port 26632. I've only tested/ran it under Windows. It has these options: #define USE_GSOCKET_FOR_RECV 0 #define USE_GSOCKET_NEW 1 // setting USE_GSOCKET_FOR_RECV to 0 and USE_GSOCKET_NEW to 1 causes a low-level recv() to be used on a GSocket (does not work) // setting USE_GSOCKET_FOR_RECV to 1 and USE_GSOCKET_NEW to 0 causes a g_socket_new_from_fd to be created and a g_socket_receive for receiving (works!) // setting USE_GSOCKET_FOR_RECV to 0 and USE_GSOCKET_NEW to 0 causes a g_socket_new_from_fd to be created and low-level recv(does not work) (this would be the main case for using other socket libs) // setting USE_GSOCKET_FOR_RECV to 1 and USE_GSOCKET_NEW to 1 results in an all-GLib socket implementation (works) Presumably, all combinations do work under Linux? The output for the non-working cases is: -- Send a UDP message to localhost:26632 or do a UDP broadcast... callback! condition: 1. got data: 114 bytes: FEAR ME FOR I AM A UDP PACKET callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 callback! condition: 1. WSA error: 10035 ...etc -- (WSA error 10035 is WSAEWOULDBLOCK) P.S. Does the gtk-win32-list still exist? I thought the consensus was that it is unnecessary and can be dropped. No idea, it's still there on the site (http://mail.gnome.org/mailman/listinfo/gtk-win32-list) though. I'll just remove it from the Cc list then. Thanks for your time, Daan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Run time problem with gtk+-2.16.6
Hi, I am new to GTK. I have downloaded the GTK ver 2.16.6 and compiled it in FC9. While running helloworld (sample from gtk.org) I am getting the following error: [...@localhost ~]$ ./helloworld (helloworld:23339): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed (helloworld:23339): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `G_IS_OBJECT (object)' failed (bug-buddy:23340): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed (bug-buddy:23340): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `G_IS_OBJECT (object)' failed Please let me know what can be the issue here? ~Thanx Abhijit -- An Excellent Credit Score is 750 See Yours in Just 2 Easy Steps! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Issues with gtk.Entry in Gnome Applet
Hi, I've been trying to work out a gnome panel applet since this friday and have finally ended up in weird issue, this might have come due my lack of understanding of applets/gtk+. So I seek some suggestions/pointers/eye-openers. The source of my applet can be checked out here - http://github.com/ideamonk/tweetbar To run it - $ sudo ./install.sh ' it just copies files into /usr/share/gtweetbar and main script to /usr/local/bin as source uses absolute path $ python ./tweetbar.py run-in-window ' this would run the applet into its own window, where everything is functioning properly - http://twitpic.com/k8lda/full - with respect to the gtk.Entry in center. While when you do a right click on a panel and add the applet to it, the gtk.Entry box becomes un-typable. It never gets focus. I have tried to put all the widgets into an EventBox() but still I didn't find any change. - http://twitpic.com/k8lf8/full I'm able to do a right click on the gtk.Entry(), am able to cut-copy-paste stuff into it, but not able to see a cursor in to so as to type in a tweet. Relevant code - http://paste.pocoo.org/show/142852/ Let me know if you are aware of any applet that has been made in pygtk and has an entry box in it. I tried looking at tracker-search bar's code, but could'nt grasp much, it being written in C. Let me know if there is a way to activate the gtk.Entry (txtTweet in this code) when I run the code in applet mode. Thanks, Abhishek Mishra http://ideamonk.blogspot.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview Row Count
dhkuhl wrote: Is there a function to give the number of rows in a treeview? I used built-in python len() function, like this: count = len(self.model) I suppose you can use it however the lists are implemented in language you are using. -- View this message in context: http://www.nabble.com/Treeview-Row-Count-tp25593281p25850819.html Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango problems
Out of no where my program decided to start having problems with Pango rendering. The GUI now shows text as the standard no character boxes and all of the icons that were there have been replaced by the red x file icon. When I run the program I get a lot of errors like: (xpath_test:11200): Gtk-WARNING **: Error loading theme icon 'gtk-media-record' for stock: Unable to load image-loading module: /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: ELF load command alignment not page-aligned (xpath_test:11200): Pango-WARNING **: /usr/lib/pango/1.6.0/modules/pango-basic-fc.so: ELF load command alignment not page-aligned All of the code used was pretty much cut and pasted from another application that still displays fonts and icons correctly so I'm not sure what happened to this one. I can provide source code if anyone requires it. Build system - Linux 2.6.24-24-generic #1 SMP Fri Sep 18 16:49:39 UTC 2009 i686 GNU/Linux GLib: 2.16.6 GTK+: 2.12.9 GCC: 4.2.4 Pango: 1.20.5 Thanks, Geoff ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Question about the default title of a GTK window
Hey pals, I am a new comer on GTK things. I have some questions about it, would any one have time taking me over it? Here is it: 1, What is the default title of a GTK window? I mean, if there is no string was assigned to title of a GTK window, what will be exposed in the title bar of said window? 2, Whether there is another interface for developers on setting title on GTK window except gtk_window_set_title? 3, More specifications, will GTK framework take application name from anywhere and set it as title into any untitled window in the application? That all. Thanks alot. -- View this message in context: http://www.nabble.com/Question-about-the-default-title-of-a-GTK-window-tp25960347p25960347.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
2009/10/20 Mark mark...@gmail.com Also the ability to choose between thumbnailers isn't bad.. this is opensource after all and that's all about freedom of choice. Something inside of me just died. Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: For Jannis and Philip, Nice tumbler talk but could you two make suggestions for my project? ^_^ As I already wrote: A PDF thumbnailer that implements the 'specialized thumbnailer' spec that doesn't need to link with gdkpixbuf. I think that matches your project description, it fits in the architec- ture of Tumbler (and if done right we could make this a project that many people will use and install alongside Tumbler). It's much more simple than developing an entire thumbnailer, as you only need to implement one D-Bus method called Create. - You'll have to work with a queue handling the thumbnailing, as Create isn't allowed to block, which means that GThreadQueue could for example be used (which means that your work will involve dealing with threads). - You'll need to deal with DBus .service registration - You'll need to code against a specification (which is in general harder than doing your own thing - but schools like that) - It's a thumbnailer service and it could work standalone (which means that it fits your requirements for school) - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer that implements the 'specialized thumbnailer' spec - It sounds doable within 8 weeks I suggest that you set up a gitorious repository, start with making a skeleton out of the maemo-video-thumbnailer project, adapt all the files that you read about in the specification, hollow out the methods, and then implement them for PDF files instead of video (GStreamer). You can check out libpoppler for dealing with PDF files. Poppler can be compiled not to use gdkpixbuf, but instead cairo as far as I know. I strongly advise to do that. Anyway, it's up to you. Also, it wont be about free-choice unless your thumbnailer implements the specification. Each new home-brew specification that isn't agreed by multiple people adds API clutter to the platform. ps. Specialized thumbnailers spec: http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052 ps. Note that we might make minor changes to this spec in the following days. Among them might be the optional Cancel() method and a parameter to the Create() method called scheduler (which you can also ignore, for now). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 13:08 +0200, Philip Van Hoof wrote: - You'll have to work with a queue handling the thumbnailing, as Create isn't allowed to block, which means that GThreadQueue could for example be used (which means that your work will involve dealing with threads). Sorry that's GThreadPool, not queue. I have too many 'queue' words in my head at the moment ;-) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof s...@pvanhoof.be wrote: On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: For Jannis and Philip, Nice tumbler talk but could you two make suggestions for my project? ^_^ As I already wrote: A PDF thumbnailer that implements the 'specialized thumbnailer' spec that doesn't need to link with gdkpixbuf. I think that matches your project description, it fits in the architec- ture of Tumbler (and if done right we could make this a project that many people will use and install alongside Tumbler). It's much more simple than developing an entire thumbnailer, as you only need to implement one D-Bus method called Create. - You'll have to work with a queue handling the thumbnailing, as Create isn't allowed to block, which means that GThreadQueue could for example be used (which means that your work will involve dealing with threads). - You'll need to deal with DBus .service registration - You'll need to code against a specification (which is in general harder than doing your own thing - but schools like that) - It's a thumbnailer service and it could work standalone (which means that it fits your requirements for school) - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer that implements the 'specialized thumbnailer' spec - It sounds doable within 8 weeks I suggest that you set up a gitorious repository, start with making a skeleton out of the maemo-video-thumbnailer project, adapt all the files that you read about in the specification, hollow out the methods, and then implement them for PDF files instead of video (GStreamer). You can check out libpoppler for dealing with PDF files. Poppler can be compiled not to use gdkpixbuf, but instead cairo as far as I know. I strongly advise to do that. Anyway, it's up to you. Also, it wont be about free-choice unless your thumbnailer implements the specification. Each new home-brew specification that isn't agreed by multiple people adds API clutter to the platform. ps. Specialized thumbnailers spec: http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052 ps. Note that we might make minor changes to this spec in the following days. Among them might be the optional Cancel() method and a parameter to the Create() method called scheduler (which you can also ignore, for now). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be I do miss some vital parts: - Designing the daemon and plugin architecture - Making those 2 That's what i see missing now but i probably missed a few other parts. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 14:33 +0200, Mark wrote: On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof s...@pvanhoof.be wrote: On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: For Jannis and Philip, Nice tumbler talk but could you two make suggestions for my project? ^_^ As I already wrote: A PDF thumbnailer that implements the 'specialized thumbnailer' spec that doesn't need to link with gdkpixbuf. [CUT] Please reply inline and cut away non-relevant things. I do miss some vital parts: - Designing the daemon and plugin architecture - Making those 2 That's what i see missing now but i probably missed a few other parts. If you want to make a functional analysis of Tumbler, then go ahead. If you want to draw cute UML diagrams with the classes and interfaces being used, yeah sure. Sounds like useful documentation that doesn't exist atm What does Making those 2 mean? You still have to make the specialized PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a quick skeleton of the code. But if you prefer making an all new one in C++ or whatever ... yeah sure. I think you are just looking for a reason to make your own one. That's you decision of course. It's called NIH, but anyway (I can't and wont stop you from doing that). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
XInput 2.0 branch ready for review
Hi all! I think The XInput 2.0 branch is ready for initial review, there are some things missing, but at least the GDK part looks quite consistent, there are some glitches in non-pure GTK+ apps, but as far as I've tested in my jhbuild environment, it works quite well. The patch [1] is fairly big (22'5K lines) and does quite heavy modifications on pretty basic GDK internals, so I'm not sure how could we best do for merging, I've tried to keep things working along git history though. I've also updated the MPX page in l.g.o [2] with some implementation details and roadmap. There are some things left, such as DnD or modifying GtkWidgets, but I think that can be done step by step without disrupting anything. I'll keep working on the missing items in the xi2 branch anyway. So, questions? petitions? :) Cheers, Carlos [1] https://bugzilla.gnome.org/show_bug.cgi?id=596725#c1 [2] http://live.gnome.org/GTK+/MPX ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
I do miss some vital parts: - Designing the daemon and plugin architecture - Making those 2 That's what i see missing now but i probably missed a few other parts. If you want to make a functional analysis of Tumbler, then go ahead. If you want to draw cute UML diagrams with the classes and interfaces being used, yeah sure. Sounds like useful documentation that doesn't exist atm What does Making those 2 mean? You still have to make the specialized PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a quick skeleton of the code. But if you prefer making an all new one in C++ or whatever ... yeah sure. 1. designing a daemon 2. designing a plugin architecture 3. making the daemon 4. making the plugin architecture like that I think you are just looking for a reason to make your own one. That's you decision of course. It's called NIH, but anyway (I can't and wont stop you from doing that). you just don't seem to get the point. I need to build something from the ground up (making uml, class diagrams and such).. and based on that i need to make the actual program. Tumbler is existing already! i would be making those diagrams based on the current inner working which is not the way to go. Oke, i know that for each project i start outside of school i don't make a design at all or a very simple one and in that case i could perfectly help tumbler. That, sadly, isn't the case (which i told you already on irc) Just for that reason alone tumbler isn't a fine project for me to join in this case. Also i would like to learn as much as possible and that is less likely to happen if i join tumbler. I am not looking for reasons to make it all myself.. the requirements simple.. require that. Now can we please quit bashing the idea that there will be 2 thumbnailing services in a few months time and can i get some constructive feedback about the ideas in my first post? Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk As said a few times. the outline is right there (in the first post) now all i can do is steer some more in one direction or the other. I personally would like to steer in the optimizing direction... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote: On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote: Yeah, I think we need to support this from the get-go. Anyway, at the end of the day, UNIX fds are just integers so if you require that users (such as GDBus itself and apps using GDBus) keep the fds alive until the method/signal has been sent/received you should be able to treat them as such. Anyway, it's probably more complicated than this. I talked to Lennart on IRC and the 'h' type, as serialised, isn't a file descriptor so much as it is an index into a table of file descriptors that are stored separately (in a separate part of the DBusMessage). Keeping this in mind, we could support this by doing the same thing with GDBus -- support 'file descriptor array offset' as a special type of integer in GVariant (much like 'o'bject path is a special type of string) and have a GDBus call for send_with_file_descriptors() or such. Lennart mentioned that he thinks that it's a bad idea that the dbus_message_marshal stuff was ever added to libdbus, and that the fd-passing stuff in libdbus will break if you try to use those functions. If we ever want to make a more efficient GVariant-to-DBus conversion process we'll have to turn it off for the case where fd's are present -- that's another reason for having a separate call, maybe. I don't think we would want to have any more 'deeply integrated' support than that, for a lot of reasons: Lennart mentioned that this only really works on Linux (and of course, only works if you connect to the bus using Unix sockets). There's also the concern of what it would mean to serialise a GVariant that contains an fd (to dconf, to the registry, to text format, to XML, or to anything else). Yeah, the 'h' type really is for _handles_ - see the discussion on the dbus list when this was introduced (well, initially Lenny wanted 'f' - but some D-Bus implementations use that for gfloat and we didn't want to screw them). So only in Unix (mind you, not only Linux but any Unix that can pass fds - including Solaris and OS X) 'h' used for sending file descriptors but in Win32 it could probably be used for a HANDLE (e.g. the Win32 concept of file descriptors) - I actually think you can pass HANDLE to other Win32 processes. So how about something like 1. and 2. below? We'd put g_dbus_connection_get_handle_for_unix_fd() g_dbus_connection_set_handle_for_unix_fd() in the gio-unix-2.0 headers. Presumably we could add g_dbus_connection_get_handle_for_win32_handle() g_dbus_connection_set_handle_for_win32_handle() and put that in gio-win32-2.0 if such a thing was to surface. In the future we could also have g_dbus_connection_get_handle_for_iostream() g_dbus_connection_set_handle_for_iostream() that takes a GIOStream (this might not be a good idea, I don't know). For this to work, however, I'd need something like g_object_set_data_full() g_object_get_data() on the GVariant type since we'd want to clean up stuff when the passed GVariant is destroyed. It might be nice to have that on GVariant *anyway*, see http://bugzilla.gnome.org/show_bug.cgi?id=581106 for why associations are useful in general. Thanks, David --- 1. user code for sending variants: GVariant *parameters; parameters = g_variant_new ((ih), some_int, g_dbus_connection_get_handle_for_unix_fd (connection, variant, some_fd)); g_dbus_proxy_invoke_method (proxy, SomeMethodTakingAnIntAndUnixFd, parameters, -1, NULL, callback, user_data); 2. user code for receiving a variant gint some_int; gint handle; gint fd; handle = g_variant_get (result_parameters, (ih), some_int, handle); fd = g_dbus_connection_get_unix_fd_for_handle (connection, handle); g_variant_unref (result_parameters); /* use fd */ close (fd); ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: I do miss some vital parts: - Designing the daemon and plugin architecture - Making those 2 That's what i see missing now but i probably missed a few other parts. What does Making those 2 mean? [CUT] 1. designing a daemon With a specialized thumbnailer for PDF thumbnails you'll be designing a daemon. 2. designing a plugin architecture I don't know what that means anyway. A plugin architecture can mean: - Registering yourself to a DBus service, so that it knows about your existence and can delegate work to you. This is what a specialized thumbnailer is wrt Tumbler. You could see such a thumbnailer as a plugin for Tumbler (or any other thumbnail service). - Implementing an interface in Java or .NET, or implementing Event handlers in .NET, or anonymous classes in Java, or delegates in C#, that provide functionality that a core application doesn't have and that you provide dynamically by installing an assembly (or .class file, in Java) somewhere on demand. - Making a struct with a bunch of function pointers that you return at a get_plugin_info-like function that you find with dlsym after you dlopen a .so file from a core application on demand. You can also use GModule in GLib to make all this a lot more easy. - etc ... 3. making the daemon With a specialized thumbnailer for PDF thumbnails you'll be making a daemon. 4. making the plugin architecture Same answer as #2 like that Yes? I think you are just looking for a reason to make your own one. That's you decision of course. It's called NIH, but anyway (I can't and wont stop you from doing that). you just don't seem to get the point. I'm quite afraid that I do get the point ... :-\ I need to build something from the ground up (making uml, class diagrams and such).. and based on that i need to make the actual program. Yes, you could do that for a specialized thumbnailer for PDF thumbnails. Tumbler is existing already! i would be making those diagrams based on the current inner working which is not the way to go. There's no specialized thumbnailer for PDF thumbnails (for Tumbler) yet. Oke, i know that for each project i start outside of school i don't make a design at all or a very simple one and in that case i could perfectly help tumbler. You can help Tumbler by making a specialized thumbnailer that makes PDF thumbnails, for example. That, sadly, isn't the case (which i told you already on irc) Untrue, specialized thumbnailer that makes PDF thumbnails. Just for that reason alone tumbler isn't a fine project for me to join in this case. Also i would like to learn as much as possible and that is less likely to happen if i join tumbler. Eh? I disagree. But oh well. I am not looking for reasons to make it all myself.. the requirements simple.. require that. Untrue, I know about your requirements. I read them. And a specialized thumbnailer, that for example makes PDF thumbnails, fits it perfectly. Now can we please quit bashing the idea that there will be 2 thumbnailing services in a few months time and can i get some constructive feedback about the ideas in my first post? The replies of the people who have replied so far is the constructive feedback on your first post. Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk That's not up to me. As said a few times. the outline is right there (in the first post) now all i can do is steer some more in one direction or the other. I personally would like to steer in the optimizing direction... -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Thumbnailing service project; opinions, suggestions?
[ CUT ] Sorry to keep chiming in, but regrading the statement: you just don't seem to get the point. I need to build something from the ground up (making uml, class diagrams and such).. and based on that i need to make the actual program. Tumbler is existing already! i would be making those diagrams based on the current inner working which is not the way to go. [CUT] I think everyone understands what you are doing, I think your the one missing the point; from what I gather, many on this very list, have given you some very good constructive advice on what to do, if you want to do this from the ground up. So be it. They are also very prudently advising you that this is not needed, and would ONLY serve as a class project, so: Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk No one is bashing anything, but despite the many who agree, that this project is NOT a requirement for GNOME or GTK (and since it is only for school, a place that rots the brain) I would be shocked... SHOCKED... if they provided you with a GIT, a gnome sub domain, and a blog. My friend, understanding is a two way street, and I'm not sure if any one on this list will convince you of any other path, than the one you are on. But don't expect them to hold your hand in this process as well. You want to do this do it: Put up your own GIT repo. Use a domain name off of your own schools website. and create your own blog for the project. I doubt any of this will effect your grade. Frankly it simply sounds like your trying to get your name on the site, which will help with other prospects. I would LOVE to be attached to such a project, many would. Open source is not about having many choices of software that do the same thing, it is about having many people working together in a cooperative (operative word here) to create something for the people, by the people, that will benefit the people, and in the process have some fun doing what we love. Open source is about freedom to do as you will, without the fear of big bro slamming you. Open source has never NEVER been about quantity, and has everything EVERYTHING to do with quality. IMHO shawn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
Hi Mark, On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: Now can we please quit bashing the idea that there will be 2 thumbnailing services in a few months time and can i get some constructive feedback about the ideas in my first post? Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk gtk-devel-list is *really* not the right place for this kind of requests. Please read [1] for information about the GIT account requests, [2] for Planet GNOME and [3] for the GNOME website. Anyway, it seems to me that not having these kind of resources available right now (or even not having them at all) should not block any development of your project. For what concerns the project itself, I don't like see people duplicating efforts; as others already told you, I really can't see the point of rush-writing a daemon that will be, in your own words, less functional than something which is already widely used in two big platforms and which has a well-defined spec many people already agreed upon. Unless you see something so fundamentally broken in the ThumanailerSpec or in Tumbler that could only be solved with a rewrite from scratch of everything. If I were you, I would really make a step back and reconsider what other people proposed you, be it a specialized thumbnailer for some format, or a library with optimized thumbnailing algorithms with a demo test-drive thumbnailer attached. [1] http://live.gnome.org/NewAccounts [2] http://live.gnome.org/PlanetGnome [3] http://live.gnome.org/Sysadmin/WebSites Regards, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk No one is bashing anything, but despite the many who agree, that this project is NOT a requirement for GNOME or GTK (and since it is only for school, a place that rots the brain) I would be shocked... SHOCKED... if they provided you with a GIT, a gnome sub domain, and a blog. Then you have the wrong impression or didn't read everything. It was supposed to be just a single place where all information and progress would be collected. It was not at all my intend to somehow just get my name on there. Don't get me wrong. I can provide myself with all those requests bit not on the gnome site and i would have preferred that. On Tue, Oct 20, 2009 at 6:11 PM, Cosimo Cecchi cosi...@gnome.org wrote: Hi Mark, On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: Now can we please quit bashing the idea that there will be 2 thumbnailing services in a few months time and can i get some constructive feedback about the ideas in my first post? Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk gtk-devel-list is *really* not the right place for this kind of requests. Please read [1] for information about the GIT account requests, [2] for Planet GNOME and [3] for the GNOME website. Anyway, it seems to me that not having these kind of resources available right now (or even not having them at all) should not block any development of your project. It's not blocking or holding the project.. but then it might just end up on a local repository to never get released simply because i leave it rot on my hdd. It would just, for me, be nice that something that i make (also for gnome) to be hosted on a oss project and gnome does seem to fit it. For what concerns the project itself, I don't like see people duplicating efforts; as others already told you, I really can't see the point of rush-writing a daemon that will be, in your own words, less functional than something which is already widely used in two big platforms and which has a well-defined spec many people already agreed upon. Unless you see something so fundamentally broken in the ThumanailerSpec or in Tumbler that could only be solved with a rewrite from scratch of everything. I also hate to see myself duplicating something that is existing out there but i learn a lot from it by doing so. If I were you, I would really make a step back and reconsider what other people proposed you, be it a specialized thumbnailer for some format, or a library with optimized thumbnailing algorithms with a demo test-drive thumbnailer attached. If it wasn't a school project i would have done exactly that. As said a few times. I can't take a step back. the projects outline is set and must be made now. And to all. Don't get me wrong! I do still want to make this project and have been doing thumbnail benchmarks for the last few months as a startup for the project. I do have ideas on how to make it better, faster and cooler and yes much of that is in tumbler (which i didn't know a few months ago). So, it seems this is going to be a project just for school with no interesting parts for tumbler, glib or gnome in general. I would have liked it seen different but learning a lot from this project is worth a lot as well. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
2.18.1 directfb breakage
building 2.18.1 with directfb fails with
gdkwindow-directfb.c:2077: error: conflicting types for
'_gdk_windowing_window_at_pointer'
../../gdk/gdkinternals.h:460: note: previous declaration of
'_gdk_windowing_window_at_pointer' was here
gdkwindow-directfb.c: In function '_gdk_windowing_window_at_pointer':
gdkwindow-directfb.c:2102: error: 'get_toplevel' undeclared (first use in this
function)
gdkwindow-directfb.c:2102: error: (Each undeclared identifier is reported only
once
gdkwindow-directfb.c:2102: error: for each function it appears in.)
make[5]: *** [gdkwindow-directfb.lo] Error 1
--- gtk+-2.18.1/gdk/directfb/gdkwindow-directfb.c.orig 2009-10-01
12:25:20.0 -0400
+++ gtk+-2.18.1/gdk/directfb/gdkwindow-directfb.c 2009-10-01
12:25:13.0 -0400
@@ -2077,7 +2077,8 @@
_gdk_windowing_window_at_pointer (GdkDisplay *display,
gint *win_x,
gint *win_y,
- GdkModifierType *mask)
+ GdkModifierType *mask,
+ gboolean get_toplevel)
{
GdkWindow *retval;
gint wx, wy;
@@ -2137,7 +2138,8 @@
gdk_directfb_window_get_pointer (_gdk_windowing_window_at_pointer (display,
NULL,
NULL,
- NULL),
+ NULL,
+ FALSE),
x, y, mask);
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Get window screenshot on 2.18.
Good afternoon!
I'm experiencing some difficulties using 2.18 release.
I'm trying to get window screenshot using such code (working on
previous major releases, including 2.16):
GdkWindowObject *private = (GdkWindowObject *)(window);
GdkPixmap *internalPixmap = ((GdkWindowPaint
*)private-paint_stack-data)-pixmap;
if (internalPixmap == NULL) {
return NULL;
}
//
GdkPixmap *pixmap = gdk_pixmap_new(internalPixmap, width, height, -1);
GdkGC *gc = gdk_gc_new(internalPixmap);
//
gdk_draw_drawable(pixmap, gc, internalPixmap, 0, 0, 0, 0, width,
height);
But I get nothing...
Can anyone help, please?
--
Best regards, Nikolay Zamosenchuk
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
The difference of mapping between toplevel window and popup window
Hello, I'm new to GTK+ programming.I encountered a problem in my program. There is a window which contain more widgets in my program, the widgets were mapped with more pictures(via gtkrc file ). The problem is: if the window is a toplevel window,you would saw flicker phenomenon; if the window is a popup window,you wouldn't saw flicker phenomenon,and mapped normally(no flikcer phenomenon). The flicker phenomenon not serious,but you could saw it with eyes.and popup window mapped normally( Why ?). The version of gtk is gtk+ - 2.12.9 (the OS is ubuntu 8.04 ), and it already set double buffer mechanism. How could I do to avoid flicker phenomenon ? Thanks, Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Invalid typelib for module 'GLib'
Hi, I am seeing this build error while building gobject-introspection on ARM (EABI) --- Error log starts --- ../tools/g-ir-compiler --includedir=. GLib-2.0.gir -o GLib-2.0.typelib ** ERROR **: Invalid typelib for module 'GLib': In directory:The entry is contains invalid characters: LN10\u007f1\xb5\xbb\xb1k\u0002@ aborting... --- Error log ends --- Any pointers on what might be going wrong here? Could it be an ENDIANNESS issue? The same builds works fine on x86. Here is the complete build log: http://arm.koji.fedoraproject.org/koji/getfile?taskID=71821name=build.log Kedar. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Fwd: gtk+ wrong code in JPEG loading module]
This landed in my inbox - has anyone played with new versions of libjpeg
to see if this works?
Federico
---BeginMessage---
Hello all
This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c
module of the current gtk+ 2.18.0 package,
from Guido Vollbeding, organizer Independent JPEG Group.
I'm sorry if this way is inappropriate, but I'm not involved in any
forums or mailing lists. Please forward to whom it may concern if
possible.
I have noticed various complaints about weird display of JPEG images
with applications depending on gtk+ after upgrading to the new IJG
JPEG 7 version, and I have seen faulty patches to the above mentioned
module to work around the problem.
I have now looked through the code and found the flawed code sequence
in function gdk_pixbuf__jpeg_image_load_increment.
I strongly advise to correct the code by simply inserting the statement
cinfo-scale_num = 1;
in front of the following code sequence in mentioned function:
for (cinfo-scale_denom = 2; cinfo-scale_denom = 8;
cinfo-scale_denom *= 2) {
jpeg_calc_output_dimensions (cinfo);
if (cinfo-output_width width || cinfo-output_height
height) {
cinfo-scale_denom /= 2;
break;
}
}
jpeg_calc_output_dimensions (cinfo);
This addition will work with older and newer versions of the library.
The implicit assumption of the given code that cinfo-scale_num is
initialized with 1 by the JPEG library is no longer true for versions
7 and later! Version 7 initializes this field (and the other) with 8,
and version 8 and later will initialize the fields with the (variable
from 1 to 16) block size of the given JPEG file. (Note that the
default resulting scaling factor remains 1 in any case.)
The usual recommendation for versions up to 6 has always been that
scale_num and scale_denom be set *simultaneously* by the calling
application. Applications following this recommendation will not
suffer an incompatibility with newer JPEG library versions.
Newer applications (written for JPEG library versions 7 and later)
MAY choose to set only one of both fields, because the initialization
defaults are now depending on the input file and are specified as
mentioned above.
The given correction code simply retains the same behaviour with
new JPEG library versions as with old JPEG library versions.
The code may later be revised to utilize the more flexible scaling
choices of v7 and later, but there is no need to do this now.
I have not verified other code in the module.
But this part is clearly wrong for use with newer JPEG library
versions and requires correction, as it may affect a lot of gtk+
dependent applications.
Regards
Guido Vollbeding
Organizer Independent JPEG Group
---End Message---
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minutes of the GTK+ Team Meeting - 2009-10-20
= minutes for the 2009-10-20 meeting = 1. schedule post 2.20 [bratsche] - aim for 3.0 after 2.20 - list of things to deprecate, including signals and properties - figure out a diagnostic mode [discussion degenerates into pet features] - cross all items from the 3.0 readiness wiki page ACTION: decide along with the GNOME 3.0 schedule 2. Git repository surgery [jjardon] - removal of the gtk-2.16 branch - rename of the gtk-2.90 branch to gtk-2-90 ACTION: desrt to operate 3. state of development branches for 2.20/2.90 - see point 1, re: massive mess of suggestions - xi2 requires testing with complex applications before review - resolution independence requires a high-level story for configuration before reviewing the API changes and more testing with non-gtk applications using gtk API - extended layout should hopefully get a review - deprecation of [H|V] variants or orientable widgets still depends on overriding the default value for properties in sub-classes 4. GtkCurve, GtkNotebook tab packing, non-multihead-safe API deprecation - deprecation of GtkCurve is agreed - deprecation of packing property for GtkNotebook is agreed - maybe deprecation of GtkRuler? - non-multihead-safe API removal for 2.90 is still on the fence, given the changes in X land; remote use case might still apply 4. glib 2.90 branching - glib 2.24 minus deprecations equals 3.0? - general agreement (also at the Summit): not worth doing a 3.0 - it really boils down to features getting traction 5. gobject-performance ACTION: wait for alexl and try to get the work done before glib-next 6. miscellaneous - some stuff fell through the cracks ACTION: next meeting in one week next IRC meeting: 2009-10-27 ciao, Emmanuele. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
Mark, On Mon, 2009-10-19 at 16:32 +0200, Mark wrote: on school i study ... So this project, described in depth below... Keep in mind that contribution to an open source project doesn't have to be bounded by school projects or an institution's academic calendar; you are welcome to continue participating in the evolution of GTK long into the future; indeed, people are going to be happier to work with you if they think that you're going to be around for a while, thereby making their investment in helping you more likely to have a long term impact. GTK is, of course, a very mature project (which in practise means it is a core piece of the infrastructure of a huge number of production [in use] systems), and it is worked on by people with a broad cross section of interests and needs. Which is why you've noticed considerable discussion from your original message, and people adding other aspects to be considered, especially as the specific thing you proposed intersects with ongoing FreeDesktop and GNOME work. This may well take it out of the scope of something you can do in your available school time, but that's the reality of something that is as critical a player in the desktop as GTK. Regardless, I hope you will choose to participate in the broader development of the platform. Finally, I would observe that proposing ideas is important (including for helping find people who might mentor you), but the best way to show the quality of your idea is to write code implementing it and then submit a patch for consideration. AfC Sydney 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: [Fwd: gtk+ wrong code in JPEG loading module]
On Tue, Oct 20, 2009 at 6:08 PM, Federico Mena Quintero feder...@ximian.com wrote: This landed in my inbox - has anyone played with new versions of libjpeg to see if this works? I believe gentoo has been trying to get gtk to work with libjpeg7. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Wed, Oct 21, 2009 at 1:39 AM, Andrew Cowie and...@operationaldynamics.com wrote: Mark, On Mon, 2009-10-19 at 16:32 +0200, Mark wrote: on school i study ... So this project, described in depth below... Keep in mind that contribution to an open source project doesn't have to be bounded by school projects or an institution's academic calendar; you are welcome to continue participating in the evolution of GTK long into the future; indeed, people are going to be happier to work with you if they think that you're going to be around for a while, thereby making their investment in helping you more likely to have a long term impact. I know. I did contribute patched to gnome and am around here for years but just recently (as in the last few months) became capable of understanding parts of glib and making patches for things that are broken, have bugs or can be better (like: https://bugzilla.gnome.org/show_bug.cgi?id=594918) GTK is, of course, a very mature project (which in practise means it is a core piece of the infrastructure of a huge number of production [in use] systems), and it is worked on by people with a broad cross section of interests and needs. In the end my project might be a pixbuf alternative ^_- . i might have added that blink but that thought did cross my mind more then once and if i optimize it the way i want (with opencl and such) then it might just get close to a new proposal to replace gdk-pixbuf with Aldebaran (the name of the project: http://en.wikipedia.org/wiki/Aldebaran .. i kinda like star names) with it's repo here: http://gitorious.org/aldebaran Other then that there is no GTK coding involved in it. only Glib. Which is why you've noticed considerable discussion from your original message, and people adding other aspects to be considered, especially as the specific thing you proposed intersects with ongoing FreeDesktop and GNOME work. This may well take it out of the scope of something you can do in your available school time, but that's the reality of something that is as critical a player in the desktop as GTK. Regardless, I hope you will choose to participate in the broader development of the platform. This project will, if i not keep it tightly in bounds, go out of scope. So, there will probably be a future for this project but probably not as a thumbnailing service. In the end (and now i speak of one year from now) this project will either be dead or will be a image (scaling) library which Tumbler might even use ;). Note. this is all just guessing. it might end completely different Finally, I would observe that proposing ideas is important (including for helping find people who might mentor you), but the best way to show the quality of your idea is to write code implementing it and then submit a patch for consideration. That is conflicting with others (although not said here). I used to hear things like: make a design, make a proposal, see how that works and then, if it's considered interesting write code. And that is exactly how this is going. What you propose is what would have me preference. AfC Sydney Andrew, thank you for your nice post. It did give me some thought of how this project might have evolved in roughly a year from now. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Question about the default title of a GTK window
Hey pals, I am a new comer on GTK things.
I have some questions about it, would any one have time taking me over it?
Here is it:
1, What is the default title of a GTK window? I mean, if there is no string
was assigned to title of a GTK window, what will be exposed in the title bar
of said window?
I got curious so I looked. All three implementation Win32, X11, and my
favorite Quartz (Next Step, just cause that's what I'm working on now)
implements gdk_window_new based on the underlying platform and are somewhat
different. From what I can gather this is the part that gets the title and use
the implementation specific library functions to set the actual title, with the
text coming from this tidbit of code based on glib:
in gdk_window_new_internal(){
(implementation specific code)
if (attributes_mask GDK_WA_TITLE)
title = attributes-title;
else
title = get_default_title ();
(implementation specific code)..
}
with the function get_default_title defined as:
static const gchar *
get_default_title (void)
{
const char *title;
title = g_get_application_name ();
if (!title)
title = g_get_prgname ();
return title;
}
in all implementation, thus the answer being, the executable name.
2, Whether there is another interface for developers on setting title on GTK
window except gtk_window_set_title?
I suppose you could use g_set_prgname() look at
http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html
3, More specifications, will GTK framework take application name from
anywhere and set it as title into any untitled window in the application?
That all. Thanks alot.
Take application name from anywhere? Huh? I can't say the function below is
straight forward, I can only imaging its convolution is do the WIN32, but from
what I can gather g_prgname is a global variable within the file, and as as
mentioned initialized in gdk_init. Actually it comes from
g_option_context_parse() in goption.c.
Basically the function (very compiler depended) finds the program name and sets
it, which intern becomes your very changeable window title.
**
* g_get_prgname:
*
* Gets the name of the program. This name should emphasisnot/emphasis
* be localized, contrast with g_get_application_name().
* (If you are using GDK or GTK+ the program name is set in gdk_init(),
* which is called by gtk_init(). The program name is found by taking
* the last component of literalargv[0]/literal.)
*
* Returns: the name of the program. The returned string belongs
* to GLib and must not be modified or freed.
*/
gchar*
g_get_prgname (void)
{
gchar* retval;
G_LOCK (g_prgname);
#ifdef G_OS_WIN32
if (g_prgname == NULL)
{
static gboolean beenhere = FALSE;
if (!beenhere)
{
gchar *utf8_buf = NULL;
wchar_t buf[MAX_PATH+1];
beenhere = TRUE;
if (GetModuleFileNameW (GetModuleHandle (NULL),
buf, G_N_ELEMENTS (buf)) 0)
utf8_buf = g_utf16_to_utf8 (buf, -1, NULL, NULL, NULL);
if (utf8_buf)
{
g_prgname = g_path_get_basename (utf8_buf);
g_free (utf8_buf);
}
}
}
#endif
retval = g_prgname;
G_UNLOCK (g_prgname);
return retval;
}
I hope this answers your question. It sure helped me to answer it :)
EMAILING FOR THE GREATER GOOD
Join me
Date: Mon, 19 Oct 2009 08:30:56 -0700
From: zheng.easy...@gmail.com
To: gtk-devel-list@gnome.org
Subject: Question about the default title of a GTK window
Hey pals, I am a new comer on GTK things.
I have some questions about it, would any one have time taking me over it?
Here is it:
1, What is the default title of a GTK window? I mean, if there is no string
was assigned to title of a GTK window, what will be exposed in the title bar
of said window?
2, Whether there is another interface for developers on setting title on GTK
window except gtk_window_set_title?
3, More specifications, will GTK framework take application name from
anywhere and set it as title into any untitled window in the application?
That all. Thanks alot.
--
View this message in context:
http://www.nabble.com/Question-about-the-default-title-of-a-GTK-window-tp25960347p25960347.html
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
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
