Slashdot Mirror
The State Of The GTK+ File Selector
Anonymous BillyGoat writes "The next stable release of GTK+ (from the 2.4x series) will have a new file selector, and of recent, a lot of activity has been going on around that. One of the GNOME artmasters, Tigert, has released a mockup of the new file selector and the GTK developers are busy working towards that. Meanwhile the people from OSNews have some other ideas, while an OSNews reader has made even better mockups."
here
(first post)
I still don't see how this is going to help my shell prompt.
> But a buddy was showing me some of his favorite GTK themes on his Gnome desktop, and I have to admit that I was impressed. Unfortunately, when I checked to see how many packages I'd have to install for Gnome, there were over 30 -- Mozilla was one of the dependencies!
> So, can any
The eyecandy comes from different places. Applications that use the GTK+ widgets will render with your choice of GTK+ theme, regardles of what window manager you use. The window manager eyecandy will only effect the "decorations" around the windows, though some of them will allow nice customizations for that. The panel and panel applets are provided by GNOME itself.
I use GNOME, but mostly for the panel these days; most of my favorite applications have been cast aside by current GNOME management. However, by using GARNOME I can comment out the builds for crap that I don't want, and almost trivially add back in a cast-aside GTK+ application that I do want.
I use the Sawfish window manager (another cast-aside), customized to look like the old ShinyFusion theme I used to use under Enlightenment, with many virtual desktops to organize my work (I typically stay logged in for six months at a time), and with lots of nifty buttons in the "decorations" to allow things like maximize-vertically, maximize-horizontally, maximize-both, etc.
BTW, you can window shop for eyecandy at themes.org. It is organized according to what component supports a theme (window manager, toolkit, etc.).
Sheesh, evil *and* a jerk. -- Jade
The last /. article about the new file selector was filled with "this is totally stupid", "this is worse than the old file selector", "this is the last chance they have to fix it, and they've royally screwed it up", "usability experts, bah! This is why gnome will never catch up with kde" etc.
Now listen. The change that's happenning in the new file selector is primarily that they're creating a new API. Got it? The programming API. That's why the screenshots looked the same. The screenshots tell you nothing. As long as the API doesn't suck the front end can be freely changed without breaking anything, and everyone can do their own mockups and various ideas can be tried and the experts can weigh in with their opinions and so on. This can go on for a long time, and the front end will stabilize when it has reached (near) perfection.
So a next-generation save/open box should include comprehensive network protocol support.
With all due respect, I think that this is a really, really awful idea. Unfortunately, Microsoft has traditionally taken this approach (for political, not engineering reasons). The KDE project, which takes a very Windows-like approach to a number of architecture decisions, copied their approach, and GNOME has come uncomfortably close.
The reason why I'm not a fan of implementing network transparency at the KIOSlave or GNOME-VFS or whatnot layers is that this sort of functionality is *not* KDE or GNOME or whathaveyou specific. It just isn't part of the desktop environment. It should be implemented at a lower level, so that *all* programs running on the machine can take advantage of the functionality. There are a couple of projects that do this -- take a look at LUFS for a proper (IMHO, of course) implementation of what you're asking for.
May we never see th
Why can't they put in ONE text field with the entire pathname, so it can be cut & pasted, and it can be easily examined and compared to another file in an email or other source, and it is obvious how to type in a pathname?
This can't be that hard, really. I did it ten years ago in a NeXT file chooser I wrote.
Have a SINGLE text field. Anything before the last '/' is the "current directory" and anything after is the "current file". Then add all the buttons and tab completion and scrolling list. As the user edits the text, update the display to match. As the user hits the buttons, re-edit the text.
I consider this obvious and I am dumbfounded that nobody seems to be doing this even today.
I don't care if Grandma is confused by pathnames. Grandma is also confused by insertion-editing of text fields but nobody seems to be trying to make it overwrite.
Show a little incentive, and do this right!
Consider:
I use gnome instead of kde (on gentoo) but the lack of any UI sense is frustrating. Another example: the gnome-panel buttons grow to be unbelievably large if there are only a few windows open. This just looks terrible and combined with the layout problems make it nearly impossible to have a vertical or expanding bar that doesn't just look disgusting.
I really think linux is set to take off on the desktop this year, but these usability/aesthetic details can really have a large negative impact.
You know, I have no problem with 'innovation' being touted as an absolute virtue. Yes, innovation is good, and it's always nice to develop new, more efficient ways of doing things, but... what if something already works fine? Why not copy from someone else if their idea is great? I sorely wish the GTK+ file selector has shortcuts, and I was ecstatic when I installed KDE 3.0 a year ago and found out they had added them in.
Innovation isn't the important thing. Usefulness is. Innovation is only one of the many tools used to create something useful.
Standing at the very edge of my imagination, I peered into the inky void and realised -- I couldn't think up a new sig.
It's pretty funny that the 'even better' mockups have a 'New Folder' button on a 'Open File' dialog box.
Surely the intention of this button is to make absolutely 100% sure that the user can select a file that doesn't exist. I mean, what other file could a user possibly want to open?
There is simply no better file to open then the one that remains in a directory that doesn't exist yet.
The love-sending widget will not be present in the final release of the new file selector, and is included in mockups to demonstrate how developers can add in special-purpose widgets into the window. For example, The GIMP may insert a quality slider in that place for saving JPEG images.
Early mockups used the phrase " Frobnicate the file ," which was changed to " Lart whoever asks about this button " after countless questions as to the use of frobnicating files.
These screenshots are linked from Federico Mena-Quintero's Activity Log, which is really rather fun to read. You may also be interested in Planet Gnome, which aggregates the weblogs of many interesting Gnome and Open Source personalities.
It would make more sense IMHO to abolish file selectors altogether and instead throw users into their preferred file manager for opening files. All it would need is a freedesktop.org standard protocol for file manager/application interaction and perhaps a $FILEMANAGER environment variable. (Theoretically, $FILEMANAGER could then also be a shell in a terminal.)
-F
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70