Re: [Wikitech-l] Provide a well-performing API to rotate an image
Apologies if I'm missing something but is there any reason why we can't do image rotation on the client using the canvas JavaScript api? Client side rotation takes ages, especially with big files. Agreed! Most of that probably should be non-destructive editing that keeps the original and applies crop/rotate/filters along with thumbnailing as necessary. I suggest that we keep status quo. It has worked perfect for years. Just fixing thumbs does not fix the file itself and we want to have the file itself fixed. Date: Fri, 17 Jul 2015 19:30:44 +0800 From: jdlrob...@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an image Apologies if I'm missing something but is there any reason why we can't do image rotation on the client using the canvas JavaScript api? On Thu, Jul 16, 2015 at 3:45 PM, MZMcBride z...@mzmcbride.com wrote: Brion Vibber wrote: Allowing override of the thumb rotation would provide you real time rotation... I'm not sure about the need to rotate the original file; ideally original files should be left as-is and kept archival. In my opinion, we need to solve image rotation as part of a larger project to support in-browser rasterized image manipulation. A bot shouldn't be necessary here. We should have the ability, in a Web browser, to crop, rotate, and make other basic manipulations to rasterized images. The fact that we have a media repository using software called MediaWiki that doesn't include an in-browser basic photo editor is pretty silly. Agreed! Most of that probably should be non-destructive editing that keeps the original and applies crop/rotate/filters along with thumbnailing as necessary. That'll take some more infrastructure work though. Of course if you're going to draw on a picture that'll require uploading a new version. -- brion ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] VE plugin related questions
Hi all, I have been working on a small VE plugin that provides the functionality of adding SMW annotations. I am mostly done with the script but need to understand some minor coding practices for VE plugins to complete it. Would appreciate some help on these questions. When the script makes some changes to the document model, sometimes the Save button stays greyed out. Is there a way I should trigger the save button to become active? Or maybe I am doing something in the wrong way. The undo doesn't seem to automatically work for my code, what's the best way to develop that functionality? I have a couple more doubts, but these are the major ones right now. Here's my code if needed, its a mess right now and needs lot of refactoring, etc https://en.wikipedia.org/wiki/User:Nischayn22/veSMW.js Thanks and regards, Nischay Nahata ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator filter by language
On Fri, 2015-07-17 at 10:04 +0200, Petr Bena wrote: What if we added extra projects to phabricator for programming languages (such as language-php, language-c) which could be optionally added to some tickets if help of people who know these languages would be needed. So that it would be possible for example to c++ experts to filter out open tasks that need c++ expert to look in them and so on? Currently I have few of such tasks that I would like to have experts in some language to look at, but there isn't really an easy way to do that. What you think? Should we add these meta-projects? If there was enough shared interest to add such tags, they should have a naming format need-XYZ-help or such. Whenever a new tag is created, you need to raise awareness so 1) tasks actually gets tagged and 2) people get to know they are supposed to search for such tags. Communicating to your target group, maybe. A tag language-php would not imply it's optional. Searching for tasks under a project/tag, I'd expect results not to be optional results. Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] AccountAudit extension will be undeployed soon
Hi, Now that SULF is over, we have no need for the AccountAudit extension anymore. If you have been relying on it for any statistics, please be aware that a) it is going away soon and b) the data is generally inaccurate for global users (which all users are now). Please follow https://phabricator.wikimedia.org/T105894 for updates. Thanks, -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Phabricator filter by language
Hi, What if we added extra projects to phabricator for programming languages (such as language-php, language-c) which could be optionally added to some tickets if help of people who know these languages would be needed. So that it would be possible for example to c++ experts to filter out open tasks that need c++ expert to look in them and so on? Currently I have few of such tasks that I would like to have experts in some language to look at, but there isn't really an easy way to do that. What you think? Should we add these meta-projects? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator filter by language
You can already infer some languages from the project: Pywikibot → Python, Hierator → Java etc. And nearly any other one will have language-php then. But for C++ it might still make sense. Il 17/07/2015 10:04, Petr Bena ha scritto: Hi, What if we added extra projects to phabricator for programming languages (such as language-php, language-c) which could be optionally added to some tickets if help of people who know these languages would be needed. So that it would be possible for example to c++ experts to filter out open tasks that need c++ expert to look in them and so on? Currently I have few of such tasks that I would like to have experts in some language to look at, but there isn't really an easy way to do that. What you think? Should we add these meta-projects? ___ 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
Re: [Wikitech-l] Phabricator filter by language
That's not useful at all. What is I wanted to filter out all tickets that need some python expert to look at them? How is knowledge that pywikibot uses python good for that? I don't need this per project, but per ticket. For example I need a CSS expert to look at some ticket of huggle, which is a C++ project. I would happily flag it need-css-expert or whatever but there is no option for that. Also if I was an expert in some expert, I would like to be able to filter out tickets made by people who need me :P On Fri, Jul 17, 2015 at 10:25 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: You can already infer some languages from the project: Pywikibot → Python, Hierator → Java etc. And nearly any other one will have language-php then. But for C++ it might still make sense. Il 17/07/2015 10:04, Petr Bena ha scritto: Hi, What if we added extra projects to phabricator for programming languages (such as language-php, language-c) which could be optionally added to some tickets if help of people who know these languages would be needed. So that it would be possible for example to c++ experts to filter out open tasks that need c++ expert to look in them and so on? Currently I have few of such tasks that I would like to have experts in some language to look at, but there isn't really an easy way to do that. What you think? Should we add these meta-projects? ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Provide a well-performing API to rotate an image
Apologies if I'm missing something but is there any reason why we can't do image rotation on the client using the canvas JavaScript api? On Thu, Jul 16, 2015 at 3:45 PM, MZMcBride z...@mzmcbride.com wrote: Brion Vibber wrote: Allowing override of the thumb rotation would provide you real time rotation... I'm not sure about the need to rotate the original file; ideally original files should be left as-is and kept archival. In my opinion, we need to solve image rotation as part of a larger project to support in-browser rasterized image manipulation. A bot shouldn't be necessary here. We should have the ability, in a Web browser, to crop, rotate, and make other basic manipulations to rasterized images. The fact that we have a media repository using software called MediaWiki that doesn't include an in-browser basic photo editor is pretty silly. Agreed! Most of that probably should be non-destructive editing that keeps the original and applies crop/rotate/filters along with thumbnailing as necessary. That'll take some more infrastructure work though. Of course if you're going to draw on a picture that'll require uploading a new version. -- brion ___ 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
