[Loadstone] Find & show area
shawn at odyssey.cm.nu
Fri Jan 11 02:41:27 GMT 2008
There's a bit of inconsistancy with the keys in navigation and exploration
mode, mainly with the long star and shift star. This because in navigation
mode the shift star was already used and in exploration mode long star has
been allocated to the new show point comment function that was deemed to be
more often used than the find point function. Since the keys in navigation
mode can be remapped the user can fix the inconsistancies if it's a real
The show area and find point functions are almost the same as far as code
goes but the show area doesn't do a string search. The reason for this is
clear, show area is for looking at what's around you without knowing any
part of the name, and find point is to find a point when you know the name
or partial name of the point you're looking for. A find point will be slower
than a show area because of the additional work involved with the text
If you have a small database then getting results will be quite fast. Scale
this up thoe, say 100000 points or so, and things start to slow down quite a
bit. At those levels even 10 results for a show area will take a few
seconds. The higher the number of returned results the longer the response
time will be.
When doing a find point you don't really need fine resolution since the
exact location of the point isn't known or you wouldn't need to find it in
the first place. Having the search radius in kilometres doesn't prevent the
function from finding a point less than a kilometer away and has no effect
on the way the distance is reported.
As far as units go it probably makes the most sence to have them in the most
common representation that people will use for the given purpose. This means
that larger values would be in kilometres and smaller ones in metres.
On Thu, 10 Jan 2008, Ari Moisio wrote:
> Hi Shawn
> On Wed, 9 Jan 2008, Shawn Kirkpatrick wrote:
>> The new system does something like that. In navigation mode the long arrows
>> will do a show area in that direction and long select does a show area in
>> all directions. Find point can be mapped to a key and defaults to long * but
>> that may change before release. In exploration mode shift of the numeric
>> keys will do a show area in the given direction and shift 5 will do it for
>> all directions. There's a shortcut to find point with shift *.
> Ok, sounds good. There is however still inconsistency between navigation
> and exploration modes.
>> There's probably no point in bringing up the dialog on a show area since
>> it's likely to find something unless you have a database with not much in it
>> and an unreasonable search radius.
> I still wonder is the only difference betweeen find point and show are
> the lack of dialog in the show area -function. For end-user's point of
> view two almost similar functions is no good at all.
>> You couldn't represent the search results in screenfulls (on what size
>> screen?) since there's only one result on screen at any one time. More often
>> than not you want a low number of search results to start with anyway.
> There were those quotation marks for a reason. Why shall i want a low
> number of results at first time. Even 6680 can calculate 25 results - my
> current default - faster than screen reader could read the first line.
>> Having the search radius in kilometres makes sence since you're probably
>> searching for points further away from the current position. Having the
>> number in metres would just result in bigger numbers.
> Bigger numbers but also finer resolution. For orientation purposes some
> point at south 2.7 kilometers apart is quite useless.
>> Unfortunately the user interface just doesn't seem to provide any good to
>> specify what units things should be in. By the time you get the prompt up
>> there's no room for anything else. Even worse symbian does provide for doing
>> things like this but series60 doesn't use those fields for some reason.
> For this reason units should be as consistent as possible.
>> On Wed, 9 Jan 2008, arimo at iki.fi wrote:
>>> On Tue, 8 Jan 2008, Shawn Kirkpatrick wrote:
>>>> This could probably be done but that would introduce an extra step in the
>>>> show area function making it a bit slower to access.
>>> The access speed difference is plusminuz zero, one extra selecto for one
>>> less arrow down. There is currently six keystrokes to get from navigation
>>> mode to show area.
>>>> Access to these functions has been improved for the next version.
>>> Great:-) How about following scheme in both navigation and exploration:
>>> arrow will open show area -type list in given direction and pressing
>>> select will open current find- type dialog in all directions.
>>> To stay even more consistent between exploration and navigation modes
>>> arrow up could always be 'in front', ie in exploration mode heading of
>>> latest virtual movement.
>>>> I've been thinking of making the find dialog save the last search criteria
>>>> but don't know if it'll get put in or not.
>>> I'll vote to put it on.
>>>> For the results field you can type in the number instead of using the
>>>> arrows. I think the adjustment step is handled by the dialog framework and
>>>> might not be adjustable.
>>> Ok... how about defining it as a 'screenfulls', ie for example ten
>>> results per single unit?
>>>> The search radius is in kilometres, consistant with other things.
>>> I haven't found any other setting presented in kilometers so far. They
>>> are in metres, seconds or just numbers.
>>> You can still escape from the Gates of hell: Use Linux!
>>> mr. M01510
>>> Loadstone mailing list
>>> Loadstone at loadstone-gps.com
>> Loadstone mailing list
>> Loadstone at loadstone-gps.com
> You can still escape from the Gates of hell: Use Linux!
> mr. M01510
> Loadstone mailing list
> Loadstone at loadstone-gps.com
More information about the Loadstone