[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] ToolManager and finding tools
|
Sounds good.
If you get a chance can you ask Jeff to return our call :-) We are trying to do a couple of things and would like Jeff to be in the loop (change license, discuss entering eclipse foundation and so forth).
On Saturday, 3 March 2012 at 10:20 AM, Emily Gouge wrote:
Thanks Jody.
I will post a pull request when I get the chance (hopefully early next
week).
Emily
On 01/03/2012 5:18 AM, Jody Garnett wrote:
Jesse has created a couple of tutorials on embedded a map viewer; you could review his code for hints.
I think I have it to the point where each map could have its own tool manager; and indeed tool manager would be well enough behaved to stand on its own.
Your method sounds find to me; I was forced to add similar methods when I was wiring things up.
Would you like to submit your your method as a pull request?
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
____________ 10.68.218.228 as permitted sender) client-ip.68.218.228;
Authentication-Results: mr.google.com;
spf=pass (google.com: domain of jody.garnett@xxxxxxxxx
designates 10.68.218.228 as permitted sender)
smtp.mail=jody.garnett@xxxxxxxxx;
dkim=pass header.i=jody.garnett@xxxxxxxxx
Received: from mr.google.com ([10.68.218.228])
by 10.68.218.228 with SMTP id pj4mr39983585pbc.167.1330878749898
(num_hops = 1); Sun, 04 Mar 2012 08:32:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113;
hÚte:from:to:message-id:in-reply-to:references:subject:x-mailer
:mime-version:content-type;
bh=rJgoJlHNqDgRKnW3zWSKt8qQLTfTbmh3sOzk+8rDD98=;
b=Jo68kUbKFEseA7ViRVzLS8b5YjkdO0wC/espCjtr5dO+tWr3GXAFukGYT2bVb8DWsl
Wh5fecr6jMhpBFvxepKoK2fFEwse0KvCmIOny8mBO8+Bb1jHqgLyhBEnxpbIuNIsV/MV
ZmPl9BnRE/JTxmthHCERAyFjgroRKsH7PVlHOpZFH0mvPMl3q5jXrgHlVZsbJ5Y+5rli
8Ge9FSm0xxV+xHsYrvVNle3JVUipptyqoyNHnyKQnYOov9YTd3bjA91LTAd/y2icp7HQ
eafsk0Fvf0HjsCh3EDjC10XT4Qzl934YjUcJ1HJDoQc2ZvaOODKXVSL8OO1xrxbHSxvx
k6aQ=Received: by 10.68.218.228 with SMTP id pj4mr34228761pbc.167.1330878749851;
Sun, 04 Mar 2012 08:32:29 -0800 (PST)
Received: from Liberi.local (27-33-181-124.static.tpgi.com.au. [27.33.181.124])
by mx.google.com with ESMTPS id a2sm10075077pbc.16.2012.03.04.08.32.27
(version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 08:32:29 -0800 (PST)
Date: Mon, 5 Mar 2012 02:32:25 +1000
From: Jody Garnett
To: User-friendly Desktop Internet GIS
Message-ID: <715ADF31094D460EAB0D24E90E6A4236@xxxxxxxxx>
In-Reply-To:
References: <5CD79E65A2874D889294953F9340CB44@xxxxxxxxx>
X-Mailer: sparrow 1.5 (build 1043.1)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f539919_77ae35eb_1e9b"
Subject: [udig-devel] =?utf-8?q?ContextModel_changes_…_try_another? =?utf-8?q?_day?X-BeenThere: udig-devel@xxxxxxxxxxxxxxxxxxxxx
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: User-friendly Desktop Internet GIS
List-Id: User-friendly Desktop Internet GIS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 04 Mar 2012 16:31:01 -0000
--4f539919_77ae35eb_1e9b
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I have placed the work on "upstream/legend" so it can be looked at another time.
This is a case of getting 90% of the way there and needing to back out in order to not get in the way of others.
What went well:
- The model changes went smoothly; git very was useful in keeping track of everything
- Tracking down references and events related to context model
- Using "containment" for the LegendItems (including Layers) so they get saved; while letting the layers list hold on to Layers by reference
What did not go well:
- The MapItemProvider (an Item provider which uses a child fetcher job to load things in the background rather than stall out the display thread). The code was a little bit magic in that it had been hacked up to delegate to the ContextModel (including events forwarding).
What got stuck:
- The Layers view makes use of the default MapItemProvider; which appears as if it would like to follow the "eStructure" heirarchy --> which we are trying to change over to storing things in the legend item list.
What to try for next time:
1. Start from the legend branch; in particular the model is much easier to follow now
2. Look into how the MapItemProvider works; and make a couple variations (one for layers list, one for legend items) prior to starting
3. Trace through the event handling around context model and make a checklist of what it is used for (so we can be sure of hitting those points again)
I will not be able to return to this work for the rest of the week due to some deadlines at work.
--
Jody Garnett
On Sunday, 4 March 2012 at 11:42 PM, Jody Garnett wrote:
> I have just finished:
> 1) finding all references to the class ContextModel and replacing them
> 2) finding all references to map.getContextModel()
> 3) reviewing each mention of ProjectPackage.CONTEXT_MODEL
>
> I should have something that can be tested shortly..
> --
> Jody Garnett
>
>
>
> --
> Jody Garnett
>
>
> On Friday, 2 March 2012 at 2:50 PM, Jody Garnett wrote:
>
> > Productive day thus far …
> >
> >
> > 1) Paul has review and accepted Naz's addition of a LegendView (he even ran find bugs etc… thanks Paul / Naz)
> > 2) Paul has helped me updated the core EMF model here are the highlights …
> > - Map now directly has list of references to layers (with each layer having a back pointer to its map). This should be the zorder sorted layer list used for rendering and the replacement for the current context model.
> > - Map now contains a list of legend item
> > - I checked over the use of LegendItem (so that Folder and Layer reuse LegendItem fields of name, isShown and icon).
> > - Made sure Folder was containing a list of LegendItem
> >
> > Summary:
> > - Map saves out legend items now
> > - We will try having Map keep a layers list (rather than context model) we will need some event listening code so that any layer added to the legend item list is sorted into the correct spot in the layers list. If this does not work (or is too complicated to maintain) we will use the Legend list directly.
> > - MapContext is still around -> used to load "old" maps for a bit; but should vanish after one release or so
> > --
> > Jody Garnett
> >
>
--4f539919_77ae35eb_1e9b
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I have placed the work on "upstream/legend" so it can be looked at another time.
This is a case of getting 90% of the way there and needing to back out in order to not get in the way of others.
What went well:
- The model changes went smoothly; git very was useful in keeping track of everything
- Tracking down references and events related to context model
- Using "containment" for the LegendItems (including Layers) so they get saved; while letting the layers list hold on to Layers by reference
What did not go well:
- The MapItemProvider (an Item provider which uses a child fetcher job to load things in the background rather than stall out the display thread). The code was a little bit magic in that it had been hacked up to delegate to the ContextModel (including events forwarding).
What got stuck:
- The Layers view makes use of the default MapItemProvider; which appears as if it would like to follow the "eStructure" heirarchy --> which we are trying to change over to storing things in the legend item list.
What to try for next time:
1. Start from the legend branch; in particular the model is much easier to follow now
2. Look into how the MapItemProvider works; and make a couple variations (one for layers list, one for legend items) prior to starting
3. Trace through the event handling around context model and make a checklist of what it is used for (so we can be sure of hitting those points again)
I will not be able to return to this work for the rest of the week due to some deadlines at work.
--
Jody Garnett
On Sunday, 4 March 2012 at 11:42 PM, Jody Garnett wrote:
I have just finished:
1) finding all references to the class ContextModel and replacing them
2) finding all references to map.getContextModel()
3) reviewing each mention of ProjectPackage.CONTEXT_MODEL
I should have something that can be tested shortly..
On Friday, 2 March 2012 at 2:50 PM, Jody Garnett wrote:
Productive day thus far …
1) Paul has review and accepted Naz's addition of a LegendView (he even ran find bugs etc… thanks Paul / Naz)
2) Paul has helped me updated the core EMF model here are the highlights …
- Map now directly has list of references to layers (with each layer having a back pointer to its map). This should be the zorder sorted layer list used for rendering and the replacement for the current context model.
- Map now contains a list of legend item
- I checked over the use of LegendItem (so that Folder and Layer reuse LegendItem fields of name, isShown and icon).
- Made sure Folder was containing a list of LegendItem
Summary:
- Map saves out legend items now
- We will try having Map keep a layers list (rather than context model) we will need some event listening code so that any layer added to the legend item list is sorted into the correct spot in the layers list. If this does not work (or is too complicated to maintain) we will use the Legend list directly.
- MapContext is still around -> used to load "old" maps for a bit; but should vanish after one release or so
--
Jody Garnett
--4f539919_77ae35eb_1e9b--
Back to the top
