Sorry for my English. I tried to use GTKatalog, but is a
problem: If I try to add a CD which has an empty
volume label, I receive an Segmentation Fault error (in
terminal) and GTKatalog ends, of course. I tried on
Fedora, Mandriva, SuSE, RedHat and on different
hardware configurations. Where am I wrong?
Feature / bugfix requests
This is a useful program. However, I'm hesitant to use it on a large scale basis because the File Descriptions are destroyed after Updating the database: even if you choose update and all the filenames / sizes remain the same. I would like to use this to maintain a large (dynamic) database of files, and the ability to give each file a unique description is essential.
My other complaints are the rudimentary (nonexistent) keyboard support that exists in many GTK applications, (There is no way to perform all operations using a keyboard only) and the lack of support for multiple CDROM drives. My system has two cdrom drives, so I would appreciate the program's ability to detect or give the user a choice of which CDROM to add upon picking the "Add CD" button.
Very good but slow
(Sorry for my poor english, I am French :))
Thank you very much for this wonderful piece of software. It is very useful to me.
I work on a K6-200Mhz machine and when the catalog file grows over a few megabytes, gtktalog goes slower and slower... After only a dozen of CDROMs of Linux distributions (with thousands of RPMS, I agree), the program becomes too slow to be usable.
Looking at the source code, I remarked that:
- The (Gnome) GUI code is mixed with the core processing code. I don't think that it is the best design for such a program and the code is not easy to understand.
- There should be a way to save the catalog into a MySQL database to speed up the whole application. By doing this, the catalog can grow bigger and bigger without decreasing the overall performance.
Keep up the good work!
Re: Is "Speed Improvement" going to be on the TODO list anytime soon?
> What a useless comment. Since your dishing out
> suggestions on a project that you are not pleased
> with, I would suggest that you use a different CD
> cataloging program. Or write your own if you can.
And that's what I did, since GTKtalog people don't
seem to care about how slow their software is.
By the way, who uses a GNode without actually
storing a tree structure in it?
After spending a few minutes looking over GTKtalog
source code, I must say its rather messy.
What a useless comment. Since your dishing out
suggestions on a project that you are not pleased
with, I would suggest that you use a different CD
cataloging program. Or write your own if you can.
Is "Speed Improvement" going to be on the TODO list anytime soon?
I realize all the devlopers have Pentium III
900Mhz computers and only catalog 20 files but get
real, this thing is totally freaking slow.
Somewhere between 0.13 and 0.16 this software
became unusable slow. Why was the "progress
scrollbar" added for the loading process? Instead
of making a long process look shorter by adding a
frame of reference why not debug the loading
proces and make it FASTER? Wow, what a concept. I
suggest the coders stop adding useless features
(enough of these already), and start optimizing
code, or better yet rewriting it to suck less.
Thanks Yves, GTKtalog really helps me
This program is really cool, I have tons of CDs and sometimes I need a single file and I have to start looking at all of my CDs looking for it, sometimes hours looking!
With GTKtalog I have a DB of all my CDs I can search on them without even mounting!
Again, thanks Yves.
A fast, versatile, compatible browser.
A CORBA C++ ORB.