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)
this is what passes for "stuff that matters" these days?
what's next, a front page article every time Linus passes gas?
Why is it everyone gets the hang-ups over a freakin' FILE SELECTOR? GNOME critics will always say "GNOME is the worst DE in the universe! It sucks! Why? Because... it has...uh... a lousy...FILESELECTOR! Yeah, thay's it".
Now that the fileselector is improved, what will you bitch about now?
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Only not quite as functional. The pathname entry is good, but it looks like it doesn't have the quick drill down. If you're going to copy, why not copy the good parts?
... and I don't want to be rude.
Neither of them are particularly inspiring though, I thought the community was hoping to steal the hearts and minds of the consumer in 2004.
This is not meant as a troll, although I know it will be read as such by some.
Maybe I should read into this more, but who is Eugenia, and what does sending him/her love have to do with saving my files?
--Nuintari
slashdot : where an opinion can be wrong.
Will the shortcuts on the left side (home, etc) be configurable? That would be one way to beat the crap out of Windows once again. On my one Windows box, I never put anything in My Documents, I keep it all elsewhere, ona FAT32 partition for dual-booting use. I'd LOVE configurable shortcuts.
You are not the customer.
I love osnews little version, with all the directories in the path displayed at the top, the idea being you could click on them to go back to that directory.
/, root)
Example:
user clicks root, stuff, music
(root, stuff, music, / appears at the top)
user decides he needs to go back to root, clicks root
(top now says:
It could really work, and be really useful.
Keep at it gnome boys!
Microsoft IIS is to webserving as KFC is to healthy eating
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 /.ers recommend a... svelt window manager that supports some of this wonderful eye candy?
I hope they get it right, already. I bet it's gonna be some bloated kitchen sink that resembles Nautilus in complexity, complete with all kinds of previews and bells and whistles, and that it still won't be able to remember the last used directory.
It also looks like they are trying to catch up with KDE's file selector. No matter what people say, that's not my ideal one. I'm much more fond of the one Mozilla [Firebird] has -- that one is the embodiment of the KISS principle to such extent I'd venture to call it perfect. That's if you agree on the definition of perfect as being "not nothing to add, but nothing left to take away".
Have sluggish response and visible redraws when you do something simple like scrolling a window, like the old ones did?
Because personally, my complaint with GNOME and such isn't the quality of the UI. It's the performance so horrific it makes Mac OS X Public Beta look like a usable operating system.
One thing I really like about the current file selector is that I can start typing a name and press tab, and it will show only entries starting with what I typed. It even supports wildcards. Does anyone know if that will still be there? As long as I have that, I really don't care what it looks like - I'll still be able to find stuff efficiently.
It looks like sending love to Eugenia is on by default in the file selector. I always hated having to goto a bash shell after opening a file and doing an "echo love > /home/eugenia/warm_fuzzies".
Outdoor digital photography, mostly in New Engl
The GTK development team thought that bringing in a female would help the aesthetics of their GUI. Boy, were those dumbfucks WRONG!
ror
I still don't see how this is going to help my shell prompt.
A good improvement would be the ability to navigate the goddamn thing with the keyboard
I think this is a little improvement, but if they had an option to change the panel of the "favorites" I would see it as a bigger step toward an integrated desktop.
You can find more information about the GTK+ file selector here, here, and here. Hope that helps. :)
But I would suspect that most ppl will see in it what they want, or not want, to see.
I prefer the "u" in honour as it seems to be missing these days.
It's a shame all of them just look like bad ripoff's of what windows has had for a while. And the one designed by Eugenia at osnews is just retarded. File selectors should be longer horizontally since file names can be long. Having something that is taller than it is long is just dumb, there just isn't a polite way to say it.
Why not an address bar that you can type into for faster directory navigation? I think they should just steal the design of the kde file selector.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
Shortcuts? Just put it all in one directory called 00stuff
Is this some kind of special File Selector? Why is such a big deal being made about it?
-- You see, there would be these conclusions that you could jump to
I like Tigert's the best. Those mockups look like garbage. Really, what more do we need than a simple file selector that works? I don't want crazy widgets and special features, I just want the goddamn thing to select my files and do it right. Preferably there should be the ability to see many files at once, instead of like 8. At least 16 things should be viewable at any one time.
Happy New Year, it's 1984!
The problem with those mockups is that they seem specificaly tailord to GNOME. Ie it uses icons for HOME, Desktop, Most recent files etc but all of these are classic things that are integrated within gnome and no use to someone that uses blackbox or other light window managers as they're primary window manager.
Why cant we just get rid of the icons and by doing so cut down the size of the selector and simplly have a listbox of pre-defined locations to save files?
Also it would be good if that list could be changed by editing a configuration file, maybe an XML file?
KISS
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
If not in drive, don't click this until you insert a CDROM. But you knew that already. After you insert the CDROM, mount it using the console. Make sure you mount it to the right path or you'll be screwed. Use the CDROM. When finished, unmount it using the console and when hitting the botton on the front of the drive fails, apt-get install eject. Then eject using the console. Then go fuck yourself.
Am I the only person who doesn't really care?
This evening, I did one thing that gives me much joy - writing and submitting invoices.
I write them using a stupid-simply web app thingy I hacked together long ago, which generates PDFs which I then attach via e-mail to the clients.
KDE has an awesome file selector - as I go down the list of PDF files, and choose one, a preview window shows the PDF scaled, right there in the selection window.
That makes it SO EASY to make sure I have the right invoice for the right client!
The preview window in KDE previews most file types: html, jpg, gif, png, pdf, etc. There's a bunch of common links to the left, such as "Desktop", "Documents", "Home", "Floppy" that make finding the destination a snap.
The gnome file selector is pretty lame in comparison. No preview, no hot links, etc. and just a retarded dropdown menu for navigation.
For a toolkit, this is a pretty big deal!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
You don't want to go there. Trust me on this.
More information.
Here is a link to her personal website.
And now a quote from her site:
My favorite places on this planet is my parent's village in Greece, called Skiadas (think bald mountains and lots of goats)
I don't know about you, but this immediately conjured up images of certain Slashdot links. I can most definately say that said link is not my most favorite place on this planet.
-- Fighting mediocrity one bad post at a time.
I think the next 'evolution' for linux desktop would be the merger of browsers for local and network data.
.MAC account? Or can you upload to your web site? What about sending it as an email attachment? Or a fax.....
:)
Yes, this is like windows. But linux could do it so much better.
A truely cohesive network workstation should be able to save or open any document to or from anywhere. Appletalk shares, WebDAV, HTTP POST, FTP, rsync, etc.
So a next-generation save/open box should include comprehensive network protocol support.
Of course, any mounted file system (networked or otherwise) can easily be saved to with all current file selector dialog boxes, but can you save to your
Be was a great OS, wasn't it....
... I don't know what I want.
But damnit they should make it do that too !
Time travel is possible. We are quickly heading for 1984.
So you are saying you prefer the current GTK file selector widget?
You can add previewing to this new GNOME file selector. The 'Send love to Eugenia' part in the screenshot from TigerT is just there so be an example of where/how to extend it. So a PDF viewing applications could extend the fileselector to include a preview window for instance.
I've said it before, and I'll say it again, the KDE v3 file selector is the best one I've ever used simply because the shortcuts on the left hand side are easy to use and customize (just give 'em a context click, and you can change the name, location, icon, etc).
And then you add in cool features like the kio_slave support (so that the location can be a WebDav dir for DnD file publishing, etc), and the fact that the custom locations can be made app specific (wow, my digital camera knows about my image dir, but I won't worry about that cluttering my kwrite dialogs!), and you see why KDE is a great DE to use.
The KDE folks got the file dialog right a while back -- it's time more people noticed their great work.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Probably shoulda been from the it's-a-slow-day-for-news-dept.
Here's some real news.
Dude, if your files are in there... well, select at your own risk...
====
Crudely Drawn Games
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.
This redesign went by the gtk-devel-list AGES ago. The API is due to be frozen in about a week for the pending 2.5 release. Eugenia is WAY behind schedule if she actually wants to influence the design....
This should be +5, Funny... "Constructive." That's good. Sort of like how Slashdot discussions are "insightful," huh?
True story.
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
Looks like they got the "Open" and "Cancel" buttons switched around the wrong way. Simple copy/paste error I'm sure--nobody would really want them that way (except maybe in RTL localizations)
no one cares about "team ups" relating to products that dont exist?
There is a lot of "borrowing" from Microsoft in the open source GUI world. I know some genius who thinks he knows something is going to make a comment about Microsoft "borrowing" from Apple (and, if they want to be fair, about Apple "borrowing" from Xerox).
Those are mockups of what the file dialog box might look like when it's done.
no one cares about "team ups" relating to products that dont exist?
But mock ups of a file open dialog box is news? Come up out of the hole.
I've seen better.
Seriously though. How hard can it be?
Michael.
Linux : Mac
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!
No kidding. And this file selector isn't even being developed and as far as I can tell, the author of that article is not a UI designer with professional experience (she seems to assume her opinions are facts).
True story.
Linus passes gas.
Film at 11.
FP hah hah
Acorn got this aspect of GUI design right. You don't need a file selector. Opening or reading things is best done by clicking or dragging from an existing directory browser. Saving or outputting is easily done by dragging an icon that represents your file into an existing directory browser. Need to open a directory browser to do that? How is that different from needing to open a file selection dialog?
File selectors? How modal. How quaint. Just say no.
-- Andrew
Or you could just use a file manager and then DnD (drag and drop) the file into the program. That would give you a preview if you had it enabled in, say, Nautilus.
True story.
I'm a former Amiga user who has long since moved on to linux. My desktop enviornment these days is made up as a combo of e and gnome. I generally prefer it but I do miss the amiga file requestors. That is the ones that came after AmigaDos 2.x, especially the replacement versions such as reqtools. There seems to be a remake for GTK of reqtools at http://reqtools.sourceforge.net/screenshots.html Not as good as the original :) but who knows after it is cleaned up and made pretty. Also, for powerusers the Directory Opus workbench replacement at least version 5 and higher beats what we currently have on linux. Think you just had to double click on the desktop to have a file manager popup and you could set one file manager window as destination and have the other ones as source and do some things much faster than you could from CLI.
;) this is a bit knitpicking but you do not want to have a button to create a directory when opening a file. That's only when saving. GUI 101 :) stuff.
oh yeah about the screenshots of the new GTK file requestors this article is talking about.
For sure. I am now enlightened on why there's a Eugenia Hate Club out there somewhere....
Are you tired of slashdot's editors? Check out anti-slash!
/.'s already low signal to noise ratio, you can force /.'s editors to come clean about their ethical lapses, and have a great time doing it!
While you're there, check out the database tool here. With the database tool, you can quickly gain karma by reposting highly-moderated slashdot posts, and secure the +1 bonus for future jihad operations.
By decreasing
Thank you for your support,
jihadi_31337
The point of the new GTK+ file selector is not so much how it looks than the fact that it is based around a new, extensible API. The old implementation was so tied to the API that its appearance couldn't really be altered (on a system-wide level), the new file selector can.
It does what I need it to. The shortcut to the Desktop and my home dir is very useful. I dont know why they are trying to re-invent the wheel, and why they are taking so long to do it. Even though they are up to 2.4 I still use Ximian's 2.0 because I don't want to lose their file selector.
Does anyone know of a way I can replace the one in Gnome 2.4 with Ximian's without breaking anything?
A sentence you'll never see on an Internet discussion board: "You know what? You're right."
Is a damn file selector box, where if I enter a DIRECTORY NAME into the box, and then press ENTER, it will SWITCH to that DIRECTORY, rather than giving me an error, or showing me an empty selector box that isn't pointed to anything.
That's what irks me the most. I don't care how PRETTY the damn thing is.
I can't even make out what the hell half the controls on those mockups ARE...
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
http://a352.g.akamai.net/7/352/51/2e9d5a1ab1d2db/w ww.apple.com/macosx/features/finder/images/finderw indow10082003.jpg
One of the things I miss...
People do realize this article is an old dupe, right? Just curious.
"Sufferin' succotash."
I'm posting this as AC to protect the innocent. I've talked to some people that worked on those mockups, and found out that next month they plan to have a file save yes/no dialog box mockup completed as well. Buy the end of this year the whole file menu should be working, so in 2005 they'll be able to tackle the whole Edit cut/copy/paste menu thing so that we'll be able to actually cut and paste reliably between apps in Linux. 2004 is off to a great start!
Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI? I mean, that's like 4 years behind all the other GUI operating systems. What was the holdup?
"Sufferin' succotash."
Seriously, these file dialogs don't have enough alphablending. While they're at it, they should throw in some lens flare too.
I can't believe you rejected my article on MS teaming up with Nitendo on Xbox II.
So Microsoft is *finally* admitting they can't design a decent game console on their own? 'bout time!
Microsoft is to software what Budweiser is to beer.
What it looks like is Windows XP. Actually, 2000 had it as well, and I believe Office 98 introduced it (having the shortcuts on the left like Desktop, My Documents, and so forth). But I guess because it's "M$" nobody will fess to that.
"Sufferin' succotash."
please? it's not just used by windows for no reason
Is it just me or is this design just a copy of the KDE file selector? Which is annoyingly overloaded. I like GTK but it seems like everyones missing KISS these days (Keep It Simple Stupid). Its like the Microsoft file loader with 'My Computer' stuck to the side of it.
Quack, quack.
They should change it to .... 9drum roll0 ....
Find File(s):
anyways, looks nice - compact and efficient. and finally can customize easy access locations/folders (or maybe this is old?)
Wait, what happened to the delete button? This one the one thing that made me respect Windows 9x when it came out! I hated not being able to perform minor file maintenance, in the application that made the files where it was convenient to see them. New feature, or easier to use = improvement. Remove feature = disappointment.
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.
Why is this a troll? I rarely use the File Selector in Windows or OSX for "Open", and nearly always use the file browser instead.
There's an old argument (back to the 80s) that the File Dialog shouldn't even exist at all and it's functionality should be replaced somehow with drag-n-drop and the File Manager.
I would like grokker interface.
Why isn't the file selector a corba service then
the file selector could be devloped independed of gtk ?
Why there isn't directory tree in left panel? I'm supposed to use mouse to navigate this dialog, sa ability to quickly expand directory tree and click on interesting dir is pretty useful.
:wq
No Slashdotter has yet to legally or morally justify pirating an artist's music. But they sure hate the RIAA!
So, um, if no Slashdotter has yet to legally or morally justify pirating an artist's music, that means that all Slashdotters have already legally or morally justified pirating an artist's music...
Here is a screen shot from BBEdit (text editor of the gods) on Mac OS X 10.3, for comparison. The list of mounted volumes (top left) wouldn't really apply on Linux I suppose. Columns to navigate are kinda nice (it's a NeXT thing), but we got along without them just fine in Mac OS 9.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
i don't mean point-and-click and drag-and-drop interfaces suck, i just mean: why the mainstream open source desktop environments try to mock the mainstream commercial desktops? why command line and desktop are kept two separate worlds? why <TAB> serves absolutelly different functions in command line and GUI?
i dream about the day when using desktop applications will be as intuitive for a command line user as for somebody whose right hand seldom leaves the mouse. as for now i often feel trapped when i have to use another GUI application [for example using mozilla at the moment. why can't i maximize this text field? because i can't do that in IE?]
"what's next, a front page article every time Linus passes gas?"
That and the one were CowboyNeal gives his rebuttal.
..Not trolling for KDE fans - just generic oo stuff - it just makes sense yes?
Look at
i ze /92.png
http://www.kde.org/screenshots/images/3.1/fulls
For KDE 3.1.x file selector screenshot. I prefer KDE version much more than the proposed GTK+ variants for the following reasons:
1) Preview that works fast and well. The previews for text, ps, pdf, jpeg, gifs etc. are very fast and very readable (even for texts). Also, almost all filetypes that I have run across are "previable".
2) Back/Forward arrows. I wonder how come they are not there in Gnome mock-ups. They have proven to me to be very very useful.
3) Network integration.
4) Icons/Look very well integrated with the rest of the KDE applications. For example, up/back/forward actions use the same icons as in the konqueror browswer.
In the mockups, there's a arrowed list of each component in your current path. "/" should always be present in the list and not findable only after multiple left arrow pressings.
An On
Its the same as Windows - the reason I don't use Linux is because its always a couple of steps behind!
Call me old-fashioned if you like, and maybe my geekiness is wearing off, but I just can't understand why a GIU file selector box makes font-page headlines. It's only a damned widget. It's hardly a great breakthrough in mathematics, fundamental physics or the search for extrterrestrial life. I can just see the day when ET is discovered, it'll be relegated to the Science section on slashdot while a piece about new GNOME themeability makes the front page. Foo to the lot of you.
Stick Men
Thank you.
Normally, I don't read random, unresponded to comments late in discussion.
However, I read this one when I saw "readline completion", and was very pleased.
First, it phrased exactly my frusteration with many Linux GUI apps -- why can't the basic tab completion functionality that already exists for bash/zsh (slightly more than readline alone, FWIW) be replicated? This is a mature, well-designed interface that has been already done once. Why throw out what has already been achieved in the CLI world?
Second of all, it introduced the first really interesting and inventive browser UI idea I've seen in a while. Why *can't* text fields be maximized? This is a damned good idea -- I'm sure others have struggled with tiny text entry areas that allow one no more than a peephole into their editing environment. I should be able to kick the text entry field into a full-window mode for typing up my email/comment/message, and then be able to drop it back down to regular size.
May we never see th
I design user interfaces for a free network management application,
I just looked at the mockup, and all I can say is GAH! Why in the hell is everyone just trying to clone Windows? Crap!
Frankly, cloning Windows is a big step backwards. Is there really that many programmers out there, ready to write this stuff, yet have no thoughts of their own, as to how to improve on this, rather than just cloning someone else's work?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Mmmmff.
Drag and Drop has certain benefits, but there are reasons that it's never really taken over as the standard interface system.
First issue: DnD is not standardized in tasks performed in response to a given action -- it bears much in common with the right mouse button on x86 boxes before the advent of Windows 95. Suppose I drag a Word-openable document into a Word window containing an open document. Should Word open the dragged-in document? Should it embed an OLE object referencing the document? Should it attempt to import and insert the data directly into the document? When I'm typing an email in Lotus Notes, I can attach a document by using the "Attach" menu. However, if I drag a document into the email window, the document is simply embedded and appears as part of my email.
Second issue: DnD does not have an obvious keyboard equivalent in current desktop environments. While there is no law of HCI stating that every mouse-operable action must always have a keyboard equivalent, it has been informally adopted as a convention by most desktop environment GUI folks to have an equivalent whenever possible. If DnD is used to replace opening and saving, a very common activity, but no keyboard equivalent is given, many keyboard fans are going to be quite unhappy.
Third issue: current widget sets (and perhaps this was not the case on the Acorn) do not provide good default DnD behavior. Generally, I've found that features where application authors must go out of their way to provide support for the feature to work tend not to work consistently. The more work it takes to support something, the less likely it is to be supported. (The most notable exception is the "resize to fit window contents" titlebar button in MacOS -- however, this was a very obvious and blatant thing to make not work correctly.) DnD, if used as a replacement for copy-and-paste or open-and-save, must work *everywhere* to be effective. If it works in 30% of your apps, you're going to simply use the method that works in all of your apps instead. Last I looked, nobody implemented DnD globally and consistently enough for it to be worthwhile.
Fourth issue: By overloading some interface actions, DnD may be detrimental to the user. This is most irritating when working with DnD support for text. Traditional text editing states that clicking and dragging over text starts and begins extending a new selected area of text -- this is regardless of where the user clicks. DnD means that this behavior changes for text within an already selected area of text. To select a subset of an already selected area of text, the user must click once to deselect the area. I found this incredibly annoying in Mac OS System 7.5 -- DnD was not implemented consistently enough to rely upon, and it *did* impose irritating constraints on my text editing behavior.
I agree that making the directory browser and the file browser one and the same has a number of appealing benefits, though...
May we never see th
[snort][chortle]That was a very good Micro$lut joke!!!!!!!!![snort][chortle]They suck!![snort][chortle]My mom's calling me...gotta go
Looks like a kind of windows rip-off again.
Anybody remember Amiga and ReqTools file requesters? They were the fastest you could imagine: in the dialog window there was one listbox that switched between volumes (unixworld equivalents of root dir, desktop, home dir etc.) and dir+file list. Good keyboard control that grabbed all relevant keypresses (like up/down) directly to the listbox, no need to worry about widget focus. Now *that* would be something I'd like to see in GTK+ too.
methinks the 3-panel NeXT thing is cool - it lets you see the files you have on your folder while reminding you the path you have tracked down.. that's pretty close to being able to do "cd .." in GUI... okay, GUI aside,
would a pipe open in a file selector be a good idea? when i need to paste the current system time into vim, i would just do a :r! date, and it'd be cool if you could read stuff like "|tar xvfzO mails.tar.gz rejectmail.txt"... or will the selector somehow step into tgzs? it'd be irritating to be trying to open a file and realize oops i gzipped it letme go back to my good old shell and gunzip it first.
ok maybe i'm getting something wrong - well i never coded with GTK :P
Yes, the one thing I am sick of under Linux is the stupid Windows-copy file selector. Every time I want to save a file I have to pop it up and wend my way tediously from the normally illogical default start point. I would love an Acorn-like drag-and-drop system, much like ROX tries to do. Make it globally selectable in KDE/Gnome what file selector module to use so those that prefer the old way can keep it but those that need the drag and drop can have it in all their apps.
Phillip.
Property for sale in Nice, France
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
The problem is, the current file selector is the worst layout I can think of, and the one in windows is pretty good.
/home/$USER/`cat /var/omgwtf`/)
/, and whether I should escape my parens. Are there even two programs which use regexps the same? It's fucking annoying, developers should clue in)
I hate those "Home" "Trash" "Desktop" buttons, yes, and if there's no way to turn them off, it's a huge mistake. However, The idea of having a seperate place to type file, directory, and filter, that is a good thing.
The Linux version of Opera has a very good (though not perfect) file selector. Oh no! It's a clone of a successful and easy-to-use design! That must make it bad!
-Make it look like the windows file selector. Windows has a GOOD file selector, so you may as well start from there.
-Get rid of the extra windows-only crap (Like a "Desktop" button. That whole area where the "Desktop" button resides should be killed too.
-Allow people to actually type paths into the directory selector- including Tab-completion and bash-style escapes (eg:
-A comprehensive filter which supports both simple patterns (*.mp?g) and regular expressions (with a fucking EXAMPLE of what syntax the regexps follow, god damnit! I hate not knowing if I should begin/end my patterns with
-allow patterns/bash escapes/regex/etc in the file selector AS WELL. Not "In the file selector, but not in the filter", not "in the file selector, so you don't need them in the directory selector", but allow them in every place you can type a path!
-If I type a directory into the file selector, don't close the file dialog when I hit enter. EVER. If it is a directory selector, give two buttons: "Use Current Directory" and "Use Selected Directory"
-Always show the user's home directory in the path drop-down. some MRUDs would be nice too, seperated by an HR
-stop and think to yourselves "Is this the gayest shit ever?" before showing off your ugly designs.
-- 'The' Lord and Master Bitman On High, Master Of All
Why are all these mock-ups so small? When I'm saving a file my full attention is devoted to the file selection dialogue, so it might as well fill up a reasonable part of the screen. MS realised this with Office 2000.
Now I'm aware that all these file selectors are resizable with GTK layouts etc. but the default, and the size for which the GUI is optimised, ought to be a little larger I think.
Badly ripping off the Windows file selector seems to be all those fellas are capable of. Come on, slashdotters, you like to lambast Microsoft for ripping off Apple, go ahead, unleash the dogs on these poor shmucks. It's a "ripoff squared", with a lot of important subtleties left off, as always, because they're boring to implement. Next thing you know, these fellas will be ripping off the file selector from beta versions of Longhorn.
Why do we have to always copy microsoft, every single time we do anything on linux it ends up looking like some horrid antiquated microsoft product that everyone agrees isn't that great itself.
By god the number of paint programs which fail tradgically simply by using the awful microsoft paint package as a template for how there UI should work and what features to include in the software.
Look around at every operating system which has a slightly diferent system, this method of saving files has been around since the early days of dos, something better is bound to be out there.
Though I probably only spot it coming from RISC OS which had in my opinion a fantastic drag and drop saving system. Handilly since saving a file use the same internal mechnism as any data transfer between applications you could save a document straight into another document draging it into place or drag it to a filer window, your desktop, a icon representing a hardisc.
Yes RISC OS suffers from having a UI which hasn't been brought forwards in the past 10 years by any great ammount, but then if you think about it, very little has been brought forwards in windows or linux yet since were still using dialogue boxes which have there origin 20 years back when text was the only medium available.
GTK file requesters are -horrible- period.
Here's a screenshot of what the Amiga did more than 10 years ago: a simple, clean and usable inteface.
Actually it's an AROS screenshot, but the originals, except the irregular windows that weren't supported, would have looked mostly identical. GTK graphics authors should take inspiration from the other screenshots at that site: The Amiga in the early 90s had a very poor (compared with modern systems) graphics engine, yet its user interface was (and still is IMHO) an example of what can be done with limited resources when there is a good design to start from.
Office 97. It's the one that *didn't* share a year with a release of Windows.
Though a quick search seems to indicate that it was Office 2000 that first had this feature, not 97. At any rate, unless Macs had this type of filepicker before OS X and I just didn't notice, MS was still the first to have this type of filepicker.
(And considering that it took Apple until X to finally realize that a 2-pane file browser is a good idea, something which Windows (and probably other OSes) had had for a long time, it seems to me that Apple did some "borrowing" back of ideas for OS X.)
C'mon... That's such a little improvement... how many kids are working on that component? I made a better one with java / swing in a week.
The Gnome project has been a complete and total waste of time. How many times will you fools reinvent the wheel?
The bookmark list should synchronise itself with the bookmarks menu in nautilus. that way things can be a little consistent.
:)
They probably could also use a common bookmark thingummy for folders, that both kde and gnome could share, in the spirit of freedesktop.
For that matter they should use a common bookmark format for konqueror, mozilla, fire bird and the gad zillions of browsers out there
Exactly. To me the most important thing is being able to enter absolute or relevant pathnames in the same box you would type filenames. Any file selector that can't do this drives me crazy...
the minimize button in the title bar. OK, OK, it's a mockup, but still. It just shows how little most GTK programmers care about usability. Most of them forget to make utility windows modal and/or transient, leave minimizability and resizability on, provide no placement or role hints. The result is a clunky, GIMPish, messy interface where you spend all your time digging through windows.
If beta versions of longhorn will have good enough file selectors that it should be copied, then sure, someone will probably do it. Which is good.
Nothing bad in "ripping off" working designs.
And this has been ripped of from mac and kde just as much if not more as it has from windows.
Why did it took them 4 Years to copy a lousy fileselector from Windows ?
GTK has to work in an environment without a file manager, so it needs a baby one built in as a fallback. What people are looking at here is the fallback GTK file selector.
The API supports pluggable file managers, so if Nautilus/whatever is selected as the default file manager, a nautilus window could pop up when you click on "Open file ...".
no i think this is big news. the file selector is a very important interface in any gui, and the fact that gnomes sucked hard, but now looks 1/2 as good as kde's is important. it gives people a chance to comment and to make useful suggestions
If you mod me down, I will become more powerful than you can imagine....
... that *no* industry is about innovation, but playing catch-up. GM/Vauxhall/Opel are touting headlights that swivel as you turn corners as a great new thing, but that's just playing catch-up to Citroen who had those on the DS nearly 40 years ago. Likewise varipower steering - ancient French technology. Or what about BMW, with paddle-change gearboxes where you select the gear with the paddles, then press a button to engage it? That's just playing catch-up to the Wilson Preselector gearbox, found in 1930s Wolsley and Frazer-Nash cars.
A better GUI would be to have no file selector at all.
I wonder how long it will take for everyone (GNOME/KDE) to realize that...
that the new file chooser will be replaced in the next GTK+ release because even after lots of review, etc. people will start bitching after it is released.
We went through this two years ago with the FLTK file chooser, resulting in this. We did a design context, voted on the results among the developer community, and then released the new chooser in 1.1. We started getting suggestions for a new file chooser about a month later...
We're dealing with this in a simple way - all of the change requests are essentially cosmetic, so if someone wants a different looking file chooser, they can code it themselves...
I print, therefore I am.
Well the old file selector pretty much sucks and it hasn't been changed since GTK1.x series. The most annoying thing about it is that you can't see .dot files and directories (the ones in your $HOME for instance) unless you know they exist and type thieir name in the "Selection" field. I hope the new file selector (the mockups look pretty cool btw) will have an option to show listings with dot files.
Yes and the files selector was a thing people bitched about all the time when the GNOME vs KDE issue came into discussion.
eggy, is this you? It's me, rogerborg. Come to husi and we'll hug each other 'til we spurt.
I was very upset to see the blatant toadying and kowtowing to the illiterate and half-knowledgeable Eugenia.
Here is some commentary on her previous work...
OSNews, blah... (Score:5, Informative)
by vsync64 (155958) <vsync@quadium.net> on 2003.09.15 5:11 (#6962669)
( http://quadium.net/ )
While reading through the interview, I noticed such bizarre and nonsensical statements as:
Looking Red Hat's recent press releases and web site lately, it reveals a new, stronger effort to shift focus further into the Enterprise and leaving Red Hat Linux to the hands of the community for the home/desktop market while leaves a "hole" in the previous target of Red Hat at the "Corporate Desktop market".
At the end of the day, we have seen patents being so "duh, brain dead", that many have said that writing software is almost impossible anymore. What a solution for this issue OSS software should find, to ensure a future that is not striked by lawsuits left and right?
Once, you started a C++ wrapper for GTK+, but then the project got sterile.
Do you feel that Linux is replacing Unix slowly but steadily, or do they follow parallel and different directions in your opinion?
I said to myself, "This article must be by Eugenia Loli-Queru", looked to the byline, and lo and behold I was correct. The local rag is more respectable, which is saying a lot, considering that they routinely misspell the names of cities in front page headlines and such. Even JeffK makes more sense than Eugenia.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
Starting Score: 1 point
Moderation +3
Extra 'Informative' Modifier 0 (Edit)
Karma-Bonus Modifier +1 (Edit)
Total Score: 5
Re:OSNews, blah... (Score:1)
by paranerd (672669) on 2003.09.15 6:18 (#6963048)
I typically avoid OSNews because of the poor quality of their writing, but this article hit a new low. After struggling to understand Eurenia's first question I switched to reading Pennington's answers only.
Linux user since December 1991
[ Parent ]
Re:OSNews, blah... (Score:1)
by TrekCycling (468080) on 2003.09.15 7:36 (#6963738)
Yes, it would be a nice benefit if you could understand the question she was asking without having to reread it 4 times and include your own (sic) marks as you read it.
[ Parent ]
But not amazingly more usable
... did this post or not? I just got an error 500 page for my first attempt, but it recognised that I had tried to post when I clicked submit again.
In fact, the only file requestor that I have ever liked is the Amiga file requestor, ASL.
Firstly, the vast majority of the window was set aside for the files themselves! An amazing concept that, compared to the 1/4 of the window for these mockups! It is a file requestor!
Secondly there was a button "Disks" (or "Volumes") that changed the file area into a locations area where you could select disks and assigns (you could assign "Music:" to "Work:Files/Media/Music" for example) to navigate quickly around the filesystem. No need to waste a lot of space on a "common locations" area that won't be used most of the time.
Yes, it had a filename filter option as well.
With a little thought this 15 year old file requestor could be modernised and made up to date. In fact, as AmigaOS4 is coming out soon, it might very well have been updated already to include modern graphical sparkle and useful functionality like "New Folder", etc, icons for the save requestor.
bah
One of the things that Apple does well, is to steal things and pass it off as original. It may be a bit perverse, but its kinda like the grudging respect you have to give a skilled pickpocket.
There is no need for two different file managers - one like evolution or kfm and a completely separate 'file picker' used just for Open and Save dialogue boxes. As others have pointed out, they are a prime example of cruft in user interfaces, there because of the limitations of older systems that couldn't manage a multi-tasking desktop.
Personally I think that RISC OS did this the right way. There is a single file manager program ('Filer') which displays windows showing the content of directories. To load a file, double-click on it or drag it onto an application's icon. To save a file, you drag it from the application to the Filer window. This is much more intuitive and also quicker - for example you can have two Filer windows for two directories and load or save files in one or the other without clicking about in the file selector to go up one directory and into another.
This style of drag and drop saving has been implemented in the ROX desktop, but so far the other desktop environments haven't picked up on it, preferring to imitate Windows.
-- Ed Avis ed@membled.com
Process Explorer
Why not change GTK+ to provide more than one file selector, and have the user choose which file selector to use in the gnome configuration center? Application should only call a generic function to call up a file selector, and the Gnome library code would contain a factory that instantiate the FileSelector the user choose.
There is a downside to my idea though. When a person borrows someone else's computer, the user might not be familiar with the other person's file selector. Also, what file selector to choose when documenting? (probably the one set by default when Gnome is being installed).
Remember the year 2000? They promised us flying cars. They delivered the PT Cruiser...
Type the directory name (or part of it) and press tab... sure it's not the same, but it does the same thing, try it... you might like it.
This reinforces my firm belief that coders should *never* design GUIs for non-coders.
/. Windows requires this fluff because they separate out all the different filespaces into disjoint areas. We don't need it - this is where a simple tree navigator is a perfect solution.
Much as I despise MS Windows, their tree navigator just plain *works*.
1. As with every other file navigator, this one consumes too much space for the amount of information that it presents. The actual filenames only consume ~24% of the window (yes, enlarging the window will improve the ratio but it is a lot of wasted space)
2. The ability to switch between different view modes requires the user to pull down a list and select an entry. The space consumed by the list pulldown widget is enough to present a small but coherent set of button images.
3. The favourite locations sub-window is full of fluff and borrows too heavily from windows. Remember that one of the beautiful things about Unix is the rational filesystem layout: it is a heirarchy under
If you have "favourite" locations, then put them on your desktop and then use drag-and-drop. That way, the favourites are confined to the file navigator - they can be used anywhere.
4. The search dialogue is entirely superfluous. Just type! Use something like Mozilla's searching capability.
5. Font/Line sizes: enough with the white space already. Stop wasting so much space between lines of text. I want to see more information.
Sorry to rain on your parade people but please go back to the drawing board.
In fact, I switched to GNOME because it was lighter and more stable. Every couple months I install the latest KDE. Generally I'll use it for a couple days and get it setup as best I can for my own needs, but it always falls short. KDE is always just full of so many quirky bugs and apps that crash or are just too bug-riddled to be useful. Eg. the control panel (font settings are extremely quirky - and the cp crashes often), toolbar settings are extremely problematic(drag them around only to have apps crash, or worse, lose a toolbar and be unable to get it back), text alignment is generally very poor(compare to GTK, where text is always properly centered in toolbars and panels, in KDE/QT, text is often placed off-center or aligned to one edge) - I could go on and on about seriously irritating bugs in KDE.
Now, don't get me wrong, I'm not trying to disparage KDE - it is a fantastic DE. I'm just pointing out that there are real reasons that many people like GNOME better, especially more traditional *nix folks.
The grand-parent poster does, however, make some excellent points about some of the technical merits of KDE - like I said, it is a fantastic DE. I'll stick with GNOME for now though.
Cheers!
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Ever try following a shortcut to a directory in a dialog box? This only recently worked the way you expect it instead of just selecting the shortcut file itself
actually that has worked since windows 95, but only recently have developers noticed that you have to pass a specific flag to the open file dialog box to get it to follow links. if you dont add this flag then it will select a link as a file.
YUP
This is a file selector! It is a dialog box to open files. It has some shortcuts. It looks similar to that on a Mac or Windows XP system. It's a file selector!! If this is what the linux zealots are drooling over to put an end to microsoft's evil world domination then these people have to shut the fuck up. No one cares about these stupid little gui "enhancements." When I can cut and paste and actually find good software for linux, then maybe I'll give a shit. But until then, it's still just a piece of shit microsoft/apple clone. And the fact that's it's open source don't mean two shits to me since I don't want to bother reading the code.
...the GTK one looks like it is from Sun's CDE/Motif windowing system circa 1970
Probably for the same reason it has taken you so long to learn proper English.
Who the heck is Euginia and why do I want to send her love?
i photoshop user interfaces all day, so forgive me for not having the energy for visually articulating this idea...
the idea was inspired by Suggestion 3. if you go and read the discussion thread about this, the idea was actually to implement a FILTER rather than a SEARCH. i find this articulation a bit silly really because SEARCH implies a global search not a filter.. which made me think:
if you had a really simple dialog box that had a search capability you could just start typing in "hilton pari". in the background one just interrogates the slocate database and starts to put all items that start with "hilto..." in a list view below. the list view should display the parent folder of that element with a hyperlink/expander of sorts to illustrate the full path to that file.
furthermore if you abstracted this functionality, you could offer the same global search capabilities across filenames in the "recent documents" interface. so this would extend the search boundary to elements that are possibly not in your slocate database (SMB shared docs for example).
there would still be browing capabilities to allow users to do regular browsing of CD, Network etc... but i just thought this would be a highly Googleian way of opening files.
There are two different dialogs you are trying to create. One is a file finder. The other is a file creator. The former is for finding an existing file, the latter is for naming a to-be-created file. These are different ideas!!! One needs a "create new folder" button, the other does not. One needs a place to type in filenames, the other does not. Please stop confusing the two.
I just discovered this the other day...
...
The registry key
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillAppTimeout
(And if it isn't that one, just search the registry for 'WaitToKillAppTimeout')
is defaulted at I think 5000ms. Changing this to 0 gives you back that "shot to the head" effect.
Also, others have mentioned the desire for lsof or other such things...
go checkout SysInternals. They have tons of freeware monitor file handles , processes, threades, memory, DLL Accesses, port accesses, disk accesses,
no comment
Where's the dialog box to enter a filter?
Oh, and the IDE runs under WINE.
For a variety of technical and cultural reasons it seems that Kylix hasn't caught on. On the cultural side, I suppose there aren't many Linux/UNIX programmers craving a Pascal IDE and on the Windows side, there are not that many Delphi developers hankering to use Linux. On the technical end, it seems that Borland is using Java to make their IDE's portable (the X-series -- C++ Builder X, JBuilder X -- are Java Swing IDEs), and there is some hint that they are looking at wxWindows for GUI app portability (they have a toe in the water with some "preview" level of wxWindows support in C++ Builder X).
The reason KDE's dialogs don't allow file management is because they are not file managers; I have several users in my organization that can *only* manage files using the Word dialog. The dialog should only serve the purpose of opening a file, and relegate other operations to Konqueror. I am interested in your idea of a "history" view, though. Do you mean like the "Recent Files" entry in the File menu of apps?
Do not ask who Eugenia is; ask if she is single.
It's damn uncompetetive to be overwriting everybody else's love. Just because you have the last word, there is no reason to stack the echos against everyone else. We like Eugenia too you know...
Mac and Win32 have had _working_ file selectors for HOW MANY YEARS? And the unix world is STILL fighting over which GUI framework to use?
Christ. It's no wonder end-users have a hard time embracing free technologies, when bit-heads argue to their death about stuff that just doesn't matter a bit.
KDE and Gnome piss me off equally, but if we could just pick a horse and ride it I'm sure everything annoying about it would be repaired.
Is there any particular reason for open or save dialog boxes to be so small? When you are using the application it is clear nothing much else can be done at that point. Why not have a dialog box that fills to the whole screen?
No, that's not the "original version". Smalltalk, for example, had graphical file selection dialog boxes showing directories and file lists years before the Mac, and I don't even want to claim that Smalltalk was first.
In fact, text-based, screen-oriented interfaces had file selection dialogs that would present lists of choices from which you could easily pick.
What is all this "Desktop" junk and all those stupid icons? And what is wrong with "Up"? We are dealing with a tree structure here, a nice clean file system, not the new "Micro$haft File System" that Uncle Bill is trying to foist off as part of "Long-Horny".
Why do these people try to brand good, working, interfaces as "legacy" and delete or mangle them?
The file selector on my Gnome Red Hat 7.0 system is clean, easy to use, and I find nothing "non-intuitive" about it.
Leave it alone, dammit!!!!
Teen Angel - a Ghost Story
The file selector is for the "save" function also, so it makes sense to have new folder. As was mentioned earlier, the "send love to Eugenia" widget was an example for the ability to add application-specific features, such as a quality slider in GIMP when *saving* JPEGs.
On the one hand, it's pretty lame to make a big deal out of this, considering it's just a ripped-off Windows UI component. On the other hand, it's great to finally see the GNOME team getting serious about usability for the unwashed masses. Kudos all around.
From Jargon File (4.3.0, 30 APR 2001) : 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.
What i dont like to see, is when people try to copy the crappy ( but sometimes, pretty-looking ) features, that actually draw away from usefulness.
Improvements to file selector are all fine and dandy, as long as the thing actually improves the way you can work with it, at acceptable performance ( as this particular version seems to do )
But there are lots of widgets incorporated into "modern GUI-s" that should never have left the drawing boards. Witness the WinXP desktop in default post-install configuration. You have to spend significant extra effort every time to turn all that fancy crap off. And thats every time you create a new user profile.
Heres where OSS stands head and shoulders above anything that M$ has to offer, you dont want the misfeatures ? Simply dont install them.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
I was about to say the same thing. Most of the discussions there, no matter what the topic, boil down to -
50% of the posters: windoz sux! so you too ha!
Other 50%: linuz sux! so you too ha!
It's not often about being interested in different operating systems, it's more about just trolling for one's pet OS.
Mozilla, KDE, Gnome and OpenOffice must all share the same set of favourites in their file dialogs. If I add a favourite in Gnome, it should turn up in KDE's dialog boxes as well. This must be standardized. I suggest that there exists a directory where .desktop files are stored for each "favourite".
I'm taking a look at KDE 3.1's file open dialog box via an impromptu vnc session on a lonely ratpoison'd X session. I haven't played with the WinXP's dialog box, but here's the things that make the KDE dialog box more innovative than the one in Windows 2000:
A) You can right-click to add, delete and edit the shortcuts in the "Navigation Panel" (that's what KDE calls the "Places Bar"). In Windows, you'd have to add a registry key in a rather nonintuitive place ("HKCU\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ ComDlg32\ Placesbar")
B) You can hide and unhide the Navigation panel via the mouse or the keybinding. In Win2k, you would have to play with the registry for this, which makes it rather annoying if you'd prefer to have the Places Bar hidden 90% of the time, only to be revealed when needed.
C) You can customize the Navigation Panel so that there are shortcuts common to all KDE apps and also shortcuts individual to each application. I frequently visit "/mnt/niven/code" from kate (a text editor with syntax highlighting), but I'd have no reason to go there from K3b (a rather sweet CD/DVD burning app).
D) You can swap between large and small icon size for shortcuts in the Navigation Panel. Nice if your current program has a ton of shortcuts. Oh, there's a scrollbar for when you have too many icons to fit in the visible space.
E) There's a button to refresh the current directory listing. I have to hit "F5" in Win2k more often than you'd think, so mouse access for this is kinda neat.
F) A bookmarking system is built into the selector. I don't use this, but I can see how it might be useful for some people who need a little more flexibility than you'd get from the regular, flat Navigation Panel.
G) Sorting is a little more flexible, allowing you to sort in any view mode without having to right-click (in Win2k, you have to do this unless you're in "Detailed" view mode). It also allows you to decide whether the sort is case sensitive, and it's easier to reverse sorts. And you can specify whether you want directories all listed above the files or intermingled in the sort.
H) You can dynamically toggle the listing of hidden files (there's a menu button for it, or you can just hit "F8"). That's a far cry from the more time consuming "explorer.exe, Tools->Folder Options->View->Hidden Files and Folders".
I) File previews are built into this widget, and you can toggle this on and off. Moreover, if you go into KDE's configuration gui, you can tell the system which file types should be previewed.
J) At any time, you can separate the files and folders into two separate window panes, or you can put them in the same pane.
K) As with the Win2k file dialog widget, there are dropdown widgets for the active directory ("Look in"), file name and file filter ("Files of type:"). But while Win2k only makes the file name editable by the user, KDE allows you type into any three of the fields. This means that I can change to another directory easily without having to worry about accidentally mangling the file name. Sometimes, Win2k takes a while to pop up the "Look in" bar when I click on it, and while I could type a directory location into the "File name" widget, I'd lose the file name itself (in a "Save As" situation)! And if I wanted to look at all *.html files to open up in notepad, the filter widget is useless (it only lets me pick "*.txt" or "all files"), and the only way to do it -- typing into the "File name" widget -- also destroys the existing file name.
L) The KDE file dialog box is fully network aware. I could load from or save to a file via ftp or ssh (sftp), and it'll even remember the passwords during my current session.
I'm sure that Windows XP has most of these improvements built-in. I'm not trying to suggest that putting the latest KDE against Windows 2000 is a valid comparison. But I do like that I can get the above capabilities without having to spend even more money on Windows than I already have.
--
-JC
coder
http://www.jc-news.com/parse.cgi?coding/main
So Canopy representatives dont sit on the
board of Trolltech?
Sorry. Nice try KDE phanatics !!!!
@#%$#%$#! Gluey Gui's!
I accidently oppend a 2 Gig binary file in Notepad on my XP box with 512 Megs Ram, and 1 Gig pagefile.
The results weren't pretty.
Ok, so this is the worst kind of thrashing possible for an OS to deal with, but we're talking over 15 minutes just to "shutdown/reboot"
At least the memory leaks in (XP) NT are getting smaller.
What would it take to have '~' ACTUALLY work in Windows? I mean completely transparent underneath applications. REAL linking would be a godsend as well.
ROX is the most instinctive filer i know of.
Why did GEAR crush RDP?
Then how can a user find which apps have a "current directory" within a folder that the user wants to move or delete?
Qt does not make any effective use of the STL
Trolltech first published Qt when few available compilers had reliable template implementations, which is also why Qt uses a preprocessor instead of templates to add signals and slots to C++.
vintage MS Windows (1.0 or 2.0), where the user dragged a file icon from one screen area to another to get it open.
And guess what: it still works. Try dragging e.g. a .txt file onto an open Notepad window, a .bmp onto Microsoft Paint's window, etc. If the app supports embedding one document within another, you may have to drag the document on top of the app's menu bar or status bar to make the app open the document instead of embedding it in the current document.
Other than Tab, which you give a good reason to bind exclusively to switching among controls in a form, what other key would you suggest to bind to guessing the rest of a partially typed name?
even that is but one tab away for existing files and not applicable for files one is about to save.
Is too. The file name is applicable for files one is about to download and save. I've experienced a lot of frustration in file pickers not always preserving the name that the web browser suggests.
I haven't used a maximized window since the days of 800x600 laptops
I own a small-screen laptop, you insensitive clod!
the lines become too long to read, usually.
I'm guessing that by "lines" you refer to lines of text, which run horizontally in at least English text. Bitmap images don't have "lines." Vector images don't have "lines." Audio does not have "lines." I see valid reasons to maximize windows displaying things other than text.
Still have to name it? You have to type the name in anyway.
Not if it's an Internet download.
And for accessibility's sake: How do you drag-to-save or drag-to-open if you don't have a mouse? And what good is having a mouse if your arm cannot manipulate it?
Suppose I drag a Word-openable document into a Word window containing an open document. Should Word open the dragged-in document? Should it embed an OLE object referencing the document?
The right way: the app should pop up a menu with options Open and Embed. Or the user can double-click the document to Open it in a new window. If a particular app creates a new window too slowly, consider it a bug in the app.
While there is no law of HCI stating that every mouse-operable action must always have a keyboard equivalent
Such a law does exist in the U.S. Code, namely Section 508 of the Rehabilitation Act. Anything basic to a computer's operation should not require the user's ability to operate a mouse. If an app does not obey this law, the U.S. government won't consider using it. Some users can't see the mouse pointer (blindness). Some users can't move a mouse precisely (amputation, palsy, etc).
On the Acorn platform [drag-and-drop using a mouse is] the _only_ way of doing things, and works in 100% of the applications.
Fifth issue: Does it work in 100% of the human beings? Some human beings navigate UIs using a keyboard and a screen reader because they can't see a mouse pointer. Other human beings navigate UIs using a novel device because they lack coordination to move a mouse.
I understand key-navigating to a file and then Accel+O to open it; Mac OS and Windows do it roughly this way. But one thing remains: how can a user do do drag-to-save-as with a keyboard? And what about embedding another document, which many apps do when the user drags a document from filer to inside an open document?
So how would a person with limited vision or limited motion use drag and drop?
I don't see any one else bitching about this so I will. It's not a folder it's a directory.
And frankly I'll look forward to a patch for the source which fixes every release.
so that's the actual, technical term for this dialog box?
first of all, thanks to all mods... it's nice to get modded up instead of down for a change ^_^ But here are the mistakes I discovered:
You see, I'm just as terrible and despotic a language policeman to myself as I am to others :)
Standing at the very edge of my imagination, I peered into the inky void and realised -- I couldn't think up a new sig.
GNOME 2 still has the Ok/Cancel buttons ass backwards!
It's a 'basic feature' in comparison to the operating system which about 90% of the planet uses daily and has experience with. And many more people than you think *do* use it (tho running Linux you have to train yourself to *not* use it, so you eventually get out of the habit).
We're waiting.
the best way (which will kill _any_ process - even ones that task manager won't let you) is to debug it (with VC++) and then terminate debugging (which kills the process) :)
Mutter mutter RISCOS mutter mutter...
Terrorist. God bless America, who nurses a snake in her bosom.