Branches
Comments
[»]
GTKatalog problem?
by someone - Oct 18th 2005 13:46:22
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?
[reply]
[top]
[»]
Feature / bugfix requests
by Chaotic Thought - Feb 21st 2003 10:49:57
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.
[reply]
[top]
[»]
Very good but slow
by linuxmatt - Oct 21st 2002 03:46:51
(Sorry for my poor english, I am French :))
Thank you very much for this wonderful piece of software. It is very
useful to me.
But...
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!
Best regards,
Matt
[reply]
[top]
[»]
Is "Speed Improvement" going to be on the TODO list anytime soon?
by timecop - May 31st 2001 03:57:46
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.
[reply]
[top]
[»]
Re: Is "Speed Improvement" going to be on the TODO list anytime soon?
by dino - Jun 9th 2001 00:05:03
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.
[reply]
[top]
[»]
Re: Is "Speed Improvement" going to be on the TODO list anytime soon?
by timecop - Jun 9th 2001 14:50:22
>
> 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.
[reply]
[top]
[»]
Thanks Yves, GTKtalog really helps me
by Pablo Fernández - Jan 31st 2001 18:54:56
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.
[reply]
[top]
|
