Re: [josm-dev] [PATCH] timestamp parsedTimestamp in OsmPrimitive
On Mon, 9 Mar 2009, Jiri Klement wrote:
Calling functions twice is always bad design for multiple reasons. Use a
temporary variable here.
OK, I've fixed that. Way is calling functions twice bad design? Is
OsmPrimitive supposed to be thread safe?
Code will be changed later. When a variable should represent a value then
call it once or changes may miss the second call. Also it is not sure
that compilers optimize the two calls into one and some other reasons
also apply which are of minor importance.
b) This whole block should be in the new class. It's pure time logic.
String timestr = p.getString(time);
if(timestr != null)
{
timestr = timestr.replace(Z,+00:00);
n.setTimestamp(new DateContainer(timestr.replace(Z,+00:00)));
}
I don't agree with this one. DateConverter seems to expect date in
multiple different formats while code here seems to be sure that the
date is in some specific format. So I think this is gpx specific.
No. Actually that is a workaround to convert Z (i.e. Zulu time) to
offset form, because GPX files have Zulu representation very often.
c) Same for this one.
public int compareTo(HistoryItem o) {
return
unifyDate(osm.getTimestamp().getAsDate()).compareTo(unifyDate(o.osm.getTimestamp().getAsDate()));
Again, this is imho specific to history dialog.
I though it is clear what I meant:
It should be return osm.getTimestamp().compareTo(o.osm.getTimestamp());
Whatever conversion needs to be done must be inside the date class.
I do not know what unifyDate() does, but surely it is meant to have proper
time checking only.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On 09/03/2009 11:24, Frederik Ramm wrote: Hi, Stefan Breunig wrote: Try double clicking. Would we lose anything by simply reinstating the old shift behaviour? Indeed. AFAICS shift is unused now. Remember Habit gets built into the fingers, changing it arbitrarily is not a good thing to do when there doesn't seem to be an overwhelming need to change it. The double click is too early. You've got to do it as you end the previous way and if you forget, as is likely, you have to switch modes to recover. It's not nearly as good. No objection to having it as well, but not instead. David ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On 09/03/2009 11:34, David Earl wrote: On 09/03/2009 11:24, Frederik Ramm wrote: Hi, Stefan Breunig wrote: Try double clicking. Would we lose anything by simply reinstating the old shift behaviour? Indeed. AFAICS shift is unused now. Remember Oops, half finished paragraph. I was going to say ... Shift used to do (similar)two things - create a node ready for extension when in open space, and select a node ready for extension when shift+click near a node. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
create a node ready for extension when in open space, and select a node ready for extension when shift+click near a node. A normal click does just that. Pressing Shift was superfluous even before the change got checked in. -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On 09/03/2009 11:40, Stefan Breunig wrote: Would we lose anything by simply reinstating the old shift behaviour? Shift now prevents JOSM from re-using nodes, but still inserts nodes into existing ways. Old way to deal with this was to zoom in so the snap distance would be too large, then click, then zoom out again. Now you can just Shift-Click. If you wonder why one needs this, try to think if when you try to create a T crossing. There are sometimes nodes that make it more look like an italic T crossing, which is annoying. Since there were no free modifiers (ctrl: no re-using at all, ALT: start new way from current node) I figured it was best to remove SHIFT as double click is a good alternative. The double click is too early. You've got to do it as you end the previous way and if you forget, as is likely, you have to switch modes to recover. It's not nearly as good. No objection to having it as well, but not instead. You can also just click the node you wanted to insert again. OK, with that information I can now do everything I used to, though it still takes an additional click. And when you're ready to start another way, your attention is focussed elsewhere and I think I'll end up having to move the mouse back to the end of the previous path quite often. (If ESC or some such key did this too, would be useful?). But there's no indication you can repeat click, or indeed that you can double click. I'm sure I can get used to it, but arbitrarily changing the user interaction does seem rather draconian, and needs a prompt somehow, somewhere. Once you know, you know. But until you know, it is very hard to find out. I don't really get what you're taking about with how you've switched SHIFT to something else. Can you illustrate it some how. My feeling from your description is that if you're nowt zoomed in far enough to distinguish things, you probably don't know what you;'ll get so would have to zoom in anyway, but I'm probably misunderstanding what you said. BTW, I do very much like the little insertion indicators that tell you what will happen next depending where you are hovering. The rubber band kind of did that before but it was very subtle to notice it snap. It's a while since I updated my JOSM before last weekend, so I didn't know when these changes had happened. David ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On 09/03/2009 11:42, Stefan Breunig wrote: create a node ready for extension when in open space, and select a node ready for extension when shift+click near a node. A normal click does just that. Pressing Shift was superfluous even before the change got checked in. There was a time when it didn't. I agree this aspect is better now - again now I know about it. David ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On 09/03/2009 11:54, David Earl wrote: I don't really get what you're taking about with how you've switched SHIFT to something else. Can you illustrate it some how. My feeling from your description is that if you're nowt zoomed in far enough to distinguish things, you probably don't know what you;'ll get so would have to zoom in anyway, but I'm probably misunderstanding what you said. Oh, I see now, it just prevents the extension from snapping onto an existing node. David ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On Mon, 9 Mar 2009, Frederik Ramm wrote: Stefan Breunig wrote: Try double clicking. Would we lose anything by simply reinstating the old shift behaviour? Well, I was not totally happy with that change, but I agreed with it. I would not have accepted such change if I would think previous version was better. You know, every two month changing a bit to keep users alive :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
Ah, I see you found out yourself what shift does now :). Double clicking to end, or clicking last node again makes it especially easy for Potlatch switchers because that's how drawing is ended in Potlatch since like always. Also, there is a little indication of what will happen when you have a look at the status bar – it's really subtle though, hence the highlighting/changing cursor depending on where you hover and/or which modifiers are pressed. Hopefully the users will find the new way easier to use once they get used to it. You are right in one thing though, functionality isn't really exposed anywhere. It's a bit for the select tool where it says in the status bar ctrl to toggle, shift to add, … but it's really overcrowded and not easily parsable for the human eye. I changed that for drawing mode to be as precise as possible with the disadvantage of not showing the modifiers anywhere at all. You have to go to the wiki to find out about them. Maybe a more extensive tooltip on the mode icons could solve this? About ESC: Yeah, you can hit ESC to end drawing, too. It deselects the newly created node though. Oh, and I just found out that you can keep ESC pressed to restore previous SHIFT behaviour. On Mon, Mar 9, 2009 at 13:20, Dirk Stöcker openstreet...@dstoecker.de wrote: On Mon, 9 Mar 2009, David Earl wrote: OK, with that information I can now do everything I used to, though it still takes an additional click. And when you're ready to start another way, your attention is focussed elsewhere and I think I'll end up having to move the mouse back to the end of the previous path quite often. (If ESC or some such key did this too, would be useful?). But there's no indication you can repeat click, or indeed that you can double click. Press U to unselect is another keyboard based alternative. I'm sure I can get used to it, but arbitrarily changing the user interaction does seem rather draconian, and needs a prompt somehow, somewhere. Once you know, you know. But until you know, it is very hard to find out. It is noted at the start screen BTW. And yes you right that changing user interaction is not nice, but on the other hand there have been good reasons to do so. The remaining users will learn about that change and we have a better interface :-) Especially new users had lots of problems with the dangling rubber band which are now solved. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
Shaun McDonald wrote: If you are zoomed in enough, you will find a little plus in the middle of the line. You simply need to drag that plus to get a new node. But then you drag the segment into a direction you don't want it to go. If you want the segment to be where it was you will have to straighten it out again with L. Doubleclick seems to work fine, but I already had it happen to me that I apparently moved the mouse slightly and I created a new node with a segment coming from that node and going to that node. And I just found that doubleclicking is also not really handy when adding nodes to the crossing of two segments. Using shift was IMHO much more convenient and sure is faster. If we are having a vote, I am a lot in favour of getting the shift modifier back. You don't have to remove the other options, but I see no reason why the shift was removed and couldn't go back in. Regards, Maarten On 8 Mar 2009, at 13:06, Maarten Deen wrote: Until recently, pressing A and then clicking a way while holding the shift key resulted in nodes being added to a segment. For a week now ( first noticed it in the march 01 version and I now took the latest from march 08) this does not work anymore. A and then clicking (either with or without holding shift) alway makes a new segment. Is this a bug or is this on purpose? If it is on purpose, what is now the new way of adding nodes to an existing segment? The only way I found was A, click, S, click on background, repeat. Regards, Maarten ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
Dirk Stöcker wrote: The remaining users will learn about that change and we have a better interface :-) Especially new users had lots of problems with the dangling rubber band which are now solved. I don't see that. When I click, I still get the rubber band. Maybe you mean something else, but the shift was _the_ way to eliminate the rubber band. And when you are trying to work fast and the mouse moves just before the second click, the new segment is there. That problem could not occur when using shift-click. Regards, Maarten ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [PATCH] timestamp parsedTimestamp in OsmPrimitive
Jiri Klement napsal(a): Hi, Attached patch replaces timestamp and parsedTimestamp in OsmPrimitive with DateContainer class accessible only using setter and getter. The patch is not much usefull on itself but hopefully its the first step to make OsmPrimitive encalupsed (without public variables) so things like spatial index or better caching will be possible in future. I have read both the patch and the thread and I would suggest something different, once you're touching this and removing public access to the field(s). First, adding another holder class is both unnecessary and a memory waste. You can add reasonable access methods directly to OsmPrimitive (while providing e.g. DateComparator for comparing OsmPrimitive dates, if necessary) and resort to keeping only a private integer timestamp (in seconds, not long millis) inside the OsmPrimitive. This means that you'll need to parse all the timestamps during xml parsing, but if done properly, you won't notice the slowdown. Feel free to use the parsing code from josm-ng: http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/utils/DateUtils.java which I do use quite quickly for datasets much larger that JOSM can even imagine. (I have spent quite some time benchmarking and optimizing the parsing code, you can be sure I know why there was lazy parsing and everything in the riginal code). As long as you hide the field and provide only the Date/String(/int) API, you can reintroduce the String field anytime though (but you won't need to). Regarding your: // TODO Is it enough to compare string representation? Dates can be in different format but are they in real life? No, it isn't. The timestamps seem to be stored in the OSM database in the textual form or at least keep the original timezone information (which is useless anyway) and you'll encounter many different formats (timezones) coming from the OSM server all the time (in the same download). Just download a random area, store to a file and look there. Once you're all integerized, you can remove all the String based code paths to simplify the code. Petr ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
I've just gone back through my mail, and I have nothing with your name on it about these changes, unless it is buried in something with an unrelated subject heading. They just appeared. I only updated Friday after a long period of using an older version in the mid 900s(*). Nah, I meant the mail I wrote earlier today to this thread (the one with ESC). My feeling is that it should be possible to have a switchable interaction style so you can choose your favourite, or we can come to a consensus on which works best by developing new ones or variations without upsetting the status quo until there is a broad agreement. You're welcome to send patches, but it's a lot of work for little gain. It's always the case that when you change something some people don't like the change and start complaining which is normally good because you can find alternatives. In my opinion this discussion goes nowhere here so far, other than I want it like it was (or adding a control mechanism to switch this). The offending bug https://josm.openstreetmap.de/ticket/383 has been open for 16 month before I started thinking about how to implement this. I posted my suggestion about a week before posting the patch. You showed that you do care, so why not take it a bit further and add suggestions to new bugs on how to implement them? Anyway, it's done now. I guess we'll get used to it. I am confident of that :). But hey, if you have better ideas of how to improve things, just open tickets. (*) by the way, older JOSMs no longer display the message of the day apparently, which was partly the point of having them - that people with older versions get to know about mandatory and optional changes in later versions they don't have, not jsut what's new in the version you *do* have. Also it broke my paint colors until I realised I had to remove my custom mappaint XML reference from the days when I had a plugin. That took ages to track down. That'll teach me to keep up with the cutting edge. Normally JOSM only displays the messages up to its version. But I remember there has been a change to that rather recently, maybe it broke it for older builds… -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [BROKEN PATCH] Adding a Full Screen action to the View menu
On Thu, Mar 5, 2009 at 7:12 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Would a patch that only enabled this feature under X11 be acceptable? Or perhaps some win32/OSX hacker can take a look at it. I've submitted one at http://josm.openstreetmap.de/ticket/2279 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
