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

List:       kde-core-devel
Subject:    Re: fast, dirty, but hopefully useful (clueless user report :-)
From:       Reginald Stadlbauer <reggie () trolltech ! com>
Date:       2000-03-23 18:29:53
[Download RAW message or body]

On Thu, 23 Mar 2000, Cristian Tibirna wrote:
> Hi
>
> First and foremost, my deeply respectful congrats to all the heavy working
> people who changed the face of kcontrol and the status of konqueror so
> much so fast. It's absolutely amazing.
>
> Now, the fast and dirty part (once again under the reserve that I will
> try to look in at least a few of them soon):
>
> Kcontrol:
> - could use some sort of double buffering or other (delayed refresh)
> tricks in order to eliminate the heavy flickering at module change
>
> - trying to access modules that aren't there or aren't functional crashes
> kcontrol altogether. I know this is not insurmontable, since it didn't do
> it, for same modules, a bit of time ago (before the big rewrite).
> Examples (in the same time, modules to check) : Desktop/borders; Windows/*
> (how comes, I have done these work a few weeks ago!!!); Sound/Bell;
> Laptop/Battery warning;
>
> - the layout on the about page is a bit too spaced. Konqui has too much
> white around him (above and below). Putting the brief sys info in a box
> could help. A brief info about uptime and memory usage would be nice too
> (but not portable, I believe).
>
> - the layout on the Network/SMB page is too widespread.
>
>
> Konqueror (all these are 100% reproductible):
>
> - when a viewer part is loaded (e.g. kview), Up button remains active.
> Clicking on it (almost an automated reflex) crashes konqui.
>
> - aktion loads toolbar and seems to function, but no image is displayed
> (possibly some changes in the part display API in konqueror)
>
> - if I split to 2 views, link the (e.g.) left one (master) to the right
> one, then unlink them, last mouse click pass the focus to the former
> master, but doesn't refresh the green led in the status bar. Have to pass
> focus to former slave view and back again to former master to have the led
> functional again
>
> - in dirtree mode, tree view has |+| and |-| signs even on directories
> that don't have subdirectories. Clicking toggles +/- but doesn't do
> nothing AAMOF.
>
> - in dirtree mode, a linked view indicator appears. If we unlink them
> manually (permission granted but shouldn't) then change focus to previous
> tree view (left) then try to toggle off the menuitem in the View menu (the
> one that says "Directory Tree view" crashes konqueror
>
> - kimap files are mimetyped as executable .desktop files.
>
> - if the first click in a tree view is on a |+|/|-| branching sign, a drag
> operation is erroneously started (possibly a Qt bug)

No, but it does for sure the same thing wrong as nearly everybody does. The 
problem is that for starting a drag you use normally QListView::itemAt() to 
find out if the user clicked on an item and start a drag if it returns an 
item. And the +/- sign is part of the item. So you have to do the trick like 
it is done in the dirview example in beta3 (around line 450) and IIRC I 
added some docu for the in QListView::itemAt() for beta3.

-- 
Reggie (reggie@trolltech.com)

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