Post a Comment
I wish they'd just start work on version 3!
Why? The only reason for a version 3 is because you're breaking compatibility with 2. And that's something you do because 2 is holding you back.
Is there anything that's preventing new features from being added to 2, that makes you want them to break compatibility?
Project Ridley can actually be done right now, without needing to break binary compatibility. All Ridley is, is a merging of a number of different projects under one roof; those who need compatibility, simply keep the seperate libraries going, whilst those who embrace the new features will simply have to say, "requires GTK 2.10 or later"
It's really sick, that people complain about GTK+ keeping it's major version number that long, instead of recognizing that it obviously is some achievment to extend GTK+ but keep it source and binary compatible for more that 42 months now. This "two" in front of GTK's version number expresses nothing but compatiblitly. From a developers point of view quite alot as been improved since 2.0.
Well, but fortunatly[?] the GTK+ crew realized, that stability and maturity makes bad marketing: Not enough fancy improvements to announce. So they decided to announce GTK+ 3.0 as soon as Project Ridley is finished. Oddly enough this release number will be a marketing gag only.
some people do a great job in keeping GTK+
Definitely. For one, the filechooserbutton has saved me quite a bit of time. No mucking about with making a filechooser dialog, a button, and a text widget; I just throw that in and boom; an hour of work and a mess of code eliminated! Of course, I could care less about the hour, it was the mess to clean up later I didn't want!
This looks nice
http://people.redhat.com/alexl/files/offscreen3.html
Yep, and I imagine where it could be used first. Not rotating, but cairo scaling.
People were always bugging Gimp people that toolbox widgets are too large. If I understand correctly, zoom should be appliable just as rotation, which means toolbox could automaticaly just scale down everything inside but without any problem with its current theme (mini gtk was now handled as separate part of .gtkrc and very very buggy).
Can you please fix the filechooserbutton too? Everytime I add it to a window, the window takes <forever> to load up and I hear tons of disk churning... Of course, the second time I load it it's massively better.
But the faster filechooser loads will be a VERY welcome change; especially since I massively preferred the old file chooser anyway!
Speaking of, screw bookmarks: Give us keyboard usability. I want to be able to type my way through a file selector.
The proposition that Gnome is dying is idiotic, especially in a GTK thread since Gnome != GTK. So lets rephrase that as the question, is GTK dying? The obvious answer is no. You have a thriving community around it that is about as large as the QT based FOSS community. That’s not dying to me. Then you have SWT, more apps are being developed with it, who knows maybe java programs based on SWT will become significant on the Linux desktop, if they do they will integrate nicely with Gnome. Again, that’s not dying. Then there is wxWidgets and there are lots of apps, FOSS apps, based on it. I’ve found a statistic on freshmeat per toolkit and the wx based apps far outnumbered those written for QT/KDE and GTK/Gnome and of course the Linux version sits on top of GTK and integrates nicely into Gnome. I wouldn’t call this dying, I would call this thriving, and before anybody starts with KDE is dying, let me ask you, how can you consider a large, self-sufficient and growing community as dying?
-1
Interesting, and on what basis was that made? the fact that a person makes a remotely positive comment about GTK.
Please, OSNews staff, when a person puts a point or takes one, their name should be registered against the comment to show to all the community who added/subtracted points - maybe then people would think twice before acting like a dickhead.
You can use the keyboard to navigate within the file selector. Just start typing! Typing activates a search completion widget that aids you in navigating through files and folders. It also supports tab completion! I think the file selector is well designed and it will only get better.
Here you go: the latest GTK+ for Windows that I know of. It's a shame that the 2.8.x series isn't available on this platform though... :-(
http://prdownloads.sourceforge.net/gaim/gtk-runtime-2.6.10-rev-a.ex...
I _greatly_ appreciate the offscreen stuff, because it happens to perfectly suit the needs of a project I will have to tackle. The specific application (with a MacApp legacy) relies on printing partially reformatted dialog contents for documentation of its use, and this looked _hard_ and like a big roadblock until now. With the new features it should be either direct-to-print via cairo (haven't looked at the source yet) or at least pixmap-to-print. So YAY! for me and my specific needs.
However, I doubt this is very interesting to most. And as Nautilus maintainer, IMO, Alex should've focused on bringing that up to standards first. It's still so _abysmally_ slow with even a low 4-figure number of files per folder that it's not funny. 2.12.0 still takes in the order of 10 seconds on a 2GHz AMD machine. Worse, when this combines with the new spring-loaded-foldout on a d-n-d copy, it forces desperation upon the user because s/he not just can't continue, but has to hold down the mouse button to avoid dropping the files somewhere in nirvana.
I use Gnome for 95% of my daily work, but in this case it's actually faster to load the whole Qt-lib-chain, navigate to the given folder, and _still_ have Konqueror not just run circles around it, but de-class Nautilus into the realm of the ridiculous. Right down there with the 10.0.0-Finder.
Printing is also absent, so there's a lot to do.
Now, folks, the question arises "It's FLOSS, so why don't you scratch your itch and code it yourself?". I actually might have considered delving a bit into Nautilus and read a bit of the mailing list. It seems to be that Alex is rather quick at patch rejections with either a "this won't work" or a "this is not how i like it" attitude rather than a somewhat more constructive approach - so at least some efforts will be lost in friction. The first reason likely comes from bad maintainability of the code base, but then I'd say it's his task to bring it into shape for larger participation. Maintaining such a core component IMO brings a bit more responsibility than happily hacking along as a part time job besides making GTK offscreen-happy.
Indeed. Good to see them move GTK6 forward. :-)
http://sourceforge.net/project/showfiles.php?group_id=121075&packag...




