[glideplan_swproj] Re: [glideplan_swproj] Questions

  • From: Tomáš Zámečník <pulcik@xxxxxxxx>
  • To: glideplan_swproj@xxxxxxxxxxxxx
  • Date: Wed, 16 Nov 2011 18:03:00 +0100 (CET)

Hi Kuba,
good job.
I send some suggestions (denoted by "RE:" ) ...

> 1) 
> Task planning seems to need a global state ... "task plan being
> edited", because when you click the map in this state you need to
> overide all other controls (IGC click handler, airspace click handler)
> and add a new point instead. 

I agree that the global state is right choice. And also that the application 
should prioritize the active tab (i.e. plugin).
It means: If you do some action in map (click, r.click, drag & drop), there 
could be some active state,
which hooks that command and invokes it's processing.
Global state could be stored in the stack so you can push some state and get 
back to previous by popping
ot there could be one active global state and one default - when you get from 
the active one, you go to the default one.
If the tab is activated (switched on), it should register all it's signal-port 
bindings to map.
If the tab is deactivated, it should release it's bindings and also pop/release 
global state.

1] You start new task decalaration (e.g. from menu) --> new panel(tab) is 
created and activated. Previously active panel ends it's actions and relase 
2] You choose adding new point --> global state is set.
3] You click several times to map --> points are added.
4] You switch to another tab --> global state is released, hooks are released 
(and new are set).

> Also we must choose what to do when you
> have multiple task plans opened, start editing one and then switch to
> the second.
> SeeYou avoids this by having a separate window for each task plan and
> never using a common part of gui.
> Airnav pro adds a dangerously looking red/black stripped bar to the map
> saying that task editing mode is enabled.
> Another way would be disabling edit mode once a different tab is
> selected.
> @Tom: Is this what you meant by the "selected task" thing in the
> specification? But this doesn't work with the tabbed interface, does it?

RE: Exactly, but I think that it can work with the tab interface well...in the 
way I mentioned in the previous "RE" of this mail.
The selected task is the one, which tab is opened. There is also option to have 
all declared tracks in one tab and in that
case there should be one selected explicitly (like in the figure 2 in the 
requirements specification).

> 2)
> What about adding waypoint to the middle of flight plan? We already
> talked about this, but it was only in cotext of buttons in the task
> plan window. What about adding a new point by dragging the line on the
> map? 

I think it could be nice.

> 3)
> Not really task planning, but where will the measure distance tool be
> displayed if we choose to implement it? another tab at the bottom?

It shouldn't be in another tab. It should be accesible at any time.
I think, that this control can be accessible from menu or context menu and also 
by shortcut.
Some space for non-plugin gui can be in the left pane, but I would like to 
avoid this.

> That would mean it's a new plugin, right?

No, I think it should be a part of the map interaction. If you invoke distance 
measurement, then it sets global state (similar to task planning).
...I think that is the reason, why we need the global state...it allows hooking 
"messages" by both plugin and non-plugin features, it says "who has the 
focus"...one may say that the active tab always has the focus, but there are 
also non-plugin features like this one,
which can want to do something.


To visit archive or unsubscribe, follow:

Other related posts:

  • » [glideplan_swproj] Re: [glideplan_swproj] Questions - Tomáš Zámečník