- Koha-devel - lists.koha-community.org

Unicode in Guided Reports
by Marcel de Rooy 22 Feb '10

22 Feb '10

Hi all, I stumbled across some garbled characters in Koha 3.0.3 Guided reports, although we use UTF-8 'everywhere'. Looking further, I noticed the line binmode STDOUT, ':utf8'; in guided_reports.pl (line 341). Since the script is not working here on a binary file, this does not seem appropriate. If I comment this line, the problem is resolved. I did not find a bug on this topic on Bugzilla however. Did anyone of you come across this problem before? Regards, Marcel

1 0

Koha Sound Events
by Darrell Ulm 22 Feb '10

22 Feb '10

Hello, Working on putting sound events into Koha 3.2 but it is a bit of a pickle. While I have it working using <embed (embed is the problem, works to a point, but please read below) ... <embed is not the solution for playing the sound My question is *what is?*. Currently the two best candidates are playing with a Java Applet (works very well and loads concurrently so no delay) or Flash, which I have not tested. Basically to get decent sound, we are going to need a plug-in, because web browsers just don't cut it for playing sound in a fast environment.  <script type="text/javascript" language="javascript"> if ( get_cookie( "kohastaffsound" ) == "yes" ) { document.write('Sounding...'); document.write('<embed src="/intranet-tmpl/prog/sound/beep.wav" hidden autostart="true" loop="false" />'); } </script>  in Circulation.tmpl along with a cookie (kohastaffsound) controlled audio on and off (note the syspref "soundon" also) which is set by a toggle button in header.inc (may not be the best place) <script type="text/javascript" language="javascript"> if ( get_cookie( "kohastaffsound" ) == "yes" ) { document.write('<img src="/intranet-tmpl/prog/img/famfamfam/silk/sound.png" onClick=\'delete_cookie ( "kohastaffsound" ); window.location.reload();\' >'); } else { document.write('<img src="/intranet-tmpl/prog/img/famfamfam/silk/sound_mute.png" onClick=\'set_cookie( "kohastaffsound", "yes", 2020, 01, 01 ); window.location.reload();\' >'); } </script> That is about it, which is fine, except the silly <EMBED is weird and flashes the screen as well as slows everything down. I think if I aim for a very small audio file this could be improved, however, there is a delay with the <embed. With <Embed we have * Firefox 3.6 there is a delay and an entire screen refresh, but works the best. * Chrome 4 there is a delay, then the sound plays late, and it even messes up the formatting * IE8 - worked great- loads quick - , but not so with Firefox which is a must * Opera - Worked the best, very quick load on Circ, but other things did not, unrelated the sound changes It seems one way to get around this is to NOT use Embed, and instead use Java with a class (open source of course) to handle playing a sound on demand. Has anyone else thought about this or experimented. The issue is mainly with the browsers and the lack of support for sound. Using straight javascript to play the sound works worse than embed across the browsers, which is probably why Jquery doesn't have a good sound plug-in. I think the reason sound is important, is so at the *end* of a transaction (check-in / out) there is a beep, to speed up these tasks. Also, when there is an exception on a book (missing barcode) there should be an audible warning. These are often missed, because Koha does not have sound cues, and other ILS systems do. What do you all think? Darrell Ulm _______________________________________________ Koha-devel mailing list Koha-devel(a)nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel

8 25

Koha Perl Dependencies PPA
by Braedon Vickers 21 Feb '10

21 Feb '10

Hello all, After installing assorted versions of Koha on Ubuntu numerous times over the last few weeks, one of the major speedbumps I always seemed to have was retrieving the Perl dependencies not in the standard Ubuntu repositories from CPAN. After it was suggested to me on #koha, I put together a PPA to serve these as Debian packages instead. Unfortunately, prior to this I had no experience with Debian packaging, and didn't really have the time to learn properly, so the packages I have build are generated by "dh-make-perl" (a very handy tool), with a few minor changes to fix dependency generation errors. As such, two requests. Firstly, to anyone who runs Koha on Ubuntu9.10, some testing of the packages would be great of you could spare the time. Secondly, to anyone with any experience with Debian packaging, if you would like to provide advice, or even take over this project, it would be greatly appreciated. The PPA can be found here: https://launchpad.net/~braedon-vickers/+archive/kohaperl The packages are all the required CPAN Perl modules for git HEAD Koha as of the 17th of February. Braedon Vickers -- TechnologyWise Ltd, Tauranga, NZ braedon(a)tw.co.nz www.technologywise.co.nz ph: +64 (0)7 571 1060 fax: +64 (0)7 571 1061

2 1

Kids catalog interest?
by David Schuster 18 Feb '10

18 Feb '10

I've been in contact with some Evergreen folks that are going to start working on developing a Kids Catalog type interface that will be targeted toward k-3 grade students to use. Similar to the old Carl catalog I suspect, but they are starting from scratch. If others are interested in this type of interface please reply to this post so we can judge interest and the possibility of collaborative development. I believe they have an IMLS grant that is helping to pay for some of the development. http://biblio-os.blogspot.com/2010/02/kids-catalog-project-gets-underway.ht… - blog post from Amy Terlaga example of TLC's - kids catalog: http://starship.snap.lib.ca.us/remote/servlet/kcHome example of III? http://vulcan.bham.lib.al.us:90/ I figure if nothing else we might be able to share the icon development and not the searching or??? -- View this message in context: http://old.nabble.com/Kids-catalog-interest--tp27608875p27608875.html Sent from the Koha - Dev mailing list archive at Nabble.com.

