MediaWiki talk:Gadget-UTCLiveClock.js

Font size

I've just installed this into my account after using the original version by User:Mathwiz2020. Enlarging the font of the clock makes the rest of the personal toolbar look out of place (like its touching the page tool tabs). Is it okay if I change the font size back to match the rest? --w^{L<speak·check>} 12:44, 15 January 2008 (UTC)

I designed it based on the reality of mine to have the personal toolbar at the left, so personally I would like to have it larger. _→AzaToth 17:17, 16 January 2008 (UTC)

Mines twitches like a dying animal: is this a problem with my browser (Mac, Firefox, no add-ons)? I can't for the life of me figure out what's up with it. Anthøny 11:25, 20 January 2008 (UTC)

Strike that; I still had VoA's clock gadget installed (importScript('User:Voice_of_All/UTCclock.js');), so the two were essentially clashing. Fixed :) Anthøny 11:28, 20 January 2008 (UTC)

Browser access-key conflict

I'm not sure if this is the correct page, but it's the closest I could find. I run IE6 and IE7 (on different partitions, but same comp) on WinXP/SP2. When the "UTC LIVE clock" feature is activated throught eh Gadgets in Preferences, the "Undo" function in the Windows right-click and Ctrl-U functions is disabled. I'm a lousy typist, so this is a function I need to have, but I like the UTC time feature also. After several weeks without my Undo, I finally tried disableing each new feature in Gadgets, and discovered that the CLock was the apparent culprit (my undo works now, anyway!) Is there a fix or work-around to this problem? Thanks. - BillCJ (talk) 09:11, 15 February 2008 (UTC)

This might not suit you, but I usually press Ctrl + Z to undo, which you might find easier. Mahahahaneapneap (talk) 01:33, 24 February 2008 (UTC)

I just tried that, and it does not work either. Evidently it's the "undo" functionalitly, not just the right-click undo feature. - BillCJ (talk) 01:57, 24 February 2008 (UTC)

I can confirm that this is indeed a problem in IE because of setTimeout(), but I'm not sure how to fix this at the moment. —AlexSm 04:07, 24 February 2008 (UTC)

One tick per minute

I have a rather old and slow computer, and I use Firefox. So I can not use this gadget since it slows down my browser way too much. How about changing it so it only ticks once per minute? I don't see why people would need the seconds? And having the seconds tick must be distracting, right?

Or if you want to keep the seconds, make a second gadget with minutes only.

--David Göthberg (talk) 21:35, 22 April 2008 (UTC)

Some time ago User:Saintrain brought up the same issue in a discussion at the Village Pump. I have now gotten around to update my version of the clock with the improvements suggested by Ilmari Karonen and others in that discussion. It is now fully configurable to meet all needs. Due to it being fully configurable it is now more code, but it is more efficient than any of the other versions since it is only the very small inner "updateTime" function that runs on each tick.

I have not installed my version of the clock as the gadget yet, since I think some users should test it first. But it works in all three of my browsers, even in my very old Internet Explorer 5.5.

If you would like to test it you can copy my version of the clock from User:Davidgothberg/monobook.js and put it into your own monobook.js.

Note: There are several code snippets on my monobook.js page, be sure to copy the right part. (Now moved to User:Davidgothberg/clock.js, see instructions there.) Oh, and don't forget to configure the DavidClock to tick and show as you like. As you can see I have it set to only tick once every 5 minutes since I have a very slow computer and don't really need higher time resolution.

--David Göthberg (talk) 16:56, 17 September 2008 (UTC)

It would be a bit more convenient if you made it a separate page, and then we could test the script simply by pasting javascript:davidClock=30;importScript('User:Davidgothberg/clock.js');void 0 into the browser address field. As for the code, the line else if( window.davidClock == 0 ) doesn't have any purpose, some code pieces could be combined together. And I suspect some current users will not be happy with the second "static" clock by default. —AlexSm 19:11, 17 September 2008 (UTC)

Yes, a separate page would probably be convenient. I just haven't learnt how to do that yet. (Although having programmed computers since 1982 I am brand new to JavaScript coding.) One reason I did not read up on that is that I don't want people to just link to my code, since I will be playing with it whenever I feel like it and don't want to have take into consideration all the users who might be linking to my code. Instead when we feel we have a good version I would like to update this gadget.

