Hey all, I would like to work on the external editor helper with a cross-platform Qt/C++ interface. I'm trying to make the ee.pl work but I get an error about my password and url match. This is what I put in my ini file: [MediaWiki] URL match=en.wikipedia.org Username=patcito Password=<mypassword>
isn't that correct?
thanx in advance
Pat
On 5/2/06, Patrick Aljord patcito@gmail.com wrote:
This is what I put in my ini file: [MediaWiki] URL match=en.wikipedia.org Username=patcito Password=<mypassword>
isn't that correct?
Yes, that should be working. I just tested it again to make sure that nothing has broken recently. Try setting $ignore_login_error=1; in the beginning of the file -- does that make the problem go away? Also try fetching this URL:
http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&...
and saving it to the disk e.g. as "wpedit.ini", then run ee.pl with the file as a parameter.
Erik
On 5/2/06, Erik Moeller eloquence@gmail.com wrote:
On 5/2/06, Patrick Aljord patcito@gmail.com wrote:
This is what I put in my ini file: [MediaWiki] URL match=en.wikipedia.org Username=patcito Password=<mypassword>
isn't that correct?
Yes, that should be working. I just tested it again to make sure that nothing has broken recently. Try setting $ignore_login_error=1; in the beginning of the file -- does that make the problem go away?
yes it does thanks, I'm gonna try to apply. I want to do it in Qt/C++. The main functionalities will be the same as your perl script: - save - save & continue - diff - preview - cancel
plus a few other ones: - support for mac, win and linux though I won't be able to test it on Mac. Should be ok with Qt4. - support i18n with .po files - ability to manage several documents at the same time (with a list of all the different documents) - ability to save sessions to remember which documents you were working on - select session upon start - that session thing will be turned off by default so it don't get in your face for people that don't care
what do you think of these? do you have any other ideas before I submit the application?
Thanks in advance
Pat
On 5/3/06, Patrick Aljord patcito@gmail.com wrote:
I want to do it in Qt/C++.
Good choice.
The main functionalities will be the same as your perl script:
- save
- save & continue
- diff
- preview
- cancel
Make sure you test how the app reacts in case of edit conflicts, I'm not sure the current script handles them properly. Also check the caching behavior. The current script may view out of date images, for instance, after saving (it sometimes does, sometimes doesn't, probably a race condition). A MediaWiki URL that ends with &action=purge should override all caching.
It might also be nice to have an additional method of saving to the server, simply by saving the file itself from the application. To do this, you would have to monitor changes to the data. This should be optional and quick to enable/disable from the UI (hotkey or visible checkbox). Check out http://www.zope.org/Members/Caseman/ExternalEditor/ - this is a similar feature in Zope. The zopeedit file contains the helper application, written in Python. It follows a different protocol than MediaWiki, but may provide some inspiration.
Since the helper application will have to be capable of uploading files, adding some additional MediaWiki upload functionality would be a nice way to make the project a little larger. This would be an interesting alternative to your other SoC application for improving the upload process. There are currently a few batch upload utilities, but the only cross-platform tool I've seen is written in Java and rather slow.
Having the upload functionality in there would also be a good way to get more people to install the tool. In the long run, it could be enriched with even more client-side functionality such as simple bot tasks.
- ability to save sessions to remember which documents you were working on
- select session upon start
Not sure this is very useful, since you're typically going to launch the editor from a wiki when you have a need for it.
Erik
On 5/4/06, Erik Moeller eloquence@gmail.com wrote:
Make sure you test how the app reacts in case of edit conflicts, I'm not sure the current script handles them properly. Also check the caching behavior. The current script may view out of date images, for instance, after saving (it sometimes does, sometimes doesn't, probably a race condition). A MediaWiki URL that ends with &action=purge should override all caching.
ok so before uploading a modified file back to the server I could do a &action=purge and check the diff.
It might also be nice to have an additional method of saving to the server, simply by saving the file itself from the application. To do this, you would have to monitor changes to the data. This should be optional and quick to enable/disable from the UI (hotkey or visible checkbox).
great idea, I'm going to add it to the todo list :)
Since the helper application will have to be capable of uploading files, adding some additional MediaWiki upload functionality would be a nice way to make the project a little larger. This would be an interesting alternative to your other SoC application for improving the upload process. There are currently a few batch upload utilities, but the only cross-platform tool I've seen is written in Java and rather slow.
you mean a full upload form with the choice of category and all? a Qt/C++ version of the wikimedia php page? guess it could be done but I'd need your help about how to get the categories names from the wikimedia db, is there a protocol or something or I'll just use http and fetch them like the ee.pl?
Having the upload functionality in there would also be a good way to get more people to install the tool. In the long run, it could be enriched with even more client-side functionality such as simple bot tasks.
- ability to save sessions to remember which documents you were working on
- select session upon start
ok I'll postpone those then.
thanx again for all your answers
Pat
On 5/4/06, Patrick Aljord patcito@gmail.com wrote:
On 5/4/06, Erik Moeller eloquence@gmail.com wrote:
Make sure you test how the app reacts in case of edit conflicts, I'm not sure the current script handles them properly. Also check the caching behavior. The current script may view out of date images, for instance, after saving (it sometimes does, sometimes doesn't, probably a race condition). A MediaWiki URL that ends with &action=purge should override all caching.
ok so before uploading a modified file back to the server I could do a &action=purge and check the diff.
What diff? There are no diffs on files, only on pages. Let me be extra clear on this: ee.pl has two primary functions, editing text or changing files (images, sounds, videos etc.) on the server. These are very different in nature. Just double-checking that you've noticed that.
I think what you should do is first test the upload process in ee.pl a bit and see under which conditions you're seeing old files rather than the uploaded ones. If it's related to the processing of the image on the wiki, you could try simply adding some sleep() between the upload and the page view (making that customizable would probably be a good idea).
you mean a full upload form with the choice of category and all?
No, just a very simple file/description combination. The description is wikitext, so the user can add the categories or license manually. It might be nice to have two text areas "Prepend to all:" and "Append to all:" in addition to the individual file descriptions.
Erik
On 5/4/06, Erik Moeller eloquence@gmail.com wrote:
On 5/4/06, Patrick Aljord patcito@gmail.com wrote:
On 5/4/06, Erik Moeller eloquence@gmail.com wrote:
Make sure you test how the app reacts in case of edit conflicts, I'm not sure the current script handles them properly. Also check the caching behavior. The current script may view out of date images, for instance, after saving (it sometimes does, sometimes doesn't, probably a race condition). A MediaWiki URL that ends with &action=purge should override all caching.
ok so before uploading a modified file back to the server I could do a &action=purge and check the diff.
What diff? There are no diffs on files, only on pages. Let me be extra clear on this: ee.pl has two primary functions, editing text or changing files (images, sounds, videos etc.) on the server. These are very different in nature. Just double-checking that you've noticed that.
ok got it. I already installed ee.pl and played with it. I started looking at the code yesterday, I don't know perl but I could get the gist of it, need to study it more though. thanx for all your all suggestions.
Pat
wikitech-l@lists.wikimedia.org