-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    LinuxDaily.com    Linux42.org    OpenSkillz.com   
 
Apps
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login


Sponsoring


-
- Content .- Fans (4) .- Knowledge Base  . 

Filelight

   1.0  

KDE Filemanager

Score 85%
Filelight
zoom


Filelight
zoom


Link:  Link
Minimum required   KDE 3.3.x
Downloads:  24774
Submitted:  Jan 5 2004
Updated:  Sep 2 2006

Description:

Filelight creates an interactive map of concentric segmented-rings that represent the sizes of files and directories on your computer.

* KIO support, check disk usage on your web server or grandma's linux box
* KPart for quick disk usage checks while in Konqueror




Changelog:

1.0
* As RC2, no changes at all.

RC2
* Fixed two crashes, we hope
* Correct 2GB size limit on Debian
* Stopped using GiB/MiB in favour of the more universal GB, MB

RC1
* All known bugs fixed as far as I can before 1.1
* Click very center to go up a dir
* Context menu gains copy to clipboard




LicenseGPL
Source(aa885e53e09f40e7fdd371395140b957)
other(i18n-20070422 -- 14b74c4e8095e5979cd9c02c6146ea0e)
Send to a friend
Subscribe
Other  Apps  from MxCl
Report inappropriate content



goto page: prev   1  2  3  4  5  6  7  8  9  10 

-
.

 Debian (Sid)

 
 by cado on: Feb 2 2005
 
Score 50%

Great Job. =)
Debian Unstable (Sid) available at http://download.codigolivre.org.br/pacotesdeb/filelight_1.0-beta6-1_i386.deb


Brazilian Team
Reply to this

-
.

 Suse 9.2 RPM build

 
 by linux3114a on: Feb 4 2005
 
Score 50%

filelight-1.0.beta6-suse92.i586.rpm at

http://home.tiscali.be/raoul.linux/download.htm

my participation ...


Raoul
Reply to this

-

 getmntent

 
 by oliverthered on: Feb 21 2005
 
Score 50%

Hi, you should be using getmntent to read the fstab.
it's much simpler than the code you currently have, and it meens that your application should work on and system that impments getmntent regardless of the format or location of fstab

man fstab notes....

The proper way to read records from fstab is to use the routines getmntent.


Reply to this

-
.

 Slack 10.1 package

 
 by franck on: Feb 24 2005
 
Score 50%

Hello!
I've build the package filelight-1.0beta6-i686-1fba.tgz for Slackware 10.1. Here where to download it:
http://franck.barbenoire.free.fr/download.php?id=95
Enjoy!


Reply to this

-

 performance+ notes

 
 by oliverthered on: Feb 26 2005
 
Score 50%

Hi,
I've found FileLight quite useful but very slow. If you want to replace KDiskFree I would suggest that you performance and memory tune FileLight, here are some suggestions that could increase performance and reduce memory all are reasoned all are costed (if the cost isn't the reason). If you don't know how to implement or are unsure of any of the algorithms then drop me message. Some of my suggestions my already be partly implemented via the 'cache' mechanism, if so they do not appear to be working for me.


