Re: tree model
I would hope iterators and models will be part of glib 3.0 to avoid 3rd party duplication as well as all other Libgee functionality this would also make it more vala friendly jamie On Mon, 2009-05-11 at 19:16 +0200, Szilárd Pfeiffer wrote: What do you want to do with that? What about GNode? Isn't it good for you? regards, Szilárd Ryan Lortie wrote: are there any 3ish plans for GtkTreeModel - GTreeModel? cheers ___ 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 ___ 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 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: Native file chooser dialog on Windows
Hi, On Fri, 2009-05-15 at 22:28 +0200, Jernej Simončič wrote: For the values of nicer that match much slower, worse autocomplete behaviour than the native dialog, less useful Places list and confusing gradual display of network locations (the first time I tried opening something from my fileserver I thought some of my directories went missing because the GTK+ dialog displayed about a tenth of all folders at first, and then very slowly added the rest in about 15-second intervals; That sounds like a severe performance problem of GIO on the Win32 platform. Have you reported this as a bug? Can you assist in getting this fixed? 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: Native file chooser dialog on Windows
and confusing gradual display of network locations (the first time I tried opening something from my fileserver I thought some of my directories went missing I think this could actually be improved fairly easily for all platforms if something (the chooser or backend, not sure) was more careful of the order it stats stuff. From the name of entries, it should be possible to come up with a fairly good guess of what to stat first. We want directories before files and things alphabetically within those groups, except that dot files should be last if they're not going to be displayed. That makes it a problem of guessing what is likely to be a directory. I'd try looking for an extension which would typically indicate something that isn't a directory. 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: 3.0-related deprecations
Cody Russell schrieb: Hi all, gtk+ currently does not build with GSEAL enabled, and I want to remedy this so we can make progress on 3.0. I'm planning to post a large series of patches unless someone has a suggestion for how better to do proceed with this. Right now I was thinking to break this up by widget in order to make it somewhat manageable in terms of review. Does this seem like a good idea, or should I just do all the work in one enormous branch and post for review? I've posted the first patch[1] and it's about 105k, although it shouldn't really be a big burden to review.. it adds 5 new API functions for public struct members that didn't previously have API, otherwise there's not much of interest in it. I used the code rewriter to generate parts of it, but had to insert all the GtkPrivate *priv = GTK_WINDOW_GET_PRIVATE (window) type stuff somewhat manually. it not doing this for every call? just want to check that you set up the priv pointer as a private field in the object struct and dereference from there. stefan Last thing is what to do with this stuff. Assuming someone is able and willing to review it, should it go in git HEAD or should we make another branch for it? My preference is to just put it in git HEAD probably. Thanks, Cody [1]. http://bugzilla.gnome.org/show_bug.cgi?id=582018 ___ 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
Re: Native file chooser dialog on Windows
On Sun, 17 May 2009 12:04:47 -0400, Morten Welinder wrote: From the name of entries, it should be possible to come up with a fairly good guess of what to stat first. We want directories before files and things alphabetically within those groups, except that dot files should be last if they're not going to be displayed. That makes it a problem of guessing what is likely to be a directory. I'd try looking for an extension which would typically indicate something that isn't a directory. Just for comparision: there's 231 directories (and 4 files, but they aren't pictures - I was testing with GIMP) in the directory on network drive I tried opening, and the Windows native chooser took 3 seconds to display the entire list. GTK+'s chooser displayed about a tenth of the list after about 10 seconds, and then further tenth every 10 seconds. I also couldn't get autocomplete to work at all in the GTK+ file chooser there, while it was available immediately in the Windows filechooser (I wonder how hard would it be to actually use the Windows' built-in autocomplete in GTK+ - to use it with Windows native controls, you just need to call SHAutoComplete and pass the handle of the control). -- 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 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
GLib and Symbian?
Hi, A few months back someone reported on this list hat he had ported GLib to Symbian. Has this port been merged, or is there somewhere I can get the branch of the Symbian version? Kind regards, Wim -- Wim Vander Schelden http://fixnum.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Symbian?
On Mon, 2009-05-18 at 01:07 +0200, Wim Vander Schelden wrote: A few months back someone reported on this list hat he had ported GLib to Symbian. Has this port been merged, or is there somewhere I can get the branch of the Symbian version? It has not been merged in. The problem was that static globals are not allowed in Symbian, and are used in quite a number of places. Tor posted a possible solution for that [1], but it would require a lot of changes to be made. If Tim or Matthias can comment and mention whether this solution would be acceptable, I'd be willing to try to adapt the gtk rewriter to try to automatically convert the global statics to use Tor's macro. [1]. http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00029.html ___ 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
