taco909 wrote:

turbomkt wrote:

KuniaKid wrote:Popup info windows are generated directly under cursor not allowing selection of item.

This. It would be nice for pop ups to be offset in some way. Not sure if a corner (Places?) or slightly offset from cursor location so things aren't obscured. Otherwise, I leave pop ups off for segments at the least.

Ditto.

I would be okay with the popup near the cursor, but offset by far enough that it would not get in the way of a click.
Place points are the worst when mousing in from the left.
I'd be happy with an offset of "an inch" above the cursor.

Something is a bit odd with your setups then, because in both FF and Chrome the existing offset mechanism is still working just fine here - even if I slowly bring the pointer in from the left hand side of a point place, the popup only overlaps maybe the right-hand third of the point, leaving more than enough of it still visible under the mouse pointer for it to be clickable. Likewise with segment popups - they appear with a consistent offset to the right of the mouse pointer position at the time the segment highlight is first detected and processed.

To help track down what's going on with your setups, please can you do the following...

1. Assuming that, like most other editors, your WME setups are loaded down with other scripts, please test the popup behaviour with everything disabled except URO. If this results in an improvement, please then try re-enabling the others one by one until the popup behaviour reverts to what you normally see.

2. Post a screengrab of the entire WME window, including all of the sidebar, topbar, bottom bar etc. etc. plus any scrollbars within the browser window. Preferably take the screengrab with a popup displayed so I can see how bad the offset (or lack of) is... I don't need to see the browser address bar/bookmarks bar/list/etc, just what's within the "active" part of the browser window when WME is running and the popups are being incorrectly offset.


Thanks,
Chris

bz2012 wrote:"Hide for this session" doesn't seem to do anything.

win7 ent, chrome 51.0.2704.106 m all current updates.

Has it stopped working for both URs and MPs, or just one or the other?

Does the Chrome console (Ctrl+Shift+I) show any errors when you click on the "Hide for this session" link?

When you click on the link, do the "Undo last hide"/"Undo all hides" buttons appear at the bottom of the URO tab?

SanzClew wrote:Anybody else coming across a crash when toggling the WSLM custom icon flag? When I mouse over Chrome just dies, no matter what computer I'm on. Using a regular UR marker, I can see and use it like any other.

Nope, haven't experienced any problems with the WSLM icon. I'm assuming the non-mouseover custom marker is being displayed OK here, and that you're using the latest version of URO?


A few versions ago I changed how the custom markers were handled - originally URO itself rendered them all on top of the native ones, which was both resource-hungry and also required URO to deal with changing the markers as and when they were moused-over/out or marked as closed.

In the most recent versions however, URO now takes advantage of the native marker rendering/mouseover/open/closed/etc handling in WME by simply replacing the default image collection for each tagged marker object with the appropriate custom image collection.

So if the markers are being displayed with the correct custom marker when not being moused-over, this shows that URO is replacing the default image collection as expected, and from then on it's up to WME to handle things. My first thought would then be that the custom image collection for the WSLM markers has somehow become corrupt in your script installation, so that when you mouseover those markers, WME is trying to display image data that is damaged in such a way that it's killing the image rendering part of the browser.

As a first attempt to resolve this problem then, please can you try uninstalling and then reinstalling the script, making sure you're taking the latest version available from the Chrome Store and not any older version you may have stored locally on your system.

Do you have UR backfilling enabled, and if so does the problem go away if you disable it?

3.82 now shows/hides the feed filter controls via a clickable toggle icon rather than automatically on mouseover/exit. Also, the keyword feed filter can now be set to filter either if the keyword is present or if it's absent, independently of the invert filter setting.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

3.83 restores operation in the beta. Note that due to the (aparently really quite pointless) change in URL, any settings you had previously saved in the beta editor have now been lost. Nice one devteam


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

3.84 fixes the "Next->Done" button hack for URs and PURs opened from the feed, and adds filtering by editor name for cameras.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

3.85 resolves a potential bootloop issue triggered during population of the user ID list for camera filtering.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

iainhouse wrote:I'm seeing significant issues with the latest update, possibly caused by the addition I asked for: filter cameras by user, for which I thank you greatly.

This seems to have been triggered by something particular to the camera data within central London, and how the associated user ID list is generated - I was using 3.84 quite happily earlier today editing around the fringes of London, but all hell broke loose when I started looking at some URs in the central area... Of course, there's always the possibility that HQ pushed out a sneaky WME update this evening that broke something.

dbcm wrote:Hi, i'm getting this error:

wme_uroverview.3.85.user.js:283 Uncaught TypeError: Cannot read property 'style' of null

Do you have any cameras listed in the OWL tab?