Hi,
You cannot configure IntelliJ to use Subversion - that plugin only uses GIT.
If you want the automated plugin versioning to work, you need to check
out the plugin from the git repository. You probably did not do that and
just downloaded the plugin ZIP file - this will work fine to do some
I noticed that a lot of devs have changed from Eclipse to IntelliJ
The free community edition is fine for working on JOSM and we have some
ultimate licenses available if any core dev needs them.
We currently have those build systems checked into our svn repository:
* ant
* Eclipse
In #17218
Hi,
A plugin update always requires a restart - you cannot get around this.
The technical reason is that JOSM cannot unload the old plugin classes. This is
why an activation of a plugin is possible without restart, but deactivating it
is not.
Am 27. Februar 2019 13:33:49 MEZ schrieb Jiri
On 15.10.2018 19:55, Dirk Stöcker wrote:
Don't mix that: For the first two points I currently have a big no, as
suggestions involve mostly relying on third party services (in case of
git even on Microsoft). I'm too long in this business to ever do that
again for a critical infrastructure
Since you are the one one objecting the loudest so far and won't be
attending, what are the points that would convince you to do one of the
following:
* Switch to a different build system
* Switch to a different / decentralized source versioning system?
* Change the project layout
should see how to reduce this number (inclusion in
core, deletion or merging plugins together)
Do you have something else in mind?
Le dim. 14 oct. 2018 à 19:26, Michael Zangl
a écrit :
Hi,
are there any specific issues we will be working on those days?
Michael
On 03.09.2018 22:36, Vincent
Hi,
are there any specific issues we will be working on those days?
Michael
On 03.09.2018 22:36, Vincent Privat wrote:
Hello,
I was thinking for quite some time about setting up a meeting between JOSM
developers somewhere in Germany (for convenience).
As Christine and Frederik are inviting
Hi,
I just had a short look at the patch that is attached to the ticket,
assuming it contains the code you used to split things.
I did not have a deep look at it, but from what I can tell, you copy
over the waypoints to a new layer.
Mind that this should not be done. New WayPoints always
Hi,
I'll be coming on October 20th ;-)
Michael
On 03.09.2018 22:36, Vincent Privat wrote:
Hello,
I was thinking for quite some time about setting up a meeting between JOSM
developers somewhere in Germany (for convenience).
As Christine and Frederik are inviting OSM developers to Karlsruhe on
Hi,
No, getResponseCode() is not only for logging. It just happens to be the
first method that is called on the HTTP result and triggers the Thread
to wait for the HTTP response (therefore the long wait). Since we need
the response any way, it won't be a noticeable performance improvement
to
Hi,
I just tried to access SVN / Website and they seem to be down.
Michael
Hi,
I'm interested (since I already did quite some profiling on the
rendering stuff).
But to be honest, I probably won't have the time to do anything useful
in that direction this year.
Michael
On 22.06.2018 19:46, Vincent Privat wrote:
I only got answer from Dirk. Nobody else
The idea of the quasi-standard files is to have them in a structure in
which IDEs can pull them in automatically.
We only have few plugins that use a build system that could make use of
such a functionality. And as far as I have seen, most of them use git
and are outside of the source tree
Hi,
I'm not a fan of having distribution binary files in the source code
repository or in any other repository that has to be at a specific place
in the directory tree.
We currently have all snapshot plugin jars including source/javadoc on
the nexus server:
Hi,
About your concrete example: There are several questions to think of:
* Is your functionality a generic task? (in your case, this would be
something like "create a convex hull")
* Is that functionality required by a lot of users?
* Is your functionality approved by the community? Or
I don't think it's worth speculating now.
(1) The linked document mostly focuses on Java web start (which is just
a convenience for some users - but we can ship JOSM otherwise, e.g.
using a launcher like many java programs do) and other non-JOSM
technologies (we have only one class depending on
omments. Hopefully, the designs will be
> beneficial for the proposal.
>
> As such is the basic UI Mockup + proposed UI changes + project timeline
> is sufficient for the proposal?
>
> Best Regards,
> Madhavan
>
> On 13 March 2017 at 18:13, Michael Zangl
> <opens
Hi Madhavan,
Using the ticket as a starting point is a good way to go. For the GSoC
project, you are free to suggest whatever you want - feel free to use
your creativity.
You are free to search the features for yourself. You could try to
improve the way Plugin Buttons integrate into JOSM (try
Hi,
I am one of those that could not really find time the last weeks.
#13809 is the only major issue. It is only related to testing.
#13724 I could not find a cause for this one. A release would be
beneficial here to get debug data if anyone triggers it again.
#13604 and #13725 are only annoying
Hi all,
Google summer of code has officially ended.
I was working on the core of JOSM a lot for the past three months. You
probably didn't notice much, except for some bug report windows popping
up when using the latest JOSM version.
But there were a lot of changes under the hood that should
Hi,
A short note on the current GSoC progress for plugin writers and
interested users.
4 weeks ago I started to restructure some of JOSM main classes. A lot
has changed in the last few weeks. Some of the changes are affecting
plugins and large parts of JOSM, this is a short summary.
-
Hello,
I am Michael Zangl. For this year's GSoC I am planing to restructure
some core components of josm.
There are currently lots of global references and circular dependencies
in this code. Especially Main and MapView have many unwritten
implications and do a lot of instanceof.
My goal
Hi,
Which style are you using?
MapCSS styles can be pretty fast. It depends on the style you used how
fast it really is. You can use --trace to display the rendering times
(style preparation and actual drawing)
Some things to keep in mind for style performance:
- [key=value] selectors use a
Hi,
I decided to apply to GSoC once again this year.
During my GSoC last year I noticed that there are many things in JOSM
core that are working but make extending JOSM painful. I already send in
many small patches over the last year but I did not have the time to go
any further and work on some
Am 18.03.2016 um 12:09 schrieb Dirk Stöcker:
> On Fri, 18 Mar 2016, Michael Zangl wrote:
>
>> I decided to apply to GSoC once again this year.
>>
>> During my GSoC last year I noticed that there are many things in JOSM
>> core that are working but make extendin
Am 25.11.2015 um 13:55 schrieb Paul Hartmann:
>
> The cleanest solution is to patch JOSM core so your plugin can intercept
> the delete action. (Similar to DatasetListener, but the "listener"
> returns a boolean value which tells JOSM to continue or abort the delete
> action.)
An even cleaner way
, OpenGL-Plugin related).
Feel free to post any thoughts you have on this and any problems you see
;-).
Michael Zangl
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
Am 08.09.2015 um 14:28 schrieb Dirk Stöcker:
> On Tue, 8 Sep 2015, Michael Zangl wrote:
>
>> Currently, MapView is a collection of global flags, variables and lots
>> of stuff that has nothing to do with simply viewing the map. Some fields
>> are not even accessed by MapV
.
Michael Zangl
[1] https://github.com/michaelzangl/josm-plugin-opengl/releases/tag/v0.2
[2] https://github.com/michaelzangl/josm-plugin-opengl/
[3]
https://github.com/michaelzangl/josm-plugin-opengl/wiki/Performance-comparison
___
josm-dev mailing list
josm-dev
in Navigateable Component.
- Test if there are any issues with synchronizing the addLayer/...
methods.
Michael Zangl
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
Hi,
One thing that always annoyed me about JOSM is that it has those many
modal dialogs. In other editors, you can simply fill in the key/value
table, in JOSM you always need to double-click on the value, then move
your mouse and click on the position where you want to edit the value
(assuming
on top of JOGL and the other way around is an option I
don't like, since it went wrong the last time I tried it (mouse events
not beeing captured correctly, ...). But it might also just need some
more tweaking.
Michael
Am 23.03.2015 um 15:19 schrieb Paul Hartmann:
On 17.03.2015 11:41, Michael Zangl
,
Michael
Am 09.03.2015 um 18:19 schrieb Michael Zangl:
Hi,
I'm also posting this on the JOSM-List in hope to get feedback on the
technical parts here.
Regards,
Michael
Weitergeleitete Nachricht
Betreff: [OSM-dev] GSoC: OpenGL view for JOSM
Datum: Mon, 09 Mar 2015 13:58:41
Hi,
Thanks for the feedback.
Am 10.03.2015 um 11:22 schrieb Dirk Stöcker:
On Mon, 9 Mar 2015, Michael Zangl wrote:
This is a thing that annoyed me for a long time: JOSM is slow when
zooming out. I would like to improve this and have enough spare time
this summer to work on this as GSoC
Hi,
I'm also posting this on the JOSM-List in hope to get feedback on the
technical parts here.
Regards,
Michael
Weitergeleitete Nachricht
Betreff: [OSM-dev] GSoC: OpenGL view for JOSM
Datum: Mon, 09 Mar 2015 13:58:41 +0100
Von: Michael Zangl openstreet...@michael.fam
35 matches
Mail list logo