What does the "void 0" part in your string above do?

Actually, the else if( window.davidClock == 0 ) does have a purpose. According to my testing "window.davidClock == 0" doesn't mean the same thing as "!window.davidClock" since the first case returns true only if the variable exists and has the content "0", while the other case reports true also if the variable does not exist. And we want the code to use the default settings if the variable doesn't exist. Oh, silly me! I added the surrounding "if( window.davidClock ) {}" after I wrote and tested that line, to make the code more readable for other programmers. I see now that it breaks things. Darn, I should have done more testing when I felt "finished" with the code. Thanks for catching that bug. That is just my second version of the code, so I will look at it more during the coming days. I now also see that I can change "window.davidClock > 0" to "window.davidClock >= 0" and thus get rid of the "window.davidClock == 0" line altogether. (I can blame that I initially had the setting "window.davidClock == 'static'".) So one error fixed and one optimisation found. Thanks.

And yes there is some code duplication. It's there for speed reasons. The reason I made this version of the UTC clock is that some of us had problems that the old clock loaded our computers too much. With the old UTC clock (that ticks every second) and 10-15 tabs open my web browser becomes almost unusable. Yes, I have a very old computer and Firefox probably isn't the fastest browser. And complaints about the amount of CPU load the UTC clock causes have been brought up by others on the Village Pump.

And regarding the static clock: Some users instead wanted to have only the static clock. And in this case I prefer to show both clocks per default, so people know their options and instead can turn off what they don't need. Besides, if you try both clocks for some days I bet you will become as dependant on them as I am now. There are many reasons to be able to tell when you last reloaded a page, for instance on talk pages like the Village Pump.

Of course, the best thing would be if we could add several different versions of the UTC clock as gadgets. Then the users would not have to edit their monobook.js. Having to edit ones monobook.js to use a gadget defeats the purpose of a gadget, then one can just as well paste the code or an "importScript()" line into the monobook.js. But for some silly reason some people resist any increase in the number of gadgets.

I would like that JavaScript knowledgeable users like you copy the code to their user space and work with it to add and test any improvements or changes. Then you can tell me about it and we can compare and copy/use the best from each version. We already have done that some increments for this clock.

--David Göthberg (talk) 20:45, 17 September 2008 (UTC)

I guess the javascript: address just works this way: the last statement should not return any value, and void 0 does exactly that; I think I picked it from bookmarklets. As for the speed, I don't think you gain much by not defining function zz(x){ return z < 10 ? '0'+z : z } which would make the rest of the code much more readable. And I don't think updateTimeMinutes() would really slow down from just one extra condition ... + (tick < 60 ? zz(now.getUTCSeconds()) : "") which eliminates the need for updateTimeSeconds(). —AlexSm 03:44, 18 September 2008 (UTC)

AlexSm: Thanks for the explanation of how to call a JavaScript page from the address bar. (And I have read up on things and now do my editing and testing on a .js and .css page loaded from my localhost web server. Way more efficient.)

I have taken your advice and moved my UTC clock to a separate page User:Davidgothberg/clock.js. And that also means I can add it to the list of user scripts over at Wikipedia:WikiProject User scripts/Scripts. (But I still want to add it to this gadget too, since it does have several improvements.)

And I made several changes/fixes to the code. For instance when the clock shows both the ticking and static clock I made it so the static clock instead has a link to edit section 0. Why not use that extra link for something when we anyway have it there? :))

And I have done some speed testing, again. On really slow computers like mine and with the slow JavaScript interpreter that Firefox has then even small changes in the JavaScript code matters. The new code I use now causes noticeable less load on my computer.

--David Göthberg (talk) 19:49, 19 September 2008 (UTC)

Inexplicable Bug?

I'll be pleasantly surprised if someone is watching this page, but I didn't want to bother WP:VPT for a non-critical puzzler. (Plus, this way I get to bump up my MediaWiki talk edits!) If I don't hear from anyone in a while, I'll try there.

OK, here’s the puzzle. I have the little clock/purge gadget installed. So far, it has appeared without incident on every page on Wikipedia except WP:ANI. Now, if I go into edit mode at WP:ANI, it’s there; but if I’m just viewing the page, it isn’t. The clock isn’t being covered up by anything; the rest of my personal toolbar just shifts over as if I didn’t have the clock installed. Purging pages, logging out and in, etc. doesn’t work. I have no idea if it’s always been like this, or if it’s a new phenomenon, but I’d love to know why this is happening. --barneca (talk) 19:06, 24 July 2008 (UTC)

