[Marble-devel] Busy and please give me a quick update
torsten.rahn at credativ.de
Wed Sep 19 16:27:34 CEST 2007
Ok, here the proof-read version ;-) (Sorry I pressed the "Send" button too
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).
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.
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.
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
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
> I hereby propose this change.
> > 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
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
More information about the Marble-devel