Kickoff multiple columns

Luiz Felipe Talvik talvik at gmail.com
Thu Jul 31 21:29:36 CEST 2008


Hi again
This was freakin hard. That thing about fluid is complicated. :-)

There is no need to look or compile the patch, the code is functional
but unreadable(the next thing in my todo list).
Here are the screen shots of the behavior:
http://www.comp.ufscar.br/~talvik/kickoff/screenshot.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot1.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot2.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot3.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot4.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot5.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot6.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot7.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot8.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot9.png
http://www.comp.ufscar.br/~talvik/kickoff/screenshot10.png

Aaron, you said I should base the minimum size of the column with
"Fits", but the items don't have a limited size. So I propose to base
the minimum size on a certain number of chars(independent of font size
a least a minimum number of chars would appear). I don't know how to
implement that(just reverse engineering until now), something about
Qstyle right?
When the name is to long I wanted it to look like this:
http://www.comp.ufscar.br/~talvik/kickoff/20080729_applications_browsing3.jpg
By the way, I couldn't find lancelot't code in svn, where is it?

TODO:
-polish/comment code
-"applications" tab support multiple columns
-threshold not based on fixed pixel based value
-fix itemdelegate to respect boundaries
-create smooth item look when doesn't fit

What to improve? What doesn't look right? Wishes?
Thanks



On Fri, Jul 18, 2008 at 1:31 PM, Luiz Felipe Talvik <talvik at gmail.com> wrote:
> 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
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 11659 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080731/f0d11213/attachment-0001.bin 


More information about the Plasma-devel mailing list