| Summary: | Warning message on the start up of filelight every time | ||
|---|---|---|---|
| Product: | [Unmaintained] kde-windows | Reporter: | Jekyll Wu <adaptee> |
| Component: | general | Assignee: | Patrick Spendrin <ps_ml> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ps_ml |
| Priority: | NOR | ||
| Version: | 4.10 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jekyll Wu
2013-05-29 13:00:50 UTC
Hm, the shortcut is generated from the .desktop file afair, so I guess we need to find out what is really wanted: how would a working commandline look like? Filelight has some more problems: 1) no icon in the executable (missing kde4_add_app_icon) 2) no coloured output. (In reply to comment #1) > Hm, the shortcut is generated from the .desktop file afair, so I guess we > need to find out what is really wanted: how would a working commandline look > like? I guess it expects a folder path, so that for example in dolphin you can trigger the context menu of some of folder, then choose to open it with filelight and filelight will calculate its size statistics? Of course, that is under *nix environments. I'm not clear how the conversion from .desktop to windows shortcut is done, but I also notice other application (like okular) shoutcuts do not contain place holder any more after being generated from .desktop. Why filelight is special here ? > Filelight has some more problems: > 1) no icon in the executable (missing kde4_add_app_icon) Yes, actually quite a few(10+) applications lack that. I'm considering opening a meta ticket for that kind of issues. (In reply to comment #2) > (In reply to comment #1) > > Hm, the shortcut is generated from the .desktop file afair, so I guess we > > need to find out what is really wanted: how would a working commandline look > > like? > > I guess it expects a folder path, so that for example in dolphin you can > trigger the context menu of some of folder, then choose to open it with > filelight and filelight will calculate its size statistics? Of course, that > is under *nix environments. aah, that makes sense. > > I'm not clear how the conversion from .desktop to windows shortcut is done, > but I also notice other application (like okular) shoutcuts do not contain > place holder any more after being generated from .desktop. Why filelight is > special here ? No idea, I didn't write that code. Need to look into that. > > > Filelight has some more problems: > > 1) no icon in the executable (missing kde4_add_app_icon) > Yes, actually quite a few(10+) applications lack that. I'm considering > opening a meta ticket for that kind of issues. Please do so. Also filelight doesn't show to much useful information (e.g. for subfolders), so maybe you can open another ticket for that as well? ok, simple bug in the start menu generation code. Git commit c179b20f30f9c487a01706efa11e6217edd20738 by Patrick Spendrin. Committed on 29/05/2013 at 16:34. Pushed by sengels into branch 'kde-4.10'. fix generation of startmenu entry for filelight M +1 -0 portage/kde/kde-runtime/kde-runtime-20110130.py A +12 -0 portage/kde/kde-runtime/kde-runtime-4.10.2-20130529.diff M +1 -1 server/serverconfig/packagelist-release.txt http://commits.kde.org/emerge/c179b20f30f9c487a01706efa11e6217edd20738 > Also filelight doesn't show to much useful information (e.g. for subfolders), so maybe you can open another ticket for that as well? Well, I fail to notice such problem, so I really can't create such a ticket for that. Now that I have create a meta ticket (bug 320424) for those icon issues, and this warning message should have been fixed by the previous commit, should this ticket now be closed as fixed ? Yes, I'll add a different bug report for that as soon as I have checked what filelight should display. So, I think it is OK to close this report now. |