2 1

Koha sessions table is ridiculously huge
by Walls, Ian 18 Feb '10

18 Feb '10

Developers, After performing a software upgrade and server reboot, I came across this problem. My koha.sessions table is over 13 million entries. This seems to indicate that entries into the table were never removed, and that may help to explain why my backup mysqldumps are increasing by around 4MB daily. Chris Cormack suggested that I do a mysqldump of sessions with the no-data option set, then reimport it into the database to clear it out. I've finally gotten sessions to tell me what indexes it has on it, so that can be recreated as well. Are there any risks to doing this that I'm not factoring in? More generally, what could be causing my sessions table to get so out of hand? Permissions, perhaps? Something in the code being off? Any ideas or feedback would be appreciated. Thanks! Ian Walls Systems Integration Librarian NYU Health Sciences Libraries 550 First Ave., New York, NY 10016 (212) 263-8687 </PRE> <html> <body> ------------------------------------------------------------<br /> This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.<br /> ================================= </body> </html> <PRE>

9 17

How about a different way of handling database updates
by Michael Hafen 17 Feb '10

17 Feb '10

Database updates using the updatedatabase.pl script. I'm thinking there could be a better way, both for developers and the release maintainers. The problem is that we have a sequential number controlling the updates. This is working now, but I think there could be a better way. The current method is simple, it has that benefit. On the other hand it makes things more complex for the release maintainer to make sure the sequence is right. It's also more complex for the developers to coordinate who will use what number. My idea is to use a string for the update instead of a number. It will mean adding a table to the database to track update strings that have been applied. This way each developer, or company, uses their own string to distinguish updates. Also, in order to keep the table from being huge, the release maintainer will occasionally announce a database revision. We will keep the number to effectively federate the updates. Within each revision there will be any number of update strings. With each new revision it is assumed that the updates from the previous version are applied, so the database table is emptied. There will be some added complexity when when there is a revision. The developers who are working on update code will have to move their in the updatedatabase.pl file into the section for the new revision. The added benefit of this method is that developers, and companies, can have a database update easily without worrying about it getting into the official code repositories. The change is kept in the developers own branch, with it's unique update string, while others that are accepted into the official code are also there. Does that make sense? Have I described it well enough? Is anyone interested in this idea? I've been thinking about it, and the changes to the database update process should be minimal. There will be significant changes, but not many of them. There will have to be a sub added to check if an update string is in the database. And a sub to add the update string to the tracking table in the database. And the revision update sub will have to be expanded to empty that table. I think that would be the extent of the changes. Comments please. -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha

11 26

koha 3.0.5 + print slip problem
by Zico 17 Feb '10

17 Feb '10

Hi, i have been trying to print slip from Koha 3.0.5. I am using Star TSP650. But, when the print occurs, it takes a 11.5 inch/A4 size slip; whereas the datas are very little there in that page. I tried to find the page setup from Firefox; but it hasn`t change anything. -- Best, Zico

3 3

Change requested: XSLT syspref changes in 3.0.x
by Galen Charlton 17 Feb '10

17 Feb '10

Hi, I would like to request that the following 3.0.x commits be reverted or modified before the release of 3.0.6. 4b04de209aa25816f5d97c05ce71ea9619027484 3057a7afb98c9224d3fd987131ae88956eb513d3 The upshot of these changes are that XSLTDetailsDisplay and XSLTResultsDisplay were changed from a Boolean to a free text field containing the full path to the desired XSLT stylesheets. Unfortunately, this has a defect that I would really prefer not get propagated, and I would not have accepted this change for HEAD as is. Specifically, unlike every other syspref that specifies an override of a template or CSS file, the proposed change requires the operator to know and enter the server path of the stylesheet, *including* the language directory (assuming that the operator is specifying a local stylesheet). For example: ../koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACDetail.xsl Besides forcing the operator to get the path right (and OPAC results and/or details display breaks if the operator gets it wrong), which no other syspref requires, it prevents a multi-lingual OPAC from being able to use a different stylesheet for each translation it uses. Local template and XSL files referred to by a syspreef should always be presented to the operator relative to the translation, i.e., a plain 'MARC21slim2OPACDetail.xsl' instead of '../koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACDetail.xsl', with code to select the appropriate translation. Furthermore, it should degrade more gracefully if the XSLT file specified in the syspref doesn't exist. In the short term, I would like to see one of the following happen: [1] The changes get reverted in 3.0.x, leaving the sysprefs as Boolean and allowing this enhancement to be dealt with in HEAD for 3.2. [2] The changes get improved so that there is a fallback and the syspref will respect the translation system. Regards, Galen -- Galen Charlton Koha 3.2 Release Manager gmcharlt(a)gmail.com

1 0

Measuring Koha resource usage
by Charl 17 Feb '10

17 Feb '10

Is there a specific tool available to check/record Koha's usage on a server? If not, which processes should be checked/measured? Thanks

1 0

Hourly loans
by Oscar Gaona 17 Feb '10

17 Feb '10

Hi, again We need to establish a hourly loans policy running Koha. I know it is a piece of the plan for Koha 2, but I ask: is it possible to reconfigure any stable version for doing that rule. Thanks for any idea. Regards. Oscar.

2 1