Kickoff multiple columns

[Luiz Felipe Talvik]

Agreed on everything.

It will take some time, I'm not used to C++/Qt and kickoff's coding style.



2008/7/18 Aaron J. Seigo <aseigo at kde.org>:
> 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
>
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>