Re: [Wikitech-l] GSOC proposal: Native application uploader
On Apr 5, 2012, at 1:40 AM, Platonides wrote: Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns. This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments. The deliverable is such an application, which shall be: * A tiny autocontained program (probably in C++), with different versions for each target operating system. * Configurable defaults for uploading to Wikimedia Commons own images as cc-by-sa with given templates and categories. * The user shall be able to change the license / categories if needed. * Request the monument id for the image. * Validation of the monument identifier through a web service if available and time permits. * Basic documentation of the competition (rules and FAQ) * Contains the WLM logo somewhere. * Localisable through translatewiki.net for at least the 28 countries of [2] * Save configuration of images description for later upload. * Asynchronous upload of the images in the background. Opinions? Improvements? Sexy names? Mentors? All of them are welcome! 1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.html 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Participating_countries Blame me for loving front-end technology, but maybe one of these ideas are useful to you: * Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins) * Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension or a standalone web application. Or extend / improve UploadWizard. * If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application, also very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc. -- Krinkle [1] disclaimer, disclaimer, .. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
On 05/04/12 02:19, Max Semenik wrote: When I hear C++ and UI, I reach for my minigun. And you want to make it tiny and portable, too;) Though if you consider QT or wxWidgets to be tinier than JRE/Mono/.NET... Let's make a straw weight competition: du -hc /usr/lib/jvm/java-6-openjdk/ 119M du -hc usr/lib/libmono* usr/lib/mono 117M du -hc *amd64* *AMD64* contents of netfx_Core.mzz from dotNetFx40_Client_x86_x64.exe 124M du -hc /usr/lib/libwx_* 12M du -hc /usr/lib/libQt* /usr/lib/qt/* 72M So yes, I think they *are* tinier even without any stripping of unused modules. I made time ago a console uploader which was just 15K, but I'm afraid that wouldn't pass the sexyness threshold. :) A good application to compare with would be sqlitebrowser (sqlitebrowser.sourceforge.net) The windows binary distribution (which includes the needed Qt dlls) is 17M, and in a zip file of 7M. I'm open to further suggestions of better ways to reach those goals, though :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
I have years of experiences with c++ and gui and I will be happy to help you in any way On Thu, Apr 5, 2012 at 3:12 PM, Platonides platoni...@gmail.com wrote: On 05/04/12 02:19, Max Semenik wrote: When I hear C++ and UI, I reach for my minigun. And you want to make it tiny and portable, too;) Though if you consider QT or wxWidgets to be tinier than JRE/Mono/.NET... Let's make a straw weight competition: du -hc /usr/lib/jvm/java-6-openjdk/ 119M du -hc usr/lib/libmono* usr/lib/mono 117M du -hc *amd64* *AMD64* contents of netfx_Core.mzz from dotNetFx40_Client_x86_x64.exe 124M du -hc /usr/lib/libwx_* 12M du -hc /usr/lib/libQt* /usr/lib/qt/* 72M So yes, I think they *are* tinier even without any stripping of unused modules. I made time ago a console uploader which was just 15K, but I'm afraid that wouldn't pass the sexyness threshold. :) A good application to compare with would be sqlitebrowser (sqlitebrowser.sourceforge.net) The windows binary distribution (which includes the needed Qt dlls) is 17M, and in a zip file of 7M. I'm open to further suggestions of better ways to reach those goals, though :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSOC proposal: Native application uploader
Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns. This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments. The deliverable is such an application, which shall be: * A tiny autocontained program (probably in C++), with different versions for each target operating system. * Configurable defaults for uploading to Wikimedia Commons own images as cc-by-sa with given templates and categories. * The user shall be able to change the license / categories if needed. * Request the monument id for the image. * Validation of the monument identifier through a web service if available and time permits. * Basic documentation of the competition (rules and FAQ) * Contains the WLM logo somewhere. * Localisable through translatewiki.net for at least the 28 countries of [2] * Save configuration of images description for later upload. * Asynchronous upload of the images in the background. Opinions? Improvements? Sexy names? Mentors? All of them are welcome! 1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.html 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Participating_countries ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
On 05.04.2012, 3:40 Platonides wrote: * A tiny autocontained program (probably in C++), with different versions for each target operating system. When I hear C++ and UI, I reach for my minigun. And you want to make it tiny and portable, too;) Though if you consider QT or wxWidgets to be tinier than JRE/Mono/.NET... -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
Zawartość nagłówka [Followup-To: gmane.science.linguistics.wikipedia.technical.] Platonides platoni...@gmail.com wrote: Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns. Opinions? Improvements? Sexy names? Mentors? All of them are welcome! 1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.html Odder already mentions Commonist in his email, so let me expand on this (as I was fixing older Java versions to work with a more modern MediaWikis): You have the last Java version in our SVN: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/ as well as the next generation Commonist in Scala: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist/ Scala version solved some architectural issues with the Java version. I would definitely recommend to build on Commonist; I actually like the tool very much (I was still using old java version until recently). It has simple UI that meets *most* of the requirements. Actually providing some sensible defaults (or even-simpler-UI) should be enough for WLM people. Commonist is actually quite customizable (a lot can be done using property files and templates), The only thing which I really don't like in Commonist ist that actual upload phase is done together with metadata editing. Metadata weren't saved (at least in the older versions I have used) together with images (or somewhere else - images can be on R/O medium) so you would lose them if the tool was closed. So probably there should be three phases: (1) metadata management/editing (that includes some defaults for WLM folk) (2) actual upload/sync (Commonist has ability to re-upload). (3) obtaining upload results and letting users to decide what to do with problems (force re-upload etc.) Some users with very limited upstream bandwidth reported quite good results with Commonist when needing to upload lots of images and having to leave computer working overnight to actually transfer them. And there is one feature that actually huge majority of people liked - Commonist can be launched from the webpage as the Java Webstart application, so - from the user's perspective - you don't really need to install it on your computer. I've even talked to some who didn't realize really it was a separate application, it just magically worked for them out of the browser. Huge advantage. So from my POV - +1 for taking Commonist to the next level, even if this means learning Scala. //Saper ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
Greetings, Thank you for your work on this and interest in this year's GSOC. Have you had a chance to write up a proposal on the MW.org wiki? https://www.mediawiki.org/wiki/GSOC#Student_applications It would be helpful, just to avoid confusion, what OSes you plan to support once completed. -greg aka varnent On Apr 4, 2012, at 7:40 PM, Platonides platoni...@gmail.com wrote: Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns. This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments. The deliverable is such an application, which shall be: * A tiny autocontained program (probably in C++), with different versions for each target operating system. * Configurable defaults for uploading to Wikimedia Commons own images as cc-by-sa with given templates and categories. * The user shall be able to change the license / categories if needed. * Request the monument id for the image. * Validation of the monument identifier through a web service if available and time permits. * Basic documentation of the competition (rules and FAQ) * Contains the WLM logo somewhere. * Localisable through translatewiki.net for at least the 28 countries of [2] * Save configuration of images description for later upload. * Asynchronous upload of the images in the background. Opinions? Improvements? Sexy names? Mentors? All of them are welcome! 1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.html 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Participating_countries ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