all notes are against 1.0beta_6.
'make install
Making install in src
make[1]: Entering directory `/var/tmp/portage/filelight-1.0_beta6/work/filelight-1.0-beta6/src'

Make tree nodes as light as possible, if states only apply to a few nodes remove the states from the node and keep a separate list. (vtables partly count here so make sure you using static and non-virtual functions etc.. as appropriate)

Reasoning: The more of the tree that fits in memory,cpu cache the better. and there's no point storing needless information in nodes. Locating the state is a n for the number of states, not n for the number of nodes. Memory overhead is per state + 1 not per-node.
(Does Chain really need to be a double linked list? for every directory?)


Start by using a queue system to the next node, then a stack system when you get a number of nodes deep, This way you can generate the chart as you traverse the directory tree.

Reasoning: a queue will cause all directories in the current directory to be scanned next, a stack will causes the first then second descendants to be scanned, since the user wants to know about the 'current' node, all children of the current node should be scanned before any descendants. Using a queue will probably increase memory usage when compared to a stack.
(cost slight memory overhead + instant visual display vs reduced memory overhead, delayed visual display)

Make a simple version with no directory traversal for those people who just want a df, without hammering their server.

Reasoning: I just want a df, I don't want to wait ten minutes while my 1tb of data gets scanned turning my server into a lemon.
(cost a few inodes almost instant vs every inode on my fileing system)


When you traverse the nodes stack style consider aggregating the results.

Reasoning: unless a file some way down the file hierarchy is especially large there is no point in showing it so there is no point in storing a node for that file, just aggregate with the parent directory. (cost fixed memory vs n memory)


Use a weighted balanced tree to decide when to aggregate. (or calculations based on a weighted balanced tree).

Reasoning: this enables you to aggregate in an intelligent manner based on filesize, tree depth, tree width etc....
(cost is balanced tree with aggregation (=log2n ~= logn) as apposed to no aggregation n)

Deletes should run off of cache, or don't update the tree for a delete.

Reasoning: I'm deleting files, not updating the tree, let me delete in piece. A lazy update could run in the background, so long as it doesn't affect the user deleting. (cost is 1 delete vs 1 delete + n inode operations)



Only parse the aggregate node and it's children when a user "cd's" to the aggregate node or it's parent, don't recalculate the whole tree.

Reasoning: The user is obviously interested in the current node, even if the other nodes may be a few meg bigger/smaller don't bother updating unless the user asks. (maybe show an out-of-date Icon or something) (cost is 0, except an icon, vs n inode operations)

Don't delete parent nodes (from the internal tree) until you hit a memory limit, that way hitting back is a as near zero time operation (unless you've hit the memory limit, in which case sections of the tree will need reparsing).

Reasoning: The use may want to hit the back button (it is the most commonly used button apparently!), so don't clean out cache that could be used to generate an almost instant back. (cost is 1 memory look-up, and a fixed memory cost, vs n inode operations)

Make tree nodes as light as possible, if states only apply to a few nodes remove the states from the node and keep a separate list.

Reasoning, locating the state is a n for the number of states, not n for the number of nodes.
Memory overhead is per state + 1 not per-node.



Start by using a queue system to the next node, then a stack system when you get a number of nodes deep, This way you can generate the chart as you traverse the directory tree.

Reasoning: a queue will cause all directories in the current directory to be scanned next, a stack will causes the first then second descendants to be scanned, since the user wants to know about the 'current' node, all children of the current node should be scanned before any descendants. Using a queue will probably increase memory usage when compared to a stack.
(cost slight memory overhead + instant visual display vs reduced memory overhead, delayed visual display)

Make a simple version with no directory traversal for those people who just want a df, without hammering their server.

Reasoning: I just want a df, I don't want to wait ten minutes while my 1tb of data gets scanned turning my server into a lemon.
(cost a few inodes almost instant vs every inode on my fileing system)


When you traverse the nodes stack style consider aggregating the results.

Reasoning: unless a file some way down the file hierarchy is especially large there is no point in showing it so there is no point in storing a node for that file, just aggregate with the parent directory. (cost fixed memory vs n memory)


Use a weighted balanced tree to decide when to aggregate. (or calculations based on a weighted balanced tree).
Reasoning: this enables you to aggregate in an intelligent manner based on filesize, tree depth, tree width etc....
(cost is balanced tree with aggregation (=log2n ~= logn) as apposed to no aggregation n)

Deletes should run off of cache, or don't update the tree for a delete.

Reasoning: I'm deleting files, not updating the tree, let me delete in piece. A lazy update could run in the background, so long as it doesn't affect the user deleting. (cost is 1 delete vs 1 delete + n inode operations)



Only parse the aggregate node and it's children when a user "cd's" to the aggregate node or it's parent, don't recalculate the whole tree.

Reasoning: The user is obviously interested in the current node, even if the other nodes may be a few meg bigger/smaller don't bother updating unless the user asks. (maybe show an out-of-date Icon or something) (cost is 0, except an icon, vs n inode operations)

Don't delete parent nodes (from the internal tree) until you hit a memory limit, that way hitting back is a as near zero time operation (unless you've hit the memory limit, in which case sections of the tree will need reparsing).

Reasoning: The use may want to hit the back button (it is the most commonly used button apparently!), so don't clean out cache that could be used to generate an almost instant back. (cost is 1 memory look-up, and a fixed memory cost, vs n inode operations)


Only update the counter at the bottom right had side of the screen for every... (suggestion: directory entered or exited).

Reasoning: Writing text is surprisingly CPU intensive, the use can also read a value that changes 10times a second, but can't read one that changed 100times a second.(Cost, Moderately reduced CPU overhead, improved clarity reduced granularity vs improved granularity, greater CPU overhead, reduced clarity).


Two column view doesn't fit on my screen,the number of columns must be dynamic or one e.g. two lots of ...'
/net/bigdisk/films on /var/data/fake_windows/MySharedFolder/movies type none (rw,bind)' side by side won't fit 1280x1024.


Columns should be left (or right for some languages) aligned not centred.
Reason: I have to allign the columns in my head if they are centred, but not if they are left/right aligned. headings centred, lists aligned.

you MUST use getmntent to read the fstab if you want to replace KDiskFree, see 'man fstab' or http://www.rt.com/man/getmntent.3.html for more info.
Reason: fstab says, 'The proper way to read records from fstab is to use the routines getmntent(3)',
what if fstab is in digieridoo format?

I hope you implement some of my recommendations, they should help make your application business class.
Reason: What's good for the goose is good for the gander, why not make the best possibly application.


Reply to this

-

 Re: performance+ notes

 
 by MxCl on: Mar 21 2005
 
Score 50%

Oliver wrote to me by email. I'll be sure to implement all these suggestions as soon as possible, as they are first-class! Many thanks :)


Reply to this

-

 But...

 
 by MxCl on: May 11 2005
 
Score 50%

Although I might add, none of these will speed up scan times. That is already bottlenecked by disk access speeds.

If I can make it render while it scans it may feel faster, but it won't be any faster.


Reply to this

-

 build issues

 
 by HJH on: May 21 2005
 
Score 50%

I am unable to build this app. in MandrivaLinux 2005LE x86_64.
I get an error during the config about the program being unable to locate qt-mt
I am quite sure that libqt-mt.so does exist, so what's going wrong here?


Reply to this

-

 Re: build issues

 
 by HJH on: May 23 2005
 
Score 50%

The exact error:

checking for Qt... configure: error: Qt (>= Qt 3.3) (library qt-mt) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Make sure that you have compiled Qt with thread support!


While I did this with configure:
./configure --with-qt-library-dir=/usr/lib/qt3/lib64
--with-qt-dir=/usr/lib/qt3 --with-qt-includes=/usr/lib/qt3/include
--with-kde-library-dir=/usr/lib64/kde3


Reply to this

-

 Re: Re: build issues

 
 by HJH on: May 25 2005
 
Score 50%

The same "solution" that applied to codeine about libqt-mt, also works here.
However, when building this one, I get the following error message:

*** Warning: Linking the shared library libfilelight.la against the
*** static library ./radialMap/libradialmap.a is not portable!
/usr/bin/ld: ./radialMap/libradialmap.a(widget.o): relocation R_X86_64_32S against `vtable for RadialMap::Widget' can not be used when making a shared object; recompile with -fPIC
./radialMap/libradialmap.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libfilelight.la] Error 1
make[4]: Leaving directory `/home/hjheins/RPM/BUILD/filelight-1.0-beta6/src/part'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/hjheins/RPM/BUILD/filelight-1.0-beta6/src/part'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/hjheins/RPM/BUILD/filelight-1.0-beta6/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/hjheins/RPM/BUILD/filelight-1.0-beta6'
make: *** [all] Error 2


Could you shed some light on this?

Hendrik-Jan


Reply to this

-
.

 Re: Re: Re: build issues

 
 by avaurus on: Oct 8 2005
 
Score 50%

hi,
easy ;)

./configure --prefix=/opt/kde3 --libdir=/opt/kde3/lib64/ --with-qt-dir=/usr/lib/qt3 --with-qt-includes=/usr/lib/qt3/include --with-qt-libraries=/usr/lib/qt3/lib64 --enable-libsuffix=64 --with-pic --enable-shared=no --enable-static=yes

With this configure-line I got it compiling, but not running...argh.


Reply to this

goto page: prev   1  2  3  4  5  6  7  8  9  10 

Add commentBack






-
-
Do you like or dislike Ubuntu Unity?
 Yes, unity is alien technology!
 It is less confusing than Gnome 3 default, shell.
 Granny thinks it is much more usable than Gnome 2
 Canonical is embarrasing itself with this split project
 Gnome 3 default shell is much better
 I dislike Unity, Gnome 3 default shell is alien technology!
 None of the above, I like the 2Gb for free and Apple alike behavior. Will post a comment instead

resultmore
 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Facebook App
Content RSS   
Events RSS   

Participate
Groups
Forum
Add App
Public API
About KDE-Apps.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2003-2014 KDE-Apps.org Team  
All rights reserved. KDE-Apps.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
KDE and K Desktop Environment are trademarks of KDE e.V.