how to set widget background?
hi, I have a hbox that looks like this: - | || | | | | | | | || - is a gtkimage is text in gtklabel how can I set the background color for the whole hbox? gtk_widget_modify_bg won't work. I need the color for the whole hbox. when I set the background of the text, only the background of the letters is drawn in the specified color... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to set widget background?
On Dec 3, 2007 3:57 AM, Guenther Meyer [EMAIL PROTECTED] wrote: hi, I have a hbox that looks like this: - | || | | | | | | | || - is a gtkimage is text in gtklabel how can I set the background color for the whole hbox? gtk_widget_modify_bg won't work. I need the color for the whole hbox. when I set the background of the text, only the background of the letters is drawn in the specified color... Add a GtkEventBox, then add your hbox to the event box. Set the background color for the event box. -Jim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Announce: gio merged
On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: * gio/gcontenttype.c : use GDir instead of using dirent.h Hmm? Why is that building on Win32? It should be picking the #ifdef G_OS_WIN32 part of that file. You are right. I was just fooled by the unconditional #include dirent.h and mechanically translating to GDir (without testing if it compiles). But - given that there are two completely independent implementations in this file - wouldn't it be better to split it into gcontenttype-win32.c and gcontenttype-unix.c ? Probably. I'm not sure why they ended up in the same file while e.g. the appinfo stuff got split. Just happened I guess. gsocketinputstream.c gsocketoutputstream.c needs some reimplementation/porting to use winsock specific API. This has been made Unix only. We'll probably need a winsock version of this later though. g_io_modules_ensure_loaded (GIO_MODULE_DIR); It would be nice if this function would take no parameter to allow implementation of dynamic DLL placement resolvement in one place. Hmm. This is also used by gvfs to load its modules. It then passes a different location to the function ($(libdir)/gvfs/modules). Can you describe in more detail what you want it to do? On windows the location of DLLs is deduce at runtime. It depends on where a setup installed the DLLs, rather than fixed at compiled time. Thus we have established a pattern to resolve module placement from the DLL loading them. See for example gtk/gtkmodules.c. My first idea was taht the parameter to g_io_modules_ensure_loaded() was always the same. Thus it would have been possible to do the dynamic path calcualtion in just this one function. Of course GIO_MODULE_DIR can be defined to a function call on win32, to keep the other code like it is. _gio_win32_module_dir() will have to return a static string than. Thats a way it can be made to work with the current use in libgio, but it makes the API sort of weird for win32. How exactly is the dynamic path calculated? Maybe its possible to make the API work in some relative way? That way some other library on could also use g_io_modules_ensure_loaded() to load its modules relative to its dll. glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test g_file_test is pretty lame though. It does a new stat each time you call it and there are no ways to get more than a single piece of info for each call. This will just slaughter i/o performance. What exactly is it that you need it to do that g_file_test does? We need to move that into glocalfile.c instead. The first thing is the undefined statfs_buffer for !USE_STATFS and !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand the unknown API first to propose how to port it. On a quick glance the missing definition for S_ISDIR led me to propose g_file_test(). But of course this can be resolved differntly. Maybe we should have a full alternative implementation of g_local_file_query_info() using GetFileAttributes and similar calls. I think we can make the posix version mostly work for win32, but a native implementation can get more information, like fat attributes (hidden, archive, system) and NT ACLs. I think the interesting parts for a native win32 implementation is (for local files, i.e. in glocalfile.c): g_file_query_info() - This returns information about a file, like size, type, icon, last changed, etc. The return type is a GFileInfo which is a key-value container where the keys are namespaced strings like std:type or unix:uid. g_file_query_filesystem_info() - Similar to the above, but gets information about the filesystem the file is on. i.e. total diskspace, diskspace left, type of filesystem. g_file_enumerate_children() - This is readdir() + stat of each file combined into one. I think Win32 has a better fit to this, where FindNextFile actually returns stat info. On posix you need to make a separate stat call for each filename readdir() returns. So, a native win32 implementation of GFileEnumerator would be more efficient. None of this is strictly necessary of course, so it all depends on how much time the win32 developers want to spend on it. Finally gio.symbols should be added to make exporting of symbols (and what not;) as easy as for glib/gobject and gtk+ It also needs to set up the aliases work for unix... I'll take a look at it. Do you want me to commit the uncritical pieces? Everything but the gcontenttype.c part (that should not build on win32) looks good to me. Ok, revert that thing and just moved the #include dirent.h stuff into the !G_OS_WIN32 #else. Did you commit your stuff? In the first chunck I was also completely missing the gwin32appinfo.c thing. Now it is giving me a hard time by using somewhat unusual API - not available in my current Platform SDK installation. There are people claiming shlwapi.h to be one of the worst designed libraries to
Re: keyboard functions
On Sat, 2007-12-01 at 14:19 +0100, linux user wrote: Every day is more and more necessary to dominate the keyboard, especially in applications running in a globalized contexts which work with different languages, so need to switch / change the configuration of characters (letters) along the keyboard (according those languages). Or more exactly, with the same keycodes (because usually the same keyboard) produce different letters according the prefered layouts of each language. X Window System foresaw this situation and provide us some mechanisms... among them, we have the configuration files placed (at least on my computer) in /usr/share/X11/xkb and /etc/X11. Default keyboard configurations (layouts variants, mainly, rigth here..) -set in /etc/X11/xorg.conf- are defined in /usr/share/X11/xkb/... Furthermore, if an option like grp:switch,grp:shift_toggle or grp:switch,grp:alt_shift_toggle is provided, it's possible to switch among two, three or four keyboards (= character configurations). It's also possible, in a graphical console, to use the command setxkbmap, and in Gnome Dektop Environment, we have the gnome-keyboard-properties application. But... Why the silence in the GTK+ users list when I ask the way to do it in my GTK+ applications ? Perhaps: http://freedesktop.org/wiki/Software/LibXklavier Would help you. These features will not be added to GTK+ itself because: - They are only useful for a very small number of applications - They are not useful for applications running inside a desktop environment like GNOME or KDE. - They are X specific. Other systems configure keyboards very differently. - There's no advantage in adding them to GTK+, since they are X specific. Applications can use libXkb and libXklavier if they need the functionality. - 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
[REMINDER] GTK+ Team Meeting -- December 4, 2007
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. the points are: * GIO merge post-mortem and follow-up * Extended layout hints (Google Summer of Code) * Version bump for GTK+/GLib eventual changes will be made on the wiki page[0]. everyone can partecipate, as usual. Note: I won't be able to attend, so there won't be the usual nagging on IRC; and if somebody could take the log of the meeting for the web site it would be greatly appreciated. ciao, Emmanuele. +++ [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=12day=04year=2007hour=20min=0sec=0p1=0 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Static compose table in gtkimcontextsimple.c
I notice there's a large table of compose sequences in gtkimcontextsimple.c. Is there any particular logic to the exact sequences listed here, or would it be acceptable to add some more? I'd quite like to have some mappings of Esperanto characters added; namely: GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_G, 0, 0, 0, 0x011D, /* LATIN_CAPITAL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_H, 0, 0, 0, 0x0124, /* LATIN_CAPITAL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_J, 0, 0, 0, 0x0134, /* LATIN_CAPITAL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_S, 0, 0, 0, 0x015C, /* LATIN_CAPITAL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_g, 0, 0, 0, 0x011D, /* LATIN_SMALL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_h, 0, 0, 0, 0x0125, /* LATIN_SMALL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_j, 0, 0, 0, 0x0135, /* LATIN_SMALL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_s, 0, 0, 0, 0x015D, /* LATIN_SMALL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_caron, GDK_U, 0, 0, 0, 0x01D3, /* LATIN_CAPITAL_LETTER_U_WITH_CARON */ GDK_dead_caron, GDK_u, 0, 0, 0, 0x01D4, /* LATIN_SMALL_LETTER_U_WITH_CARON */ Should I submit a patch? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libgdl runtime error on gtk+-quartz
John Swensen wrote: I have compiled gtk+ using the script from Imendio and everything was working fine. I have compiled several programs against it and they all work beautifully. Then I decided to use the libgdl dock widget and ran into problems. This has been fixed in svn now (trunk and 2.12 branch), thanks for the report. Regards, Richard -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: keyboard functions
Mr. Owen Taylor, I'm very glad. Is the kind of answer that I hope !. Thanks a lot !. Applications can use libXkb and libXklavier if they need the functionality. Is there anywhere that I can post my doubts in using these functions ? (I see that in the API reference, there are not too much explanations ...). But thanks anyway... Thanks a lot for your answer ! - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gio on win32 (was Re: Announce: gio merged)
On 03.12.2007 10:07, Alexander Larsson wrote: On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: [...] g_io_modules_ensure_loaded (GIO_MODULE_DIR); It would be nice if this function would take no parameter to allow implementation of dynamic DLL placement resolvement in one place. Hmm. This is also used by gvfs to load its modules. It then passes a different location to the function ($(libdir)/gvfs/modules). Can you describe in more detail what you want it to do? On windows the location of DLLs is deduce at runtime. It depends on where a setup installed the DLLs, rather than fixed at compiled time. Thus we have established a pattern to resolve module placement from the DLL loading them. See for example gtk/gtkmodules.c. My first idea was taht the parameter to g_io_modules_ensure_loaded() was always the same. Thus it would have been possible to do the dynamic path calcualtion in just this one function. Of course GIO_MODULE_DIR can be defined to a function call on win32, to keep the other code like it is. _gio_win32_module_dir() will have to return a static string than. Thats a way it can be made to work with the current use in libgio, but it makes the API sort of weird for win32. How exactly is the dynamic path calculated? Maybe its possible to make the API work in some relative way? That way some other library on could also use g_io_modules_ensure_loaded() to load its modules relative to its dll. The thing needed than would be the DLL name or the HANDLE of the DLL to resolve the relative path against. I'm not sure though how the responsibilities need to be split for loading some gio-modules. Is an application supposed to deliver it's own extension modules for gio? glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test g_file_test is pretty lame though. It does a new stat each time you call it and there are no ways to get more than a single piece of info for each call. This will just slaughter i/o performance. What exactly is it that you need it to do that g_file_test does? We need to move that into glocalfile.c instead. The first thing is the undefined statfs_buffer for !USE_STATFS and !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand the unknown API first to propose how to port it. On a quick glance the missing definition for S_ISDIR led me to propose g_file_test(). But of course this can be resolved differntly. Maybe we should have a full alternative implementation of g_local_file_query_info() using GetFileAttributes and similar calls. I've started something of this, but not commited yet. (I'm getting too old for all these ifdefs ;)) See attahed patch. I think we can make the posix version mostly work for win32, but a native implementation can get more information, like fat attributes (hidden, archive, system) and NT ACLs. I think the interesting parts for a native win32 implementation is (for local files, i.e. in glocalfile.c): g_file_query_info() - This returns information about a file, like size, type, icon, last changed, etc. The return type is a GFileInfo which is a key-value container where the keys are namespaced strings like std:type or unix:uid. This sounds like the application again must be unix/win32 specific. Or who is supposed to interpret the unix:uid key? Could some of this be abstracted away? g_file_query_filesystem_info() - Similar to the above, but gets information about the filesystem the file is on. i.e. total diskspace, diskspace left, type of filesystem. Again I alread started a win32 specific implementation, not commited yet but attached for review. g_file_enumerate_children() - This is readdir() + stat of each file combined into one. I think Win32 has a better fit to this, where FindNextFile actually returns stat info. On posix you need to make a separate stat call for each filename readdir() returns. So, a native win32 implementation of GFileEnumerator would be more efficient. None of this is strictly necessary of course, so it all depends on how much time the win32 developers want to spend on it. At the moment I'm concentrating on getting gio to work at all. At some points there still is working implmentation missing. My current unresolved externals (i.e. some of the stuff that compiles still requires functions not compiled) : glocalfile.obj : error LNK2001: unresolved external symbol _g_unix_mount_free glocalfile.obj : error LNK2001: unresolved external symbol _g_unix_mount_is_readonly glocalfile.obj : error LNK2001: unresolved external symbol _g_get_unix_mount_at glocalfile.obj : error LNK2001: unresolved external symbol _g_unix_mounts_changed_since glocalfile.obj : error LNK2001: unresolved external symbol _localtime_r glocalfile.obj : error LNK2001: unresolved external symbol __g_local_directory_monitor_new glocalfileinfo.obj : error LNK2001: unresolved external symbol _get_groupname_from_gid glocalfileinfo.obj : error LNK2001: unresolved external
Re: Static compose table in gtkimcontextsimple.c
On Mon, 2007-12-03 at 17:08 +, Paul LeoNerd Evans wrote: I notice there's a large table of compose sequences in gtkimcontextsimple.c. Is there any particular logic to the exact sequences listed here, or would it be acceptable to add some more? The table should be in sync with the one from Xorg, /usr/share/X11/locale/en_US.UTF-8/Compose There is a bug report on this, Synch gdkkeysyms.h/gtkimcontextsimple.c with X.org 6.9/7.0 http://bugzilla.gnome.org/show_bug.cgi?id=321896 I'd quite like to have some mappings of Esperanto characters added; namely: GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_G, 0, 0, 0, 0x011D, /* LATIN_CAPITAL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_H, 0, 0, 0, 0x0124, /* LATIN_CAPITAL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_J, 0, 0, 0, 0x0134, /* LATIN_CAPITAL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_S, 0, 0, 0, 0x015C, /* LATIN_CAPITAL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_g, 0, 0, 0, 0x011D, /* LATIN_SMALL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_h, 0, 0, 0, 0x0125, /* LATIN_SMALL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_j, 0, 0, 0, 0x0135, /* LATIN_SMALL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_s, 0, 0, 0, 0x015D, /* LATIN_SMALL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_caron, GDK_U, 0, 0, 0, 0x01D3, /* LATIN_CAPITAL_LETTER_U_WITH_CARON */ GDK_dead_caron, GDK_u, 0, 0, 0, 0x01D4, /* LATIN_SMALL_LETTER_U_WITH_CARON */ Should I submit a patch? A quick glance at the compose file of Xorg shows that these sequences exist there which is good. If you would like to help with bug 321896 it would be great. The current state is on how to make the table much smaller, even with the addition of more keysyms. There is a script that converts en_US.UTF-8/Compose into a series of arrays that should be easy for GTK+ to work on. Regarding Greek polytonic there is an optimisation suggested by Tor to reduce the sequences (current about 1000 sequences out of 5000). Simos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */ [...] GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */ [...] The sequences you list are exactly of the straightforward kind that in my opinion can and should be handled algorithmically. I.e. a dead accent followed by a letter can be mapped to the corresponding precomposed character without an explicit table. I have a patch in bug #321896 that implements such an algorithm (and which would handle your cases, too.) Basically it's waiting for a second opinion from the GTK+ maintainers. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
