Re: Intent of NavigatableComponent$isVisibleOnScreen()
On Monday, 20 November 2017 22:45:04 GMT Paul Hartmann wrote: > ... > This code is by Michael Zangl, so he would know much more about it. From > my understanding, isVisibleOnScreen() prevents the recalculation of the > location state when the component has not been added to the visible window. > At the same time, the method is intended to be overridden with constant > true in a situation where the NavigatableComponent is handled completely > off-screen (RenderingHelper and unit tests, see also [10405]). > > It would be good if RenderingHelper could be compiled without any > dependency on Swing classes (i.e. JComponent as super class of > NavigatableComponent). Michael has achieved a lot in this direction, but > there is still more to be done. :) Thanks for this. I have actually just been trying the tests with it patched out to true and indeed it doesn't seem to cause any additional failures or errors on my system. I'm thinking it would be extremely useful for the tests if the standard class were able to have a flag set (and unset) which would hard-wire this to true. This way, any of the complicated mocking or JOSMFixture re-initialization that might be required in other solutions I've been investigating would be necessary. Hell, it might be as simple as adding a straightforward GraphicsEnvironment.isHeadless() || (...) before the existing expression. robert.
Intent of NavigatableComponent$isVisibleOnScreen()
Hi, Just trying to decode some of the reasoning behind bits of NavigatableComponent - was wondering what case exactly NavigatableComponent $isVisibleOnScreen() is intended to protect updateLocationState() from. I'm looking at it thinking whether it's possible to make it more granular with a view to being able to use MapView more fully in tests, and its presence confuses me - if it's possible to patch it out with just a constant true (e.g. in gui.mappaint.RenderingHelper, even in headless mode, what is its purpose? Is it an optimization? Is it for cases when it might get called before a NavigatableComponent's added to a visible window? Is it for the CLI mode? If I knew I'd be able to see whether it can be replaced with something more specific. robert.
Re: [josm-dev] terracer plugin maintainer
On Thursday 12 May 2011, colliar wrote: Hi Thanks for this plugin. I use it quite often. It would get really useful with some improvements. -- trac I lately did not see any improvements. Is zerebubuth still aktiv. Otherwise the owner should not be set. Zerebubuth is Matt Amos and he is still very active in OSM though he may not have paid much attention to this plugin recently. He's zere on IRC if you want to talk to him. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Tuesday 08 December 2009, Matthias Julius wrote: What do you think? It's funny you should say this - I am currently working on a few things such as some proper geometry operations. It started with me doing some work on the extrude function and realizing it should really be able to work in real-space rather than projected-space. The way I was planning on doing this was to do the operation in in 3-space, in cartesian coordinates, then converting back to latlon. However, the ability to also do the operation in projected-space is quite important I think, as users are often tracing from imagery, in which case they will probably want WYSIWYG behaviour on the projection. In this vein, the way I was planning on doing it was to have a modifier key (hmm most of them are already taken aren't they?) to select between 2-space(projection) calculations and 3-space(real) calculations. One of the pieces of initial work would probably have been improving some of the datatypes like EastNorths, which make geometry operations pretty painful imho. We need more generic vector operations and perhaps even some 3-space vector types. I'm currently working on some more options (in plain-old-2D) for the extrude mode, and I haven't actually started coding all this stuff. Apart from extrusion I also thought the 'rotate' operation could do with ellipsoidally-correct calculations. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Tuesday 08 December 2009, Matthias Julius wrote: I guess local cartesian coordinates would be the best for things like orthogonalize since that's the way buildings are built. But, in practice, using Mercator should be close enough for real world building sizes. Close enough maybe, but I don't think doing the calculation in 3-space cartesian coordinates is significantly more complex. In fact, I'd argue that it's simpler. And remember people aren't just editing buildings. Think of rectangular landuse areas that may have side lengths kilometers long. In other words: if the current projection makes circles look like eggs then I would expect this to be true for both the imagery and the circles created by AlignInCircleAction. Yes, I understand that, but a user tracing imagery will probably be expecting the application to behave like a drawing application, with an 'extrude' operation extruding perpendicular to the object as seen on screen, not going off in some random direction that it thinks is clever. Some users don't understand/want to care about projections, and just want to draw things 'as-seen'. Take for example a straight edged object that's non-square, but happens to be distorted vaguely inversely to the map distortion, so that it appears nearly square on screen. A user wishing to trace it would get puzzled and frustrated with an extrusion going off in the seemingly wrong direction. This may be a far fetched case for extrusion, but I think it's a more obvious problem for rotation. A user using the rotation operation often doesn't actually want to literally rotate the literal object as they would in real life, rather people sometimes use it just to visually manipulate the data they're working with. In which case they would want to rotate in screen space, not real space. I don't know if I'm explaining this very well, but my point is I think maintaining the option to do operations in screen space is valuable, even if it is not the default. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Tuesday 08 December 2009, Tobias Wendorff wrote: I did the same, aprox. a year ago, but I don't have a clue, how to implement it in JAVA. Neither did I. I'm a c++ programmer, I just dived straight in. It's pretty straightforward, but painfully long-winded in areas for a higher-level language. 3D-geometry is pretty complex, For a lot of things it really isn't. It's just linear algebra. There are some corners where things can get complicated when dealing with ellipsoid geometry, but that can be figured out or we can compromise and put some spherical approximations in until someone comes along who cares enough about micro-accuracy to do it properly. The problem is, formulars of surviyors only work on 2D, so we've got to reinvent these for 3D ;-) What formulas of surveyors do we need? How many mappers do we have with theodolites who know how to use them? robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please add the walkingpapers description to the scan-info section in the HTML source for JOSM
On Tuesday 10 November 2009, Ævar Arnfjörð Bjarmason wrote: Cool. I've patched my fork here with this functionality: http://github.com/avar/paperwalking Sent a pull request to migurski/paperwalking. If only JOSM development were so flexible and easy. /me runs and hides. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please add the walkingpapers description to the scan-info section in the HTML source for JOSM
On Tuesday 10 November 2009, Dirk Stöcker wrote: If only JOSM development were so flexible and easy. /me runs and hides. Aiming with my long range rifle ... Do you wanna excuse? 10 .. 9 .. 8 .. In all seriousness, it would make life a lot easier for those of us who submit patches that people don't seem to have time to review[1], as it would allow us to continue developing in parallel until our branches got merged. With svn, if your patches aren't getting merged to upstream, you have to start doing horrible manual patch management. Or something involving svn tricks that I don't know about. DVCS raises the status of potential contributors bringing a patch democracy compared to svn's patch serfdom. I'm personally an advocate of Mercurial/bitbucket.org over git/github.org, as I find it easier to use and understand. And Mercurial is supposed to work better for windows users (I personally don't know). robert. [1] ahem https://josm.openstreetmap.de/ticket/3832 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] [PATCH] Extrude 'move along normal' and cleanups
Hi,
Attached is a patch against SVN 2374 which adds a feature to extrude mode: hold
ctrl while dragging to move an existing segment along its normal rather than
creating a new segment.
This is needed to be able to easily edit buildings etc after they have been
initially extruded.
In adding this, I touched most of the extrude mode code, removing some of the
more glaring problems (like editing logic in the painting code) and tried to
sanitize the mode's state machine. I also removed most of the remnants of the
select mode it was copied from for clarity.
There are a few other things I would like to do to extrude mode, such as make
the geometry work in real space rather then screen space - so that it's
projection independent. And I also want to make the hint line painting a bit
better. But this will have to do for now.
Please note I am a c++ programmer, not a java programmer, so comments are
welcome.
robert.
Index: src/org/openstreetmap/josm/actions/mapmode/ExtrudeAction.java
===
--- src/org/openstreetmap/josm/actions/mapmode/ExtrudeAction.java (revision 2374)
+++ src/org/openstreetmap/josm/actions/mapmode/ExtrudeAction.java (working copy)
@@ -12,7 +12,10 @@
import java.awt.Point;
import java.awt.event.KeyEvent;
import java.awt.event.MouseEvent;
+import java.awt.event.ActionEvent;
import java.awt.geom.GeneralPath;
+import java.awt.geom.Line2D;
+import java.awt.geom.Line2D.Double;
import java.util.Collection;
import java.util.LinkedList;
@@ -20,9 +23,11 @@
import org.openstreetmap.josm.command.AddCommand;
import org.openstreetmap.josm.command.ChangeCommand;
import org.openstreetmap.josm.command.Command;
+import org.openstreetmap.josm.command.MoveCommand;
import org.openstreetmap.josm.command.SequenceCommand;
import org.openstreetmap.josm.data.coor.EastNorth;
import org.openstreetmap.josm.data.osm.Node;
+import org.openstreetmap.josm.data.osm.OsmPrimitive;
import org.openstreetmap.josm.data.osm.Way;
import org.openstreetmap.josm.data.osm.WaySegment;
import org.openstreetmap.josm.gui.MapFrame;
@@ -35,14 +40,11 @@
/**
* Makes a rectangle from a line, or modifies a rectangle.
- *
- * This class currently contains some sleeping code copied from DrawAction (move and rotate)
- * which can eventually be removed, but it may also get activated here and removed in DrawAction.
*/
public class ExtrudeAction extends MapMode implements MapViewPaintable {
-enum Mode { EXTRUDE, rotate, select }
-private Mode mode = null;
+enum Mode { extrude, translate, select }
+private Mode mode = Mode.select;
private long mouseDownTime = 0;
private WaySegment selectedSegment = null;
private Color selectedColor;
@@ -56,10 +58,6 @@
*/
private Cursor oldCursor;
/**
- * The current position of the mouse
- */
-private Point mousePos;
-/**
* The position of the mouse cursor when the drag action was initiated.
*/
private Point initialMousePos;
@@ -67,7 +65,17 @@
* The time which needs to pass between click and release before something
* counts as a move, in milliseconds
*/
-private int initialMoveDelay = 200;
+private static int initialMoveDelay = 200;
+/**
+ * For translation, a the initial EastNorths of node1 and node2
+ */
+private EastNorth initialN1en;
+private EastNorth initialN2en;
+/**
+ * This is to work around some deficiencies in MoveCommand when translating
+ */
+private double alreadyTranslatedX;
+private double alreadyTranslatedY;
/**
* Create a new SelectAction
@@ -116,7 +124,6 @@
Main.map.mapView.removeMouseListener(this);
Main.map.mapView.removeMouseMotionListener(this);
Main.map.mapView.removeTemporaryLayer(this);
-
}
/**
@@ -127,41 +134,22 @@
@Override public void mouseDragged(MouseEvent e) {
if(!Main.map.mapView.isActiveLayerVisible())
return;
-if (mode == Mode.select) return;
-// do not count anything as a move if it lasts less than 100 milliseconds.
-if ((mode == Mode.EXTRUDE) (System.currentTimeMillis() - mouseDownTime initialMoveDelay)) return;
+// do not count anything as a drag if it lasts less than 100 milliseconds.
+if (System.currentTimeMillis() - mouseDownTime initialMoveDelay) return;
-if ((e.getModifiersEx() MouseEvent.BUTTON1_DOWN_MASK) == 0)
-return;
+if (mode == Mode.select) {
+// Just sit tight and wait for mouse to be released.
+} else {
+EastNorth en1 = initialN1en;
+EastNorth en2 = initialN2en;
+// This may be ugly, but I can't see any other way of getting a mapview from here.
+EastNorth en3 = Main.map.mapView.getEastNorth(e.getPoint().x, e.getPoint().y);
-if (mode == Mode.EXTRUDE) {
-
Re: [josm-dev] Extrude 'move along normal' and cleanups
On Sunday 01 November 2009, Dirk Stöcker wrote: What should this change mean? -return tr(Drag a way segment to make a rectangle.); +return tr(); The previous code used a 'mode' of null to represent the initial (non-dragging) state of the mapmode and an inconsistent use of the 'select' mode. I changed it so null is an invalid mode and 'select' is the initial mode. Hence at this this line I didn't know what to say when mode is null. Perhaps it should be some default extrude string - I don't know - but it should never happen. BTW: Best is to attach patches as Trac tickets. Noted. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Extrude 'move along normal' and cleanups
On Sunday 01 November 2009, Dirk Stöcker wrote: Then remove it. tr() results in the translators information string which is surely not wanted. Didn't think of that. I'll put the new patch on trac. robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [PATCH 1/2] QuadBuckets (using quad tiling) for node storage in JOSM
On Saturday 12 September 2009, Dave Hansen wrote: I've been hacking on the JOSM validator plugin for a while. One of the repeating hard problems that comes up are doing the UnconnectedWays tests. You need to do searches for every segment in a way to see if there are any nearby nodes. This generally means that you do a number of searches on the same order as the number of nodes that you have. ... Dave, I realize this is quite a crude reply to such a detailed email. Did you investigate kd-trees at all? http://en.wikipedia.org/wiki/Kd_tree robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] ewmsplugin - webkit-image bug
On Friday 19 December 2008 12:27, Hermann Schwaerzler wrote: it was richard scott who Oi. robert. (You must be the 500th person who's called me Richard. I'm considering changing my name seeing as it seems to be what people think I should be called.) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] ewmsplugin - webkit-image bug
On Wednesday 17 December 2008 11:32, Dirk Stöcker wrote: Hmpf, you are too far north and the image height is larger than your screen size. I found no way to tell Qt that it has a 2000x2000 virtual screen yet (Theoretically it would be enough to tell it the Yahoo-Javascript). It always adds the scrollbars, when size is your physical screen solution. Help welcome. My request in Qt mailinglist was not answered. your_qwebview.page()-setViewportSize ( const QSize ) ? and if all else fails, your_qwebview.page()-mainFrame()-setScrollBarPolicy ( orientation , policy ) (...sorry I can't test this right now.) robert. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
