Is there support for Opera? Searched for it in here but it has never been mentioned.
Re: [Script] WME Toolbox (1.7.12)
Posted: Mon Oct 30, 2017 5:54 am
by thanior
Hello!
When will this script get update? Without WME Toolbox it's hard to work. :/
e.g. I don't see revcons and loops and u-turns instantly on the map.
Regards,
Viktor
Re: [Script] WME Toolbox (1.8.0)
Posted: Tue Oct 31, 2017 11:35 pm
by thanior
Very big THANK YOU @BellHouse! \o/
Re: [Script] WME Toolbox (1.7.12)
Posted: Tue Sep 26, 2017 1:45 pm
by TheChrisK
Having an issue opening the keyboard shortcuts menu in Chrome. The config box does not show and the console throws this error.
I've tried:
* A reinstall
* No Tampermonkey scripts
* Different machine
Thanks.
Re: [Script] WME Toolbox (1.8.3)
Posted: Fri Dec 08, 2017 7:23 pm
by TheChrisK
I agree with everyone here that RevConns provide a glaring indication of a potential new editor and usually other map issues by non-newbies. WME Magic has really improved the way we find map issues but that doesn't always uncover a new editor. The bright purple triangle always lead to a closer look in that area where other tools were then utilized to find potential editors who are not in our community.
If the RevConns are no longer important or needed as indicated by Waze Staff, why lock the indicators to R5? Why not just remove them altogether? In the same regard, if they are not doing anything anymore, why not keep visibility to the way it was?
Re: [Script] WME Toolbox (1.6.11)
Posted: Fri Jan 29, 2016 3:59 pm
by TheLastTaterTot
I also see a translucent, black vertical bar on my editor screen and it's even longer than the one uscwaller is seeing. It does not move and cannot be clicked, but it seems to be overlaid on top of everything within the WME DOM window. I appended a test div element with an opaque background onto the page and set the z-index to 99999 and was unable to cover this black bar artifact. Since I am unable to select it, I cannot find it via the Element inspector. I think it looks like it could be a Mac OS scroll bar and since it doesn't respond to anything, it feels like a scroll bar from a DOM object set to pointer-events: none. Hope that helps.
Re: [Script] WME Toolbox (1.6.11)
Posted: Fri Jan 29, 2016 4:09 pm
by TheLastTaterTot
I started testing every DOM element created by Toolbox and found the cuprit. Good thing I started from the bottom-up since it was one of the last TB elements on the page. Lol
$('#WMETB_HelpDiv').css('overflow','') solves the problem, as well as $('#WMETB_HelpDiv').css('display','none'). In general, might I recommend using "display: none" rather than "visibility: hidden" and a negative z-index? If the goal is to simply tuck an element away on the page for when it's needed, "display: none" is less obtrusive.
In any case, thanks for all your work on a very useful extension!
Re: [Script] WME Toolbox (1.6.11)
Posted: Fri Jan 29, 2016 11:01 pm
by TheLastTaterTot
BellHouse wrote:
With which browser and OS are you having that issue?
Happy to have helped! I'm currently running Chrome Version 48.0.2564.82 (64-bit) and Mac OS 10.10.5.
Re: [Script] WME Toolbox (1.6.14)
Posted: Sat Feb 27, 2016 12:57 am
by TheLastTaterTot
I've been getting this weird behavior where random text seems to disappear from the page. Is anyone else experiencing this? After toggling scripts on/off, I've narrowed it down to Toolbox. With just Toolbox and no other userscripts or extensions running, I get the following:
It is reproducible. When I turn off Toolbox, everything returns to normal. Turning Toolbox back on, the text disappears again. However, there is a randomness aspect to it as well. If I select/deselect some more segments, eventually the text may come back. Also, if I fiddle with the visibility/opacity of a single text field, all text fields will return to normal.
I'm running Chrome Version 48.0.2564.116 (64-bit) on Mac OS 10.10.5 using the latest Toolbox in the Chrome store.
Thanks for taking a look!
Re: [Script] WME Toolbox (1.6.14)
Posted: Mon Mar 28, 2016 9:14 pm
by TheLastTaterTot
SuperDave1426 wrote:I don't know if someone has already requested this, but in case they haven't:
Feature enhancement request for the color highlighting for speed limits: Would it be possible to change the way that it colors the edges of a street to make it obvious when a speed limit hasn't been confirmed/verified? Maybe a broken color band for unverified, and solid (as it is now) for those speed limits which have been verified? The colors are useful for when scanning an area for speed limits, but if Waze has decided on a speed limit that hasn't been verified by an editor yet, there doesn't seem to be any way of knowing this. Kind-of defeats being able to use colors to tell where speed limits haven't yet been set...
So if that's something that could be added, it would be great!
If you do end up trying it out, here's something that you can import into RSel Highlights... You'll probably have to also select the checkbox for the setting "Play nice with other highlighting scripts":
