Benutzer Diskussion:Dapete/Archiv ImageMapEdit
Dies ist ein Archiv von (teilweise) unerledigten Diskussionen zu ImageMapEdit.
ImageMapEdit
[Quelltext bearbeiten]hi.
so i'm trying to use your imageMapper (from 'http://toolserver.org/~dapete/ime/ime.js') on hebrew wikipedia, and there is a slight problem.
the issue is that a lot of calcs are done, presuming that previewdiv and the image overlap exactly, but on RTL wikis this does not happen.
the remedy is very easy: make sure divFile is ltr: in function ime_init2(), just after
divFile.insertBefore(divImeContainer,tempNode);
divFile.removeChild(tempNode);
add
divFile.style.direction = 'ltr';
and now we can use it in hebrew (and i would guess, all other rtl) wiki also.
thanks a bunch, קיפודנחש 23:50, 6. Mai 2011 (CEST)
- Thanks for the report, and also for the solution - adding the line has solved the problem for now. Only if I ever add a translation in a rtl language, I will have to find a better solution (but that would involve a lot more changes as well, as far as I understand) …
- I guess this is a typical problem with developers who only use ltr languages. To avoid this I will from now on test things like these in at least one rtl wiki. I have no excuse anymore if I break anything :) --dapete 09:35, 7. Mai 2011 (CEST)
- vielen dank. tested it and it works (although my solution was a bit on the too-simplistic side: it would work better for us if the bottom of the page, with all the input fields would have stayed RTL). you might be interested to know that we (i.e. hebwiki) now added the tool to common.js (because it's "importurl", we test first and only link to it if user is in namespace 6, but other than that it's just "in" for all users). Thanks again for creating this super-useful tool! i wonder if it's enough to set "ltr" on imeContainer ? (much harder for me to test now, b/c your tool is linked unconditionally...) peace, קיפודנחש 02:01, 8. Mai 2011 (CEST)
- Loaded by default? I guess I should make a the translation a priority :) I don't know when I'll have time for this, but I will try to find a better solution for the "rtl problem" that doesn't have to change anything to ltr (or at least nothing that makes any visible changes like it does now).
- In the meantime it would be great if you could translate the text (see meta:User:Dapete/ImageMapEdit/translation template). This will give me some real text to work with (I think I need that) and will also motivate me to finish this. --dapete 07:52, 8. Mai 2011 (CEST)
- so i added hebrew tranlsation there. thanks. קיפודנחש 17:21, 8. Mai 2011 (CEST)
ImageMapEdit/jQuery
[Quelltext bearbeiten]also: reading the code, you might want to consider using $.extend(): e.g. instead of
function ime_RectCoord(x1,y1,x2,y2) {
this.left = x1;
this.top = y1;
this.right = x2;
this.bottom = y2;
}
the following is shorter, and IMO just as readable.
function ime_RectCoord(x1,y1,x2,y2) { $.extend(this, {left: x1, top: y1, right: x2, bottom: y2}); }
in many places using $.extend() not only shorten the code, but actually makes it clearer and simpler. peace, קיפודנחש 19:23, 9. Mai 2011 (CEST)
- (I moved this to its own section to make it easier to keep track.) Thanks. I'm already working on a version that uses jQuery for everything (my progress so far: http://toolserver.org/~dapete/ime/ime_jquery.js) and will include that in there. --dapete 20:34, 9. Mai 2011 (CEST)
- so i played with ime_jquery.js (btw: translation works!), and for the "direction = ltr" part, it's anough to set it for divImeContainer, rather than for the whole divFile. this makes a difference for the input fields, where it's a bit of a pain to enter the title and link in an ltr input field on an rtl wiki. as usual, thanks + peace - קיפודנחש 02:08, 13. Mai 2011 (CEST)
Feature Request für ImageMapEdit
[Quelltext bearbeiten]Hey Dapete,
erst einmal ein großes Dankeschön, für das ImageMapEdit, das ist ein tolles Script/Tool. Ich wollte nur mal einen kleinen Feature Request los werden, der auch schon hier geäußert wurde: nämlich die Möglichkeit alle bzw einzelne Bereiche gezielt zu verschieben. Das wäre ungemein hilfreich, falls sich die dazugehörigen Regionen im Bild verschoben haben, z.B. weil das Bild anders aufgebaut ist, oder die Ränder zurecht geschnitten wurden.
Ich kann mir sehr gut vorstellen, dass das nicht unbedingt ein triviales Feature ist und ich kann verstehen, falls du das für nicht lohnenswert erachtest (Aufwand/Nutzen-Verhältnis) oder einfach nicht dazu kommst, weil es zu viel anderes zu tun gibt. Trotzdem wollte ich den Wunsch einfach mal los werden.
Viele Grüße --Frog23 10:43, 26. Mai 2011 (CEST)
I can't get ImageMapEdit to work inside my wiki
[Quelltext bearbeiten]Hello,
I have a MediaWiki here: http://www.informationtamers.com/WikIT/
and have successfully enabled image mapping but can't get ImageMapEdit to work from inside the wiki.
I'm using Monobook, with mild style customization, but I have also tried on a different wiki with no customization and the Vector skin, and the problem is the same. Both wikis are using MediaWiki 1.16.5 / MySQL 5.1.54 / PHP 5.2.17 / and I have tested this in IE and FF (also Chrome, but I know it's not expected to work with that).
I have three problems of ignorance (at least):
1. I'm not sure if 'personal common.js file' refers to a wiki page (User:WikITSysop/common.js in my case) or an actual file, and if it's a file where I should put it.
2. If it refers to a wiki page I am not sure that this:
http://www.informationtamers.com/WikIT/index.php?title=User:WikITSysop/common.js
is really the right place to load the statement (my user name is WikITSysop).
3. I assume 'image description pages' refers to pages like this:
http://www.informationtamers.com/WikIT/index.php?title=File:Prefuse.jpg
Is that right? If not, maybe I'm looking in the wrong place.
I have added
importScriptURI('http://toolserver.org/~dapete/ime/ime.js');
to various locations without success. Here's where I tried :
http://www.informationtamers.com/WikIT/index.php?title=User:WikITSysop/common.js
when that didn't work I tried
http://www.informationtamers.com/WikIT/index.php?title=MediaWiki:Common.js
But that didn't work either, so I removed it.
I refreshed to reload the cache, several times.
Can you tell me what I'm doing wrong, please?
Thanks,
Roy Grubb 219.77.175.217 16:00, 6. Jun. 2011 (CEST)
- Hi Roy, basically you did this correctly, and looked in the right place if it worked. I found two problems, though:
- The user-specific common.js was only introduced in MediaWiki 1.17 - in 1.16 you will have to test this with monobook.js (or vector.js).
- User-specific .JS and .CSS seems not to be enabled on your wiki (whatever I put in "my" monobook.js or monobook.css - I created an account - does not work). See $wgAllowUserCss and $wgAllowUserJs how to enable this for CSS/JS.
- What I suggest is you try it in MediaWiki:Common.js again (and really make sure you bypass the cache - Ctrl-Shift-F5 in Firefox), because I can see the current contents are included in all pages of your wiki. If that does not work, enable $wgAllowUserJs and try to include it in your user monobook.js. If that fails, too, let me know again - at least if I can edit my own user .js, I can test myself what the problem is. --dapete 21:22, 6. Jun. 2011 (CEST)
- Thanks for your time on this and the help.
- I am not using 1.17 because it's in Beta. As the wiki I linked to before uses a slightly modified monobook, I decided to try your suggestions on the other wiki I mentioned. That is using an unmodified vector skin, so I thought it would be a cleaner environment. It is here:http://www.information-organizer.com/visionair-e/ The only things I've changed in that are the logo and adding an All pages link to the left margin Navigation block.
- First I appended
$wgAllowUserJs = true; $wgAllowUserCss = true;
- to LocalSettings.php in both wikis. Just out of interest I then tried adding the
importScriptURI('http://toolserver.org/~dapete/ime/ime.js');
- command to http://www.information-organizer.com/visionair-e/index.php?title=User:Visionairesysop/common.js again (actually I deleted that and added it back in case the act of adding it was needed after the change to $wgAllowUserJs.
- The page I'm testing for the editing link is
- http://www.information-organizer.com/visionair-e/index.php?title=File:Components.jpg
- I repeatedly refreshed in FF and even tried on a PC that had never accessed the wiki before. That didn't work so I deleted the content of User:Visionairesysop/common.js again.
- Next I did the same with http://www.information-organizer.com/visionair-e/index.php?title=MediaWiki/vector.js as you suggested. Followed by http://www.information-organizer.com/visionair-e/index.php?title=MediaWiki/common.js
- I repeatedly refreshed in FF but I still don't see the link for editing the image map, and again I tried accessing from yet another PC to ensure it wasn't a cache problem. It's mystifying.
- Roy Grubb
- 219.77.175.217 08:24, 7. Jun. 2011 (CEST)
By: Aidan Whitehall
- Roy, did you get this sorted? I'm in almost exactly the same boat with our local Intranet. Have just upgraded from MediaWiki 1.9.3 to 1.16.5, and am struggling to get ImageMapEdit to work. I've added
$wgAllowUserJs = true; $wgAllowUserCss = true;
to LocalSettings.php, and have created pages at MyWiki/User:Aidan/vector.js (am using the Vector skin) and MyWiki/MediaWiki:Common.js, both containing the line
importScriptURI('http://toolserver.org/~dapete/ime/ime.js');
If I browse to that URL on toolserver.org, I can retrieve the JavaScript file (so it's not a firewall issue), I've disabled AdBlock in Firefox for MyWiki, and doing a "View Source" of the image I'd like to map (at File:SomeImage.jpg) shows no reference to "toolserver.org" in the page source code (which is presumably why I'm not seeing any image map editing options in the page).
I've repeatedly refreshed, so it's not a cache issue. Any ideas anyone?
EDIT: Ah, having added:
alert("Hello World");
to MyWiki/User:Aidan/vector.js, a "Hello World" popup is displayed on every page request, which is evidence that the "vector.js" is being changed in some way... so perhaps it's an issue with importScriptURI()?
As per some MediaWiki upgrade instructions I read, I preserved the old LocalSettings.php from the old installation, so maybe there's a setting I need to enable in it to allow importScriptURI() to work...?
Thanks,
Aidan Whitehall
- Hi Aidan, Thanks for your input - no I haven't found what's blocking the link to the external script. I tried your alert trick, and got the same result. I also tried putting an alert in MediaWiki/vector.js just to see what happened, but that did nothing obvious. Not too surprising that, for a page with wiki-wide scope. Roy Grubb 219.77.175.217 18:20, 8. Jun. 2011 (CEST)
- Roy, just a quick note before I look at this - it's "MediaWiki:", not "MediaWiki/", that's the reason that particular change did not work. I'm now looking at your problem from above. --dapete 18:57, 8. Jun. 2011 (CEST)
Hopefully I have to solution: Roy does not have jQuery loaded on his wiki, and I assume that's the problem for both of you. I had assumed this was included in 1.16+, which it isn't, and the code I had put in to load "my own" jQuery if none was already loaded did not work (because it was fundamentally flawed). I have created a wrapper script which should make this work correctly, include this instead:
importScriptURI('http://toolserver.org/~dapete/ime/ime_loader.js');
I could not fully test this because, Roy, the ime.js script is already loaded globally before I load the wrapper script in my user JS. Please both of you try to replace the script and let me know if this solves the problem. --dapete 19:29, 8. Jun. 2011 (CEST)
- Hi Dapete -- yes, that works! thank you :) By the way, I noticed an interesting side-issue. The first image I was using it with was uploaded with the file name Pumps & Nozzles Window.png. After changing the .js reference to ime_loader.js , this image still didn't display the ImageMapEdit > link (no matter how many times I cleared the cache and forced a reload of the page). By chance I looked at a difference image, and the ImageMapEdit > link was displayed on that page. I confirmed that it appears to be the & in the image file name that is causing the problem by uploading another file with an ampersand in it; that too doesn't display the ImageMapEdit > link.
- If I can find out how to get jQuery in the Wiki, then I'll revert to using the standard ime.js file.
- Thank you for your help and quick reply! -- Aidan Whitehall, 09/06/2011
- Hi Dapete,
- On the "MediaWiki/" error - thanks - that was my mental mix up.
- Like Aidan, I'm making progress. Not fully there, but it seems now to be down to a browser dependency.
- I have deleted User:Visionairesysop/common.js, MediaWiki/vector.js and MediaWiki/common.js
- I have added
- importScriptURI('http://toolserver.org/~dapete/ime/ime_loader.js');
- in MediaWiki:Vector.js because I want all users to have access to image editing.
- This works in FF and Chrome, but not IE8 on XP SP3 or IE9 on Vista. I checked in IE with multiple refreshes - the link does not appear.
- Just for the record, none of the files in my test have an & in the filename.
- Roy Grubb 219.77.175.217 16:10, 9. Jun. 2011 (CEST)
- Dapete & Roy
- Further to Roy's comments, yes, I too believe there is (at least) an IE8 issue.
- I tested the extension on another user's PC (Windows 7 Professional) which had IE8 installed, and the ImageMapEdit > link didn't appear. I installed Firefox 4, and using her same MediaWiki profile, the ImageMapEdit > link did appear.
- On IE 8 on my PC (Windows XP Professional SP3), the error in IE says
- User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET4.0C; .NET4.0E; MS-RTC LM 8)
- Timestamp: Thu, 9 Jun 2011 14:54:41 UTC
- Message: Object expected
- Line: 49
- Char: 1
- Code: 0
- URI: http://toolserver.org/~dapete/ime/ime.js
- despite the only code reference in MyWiki/User:Aidan/vector.js being the one to ime_loader.js
- Aidan Whitehall, 09/06/2011
- OK, so I think this is just IE8 not liking new jQuery loading method, either... (BTW, it's correct that ime.js is still loaded - all ime_loader.js does is make sure to load jquery if it's not already there, and then load ime.js). I'll see if I can find a solution.
- I will also look at the problem with & in the filename - that's probably an old problem, I believe & is not allowed in file names on Wikipedia, so probably noone here would ever have found this. --dapete 18:42, 9. Jun. 2011 (CEST)
- Thanks, Dapete. With regards the file names, whilst the title of the page is displayed as File:Pumps & Nozzles Window.png, the URL of the file you edit is MyWiki/index.php/File:Pumps_%26_Nozzles_Window.png. I realise MediaWiki isn't wild about certain file-naming practises, but it appears to allow the upload of the file, despite it's original file name. If we have to just change a few file names so they include and instead of & to workaround this issue, it's no big deal. It's working in Firefox, so for now, we're very happy!
- If more users on our LAN want to use ImageMapEdit, then being able to use IE would be a big help too... but we have something that is useable, so Thank you! for your s/w & help :)
- Aidan Whitehall, 09/06/2011
- It doesn't work with IE8 in Wikipedia, either; so it's not a jQuery loading issue (it's definitely already there), but a does-not-work-with-IE8 issue. Which means it will take me a while until to get to the bottom of this, because it involves a lot of checking. --dapete 22:06, 9. Jun. 2011 (CEST)
- Just to +1 on Aidan's thanks for your work on this. I'll have a note on my wiki that this function is Chrome and FF only. And for the record, as Aidan mentioned FF 4, I was using FF 3.16 so probably all users of recent versions will be OK. Roy Grubb 219.77.175.217 05:11, 10. Jun. 2011 (CEST)
more fun with imagemaps
[Quelltext bearbeiten]hi.
you might be interested in a little script i am developing for hebrew wikipedia, to make imagemaps a bit more useful (IMO). i made 0 attempts to make it generic (i.e., suitable for LTR), but there is only one place (creating a new <li> element) when this comes into play, so it would be very easy to convert it to ltr.
what the script does is this: it extracts from the imagemap a list (by order) of all the areas, and generates a textual list of the areas titles and links under the image (i.e., each list item is a link, showing the title - just like the corresponding area). then, it creates event handlers, such that every time the mouse enters a "hot area", the appropriate list item is highlighted (currently i use a yellow background for highlighting).
all this is boring - the real "killer" is the opposite direction: whenever you float the mouse above one of the items in the list (or over one of the areas in the image), the appropriate area is highlighted on the image. to do that i use "canvas", which is supported by all the sane browsers, plus IE-9 (although IE support is slightly buggy). unfortunately, it is not supported by IE 6,7,8.
i think that this can make an imagemap element much more useful, because it gives the viewer a list of all the "hot" areas, and give them a very convenient way to locate them on the image or the drawing.
my script does one more small thing: the list is "collapsed" (by title), i.e., if you have multiple areas with the same title, there will be only one entry in the list, and entering any one of those areas or the corresponding list item, will highlight them all.
i am mildly proud of this script, esp. since it does all that in 99 LOC. if you want to try it, add the lollowing line to your common.js in hebrew wikipedia, and then look at w:he:משתמש:קיפודנחש/אנטומיה (you'll have to scroll down a bit - the top several imagemaps do not use this script). so here is the script:
https://raw.github.com/fur-hebwiki/heb-wikipedia/master/imageHighlight.js
i don't remember if i mentioned it before, but your imagemap tool is now part of common.js on the hebrew wikipedia. if you have any qustions about my script, please ask on my userpage in heb-wiki.
Imagemap on Internet Explorer 9 and Google Chrome 20.0.1132.57
[Quelltext bearbeiten]I tested your "ImageMapEdit" on internet explorer 9 and not get any problem. The coordinates x, y are OK, the only problem I found was the disbanding of the coordinates when you use the tool and I come down a bit 'with the scroll bar.
Instead in Google Chrome 20.0.1132.57 there are no problems.
I add some screenshot about Imagemap edit and Internet Explorer 9:
Raoli (Diskussion) 00:21, 1. Aug. 2012 (CEST)
- Can I be useful to translate it into Italian? I have already translated the explanations in your page http://meta.wikimedia.org/wiki/User:Dapete/ImageMapEdit # Installation_2
- Thank you --Raoli (Diskussion) 00:32, 1. Aug. 2012 (CEST)
- Hi Raoli, thanks for the translation of the instruction page. If you look at the entries
abovehere, you will see I've been collecting a to-do list for a long time. To fix some of the things, I basically have to start from zero and write everything again; I have not been motivated enough to do that yet. If I ever do it (and I fear I might never...), I will let you know so you can help me get a Italian translation. --dapete 21:16, 2. Aug. 2012 (CEST) Edit: Linked to the discussions I just archived. --dapete 21:24, 2. Aug. 2012 (CEST)
- Hi Raoli, thanks for the translation of the instruction page. If you look at the entries