gwhere-discussion
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GWhere-discussion] todo - new GWhere feature


From: Jarkor
Subject: Re: [GWhere-discussion] todo - new GWhere feature
Date: Wed, 27 Aug 2003 22:49:38 -0300

Hi people in the discussion list.....


----- Original Message ----- 
From: "Zero - GWhere" <address@hidden>
To: <address@hidden>
Sent: Tuesday, August 26, 2003 9:27 PM
Subject: Re: [GWhere-discussion] todo - new GWhere feature


> Hi everybody,
>
>
> > I was going to post something about loading speed....so this came just
in
> > time..
> > Actually I'm adding Cd's to the catalog and got only 50 scanned, and it
> > takes about 15 seconds  to load the whole database on my P3 550MHz.
> > It's not too much for now anyway, but....I got over 1000 CD's.....and
> > imagine what would be that to load everything.........Let me take the
> > calculator....
> > ;-)
> Yes, I'm very conscious about this problem. That's why the 0.2.x
> versions are very important for me to fix this above trouble.
It's ok, I'll be patient waiting for new versions coming. Anyway, the
program
runs without any problem...that's very important too.

>
>
> > Also I note that it takes about between 30 and 40 Mb of ram when
> > everything is loaded......It's that possible?
> Did you use GWhere in debug mode?? Launch GWhere with the following
> command line and check the contents of the gwhere.log file in order to
> know if GWhere is in debug mode. So if it is in debug mode it can use
> lot of memories as you say :
> gwhere.exe > gwhere.log
I ran it as you note, the log file is generated and always empty but when I
enter
Options and I leave (changing nothing) it's 144 bytes long containing:

