[josm-dev] GSoC application for JOSM core

[Michael Zangl]

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 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 of the bigger tasks. Especially #11838 and
>> #11637 did not get the focus they deserved and starved a bit.
>>
>> This is why I propose to restructure some things, especially around the
>> MapView.
>>
>> Those are the tasks I identified and of which I think that they can fill
>> a summer - a lot of the work will be required for backward
>> compatibility, testing and fixing bugs.
>> https://docs.google.com/document/d/1CfGQBtsTljYg0N56sjeomZVRPTasyLoaAqVgbwDmzKs/edit?usp=sharing
>>
> 
> You're sure this only fills a summer?

I am pretty sure I won't get even close to what I personally would like
to do, but it should be a good starting point.

> I appreciate many of the ideas you have to make the core components more
> modular. That's a lot of work and if finished will allow us to start
> some things which are wanted for some time (e.g. using the MapView in
> other places).

Yes, this was one of my intentions. I don't know if I can get there
during this year's GSoC, especially because layers assume that they are
only displayed once (and there is a lot of layer code...).

> Is there a chance that GSoC accepts such an approach, as it's hard to
> show your own work when a constant review process lies inbetween?

Simply do a SVN grep for "Patch by..." ;-). Both MapView and bug
tracking are components that will require rewriting / new code in large
parts. That way, a lot of new code is at one place. I don't think that
this should be a problem for Google.

OSM already had several such projects (e.g. improving the road style).

They might have more problems with dependencies on other work though but
I do not have many of them here. I could work mostly on myself, although
I hope to have feedback from and discussion with the community.

> We did similar things in the past, e.g. when replacing the data storage
> with QuadTree. In such cases we accept less mature code and constant
> fluctuation for some time as long as it does not break the software
> completely and the changes come in small steps. We'll get fire from the
> latest-user in that time, but one could say that's appreciated feedback :-)

Nice to hear. I am worried most about breaking plugins, especially the
ones that do not use the documented API but assume some internal state
of JOSM. I won't be able to test them all or even know of them.

Michael