Re: symbolic icon fallback failure
Le vendredi 22 novembre 2013 à 12:56 +, Patrick Welche a écrit : 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 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). My two cents ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.XX sources
Le dimanche 24 mars 2013 à 12:39 +, John Emmas a écrit : If I'm working on an application which still uses GTK+ version 2, is it still possible to obtain the sources (using subversion or git) or is version 2 only available from tarballs now? Of course, git stores all of GTK's history. You can find the last GTK 2 code in the gtk-2-24 branch. Use 'git checkout gtk-2-24', or see https://git.gnome.org/browse/gtk+/log/?h=gtk-2-24 Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to make a progress-bar thinner?
Le vendredi 30 mars 2012 à 09:35 +0200, Osmo Antero a écrit : Hello, How can I make a GtkProgressBar thinner in this application. See: http://www.futuredesktop.com/tmp/test1.c And http://www.futuredesktop.com/tmp/screenshot1.png I'm not sure at all you can make it smaller. Actually, the button on the left hand-side is higher than the progress bar, so you cannot gain space here - and this size depends on the font size, so no luck with padding. The general problem IMHO is that you're basically trying to theme your application, and GTK is really not designed that way. You don't really control the appearance of the widgets, at least not at such a detailed level. If you're not happy with the progress bar, you may use a slider instead (just like other sound applications). PS : this list is about discussion of GTK internal development. YOu should have used gtk-app-devel-list for this problem. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GI Help
Le mardi 20 décembre 2011 à 06:36 +0330, bijan binaee a écrit : Thanks i mean that why this project doesn't have any document !! also i read all document that available on gnome but any of them not sufficient for my work i define my work again: i have a c code and i want to bind it to JavaScript that document you send to me is for how to write code in Gjs that i know it Have a look at what gnome-shell does, that's the best solution to work around the lack of proper documentation: https://live.gnome.org/GnomeShell/Development http://git.gnome.org/browse/gnome-shell/tree/ Good luck! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New modes for GtkProgressBar
Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: New modes for GtkProgressBar
Le lundi 31 octobre 2011 à 15:54 +0530, Rhishikesh a écrit : First mode would be an activity mode which could be used for showing ongoing indeterminate activity ...and wouldn't you use a GtkSpinner for this? ;-) Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Le mercredi 28 septembre 2011 à 11:03 +0200, Kean Johnston a écrit : Only if you define UNIX as Linux. OSX has other fields Linux doesn't. Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 16-bit ino_t's others have 64. There are all KINDS of ways in which it differs. Offering a portable, no-ifdefs-required, suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* that all code can use completely portably without having to worry about anything ... SURELY you can see the value in that? GFileInfo from GIO? You have GOT to be kidding me? As a replacement for stat()? When I want to look up a file attribute I have to go through hash table lookups for attributes and a completely open-ended size (GArray *attributes) and all that parent class and instance overhead - versus having a single structure I can sizeof() and write to a file? In what universe is that a better approach? Do you have a use case where hash-table lookups would be a bottleneck? With dual-core CPUs we have nowadays, disk access is likely to be much slower than the hash-table work that GIO produces. And few programs would need to stat that many files anyway. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
Le mardi 06 septembre 2011 à 16:34 -0700, John Ralls a écrit : I'm not going to respond to most of that. I think you shouldn't take Emmanuele's tone so bad. ;-) He's always very direct, but his point is right, and his suggestions are actually the acknowledgment that your work is worth being part of core GTK - they are meant to help you. I'm going to try telling things in a slightly nicer fashion... Suffice it to say that building gtk-osx is largely automated, and there are well-tested instructions at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build That's not the question. This page should be on live.gnome.org, because that's where we assume docs are, and people with an account there can give a hand. I didn't get commit privs at Gnome.org until just under a year ago, 18 months after I took over from Richard. I still don't have privs on any of the other facilities except Bugzilla, and there only because I'm a Gnucash Dev. (That turns out to be sufficient for almost everything.) Maybe it took some time, but in my experience getting privileges is very fast. Anyway, now you have everything you need to work on gnome.org, don't you? Gtk-OSX needs its own mailing list because it provides jhbuild modules for over 100 separate projects, not all of which are even Gnome. It's not feasible for me to monitor all of them for support, nor is it reasonable for users of my build scripts to have to figure out which one to use for any particular problem. So maybe you need a separate mailing list for helping building these programs, but it could live on gnome.org. For GTK+ development itself , the present list is the natural place, like Emmanuele said. It's not a fork of Gtk+ (yet, though on days like this one I get really tempted). I actually revived the gtk-osx project on SF; the previous version was an actual fork of Gtk1. So let's improve things a step more, and completely merge the project. Sounds like the natural end of the story. :-) As I explained earlier, the changes *are* patches, they *are* attached to bugs in Bugzilla, and Kris Reitveld *has* promised to review them. When he has had time to do so and they have been polished to his high standards, they will be committed into mainline. If you need Kris to review your patches before committing them to mainline, then the usual way is to have a branch in the GTK git repository, and rebase it into master when it's accepted. That's much easier for everybody, much better than putting them on a different repo. In the meantime they're quite useful for a number of projects who want a better Mac experience for their users than the Gtk core devs seem motivated to provide. *This* is a different issue. If reviewers cannot keep up with your patches, and you need to release tarballs that include code not in mainline, that means gtk-osx isn't yet fully merged into GTK. But, disregarding the fact that it would probably be good that everything goes to mainline in time, putting your gtk-osx special branch on in the GTK repository instead of SF would be a good thing. I hope that was helpful... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing the places sidebar between Nautilus and GTK+
Le mercredi 07 septembre 2011 à 01:53 +0200, Jannis Pohlmann a écrit : * the sidebar has no mount/eject progress indicators, There's a rough patch for it, maybe it will be committed soon: https://bugzilla.gnome.org/show_bug.cgi?id=619665 * the eject buttons do not look/feel clickable, i.e., they don't change their appearance on hover events, This was apparently committed before 3.0, but I don't see it. Bug is: https://bugzilla.gnome.org/show_bug.cgi?id=544103 Of course, some of these missing features are due to cell renderer limitations, e.g. last time I tried, I couldn't get hover-in/hover-out events for individual cells to work good enough to implement a fully-working button renderer. But still, the places sidebar has more potential and the current implement feels somewhat half-baked. Yeah, GtkTreeView would need some changes to implement this properly, but a hacky solution works currently (see patches). I had filed this: https://bugzilla.gnome.org/show_bug.cgi?id=586458 Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Le lundi 30 mai 2011 à 20:17 -0400, Morten Welinder a écrit : Doing a g_return_val_if_fail is fine here. That will give the user a chance of saving his work. This is in contrast to g_error which is a sure way of eating data. There's no work of data here. Programs load GSettings on start, and OTC it's far better for users' data to ensure a program won't start without schemas. If it pretends to work, it might crash at any point because the code paths run when schemas are not present are poorly tested (if at all), and do nasty things to the data it works with. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Le vendredi 27 mai 2011 à 19:04 -0700, Hubert Figuiere a écrit : My code is *designed* to actually manage default value. Like UI has default that people whine about. This is just good programing practice. While I can perfectly conceive we might need a way to avoid crashing when a schema is missing (e.g. when loading broken plugins), I really think code designed to manage default values is wrong. And that's exactly what GSettings's behavior is meant to prevent. What the point of duplicating information in the schemas and in the code? In the good GConf times, you had to create several code paths every time you read a key in case the setting wasn't valid, or had no default. And then you had to keep the hardcoded default in sync with the schemas to avoid a big mess. With GSettings, that's easy: you're guaranteed to get a correct value, and in the worst case the default. You don't need any if() in your code, and you can change the default just by editing the schema. GSettings was designed with the idea that settings can't be missing in mind. As Havoc said, consider them as being part of the code (at least as a metaphor). There's no good reason a program should have missing schemas - except maybe in the case of plugins. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Le vendredi 27 mai 2011 à 08:51 -0700, Hubert Figuiere a écrit : First, if the UI file is missing the application does not abort. There is an error but it can be handled by the application, and eventually recovered gracefuly. I deleted all the UI files and my app didn't crash. Sure it was not very functional but I actually had the opportunity to show a proper error message to the user. Not a crash. That's already what you get: g_error (Settings schema '%s' is not installed\n, name); I really can't imagine what you could do from a program missing its schemas, except if you hardcode (i.e. duplicate) all default values in the code to handle this broken case, which we actually want to avoid. You could probably show a GTK error dialog, but people that don't know to look at the console output wouldn't understand the settings issue anyway... The only place where it makes sense not to exit is for an application that loads extensions. Maybe it's worth having a convenience function around g_settings_list() to check the schema is present before loading it... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: understanding gtype and gobject
Le mercredi 20 avril 2011 à 06:13 -0400, abhishek desai a écrit : I am trying to understand the gtype system and the gobject system. http://developer.gnome.org/gobject/stable/ Unable to figure out the difference between the gobject constructor and the gtypes instance_init function. Why do we use a constructor function in gobject ? Can we not do the functionality in the instance_init itself ? instance_init is the standard init function to use. constructor is called later when the object has been initialized, and is only useful if you need to rely on construction GObject properties having been set already. See http://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation For instance_init: Provide an instance_init function to initialize your object before its construction properties are set. This is the preferred way to initialize a GObject instance. This function is equivalent to C++ constructors. For constructor: If you need to complete the object initialization after all the construction properties are set, override the constructor method and make sure to chain up to the object's parent class before doing your own initialization. In doubt, do not override the constructor method. But I'd like to understand why the table on the page shows constructor before instance_init, while the former is actually called *after* the latter... Regards PS: General questions like yours should rather be asked on gtk-app-devel-list: the present list is for development of GTK+ itself. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: copying a file from a source path to destination path
Le vendredi 10 décembre 2010 à 10:55 +0530, Lourembam Lenin a écrit : Hi Team, How can i copy a file from a source path to destination using Glib libraries. See http://library.gnome.org/devel/gio/stable/GFile.html#g-file-copy I have checked using Glib file utilities, but could not find my requirement. I guess you only found the page listing basic file utility functions. The main GLib part for handling files is GIO. Next time you need help, please use gtk-app-devel-l...@gnome.org. The present list is only for development of GLib/GTK itself, not of applications using it. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Patch to detect and obbey .hidden files
Le mercredi 15 septembre 2010 à 15:55 -0300, Daniel Morais a écrit : Hello people, I made a little patch to GTK to make .hidden files to be read and consequently hide the listed files inside it when Show Hidden Files is not marked. Most of the code was taken from Nautilus, with minor changes to suit the gtk coding style. I'd be glad if you take this in consideration. http://pastebin.com/Uq3DTKwQ Hi! Thanks for the patch, this would be a nice addition IMO. But please file a bug in Bugzilla and attach the patch there: it's the general workflow for patches. This way you'll ensure the appropriate people will be notified, and the review of the patch will be easier. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le lundi 28 juin 2010 à 21:25 +0200, Xavier Claessens a écrit : How could I come up with a better API if: 1) You don't tell what's wrong with current? 2) You keep repeating completion is not used by app, and barely used code shouldn't be included in GLib? If that was true, even a better API should be rejected in glib... or is there something I didn't understand? I think Emmanuele already listed the main issues with the current API: • g_completion_new(): not bindable; requires at least a new version with a GDestroyNotify function for language bindings. • the GCompletionFunc doesn't have a data parameter, making it unbindable. • the GCompletion structure is completely exposed and cannot be extended or updated, hence we cannot add a GCompletionFuncData that takes a user data parameter, unless we use the struct alignment C trick, in which case the func pointers will be set to NULL even in valid cases. • the same applies for GCompletionStrncmpFunc. • the whole API uses untyped lists, which makes its use awkward from anything that's not C - and even in C it's odd to use, especially with regards to bookkeeping of the items. So basically one would have to suggest an API more in key with the current conventions and bindings-friendly. What about providing something mixing search and completion from your GtkLiveSearch proposal? These features are deeply related with e.g. the advanced ways of searching (à la GNOME Do), allowing completion from different parts of a string, the beginning of any word, escaping accented characters... The new API should be usable alone, or automatically tied to a couple GtkEntry/GtkTreeView, so that only one completion API exists in GLib/GTK. Just my 2c ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
File Chooser patches to review
Hi! I've made a few patches to fix several little bugs that we have in the GtkFileChooser for some time. Some have been reviewed, approved, but eventually forgotten, and others did not get any response. While there's no hurry to apply them before the next release, I suspect they won't get any attention until the final rush, and finally won't be committed. So many patches have rotten this way... ;-) These little details are IMHO the only remaining problems that make users angry about our nice file chooser (now that dialog size is fixed). I think fixing them is worth the pain! So here's the list: * Remove error dialog when directory does not exist http://bugzilla.gnome.org/show_bug.cgi?id=562579 - Improve my previous committed patch by extending its logic, should not be a problem. * Resume editing if name of new folder is Type name of new folder http://bugzilla.gnome.org/show_bug.cgi?id=171416 - Commit accepted by Federico, but I don't have commit rights. * File Dialog shows Backup Files http://bugzilla.gnome.org/show_bug.cgi?id=355851 - No response, the bug was dead since 2007. Pretty basic fix too. * 'Places' items should not move up and down the whole UI when selected http://bugzilla.gnome.org/show_bug.cgi?id=486839 - I've attached a patch that's not been reviewed. This one may require some discussion, but it works quite well. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Bug?] GtkStatusIcon bad default size when used with GtkIconFactory
Le samedi 05 avril 2008 à 06:18 +0800, 洪任諭 wrote: This is quoted from gtk+ API doc. I think this weird behavior is related to your problem. gtk_icon_info_load_icon () GdkPixbuf* gtk_icon_info_load_icon (GtkIconInfo *icon_info, GError **error); Renders an icon previously looked up in an icon theme using gtk_icon_theme_lookup_icon(); the size will be based on the size passed to gtk_icon_theme_lookup_icon(). Note that the resulting pixbuf may not be exactly this size; an icon theme may have icons that differ slightly from their nominal sizes, and in addition GTK+ will avoid scaling icons that it considers sufficiently close to the requested size or for which the source image would have to be scaled up too far. (This maintains sharpness.) gtk+ doestn't load images in the size you specified. This really bothersome in some cases. Thanks for this interesting quotation. But I can't see how this may affect my case. Here's my scheme: - two icon sources: one SVG and one PNG-22x22 - a GtkStatusIcon that normally is set to 22x22 Why the hell would GTK+ draw the icon from SVG in 20x20, and then consider this as better than 22x22?! Moreover, when the SVG is removed and I set size_wilcarded to FALSE for the PNG, the GtkStatusIcon has no icon at all, so this is not about scaling anything. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Bug?] GtkStatusIcon bad default size when used with GtkIconFactory
Brian J. Tarricone wrote: What happens when you create a new GtkIconSource here for the PNG icon? E.g.: iconSource = gtk_icon_source_new(); I'm not sure, but gtk probably doesn't make a copy of the GtkIconSource you add via gtk_icon_set_add_source(). So when you set the PNG filename a couple lines down from here, you actually overwrite the entry for the SVG icon above. Again, not completely sure here, as I don't have time to read the docs atm, but give it a try. Indeed, GTK makes a copy of the IconSource. This is documented here: http://library.gnome.org/devel/gtk/2.12/gtk-Themeable-Stock-Images.html#gtk-icon-set-add-source This function copies source, so you can reuse the same source immediately without affecting the icon set. And I tried with several methods, only using SVG or PNG to check what could be wrong. Thanks anyway - other ideas? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkStatusIcon bad default size when used with GtkIconFactory
Hi! I'm trying to use the GtkIconFactory system to set the icon used by GtkStatusIcon. Once I've created the GtkIconSet for my icons (I have SVg and PNG versions of the same icon), I use gtk_status_icon_set_from_stock. Everything goes right, except that the created icon is 20x20 px by default (i.e. when the GNOME panel is set to a size of 24 px), when it should be (like every app does) 22x22. Normally, the status icons measure: (height of the panel) - 2 px. But this is not true in my case until the panel is = 26 px. The strange point is, if I set the GtkStatus Icon directly from an icon file, the size is 22x22. Is that a bug in GNOME or am I doing something wrong? I guess this would be the prefferred way of setting up a status icon, since with a custom sotck icon it can be risized without problems - but still I may have missed something. Thanks in advance! Here's for reference a part of the code that I use, if you like (it's in gnunet-gtk from the GNUnet project): char *instDir; char *iconPath; GtkStatusIcon *trayIcon; GtkIconSet *iconSet; GtkIconSource *iconSource; (...) iconSet = gtk_icon_set_new (); iconSource = gtk_icon_source_new (); iconPath = g_build_filename (instDir, .., gnunet-gtk, gnunet-gtk-status-connected.svg, NULL); gtk_icon_source_set_filename (iconSource, iconPath); g_free (iconPath); gtk_icon_set_add_source (iconSet, iconSource); iconPath = g_build_filename (instDir, .., gnunet-gtk, gnunet-gtk-status-connected.png, NULL); gtk_icon_source_set_filename (iconSource, iconPath); g_free (iconPath); gtk_icon_source_set_size_wildcarded (iconSource, FALSE); gtk_icon_set_add_source (iconSet, iconSource); gtk_icon_factory_add (GNUNET_GTK_get_iconFactory(), gnunet-gtk-status-connected, iconSet); gtk_icon_set_unref (iconSet); gtk_icon_source_free (iconSource); gtk_status_icon_set_from_stock (trayIcon, gnunet-gtk-status-connected); ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