What browser are you using? It works for me in the Mac version of Safari and Firefox. -- Ned Scott 07:41, 5 August 2008 (UTC)

Hmmm. It works for me now too. In a way, that's a shame, because now I'll never know what was going on, and it's irritating not to know. But, to answer your question, when it wasn't working, I'm 100% sure it wasn't working in IE7, and if my sometimes unreliable memory serves, I'm 90% sure it also wasn't working in Safari (not sure what version, I'm not near that machine right now). --barneca (talk) 12:26, 5 August 2008 (UTC)

Vector skin

When the script was loaded using the Vector skin, it gots the script error. I think the script is need to be updated in order to supporting for the other skins. Shinjiman ⇔ ♨ 17:22, 6 July 2009 (UTC)

Font Size (again)

Ok, so like with the font-size: larger, it looks totally ridiculous with the vector skin. The clock looks completely ridiclous, and looks like someone just randomly jamed in the toolbar (or whatever you call it), and it sticks out like a sore thumb. If your not willing to shrink it (dropping the font-size: larger; is all that is needed), could you provide an option to shrink it? – Andrew Hampe ^Talk 16:15, 7 December 2009 (UTC)

Yea... Someone should have fixed this a LONG LONG LONG time ago. I finally went and found me an admin and made them update the clock to match the fix we've had for the last 8 months on enwn. --ShakataGaNai ^{^_^} 00:20, 12 February 2010 (UTC)

style attribute properties

It would be better to remove these lines:

	if (skin !== "vector") { //Looks bad on vector 
		liveClock.node.style.fontSize = 'larger'; 
		}  
	liveClock.node.style.fontWeight = 'bolder';

And add these css properties to MediaWiki:Monobook.css and the other skins in which they do not “look bad”:

#utcdate {
	font-size:larger;
	font-weight:bolder;
	}

Or alternatively, add the above to MediaWiki:Common.css but cancel it in MediaWiki:Vector.css using the following:

#utcdate {
	font-size:inherit;
	font-weight:inherit;
	}

―AoV² 22:48, 24 April 2010 (UTC)

Why? Amalthea 08:55, 25 April 2010 (UTC)

Because I tried to shrink it with user css but found it was hard-coded, obviously. ―AoV² 09:37, 25 April 2010 (UTC)

The element styles set by javascript are still just styles, and you can override them in your monobook.css with something like

#utcdate{font-size:9px !important;}

You're right in general that the style info should be broken out, but I don't think the site or skin sheets are the best place for them, those shouldn't be filled with gadget specific stuff. Right way to go would be either placing them in a separate sheet that can then be loaded via MediaWiki:Gadgets-definition, or letting the script add a CSS node using appendCSS from wikibits.js.
Amalthea 10:06, 25 April 2010 (UTC)

Yes if there is a corresponding css page for each gadget js it should all go there. Since all skins would be sharing it, you can set them to be different with:

body.skin-monobook #utcdate { what:ever; }
body.skin-vector #utcdate { what:ever; }

etc. ―AoV² 10:28, 25 April 2010 (UTC)

Y Done, a bit different though. Loading a separate CSS file for this seemed excessive, so the script just creates a CSS node, with a style that works for both monobook and vector.
Amalthea 17:35, 28 April 2010 (UTC)

Documentation for gadget authors

We're trying to start a library for gadget authors to use. Please check it out and post any questions or comments there. -- ☠MarkAHershberger☢(talk)☣ 01:19, 9 March 2012 (UTC)

Protected edit request on 18 July 2014

Please remove "&smaxage=21600&maxage=86400" as in mw:Special:Diff/1068457. These parameters are not necessary. Helder.wiki 16:03, 18 July 2014 (UTC)

 Done Ruslik_Zero 19:26, 18 July 2014 (UTC)

No, it isn't. The last edit to this was in 2011. — ACupOfCoffee@ 01:32, 5 February 2015 (UTC)

Done for real this time. --w^{L<speak·check>} 06:26, 7 February 2015 (UTC)