(gwhere.exe:600): Gtk-CRITICAL **: file gtkwidget.c: line 3186
(gtk_widget_grab_default): assertion `GTK_WIDGET_CAN_DEFAULT (widget)'
failed

That's using the lastest win32 version.
Anyway, I make a mistake in the post about memory loads. I post that with my
bigger catalog file loaded. I run some test again and the program itself
without
any db loaded, takes about 3400~3500 KBytes. Loading a catalog file wich
size is 684479 bytes long, takes 7880KB more and loading a big one, 2037089
bytes long catalog file takes 34228KB more of ram. (Measured under win2k pro
with mem usage under Windows Task Manager (I know is not the best method,
but to have an idea).)


>
>
> > I think loading the catalog in background or just do a partial display
while
> > loading will be great. (display Main tree only, for example).
> > Maybe with a message in the status bar "loading" or something like that
> > will help too, while loading everything.
> in fact the next generation of catalog file will use a binary format in
> order to be smaller. And it will never be completely loaded.
That's great :-)

>
>
> > MDI or some kind of tree organization of catalogs by categories will be
> > great too.
> Yes.
>
>
> > About dynamic fields.....that would be a nice feature too...
> Very nice and very hard to define their limits...
:-S


>
>
> > Ok, that my opinion only, go ahead with this excellent project.
> Thank you, I try. :-)
You do it very well....... :-D

Jarkor.

>
>
> Yours,
> Zero
>
>
> > regards,
> > Jarkor
> >
> > ----- Original Message -----
> > From: "Zero - GWhere" <address@hidden>
> > To: <address@hidden>
> > Sent: Wednesday, August 20, 2003 3:16 PM
> > Subject: Re: [GWhere-discussion] todo - new GWhere feature
> >
> > > Hi list,
> > >
> > >
> > > I post a discussion between Thomas and me :
> > > ===========================================
> > > <discussion>
> > > [Zero] I see two goals for GWhere :
> > > - To not load all datas when the user open a catalog. With this way
the
> > > loading of catalog will be quicker. It is not really visible for users
> > > but it is very important.
> > >
> > > [Thomas] Yes, it will speed up startup and they can be loaded during
> > > searching. Did you thinked about indexing data and/or implement
database
> > > backedn for storing data like MySQL ? It will boost speed even with
> > > tousands of CDs.
> > >
> > >
> > > [Zero] - Support a MDI-like feature. MDI is Multi Document Interface.
In
> > > fact when you ask to allow tree organization of disks, you want to
open
> > > severals catalogs in a same time. One catalog may be "My music",
another
> > > "My distributions", another "Videos", and more... Over it, we can
> > > implement a file format which make links between a tree organization
and
> > > catalogs.
> > >
> > > [Thomas] Yes, we talked about this linking file-type (I will call it
> > > master file - MF) yet. User can make trees management in it without
> > > having to open any of catalogs.
> > >
> > >
> > > [Zero] Dynamics fields are very import for the next generation of
> > > cataloguer. At time, some users have too much information in GWhere.
And
> > > others users don't have enought information. The best way (I think) is
> > > to make the majority of fields dynamics, and to allow users to choose
> > > which fields are needed.
> > >
> > > [Thomas] I think we can lat user not only to choose from group of
> > > parameters, but also to define their own (flags, locations,...) - he
> > > will define its type (string, integer,...) and MF will containt these,
> > > so after opening it, user will see all field in which he can search,
> > > including/excluding nil values where some of catalogs does not have
> > > field.
> > > You can do two MF formats - first will be one MF and some number of
> > > files and second one single file, in fact .tar.gz(bz2)iped first
version
> > > - this way it will be simple to manage if user have more catalogs. It
> > > will do little problem with adressing catalog inside this compressed
> > > master file (CMF), but you can use something like
> > > :bzip2:/home/user/catalog.cmf:trance.ctg
> > > </discussion>
> > >
> > >
> > > Yours,
> > > Zero
> > >
> > >
> > > Zero - GWhere wrote:
> > > >
> > > > Hi Thomas and all,
> > > >
> > > > > > Someone should imagine a CD catalogiser, that can maintain where
are
> > the CD-s too.
> > > > > > Where contains places and persons. For example "Jimmi Hendrix"
> > labelled CD's original storage place is at "father's room", but actually
it
> > is borrowed by "Father's friend - phone number".
> > > > > >
> > > > > > I hope it was clear. What do you think about it?
> > > > > >
> > > > > > yours,
> > > > > > Laci
> > > > > >
> > > > >
> > > > > I sent Zero some of my wishies, this was one of them, so he knows.
> > > >
> > > > Yes, it is rigth, ;-)
> > > >
> > > > > I suggest these atributes to Item in catalog - category (linux,
> > mp3,...), flag (damaged, personal) and location (home, red pen,
girlfriend's
> > brother). Together with them next thing, that will allow tree-like view
to
> > database - so i might not have only one big (and over 200CD's is big,
trust
> > me :) root tree, but more these. It is not same as category - Jimmi
Hendrix
> > and Jan Hammer ar both mp3 (or audio) CDs, but they belong to another
> > category - different music types. I can solve it by having music-techno,
> > music-celtic,... category or put them in another tree.
> > > > >
> > > > > Example of this:
> > > > >
> > > > > root
> > > > > *
> > > > > * music  * celtic *
> > > > > *          *        * Enya - May it Be (category: mp3; flags:
> > poor-quality, damagen; location: home)
> > > > > *          *        *         - Shadow of the Moon (category:
audio;
> > flags: excelent ; location: girlfriend)
> > > > > *          *        *
> > > > > *          *        * Mike Oldfield - Tubular 1 (category: audio;
> > flags: do-not-give-away; location: hostel)
> > > > > *          *                          - Tubular 2 (category:
audio;
> > flags: do-not-give-away; location: hostel)
> > > > > *          * trance - ps{}trance-cd1 (category: mp3; flags: mix;
> > location: thomas)
> > > > > *                      - ps{}trance-cd2 (category: mp3; flags:
mix;
> > location: thomas)
> > > > > * linux * mandrake - mdk9.1-cd1 (category: linux; flags: iso;
> > location: installfest)
> > > > >          *                - mdk9.1-cd2 (category: linux; flags:
iso;
> > location: installfest)
> > > > >          *                - mdk9.1-cd3 (category: linux; flags:
iso;
> > location: installfest)
> > > > >          * slackware - slackware-9.0-current (category: linux;
flags:
> > my-own-made, life-love; location: bed)
> > > > >
> > > > > This way, I have stored all important informations and still se
only
> > about 10 categories until I "open" them. For example, look at WhereIsIt
> > software for win32.
> > > > > I know that groups music, linux are almost same as category (mp3,
> > linux), but when you have loot of CDs, you will use them. Until then,
you
> > can checkbox that category should by same as group.
> > > > >
> > > > > The tree-like view might be implemented trought another filetype,
that
> > will only save names of catalogs (like there are now) itselfs and open
all
> > of them in tree view. But including flags and locations will still
change
> > fileformat, so why not implement trees in them at once ?
> > > >
> > > > You request to implement tree organization for catagories?? I'm
working
> > on the next file format and the categories will organizated by trees...
> > > >
> > > > Yours,
> > > > Zero
> > > >
> > > > _______________________________________________
> > > > GWhere-discussion mailing list
> > > > address@hidden
> > > > http://mail.nongnu.org/mailman/listinfo/gwhere-discussion
> > >
> > > --
> > > Best regards,
> > >
> > > Zero
> > > Maintainer,
> > >
> > > GWhere - Another way to manage your catalogs!!
> > > http://www.gwhere.org
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > GWhere-discussion mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/gwhere-discussion
> > >
>
> -- 
> Best regards,
>
> Zero
> Maintainer,
>
> GWhere - Another way to manage your catalogs!!
> http://www.gwhere.org
>
>
>
>
> _______________________________________________
> GWhere-discussion mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gwhere-discussion
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]