The first stop in GTK+’s roadmap to GTK 2.4 is the unstable release of GTK+, Glib 2.3.0 and Pango 1.3.0. It includes a work-in-progress of the new File Selector (screenshot).
GTK+ 2.3.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Yeah , having a new natural file selector is an evolutionary step.
What do say about other things to be done , things that are always left:
1) drag and drop – with no crazy bugs
2) a icon view with mouse-able multiple selection using a selection square ( like on the gnome desktop ) ?
3) clipboard ( c&c&p ) that works?
They work like hell in curent implementation , and some (2) , dont even exist in applications.
What is that strange layout in nautilus , why isnt there a tree view that has (2) that i mentioned?
Are they so hard to implement ?
Best regards to linux world!!!
Signet by a designer that cant find place in linux desktop ( i am inloved with sodipodi altough ) !
I have every confidence in the GTK+ team, i think the next stable release will be the big one, i’m sure all those things you mentioned will be sorted out, and GTK+ will become more speedy to boot.
GTK+ is a fantastic achievement, and it will only get better.
What do say about other things to be done , things that are always left:
1) drag and drop – with no crazy bugs
Xdnd is the drag-and-drop specification shared between GTK+ and Qt.
http://www.newplanetsoftware.com/xdnd/
Drag and drop warts http://freedesktop.org/Main/Draganddropwarts
A review of the current state of drag-and-drop support. Examples of interoperability problems are presented and discussed.
2) a icon view with mouse-able multiple selection using a selection square ( like on the gnome desktop ) ?
???
3) clipboard ( c&c&p ) that works?
X clipboard explanation is not a formal specification, but explains our consensus on how the X clipboard works. Qt and GTK+ both follow this document.
http://freedesktop.org/Standards/clipboards-spec
(Note: GTK is not the problem. There is a problem in glib, there is a problem with old programs like {x,E,a}term, there is a problem with some particular apps like Emacs
I quite like Havoc’s explanation why it currently suck :
http://www.redhat.com/archives/xdg-list/2003-August/msg00099.html )
Your critics are a bit old. I post information about that for a good time now. Mabybie your real question is : how well do freedesktop.org do the job ?
As an observer, I’m quite optimistic. I see major developers from every project active in this : Havoc,Owen from Redhat, Gnome and Gtk ; Keith Packard from Xfree ; David Faure from Trolltech and KDE ; Thomas Leonard
from ROX-desktop ; a usuability expert from Sun ; many others
I fand most specifications pretty good, and what I read on the mailing-lists usually makes me feel good.
We have great applications. I encourage all free software developpers to take a look at the specifications so that we can have a great desktop.
I wonder why the ROX DE isn’t included with major Linux distributions
http://rox.sourceforge.net/phpwiki/index.php/Screenshots
Some of them include XFCE which is also based on GTK+
The GTK website says that GTK 2.4.0 is to be released on November 1.
I do not think that GTK 2.3.x will become stable by then.
Does anyone know what is the new timeline for GTK 2.4.0 release?
Around the same time as Gnome 2.6 (March 2004). They are trying to release the new file selector for Gnome 2.6.
There’s a screenshot here:
http://forums.gentoo.org/viewtopic.php?t=99585
I really don’t know much about this, but is it possible that there will be speed-ups with gtk 2.4? Or is this dependent soleley on the apps that use it?
Is it possible for gnome to react/open faster just by changing the toolkit?
The new file selector is probably pretty useful, although it’s design is really very ugly, although it will probably be changed before 2.4. Also, who uses the word ‘Frobnicate’??
I am also interested what ‘Frobnicate’ means.
>Also, who uses the word ‘Frobnicate’??
Hahaha…
Nice catch, cause this is what I told Owen and Federico from GTK a few days ago and they insisted that this is a valid word. I had never heard of it, and some of my dictionaries didn’t have it in. For panels like the fileselector that is used by many different people all the time, wording should be more common.
BTW, frobnicate is a kind of “tweaking”. And still, I don’t understand what “tweak the file” really does to my file…
Regular GTK+ 2 apps do not use the new file selector; it has a new API. Therefore, the app you see in the screenshot is probably a test program written to show the new selector. A lot of times, it’s useful for an app to add options to the file selector; for example, a program might include an option to compress a file in the “save” dialog. So, the “Frobnicate this file” box is just there to show the possibility of apps adding options to the selector. At least, that’s my guess.
just finished compiling @ 2:20 AM, screenshots of filechooser and combo at http://kidcrash.no-ip.com
frobnicate /frob’ni-kayt/ vt. Poss. derived from frobnitz, and
usually abbreviated to frob, but `frobnicate’ is recognized as the
official full form. To manipulate or adjust, to tweak. One frequently
frobs bits or other 2-state devices. Thus: “Please frob the light
switch” (that is, flip it), but also “Stop frobbing that clasp; you’ll
break it”. One also sees the construction `to frob a frob’. See tweak
and twiddle.
Usage: frob, twiddle, and tweak sometimes connote points along a
continuum. `Frob’ connotes aimless manipulation; `twiddle’ connotes
gross manipulation, often a coarse search for a proper setting; `tweak’
connotes fine-tuning. If someone is turning a knob on an oscilloscope,
then if he’s carefully adjusting it, he is probably tweaking it; if he
is just turning it but looking at the screen, he is probably twiddling
it; but if he’s just doing it because turning a knob is fun, he’s
frobbing it. The variant `frobnosticate’ has been recently reported.
It doesn’t seem like GTK is following the GNOME HIG (e.g. no header capitalization for window title, command button or column heading). And what means “frobnicate”? Can’t they use words that are in my dictionary?
chill out guys, this is the first release of a DEVELOPMENT version, things are bound to be ugly, buggy or just plain broken.. These screenshots should be taken with a grain of salt and are just meant to show you where things are at NOW, not what It’s going to look like when its done.
-sp
They are constantly improving. I just updated my RH box to the latest Pango,GTK and Glib. Saw some improvments.
But mostly it’s the applications that needs speed improvements.
Oh, changing Gnome to another toolkit would probably not gain much, and it would take litterally _years_ to do.
Why the hell will GTK follow the GNOME HIG? GTK is now depending on GNOME… GNOME is depending on GTK
Can I drag a file I see in a folder to the window to open the file? I guess not. Why not? Why must I browse to that same folder when I already has it open?
I wish they could fix that…
/Vaste
One of the things I really liked about KDE is its ability to change the colour themes on the desktops. I look forward to the new GKT tool kits.
Because the GNOME and GTK+ teams work closely together to design the best desktop enviroment available
Will the new GTK+ obey to the language setting you enter via GDM? If I choose “Dutch” in GDM, all Gnome apps appear in Dutch, but not the gtk+ parts, like the Cancel-OK-Apply-Forward-Backward-buttons or the file selectors.
And will the new file selector have that nice GUI effect for selection that Nautilus uses? Or even better, will it be able to embed a Nautilus view? And will it be able to use the Gnome VFS? Just like the KDE dialogs support KIO and such? If that would be possible, that would be great, otherwise I see no reason for a jazzed up dialog with just the controls moved around.
Frobnicate
Lighten up, it’s supposed to be funny.
Can I drag a file I see in a folder to the window to open the file? I guess not. Why not? Why must I browse to that same folder when I already has it open?
Do you mean dragging a file from a Nautilus window (a folder) to an application window to open this file in this application, or do you mean dragging a file from a Nautilus window to the file selector to select this file? Both is already possible with current Gtk/GNOME. If you mean dragging from the file chooser, I have no idea (is that useful?).
And will it be able to use the Gnome VFS?
Yes, that’s planned. The issue is, that Gtk shouldn’t depend on GnomeVFS, so it has to be some kind of module. Also it might be useful for Gtk only apps to support GnomeVFS if it’s available. If it works out well, this will be pretty cool because you always have the same file chooser possibilities in all your Gtk apps, whether you are running GNOME or not.
otherwise I see no reason for a jazzed up dialog with just the controls moved around.
Hey, it already has custom shortcut locations.
That’s the main functionality (besides GnomeVFS) which I’m missing from the current file chooser.
Still missing seems to be: Nautilus icons for the files (not sure if that will be trivial) and buttons for “Go UP” and “Reload”.
Also the save dialog should be different IMO (and needs a way to create a new folder).
Apart from a lacking “Create new directory” button and graphics (i.e icons), it looks very promising.
It’s moving in the right direction at least.
I’m interested in that too. GTK+ is extremely slow compared to Qt on my machine. Some examples:
1) Gedit’s text-area will lag behind the window frame very significantly, leaving an ugly grey area between the white text view and the frame. This happens even with small amounts of text in the view. You can fill Kate (which has lots more features than Gedit) with half a meg of text and resizing will be butter-smooth.
2) There is often a big lag between the time a widget (a menubar or toolbar) is exposed and the time it is redrawn. This is very noticible when you’re opening menus or moving windows over other windows. There are very few Qt/KDE apps that exhibit this.
3) GTK+ List Views are extremely slow. On my machine, a list view with 100 elements causes resizing to lag very noticibly, while in JuK the huge list containing my 1500 MP3s will not lag at all.
4) Even the simplest GTK+ windows cannot be resized without the contents lagging behind the frame. I have yet to see a Qt app that exhibets that effect, and only the most complex KDE apps (Konqueror) exhibet that effect.
GTK+ 1.x was never this slow, although I’ve heard that 2.x is much slower than its predecessor. In Fedora, the situation is better (don’t know if they’re doing something special with their build) but overall GTK apps still have a sedate feeling like OS X,. Its really irritating because otherwise, GNOME 2.x is a very polished and good-looking desktop. I was thinking of trying it out until KDE 3.2 came out (recent CVS builds have been rather unstable for me) but the speed is really a deal-breaker.
That’s what makes me laugh with Linux, this so called “new” file selector, doesn’t present a big change compared to the previous GTK’s file selector, always so ugly and inconsistant. Hey guys we are in 2003, and with Linux we are still trying to improve something which must have been improved and cleaned up since ages ago at least. With that FS I still don’t see where I am currently located in the file system tree and still seems ugly to me … Sorry to say that but Linux is still far to embrace the masses and will remain a geek stuff !!!
I agree with you, but I noticed that that QT/KDE is a little bit less accurate, at least with me. Fonts don’t look as good and some lists are rendering strangely (especially the file selector… some filenames and icons weren’t lined up correctly when I was using KDE 3.1). Some dialogs just don’t look good unless you maximise them either (i.e. some buttons/boxes are hidden because they’re too big and there are no scroll bar). Well, that’s my experience, maybe KDE 3.2 will be different, but I’ve now switched to GNOME 2.4 for the moment. Slower, but more consistant/uniform IMO.
Hello, it’s a development version. It’s also only a problem with GTK as KDE have a good file selector (except for the glitches I encountered, maybe it’s a problem with the compilation flags I used). Sure, they could just copy the one from Windows, but that’s not their goal.
The fileselector looks old and dated compared to what you find in KDE or even old win2k. Still it’s a great improvement over the current GTK file selector.
people, did any of you attend school? if yes, then what is the problem with understanding simple wording.
“Development Version” usually means something to the effect of “this is what we’re working on and we aint done quite yet with it”
The fileselector has caused some discussion on the usability list, which is fine, thats why we have the list. This incarnation is indeed an Improvement.
@Ryan, you wouldnt be ryan dawson by any chance?
@Rayiner, yeah the timings are off by far I hope owen will deal with it.
@wrawrat, afaik kde3.x doesnt enable aa on fonts smaller than 12pt (?)
@vaste, you’re not making sense, rince and repeat.
So it is a development version. Fine. But when you show it, wouldn’t you rather show something that has at least advantages over the old dialog?
I thought the left bar was some uncomprehensible folder view, and that on the right side, some random normal files had been made bold…
afaik kde3.x doesnt enable aa on fonts smaller than 12pt (?) Afayk maybe; you can just open the “Fonts” settings and adjust this, on KDE 3.0 and above.
GTK+/GNOME Usabiblity teams DO NOT WANT a fileselector like those in KDE and Windows a file selector is a dialog to SELECT files not to manage your files.
They are aiming at the MacOS X Panther file selector which is a lot simpler.
Besides the UI is still not complete.
This is just a D E V E L O P M E N T version the real goal of this version is to test the new framework, that is APIs, so that the file selector is flexible and easy enough to be useful for application programmers.
That is not the final selector. More likely a temporary one to test the new GtkFileChooser API. The file selector does not matter, because after they are done with the API, they can have a new selector with every release if they want to. Heck, they can even let the user make a choice as to which file selector they want to use, not that they will do that of course.
Nah, it has nothing to do with smaller fonts. I just think it doesn’t render AA fonts as good as Pango. Anyway, KDE 3.1 does enable AA on fonts smaller than 12pt although you may disable that in the Control Center.
actually both use freetype.