Re: [Koha] Google Chrome
Hi Lola, Yes we use Google Chrome because it is so much faster than firefox at issues and returns. We do though have problems with printing that has to be sorted out. Returns: Chrome interface does not 'show' reserves when items are being checked in so it is critical to have the volumne turned on that that the audio alerts can be clearly heard (so that the reserves are caught). Chrome will not print the slips either, aso we put the reserves in a pile and check them in again in Firefox during quiet moments so we can get the slips out. Clunky - yes - but it works and is worth doing for the big speed increases we gain in checking items in using Chrome. Issues: we use Chrome because it is faster but I have a feeling we have done something cutre with the printer to get the slipos printing out ie networking them somehow. I will have to investigate and get back to you. The biggest headache I have wiuth 3.2 is around printing and I would love to help get this issue strealined and problem free. Cheers Jo. On , Lola McKee <lmckee@salpublib.org> wrote:
Is anyone out there using google chrome for Koha? If so what printers are you using and are you having any trouble printing slips in google chrome? -- Thanks,
Lola McKee
Tech Systems Specialist Salina Public Library
785-825-4624 Ext. 239
Jo and Lola, You should report your Chrome issues at bugs.koha-community.org so that those developers who have Chrome can look into them. Chrome wasn't around when Koha was first written - and it wasn't used much when 3.0 was released, so it's just something we have to start paying attention to now :) Nicole You should report your iss 2010/8/14 <hfields19@gmail.com>:
Hi Lola,
Yes we use Google Chrome because it is so much faster than firefox at issues and returns. We do though have problems with printing that has to be sorted out.
Returns: Chrome interface does not 'show' reserves when items are being checked in so it is critical to have the volumne turned on that that the audio alerts can be clearly heard (so that the reserves are caught). Chrome will not print the slips either, aso we put the reserves in a pile and check them in again in Firefox during quiet moments so we can get the slips out. Clunky - yes - but it works and is worth doing for the big speed increases we gain in checking items in using Chrome.
Issues: we use Chrome because it is faster but I have a feeling we have done something cutre with the printer to get the slipos printing out ie networking them somehow. I will have to investigate and get back to you.
The biggest headache I have wiuth 3.2 is around printing and I would love to help get this issue strealined and problem free.
Cheers Jo.
On , Lola McKee <lmckee@salpublib.org> wrote:
Is anyone out there using google chrome for Koha? If so what printers are you using and are you having any trouble printing slips in google chrome? -- Thanks,
Lola McKee
Tech Systems Specialist Salina Public Library
785-825-4624 Ext. 239
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Nicole Engard wrote:
You should report your Chrome issues at bugs.koha-community.org so that those developers who have Chrome can look into them. Chrome wasn't around when Koha was first written - and it wasn't used much when 3.0 was released, so it's just something we have to start paying attention to now :)
If Chrome is outperforming Firefox because of something in Koha, then I feel that's a bug in Koha which should be fixed. We really shouldn't be helping people to escape the library monoliths and then driving people away from software freedom into the arms of Google. :-( Regards, -- MJ Ray (slef) Webmaster and developer for hire at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On 23 August 2010 19:54, MJ Ray <mjr@phonecoop.coop> wrote:
Nicole Engard wrote:
You should report your Chrome issues at bugs.koha-community.org so that those developers who have Chrome can look into them. Chrome wasn't around when Koha was first written - and it wasn't used much when 3.0 was released, so it's just something we have to start paying attention to now :)
If Chrome is outperforming Firefox because of something in Koha, then I feel that's a bug in Koha which should be fixed. We really shouldn't be helping people to escape the library monoliths and then driving people away from software freedom into the arms of Google. :-(
It's outperforming Firefox because it runs javascript a lot faster. I use chromium of course which is BSD licensed. I think the issue is the tablesorter code, but then again I'm not sure, any patches to make the page render faster under Firefox would be gratefully received. Chris
Chris Cormack wrote:
It's outperforming Firefox because it runs javascript a lot faster. I use chromium of course which is BSD licensed. I think the issue is the tablesorter code, but then again I'm not sure, any patches to make the page render faster under Firefox would be gratefully received.
When I proposed stripping or loading-on-demand most of the javascript (because it's not needed on 90+% of use) many moons ago, that wasn't really well-received. Would such patches be gratefully received now? Regards, -- MJ Ray (slef) Webmaster and developer for hire at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On 23 August 2010 20:57, MJ Ray <mjr@phonecoop.coop> wrote:
Chris Cormack wrote:
It's outperforming Firefox because it runs javascript a lot faster. I use chromium of course which is BSD licensed. I think the issue is the tablesorter code, but then again I'm not sure, any patches to make the page render faster under Firefox would be gratefully received.
When I proposed stripping or loading-on-demand most of the javascript (because it's not needed on 90+% of use) many moons ago, that wasn't really well-received. Would such patches be gratefully received now?
As long as it doesn't slow down the page render, or reduce functionality I cant see why not. Chris
Chris Cormack wrote:
On 23 August 2010 20:57, MJ Ray<mjr@phonecoop.coop> wrote:
Chris Cormack wrote:
It's outperforming Firefox because it runs javascript a lot faster. I use chromium of course which is BSD licensed. I think the issue is the tablesorter code, but then again I'm not sure, any patches to make the page render faster under Firefox would be gratefully received.
When I proposed stripping or loading-on-demand most of the javascript (because it's not needed on 90+% of use) many moons ago, that wasn't really well-received. Would such patches be gratefully received now?
As long as it doesn't slow down the page render, or reduce functionality I cant see why not.
The problem seems to lie in Firefox itself. Jerry-rigging Koha to match performance amongst browsers only benefits Koha users. Could we perhaps entreat the Firefox team to lift their game and improve Javascript performance? cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Always behave as if nothing had happened, no matter what has happened. -- Arnold Bennett
* Rick Welykochy (rick@praxis.com.au) wrote:
Chris Cormack wrote:
On 23 August 2010 20:57, MJ Ray<mjr@phonecoop.coop> wrote:
Chris Cormack wrote:
It's outperforming Firefox because it runs javascript a lot faster. I use chromium of course which is BSD licensed. I think the issue is the tablesorter code, but then again I'm not sure, any patches to make the page render faster under Firefox would be gratefully received.
When I proposed stripping or loading-on-demand most of the javascript (because it's not needed on 90+% of use) many moons ago, that wasn't really well-received. Would such patches be gratefully received now?
As long as it doesn't slow down the page render, or reduce functionality I cant see why not.
The problem seems to lie in Firefox itself. Jerry-rigging Koha to match performance amongst browsers only benefits Koha users.
Could we perhaps entreat the Firefox team to lift their game and improve Javascript performance?
I'm sure they would accept patches too Rick Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
Op maandag 23 augustus 2010 21:22:52 schreef Rick Welykochy:
Could we perhaps entreat the Firefox team to lift their game and improve Javascript performance?
I haven't tried it myself, but FF4 is supposed to be noticeably faster. You might want to experiment with some of the nightly builds. Also of importance (at least, it was, dunno if that's still the case) is what you were running FF on. x86 (32-bit) has JIT compiled JS, whereas x86_64 (64- bit) doesn't/didn't. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
Hi All, Our Library has been testing Firefox 4 with Koha 3.0.6 and have found that Koha runs faster in Firefox 4 than what it does in Firefox 3 and under. At present, we avoid using Google Chrome with Koha, because we find in the Returns screen it fails to alert us to any Holds/Requests on items, but, will only provide us with the audio alert to a hold. - Have any other libraries overcome this problem? Best WishesJoel Joel Harbottle Library TechnicianLibrary Services (Tasmania) Email: Joel.Harbottle@hotmail.com.au Date: Mon, 23 Aug 2010 23:05:01 +1200 From: robin@catalyst.net.nz To: koha@lists.katipo.co.nz Subject: Re: [Koha] Google Chrome Op maandag 23 augustus 2010 21:22:52 schreef Rick Welykochy:
Could we perhaps entreat the Firefox team to lift their game and improve Javascript performance?
I haven't tried it myself, but FF4 is supposed to be noticeably faster. You might want to experiment with some of the nightly builds. Also of importance (at least, it was, dunno if that's still the case) is what you were running FF on. x86 (32-bit) has JIT compiled JS, whereas x86_64 (64- bit) doesn't/didn't. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Our Library has been testing Firefox 4 with Koha 3.0.6 and have found that Koha runs faster in Firefox 4 than what it does in Firefox 3 and under.
JavaScript performance is one of the major areas of focus for browser developers these days. Chrome raised the bar for everyone, and Mozilla has been playing catch up. Here's a fairly recent comparison (Windows only): http://legitreviews.com/article/1347/1/ Mozilla doesn't need to be asked to improve JavaScript performance. They're trying.
At present, we avoid using Google Chrome with Koha, because we find in the Returns screen it fails to alert us to any Holds/Requests on items
This is the second report I've heard of this recently, but I've never seen it myself. Can anyone provide some details about what conditions lead to the problem? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
HI all, i have queston about translate.koha.net. My account name is akhundof, but i can't edit anything in Azerbaijanian language as i did at the past. Who can help me ? Thanks in advance.
On 23 August 2010 21:20, Elshan Axunzade <elshan@inbox.lv> wrote:
HI all, i have queston about translate.koha.net. My account name is akhundof, but i can't edit anything in Azerbaijanian language as i did at the past. Who can help me ? Thanks in advance.
Hi Elshan I'm guessing you mean translate.koha.org, I have updated your permissions so you should be able to edit it now. koha-translate@lists.koha-community.org is the best place to discuss translation things. Happy translating :) Chris
Returns: Chrome interface does not 'show' reserves when items are being checked in so it is critical to have the volumne turned on that that the audio alerts can be clearly heard (so that the reserves are caught).
What do you mean it doesn't 'show' reserves? Checking in a reserved item doesn't display the "hold found" message box? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
One thing I've noted in using Chrome is that the reports "Statistics Wizards" have magical disappearing drop down boxes! We are on LLEK but I have tested this with ByWater's public demos and see the same behavior (with Chrome v5.0.375.126). When you choose a date to limit by - all of the other drop down boxes disappear or are empty. The screenshot below is from ByWater's demos. All I did was select a "From" date and all of the drop down boxes disappear: [image: Capture.PNG] It happens in the Circulation, Acquisitions, and Patrons "Statistics Wizards" and generally affects the drop down boxes below the date settings. I can look into officially reporting this on Bugzilla. Honestly our biggest problem with Chrome was printing receipts and its lack of a print preview function - then we started seeing strange things like this and decided to stick with Firefox. Josh Westbrook Prescott Library Mngr/District Technology Mngr Walla Walla County Rural Library District joshw@wwrurallibrary.com http://www.wwrurallibrary.com On Mon, Aug 16, 2010 at 5:33 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Returns: Chrome interface does not 'show' reserves when items are being checked in so it is critical to have the volumne turned on that that the audio alerts can be clearly heard (so that the reserves are caught).
What do you mean it doesn't 'show' reserves? Checking in a reserved item doesn't display the "hold found" message box?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
When you choose a date to limit by - all of the other drop down boxes disappear or are empty.
I'd never seen this before, but I see this behavior too. It looks like a compatibility problem between Chrome and the date-picker JavaScript. The date-picker hides the drop-down boxes when it pops up the date calendar. It's supposed to re-display them when it closes, but for some reason it doesn't do so in Chrome. Definitely a bug, but it might be with the date-picker library we're using rather than with Koha itself. Either way I'll look into it. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
When you choose a date to limit by - all of the other drop down boxes disappear or are empty.
This is now Bug 5140: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5140 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
participants (11)
-
Chris Cormack -
Chris Cormack -
Elshan Axunzade -
hfields19＠gmail.com -
Joel Harbottle -
Josh Westbrook -
MJ Ray -
Nicole Engard -
Owen Leonard -
Rick Welykochy -
Robin Sheat