Adding .hidden support to the GTK File Chooser
Hi Guys, I'm looking into adding support for .hidden to the GTK File Chooser see: https://bugzilla.gnome.org/show_bug.cgi?id=596234 however I'm not 100% sure where I should be making this change. I'm thinking the change should be made to Glib in gfileinfo.c g_file_info_set_is_hidden() that way the code can be shared with Nautilus (the same existing code could then be removed from Nautilus) and any other application that wishes to use it. Does this sound like the right place to be making the change? Thanks, Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding .hidden support to the GTK File Chooser
hi, On 12-11-26 04:05 AM, Timothy Arceri wrote: I'm looking into adding support for .hidden to the GTK File Chooser see: https://bugzilla.gnome.org/show_bug.cgi?id=596234 however I'm not 100% sure where I should be making this change. I'm thinking the change should be made to Glib in gfileinfo.c g_file_info_set_is_hidden() that way the code can be shared with Nautilus (the same existing code could then be removed from Nautilus) and any other application that wishes to use it. Does this sound like the right place to be making the change? The bug you link is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=587806 which already has a very old (2009) patch. The patch was rejected due to its dependency on the existence of a mainloop to clear the cache. GLib now has a helper main context inside of libglib that could be used instead. If you wanted to solve this problem, the patch on that bug would definitely be a good place to start. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
Hi, On Sat, 2009-05-16 at 20:36 -0400, Morten Welinder wrote: IMO this is now pretty much of a non-issue, since the current GTK file selection dialog is sufficiently like Windows (but nicer!). I'm not sure what planet you're living on. The current gtk+ file chooser absolutely stinks! It fails miserably in its primary task: showing the user what files are there in order to let the user pick one. In particular is it very, very bad at managing its screen real estate. See http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/ http://blogs.gnome.org/mortenw/2009/02/23/the-gtk-file-chooser-dialog-take-ii/ (The first is mostly for context. SuSE shipped with a bad bug.) What you are showing there are applications using the file-chooser incorrectly. In particular they don't set the window size large enough (or they forget to remember the user-chosen size). OK, that could probably be improved in the size requisition of the file-chooser dialog. But I wouldn't say it's a fundamental problem and it doesn't make the current file-chooser dialog stink. Of course there is always room for more improvements. But even though the file-chooser did really stink in the beginning, it has over the last years evolved into a dialog that I enjoy to use. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
What you are showing there are applications using the file-chooser incorrectly. In particular they don't set the window size large enough (or they forget to remember the user-chosen size). Add a preview: no space left for files. Add a filter: no space left for files. Add file format selector: no space left for files. Solution? Blame the applications. Fixing the size-request method is only the beginning. Right now anything you add canibalizes internal space instead of requesting more. Fixing that is a start, but then you would quickly end up with a dialog bigger than the screen. Places is wasting acres of real estate right now and it cannot even be squeezed: side divider can extend it, but not shrink it. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
Hi, On Sun, 2009-05-17 at 11:52 -0400, Morten Welinder wrote: What you are showing there are applications using the file-chooser incorrectly. In particular they don't set the window size large enough (or they forget to remember the user-chosen size). Add a preview: no space left for files. Add a filter: no space left for files. Add file format selector: no space left for files. Solution? Blame the applications. Fixing the size-request method is only the beginning. Right now anything you add canibalizes internal space instead of requesting more. Fixing that is a start, but then you would quickly end up with a dialog bigger than the screen. GIMP uses a GTK+ file-chooser with preview and format selector and an extra widget. I admit it is not a small dialog, but it still fits on the screen we design the application for. For netbooks or similar hardware with smaller screens, it would certainly make sense to squeeze out some pixels. This could be done using style properties (and perhaps can already be done). Places is wasting acres of real estate right now and it cannot even be squeezed: side divider can extend it, but not shrink it. For my typical use of the file-chooser, Places is very important. I use it all the time. But surely there are a few pixels there that could be saved. Not sure if it would be a good idea to allow the user to collapse it. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
On Sun, 17 May 2009 19:32:44 +0200, Sven Neumann wrote: For my typical use of the file-chooser, Places is very important. I use it all the time. But surely there are a few pixels there that could be saved. Not sure if it would be a good idea to allow the user to collapse it. Places is pretty useless for me on Windows, because it lists all it's predefined items (which include all drives) before listing items I added myself. -- Jernej Simončič http://eternallybored.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
On Sat, 16 May 2009, Morten Welinder wrote: IMO this is now pretty much of a non-issue, since the current GTK file selection dialog is sufficiently like Windows (but nicer!). I'm not sure what planet you're living on. The current gtk+ file chooser absolutely stinks! It fails miserably in its primary task: showing the user what files are there in order to let the user pick one. In particular is it very, very bad at managing its screen real estate. See http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/ http://blogs.gnome.org/mortenw/2009/02/23/the-gtk-file-chooser-dialog-take-ii/ Planet sane. I use a couple of Linux boxes, one running hand-rolled Linux and one running Ubuntu. I've never seen anything remotely resembling the broken GTK file dialogs you show from SuSE. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
IMO this is now pretty much of a non-issue, since the current GTK file selection dialog is sufficiently like Windows (but nicer!). I'm not sure what planet you're living on. The current gtk+ file chooser absolutely stinks! It fails miserably in its primary task: showing the user what files are there in order to let the user pick one. In particular is it very, very bad at managing its screen real estate. See http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/ http://blogs.gnome.org/mortenw/2009/02/23/the-gtk-file-chooser-dialog-take-ii/ (The first is mostly for context. SuSE shipped with a bad bug.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
