From erwin at herow-international.com Mon May 11 08:28:00 2009 From: erwin at herow-international.com (erwin at herow-international.com) Date: Mon, 11 May 2009 14:28:00 +0200 Subject: [Alexandria-list] Palatina SBN ??? Advanced Settings glitch ??? Message-ID: <4A0819D0.9050801@herow-international.com> Hello All, Cathal you mentioned the GIT thing for using SBN. I downloaded it from the palatina page but seemingly it does not get integrated with Alexandria. Or at least I can not add a book using SBN code. (Tried it with 425-02123-8 which is the SBN code for The valley of fear, by Air Arthur Conan Doyle) Also I can not get into the Advanced Settings. I installed latest version of Yaz. Installed latest version of Zoom. "wget http://rubyforge.org/download.php/22653/zoom-0.4.1.gem" next "apt-get install rubygems1.9" 1.9 was the latest version according to the terminal. However I can not find any marc gem anywhere to install or to download. Neither a shutdown of Alexandria or a reboot of the computer seems to solve the fact that I can not get into the Advanced Settings. This is absolutely required for me, because I need at least Polish/Dutch/Hungarian ISBN providers in the system. I hope someone can come up with help. Erwin Roos From atenrok at gmail.com Thu May 21 15:43:20 2009 From: atenrok at gmail.com (atenrok) Date: Thu, 21 May 2009 12:43:20 -0700 (PDT) Subject: [Alexandria-list] alexandria and ebboks? Message-ID: <23659249.post@talk.nabble.com> hello, Having quite substantial number of electronic books on my harddrive, I've been looking fro some kind of ebook manager for linux, but so far did not find anything that would suit me (not surprising, considering there are only two projects of that kind available for linux now: eKitaab and calibre). I found alexandria instead, which appears to be a book library manager and it does all I need, except it is for another kinds of books. I'm not sure uhm... how does this correlate with the author's roadmap, but it is probably not too difficult to add another couple records to the properties of the book in the database, which would hold a path to the local file and the checksum. This would make alexandria a nice ebook manager. And when I'm saying "not too difficult" I don't mean myself, because I'm ruby-illiterate, but for somebody who knows stuff? Or maybe this topic has been discussed around here already? -- View this message in context: http://www.nabble.com/alexandria-and-ebboks--tp23659249p23659249.html Sent from the Gnome - Alexandria mailing list archive at Nabble.com. From cathal.alexandria at gnostai.org Thu May 21 20:48:25 2009 From: cathal.alexandria at gnostai.org (Cathal Mc Ginley) Date: Fri, 22 May 2009 01:48:25 +0100 Subject: [Alexandria-list] alexandria and ebboks? In-Reply-To: <23659249.post@talk.nabble.com> References: <23659249.post@talk.nabble.com> Message-ID: <20090522014825.366d003e@kate> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adding support for cataloguing e-books has been discussed before, but no real progress has been made on the topic. As I've been saying a lot recently, adding e-book support directly to Alexandria is not going to happen soon - the code would need substantial redesign to support such a change. However, substantial *new* design is happening independently of the main Alexandria project. I have allowed for the possibility of e-books in the design of Palatina (the not-even-remotely-ready-for-users Alexandria replacement). So any feedback you can give would be helpful in shaping the code which will eventually (i.e. months from now) be wrapped back into Alexandria. The properties you mention for e-books are: * file path * checksum I can also immediately think of: * file format (e.g. PRC, PDF, FB2...) * file size * URL (if the e-book is available online) * DOI (Digital Object Identifier - akin to ISBN for electronic documents) I've already updated the Palatina wiki with your suggestions: http://palatina.gnostai.org/wiki/BookDataRequirements Are there any other properties that would be particularly useful? Should the Alexandria GUI have any extra features or behaviour to support useful handling of electronic texts? - Cathal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE iEYEARECAAYFAkoV9lkACgkQfMAUnRdb+8rabgCgyT7NGOX/t4dzR10beRyEmt+b 9TQAmgL47nCQ8451Ed9Jgv6u8i+xH8Td =lUzc -----END PGP SIGNATURE----- From atenrok at gmail.com Fri May 22 09:27:29 2009 From: atenrok at gmail.com (atenrok) Date: Fri, 22 May 2009 06:27:29 -0700 (PDT) Subject: [Alexandria-list] alexandria and ebboks? In-Reply-To: <20090522014825.366d003e@kate> References: <23659249.post@talk.nabble.com> <20090522014825.366d003e@kate> Message-ID: <23670470.post@talk.nabble.com> Cathal, Cathal Mc Ginley wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Adding support for cataloguing e-books has been discussed before, but > no real progress has been made on the topic. > > As I've been saying a lot recently, adding e-book support directly to > Alexandria is not going to happen soon - the code would need > substantial redesign to support such a change. > > However, substantial *new* design is happening independently of the > main Alexandria project. I have allowed for the possibility of e-books > in the design of Palatina (the not-even-remotely-ready-for-users > Alexandria replacement). So any feedback you can give would be helpful > in shaping the code which will eventually (i.e. months from now) be > wrapped back into Alexandria. > I'm really happy to read this, especially realizing that you care about potential user suggestions before implementing the features. Cathal Mc Ginley wrote: > > The properties you mention for e-books are: > * file path > yes. And the main issue here is that the library manager application should not try change the location of the file. You can allow yourself to rename the file to some kind of comprehensive name (like author-year-isbn, or whatever you come up with) but if the user has its files arranged into some kind of catalog structure -- that should be intact. I emphasize that because the author of calibe, mentioned above, decided that application should organize the files for the user. > * checksum > this one, obviously should be used to keep track of duplicates and fixing the database of the path to the file was changed outside out alexandria. > I can also immediately think of: > * file format (e.g. PRC, PDF, FB2...) > * file size > * URL (if the e-book is available online) > * DOI (Digital Object Identifier - akin to ISBN for electronic > documents) > very nice, taking into account that tags, notes and rating is implemented in alexandria, this pretty much makes the list complete. The suggestion here would be to implement different icons for corresponding formats, so these are easily identifiable in the list. Although, if you add the column indicating the file format, then the icons are obsolete to my mind. Also here is the question, is the "genre" field useful or should user rely on tags? > Are there any other properties that would be particularly useful? > Should the Alexandria GUI have any extra features or behaviour to > support useful handling of electronic texts? > when it comes to handling, these days linux pretty much has all the applications needed to handle most of the formats available on the market. In case there's no reader available -- there is always a converter. Since not all of these are defined in mime-types you probably should let the user choose the corresponding reader for every file-format somewhere in the preferences dialog. Possibility to rescan the library (the directory with ebooks) in case the user has added some new books. In case the new books are detected, al offered to be added to the database (ask the user to fill the record information). There should be way to initiate the "rescan" manually, as well as schedule the interval for it. I don't particularly care about the next one, but I suspect that some users might request these later, so you might start thinking about that ahead of time. 1. format convertors, perhaps you should think about interface to specify those the same way as the readers. 2. support for various kinds of hardware ebook readers. Since you cant own them all, I would suggest implementing a plugin interface and let somebody else write corresponding plugins. good luck, and keep up a nice job -- View this message in context: http://www.nabble.com/alexandria-and-ebboks--tp23659249p23670470.html Sent from the Gnome - Alexandria mailing list archive at Nabble.com. From atenrok at gmail.com Fri May 22 09:29:09 2009 From: atenrok at gmail.com (atenrok) Date: Fri, 22 May 2009 06:29:09 -0700 (PDT) Subject: [Alexandria-list] alexandria and ebboks? Message-ID: <23670470.post@talk.nabble.com> Cathal, Cathal Mc Ginley wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Adding support for cataloguing e-books has been discussed before, but > no real progress has been made on the topic. > > As I've been saying a lot recently, adding e-book support directly to > Alexandria is not going to happen soon - the code would need > substantial redesign to support such a change. > > However, substantial *new* design is happening independently of the > main Alexandria project. I have allowed for the possibility of e-books > in the design of Palatina (the not-even-remotely-ready-for-users > Alexandria replacement). So any feedback you can give would be helpful > in shaping the code which will eventually (i.e. months from now) be > wrapped back into Alexandria. > I'm really happy to read this, especially realizing that you care about potential user suggestions before implementing the features. Cathal Mc Ginley wrote: > > The properties you mention for e-books are: > * file path > yes. And the main issue here is that the library manager application should not try change the location of the file. You can allow yourself to rename the file to some kind of comprehensive name (like author-year-isbn, or whatever you come up with) but if the user has its files arranged into some kind of catalog structure -- that should be intact. I emphasize that because the author of calibe, mentioned above, decided that application should organize the files for the user. > * checksum > this one, obviously should be used to keep track of duplicates and fixing the database of the path to the file was changed outside out alexandria. > I can also immediately think of: > * file format (e.g. PRC, PDF, FB2...) > * file size > * URL (if the e-book is available online) > * DOI (Digital Object Identifier - akin to ISBN for electronic > documents) > very nice, taking into account that tags, notes and rating is implemented in alexandria, this pretty much makes the list complete. The suggestion here would be to implement different icons for corresponding formats, so these are easily identifiable in the list. Although, if you add the column indicating the file format, then the icons are obsolete to my mind. Also here is the question, is the "genre" field useful or should user rely on tags? > Are there any other properties that would be particularly useful? > Should the Alexandria GUI have any extra features or behaviour to > support useful handling of electronic texts? > when it comes to handling, these days linux pretty much has all the applications needed to handle most of the formats available on the market. In case there's no reader available -- there is always a converter. Since not all of these are defined in mime-types you probably should let the user choose the corresponding reader for every file-format somewhere in the preferences dialog. Possibility to rescan the library (the directory with ebooks) in case the user has added some new books. In case the new book is detected, it is offered to be added to the database (ask the user to fill the record information). There should be way to initiate the "rescan" manually, as well as schedule the interval for it. I don't particularly care about the next one, but I suspect that some users might request these later, so you might start thinking about that ahead of time. 1. format convertors, perhaps you should think about interface to specify those the same way as the readers. 2. support for various kinds of hardware ebook readers. Since you cant own them all, I would suggest implementing a plugin interface and let somebody else write corresponding plugins. good luck, and keep up a nice job -- View this message in context: http://www.nabble.com/alexandria-and-ebboks--tp23659249p23670470.html Sent from the Gnome - Alexandria mailing list archive at Nabble.com.