[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] [SOCIS] comments on 2011-08-29 apk
- To: orekit-developers@orekit.org
- Subject: Re: [Orekit Developers] [SOCIS] comments on 2011-08-29 apk
- From: Alexis ROBERT <alexis.robert@gmail.com>
- Date: Thu, 8 Sep 2011 19:13:56 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=/j/F85kmIfO70xsSw7zGkLwQbITqAkPJ9kNYPtKKVb0=; b=T/QslspX0ulcU+UmOSGbfjMQdkLsCRsCwJcLKuGNMn9XNwy8jnX81QwqhzqoCmnaUl eDPPCcQMM2uE+UEhON1udGWbPIPnYXupmssCunJ2T4XjJ1cmtbA9E4Wp0xLZHPnFy1ug XlCxL1cWVmXVe9bMI/CR84GQYmiPUXB84Q3x8=
- In-reply-to: <4E68B0B6.2020300@c-s.fr>
- References: <4E68B0B6.2020300@c-s.fr>
Le Thu, 08 Sep 2011 14:10:30 +0200, Luc Maisonobe
<Luc.Maisonobe@c-s.fr> a écrit :
> Hello Alexis,
Hi,
> We are sorry for the delay on commenting your latest version, we were
> quite busy.
No problem, I was also busy so the coincidence is pretty great :)
> The new handling for the vector input is really good. I just noticed
> some weird behavior when attempting to type a velocity after having
> input a position. The next field after pos.z was vel.z while I would
> have expected it to be vel.x. Also the next field after vel.{x,y,z}
> did not work. I guess this is the same thing you mentioned in your
> August 29th message. It would also be really fine to have the same
> behavior for other forms, like latitude/longitude/altitude fields in
> station coordinates.
You're right, it doesn't work on the "Frame" part. This is only a
field lacking in the XML layout file, you can see that it works for the
position/vector fields for orbit definition.
The problem with latitude/longitude/altitude fields is how to manage
favorites in term of user interface. Here everything fits, and the
number of clicks required is not so much since there is not a lot of
fields. I really don't know how to do using these fields, but if you
have a solution which mixes favorites management as well as the "Fetch
current coarse location" so it can not feel strange, I'll be happy to
implement it :)
> By the way, there is no way to input altitude in station coordinates.
> It would be nice to add this.
Ok :)
> The favorites management is really is good thing. Two awkward things
> are that you cannot edit an entry (you can however delete it and
> recreate it) and you have only one selection chance. I would have
> expected that when you are on an input form (say for a ground
> station) and you have two or three stations available in the list on
> the bottom of the screen, selecting one station would simply fill in
> the fields in the above form and this would allow both changing the
> values afterward (possibly saving the new values) or selecting
> another station. Using the station would always be done by using the
> existing OK button. For now, when you select a station it immediately
> takes the values and close the form, just as if you had also pressed
> the OK button.
About editing, it was just because you can edit by selecting a
favorite, re-click on "Configure", delete your old, modify the settings
and save it. But I understand it's not very intuitive :)
No problem for not pressing "OK" directly.
> I think a tabular presentation for orbits would be nice. The one line
> fields is difficult to read.
OK.
> My last comment about UI is the tabular output for eclipses. There is
> a big black horizontal bar on some cells (entry or exit). From the
> top of my head I think also the entry and exit events for eclipses
> are not gathered in a single row as station events are (I'm not sure
> though, I do not have my tablet near as I write this mail).
Ah. "black" problems shouldn't happen with the scrolling part, can I
have a screenshot ? (you can make one by plugging your tablet, and
launching "ddms", a tool present in the Android SDK)
On my phone, eclipse events are gathered in a single row. But maybe
I've not commited some changes.
Alexis