Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI Programming Software IT Technology

GTK 2.3, And The Emerging File Selector 99

Posted by timothy from the frobnication dept.
Anon. writes "GTK 2.3 was released today, and initial (not finalized) screenshots of the new file selector are available here(1), here(2) and here(3). But do remember that the new file chooser is very much a work-in-progress, and the UI is not yet final."
This discussion has been archived. No new comments can be posted.

GTK 2.3, And The Emerging File Selector More

GTK 2.3, And The Emerging File Selector

Comments Filter:

  • Frobnicate (Score:5, Informative)

    by sydb ( 176695 ) <michael@@@wd21...co...uk> on Saturday October 25, 2003 @10:32AM (#7308098)
    From Foldoc.

    /frob'ni-kayt/ (Possibly from frobnitz, and usually abbreviated to frob, but "frobnicate" is recognised 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".


    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 also been reported.

    (1994-12-16)


    Didn't really help me...
    • The point of having a new API is you can have a number of implementations that target it - the frob thing is just a dev showing off.

      The problem previously wasn't that people weren't able to code a nice new file selector - that's the easy part - but that the API wasn't sufficiently flexible to get enough information from the app to know what files it wanted.

      I imagine this one is nice and flexible, so people will be able to code whatever cool fileselector they like and it will just slot it. There's a lot to
    • In extreme programming frobnication of source code is what the coder does most of the day hoping it will work by the end.

      I guess that that gtk programmer occasionally created that file dialog after a lot of frobnication. But he was a smart lazy programmer, so he automated a part of frobnication running it recursively from within the file dialog itself.

      I also guess that if no-one will stop the guy then he will frobnicate the code further and eventually it will be AI dialog talking to him.

    • What?

      Frobnicate is a perfectly cromulent word...
    • sometimes referred to as frogging a switch, at least on one campus i know.

  • It better be good... (Score:5, Funny)

    by Gnulix ( 534608 ) on Saturday October 25, 2003 @10:35AM (#7308105) Homepage
    Considering the time and effort that has gone into this file selector, the previews of porn pics ought to be able to jump out and give you a blow job...

  • wpw (Score:1)

    by Apreche ( 239272 )
    it's gtk alright, but those file selector screenshots really remind me of KMail. Are the lines between qt and gtk beginning to blur?
  • http://primates.ximian.com/~federico/news-photos/2 003-10-07-gtkfilechooser.png [ximian.com]

    Frobnicate?

    I prefer not to have to consult a dictionary to use my operating systems, thanks...
    • It just shows that the GtkFileChooser can be extended with custom widgets/items.
      The coder of the example the sceenshot is taken from added a checkbox, and labeled it Frobnicate the file.
      * It was an example.
      * That checkbox is not going to be there in the standard dialog.
      * The UI might be somewhat diffrent in the final version
      • And how, exactly, is the abillity of the random coder to add elements to key parts of what is supposed to be stable, non-changing system real estate an improvement and in-line with good UI design, or even inline with good usability design....?

        • Re: (Score:2, Insightful)

          by account_deleted ( 4530225 )
          Comment removed based on user account deletion
        • No no. Most filechoosers I've seen provides an API to add custom elements to it.
          You might have seen some filedialogs that have a preview of an image besides it ?
          And the ability of Joe Random Coder to add elements is rather high since the source
          is available and anyone can fiddle with their dowloaded sources, no ?
          This was not an example of that though, thisone used the exposed API.

          The code is at http://kidcrash.no-ip.com/testfilechooser.c btw, I'm only sorry he had to use a word
          like Frobnicate, which seems t
    • Dude, that was the BEST PART of the the new design! :)

  • good start (Score:3, Interesting)

    by Ender Ryan ( 79406 ) on Saturday October 25, 2003 @11:06AM (#7308208) Journal
    That's a nice start, just put a friggin home button on it and i'll be happy.

    I like the idea of having "bookmarks" in my file selector.

    • Yea, good start. (Score:5, Insightful)

      by Inoshiro ( 71693 ) on Saturday October 25, 2003 @11:44AM (#7308336) Homepage
      Getting closer to QT/KDE's fileselector. Once they add home; back; forward; logical parent; new dir; bookmarks (web kind), configure, a direct type path with memory; character encoding; proper MIME filtering; and (my favourite feature) an easy to configure with custom-icons left-hand directory bookmark, which just happens to be configurable per-app that calls the file selector dialog or globally, we'll have seen progress.

      Hopefully the Gnome people can build on this.
      • See, this is why I can't stand KDE. You folks make everything too complicated. When I go into a file selector, I want to be able to clearly see directories, files, a couple of helpful buttons, and not any other distracting shit.

        I don't care about setting it up to play a different .wav file for different file types as they're selected, or being able to compile source files in the window by typing alt-ctrl-g with the files I want to compile highlighted, or changing the channel on my T.V. to a show matching
        • Personally I enjoy the ability to make a new directory when I'm in a save dialog. That can be handy. But other than that I completely agree. Keep the navigation extremely simple and the basic widget from being too cluttered-- at least make most of the clutter optional and not on by default.
        • Have you actually used the KDE file dialogs? No, it's not simplistic. But it is simple. There is a difference.

          Let me bring one up here and describe it for you:

          Browser style buttons and path at the top
          Quick directory icons on the left (optional)
          List view of the current directory in center
          Preview on the right (optional)
          Filter, filename, OK and Cancel buttons on the bottom

          It's very usable, well thought out, and elegant. Any simpler and it wouldn't be usable. As it is now, you can use it solely with the mous
          • Are you afraid of those options? Get used to it, because that's the real world. Go buy a new car and the first thing the salesman is going to ask you is what options you want. And I don't see people getting themselves all in a lather because Burger King says "have it your way."

            Just because it happens in the real world doesn't mean it's the ideal. Frankly, I'd rather have a car that's more user-friendly than one with a hundred buttons I need to learn, to operate the smallest of things.

            And just because I
            • They don't ask you if you'd rather have four gears or five, what you prefer for the resistance on the steering wheel, which side you want the pedals on, whether or not you want the gear shifter "inverted", and how you want the dash layed out.

              KDE doesn't ask this stuff either. Get real here!

              The KDE file dialog has sensible defaults. You don't have to change anything. You don't have to configure it. You just use it. Is that so hard?

              Usability != conformity
        • For Christ's sake, your configuration screen for the clock has what, four separate tabs? It's just a fucking clock!

          Just a fucking clock? Clocks are complicated things. Not everyone lives in your time zone, follows your conventions on time (24 hour vs. 12 hour,) cares to see the date as well (or not.) Clocks often have alarms attached to them. Clocks are supposed to be accurate, requiring some method to set them, or even automate the setting of them. Useful clocks also include the notion of "date."
        • I ran KDE 1.1 in 1999. Then I ran Gnome 1.0, 1.2, 1.4, and recently 2.0. Guess what? Going over to KDE 3.2 recently was great. Not only is QT faster than GTK+ 2 (which is mind bogglingly slow on my Athlon XP), I gained usability of file dialogs.

          You may think it's complicated, but it's not. It intelligently sizes itself to be a larger portion of my desktop, and the customizable (per app!) quick-jump bookmarks on the left make it so much easier to work with data in directories that are far apart, it's n
          • Interesting, I was using KDE 3.1 and then switched to Gnome 2.2 (and recently to 2.4) because most of my apps are GTK+ anyways. I found it a bit faster, and also wasn't missing much. Though, Nautilus needs a bit of work. Actually, I'm finding most of my complaints and desired features have been answered in 2.4. Gnome has mostly caught up I think. Konqueror file browser still has a bit of an edge. I will have to keep checking out KDE, but I am a Gnome user for now. They are both nice, you can't go wro
        • It is two tabs now. It was a design problem, rather than functionality issue - the functionality is still the same with less clutter.
      • I don't want all that clutter, please leave it out of GNOME! :)

        Seriously, GNOME, these days anyway, is all about simplicity. There shouldn't be a zillion buttons everywhere that you really don't need. If a particular apps needs that complex a fileselector, it can have it's own.

        I like GNOME better than KDE these days simply because when I use KDE, all the buttons on everything are too distracting, and instead of having nice comfortable defaults, there's configurations for everything, but often those co

        • The KDE file dialog is simple to use. It works just like a browser with forward and back buttons, except it has a preview pane and a pane on the left for large icons of frequently used locations, both of which are practically required in a modern file dialog. The dialog works exactly how you would expect it to work. There's no learning curve at all. When features can be added without detracting from usability, then they should be added, because features are good. They help us get our work done faster.
          • and it doesn't use icons on the files

            Yet.

            Plus it has less features than a normal file dialog.

            I don't see how you'd know that, since I doubt you've used it. Even if it was true, why would that necessarily be a bad thing? Do you need a full-blown instance of Windows Explorer in your file dialog?

            • I do think that a full-blown explorer instance in the file dialog is a good thing, actually. It is an interface for navigating through files that users are already familiar with. There's no extra learning curve, and all the features of the normal file browsing windows are accessible. Why make a totally separate interface for the file dialog? It causes code duplication and it causes confusion among users who must learn two separate interfaces for file browsing. I don't see any benefit to inventing a new
            • > Do you need a full-blown instance of Windows Explorer in your file dialog?

              I don't know whether I need one, but I certainly use most of the Windows Explorer functionality in my file dialogs on a daily basis. I don't know about you, but being able to copy the old version of a file to a backup directory before saving over it is quite useful, and I appreciate not having to fire up a file manager and navigate to that file separately when selecting File/Save As will open a window in the right directory str
              • I do too. When you've got big huge directories and you were looking at them in a file manager arranged by size or extension it's a bummer if the file chooser doesn't let you go back and find your file in the context that you remember using it.
                However, the more detailed view with a few more tabs across the top could also be done as a right click perhaps. That way people who wanted it could have it and other wouldn't know it was there. Also, to be able to resize the thing when you use the detailed view ca
          • This file dialog is purely a work in progress, expect it to be entirely different when it's done.

            There were some technical reasons for not changing the file dialog sooner, hence the reason for this even being a worthy announcement.

            • Well, I certainly hope that they throw this mockup away and start on a new one.

              I'm well aware of the arguments over the GTK file selector, and I already know that this was worthy of a Slashdot story. I just don't like the mockup, that's all.

        • If you're looking for simplicity, grab your TWM and VI via xterm. Live in them all you want.

          I want usability. I want to be able to say where the 3 most common dirs I save in KWrite are in a shortcut on the left hand-side, and I want to be able to customize my browse-for-icon dialog to include /usr/share/pixmaps. I want drag and drop from Konq to download files to the desktop intelligently (which Mozilla doesn't do, annoyingly). I want all these great features Mac users have, because the automation mean

  • Why is this so hard? (Score:5, Insightful)

    by Crayon Kid ( 700279 ) on Saturday October 25, 2003 @11:13AM (#7308240)

    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.

    I'd also put my 2 cents on them 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".

    • I believe the design is loosely based on the Panther fileselector. The Firebird fileselector is nice, but it's ruined by the lack of tab-completion. That's what makes the current GTK selector so nice, and hopefully they'll keep it for the new one.
    • Man, I agree. How frickin hard is it? The GNOME file selector has sucked monkey nads since 1.x and we're now at, what, 2.4? It's not just missing functionality, it actively sucks!

      What I really don't understand is that various attempts have been made to add a better file selector (by Ximian, for example), yet they haven't make it into the GNOME core? Why not?
    • The KDE file selector? What? It's just the Qt file selector man? Almost everything in KDE is just Qt with lipstick on. Qt is a brilliant product and KDE is riding the wave. When you consider how much excellent stuff they've got to work with you see that they're not really putting in any more work than the GTK team.

  • Well.... (Score:5, Insightful)

    by samjam ( 256347 ) on Saturday October 25, 2003 @11:26AM (#7308276) Homepage Journal
    We've come a long way since the original stinky X file selector dialogs, but thats about the best I can say about it.

    No doubt a lot of honest graft has gone into the design but it stinks, really.

    Give me the latest windows shell open dialogs with shortcuts in the left hand side, pop-down directory list and big file selector with alternative views.

    The only fault with that windows dialog is the small default size.

    But these new GTK dialogs are just true-type anti-aliased windows 3.1 dialogs trying to show the directory tree and file list through two tiny peepholes.

    Ugh

    Sam

    • Re:Well.... (Score:3, Insightful)

      by Alethes ( 533985 )
      Giving them credit for something that is not finalized, I still have to say that I'm disappointed with the direction this is headed. It seems that the file selector and Nautilus both have gone the complete opposite direction as the rest of the GNOME and GTK projects in that they're not simplifying and making the desktop more intuitive and usable. Even if everything else is perfect, the usablity of GNOME will suffer greatly as long as the foundational elements of the file selection and file management are
    • It definitely needs some short cuts icons across the top, like for the user's home directory, the root dir, maybe per user configurable favorite directories, maybe a last used list even, that could be a pulldown, or some kind of small button that fans out a big directory list of previously used directories. And remember the last used directory on a per app basis some how, dunno if that's up to the application or the file selector tho. If you do that, you might not even need the left hand treeview pane, or
      • The is no "extra bells and whistles" gnome file selector. Gnome apps use the same widgets as regular GTK apps (this used to not be entirely the case, but it is now).
        • In gnome 2.4, footprint, run application, run with file, presents a "bells and whistles" file dialogue, with a button for your home directory, desktop, and documents, with rename, delete, and new directory buttons. Other gnome apps use this same dialogue. I assumed it was a gnome thing, but actually, it looks like a gtk thing as normal gtk apps use it.

          Kinda weird that the "new file dialogue" takes away these useful features, looks like a step backwards, which leads me to believe I'm missing something her
          • The dialog that you're seeing is probably the Ximian dialog, which is a patched version of the dialog in vanilla GTK 2.2. It's basically just the same old dialog from 1998, except slightly prettier and with shortcut buttons. It's included in the Ximian Desktop (obviously), but some distros (Debian, for example) have applied the patch to their own GTK packages.

            The new dialog has a much cleaner and more extensible API, does support most of the same features as the Ximian dialog (along with a few extras, like

    • I for one love the fucking horizontal scroll bar on the directory tree window on the left. It is not completely annoying, either. The fact that you cant resize that part of the window is also fucking great.

      But hey, we can't ignore such amazing UI innovations as having the word "Yesterday" under the file modification date column, instead of yesterday's date.

      Honestly, is the guy in charge of this a complete moron? File choosing widgets have advanced far beyond this, why don't they just copy them?
      • those itty bitty little trees are *the* most advanced tech on earth

        do you now how long it takes to optimize the blitting to get that to display so quickly

        it is not for you to question why some of the most important text on the page is obscured when at least 20% of the canvas is devoted to ok/cancel

        scroll scroll scroll your boat, gently down the screen


    • My biggest complaint about the Windows File Open dialog is its fixed size. I have a HUGE monitor at work, yet Microsoft forces me to scroll (horizontally, no doubt) a tiny window to find my files. I wish the File Open dialog could be maximized or at least resized.

      Looks like all three of these GTK dialogs make the same design error..

      • the windows file open dialog has been resizeable since windows 95. what app are you using? it's possible that your app is reinventing the wheel
        • the windows file open dialog has been resizeable since windows 95
          Which version of MS-W95 are you using?
          I use MS-W95 OSR-B nearly every day, and I have never been able to resize the official open/save dialog boxes.

  • Maybe next round... (Score:5, Insightful)

    by kwerle ( 39371 ) <kurt@CircleW.org> on Saturday October 25, 2003 @11:57AM (#7308382) Homepage Journal
    Sigh. You can see the problems with it just by looking at it on any system with a good dialogue (OSX, for example).

    No favorite folders (buttons/popup). No home folder (button). Image3 shows PERFECTLY that you can't tell the full path in the window without scrolling up and memorizing the directories you're in, instead of left->right and seeing them all highlighted (treeview blows). Look at it - am I in my image directory, or bobs?

    There are good file dialogue boxes out there - have been for years. STEAL THEM.

    yeah, maybe this is flamebait, but mostly I'm tired of bad non-osx file dialogues.
    • Which part of "initial (not finalized)" don't you understand? The design work on this just started less than a month ago. Give them a chance.

      • Re:Maybe next round... (Score:3, Insightful)

        by kwerle ( 39371 )
        initial (not finalized)" don't you understand? The design work on this just started less than a month ago. Give them a chance.

        To me, this looks like just about every other unix file dialogue. Bad.

        They're posting mock-ups. There's no reason a mock-up should look this bad.

        Again, this is all IMNSHO.
        • """
          To me, this looks like just about every other unix file dialogue. Bad
          """

          Are you sure?

          I'd have said _worse_! :-)

          I'm not a huge fan of the OSX style, but I'm failing to think of anything better. Some old windows 3.1 applications had decent
          home-grown file selection widgets, but they were few and far between, and I can't remember any of them.

          I'll know them when I use them. These are the things that either feel _just right_ or feel like a pain in the neck instantly.
          Everything apart from Opera 6 is a pain
    • yeah, maybe this is flamebait, but mostly I'm tired of bad non-osx file dialogues.

      Don't worry, you're not alone. Truth is I was astonished to see that "file open" dialogs are worthy of screen shots. Microsoft had this figured out back in w2k, and OS/X is even better. GTK is right about where win3.x was 10 odd years ago. What is the problem here?

    • Half of these things are unfeasible, since GTK+ is a toolkit and has to avoid having state that would tie it to a given environment.

      And tree view with completable boxes is clearly the best approach to file selection. More importantly, the widgets have to be programmer-extensible (like Java's are, IIRC).

      • Half of these things are unfeasible, since GTK+ is a toolkit and has to avoid having state that would tie it to a given environment.

        BS. GTK+ is a toolkit, which is why it should be able to maintain state and use it in any environment it finds itself. What would it possibly have a problem with? Home directory button? If the current context has no home directory, disable the button. Favorite directories? Ditto.

        And tree view with completable boxes is clearly the best approach to file selection. More

  • oi (Score:1)

    by Deternal ( 239896 )
    Seems nice and simple which is good.

    Don't need back/forward buttons. To me that is probably the most annoying 'feature' of the windows file selection UI (if it gets in please let it by off by defeault and let behaviour be controlled via the gnome config tool).

    The possibility of adding some kind of bookmarks via the gnome config tool would probably be nice. Though home dir should be max for default.

    The filetype box should have an other type (ie so it's possible to type in the mimetype if for some reason g

  • Refreshing (Score:1, Flamebait)

    by turgid ( 580780 )
    It's refreshing to see that our Free and Open Source Software elders and betters continue to make such ground-breaking improvements at such a pace. Their innovation knows no bounds.

  • I say (Score:2, Interesting)

    by Kickasso ( 210195 )
    steal a few ideas from SGI's file selection dialog. It's probably the best (and the most underrated) widget that ever existed on a Unix desktop...
    • Any screenshot to explain why you want to do it? Or you expect 90% of /.ers to be familar with SGI UI?
      • I tried to find one on the web but couldn't... sorry, and I don't have an SGI any more to make a screenshot.
        • Seems like you are the only one who knows why it's probably the best (and the most underrated) widget that ever existed on a Unix desktop. Well, let it be you little secret :)
          • If you are so eager to know, I'll find a screenshot tomorrow, okay?

  • MacOS (Score:5, Interesting)

    by Michael.Forman ( 169981 ) * on Saturday October 25, 2003 @01:38PM (#7308953) Homepage Journal

    Ugh. What a hideous file selector. After installing and taking MacOS X Panther for a spin last night, I'm just amazed how backwards and unprofessional GTK's file selectors are.

    If it's not possible to compete with commercial operating systems, why not make a radically different file selector as an option. Imagine a command-line interface where the user 'cd's into the appropriate directory and does a 'put'? Of course, I'm of the mind that Evolution and Open Office should have a "vi" input mode.

    Michael. [michael-forman.com]

  • Another Prototype. (Score:2, Informative)

    by Anonymous Coward
    I came accross these GTK file dialog mock ups recently.

    They look really good.k [wanadoo.nl]
    • All I see is a dozen shots poorly emulating the deficient Windows file selectors in their many forms (9x, 2000, XP). I would rather read a couple paragraphs explaining the reasoning behind each with a little analysis. A bit of innovation wouldn't hurt either. I'm not asking people to reinvent the wheel, just stop copying a tired Windows look and calling it a masterpiece.
      • They're all masterpieces compared to the current file dialog.

        I don't expect brilliant innovation I just want (a) an usable file dialog and every "innovative" mock-up convinces me that the only way to get it is to copy Win/MacOS/KDE/etc. and (b) *one* file dialog, currently there are myriads of slightly "improved" versions out there, practically every gtk-application has a different file dialog. And that sucks.

  • FLTK gets it right (Score:3, Insightful)

    by sunya ( 101612 ) on Saturday October 25, 2003 @02:25PM (#7309215) Homepage
    FLTK's file chooser [fltk.org] uses the best of all worlds... GTK should probably just adopt it and be done with it.
  • ...The GTK team will invent the scroll bar!
  • what was wrong with the old one? or maybe i'm remembering a different one, can someone point me to screenshots of the one everyone hates?
    • A lot of applications need specialized file selectors (with previews and such,) the old file selector can't be specialized so it needs to be reconstructed, these reconstructions usually don't take the utmost of care when conforming to GNOME UI/i18n/etc guidelines, and chaos ensues. I think.
  • The concept of a file dialog is simple, yet it's apparently hard to write a good file dialog. Solution: delegate dialogs to child processes. Let end users replace dialogs they don't like with something better by changing things around in /usr/X11R6/bin.

    GTK should install its versions of dialogs in /usr/lib/gtk/dialogs, KDE should install its versions in /usr/lib/kde/dialogs, etc. Then a symlink at /usr/X11R6/bin/choosefile should point to an executable called /usr/lib/???/dialogs/choosefile. A bonus wo
    • You could use an environment variable to override the default or look for "chooser" in the path. This is such an obvious concept that it is absolutely rediculous that no OS does it.

  • Look beneath the surface (Score:3, Interesting)

    by timotten ( 5411 ) on Sunday October 26, 2003 @08:12PM (#7316026) Homepage
    The release notes say:

    GtkFileChooser: a replacement for GtkFileSelection with replaceable backends, many new API features, better user interface (UI is still a work in progress) [Owen Taylor, Federico Mena Quintero]


    It's not clear from the changelog what is supposed to be replaceable, but looking at the gtk-devel mailing list (it took me 1 minute), a fine description [gnome.org] was posted a couple weeks ago. Applications and users can both provide shortcuts. It can use GnomeVFS instead of Unix file access, so you get access to remote folders and all that...

  • Not bad looking but (Score:3, Insightful)

    by LWATCDR ( 28044 ) on Monday October 27, 2003 @03:33PM (#7321685) Homepage Journal
    I did not see anyway to change the view I tend to like to use the details view in windows. It would also be useful to beabile to sort by date or name and to have the option of setting the view for the applications or for the entire desktop.
    just a sugestion.

Slashdot Top Deals

A complex system that works is invariably found to have evolved from a simple system that works.

Close