[Panel-devel] kalming kickoff

Aaron J. Seigo aseigo at kde.org
Mon Nov 12 18:05:24 CET 2007


On Monday 12 November 2007, Robert Knight wrote:
> > though at the same time i'm not going to put up
> > kindly with svn commit revert wars.
>
> Right, and I maintain that the use of "bold" rendering to denote the
> highlighted item instead of filling the background with the normal
> blue highlight colour is difficult to use because it makes the area on
> which you have to concentrate to determine the selected item much
> smaller.

seriously, if you tried my patch i really do not see HOW you can say that 
anymore since there are a lot more cues than bold text.

now let me say it again because apparently it hasn't sunk in:

given the small vertical space in that menu, rounded rects look really messy 
without expanding the whitespace significantly. moreover, there are still 
colour clashes: the contrast between the volume use bars and the background 
is positively paintful, and icons with shades of the colour used for the 
selection box simply don't work.

morover, there is no margin between the surrounding items and the highlight 
box; one of the original issues i noted about this approach and which is 
still not resolved. 

we now have scrollbars on pages we didn't previously have them on as well. 
this is easily solved by increasing the default height of the menu, but that 
wasn't done in your patch either.

the rounded rect and colouring used is indeed nicer than the big block of 
blazing blue, but it still falls well short of my expectations.

perhaps you could just draw this box around the text itself. i'll give that a 
try and see how it looks.

> I realised when attempting to use the "bold" rendering that 
> I don't actually look at the text of the item in the an item-view when
> trying to select it, I just recognise where the "blue selection blob"
> needs to appear and move the mouse until the blob is in the right
> position (first a big movement to get to the general section of the
> view then small movements to get the right item).
>
> At least one other person on IRC echoed my opinion, and to be honest,

that's hardly enough support to warrant the changes as made.

> I should have thrown the floor open to comments from other users
> earlier.  I am doing that now.

yeah, you should've engaged in the process. note how i'm sending patches, 
emailing the list with heads ups, not committing *when i know other people 
have patches outstanding leaving them with conflicts*?! you even managed to 
make stupid minor changes to things causing completely unecessary conflicts 
and dubious additions. hell, code no longer even compiles here ...

i also like how you completely avoided improvements such as not using 
QFileInfo in places that it's not necessary at all (it's a non-trivial class 
to instantiate) .. but hey, what's more conflicts right? and why discuss?

seriously Rob, you're commits today were just more of the same bullshit i've 
been patiently putting up with for a while now. but today i have conflicts in 
6 files here due to your will-nilly committing. 

you have asked me to engage in a process of discussion and communication while 
you yourself are not doing so. i'm not prepared to continue this way.

my personal favourite in all this might be how i now have a conflict, for 
instance, in ItemDelegate::sizeHint where the new code is actually still ... 
WRONG. *sigh*

or how you committed the part using a KMenu ... which has no impact 
what-so-ever .. but commit all the parts of that portion of the patch and 
so ... leave me with conflicts. great! zero gain, except wasting my time 
resolving conflicts.

i'm very, very, very unimpressed. i am going to ask you once more and if that 
doesnt' work then i'll just tell you to stop working on plasma related code:

	stop this behaviour. it is not acceptable in this project.

oh, and btw, could you PLEASE use the plasma coding style guide? spaces 
between methods and after commas would be a nice start.

-- 
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: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071112/badf5972/attachment.pgp 


More information about the Panel-devel mailing list