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.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
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...
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 :)
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 Platonides@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
Zawartość nagłówka ["Followup-To:" gmane.science.linguistics.wikipedia.technical.]
Platonides platonides@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.ht...
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
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 platonides@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.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gregory Varnum wrote:
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
Hello Greg, I've copied it now at https://www.mediawiki.org/wiki/User:Platonides/GSOC_proposal
This is a wiki page. I encourage everyone* to edit it adding whatever the requisites they think should be fullfilled by such an application
*Specially those organizing the WLM contest at the different levels.
It would be helpful, just to avoid confusion, what OSes you plan to support once completed.
-greg aka varnent
The ideal target are Windows, Linux and Mac, but development for the latter will be mostly theoretical (as in "this code _should_ work"), as I don't personally have a Mac OS computer, so I wouldn't be able to test it myself.
Best regards
Thank you for the info - I would suggest including the other info on your wiki page that's outlined here: https://www.mediawiki.org/wiki/Summer_of_Code_2012/Application_template
-greg
On Apr 5, 2012, at 11:53 AM, Platonides platonides@gmail.com wrote:
Gregory Varnum wrote:
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
Hello Greg, I've copied it now at https://www.mediawiki.org/wiki/User:Platonides/GSOC_proposal
This is a wiki page. I encourage everyone* to edit it adding whatever the requisites they think should be fullfilled by such an application
*Specially those organizing the WLM contest at the different levels.
It would be helpful, just to avoid confusion, what OSes you plan to support once completed.
-greg aka varnent
The ideal target are Windows, Linux and Mac, but development for the latter will be mostly theoretical (as in "this code _should_ work"), as I don't personally have a Mac OS computer, so I wouldn't be able to test it myself.
Best regards
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.ht... 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Particip...
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, ..
On 06/04/12 16:03, Krinkle wrote:
Blame me for loving front-end technology, but maybe one of these ideas are useful to you:
No blame, I welcome your insights, Krinkle :)
- Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins)
I'd prefer not to hardcode anything WLM-specific, but maybe there's a killer feature hard to do without it. Maybe I can get all WLM-specific things in a module, and have the application linkable with a different one. I've added a note about it at the application page.
- 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.
I don't find UploadWizard comprehensible enough to extend it :) We could have a web application which stored the image preferences at localStorage (not as good as an actual file, but could work), but I don't think we could load the submtited filenames from a previous run (nor would be too safe for a spec to allow that). It might be possible in Firefox by requesting higher privileges.
- 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.
Isn't that based on Flash? Had you proposed Prism... Still, the overhead of these approaches seems too big. Also, Adobe Air seem to have discontinued their Linux support, and reliance on that propietary system doesn't seem like a good idea.
wikitech-l@lists.wikimedia.org