[Potlatch-dev] Flash Player minimum version
Hi all, (This is partly a follow-up to Andy's mail of a few weeks ago!) We had a few reports on help.osm.org of P2 not working (the drag-and-drop icons on the left weren't appearing) and narrowed it down to the users still having Flash Player 10.1 installed. We were only using one 10.2 feature - the native mouse cursors (my fault!). 10.1 is, however, the last version that'll work on OS X PowerPC. It's a small number of machines but not an insignificant one. Ok, I might admit an interest here as my boat Mac is a G5. ;) I've therefore added a version check to the custom cursor code. If the user is still on 10.1, it just won't set the cursors. I've tested it with both 10.1 and 10.3 players and it seems to work fine. Flex 4.5 nominally requires 10.2 but, for now, seems to degrade to 10.1 fine - the main change AIUI is tweaks to the text layout engine. It is however possible that some of the more advanced Spark components may use opcodes not present in 10.1. I suggest we stick with 10.1 until there's a compelling must switch reason to _require_ 11+. If there's any nice-to-haves, like the native cursor support, we can use the version check. cheers Richard ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Flash Player minimum version
On 21/03/12 15:54, Andy Allan wrote: Ah, I wish that I'd known this earlier on - both that we had a mismatch between required versions (i.e. osm.org was requiring 10.1 instead of 10.2, hence the lack of warnings) and also that we were in the process of changing things around! The training course I was running earlier on had a bunch of people having major problems with 10.1 not working. By earlier on do you mean earlier today? Only we started requiring 10.2 about 9am today and that was only reverted back to 10.1 just before 11am when Richard's fixed version of Potlatch was deployed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] Flash Player minimum version
On 21 March 2012 16:00, Tom Hughes t...@compton.nu wrote: By earlier on do you mean earlier today? Only we started requiring 10.2 about 9am today and that was only reverted back to 10.1 just before 11am when Richard's fixed version of Potlatch was deployed. Yeah, I just read the commits. We were having trouble About 5 hours ago according to help.openstreetmap.org, which is, roughly, 11am. I've therefore no idea whether we were testing the current or previous build of p2! Bad timing really. Cheers, Andy ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OSM-talk] Way with only one single node
On 21 March 2012 12:56, Steve Bennett stevag...@gmail.com wrote: 1) We can fix this, but it's hard to prevent it coming back when new features are built. I've probably written such bugs. Mumble grumble unit testing. 3) I still think we should do this. We have a responsibility to not mess up the database. Saying well, we should avoid writing bugs isn't addressing that: we should both implement this failsafe mechanism, *and* avoid writing such bugs. Well, I'm not sure I agree on this one. If it was a truly awful thing to do, the API would prevent it. Given that it's not truly awful, it's not something to worry about too much. It's not messing up referential integrity, it's just something unexpected and, at the moment, seemingly useless. Furthermore, handling it at save time is, to me, the wrong thing to do. What do we do when we find our data has an issue? Alert the user? Silently swallow it? Neither is a good thing. Should that way be deleted? Should a node be re-inserted? What did the mapper mean to happen? We can't tell. Finally, in other projects I follow the convention of don't code defensively, as described at http://www.erlang.se/doc/programming_rules.shtml#HDR11 and elsewhere. The save code should trust that the data is good. If the data isn't good, whatever made it bad should be fixed. Otherwise it's turtles all the way down - should the save code check the ids are actually numerical, just in case, should it do x, y or z, just in case? So the answer is that the input should be checked, somewhere in the controller code, and then it should be trusted. Anyway, mumble grumble unit testing. When we find out what's the trigger, for the love of god someone should help me write the unit test so that when it's fixed, it stays fixed. Thanks, Andy ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OSM-talk] Way with only one single node
Andy wrote: Anyway, mumble grumble unit testing. When we find out what's the trigger, for the love of god someone should help me write the unit test so that when it's fixed, it stays fixed. I've corresponded with Thomas B and found some, ahem, fairly easy steps to reproduce: 1. Click on map (_once_) to start new way 2. With elastic band still engaged, click 'Save' 3. Whatever the opposite of PROFIT is Will look at it this weekend I guess. cheers Richard ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OSM-talk] Way with only one single node
On 21 March 2012 16:34, Richard Fairhurst rich...@systemed.net wrote: I've corresponded with Thomas B and found some, ahem, fairly easy steps to reproduce: 1. Click on map (_once_) to start new way 2. With elastic band still engaged, click 'Save' 3. Whatever the opposite of PROFIT is Will look at it this weekend I guess. My initial thought would be to not create the way until the second node was drawn. I think that would also remove a lot of the gnarlyness around POI creation, where we are footling with the way-that-we-never-actually-wanted as we finish handling the double click. Also, if anyone smarter than I am (Dave?) wants to point me in the right direction, I'd love to bind the controller state and the data state together a bit better, so that when you're doing things like undo you not only change the data, but put the controller into the appropriate state at the same time. That's only tangentially related to the above problem, however. Cheers, Andy ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
