Re: glib gitlab tag
On Mon, Sep 03, 2018 at 12:15:20PM +0100, Philip Withnall wrote: > On Mon, 2018-09-03 at 10:09 +0100, Patrick Welche wrote: > > but I don't see the 2.58.0 tag! > > I pushed the wrong tag, sorry. Trying to fix it now, but it will need > sysadmin involvement because the git server (rightfully) doesn???t allow > tags to be deleted or changed. > > The release commit you should build is > c138b98e363df8b95c2ee3eac214649b2908ad68; or just build from the glib- > 2-58 branch. I see it's all fixed now! Thanks, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib gitlab tag
I just pointed my local glib repository from git.gnome.org to gitlab.gnome.org. I did the usual pull --rebase. I see Author: Philip Withnall Date: Thu Aug 30 14:40:04 2018 +0100 2.58.0 Signed-off-by: Philip Withnall but I don't see the 2.58.0 tag! ... 2.55.0 2.55.1 2.56.0 2.56.1 2.56.2 2.57.1 2.57.2 2.57.3 EAZEL-NAUTILUS-MS-AUG07 FOR_GNOME_0_99_1 GLIB_1_1_0 GLIB_1_1_1 GLIB_1_1_10 GLIB_1_1_11 ... It is listed at https://gitlab.gnome.org/GNOME/glib/tags What am I missing? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Linking to libstdc++ in HarfBuzz
On Thu, Aug 02, 2018 at 02:38:00AM -0700, Behdad Esfahbod wrote: > Just asking, does anybody still object about using C++ standard library > (ie. linking to it) in HarfBuzz? If you mean add "-lstdc++", then yes... > I know I've been one of the bigger opponents myself. But I can change too. Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Typos in glib's code
On Sat, Feb 15, 2014 at 10:06:49PM +0100, Olivier Delhomme wrote: Hello everyone, I just saw that there is a typo in glib's code. That typo is fairly common as it appears in 132 files. The word licence (French) is used instead of the word license. Peut-etre parce que ca s'ecrit licence en anglais aussi. (Sorry couldn't resist - licence is also the British English spelling) Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' This patch (used for Win32, but there isn't anything win32 specific in there) with minimal editing should get you going. https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch Actually - what's wrong with posix realpath() ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See BTW - if my librsvg is too old, any thoughts on why the non-symbolic png icon is not found? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. I have now tried with librsvg 2.40.1, and evince still doesn't find its icons. I managed to build librsvg with the attached patch. Cheers, Patrick --- rsvg-base.c.orig2013-05-11 09:19:07.0 + +++ rsvg-base.c @@ -2190,8 +2190,7 @@ _rsvg_handle_allow_load (RsvgHandle *han dir = g_file_get_path (base); g_object_unref (base); -/* FIXME portability */ -cdir = canonicalize_file_name (dir); +cdir = realpath (dir, NULL); g_free (dir); if (cdir == NULL) goto deny; @@ -2200,8 +2199,7 @@ _rsvg_handle_allow_load (RsvgHandle *han if (path == NULL) goto deny; -/* FIXME portability */ -cpath = canonicalize_file_name (path); +cpath = realpath (path, NULL); g_free (path); if (cpath == NULL) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote: On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote: On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found) That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Your librsvg may be too old to render symbolic icons. See https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850 and the bug referenced there. Indeed: I am using librsvg 2.36.4 as per the referenced email. I just had a go at building 2.40.1, but: rsvg-base.c:2194:5: error: implicit declaration of function 'canonicalize_file_name' ? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote: Just a random guess, but are you sure Gdk was built with SVG support enabled? You need librsvg, and sometimes it happens to be missing (or not found). That was what I was worried about in: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html I have libpixbufloader-svg.so and an svg entry in loaders.cache. Given that there were no replies, I assume that that is the complete checklist. Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote:
On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote:
On Thu, Nov 21, 2013 at 10:07:55AM -0500, Jasper St. Pierre wrote:
On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@cam.ac.uk wrote:
(gtk-update-icon-cache --validate returns 0 for those two directories
so validates OK.
Is there an easy way of dumping the contents of the cache?)
Is there a way of validating
gnome/icon-theme.cachegnome/index.theme
further?
I'd put a print statement inside the for loop near that if statement that
prints the theme name, e.g.
g_print (searching theme %s\n, theme-name);
It sounds to me like the gnome icon theme isn't being properly added. Maybe
also put lots of print statements in insert_theme. Is that being called
with gnome as a theme name? Is it bailing out at some point before it's
supposed to?
At least g_key_file_load_from_file() is not giving an error with
icons/gnome/index.theme
Probably why icons/gnome cache was found in earlier post? If there
were a problem, found cache for ...icons/gnome wouldn't have been
printed?
gtk_icon_theme_lookup_icon dialog-password
theme_lookup_icon: searching theme hicolor for dialog-password
...
theme_lookup_icon found dialog-password in dir (null)
I don't see searching theme gnome for dialog-password yet it is found.
gtk_icon_theme_lookup_icon go-up-symbolic
theme_lookup_icon: searching theme hicolor for go-up-symbolic
...
theme_lookup_icon: searching theme gnome for go-up-symbolic
...
theme_lookup_icon look for go-up-symbolic in dir .../hicolor/48x48/actions
theme_lookup_icon look for go-up-symbolic in dir .../gnome/48x48/actions
...
BUT not in icons/gnome/scalable/actions
Cheers,
Patrick
--- gtk/gtkicontheme.c.orig 2013-11-11 13:53:39.0 +
+++ gtk/gtkicontheme.c
@@ -1098,6 +1098,8 @@ insert_theme (GtkIconTheme *icon_theme,
priv = icon_theme-priv;
+ GTK_NOTE (ICONTHEME, g_print (insert_theme %s\n, theme_name));
+
for (l = priv-themes; l != NULL; l = l-next)
{
theme = l-data;
@@ -1136,11 +1138,15 @@ insert_theme (GtkIconTheme *icon_theme,
g_key_file_load_from_file (theme_file, path, 0, error);
if (error)
{
+ GTK_NOTE (ICONTHEME,
+g_print (Error loading %s: %s\n, path, error-message));
g_key_file_free (theme_file);
theme_file = NULL;
g_error_free (error);
error = NULL;
}
+ else
+GTK_NOTE (ICONTHEME, g_print (Loaded %s successfully\n, path));
}
g_free (path);
}
@@ -1634,6 +1640,10 @@ choose_icon (GtkIconTheme *icon_th
icon_info = g_object_ref (icon_info);
remove_from_lru_cache (icon_theme, icon_info);
+ GTK_NOTE (ICONTHEME,
+ g_print (choose_icon: found %s in cache\n,
+ g_strjoinv (,, icon_info-key.icon_names)));
+
return icon_info;
}
@@ -2813,6 +2823,10 @@ theme_lookup_icon (IconTheme *t
min_difference = G_MAXINT;
min_dir = NULL;
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon: searching theme %s for %s\n,
+ theme-name, icon_name));
+
/* Builtin icons are logically part of the default theme and
* are searched before other subdirectories of the default theme.
*/
@@ -2822,8 +2836,13 @@ theme_lookup_icon (IconTheme *t
size, scale,
min_difference);
+
if (min_difference == 0)
- return icon_info_new_builtin (closest_builtin);
+{
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon found %s in builtins\n,
icon_name));
+ return icon_info_new_builtin (closest_builtin);
+}
dirs = builtin_dirs;
}
@@ -2836,7 +2855,7 @@ theme_lookup_icon (IconTheme *t
dir = l-data;
GTK_NOTE (ICONTHEME,
- g_print (theme_lookup_icon dir %s\n, dir-dir));
+ g_print (theme_lookup_icon look for %s in dir %s\n,
icon_name, dir-dir));
suffix = theme_dir_get_icon_suffix (dir, icon_name, NULL);
if (best_suffix (suffix, allow_svg) != ICON_SUFFIX_NONE)
{
@@ -2926,11 +2945,18 @@ theme_lookup_icon (IconTheme *t
min_dir-subdir_index);
}
+ GTK_NOTE (ICONTHEME,
+ g_print (theme_lookup_icon found %s in dir %s\n, icon_name,
min_dir-dir));
+
return icon_info;
}
if (closest_builtin)
-return icon_info_new_builtin (closest_builtin);
+{
+ GTK_NOTE (ICONTHEME,
+g_print (theme_lookup_icon found (close to) %s in
builtins\n, icon_name));
+ return icon_info_new_builtin (closest_builtin);
+}
return NULL
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:07:55AM -0500, Jasper St. Pierre wrote: On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@cam.ac.uk wrote: Originally I thought that the lack of icons on my system in the post stock-icons age was because symbolic icons are SVGs: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html (The request for documentation still stands.) It seems that the problem is somewhat different: 1) scalable gnome icons (e.g. symbolic svg icons) are not searched for. 2) the claim If a -symbolic icon is missing, the app will fall back to the regular name. seems to be false. In reverse order, 2) looked as though it should be fixed by commit d25ee710 https://bugzilla.gnome.org/show_bug.cgi?id=708163 which was did appear in 3.10.2 despite the last comment in that bug. It seems that fallback is still broken. 1) seems odd: when running e.g. evince --gtk-debug=icontheme (3.10.3), a gtk 3.10.3 system with gnome-icon-theme-symbolic 3.8.3, and gsetting: org.gnome.desktop.interface icon-theme 'gnome' shows caches found in icons/hicolor and icons/gnome (gtk-update-icon-cache --validate returns 0 for those two directories so validates OK. Is there an easy way of dumping the contents of the cache?) Evince then looks for dialog-password in -? builtins? icons/hicolor/..x.. (why hicolor when gsettings says icon-theme=gnome?) evince/icons/..x.. icons/hicolor/scalable evince/icon/scalable theme_lookup_icon found dialog-password in dir (null) ? builtin - it apparently didn't look in icons/gnome/..x.. which is where the PNGs live. Next is go-up-symbolic, which won't be found, and which lives in icons/gnome/scalable/actions It is looked for in icons/hicolor/..x.. evince/icons/..x.. icons/hicolor/scalable evince/icon/scalable (as before, and in addition) icons/hicolor/..x.. (again, interleaved with icons/gnome) icons/gnome/..x..(because of commit 90dee25e in 3.10.3?) icons/hicolor/..x.. (again, with evince/icons/hicolor) gtk_icon_theme_lookup_icon image-missing so icons/gnome/scalable is not searched, and fallback non-symbolic go-up is also not searched for. hicolor is specified as a fallback icon theme in the icon theme specification, so that apps can place their app icons there. I don't understand your comment. evince isn't providing go-up-symbolic. It is trying to use it. icons/gnome/16x16/actions/go-up.png icons/gnome/22x22/actions/go-up.png icons/gnome/24x24/actions/go-up.png icons/gnome/32x32/actions/go-up.png icons/gnome/48x48/actions/go-up.png icons/gnome/scalable/actions/go-up-symbolic.svg live on the system. go-up-symbolic.svg isn't found as for some reason icons/gnome/scalable isn't searched. non-symbolic fallback go-up.png isn't searched for. Is that clearer? BTW gtkicontheme.c:1658 choose_icon() seems odd: the first block checks for a -symbolic suffix, but appears to do the same as the second block. Was that intentional? Look closer. In the case of symbolic, it searches all themes for icon_names[0] (which is foo-bar-baz-symbolic). In the latter, it tries all the icon names (foo-bar-baz-symbolic, foo-bar-baz, foo-bar, foo) for every theme in order. Hmmm - so why isn't at least go-up found? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 10:40:42AM -0500, Jasper St. Pierre wrote: On Thu, Nov 21, 2013 at 10:35 AM, Patrick Welche pr...@cam.ac.uk wrote: On Thu, Nov 21, 2013 at 10:07:55AM -0500, Jasper St. Pierre wrote: On Thu, Nov 21, 2013 at 9:38 AM, Patrick Welche pr...@cam.ac.uk wrote: (gtk-update-icon-cache --validate returns 0 for those two directories so validates OK. Is there an easy way of dumping the contents of the cache?) Is there any more I can do to check that icons/gnome/index.theme icons/gnome/icon-theme.cache are OK? (Given Gtk 3's --enable-gtk2-dependency, it shouldn't matter if gtk 2.24.20 created the cache?) I'd put a print statement inside the for loop near that if statement that prints the theme name, e.g. g_print (searching theme %s\n, theme-name); It sounds to me like the gnome icon theme isn't being properly added. Maybe also put lots of print statements in insert_theme. Is that being called with gnome as a theme name? Is it bailing out at some point before it's supposed to? Thanks for the pointer - more soon... Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: symbolic icon fallback failure
On Thu, Nov 21, 2013 at 04:14:13PM +0100, Olivier Brunel wrote: On 11/21/13 15:38, Patrick Welche wrote: Originally I thought that the lack of icons on my system in the post stock-icons age was because symbolic icons are SVGs: https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html (The request for documentation still stands.) It seems that the problem is somewhat different: 1) scalable gnome icons (e.g. symbolic svg icons) are not searched for. 2) the claim If a -symbolic icon is missing, the app will fall back to the regular name. seems to be false. In reverse order, 2) looked as though it should be fixed by commit d25ee710 https://bugzilla.gnome.org/show_bug.cgi?id=708163 which was did appear in 3.10.2 despite the last comment in that bug. It seems that fallback is still broken. Just in case: are you running the latest GLib (2.38.2) as well? I don't know how icons are loaded in your case, but they could come from glib and the fallback to non-symbolic icons was only added there in 2.38.2 Thanks for the note - I was running 2.38.1, but just tried 2.38.2 and there is no change: evince is asking gtk to look for the icons... Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, Aug 20, 2013 at 03:01:25PM +0100, Patrick Welche wrote: On Tue, Jul 02, 2013 at 10:44:13AM -0400, Matthias Clasen wrote: On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). Since gcalctool moved away from stock icons (f962134f66), I can't tell the difference between undo and clear - both appear as the icon not found icon, which causes a problem with usability. If there is an automatic fallback mechanism, I don't see how it is working, and 1. Provided a guaranteed, consistent, and high quality set of icons for use in applications. seems to have evaporated. From http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Implementations are required to look in the hicolor theme if an icon was not found in the current theme. Which suggests that there should be a fallback mechanism, but given the gcalctool example, it doesn't seem to be implemented? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stock Items Deprecation
On Tue, Jul 02, 2013 at 10:44:13AM -0400, Matthias Clasen wrote: On Tue, Jul 2, 2013 at 10:29 AM, Tristan Van Berkom t...@gnome.org wrote: Besides what Bastian already points out, I have another concern if we are to consider moving away from stock items completely. The document above points to this list of icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names What guarantees do we have that referring to an icon name in the icon naming spec will actually produce an icon ? GTK+ ships with a built-in icon theme that covers the named icons used by the stock system (not all listed in the naming spec). Since gcalctool moved away from stock icons (f962134f66), I can't tell the difference between undo and clear - both appear as the icon not found icon, which causes a problem with usability. If there is an automatic fallback mechanism, I don't see how it is working, and 1. Provided a guaranteed, consistent, and high quality set of icons for use in applications. seems to have evaporated. Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Something I don't understand
On Fri, May 31, 2013 at 09:15:39AM +0100, John Emmas wrote: I just wondered if someone could help me with something that's puzzling me about a recent Glib commit... On 27th May, Dan Winship made a commit whose description is Add Makefile.glib and GLIB_CONFIG configure macro. According to my Git package (TortoiseGit) it looks as if the following two files got deleted as part of that commit:- FWIW I don't see it - do you have the commit ID? Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 660761
On Fri, Nov 25, 2011 at 09:32:41AM +0100, Olav Vitters wrote: On Fri, Nov 25, 2011 at 10:28:55AM +0200, Kean Johnston wrote: Please can glib devs give https://bugzilla.gnome.org/show_bug.cgi?id=660761 a little love? Its been a month and a half since I posted the last patch and there has been no traction on it. Suggestion: Best to always copy/paste the summary. No clue what it is about, too lazy to click as likely not for me (not a dev) :P glib/gmodule: Give builder opportunity to change DLL extension There are a few places where the extension of .dll is hard-coded. While it is true that this is most often the right name, there are circumstances where it is useful for the person compiling GLib to be able to use something else. For example, when compiling both 32-bit and 64-bit versions to sit side by side it is useful to have 32-bit extensions have one suffix (say, .x32) and 64-bit versions to have another (say, .x64). The attached patch provides the person compiling GLib with just that flexibility, and doesn't change any defaults. Just providing the lookup service ;-) Cheers, Patrick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
