I hope this request is admissible for the list.
I'm after a MediaWiki slideshow extension, and found a Javascript version under the GNU license at http://www.barelyfitz.com/projects/slideshow/
But my knowledge of extensions is not good enough to convert this into an extension.
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
The extension would create a new <slideshow> tag. It would not need the "Slideshow Wizard" (described on the Web site above) that creates the slideshow, as it is quite easy to do this manually.
And the one main improvement to the extension would be to be able to specify images either as a URL, or as a Wiki image, eg;. Image:picture.jpg (using the modest sized image, rather than the uploaded larger sized image. The option to restrict URLs to certain domains would prevent the use of inappropriate off-size images.
I think this extension would be a useful additional.
Regards, Ian Tresman
I thought of this some time ago: http://bugzilla.wikimedia.org/show_bug.cgi?id=5383
and I still think it would be nifty :)
cheers Brianna user:pfctdayelise
On 11/03/07, Ian Tresman it@knowledge.co.uk wrote:
I hope this request is admissible for the list.
I'm after a MediaWiki slideshow extension, and found a Javascript version under the GNU license at http://www.barelyfitz.com/projects/slideshow/
But my knowledge of extensions is not good enough to convert this into an extension.
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
The extension would create a new <slideshow> tag. It would not need the "Slideshow Wizard" (described on the Web site above) that creates the slideshow, as it is quite easy to do this manually.
And the one main improvement to the extension would be to be able to specify images either as a URL, or as a Wiki image, eg;. Image:picture.jpg (using the modest sized image, rather than the uploaded larger sized image. The option to restrict URLs to certain domains would prevent the use of inappropriate off-size images.
I think this extension would be a useful additional.
Regards, Ian Tresman
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
GNU? Why not MIT or BSD (something more business friendly)?*
The extension would create a new <slideshow> tag. It would not need the "Slideshow Wizard" (described on the Web site above) that creates the slideshow, as it is quite easy to do this manually.
I'd think a Category would do this nicely. So <slideshow category="Some category"> would put out a slide show of all images which have been tagged [[Category:Some category]]
-- Jim R. Wilson (jimbojw)
* I am not trying to start a which-OSS-license-is-better flame war, I'm just asking. :)
On 3/11/07, Brianna Laugher brianna.laugher@gmail.com wrote:
I thought of this some time ago: http://bugzilla.wikimedia.org/show_bug.cgi?id=5383
and I still think it would be nifty :)
cheers Brianna user:pfctdayelise
On 11/03/07, Ian Tresman it@knowledge.co.uk wrote:
I hope this request is admissible for the list.
I'm after a MediaWiki slideshow extension, and found a Javascript version under the GNU license at
http://www.barelyfitz.com/projects/slideshow/
But my knowledge of extensions is not good enough to convert this into an extension.
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
The extension would create a new <slideshow> tag. It would not need the "Slideshow Wizard" (described on the Web site above) that creates the slideshow, as it is quite easy to do this manually.
And the one main improvement to the extension would be to be able to specify images either as a URL, or as a Wiki image, eg;. Image:picture.jpg (using the modest sized image, rather than the uploaded larger sized image. The option to restrict URLs to certain domains would prevent the use of inappropriate off-size images.
I think this extension would be a useful additional.
Regards, Ian Tresman
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3/11/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
GNU? Why not MIT or BSD (something more business friendly)?*
Mediawiki is GPLed.
Mediawiki is GPLed.
That's true, however that doesn't mean that software (such as extensions) built on this framework must also be GPL - at least, I don't believe so.
Core devs, please correct me if I'm wrong there. I know GPL applies to derivative works, however I don't believe this applies to extensions. If I'm incorrect, and it _does_ apply to extensions, I'd very much like to know since I've been releasing my MediaWiki extensions with an MIT style license.
-- Jim
On 3/11/07, Gregory Maxwell gmaxwell@gmail.com wrote:
On 3/11/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
GNU? Why not MIT or BSD (something more business friendly)?*
Mediawiki is GPLed.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
Mediawiki is GPLed.
That's true, however that doesn't mean that software (such as extensions) built on this framework must also be GPL - at least, I don't believe so.
Core devs, please correct me if I'm wrong there. I know GPL applies to derivative works, however I don't believe this applies to extensions. If I'm incorrect, and it _does_ apply to extensions, I'd very much like to know since I've been releasing my MediaWiki extensions with an MIT style license.
<ianal> If you're uncertain, talk to a copyright lawyer about it. </ianal>
In practical terms, MIT-style is probably fine for your own code (and is conveniently 'upgradable' to GPL under common understanding. ;)
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On 3/11/07, Gregory Maxwell gmaxwell@gmail.com wrote:
On 3/11/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Would someone else oblige... I'm willing to pay, and the resulting extension would remain under GNU and freely available to everyone.
GNU? Why not MIT or BSD (something more business friendly)?*
Mediawiki is GPLed.
As is, apparently, the JavaScript thingie he found, and being as he was asking for someone to incorporate it into an MW extension, anything that fulfilled his request would certainly have to be GPL (at least partly). Of course, whether GPL JavaScript includes require the including page to be GPL is an interesting question . . . I've always wondered how we glue together a GPL interface and GFDL content on Wiki* anyway. Not to mention interface messages, which are GPL but whose modifications are ostensibly GFDL.
Bah, the FSF should make them compatible anyway. ;)
I'm currently searching for an extension which allows the TOC to be extracted from the page and used elsewhere in the skin (for example, in a sidebar - outside the confines of the article itself). It seems to be a common request yet I haven't been able to find any solutions.
If this extension does not exist then I will be making one. It's my first time delving in to Mediawiki so I would appreciate any guidance on how to go about doing this.
I've found this post which seems to be an overview of what I need to do - can anyone expand on this?
http://article.gmane.org/ gmane.science.linguistics.wikipedia.technical/17938/
Best Regards, Chris
On 13/03/07, Chris Marmo wiki@prosimian.com.au wrote:
I'm currently searching for an extension which allows the TOC to be extracted from the page and used elsewhere in the skin (for example, in a sidebar - outside the confines of the article itself). It seems to be a common request yet I haven't been able to find any solutions.
If this extension does not exist then I will be making one. It's my first time delving in to Mediawiki so I would appreciate any guidance on how to go about doing this.
Having recently played with this code I can say it sounds like a good idea to me. The TOC code is tied to the parser and the output more strongly than it need be. It should be free to be output as part of the skin or part of the article. It should be quite easy to implement.
Andrew Dunbar (hippietrail)
I've found this post which seems to be an overview of what I need to do - can anyone expand on this?
http://article.gmane.org/ gmane.science.linguistics.wikipedia.technical/17938/
Best Regards, Chris
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for the replies everyone.
Having recently played with this code I can say it sounds like a good idea to me. The TOC code is tied to the parser and the output more strongly than it need be. It should be free to be output as part of the skin or part of the article. It should be quite easy to implement.
Andrew - I agree completely. I think hacking up the parser class would be easy, however I don't want to mess with the core code. I'd rather build this as an extension on top of what already exists. I've tried extending the class and overriding the Parser::formatHeadings() function but I don't know enough about hooks, etc at the moment to make an informed decision about the best way to go about this.
For my current project CSS positioning isn't an option because I need to position the TOC in another column relative to the actions bar (which I'm displaying vertically). Because both the TOC and Actions bars increase/decrease in size absolute positioning wont cut it, unfortunately.
Again, any suggestions from developers would be received with great appreciation :)
Best Regards, Chris
On Mar 13, 2007, at 11:20 PM, Andrew Dunbar wrote:
Andrew Dunbar (hippietrail)
-- http://wiktionarydev.leuksman.com http://linguaphile.sf.net
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Am Mittwoch, 14. März 2007 schrieb Chris Marmo:
For my current project CSS positioning isn't an option because I need to position the TOC in another column relative to the actions bar (which I'm displaying vertically). Because both the TOC and Actions bars increase/decrease in size absolute positioning wont cut it, unfortunately.
Again, any suggestions from developers would be received with great appreciation :)
Well, I'm not a developer myself, but I think XSL-Transformations would be a neat way to achieve the appreciated behaviour. I think some basic XSLT which is needed for what you want to do is supported along with MSIE 6 and recent Gecko Versions, so there shouldn't be a problem with it.
Julian
On 13/03/07, Chris Marmo wiki@prosimian.com.au wrote:
Thanks for the replies everyone.
Having recently played with this code I can say it sounds like a good idea to me. The TOC code is tied to the parser and the output more strongly than it need be. It should be free to be output as part of the skin or part of the article. It should be quite easy to implement.
Andrew - I agree completely. I think hacking up the parser class would be easy, however I don't want to mess with the core code. I'd rather build this as an extension on top of what already exists. I've tried extending the class and overriding the Parser::formatHeadings() function but I don't know enough about hooks, etc at the moment to make an informed decision about the best way to go about this.
For my current project CSS positioning isn't an option because I need to position the TOC in another column relative to the actions bar (which I'm displaying vertically). Because both the TOC and Actions bars increase/decrease in size absolute positioning wont cut it, unfortunately.
Again, any suggestions from developers would be received with great appreciation :)
Oftentimes when you're doing something new there is not yet any hook in the right place. Adding a new hook is trivial and typically only adds one line to the core code. In the work I mentioned above I added two hooks. One to allow extra stuff where the [edit] links are added and one to allow an alternative algorithm for generating the TOC and the headings since this code is glommed together now.
Because you're typically only adding one line, svn updates usually cause no problem. And if you want others to benefit from your new hook you can post it to Bugzilla as a feature request with your patch. If the devs see a better way to do it they will usually say so or even implement an improved version right away.
Good luck.
Andrew Dunbar (hippietrail)
Best Regards, Chris
On Mar 13, 2007, at 11:20 PM, Andrew Dunbar wrote:
Andrew Dunbar (hippietrail)
-- http://wiktionarydev.leuksman.com http://linguaphile.sf.net
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chris Marmo wrote:
I'm currently searching for an extension which allows the TOC to be extracted from the page and used elsewhere in the skin (for example, in a sidebar - outside the confines of the article itself). It seems to be a common request yet I haven't been able to find any solutions.
Seems easy to hack with JavaScript.
On 3/13/07, Platonides Platonides@gmail.com wrote:
Chris Marmo wrote:
I'm currently searching for an extension which allows the TOC to be extracted from the page and used elsewhere in the skin (for example, in a sidebar - outside the confines of the article itself). It seems to be a common request yet I haven't been able to find any solutions.
Seems easy to hack with JavaScript.
You will be roasted in the fires of hell for suggesting such a thing.
Yes, this should undoubtedly be split partly out of the parser.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Tuesday 13 March 2007 21:18:12 Simetrical wrote:
On 3/13/07, Platonides Platonides@gmail.com wrote:
Chris Marmo wrote:
I'm currently searching for an extension which allows the TOC to be extracted from the page and used elsewhere in the skin (for example, in a sidebar - outside the confines of the article itself). It seems to be a common request yet I haven't been able to find any solutions.
Seems easy to hack with JavaScript.
You will be roasted in the fires of hell for suggesting such a thing.
Uhm, why? Just moving the table around with CSS should be quite easy. I mean, you could use position:relative or position: absolute?
Yes, this should undoubtedly be split partly out of the parser.
Can you explain this a bit more?
I'd als like to mention this (shameless plug I know :-)
http://bloodgate.com/wiki/index.php?title=POD:Graph
Note the TOC? :) Then consider that the entire page in wiki consists of roughly:
<pod> lots of text here </pod>
The TOC was created by the extension. (Technically, the extension should even create two TOCs if you have two POD sources in the same article, although that wasn't tried yet)
I haven't toyed around with moving the toc into the sidebare, but that was exactly my idea for the following scenary:
* Upon loading the page, the toc is just below the toolbox * when you scroll down, toolbox and menu scroll out to the top, so the TOC rises * when the TOC hits the upper border of the window, it stays there
E.g. the toc scrolls with the window, but only up to the upper window border so you can see it always, even on very long pages.
Problems with that approach:
* TOC might be longer than browser-window (special case this?) * TOC parts cannot be collapsed, so you cant shorten the TOC (that could be done with more JSmagic) * toc that is more wide than sidebar (will overflow/break)
But certainly an interesting area if interface research :D
All the best,
Tels
- -- Signed on Tue Mar 13 23:14:16 2007 with key 0x93B84C15. Get one of my photo posters: http://bloodgate.com/posters PGP key on http://bloodgate.com/tels.asc or per email.
"Duke Nukem Forever will come out before Doom 3."
-- George Broussard, 2002 (http://tinyurl.com/6m8nh)
After reading this discussion I whipped up a little Javascript module:
http://commons.wikimedia.org/wiki/User:Dschwen/slideshow.js
Activate it by putting:
// [[User:Dschwen/slideshow.js]] - please include this line document.write('<script type="text/javascript" src="' + 'http://commons.wikimedia.org/w/index.php?title=User:Dschwen/slideshow.js' + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
into your monobook.js
It is far from perfect, but it's a start. I still want to make the Slideshow button to auto-hide, make the time between slides confugurable, add manual advance and back buttons. etc. Take it as a proof of concept. tested on Firefox and Konqueror. Best, Daniel
At 11:10 12/03/2007, Daniel wrote:
After reading this discussion I whipped up a little Javascript module:
http://commons.wikimedia.org/wiki/User:Dschwen/slideshow.js
Activate it by putting:
// [[User:Dschwen/slideshow.js]] - please include this line document.write('<script type="text/javascript" src="'
- 'http://commons.wikimedia.org/w/index.php?title=User:Dschwen/slideshow.js'
- '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
into your monobook.js
That's pretty incredible... the speed at which you "whipped up a little Javascript module". I'm quite jealous. Thank you, I shall have a play with it.
Regards, Ian Tresman
wikitech-l@lists.wikimedia.org