Defining new dive site using the map

[Lubomir I. Ivanov]

On 15 October 2017 at 20:49, Dietrich Meyer <dietrich at sunnynames.com> wrote:
>> Am 15.10.2017 um 16:22 schrieb Willem Ferguson:
>> > I create a new, nonexistent dive location name, then click "Apply
>> > changes". Then I click the icon "edit dive site". A new marker is
>> > created on the map with a message "Drag the selected location". When I
>> > drag the new marker, I drag the map, not the dive marker. I find no
>> > way in which to drag the marker, whether I drag the marker of the new
>> > dive site name. A little more detail, please Stefan and/or Lubomir?
>>
>> Unfortunately I can confirm this.
>> I never do lot's of testing with the Linux version, only use it when I
>> want to compare some specific behavior between Windows and Linux.
>> So it seems that I (and Lubomir) were too happy and too quick when we
>> were saying: Ok, compiles with Qt5.5, map is displayed, everything ok.
>> Some "details" still don't work correctly.
>> With my Windows MXE build I'm on Qt5.9.2 and there you can drag the
>> marker...
>>
>> Best regards
>> Stefan
>
> I am using Subsurface 4.6.4-947 on Opensuse Tumbleweed, and don't see this
> problem.
> Editing existing dive sites is just working, i.e grabbing the marker and
> dragging it to whereever, no problems.

it worked for me a couple of days ago on Ubuntu, as my dive log file
has some custom dive locations (e.g. named "dsadasdsads") which now
suddenly cannot be edited.
i'm seeing a strange QML bug related to "mouse areas".

>
> When creating a new dive site, then dragging the marker also works here.
> However, I am not sure that it is intuitive that one has to grab the marker at
> position 0°0'0.0"N 0°0'0.0"E and drag it to where the new site is. Especially
> since at least on my screen, the visual difference between the selected marker
> and all other markers is rather small. I have no clue about this
> implementation, but maybe it would be possible to gray out the other markers
> when one dive site is being edited?
>

probably best to discuss these details with other users in a new thread.
once we have some solid proposals i can look at those and estimate
their complexity.
then we can pick the best proposal and create a Github issue for it
and start the work...

lubomir
--