Filelight into kdereview (again)

Sun Sep 26 00:25:22 BST 2010

Hi Martin,

Samedi, le 25 septembre 2010, à 15:45, Martin Sandsmark a écrit:
> On Monday 20. September 2010 21.09.11 Friedrich W. H. Kossebau wrote:
> > * embedded in Konqueror, the Settings menu contains two times the entry
> > "Configure Konqueror...", while one refers to the settings of the KPart
> 
> I guess this is a kdelibs bug? I just use KStandardAction::preferences.
> I'll see if I have time later to try to track it down.

Yes, is. But that action always uses the program's name in it's display. Which 
is "Konqueror" if embedded in Konqueror :) So KStandardAction::preferences() 
does not work here. You have to create an action on your own.

You could also think about omitting a special "Configure Filelight" entry for 
Konqueror (confuses the user anyway, as they selected "Radial Map" in
"View"->"View Mode" and not "Filelight", so what is this "Filelight") and have 
the config module also embedded within the ones of Konqueror, similar to like 
the Dolphin filesystem views are only configurable there.

> > * this is not, might be rather still problem in code:
> > QPainter::begin: Paint device returned engine == 0, type: 2
> > filelight(4795) RadialMap::Map::paint: Failed to initialize painting,
> > returning...
> 
> It was attempting to paint on a null pixmap. Fixed now.

Yup, vanished also for me now.

> > * embedded in Konqueror, the KPart seems to not integrate it's statusbar
> > with the one of the Konqueror window which looks strange.
> 
> Hmm, I seem to be getting a three-line high status bar, or close to, at
> least. I can't see anything blatantly wrong I'm doing with the KParts API,
> though. I can try to dig into konqueror to see why this is happening
> later.

That bigger statusbar even stays once you switch away from the Filelight view. 
Please file a bug for Konqueror if you do not find the reason when digging 
into it.

> > * there could be a hint in a tooltip on the center circle that clicking
> > this area will move the view up one level in the hierarchy (only
> > discovered it by hard testing ;) )
> 
> I'll write it up on my todolist.

Thanks.

> > * there could be a small delay until a new section is selected on
> > mouse-over hovering, similar like there is with entries in menus.
> > sometimes one just wants to move the mouse cursor out of view or to do
> > something in another window and still keep the current selection like it
> > is.
> 
> I'm not sure I understand you completely. You mean to keep the last
> selection for a small amount of time when Filelight loses focus?

No, I meant when the mouse moves over the next item which could be selected in 
the filelight view. Currently that one is selected instantly if there is a 
mouse event over the item. That way you have to move your mouse pretty fast 
out of the window so it does not trigger a single event over anything else in 
the view to prevent to have another item selected.
Hm, the menu comparison seems a bad one currently, at least with Oxygen.  
There selection of new items in it is now done also instantly. But I remember 
there is a time-delay possible, to be able to go with the mouse cursor 
directly to lower parts of the submenu just opened, i.e. with passing other 
items of the parent menu for a few milliseconds without having them triggered, 
so the submenu is not switched, to that one of the menu item you only wanted 
to pass.

Got a better idea what I mean?

> > Code-wise:
> > ----------
> > * LocalLister::readMounts()
> > 
> >     remoteFsTypes << QLatin1String( "smbfs" ) << QLatin1String( "nfs" )
> >     <<
> > 
> > QLatin1String( "afs" ); //TODO: expand
> > -> perhaps better a whitelist than a blacklist?
> 
> There are (as far as I know) more diversity in local filesystems than in
> remote ones, hence why I chose to continue with the shortest list. The best
> thing would be to have this information from solid, though.

Please file as bug to them, so they know :)

> > * MyRadialMap::setCursor(...)
> > focusSegment()->file()->name() == QLatin1String( "Used" )
> > -> will fail for a file named "Used", or?
> 
> This is just used for the summary widget (when you open Filelight), and we
> abuse the radial map widget a bit to display the available partitions. :-)

I guessed this would just fail for any file or dir also named "Used", but 
testing could not confirm this, okay. Ah, the "if (m_summary){" explains this.
A comment about that would not be too bad for your fellow coder looking into 
that code and wondering as well :)

> > * DiskList::DiskList()
> > 
> >     foreach (const Solid::Device &device,
> > 
> > Solid::Device::listFromType(Solid::DeviceInterface::StorageAccess))
> > 
> >     { // Iterate over all the partitions available.
> >     
> >         if (!device.is<Solid::StorageAccess>()) continue; // It happens.
> > 
> > -> reported to Solid guys? Should not happen! seen this also in another
> > place * too lazy to search for more items to complain :P
> 
> I was too lazy (*cough* busy) to write up a test case for them at the time,
> but it seems like it isn't happening anymore. But I'm not sure when it went
> away, though, so I'll keep the checks in place.

If you like, okay. Removing the root of evil still preferred if possible. ;)

> > Oh dear, just listed the things I did not like, forgot to list those I do
> > 
> > :) All in all looks alright, working and usable, think it should/could
> > 
> > finally move over into kdeutils, once at least the one item above marked
> > with FIXME is fixed (could be just my broken trunk, though).
> 
> I think this is it. :-)

Yes, looks like problem elsewhere.

> > Summary:
> > Hoping you will by the time iron out the other stuff I mentioned, my
> > thumb is up to have filelight move into kdeutils, once the behaviour on
> > pressing the stop button during a scanning process is assured to be sane
> > :)
> 
> I think it should be sane now.

Please also help out with 
http://lists.kde.org/?l=kde-i18n-doc&m=127851249725448&w=2
as Alexander requested, some i18nc with proper comment should do.

The minimum-height-bigger-than-my-screen-resolution seems a problem only 
experienced by Albert so far, so I consider that something to be solvable 
after the move.

Given that Albert and Burkhard both had a look but did not complain about any 
further translation/documentation problem I also see no blocker in that, 
unless they object now :)

Summary:
So please improve that unclear message as indicated by Alexander, and then I 
would like to have filelight move into kdeutils.

Will you do the move yourself, or do you want me to do that?

Will add a section on utils.kde.org for it, or do you plan to keep the 
old/current homepage for it? Max Howell still involved in filelight?

Please also do not forget to subscribe to 
https://mail.kde.org/mailman/listinfo/kde-utils-devel , the low-traffic 
coordination mailinglist of kdeutils.

Cheers
Friedrich
-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta