[Marble-devel] Busy and please give me a quick update

[Torsten Rahn]

Ok, here the proof-read version ;-)  (Sorry I pressed the "Send" button too 
early)

On Wednesday 19 September 2007 13:03:36 Inge Wallin wrote:
> A very simple way is to remove the command line option, add a checkbox in
> the Settings or View menus for the tab, and let it be off by default.  Then
> the GPS features are actually discoverable, which they are not now.

Here's what problems I'd like to see addressed, concerning GPS/GPX:

First it would be nice if we had more example files for (unit) testing in SVN 
(preferably from different sources).

File view:
-------------
My comment was mostly about the file view. The file view was meant to only 
be displayed automatically if there would exist a non-empty GPS/KML layer on 
top of the default layer.

Currently I need to use the command line to enable it.

Rearranging Menuitems
-------------------------------------
On my personal TODO there is:
- Moving all current items from "View" to "Settings" in the Qt Frontend to be 
more consistent with the KDE application. 
- Moving Compass and Scale Bar from the Legend to the View menu.
+ Adding an entry "Cross-hair" there to enable and disable the cross-hair.

GPS:
-------
Now back to the GPS feature: 
The "Current Location" tab was only added as a tab that could be used in 
custom widgets (not for the Marble Application). The reason being that it was 
meant to assist the use case where the user has got to enter his current 
location (either via automatical detection or manually).

So the motivation why the tab should be shown in Marble which was designed for 
a completely different use case  appears a bit strange to me.

Additionally the UI of the tab right now has the following issues: 
- GPS features are there no matter whether GPS functionality is compiled in. 
And they are there no matter whether a device got plugged in. Both scenarios 
need to get addessed properly:
- Labels are not labeled in a way that I would understand what clicking the 
widgets would trigger:  

* "Track GPS" - In which way? - Does this mean that the position gets 
recorded, that we connect to the GPS device?
* "Catch GPS" - How does this differ from "Track GPS"? The expected effect is 
unclear to me.
* "Draw" - What? The current position? The position + the track? Or even all 
GPS layers + the current position, etc.? This is unclear. 

So this definetely needs better labels. And as I said if GPS is not available 
it should either get hidden or disabled. Maybe with a label that tells the 
user that the Marble version he got was either not prepared for GPS or that 
the GPS device hasn't been attached.

So even for the original purpose (usage for other apps where position input is 
needed) there is some polishing to do.

On the other hand we want to expose the GPS functionality in Marble better.
The "current Location" tab currently exposes two things:

- The current Location
- Settings for the Trackturtle and the GPS Layer.

Now in addition to the current Location we have the "Home Location". This got 
me thinking whether we need to distinguish between "Home Location" 
and "Current Location". The Home Location was really the place where the user 
feels at home or lives. Compared to that the "Current location" was rather the 
everchanging place where the user is currently located and travelling. 

To the user for whom the current location doesn't get set automatically this 
distincition might not make too much sense.
If the Current Location got to be set manually it should get set the same way 
as the Home Position to make things more transparent.

Now concerning the GPS Layer display:
If we'd integrate the whole GPS functionality on top of existing features we 
would probably add the GPS features, like waypoint, route, etc.  to the 
Legend and show and hide them the same way we do for the current items in the 
Legend. 
However I feel that as there is some conceptual difference between the "raw" 
GPS features and the features of a map that have been edited and 
more "refined" map items.
So the best would probably be to have a GPS tab which would show the same 
LegendBrowser that gets used for the Map Legend for the GPS/GPX overlays:
That LegendBrowser would hold the possible GPX object symbols (waypoints, 
track, etc.)  and would easily make it possible for GPS users to identify 
items on the map as well as to switch them on and off using the checkboxes.
Of course that GPS tab would also only get shown if a GPS device got attached 
and all necessary libraries got compiled in.

Ok, So that would be the mid term solution. 
For the shortterm solution I agree with Ingwa, that we should use the Current 
Location tab in place of that future GPS tab. We unfortunately don't have 
much time left for KDE 4, so we need to settle on that for now. 
However we need to sort out the UI issues before the release:

- Getting the labels on the checkboxes clearer (but still short and up to the 
point- no long descriptions, please)
- Make sure that the GPS checkboxes get only displayed if the gps 
functionality has been compiled in (this should be easy to do).

Now concerning the Menu: Enabling the whole "Sidebar" should be placed 
in "Settings". As pointed out by ingwa it might make sense if the user was 
able to hide and show the Sidebar tabs individually.
So my suggestion would be to have an entry "Side Bar" in settings which would 
loose it's checkbox functionality and would point to a submenu instead.
The submenu would contain by default the following entries and states:

Settings->SideBar-> Hide All
Settings->SideBar-> Hide Navigation
Settings->SideBar-> Hide Legend 
Settings->SideBar-> Hide Map View
Settings->SideBar-> Show GPS
Settings->SideBar-> Show File View

Whether "Show" / "Hide" would be displayed in terms of text or as a "[x] Show" 
checkbox item needs to be discussed as well.

This still looks a bit feature creepy to me, so any better suggestion is 
welcome :-)

Torsten


> I hereby propose this change.
>
> 	-Inge
>
> > Bye for now,
> > Andrew
> >
> > On 14/09/2007, Torsten Rahn <torsten.rahn at credativ.de> wrote:
> > > On Friday 14 September 2007 04:07:53 Inge Wallin wrote:
> > > > This is a good idea.  I do think that we should number them like
> > >
> > > bugzilla,
> > >
> > > > though, so that we can refer to them in  the TODO file.  We have to
> > > > plan which bugs to fix for which release, for instance, and that's a
> > > > good way
> > >
> > > to
> > >
> > > > do it.
> > >
> > > good.
> > >
> > > --
> > > Torsten Rahn
> > >
> > > Tel.: 0 21 61 - 46 43 - 192
> > >
> > > credativ GmbH, HRB Mönchengladbach 12080
> > > Hohenzollernstr. 133, 41061 Mönchengladbach
> > > Geschäftsführung: Dr. Michael Meskes, Jörg Folz
> > > _______________________________________________
> > > Marble-devel mailing list
> > > Marble-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/marble-devel



-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz