Kickoff multiple columns

[Aaron J. Seigo]

On Thursday 17 July 2008, Luiz Felipe Talvik wrote:
> Hi
> I've made a report of a wish
> (http://bugs.kde.org/show_bug.cgi?id=164805) and tried to take it own
> my own.

well done =)

> -Should be the number of columns be fixed(defined in kickoff
> configuration) or dependable on size?

on size.

> -If dependable on size, should there be a configuration option for
> enabling multiple columns and/or setting a threshold?

imo, no.

> -Which tabs should have multiple columns?

make it consistent imho: all of them.

> -Is it better to fill up rows or columns first?

columns; vertical scanning is easier than horizontal.

> -When the number of items is small for the current number of columns,
> should be the number of columns reduced?

imho yes

> -And most important, do you like it, are there any chances this will
> be committed?

yes..

> My current modification behaves like this:
> http://www.comp.ufscar.br/~talvik/kickoff/current%20behavior.png

good progress.

> my suggestions are:
> http://www.comp.ufscar.br/~talvik/kickoff/kickoff%20suggestion-behavior.png

+1

> -Number of columns dependable on size based on a threshold, but when
> the number of items doesn't fill up all columns reduce the number of
> columns

agreed, with one exception: perfection would be to bias towards a column per 
header. for example, on the recently used section, it would be better imho to 
always have one column for apps and one for documents if there is room for 
them.

iow, this:

Applications 			Documents
----------------			----------------
Exec 1				Doc 1			
Exec 2				Doc 2
...					Doc 3
Exec N

would be preferable to this:

Applications 			Exec N + 1
----------------			Exec N + 2
Exec 1						
Exec 2				Documents
...					----------------
Exec N				Doc 3


> -Using a separator between columns that looks like the horizontal one
> currently in kicker

i like the one in your suggestion-behaviour.png (not sure which horizontal 
separator in kicker you are refering to though =)

> -Being able to configure both allowing multiple columns and setting
> the threshold

why? what is the use scenario where a user would want a wiiiiide kickoff but 
not have more columns? what threshold besides "fits" is worth setting?

think of the entries as a liquid. when you pour out a liquid, what does it do? 
it fills the container. if you put water in an ice tray, you get little cups 
full of water. if you pour water on a table, it just makes a thin layer. if 
you pour water into a drinking glass, it fills the glass until it overflows 
(onto the table? =)

that's the natural world behaviour that should be targetted here. well, 
almost: liquids react simply to gravity, surface tension and the constraints 
of the continer(s); we can make a somewhat smart liquid (e.g. biased towards 
headers) but a liquid it should be.

the real world doesn't pause when you fill up an ice tray and ask you if the 
water should spill into the other ice cups or onto the floor: it goes where you 
tilt the tray. it's a simple, direct configuration system and we have evolved 
to be pretty good at dealing with that style of configuration (to the point we 
don't even *consider* it to be a configuration system =)

that's the target. organics.

> -Fill up the column first

agreed.

> Should I release a patch as soon as I get something usable?

or sooner. don't hold onto patches too long ... if they get too big you'll end 
up with a ton of issues to fix. i'd rather see the patch step by step so we can 
comment on issues as we progress instead of a monster review at the very end. 
=)

> ps: this is useless unless this get fixed

i'll look at it tomorrow.

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

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080718/b554ad49/attachment.pgp