[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Kig dialog needs your help!
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-03-09 17:15:54
Message-ID: 200503091016.06797.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 09 March 2005 09:58, Florian Graessle wrote:
> On Wed, 09 Mar 2005 08:37:48 -0700
>
> "Aaron J. Seigo" <aseigo@kde.org> wrote:
> > On Wednesday 09 March 2005 04:28, Florian Graessle wrote:
> > > Usually the available settings depend on the file type which the
> > > user currently selects in the file dialog. Think of a user
> > > exporting to an image file. Using a wizard he is first presented
> > > with the options. JPG files e.g. offer different options from what
> > > PNG files offer.
> >
> > this isn't how the application in question works. the options are not
> > file format specific, but specific to the type of image format:
> > bitmap, vector, etc. the settings are things like width/height,
> > whether or not to include the grid... these don't change when you
> > select JPEG instead of GIF. so your concerns aren't of issue in this
> > case.
>
> They may not be right now, but they may be some time in the future.
> However a wizard-like approach would totally depend on the fact that the
> settings will never be file type specific. Can you guarantee that the
> kig developers will never implement such specific options? With

as this is not a graphics editor, i'd say the odds are rather low. as it 
stands, they don't exist and the current options in KIG don't have _anything_ 
to do with file storage.

> As I wrote I wanted to show two possible ways how the file dialog could
> be extended easily throughout KDE.
> For consistency's sake it's no use to
> use quick and dirty application specific implementations when there's
> the chance to do this KDE wide.

it would actually be far quicker to just plonk these things into the file 
dialog.

if you _really_ want to do it right... then i'd suggest that these KFD 
mimetype based additions ought to be automatically added by KFD itself. it 
should have a way to look up plugins that define features available for that 
mimetype and create some standard mechanism for applications to use those.

even then, i really wonder at the workflow this would imply ... the file 
dialog is meant to pick a location for the data. does defining the contents 
and properties of that information belong to that same step, or is it a 
separate step? how many concurrent and orthogonal options can the average 
user be expected to competently handle?

> I just wanted to show what an "advanced >>" button looks like and
> how it works. The idea behind it is still perfectly applicable to file
> dialogs. Sorry, but I simply didn't find any better example that's more
> related to the file dialog.

i've seen file dialogs on win32 that add a bunch of features to the file 
dialog, including expand-to-more-options buttons. there really is a limit to 
how much you can cram into a single interface.

there's also something to be said for a file dialog that finds a destination 
for a file and does little else, and which is consistent across applications.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]