[Merkaartor] Why so many modes?

Chris Browet cbro at semperpax.com
Mon Jul 19 13:22:13 BST 2010


>
>  Apparently, the only difference is that you have a different mode for each
>> kind of primitive to be created (node, way, relation, area, ..) and that
>> there is no double-click option.
>>
>> The big question is how does JOSM find out the user wants to create,
>> e.g., a way rather than a node (and possibly adapt the UI as a consequence)
>> with a single "Add" mode?
>>
>
> Actually we don't care. Probably here a difference in design philosophy
> exists. In JOSM you draw nodes. Depending on the state (doublicked, shift
> pressed, ...) these nodes are either connected or not.
>
> The type of the elements is choosen after you created them using the
> presets (much like in Potlatch).
>
> If I remember right in Merkaartor it is the other way round - You choose
> first and draw then (saying that - this is not absolute, as we have tools
> like a circle or area generator which does otherwise as well).


Indeed. Maybe the "create node" and "create way" can be merged in
merkaartor, too.

>
>
>  The numerous modes the initial reporter is speaking of are the tools. As
>> we have a far more smaller team than JOSM, all tools are integrated (as
>>
>
> You're sure the team is smaller? JOSMs core team are 3 people ATM.


It's still 3 times as much as merkaartor ;-)
I really meant plugin developers included. Plugins is the crucial
differentiator in favor of JOSM, functionality-wise, IMHO, although the lack
of uniformity is a downside.

>
>
>  "modes") rather than plugins. I guess JOSM users must also somehow switch
>> context each time they want to use a plugin, don't they?
>>
>
> Yes. But it is not easy to describe that, as plugins have different user
> interfaces. Some are to be applied after elements are designed. Others help
> creating elements, others are dialogs, ... A few of them also add new modes
> like lakewalker or building tools.
>
> For me the plugins are a bit like a playground to find new and better UI
> forms as well as new JOSM authors. BTW: I don't think the JOSM plugin
> concept is useful for Merkaartor. It is based on the relatively freedom of
> Java instead of proper plugin interface (which would cost a great deal of
> time to implement).
>

Indeed. Qt/C++ is a more demanding environment than JAVA, I think. If a
developer has the skills to develop within the framework, I think it is best
to include the functionality in the core directly

>
> I'm not 100% happy with the way JOSM is handled (too many control keys and
> hidden options) and last time I tried I had also some problems with
> merkaartor. Both programs have still a long way to go and I'm always happy
> when someone suggest or does a useful and implementable enhancement in user
> interface.
>

As I said recently, I think the proper place of merkaartor is between
potlach simplicity and JOSM power.
The way modeless is implemented in potlach (apparently; I must say I never
check the other editors, I'm afraid this would hinder my "creativity" and
would more-or-less unconsciously make me reproduce rather than innovate;
virtual nodes was a request based upon your work and I implemented it "my
way") seems fine for power users, I could implement it as an option and
leave the "step-by-step" approach default for casual mappers.

- Chris -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/merkaartor/attachments/20100719/65957ec5/attachment.html>


More information about the Merkaartor mailing list