- Rendering Metrics
- Composite Renderer with Dynamic Overlay
- Cape Town uDig community edition
- "SelectionListener" naming conflict
[08:07] *** Initial topic: (Link: http://udig.refractions.net/)http://udig.refractions.net/
[08:07] *** #udig: gdavis_ simboss moovida emily_g Jesse_Eichar dassouki JustinIPS KevinIPS acuster hbullen chorner ozzicle
[08:07] *** #udig was created on Wed Apr 23 17:58:51 2008.
[08:08] Jesse_Eichar: he left 10 minutes ago and said he'd be here in 10 minutes
[08:08] Jesse_Eichar: so that makes it quite soon :) 10 more minutes ;)
[08:12] *** jgarnett has joined #udig.
[08:12] jgarnett: morning
[08:12] Jesse_Eichar: ah
[08:12] jgarnett: (you guys better not of waited for me)
[08:12] moovida: morning
[08:12] Jesse_Eichar: We did :)
[08:12] jgarnett: :-P
[08:12] Jesse_Eichar: what was the topics again?
[08:12] jgarnett: shall we grab the agenda topics from email ...
[08:12] Jesse_Eichar: 1) Rendering Metrics
[08:12] Jesse_Eichar: 2) Composite Renderer with Dynamic Overlay
[08:13] Jesse_Eichar: 3) Cape Town uDig community edition
[08:13] Jesse_Eichar: 4) "SelectionListener" naming conflict
[08:13] Jesse_Eichar: Who wants to take RenderingMetrics?
[08:14] jgarnett: I can start ... but I am starting by asking if everyone has read the wiki page?
[08:14] jgarnett: outlining the plan
[08:14] jgarnett: (this change needs to happen - and your renderers will break so it is important)
[08:14] jgarnett: wiki page: (Link: http://udig.refractions.net/confluence/display/HACK/Render+Metrics)http://udig.refractions.net/confluence/display/HACK/Render+Metrics
[08:14] *** CIA-43 has joined #udig.
[08:15] jgarnett: to be clear we want to do this work today.
[08:15] Jesse_Eichar: I like this much better than our original
[08:15] moovida: aha :)
[08:15] jgarnett: we asked last week; and Jesse shot down my rough plan ... so here is a better one.
[08:15] moovida: ok, it doesn't seem to be too heavy to change, right
[08:16] jgarnett: Jesse if you can skip to the comments you can see where I am still having trouble.
[08:16] Jesse_Eichar: Resolution scares me a bit
[08:16] jgarnett: moovida it is *almost* a return to the origional design; this time learning from our mistakes (ie making "default" measurements available as constants)
[08:17] * moovida was meaning it would not be hard to get there for other renderers, as for example JGrass :)
[08:17] jgarnett: you understand the need for resolution? Perhaps a better name... it was called getAccuracy() last time but the javadocs got into precision and nobody would read them.
[08:17] Jesse_Eichar: I understand
[08:17] jgarnett: moovida - you are correct - it would not be hard.
[08:17] Jesse_Eichar: the only part is that It can be very hard to calculate in many cases.
[08:17] Jesse_Eichar: So you should detail what happens if say:
[08:18] Jesse_Eichar: you know it is more than can be shown but you don't know how much more.
[08:18] Jesse_Eichar: I'd put .5
[08:18] jgarnett: Jesse_Eichar++ - that is why I hope having constants for people to return (if it is too hard to calculate) will be useful?
[08:18] jgarnett: So should we have a couple more constants?
[08:18] Jesse_Eichar: Resolution doesn't seem to have constants
[08:18] jgarnett: oh - for resolution there are no constants yet ... I will add them.
[08:18] Jesse_Eichar: the others do and I like
[08:18] Jesse_Eichar: right
[08:19] Jesse_Eichar: you can leave that spec
[08:19] Jesse_Eichar: with a couple of constants for those cases
[08:19] jgarnett: So the style blackboard evaulation sectino
[08:19] jgarnett: does not seem to work for me
[08:19] Jesse_Eichar: I see that. It is harder I agree.
[08:19] jgarnett: see the comments for my difficulty; and my suggestion.
[08:20] Jesse_Eichar: So for style
[08:20] Jesse_Eichar: we need 2 axes
[08:20] Jesse_Eichar: 1.
[08:21] Jesse_Eichar: how good it can look when fully styled
[08:21] Jesse_Eichar: and 2. How well it will look given that not all the information is there.
[08:21] Jesse_Eichar: My problem is that I may want the "pretty" renderer to be used as long as it can if it is prettier just use its defaults.
[08:22] Jesse_Eichar: That is why I think we need a preference system to control the renderers as well.
[08:22] Jesse_Eichar: does that make sense?
[08:23] Jesse_Eichar: Just because not all the info is on the BB doesn't mean I don't want to use it... It just means that I didn't feel like taking the time to set all the preferences.
[08:23] Jesse_Eichar: (or it could mean that)
[08:25] Jesse_Eichar: ...
[08:25] jgarnett: Emily had the same question yesterday
[08:25] jgarnett: The question is really "how can I dodge all this stuff"
[08:25] jgarnett: and isOptimized() is not a good stable answer.
[08:25] Jesse_Eichar: no kidding
[08:26] Jesse_Eichar: well how about this
[08:26] jgarnett: I would a) not like people to dodge this stuff
[08:26] Jesse_Eichar: we have 2 sets of constants
[08:26] jgarnett: b) recommend a new style blackboard entry - "preferred renderer"
[08:26] Jesse_Eichar: one for each dimension
[08:26] jgarnett: if we *have* to provide a dodge.
[08:26] Jesse_Eichar: then a preference for overrides
[08:27] Jesse_Eichar: sound good?
[08:28] Jesse_Eichar: ...
[08:28] Jesse_Eichar: anyone?
[08:28] jgarnett: Jesse I was hoping Emily was watching the meeting
[08:28] jgarnett: I was updating the page based on your last feedback.
[08:28] Jesse_Eichar: ping emily_g
[08:28] Jesse_Eichar: you following?
[08:28] emily_g: I'm paying attention - I'm just thinking :)
[08:28] Jesse_Eichar: k
[08:29] emily_g: My concern would be that it might be to complicated for somebody to bother to implement - which sounds like it was the problem jody was having the first time around
[08:29] Jesse_Eichar: That is right
[08:29] jgarnett: (I also am scared with your suggestion about showing users that different renderers exist)
[08:30] jgarnett: I was more thinking the "dodge" was something programmers can use.
[08:30] Jesse_Eichar: how can a programmer do it?
[08:30] emily_g: my initial reaction is why do we need two metrics ? Do we really care how well it can look if it is fully styled if it can't actually fully style itself?
[08:30] Jesse_Eichar: Because most renderers have defaults
[08:30] Jesse_Eichar: Just because some font isn't on the BB doesn't mean it can't render
[08:30] Jesse_Eichar: it just means that it has to use a default.
[08:31] jgarnett: aside: Even if the renderer does not have defaults; the StyleContent can make a *good* default based on the GeoResource.
[08:31] Jesse_Eichar: right
[08:31] emily_g: yes
[08:31] jgarnett: perhaps we should ask the renderers not to come up with there own defaults? So the functionality of default style is not split across classes?
[08:31] emily_g: but couldn't that be wrapped into the how well it can style
[08:32] emily_g: if it knows it has defaults then it can style well
[08:32] Jesse_Eichar: sure
[08:32] jgarnett: thinking
[08:32] emily_g: if it doesn't have defaults and the styles aren't available then it can't style?
[08:32] Jesse_Eichar: I don't have a problem with that myself
[08:32] jgarnett: For me it is really how well they pay attention to the users wishes
[08:32] Jesse_Eichar: but that more or less means a can or can't style
[08:32] Jesse_Eichar: not a scale
[08:32] Jesse_Eichar: Lets walk through a scenario.
[08:33] jgarnett: when they grab a default it does not enter into the decision process - ie it is magic not under user control.
[08:33] jgarnett: please.
[08:33] Jesse_Eichar: its hard to come up with
[08:33] Jesse_Eichar: so we have 2 renderers
[08:33] Jesse_Eichar: your example jody
[08:33] Jesse_Eichar: csv B&W
[08:33] jgarnett: (note we have been working with two senarios outlined on that page; CSVRenderer vs ColorCSVRenderer and BasicWMSRenderer vs TiledRenderer)
[08:33] Jesse_Eichar: and csv Color
[08:33] Jesse_Eichar: so we open a map
[08:34] Jesse_Eichar: both renderers have the same value really
[08:34] Jesse_Eichar: no I lie
[08:34] Jesse_Eichar: color probably has better because it could provide a different color per polygon
[08:34] Jesse_Eichar: or maybe not if it does what BasicFeatureRenderer does
[08:35] Jesse_Eichar: at the top.
[08:35] Jesse_Eichar: we drop on a CSV layer
[08:35] Jesse_Eichar: which is chosen
[08:35] Jesse_Eichar: probably the color
[08:35] Jesse_Eichar: for the WMS vs Tiled
[08:36] Jesse_Eichar: no ignore wms for now
[08:36] Jesse_Eichar: so I add a style
[08:36] Jesse_Eichar: and again the csv color is used
[08:36] Jesse_Eichar: when is B&W used?
[08:36] emily_g: in the csv example if there is a color on the style blackboard we want the color renderer; however if there is no color on the style blackboard do we want the select the default one of the colored one?
[08:36] jgarnett: I would like it used when the color is removed from the style blackboard.
[08:37] jgarnett: I would like the default one.
[08:37] jgarnett: for the training materials
[08:37] emily_g: but what if the color one has a good "default" value
[08:37] jgarnett: I want people to be able to see the system switch renderers based on the color being there or not.
[08:37] jgarnett: It is supposed to be a simple example showing how the system works.
[08:37] Jesse_Eichar: Jody... I don't really see the value beyond a tutorial
[08:37] Jesse_Eichar: this is a trivial example
[08:37] jgarnett: it is.
[08:38] Jesse_Eichar: lets not mess with the system for that. Lets come up with a better example.
[08:38] jgarnett: do we need to break out NamedStyle vs SLD for WMS Renderers? Or can we continue...
[08:38] Jesse_Eichar: lets try something that we can do now
[08:38] jgarnett: okay make Color a requirement for the ColorCSVRenderer
[08:38] jgarnett: and please continue?
[08:39] Jesse_Eichar: I'm trying to think of another renderer you might want
[08:39] Jesse_Eichar: for the CSV
[08:39] Jesse_Eichar: maybe one that draws a background
[08:39] Jesse_Eichar: if a image is set on the BB
[08:39] Jesse_Eichar: as a BackgroundStyleContent?
[08:39] Jesse_Eichar: so if that is there then the background renderer would be chosen
[08:40] Jesse_Eichar: or another idea
[08:40] jgarnett: Okay let me throw two ideas:
[08:40] Jesse_Eichar: we have a renderer that can render some SLD very efficiently
[08:40] jgarnett: - we had an example made in the course where a cache was placed on the layer blackboard
[08:40] jgarnett: - or throw font into the mix and only render the labels if the font is avaialble
[08:40] jgarnett: (or let them set the column that the labels come out of - a real need actually)
[08:41] Jesse_Eichar: I think I have it
[08:41] Jesse_Eichar: We have a renderer that can't render labels but is "quick" (for argument sake) in the tutorial you can say that that is the idea
[08:41] Jesse_Eichar: and another that can render labels but is slower?
[08:42] Jesse_Eichar: but then you could get into a situation where you have an even weighting and you flip flop randomly...
[08:42] Jesse_Eichar: arg
[08:42] Jesse_Eichar: I don't know
[08:42] Jesse_Eichar: we need to move on
[08:42] emily_g: I don't think the style metric was supposed to determine the speed of rendering
[08:42] emily_g: I think we were hoping one of the other metrics would cover that
[08:43] emily_g: but we can move on
[08:43] Jesse_Eichar: I agree emily
[08:43] Jesse_Eichar: ok what is 2 again?
[08:43] Jesse_Eichar: 2) Composite Renderer with Dynamic Overlay
[08:43] jgarnett: Jesse if I do the approach outlined in the comments will you cry?
[08:43] Jesse_Eichar: gulp that is another painful one
[08:43] jgarnett: (because I want to get this started)
[08:44] Jesse_Eichar: did you just update it?
[08:44] Jesse_Eichar: For the most part it is not too bad.
[08:44] Jesse_Eichar: I say emily can decide :D
[08:44] jgarnett: fair enough
[08:44] jgarnett: okay we will update the page and implement.
[08:44] jgarnett: moving on ...
[08:45] jgarnett: wiki page for 2)
[08:45] jgarnett: (Link: http://udig.refractions.net/confluence/display/HACK/Composite+Renderer+Background+with+Dynamic+Overlay)http://udig.refractions.net/confluence/display/HACK/Composite+Renderer+Background+with+Dynamic+Overlay
[08:45] Jesse_Eichar: 2) Composite Renderer with Dynamic Overlay
[08:45] Jesse_Eichar: [5:43p]
[08:45] Jesse_Eichar: jgarnett
[08:45] Jesse_Eichar: :
[08:45] Jesse_Eichar: yep
[08:45] jgarnett: Jesse I think this is mostly questions based on lack of understanding.
[08:46] jgarnett: gdavis_ is the man with the questions; I am just getting in his way.
[08:46] Jesse_Eichar: So right now the ViewPane or what ever it is called
[08:46] jgarnett: (because I do not know the answer)
[08:46] jgarnett: ViewPane? First I have heard of it...
[08:46] Jesse_Eichar: What is it called
[08:46] Jesse_Eichar: ViewportPane
[08:46] Jesse_Eichar: I think
[08:46] Jesse_Eichar: anyhow
[08:46] jgarnett: is that from the MapEditor? I am constructing a GISWidget and would like to know if the ViewportPane is the same thing.
[08:47] Jesse_Eichar: It is what you get when you use a Context object with tools
[08:48] Jesse_Eichar: There are two implementations right now: ViewportPaneJava and ViewportPaneSWT but the Java one is not fully functional because it doesn't work on Mac
[08:48] Jesse_Eichar: It is what the MapEditor creates
[08:48] Jesse_Eichar: and sets on the Rendermanager
[08:49] Jesse_Eichar: so...
[08:49] jgarnett: shall we run through the questions?
[08:50] Jesse_Eichar: sure
[08:50] Jesse_Eichar: go
[08:50] jgarnett: is this the answer to the first question on this page
[08:50] jgarnett: ie "Who is in charge" ?
[08:50] jgarnett: I found a difference between the diagram here ((Link: http://udig.refractions.net/confluence/display/DEV/09+Renderers)http://udig.refractions.net/confluence/display/DEV/09+Renderers) and the text.
[08:50] jgarnett: It looks like a RenderExecutor is created for each renderer?
[08:51] Jesse_Eichar: that is right
[08:51] jgarnett: but now it sounds like ViewportPane is in charge?
[08:51] Jesse_Eichar: no
[08:51] Jesse_Eichar: it just displays
[08:51] jgarnett: And renderExecutor is some utility class.
[08:51] jgarnett: so who is driving; who does the composition and listens to all the renderers go ... starting and stopping them as needed.
[08:52] jgarnett: RenderManager?
[08:52] Jesse_Eichar: It is mainly the RenderExecutorComposite I think I called it just to confuse things
[08:52] Jesse_Eichar: It is the RenderExecutor for the CompositeRenderer
[08:52] Jesse_Eichar: it drives
[08:52] Jesse_Eichar: it triggers the update every 1 second or so
[08:52] Jesse_Eichar: it decides when to give up
[08:52] jgarnett: so that is the "timer"
[08:53] Jesse_Eichar: yet
[08:53] Jesse_Eichar: yes
[08:53] gdavis_: does our diagram on the whiteboard look correct then?
[08:53] jgarnett: that is started when a renderer sends an event?
[08:53] Jesse_Eichar: I don't really understand it
[08:54] Jesse_Eichar: First Render manager can say render:
[08:54] Jesse_Eichar: REC tells CompositeRenderer to go
[08:54] jgarnett: aside: I am going to copy the diagram from Section 3.7 of the framework recomendations pdf to the page; I would like to figure out how much of that work has been done.
[08:54] Jesse_Eichar: it tells all its contained RE to go
[08:54] Jesse_Eichar: they inturn tell each renderer to go
[08:55] Jesse_Eichar: each second REC tells the CompositeRenderer to create a composited image and send it to the ViewportPane
[08:55] Jesse_Eichar: the viewportPane displays the image and then paints any valid draw command on top
[08:56] Jesse_Eichar: That is the basic idea
[08:56] Jesse_Eichar: each second the REC checks to see who is done
[08:56] Jesse_Eichar: If all are done it sends the update request and stops
[08:57] Jesse_Eichar: the main confusion right now is that a renderer can at any time decide it wants to start back up.
[08:57] Jesse_Eichar: It sends a RenderRequest event
[08:57] Jesse_Eichar: and that triggers its RenderExecutor to start
[08:57] gdavis_: ok
[08:57] Jesse_Eichar: as well as the REC
[08:58] Jesse_Eichar: however in this case the REC will not tell all renderers to start
[08:58] gdavis_: so if we want encapsulate all that as a "background" that can stay relatively static when the user has the map in one spot, and then have a dynamic overlay that is updating frequently, how would that fit in?
[08:58] Jesse_Eichar: That basically has to be in the ViewportPane
[08:59] Jesse_Eichar: because compositing all the layers and displaying them can take much of a second
[08:59] Jesse_Eichar: but the ViewportPane can update dozens of times a second
[08:59] gdavis_: this 1 second, is it a static arbitrary number that is defined somehwere?
[08:59] Jesse_Eichar: I think so
[08:59] gdavis_: we tried finding it earlier without much luck
[09:00] jgarnett: aside: page update; made a note of "RenderExecutorComposite" for later.
[09:00] Jesse_Eichar: RenderExecutorComposite line178 on 2.2
[09:00] Jesse_Eichar: it is in the ncrementalUpdate method
[09:00] Jesse_Eichar: a wait period of 400 MS
[09:01] gdavis_: ah ok
[09:01] Jesse_Eichar: it should really depend on how long it takes to create the composited image
[09:01] jgarnett: I would kind of like to update that 400 MS based on what is going on.
[09:01] Jesse_Eichar: not be hard coded like that
[09:01] Jesse_Eichar: can't jody
[09:02] jgarnett: explain?
[09:02] Jesse_Eichar: On many computers it can't update every 400 ms
[09:02] Jesse_Eichar: A wait period of 400 ms means it renders about 1 time per second
[09:02] jgarnett: perhaps I am looking for a different number.
[09:02] Jesse_Eichar: as you can see that it already a massive load on the prcessor
[09:02] jgarnett: once we are down to a dyanmic renderer and a composite renderer
[09:02] jgarnett: we should be able to update many more times that 1 per second?
[09:03] Jesse_Eichar: Yes
[09:03] Jesse_Eichar: but it is
[09:03] Jesse_Eichar: maybe
[09:03] jgarnett: so I kind of want to make the delay based on what the composition step involves...
[09:03] Jesse_Eichar: A bit part is the conversion from a large AWT image to a large SWT image
[09:03] jgarnett: can you talk about that? I went looking through the code
[09:03] jgarnett: and was shocked to see for loops still in use?
[09:04] jgarnett: I thought we carefully made a block of memory that could be handled by both?
[09:04] Jesse_Eichar: It depends on the image type
[09:04] jgarnett: (perpahs the for loop was only for SWT to AWT ... when I was doing the "Draw2DRenderer")
[09:04] Jesse_Eichar: In this case it should not be a for loop
[09:04] Jesse_Eichar: If it is an arbitrary Rendered image then we don't know if it is in memory and much loop
[09:05] Jesse_Eichar: however if we know it is a BufferedImage and of a certain byte order then we can do it pretty fast
[09:05] Jesse_Eichar: but we don't have the conversion for all image types
[09:05] jgarnett: I think we can arrange for it not to be an arbitrary rendered image; ie the result of the compostite renderer should be a "composition" of all the child layers into a single "good" image?
[09:06] Jesse_Eichar: I tried to make sure we do do that
[09:06] Jesse_Eichar: and we did at one point
[09:06] Jesse_Eichar: but you should verify again now.
[09:06] Jesse_Eichar: So you need it to be a AWT Renderer for the Dynamic rendere I take it?
[09:06] jgarnett: understood
[09:07] jgarnett: gdavis where are we in the list of questions?
[09:07] jgarnett: jesse: I have placed "Section 3.7 Rendering" on the wiki page
[09:07] jgarnett: if you refresh
[09:07] jgarnett: I would like your comment on the two diagrams there
[09:07] gdavis_: I think we covered them
[09:07] jgarnett: they are the best visualization I have of what is going on at run time...
[09:07] jgarnett: ... if they are already covered I will double back to the logs later.
[09:07] gdavis_: maybe 1 more
[09:08] gdavis_: What is a Renderer+RenderContext called?
[09:08] Jesse_Eichar: There is no JAI
[09:08] gdavis_: "It looks like a CompositeRenderer keeps a number of child Renderers; I assume it owns the RenderContext for the children and uses them to draw as needed? What is one of these child entries called?"
[09:08] jgarnett: So those diagrams are useless? I think I want to make a useful one by the time we are done here ...
[09:09] Jesse_Eichar: Those diagrams are probably useless, not to mention confusing
[09:09] Jesse_Eichar: It is just a for loop
[09:09] Jesse_Eichar: drawing to the same image
[09:09] Jesse_Eichar: I talked to simone at the FOSS4G and he decided it was as good a way as any
[09:09] Jesse_Eichar: as long as you are smart about the parameters
[09:09] Jesse_Eichar: And nice and simple
[09:10] gdavis_: so the viewportpane basically owns a parent render manager, is that the top level here?
[09:10] Jesse_Eichar: I think the Rendermanager adds a listener to the RenderExecutorComposite
[09:10] Jesse_Eichar: everytime an update, started or done event comes along it tells the ViewportModel
[09:10] gdavis_: render manager has a renderexecutorcomposite, which has a composite renderer, which in turn has various renderers/executors
[09:11] Jesse_Eichar: the ViewportModel is mainly just a listener
[09:11] Jesse_Eichar: it owns nothing
[09:11] Jesse_Eichar: Right
[09:11] gdavis_: so the rendermanager is where we want to create a new overlay renderer
[09:11] gdavis_: and add a listener to the viewportmodel
[09:11] Jesse_Eichar: The final image is the image contained inthe RenderContext of the CompositeRenderer ( and since the executor and render share the same context it is the image in the REC )
[09:12] gdavis_: it sounds like the whole renderexecutorcomposite and its children can remain as they are for our purposes?
[09:12] Jesse_Eichar: I would say the CompositeRenderer is the place
[09:12] Jesse_Eichar: The REC is responsible for timing
[09:12] Jesse_Eichar: and the CR is responsible for compositing
[09:12] gdavis_: right, ok
[09:13] jgarnett: aside: we still have some agenda topics and should move on.
[09:13] Jesse_Eichar: The RenderManager is responsible for providing access to these objects
[09:13] Jesse_Eichar: yes
[09:13] Jesse_Eichar: (Sorry andrea)
[09:13] Jesse_Eichar: 3)
[09:13] *** acuster has signed off IRC ("Leaving").
[09:13] gdavis_: ok tjhanks
[09:13] Jesse_Eichar: 3) Cape Town uDig community edition
[09:13] moovida: :)
[09:13] Jesse_Eichar: go go go
[09:13] moovida: no problem
[09:14] moovida: I just wanted to have comments on what we plan to do
[09:14] jgarnett: I would like to use Jira to keep organized
[09:14] moovida: if we plan to go on joint
[09:15] moovida: jgarnett: that is ok for me
[09:15] jgarnett: Do we have an idea on what you are demoing / work shopping etc...
[09:15] Jesse_Eichar: sorry got to run we are way over
[09:15] Jesse_Eichar: vera lost somea...
[09:15] moovida: oh, Jesse, I needed your comment
[09:15] jgarnett: gak!
[09:15] Jesse_Eichar: sorry andrea
[09:16] Jesse_Eichar: ummm
[09:16] moovida: well, we'll talk
[09:16] jgarnett: okay I can try and run the rest of the meeting.
[09:16] moovida: no problem
[09:16] jgarnett: moovida how many days/weeks do you have left?
[09:16] Jesse_Eichar: talk and I will read email tonight and in the morning
[09:16] moovida: Jesse_Eichar: ok
[09:16] jgarnett: And what do both you and Jesse plan to do?
[09:17] jgarnett: workshop? yes/no
[09:17] * moovida counting
[09:17] Jesse_Eichar: I have 2 workshops
[09:17] jgarnett: okay so that is a lab setting; directed at users?
[09:17] Jesse_Eichar: yes
[09:17] jgarnett: perhaps based on the stable branch and showing them the new stuff on trunk?
[09:17] moovida: Jesse_Eichar: 2 labs
[09:17] jgarnett: Or let them try trunk at the end?
[09:17] moovida: but I saw only one?
[09:18] moovida: do you have both Jesse?
[09:18] Jesse_Eichar: I I have 2
[09:18] moovida: we have a workshop
[09:18] Jesse_Eichar: as far as I know
[09:18] Jesse_Eichar: um
[09:18] Jesse_Eichar: I want to show trunk at one
[09:18] moovida: hmmm, I didn't see one in the list
[09:18] Jesse_Eichar: but not the other
[09:19] Jesse_Eichar: so maybe one got cancelled? wierd
[09:19] Jesse_Eichar: ok really got to go :P
[09:19] moovida: Silvia also was asking
[09:19] moovida: so check yourself, hope we are wrong
[09:19] Jesse_Eichar: ok
[09:19] moovida: Alright jgarnett
[09:19] *** Jesse_Eichar has left #udig.
[09:19] moovida: I have 4 weeks
[09:19] moovida: 1 workshop at Cape Town
[09:20] moovida: and a school right after that
[09:20] jgarnett: I just see one for Jesse - "There and back again"
[09:20] jgarnett: "a school" ?
[09:20] moovida: for professional engineering made with public admin and university
[09:20] *** CIA-43 has signed off IRC ().
[09:20] moovida: a course
[09:20] jgarnett: okay
[09:20] moovida: the university makes
[09:20] moovida: and we got through with making use udig+jgrass
[09:21] moovida: but it is the first time and that will spread usig+jgrass under professionals
[09:21] jgarnett: okay!
[09:21] moovida: so I need to be sure that what we use is ok
[09:21] jgarnett: so you have started using trunk
[09:21] jgarnett: and we are assembling jiras that matter
[09:21] moovida: yes, and I like that
[09:22] jgarnett: as sceen on this page: (Link: http://docs.codehaus.org/display/UDIG/Home)http://docs.codehaus.org/display/UDIG/Home
[09:22] moovida: I do not understand a thing
[09:22] moovida: but for sure someone will explain
[09:23] jgarnett: The list is of bugs marked as "Fix For" UDIG 1.2.M0"
[09:23] moovida: if many of you are on trunk for a while now.
[09:23] jgarnett: I am hoping you will tag bugs that matter with that so we can have them ready.
[09:23] moovida: why does noone report evident bugs we found?
[09:23] jgarnett: please continue.
[09:23] jgarnett: because some of them are very new
[09:23] moovida: jgarnett: thanks, now I see why the last didn' come
[09:23] moovida: oh, really
[09:24] jgarnett: the (Link: http://jira.codehaus.org/browse/UDIG-1415)http://jira.codehaus.org/browse/UDIG-1415 bug on wrong feature layer style visualiation
[09:24] moovida: ok, because at some point I thought we were alone :)
[09:24] jgarnett: is pretty much caused by our recent work on SLDParser
[09:24] jgarnett: you can ask emily_g for details.
[09:24] moovida: aha, now world is better
[09:24] moovida: because there are not so many bugs that are critical
[09:25] moovida: there is just one I can't explain, when the renderer goes mad on shapefiles
[09:25] moovida: and it doesn't display anything and freezes udig
[09:25] jgarnett: I do not think I have read that bug report
[09:26] moovida: didn't file it because I can't explain it
[09:26] jgarnett: I test with the sample data from walkthrough 1
[09:26] jgarnett: do you know how to reproduce it?
[09:26] moovida: it seems random to me now and no error
[09:26] moovida: no... that's the problem
[09:26] jgarnett: Jesse has completly rewritten shapefile datastore
[09:26] jgarnett: (last year)
[09:26] moovida: and it needs udig to reastart
[09:26] jgarnett: so it is different code than is being run than on the stable branch.
[09:27] moovida: jgarnett: how much could the new rendering metrics break? I mean, are we ok to get with that to CapeT?
[09:30] jgarnett: thinking
[09:30] jgarnett: you know your RenderingMetrics implementation?
[09:30] jgarnett: do you extend an abstract base class?
[09:31] jgarnett: If so we should be able to arrange for it not to break too badly.
[09:31] jgarnett: I would plan to spend 30min to 1 hour filling in the constants
[09:31] jgarnett: asking us questions
[09:31] jgarnett: and tuning?
[09:31] jgarnett: but the actual "fix" should only take a couple of moments.
[09:31] moovida: I implement the interface
[09:31] jgarnett: my hope is you will give us good feedback or discover something we did not catch in the meeting today.
[09:32] jgarnett: thinking
[09:32] moovida: I don't see big big problems on the new changes
[09:32] jgarnett: I have no wish to break people
[09:32] jgarnett: so what about breaking them hard now?
[09:32] moovida: :) I know that
[09:32] jgarnett: changing it from an interface from to an Abstract base class?
[09:32] jgarnett: so we do not suffer such "thrashing" in the future?
[09:33] moovida: sound like a plan
[09:33] jgarnett: emily_g ?
[09:33] emily_g: yes?
[09:34] jgarnett: use of abstract base class for RenderingMetrics yes/no ?
[09:35] jgarnett: moovida is that it for the topic about capetown?
[09:35] emily_g: yes - there is an AbstractRenderMetrics
[09:35] moovida: no, it was some more
[09:35] jgarnett: we will all fix bugs on trunk as needed; and try and use Jira and the mailing list to keep from going insane.
[09:35] jgarnett: okay please continue.
[09:35] moovida: but since only Jesse and me will be udig in SA
[09:36] moovida: Ok, if you tell me I can bother you guys with bugs and they get solved, I feel much more confortable
[09:36] emily_g: I don't know about removing the interface and only having an abstract class though
[09:36] moovida: I want to setup a build mechanism with Jesse's stuff
[09:37] moovida: Jody, you think that could be run on refractions server to have a snapshot version of udig trunc?
[09:37] jgarnett: I cannot help you with that; but it sounds like he bundled something up for you to try.
[09:37] jgarnett: moovida I think it could; but we have no staff to put on it.
[09:38] jgarnett: we have run build servers in the past; and given that our server seems to be down ever couple of days
[09:38] jgarnett: I do not want to try.
[09:38] moovida: ok, because I can also make up the build system
[09:38] *** kartben1 has joined #udig.
[09:38] jgarnett: (aside: not sure if you caught the good news - we have managed to determine some ports to block - so hopefully the evil bot will not kick over our server)
[09:38] moovida: assuming it works
[09:38] jgarnett: 4) "SelectionListener" naming conflict
[09:39] moovida: btu then I have bandwidth problems to make it accessible
[09:39] jgarnett: I understand the limitation.
[09:39] jgarnett: let me finish up the agenda here ...
[09:39] jgarnett: This is one of the points mentioned here - (Link: http://jira.codehaus.org/browse/UDIG-1419)http://jira.codehaus.org/browse/UDIG-1419
[09:39] jgarnett: In the udig code base Vitali has added a "SelectionListener" interface
[09:39] jgarnett: that has a name conflict with the eclipse SelectionListener interface
[09:40] jgarnett: so I am going to rename it.
[09:40] jgarnett: I think only Vitali's code will be broken after this (as not many others have used this api)
[09:40] jgarnett: my understanding is that this is a single component of uDig
[09:40] moovida: ok, but that should not give much prblems, right
[09:40] jgarnett: that watches the workbench selection
[09:40] jgarnett: and remembers the last ... Layer ?
[09:41] moovida: ? hmmm, no idea
[09:41] moovida: don't think I used that
[09:41] jgarnett: But yeah; this amounts to failing a code review; when we make new interfaces we should not conflict with existing Eclipse Facilities (or risk confusing people).
[09:41] jgarnett: that is it for me.
[09:41] moovida: ok
No comments:
Post a Comment