>> ...
>> And when I started with QMS I made a list of errors I will not make
>> again. One of them is implementing features I personally do not need.
> I somehow doubt that this attitude (implementing features one personally
> doesn't need is an ERROR), fits well with the ideas behind public domain
> software.

First, QMS is open source licensed under GPL3. This is not public domain
at all. And open source does not mean: Everybody wishes and one has to
implement the stuff. No way. It is your freedom to take the code and to 
extend it to whatever suits you. As it is published under GPL3 you have
to publish your changes if you distribute your derivative. The easiest
way to comply is to contribute your code to the project. 

The basic idea behind open source is that everyone is implementing the
stuff they personally need by extending existing code and contributing
back. By that you do not have to code all by yourself and you pay back
by contributing. It's a gentlemen agreement that has been exploited by
users severely. I know no other situation in real live where people ask
so blatant and shameless others for free work than in today's open
source projects.

Besides that, wishing is one thing. It has to fit, too. In QLGT I was
stupid enough to implement every wish. Often I never got any feedback
from the one wishing. In many cases I found a severe bug months later
realizing no one ever used that stuff. Wasted time and it made QLGT the
mess it is.

> When I ran into this trackpoint list for the first time, I too was ask-
> ing myself, what the heck is that list good for.  If it's good for noth-
> ing and  read-only anyway,  why not simply  remove it?   The information
> shown in that list is also displayed above the graphs when you hover the
> mouse over a trackpoint in one of the graphs  and you could as well dis-
> play this information when the mouse hovers over a trackpoint in the map
> view.

It's there because if it wouldn't be there everyone would ask why it is
missing. ;)

>
> This would make  selecting a range in the map view  more precise because
> of the additional information you could base your selection on.
>
>

Let's look at the information you usually select a range:

* Position. I can't read coordinates in the sense that I can picture a
position on the map by it's coordinate. But I can see a point on the map
and I can click on it.

* Elevation. I use the range selection to measure slopes. Instead of
finding the local extrema in a list I simply select two points in the
profile. It's way easier.

* Speed. This is often used when selecting activities. Again it's much
easier for me to find that stuff in the speed graph than in some endless
list.

If I would really miss that selection via list I would have already
implemented it. In the beginning of QMS it was even on the todo list.
But funny enough I did not miss it. And as already said I started it
some time ago out of a mood and it didn't really fit in.


Which brings us back to open source. If anyone thinks he or she can do
better, implement it, take the challenge of a pull request and if it
fits in without breaking something and the code is in a state that is
maintainable, it will be part of the package.

I definitely love to spend my time on pull requests and to discuss code
rather than to take orders to implement other people wishes.


------------------------------------------------------------------------------
_______________________________________________
Qlandkartegt-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users

Reply via email to