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

List:       kde-usability
Subject:    Re: Idea for KDE 4 - global, smooth zoom feature.
From:       julian oliver <julian () selectparks ! net>
Date:       2005-05-24 22:16:50
Message-ID: 20050524221650.GD4900 () localhost
[Download RAW message or body]

..on Tue, May 24, 2005 at 12:10:08AM -0600, Aaron J. Seigo wrote:
> On Monday 23 May 2005 07:40, Joseph Garvin wrote:
> > I think the purpose of the RandR extension
> 
> composite, not RandR =) and yes, these sorts of things are what it hopes to 
> help make possible.
> 
> my concern with zooming interfaces is that our information is not that simple 
> and so may not map cleanly to such a system, and that we'd end up with a 
> complex combination of "zoomable infinite 2D area" and "windows with 
> relationships" (the current mechanism, simplified greatly =)

doesn't the addition of such features inevitably introduce a broader project
of describing the entire DE as an OpenGL scenegraph? this in turn
engages a dependence on the GPU, as in apple's osx, which hits the card for fast 2d blitting. 

where is the KDE project's cutoff policy on feature vs mininum spec here? 
would such GPU dependent features be considered sfx or be
allowed to move into the space of a default interface design?

i am a graphics programmer and work with OpenGL alot. i can certainly see a day
when desktop themes could essentially be vertex and pixel shaders, 
but find the great bulk of osx's visual effects (for instance) to be visually 
violent ephemera that only come between me and work. that they are
defaults in osx out-of-the-box shouldn't be inspiration for the KDE
project, given that many KDE users enjoy the fact it runs on their low spec
machines. 

i realise that a zooming feature would 'give perspective' to the overall desktop topography. 
however many agree there is plenty wrong with apple's assumptions on what constitues a 
default Productive Desktop Experience (TM), let alone their generisation of 'usability'; it may 
wise to keep such overt derivatives as a zooming feature one click away from being a dependable 
window-management paradigm.

right now, i'd be more interested in statistical comparison on the number
of mouse clicks, and time, it takes users to move a document from one folder to
another, rename it, and send it to a friend -  across the DE's winxp, osx
and KDE.

julian

-- 
	 _        _                  _
 ___ ___| |___ __| |_ _ __  __ _ _ _| |__ ___
(_-</ -_) / -_) _|  _| '_ \/ _` | '_| / /(_-<
/__/\___|_\___\__|\__| .__/\__,_|_| |_\_\/__/
                     |_http://selectparks.net

Artist in Residence IT University of Copenhagen
Department of Digital Aesthetics and Communication
Rued Langgaards Vej 7
DK-2300 København S
http://game.itu.dk
skype: julianoliver

_______________________________________________
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]