[glideplan_swproj] Re: Questions
- From: Cestmir Houska <czestmyr@xxxxxxxxx>
- To: glideplan_swproj@xxxxxxxxxxxxx
- Date: Wed, 16 Nov 2011 18:05:29 +0100
Tom, come to updraft@xxxxxxxxxxxxxx We've been discussing it there
Cestmir
2011/11/16 Tomáš Zámečník <pulcik@xxxxxxxx>
> 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.
>
> RE:
> 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.
>
> Example:
> 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
> hooks.
> 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?
>
> RE:
> 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?
>
> RE:
> 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?
>
> RE:
> 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.
>
> T.
>
> To visit archive or unsubscribe, follow:
> //www.freelists.org/list/glideplan_swproj
>
Other related posts:
