0. what is up
1. splitting up net.refractions.udig.project.ui
2. changing preference page groupsings on 1.1.x
3. bug smack 2008
4. Rendering Q&A
5. WPS client
simboss: did you have a chance to play with one of the new formats I added supports for?
simboss: jgarnett ping
Jesse_Eichar: I haven't.
Jesse_Eichar: I am too busy working on camptocamp stuff to be able to keep up with all the uDig changes
Jesse_Eichar: stuff is going crazy in the uDig camp
Jesse_Eichar: jgarnett is sleeping I think
jgarnett: morning
jgarnett: sorry I was hacking on udig before the meeting
jgarnett: want to fix some of these bugs
jgarnett: so silli does not get grumpy at me
Jesse_Eichar: :) got to keep our power user happy
jgarnett: pretty easy stuff so far; we must of been sleepy during the feature model transition.
Jesse_Eichar: If I remember it was nearly 5000 changes
silli: :-) thanks guys
Jesse_Eichar: not surprised we were sleeping through some of it
jgarnett: (note the create feature type dialog is pretty evil; trying to use a builder to hold state; we missed lots of stuff and made our code harder)
jgarnett: I am going to duck out to geotools and see if I can get points to draw correctly next.
jgarnett: 5 mins to meeting time
jgarnett: grab coffee :-P
Jesse_Eichar: good idea
Jesse_Eichar: brb
jgarnett: aside; can someone (other than me since I hate to nag)
jgarnett: send a reminder email to the list?
mauricio: hello
jgarnett: g'day
jgarnett: (ha ha Jesse already sent a reminder email)
Jesse_Eichar: ok I think we're here. Welcome back mauricio
Jesse_Eichar: agenda?
jgarnett: 1. Splitting up net.refractions.udig.project.ui
mauricio: Thanks
jgarnett: 2. changing preferences page groupings on 1.1.x
emily_g: if time permits I'd like to ask jesse a rendering question
jgarnett: 3. Bug Smack 2008
jgarnett: 4. Rendering Q&A
Jesse_Eichar: 5. WPS client
Jesse_Eichar: ok sounds good
mauricio: ok to me
Jesse_Eichar: 1. Splitting up net.refractions.udig.project.ui
Jesse_Eichar: go jody
Jesse_Eichar: or not
Jesse_Eichar: ...
Jesse_Eichar: I guess we will do 0) quick update first
Jesse_Eichar: Jesse: trunk headless build working again
Jesse_Eichar: Jesse: sextant-udig integrations
emily_g: Emily: I've updated the RenderMetrics with a bunch of additional metrics to use when rendering
Jesse_Eichar: Jesse: SpatialDataIntegrator-uDig integration
jgarnett: jgarnett - sorry was talking to aaime on #geotools about the point rendering bug. I am trying to be in bug fix mode but really I am just getting over being sick.
moovida: Jesse_Eichar: tell us more :)
moovida: trunk building on your machine?
moovida: I didn't see any commit
Jesse_Eichar: trunk not building came down to me removing a line in shared.properties
Jesse_Eichar: runPackager=true
Jesse_Eichar: apparently it is an undocumented property that makes the dependencies get packaged...
Jesse_Eichar: I had no idea.
moovida: I'll give it a go while we talk
Jesse_Eichar: here let me commit
moovida: what about sextante-sdi, were are you there?
CIA-53: UDig: jeichar * r30693 udig/extras/headlessbuild/ (2 files in 2 dirs): fix for trunk... I hope :)
Jesse_Eichar: Victor and I have a new perspective that lists all the algorithms and allows you to configure and run some of them
volaya: jesse has been doing s lot of work designing the interfaces
Jesse_Eichar: We don't have all the UI elements for all the input parameters there
volaya: and i am connecting that with the algorithms and the sextante stuff
jgarnett: Did you guys get to think about my IProcess email? And perhaps we should grab an agenda topic (so we are not here all morning)
Jesse_Eichar: we will see what we have for time.
Jesse_Eichar: It is on 1.1 though so it won't be critical til we port to trunk.
jgarnett: I am worried that you are doing lots of work designing the same interfaces as the WPS team?
jgarnett: gak? work on 1.1.x say it is not so ...
Jesse_Eichar: it is a plugin for 1.1
Jesse_Eichar: not on it
jgarnett: not so scary then.
jgarnett: but really we better get back onto our agenda or we will be sad when we all run out of time.
Jesse_Eichar: yep 1. Splitting up net.refractions.udig.project.ui
moovida: okky
Jesse_Eichar: go jody
jgarnett: For several weeks now we have talked about net.refractions.udig.project.widget right
jgarnett: well now it starts to effect your life
jgarnett: as we are ripping the implementation parts of net.refractions.udig.project.ui over into it.
jgarnett: Turns out that most of what we need to write; is stuck inside project.ui where we cannot depend on it (and it was written with the assumption of an Editor)
jgarnett: so we are carefully breaking that assumption.
jgarnett: gdavis_ is doing the work right now; I just wanted to follow up to the email and make sure everyone knew what was going on.
jgarnett: gdavis_ comments and/or questions?
Jesse_Eichar: this on trunk?
jgarnett: yes.
gdavis_: one comment is that besides moving some stuff out of project.ui I will also need to change a few interfaces to remove editor stuff
gdavis_: not big changes, just splitting up some interfaces into a couple, etc
Jesse_Eichar: Just to make sure. You are aware of the IMapPart interface
Jesse_Eichar: right?
gdavis_: im aware of mappart, but imappart?
Jesse_Eichar: ok maybe just mappart
gdavis_: yes
Jesse_Eichar: good
gdavis_: for instance that is one interface I need to update
mauricio: then sound a low impact
Jesse_Eichar: not surprised
gdavis_: public abstract MapEditorSite getMapEditorSite(); is something that is tied to a mapeditor
gdavis_: etc
Jesse_Eichar: right
Jesse_Eichar: ok go nuts
Jesse_Eichar: so jody... when are we going to get rid of plugins :P
gdavis_: so I will likely make a parent interface that doesn't have that, and a new "mappart" for editors called editormappart, or something similar
jgarnett: not sure I understand jesse?
gdavis_: anyways, I may have questions as I go along that I will email to the list.
Jesse_Eichar: just a joke, you always talk about collapsing plugins
Jesse_Eichar: sounds good.
jgarnett: yeah and it is getting worse and worse (sad)
Jesse_Eichar: thanks for the heads up
jgarnett: and also sad for me is that RCP customers like it this way ...
Jesse_Eichar: 2. changing preferences page groupings on 1.1.x
jgarnett: so I sent some email to the list
jgarnett: this is from an RCP customer working against the stable SDKs
jgarnett: (and it is really frustrating to explain why all the SDKs I ask them to use are not on the website - just in the downloads folder - we have to get back to "release early release often or the project looks dead)
jgarnett: so it is really a question for Jesse
jgarnett: are you going to tag 1.1.0?
jgarnett: or do I make the change and update the user guide to match?
jgarnett: (change is going out this morning ... cluft is on it)
Jesse_Eichar: I am doing the tag right now
Jesse_Eichar: don't commit anything to that branch until I am done
jgarnett: can you send email to the list when we are clear? I am not sure if cluft knows enough to make an SDK release from trunk on his own; and I will not have time to help him (it will be a good test of our docs)
jgarnett: thanks Jesse...
jgarnett: ... dare I ask if you are going to release 1.1.0 from that tag?
Jesse_Eichar: trunk or 1.1?
jgarnett: 1.1
Jesse_Eichar: I made a release last night
Jesse_Eichar: I have to post it
jgarnett: sweet.
Jesse_Eichar: oh good grief good luck making a build from 1.1
Jesse_Eichar: I will have to help him personally
Jesse_Eichar: there is no way he can do it
Jesse_Eichar: :)
jgarnett: I have made SDK releases from 1.1.x before? has anything gotten worse since June?
jgarnett: (sorry this RCP customer is a short term project and thus on the stable branch)
Jesse_Eichar: You might have made one but I wouldn't guarantee that it was a solid sdk.
jgarnett: they are more using it as a framework for their own data; not even using Features
jgarnett: Jesse_Eichar++
jgarnett: well we will fall off that bridge next week then.
jgarnett: moving on?
Jesse_Eichar: 3. Bug Smack 2008
jgarnett: moovida/silli this one is for you.
moovida: is that ours?
jgarnett: We had a breakout IRC (logs are posted)
moovida: :)
jgarnett: and I have fixed a few of the bugs
silli: :-) I am here...
moovida: yes, what to say about it?
jgarnett: (create feature type; and I am looking at the point color now)
moovida: didn't see the jira closed pass
moovida: did you commit them?
jgarnett: I was away yesterday and have not even managed to read your email on the topic (bad jody)
moovida: :) ok
jgarnett: create feature type changes were committed last night.
silli: create new layer has the feature type to correct and the projection (default)
jgarnett: So is this a case where I need to read your email
jgarnett: and we need to send lots of email and use Jira to keep our head on straight?
silli: to correct == to be corrected
Jesse_Eichar: ...
jgarnett: looks like we stalled.
Jesse_Eichar: yhep
moovida: don't see exactly what I should answer
jgarnett: Is there anything else to talk about right now? Or should we take this to email.
silli: ok but for me it is hard to understand if some little bugs belongs to the same or not
jgarnett: anything pressing that should be fixed right now?
moovida: we are at the same point as two days ago I think
moovida: just yesterday you were sick
jgarnett: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10600&fixfor=13063
jgarnett: I see 5 bugs reported; that is correct?
moovida: and so we are waiting for the first fixes to go through
silli: the problem with the advance graphic is solved
jgarnett: so you are waiting for me to fix these 5 bugs; and then going to give me more?
silli: I found the point to disable it
jgarnett: (jesse you had only put the "Advanced Graphics" toggle on if they were on linux - apparently they use that because it is faster for the editing tools!)
silli: the style visualization now works with this problems
silli: 1. points -> become black if restarting udig
silli: it is faster also for panning zooming...
silli: Jody is working on points
silli: 2. polygons on my pc (I think it is the only one) have no transparency
silli: 3. selection on my pc doesn't work for the map view, only in the table view
Jesse_Eichar: comments ?
Jesse_Eichar: jody?
jgarnett: I am trying to match this list with Jira
silli: layer create is on fixing
jgarnett: and coming up blank...
jgarnett: 1. points ...
jgarnett: yes I am working on that.
jgarnett: (not sure about faster panning & zooming? but I did find that *lots* of logging was being done - hopefully by mistake)
jgarnett: 2. polygons without transparency?
silli: import using the wizard has the third panel blank
moovida: 2 and 3 are a problem that is evident only to some pcswith particular graphic cards
jgarnett: not sure about that ...
silli: ok that could be
jgarnett: 3. selection
silli: or particular configurations
jgarnett: I have seen this on a slower computer; looks to be a refresh problem?
jgarnett: 4. layer creating
Jesse_Eichar: for 2 and 3 are you using advanced graphics or not?
silli: do somebody of you have these problems?
silli: no
silli: but I tried and it is the same
silli: with advance graphic or not
Jesse_Eichar: ok
jgarnett: (layer creating is getting better but will require testing)
jgarnett: that is my response; but I am having trouble keeping this straight; I am going to go through email and put this stuff in jira.
jgarnett: will send an update email when that is done (I may have some questions)
silli: I will test if it is ok
Jesse_Eichar: 4. Rendering Q&A
silli: ok
Jesse_Eichar: emily_g
Jesse_Eichar: you had some questions?
emily_g: first thanks for you help yesterda
emily_g: but I have a new problem
emily_g: I have a flock of seagulls
emily_g: randomly moving around the screen
emily_g: most of the time the background doesn't flicker
emily_g: every now and then the blackground flickers
emily_g: I'm wondering if you might be able to tell me where to look
jgarnett: (it is almost like we are not being double buffered)
emily_g: its doesn't consistently flicker
Jesse_Eichar: Hard problem.
emily_g: :)
Jesse_Eichar: why don't we go on to 5 and I wil think a bit
Jesse_Eichar: 5. WPS client
emily_g: sure
***moovida wanted to add this bug http://jira.codehaus.org/browse/UDIG-1416 to fix version 1.2M0, but couldn't.
Jesse_Eichar: volaya - victor you want to start this one?
volaya: yes, ok
***moovida asks Jody to do it, since he created it before havin rights
volaya: I hav received some money to implement a WPS client in SEXTANTE
volaya: so WPS processes can be wrapped and executed as SEXTANTE algorithms...
volaya: I know that some of you are doing similar things, so I would like to see how to do a common effort
volaya: and of course link this with the integration of SEXTANTE in uDig, which is going quite well (thanks to jesse ;-) )
jgarnett: gdavis_ is your contact here volaya
volaya: Maybe graham of jody could tell us about their plans regarding wps, and how they see a possible collaboration
moovida: do you mean a WPS client in Udig for sextante?
jgarnett: my understanding is that if you wrap your functionality in a GeoTools ProcessFactory
jgarnett: it will be visible to the geoserver WPS plugin.
jgarnett: oh .. client (sorry trying again)
volaya: I mean that sextante would be a wps client, and all the GIS that have analysis capabilities based on sextante will be able to run wps processes
jgarnett: geotools has an process module
jgarnett: and a wps module
jgarnett: the wps module is the client code to talk to a WPS server (at a very low level)
moovida: alright, I think there is confusion here#
moovida: yes, so sextante modules are on serverside
jgarnett: you can reuse that low level code; and use it to talk to the server.
moovida: are you planning to create a WPS client for sextante ?
gdavis_: in udig? or?
moovida: or a client in udig for geotools?
jgarnett: we have a processfactory implementation that shows how to go from GeoTools Process API (high level) to WPS client API (low level). You would do something similar?
volaya: I have been looking to the udig and openjump clients made by the guys at 52 North
moovida: I'm trying to understand... there is much anarchy today :)
jgarnett: gdavis do you have any wiki links?
gdavis_: sure 1 sec
Jesse_Eichar: slow down slow down
Jesse_Eichar: volaya finish explaining what you are going to do
volaya: :-)
jgarnett: (sigh)
Jesse_Eichar: Too much excitement here :)
moovida: excitment == confusion
moovida: go volaya
volaya: The idea is that know sextante is a set of geoalgorithms (local ones)...and it will be a set of local algorithms + wps processes, all running under the same framework
Jesse_Eichar: so WPS process will be wrapped with the Sextante API?
volaya: exactly
gdavis_: so sort of the opposite of what someone else was doing (wrapping sextante processes into WPS processes)
Jesse_Eichar: ah. So the current Sextante UI for uDig, GVSIG etc... would be able to seemlessly have WPS processes as well
volaya: for most of the processes, that will make in unnecessary to create any interface, since sextante itself can create them based on the requirements of the algorithm
volaya: whether is a "normal" one, or based on a WPS process
gdavis_: well wps processes in udig use a geotools process api described here: http://docs.codehaus.org/display/GEOTDOC/Process+API
moovida: volaya: would this force everyone that want to exploit it to fit in your framework?
gdavis_: so it sounds like you will want to wrap those into sextante processes
moovida: that would be a strange way to walk
jgarnett: guys we missed a step
jgarnett: the Process API gdavis described above is what I wanted feedback from voloya on a couple weeks ago (so far nothing?)
jgarnett: that is the high level api for a java developer right.
jgarnett: there is a low level api for talking to a WPS service
jgarnett: that is what voloya would like to use; ie he would like to wrap up that API in his own interfaces
gdavis_: yes but it sounds like he just wants to wrap processes
jgarnett: I think he wants to wrap the WPS client code
jgarnett: (and ignore the Process interface)
gdavis_: hmmm
moovida: volaya: many think to know what you do :) enlight us
jgarnett: voloya comments?
jgarnett: :-P
gdavis_: well he cant ignore it completely. the wps client code passes around processes
jgarnett: really? that should not of gotten past me ...
volaya: I was asking more about apis to access the wps processes. I have used that api to expose a sextante algorithm as a geotools process, i guess i already told you about that, didn't I?
jgarnett: yes; but I was hoping for more details (and things you would like changed)
jgarnett: (ie how did we do?)
volaya: Well, the geotools api look great to me , and it is very similar to the sextante one, but i am not using it at the moment...
volaya: but it should not be difficult to do it the other way round, wrapping a geotools process as a sextante algorithm
mauricio: please confirm this
mauricio: wps client -> WPS -> ProcessApi -> binding sextante -> sextante api
moovida: :) but the "standard" is geotools Victor
moovida: wouldn't it be better the way round?
Jesse_Eichar: says you moovida, not all of th GVSIG guys
Jesse_Eichar: Do remember that sextante started out as a sextante plugin
jgarnett: let me go slower mauricio
Jesse_Eichar: and only recently decided to try to play with everyone else.
volaya: well..that would mean refactoring 200+ algorithms :-S
jgarnett: voloya we would rather align the geotools Process API with your work.
moovida: ok, that was what I wanted to hear
volaya: but I wouldn't mind to have all my geoalgs based on the geotools api, that's true
jgarnett: but we cannot because of GPL
jgarnett: so can we make it method compatible or something?
jgarnett: (also not our project has ended; so we cannot really help)
jgarnett: we would like it to start up again ... but we are not sure when.
Jesse_Eichar: Perhaps you can help with informal support on how to use the API?
volaya: ok, no problem...I am just trying to see what other people ar doing in this direction, since i think that we are many people doing the same, so it would be good to cooperate
jgarnett: so at the geotools level there are *two* apis (have I made that clear?) if not I would like to talk about the difference - I am not sure if both have a wiki page or not....
gdavis_: yes they do
volaya: I am familiar with the process api...will have a look at the low level one that you mentioned
gdavis_: http://docs.codehaus.org/display/GEOTDOC/WPS is the geotools wps module for WPS service/client stuff
jgarnett: The WPS Module (is very similar to our WMS module) takes care of parsing the capabilities and dispatching requests and all that ...
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/WPS+Module is the module page
jgarnett: And you already know about the Process API...
volaya: ok, great
gdavis_: that page you linked to it not the full docs jody, the one I linked to it
gdavis_: is*
jgarnett: yeah I see that (thanks muchly - I am going to link from one to the other)
jgarnett: We only have a couple more minuets left ...
Jesse_Eichar: ok back to emily...
Jesse_Eichar: and rendering?
Jesse_Eichar: gulp...
emily_g: :)
emily_g: one of my bigger problems is I don't know where to look
emily_g: I know if I put in some breakpoints and stop it before it draws the next image
emily_g: I see a white image on the screen every now and then
emily_g: which makes me think that the image is being drawn to the screen before it has been composed
Jesse_Eichar: So what we need to find out is if the CompositeRenderer is requesting the map to show an empty map sometimes
moovida: jgarnett: could you update the JIRA http://jira.codehaus.org/browse/UDIG-1416 please? I don't seem to have the right for that.
Jesse_Eichar: s requesting the map = is requesting the ViewportPane
emily_g: I was writing out all the "composed" images to disk
emily_g: and when I added this code I never got any white images
emily_g: nor did I see any flickering
Jesse_Eichar: of course it is a timing issue
Jesse_Eichar: if you add a debug point you will likely won't get it either.
emily_g: but the odd thing was that I did see an empty screen when I added a debug point
emily_g: but maybe that was a different spot
Jesse_Eichar: where did you put it?
emily_g: thinking ...
emily_g: I put my write the image to disk statement in the ViewportPaneSWT - createImage() class
emily_g: after renderManager.getImage()
Jesse_Eichar: Ah I have an idea...
emily_g: I think my breakpoint was in the getDoubleBufferGraphics method somehwere
emily_g: I like ideas :)
Jesse_Eichar: Here is the potential scenario
Jesse_Eichar: The viewportPane is on the display thread which is different than the thread composing the image
Jesse_Eichar: so here we go
Jesse_Eichar: CR (CompositeRenderer) composes an image and asks the viewportPane to display it
Jesse_Eichar: viewportPane (in another thead) grabs the image to copy it to a SWT image ( or wrap it in a SWT wrapper)
Jesse_Eichar: just as it enters the method the CompositeRenderer is asked to update and it clears its image
Jesse_Eichar: then back in the other thread the viewportPane draws a blank image to the SWT Image
emily_g: this sounds reasonable to me
emily_g: so do I need to buffer the image in the compositerenderer ?
Jesse_Eichar: I think it is a synchronization issue.
Jesse_Eichar: buffering the image in compositeRenderer won't do it because the buffer still could get cleared
Jesse_Eichar: I can think of 2 ideas.
gdavis_: maybe lock the image for read/write synching between threads?
gdavis_: I did something similar with the tiles emily
Jesse_Eichar: 1. make a copy and pass it in the refresh request.. This sounds expensive to me because it is making lots of copies of the images
Jesse_Eichar: It is more difficult than that unfortunately graham
gdavis_: oh? ok
Jesse_Eichar: only slightly though
Jesse_Eichar: it is because the request is an event that is placed on a event queue.
Jesse_Eichar: So you could be blocking the composite renderer until the ViewportPane has time to update it
Jesse_Eichar: in which case you could get a severe performance hit
Jesse_Eichar: My second idea is to use the "loan" pattern
gdavis_: is the image actually empty/null in this case, or is it a proper image that happens to be white?
Jesse_Eichar: #2
gdavis_: ah, that does make it trickier ya
emily_g: I don't know graham
gdavis_: because a proper image could happen to be white too so you couldnt test if it was "empty"
Jesse_Eichar: use the Collections strategy for detecting a synchronous update
***moovida has to run. Thanks for the chat...
Jesse_Eichar: the idea is topass a number or a timestamp to the ViewportPane in the request
Jesse_Eichar: and when the ViewportPane checks the image it compares the timestamp to verify that it is the right one
Jesse_Eichar: if not then it knows that the image has been update and it waits for the new request
emily_g: doesn't that have the potential of never drawing anything on the screen?
Jesse_Eichar: if the CompositeRenderer update the image it should always make a request after the update.
emily_g: by the time it gets the image the number could have been updated and nothing is drawn; this repeats itself?
Jesse_Eichar: true enough
emily_g: this is probably unlikely though
Jesse_Eichar: very unlikely since the viewport model should be much faster.
Jesse_Eichar: but you probably do need to make a check for that
emily_g: can you point me to where the request is made from the CompositeRenderer to the viewportPane?
Jesse_Eichar: so maybe an opposite direction communication.
gdavis_: jesse, before you go, I sent you a quick question in a PM
Jesse_Eichar: Did that last comment make sense emily?
Jesse_Eichar: maybe everytime the image is accessed the timestamp on the image is changes so both directions can validate that the image is being used in a responsible manner.
emily_g: thinking
Jesse_Eichar: I am just brainstorming you have to make it work so do what you think is apropriate
Jesse_Eichar: Sorry I have to run now
Jesse_Eichar: Its late
emily_g: thats fine jesse - thanks for you help
emily_g: as least I have an idea of what the problem might be
Jesse_Eichar: ok ciao
mauricio: bye everyone
jgarnett: thanks
jgarnett: I suppose I better post the logs...
jgarnett: ... and try and catch up with what emily_g and Jesse were up to
jgarnett: silli and mauricio - I added everything mentioned on email
jgarnett: to Jira
jgarnett: and made this page here
jgarnett: http://udig.refractions.net/confluence/display/HACK/Home
jgarnett: have a list of everything you consider important.
mauricio: ok good
jgarnett: the list is based on "fix for UDIG 1.2-M0"
jgarnett: so if you see anything in that list that you do not *need* for capetown
jgarnett: please mark is as 'fix for' something later ...
simboss: jgarnett ping
Jesse_Eichar: I haven't.
Jesse_Eichar: I am too busy working on camptocamp stuff to be able to keep up with all the uDig changes
Jesse_Eichar: stuff is going crazy in the uDig camp
Jesse_Eichar: jgarnett is sleeping I think
jgarnett: morning
jgarnett: sorry I was hacking on udig before the meeting
jgarnett: want to fix some of these bugs
jgarnett: so silli does not get grumpy at me
Jesse_Eichar: :) got to keep our power user happy
jgarnett: pretty easy stuff so far; we must of been sleepy during the feature model transition.
Jesse_Eichar: If I remember it was nearly 5000 changes
silli: :-) thanks guys
Jesse_Eichar: not surprised we were sleeping through some of it
jgarnett: (note the create feature type dialog is pretty evil; trying to use a builder to hold state; we missed lots of stuff and made our code harder)
jgarnett: I am going to duck out to geotools and see if I can get points to draw correctly next.
jgarnett: 5 mins to meeting time
jgarnett: grab coffee :-P
Jesse_Eichar: good idea
Jesse_Eichar: brb
jgarnett: aside; can someone (other than me since I hate to nag)
jgarnett: send a reminder email to the list?
mauricio: hello
jgarnett: g'day
jgarnett: (ha ha Jesse already sent a reminder email)
Jesse_Eichar: ok I think we're here. Welcome back mauricio
Jesse_Eichar: agenda?
jgarnett: 1. Splitting up net.refractions.udig.project.ui
mauricio: Thanks
jgarnett: 2. changing preferences page groupings on 1.1.x
emily_g: if time permits I'd like to ask jesse a rendering question
jgarnett: 3. Bug Smack 2008
jgarnett: 4. Rendering Q&A
Jesse_Eichar: 5. WPS client
Jesse_Eichar: ok sounds good
mauricio: ok to me
Jesse_Eichar: 1. Splitting up net.refractions.udig.project.ui
Jesse_Eichar: go jody
Jesse_Eichar: or not
Jesse_Eichar: ...
Jesse_Eichar: I guess we will do 0) quick update first
Jesse_Eichar: Jesse: trunk headless build working again
Jesse_Eichar: Jesse: sextant-udig integrations
emily_g: Emily: I've updated the RenderMetrics with a bunch of additional metrics to use when rendering
Jesse_Eichar: Jesse: SpatialDataIntegrator-uDig integration
jgarnett: jgarnett - sorry was talking to aaime on #geotools about the point rendering bug. I am trying to be in bug fix mode but really I am just getting over being sick.
moovida: Jesse_Eichar: tell us more :)
moovida: trunk building on your machine?
moovida: I didn't see any commit
Jesse_Eichar: trunk not building came down to me removing a line in shared.properties
Jesse_Eichar: runPackager=true
Jesse_Eichar: apparently it is an undocumented property that makes the dependencies get packaged...
Jesse_Eichar: I had no idea.
moovida: I'll give it a go while we talk
Jesse_Eichar: here let me commit
moovida: what about sextante-sdi, were are you there?
CIA-53: UDig: jeichar * r30693 udig/extras/headlessbuild/ (2 files in 2 dirs): fix for trunk... I hope :)
Jesse_Eichar: Victor and I have a new perspective that lists all the algorithms and allows you to configure and run some of them
volaya: jesse has been doing s lot of work designing the interfaces
Jesse_Eichar: We don't have all the UI elements for all the input parameters there
volaya: and i am connecting that with the algorithms and the sextante stuff
jgarnett: Did you guys get to think about my IProcess email? And perhaps we should grab an agenda topic (so we are not here all morning)
Jesse_Eichar: we will see what we have for time.
Jesse_Eichar: It is on 1.1 though so it won't be critical til we port to trunk.
jgarnett: I am worried that you are doing lots of work designing the same interfaces as the WPS team?
jgarnett: gak? work on 1.1.x say it is not so ...
Jesse_Eichar: it is a plugin for 1.1
Jesse_Eichar: not on it
jgarnett: not so scary then.
jgarnett: but really we better get back onto our agenda or we will be sad when we all run out of time.
Jesse_Eichar: yep 1. Splitting up net.refractions.udig.project.ui
moovida: okky
Jesse_Eichar: go jody
jgarnett: For several weeks now we have talked about net.refractions.udig.project.widget right
jgarnett: well now it starts to effect your life
jgarnett: as we are ripping the implementation parts of net.refractions.udig.project.ui over into it.
jgarnett: Turns out that most of what we need to write; is stuck inside project.ui where we cannot depend on it (and it was written with the assumption of an Editor)
jgarnett: so we are carefully breaking that assumption.
jgarnett: gdavis_ is doing the work right now; I just wanted to follow up to the email and make sure everyone knew what was going on.
jgarnett: gdavis_ comments and/or questions?
Jesse_Eichar: this on trunk?
jgarnett: yes.
gdavis_: one comment is that besides moving some stuff out of project.ui I will also need to change a few interfaces to remove editor stuff
gdavis_: not big changes, just splitting up some interfaces into a couple, etc
Jesse_Eichar: Just to make sure. You are aware of the IMapPart interface
Jesse_Eichar: right?
gdavis_: im aware of mappart, but imappart?
Jesse_Eichar: ok maybe just mappart
gdavis_: yes
Jesse_Eichar: good
gdavis_: for instance that is one interface I need to update
mauricio: then sound a low impact
Jesse_Eichar: not surprised
gdavis_: public abstract MapEditorSite getMapEditorSite(); is something that is tied to a mapeditor
gdavis_: etc
Jesse_Eichar: right
Jesse_Eichar: ok go nuts
Jesse_Eichar: so jody... when are we going to get rid of plugins :P
gdavis_: so I will likely make a parent interface that doesn't have that, and a new "mappart" for editors called editormappart, or something similar
jgarnett: not sure I understand jesse?
gdavis_: anyways, I may have questions as I go along that I will email to the list.
Jesse_Eichar: just a joke, you always talk about collapsing plugins
Jesse_Eichar: sounds good.
jgarnett: yeah and it is getting worse and worse (sad)
Jesse_Eichar: thanks for the heads up
jgarnett: and also sad for me is that RCP customers like it this way ...
Jesse_Eichar: 2. changing preferences page groupings on 1.1.x
jgarnett: so I sent some email to the list
jgarnett: this is from an RCP customer working against the stable SDKs
jgarnett: (and it is really frustrating to explain why all the SDKs I ask them to use are not on the website - just in the downloads folder - we have to get back to "release early release often or the project looks dead)
jgarnett: so it is really a question for Jesse
jgarnett: are you going to tag 1.1.0?
jgarnett: or do I make the change and update the user guide to match?
jgarnett: (change is going out this morning ... cluft is on it)
Jesse_Eichar: I am doing the tag right now
Jesse_Eichar: don't commit anything to that branch until I am done
jgarnett: can you send email to the list when we are clear? I am not sure if cluft knows enough to make an SDK release from trunk on his own; and I will not have time to help him (it will be a good test of our docs)
jgarnett: thanks Jesse...
jgarnett: ... dare I ask if you are going to release 1.1.0 from that tag?
Jesse_Eichar: trunk or 1.1?
jgarnett: 1.1
Jesse_Eichar: I made a release last night
Jesse_Eichar: I have to post it
jgarnett: sweet.
Jesse_Eichar: oh good grief good luck making a build from 1.1
Jesse_Eichar: I will have to help him personally
Jesse_Eichar: there is no way he can do it
Jesse_Eichar: :)
jgarnett: I have made SDK releases from 1.1.x before? has anything gotten worse since June?
jgarnett: (sorry this RCP customer is a short term project and thus on the stable branch)
Jesse_Eichar: You might have made one but I wouldn't guarantee that it was a solid sdk.
jgarnett: they are more using it as a framework for their own data; not even using Features
jgarnett: Jesse_Eichar++
jgarnett: well we will fall off that bridge next week then.
jgarnett: moving on?
Jesse_Eichar: 3. Bug Smack 2008
jgarnett: moovida/silli this one is for you.
moovida: is that ours?
jgarnett: We had a breakout IRC (logs are posted)
moovida: :)
jgarnett: and I have fixed a few of the bugs
silli: :-) I am here...
moovida: yes, what to say about it?
jgarnett: (create feature type; and I am looking at the point color now)
moovida: didn't see the jira closed pass
moovida: did you commit them?
jgarnett: I was away yesterday and have not even managed to read your email on the topic (bad jody)
moovida: :) ok
jgarnett: create feature type changes were committed last night.
silli: create new layer has the feature type to correct and the projection (default)
jgarnett: So is this a case where I need to read your email
jgarnett: and we need to send lots of email and use Jira to keep our head on straight?
silli: to correct == to be corrected
Jesse_Eichar: ...
jgarnett: looks like we stalled.
Jesse_Eichar: yhep
moovida: don't see exactly what I should answer
jgarnett: Is there anything else to talk about right now? Or should we take this to email.
silli: ok but for me it is hard to understand if some little bugs belongs to the same or not
jgarnett: anything pressing that should be fixed right now?
moovida: we are at the same point as two days ago I think
moovida: just yesterday you were sick
jgarnett: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10600&fixfor=13063
jgarnett: I see 5 bugs reported; that is correct?
moovida: and so we are waiting for the first fixes to go through
silli: the problem with the advance graphic is solved
jgarnett: so you are waiting for me to fix these 5 bugs; and then going to give me more?
silli: I found the point to disable it
jgarnett: (jesse you had only put the "Advanced Graphics" toggle on if they were on linux - apparently they use that because it is faster for the editing tools!)
silli: the style visualization now works with this problems
silli: 1. points -> become black if restarting udig
silli: it is faster also for panning zooming...
silli: Jody is working on points
silli: 2. polygons on my pc (I think it is the only one) have no transparency
silli: 3. selection on my pc doesn't work for the map view, only in the table view
Jesse_Eichar: comments ?
Jesse_Eichar: jody?
jgarnett: I am trying to match this list with Jira
silli: layer create is on fixing
jgarnett: and coming up blank...
jgarnett: 1. points ...
jgarnett: yes I am working on that.
jgarnett: (not sure about faster panning & zooming? but I did find that *lots* of logging was being done - hopefully by mistake)
jgarnett: 2. polygons without transparency?
silli: import using the wizard has the third panel blank
moovida: 2 and 3 are a problem that is evident only to some pcswith particular graphic cards
jgarnett: not sure about that ...
silli: ok that could be
jgarnett: 3. selection
silli: or particular configurations
jgarnett: I have seen this on a slower computer; looks to be a refresh problem?
jgarnett: 4. layer creating
Jesse_Eichar: for 2 and 3 are you using advanced graphics or not?
silli: do somebody of you have these problems?
silli: no
silli: but I tried and it is the same
silli: with advance graphic or not
Jesse_Eichar: ok
jgarnett: (layer creating is getting better but will require testing)
jgarnett: that is my response; but I am having trouble keeping this straight; I am going to go through email and put this stuff in jira.
jgarnett: will send an update email when that is done (I may have some questions)
silli: I will test if it is ok
Jesse_Eichar: 4. Rendering Q&A
silli: ok
Jesse_Eichar: emily_g
Jesse_Eichar: you had some questions?
emily_g: first thanks for you help yesterda
emily_g: but I have a new problem
emily_g: I have a flock of seagulls
emily_g: randomly moving around the screen
emily_g: most of the time the background doesn't flicker
emily_g: every now and then the blackground flickers
emily_g: I'm wondering if you might be able to tell me where to look
jgarnett: (it is almost like we are not being double buffered)
emily_g: its doesn't consistently flicker
Jesse_Eichar: Hard problem.
emily_g: :)
Jesse_Eichar: why don't we go on to 5 and I wil think a bit
Jesse_Eichar: 5. WPS client
emily_g: sure
***moovida wanted to add this bug http://jira.codehaus.org/browse/UDIG-1416 to fix version 1.2M0, but couldn't.
Jesse_Eichar: volaya - victor you want to start this one?
volaya: yes, ok
***moovida asks Jody to do it, since he created it before havin rights
volaya: I hav received some money to implement a WPS client in SEXTANTE
volaya: so WPS processes can be wrapped and executed as SEXTANTE algorithms...
volaya: I know that some of you are doing similar things, so I would like to see how to do a common effort
volaya: and of course link this with the integration of SEXTANTE in uDig, which is going quite well (thanks to jesse ;-) )
jgarnett: gdavis_ is your contact here volaya
volaya: Maybe graham of jody could tell us about their plans regarding wps, and how they see a possible collaboration
moovida: do you mean a WPS client in Udig for sextante?
jgarnett: my understanding is that if you wrap your functionality in a GeoTools ProcessFactory
jgarnett: it will be visible to the geoserver WPS plugin.
jgarnett: oh .. client (sorry trying again)
volaya: I mean that sextante would be a wps client, and all the GIS that have analysis capabilities based on sextante will be able to run wps processes
jgarnett: geotools has an process module
jgarnett: and a wps module
jgarnett: the wps module is the client code to talk to a WPS server (at a very low level)
moovida: alright, I think there is confusion here#
moovida: yes, so sextante modules are on serverside
jgarnett: you can reuse that low level code; and use it to talk to the server.
moovida: are you planning to create a WPS client for sextante ?
gdavis_: in udig? or?
moovida: or a client in udig for geotools?
jgarnett: we have a processfactory implementation that shows how to go from GeoTools Process API (high level) to WPS client API (low level). You would do something similar?
volaya: I have been looking to the udig and openjump clients made by the guys at 52 North
moovida: I'm trying to understand... there is much anarchy today :)
jgarnett: gdavis do you have any wiki links?
gdavis_: sure 1 sec
Jesse_Eichar: slow down slow down
Jesse_Eichar: volaya finish explaining what you are going to do
volaya: :-)
jgarnett: (sigh)
Jesse_Eichar: Too much excitement here :)
moovida: excitment == confusion
moovida: go volaya
volaya: The idea is that know sextante is a set of geoalgorithms (local ones)...and it will be a set of local algorithms + wps processes, all running under the same framework
Jesse_Eichar: so WPS process will be wrapped with the Sextante API?
volaya: exactly
gdavis_: so sort of the opposite of what someone else was doing (wrapping sextante processes into WPS processes)
Jesse_Eichar: ah. So the current Sextante UI for uDig, GVSIG etc... would be able to seemlessly have WPS processes as well
volaya: for most of the processes, that will make in unnecessary to create any interface, since sextante itself can create them based on the requirements of the algorithm
volaya: whether is a "normal" one, or based on a WPS process
gdavis_: well wps processes in udig use a geotools process api described here: http://docs.codehaus.org/display/GEOTDOC/Process+API
moovida: volaya: would this force everyone that want to exploit it to fit in your framework?
gdavis_: so it sounds like you will want to wrap those into sextante processes
moovida: that would be a strange way to walk
jgarnett: guys we missed a step
jgarnett: the Process API gdavis described above is what I wanted feedback from voloya on a couple weeks ago (so far nothing?)
jgarnett: that is the high level api for a java developer right.
jgarnett: there is a low level api for talking to a WPS service
jgarnett: that is what voloya would like to use; ie he would like to wrap up that API in his own interfaces
gdavis_: yes but it sounds like he just wants to wrap processes
jgarnett: I think he wants to wrap the WPS client code
jgarnett: (and ignore the Process interface)
gdavis_: hmmm
moovida: volaya: many think to know what you do :) enlight us
jgarnett: voloya comments?
jgarnett: :-P
gdavis_: well he cant ignore it completely. the wps client code passes around processes
jgarnett: really? that should not of gotten past me ...
volaya: I was asking more about apis to access the wps processes. I have used that api to expose a sextante algorithm as a geotools process, i guess i already told you about that, didn't I?
jgarnett: yes; but I was hoping for more details (and things you would like changed)
jgarnett: (ie how did we do?)
volaya: Well, the geotools api look great to me , and it is very similar to the sextante one, but i am not using it at the moment...
volaya: but it should not be difficult to do it the other way round, wrapping a geotools process as a sextante algorithm
mauricio: please confirm this
mauricio: wps client -> WPS -> ProcessApi -> binding sextante -> sextante api
moovida: :) but the "standard" is geotools Victor
moovida: wouldn't it be better the way round?
Jesse_Eichar: says you moovida, not all of th GVSIG guys
Jesse_Eichar: Do remember that sextante started out as a sextante plugin
jgarnett: let me go slower mauricio
Jesse_Eichar: and only recently decided to try to play with everyone else.
volaya: well..that would mean refactoring 200+ algorithms :-S
jgarnett: voloya we would rather align the geotools Process API with your work.
moovida: ok, that was what I wanted to hear
volaya: but I wouldn't mind to have all my geoalgs based on the geotools api, that's true
jgarnett: but we cannot because of GPL
jgarnett: so can we make it method compatible or something?
jgarnett: (also not our project has ended; so we cannot really help)
jgarnett: we would like it to start up again ... but we are not sure when.
Jesse_Eichar: Perhaps you can help with informal support on how to use the API?
volaya: ok, no problem...I am just trying to see what other people ar doing in this direction, since i think that we are many people doing the same, so it would be good to cooperate
jgarnett: so at the geotools level there are *two* apis (have I made that clear?) if not I would like to talk about the difference - I am not sure if both have a wiki page or not....
gdavis_: yes they do
volaya: I am familiar with the process api...will have a look at the low level one that you mentioned
gdavis_: http://docs.codehaus.org/display/GEOTDOC/WPS is the geotools wps module for WPS service/client stuff
jgarnett: The WPS Module (is very similar to our WMS module) takes care of parsing the capabilities and dispatching requests and all that ...
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/WPS+Module is the module page
jgarnett: And you already know about the Process API...
volaya: ok, great
gdavis_: that page you linked to it not the full docs jody, the one I linked to it
gdavis_: is*
jgarnett: yeah I see that (thanks muchly - I am going to link from one to the other)
jgarnett: We only have a couple more minuets left ...
Jesse_Eichar: ok back to emily...
Jesse_Eichar: and rendering?
Jesse_Eichar: gulp...
emily_g: :)
emily_g: one of my bigger problems is I don't know where to look
emily_g: I know if I put in some breakpoints and stop it before it draws the next image
emily_g: I see a white image on the screen every now and then
emily_g: which makes me think that the image is being drawn to the screen before it has been composed
Jesse_Eichar: So what we need to find out is if the CompositeRenderer is requesting the map to show an empty map sometimes
moovida: jgarnett: could you update the JIRA http://jira.codehaus.org/browse/UDIG-1416 please? I don't seem to have the right for that.
Jesse_Eichar: s requesting the map = is requesting the ViewportPane
emily_g: I was writing out all the "composed" images to disk
emily_g: and when I added this code I never got any white images
emily_g: nor did I see any flickering
Jesse_Eichar: of course it is a timing issue
Jesse_Eichar: if you add a debug point you will likely won't get it either.
emily_g: but the odd thing was that I did see an empty screen when I added a debug point
emily_g: but maybe that was a different spot
Jesse_Eichar: where did you put it?
emily_g: thinking ...
emily_g: I put my write the image to disk statement in the ViewportPaneSWT - createImage() class
emily_g: after renderManager.getImage()
Jesse_Eichar: Ah I have an idea...
emily_g: I think my breakpoint was in the getDoubleBufferGraphics method somehwere
emily_g: I like ideas :)
Jesse_Eichar: Here is the potential scenario
Jesse_Eichar: The viewportPane is on the display thread which is different than the thread composing the image
Jesse_Eichar: so here we go
Jesse_Eichar: CR (CompositeRenderer) composes an image and asks the viewportPane to display it
Jesse_Eichar: viewportPane (in another thead) grabs the image to copy it to a SWT image ( or wrap it in a SWT wrapper)
Jesse_Eichar: just as it enters the method the CompositeRenderer is asked to update and it clears its image
Jesse_Eichar: then back in the other thread the viewportPane draws a blank image to the SWT Image
emily_g: this sounds reasonable to me
emily_g: so do I need to buffer the image in the compositerenderer ?
Jesse_Eichar: I think it is a synchronization issue.
Jesse_Eichar: buffering the image in compositeRenderer won't do it because the buffer still could get cleared
Jesse_Eichar: I can think of 2 ideas.
gdavis_: maybe lock the image for read/write synching between threads?
gdavis_: I did something similar with the tiles emily
Jesse_Eichar: 1. make a copy and pass it in the refresh request.. This sounds expensive to me because it is making lots of copies of the images
Jesse_Eichar: It is more difficult than that unfortunately graham
gdavis_: oh? ok
Jesse_Eichar: only slightly though
Jesse_Eichar: it is because the request is an event that is placed on a event queue.
Jesse_Eichar: So you could be blocking the composite renderer until the ViewportPane has time to update it
Jesse_Eichar: in which case you could get a severe performance hit
Jesse_Eichar: My second idea is to use the "loan" pattern
gdavis_: is the image actually empty/null in this case, or is it a proper image that happens to be white?
Jesse_Eichar: #2
gdavis_: ah, that does make it trickier ya
emily_g: I don't know graham
gdavis_: because a proper image could happen to be white too so you couldnt test if it was "empty"
Jesse_Eichar: use the Collections strategy for detecting a synchronous update
***moovida has to run. Thanks for the chat...
Jesse_Eichar: the idea is topass a number or a timestamp to the ViewportPane in the request
Jesse_Eichar: and when the ViewportPane checks the image it compares the timestamp to verify that it is the right one
Jesse_Eichar: if not then it knows that the image has been update and it waits for the new request
emily_g: doesn't that have the potential of never drawing anything on the screen?
Jesse_Eichar: if the CompositeRenderer update the image it should always make a request after the update.
emily_g: by the time it gets the image the number could have been updated and nothing is drawn; this repeats itself?
Jesse_Eichar: true enough
emily_g: this is probably unlikely though
Jesse_Eichar: very unlikely since the viewport model should be much faster.
Jesse_Eichar: but you probably do need to make a check for that
emily_g: can you point me to where the request is made from the CompositeRenderer to the viewportPane?
Jesse_Eichar: so maybe an opposite direction communication.
gdavis_: jesse, before you go, I sent you a quick question in a PM
Jesse_Eichar: Did that last comment make sense emily?
Jesse_Eichar: maybe everytime the image is accessed the timestamp on the image is changes so both directions can validate that the image is being used in a responsible manner.
emily_g: thinking
Jesse_Eichar: I am just brainstorming you have to make it work so do what you think is apropriate
Jesse_Eichar: Sorry I have to run now
Jesse_Eichar: Its late
emily_g: thats fine jesse - thanks for you help
emily_g: as least I have an idea of what the problem might be
Jesse_Eichar: ok ciao
mauricio: bye everyone
jgarnett: thanks
jgarnett: I suppose I better post the logs...
jgarnett: ... and try and catch up with what emily_g and Jesse were up to
jgarnett: silli and mauricio - I added everything mentioned on email
jgarnett: to Jira
jgarnett: and made this page here
jgarnett: http://udig.refractions.net/confluence/display/HACK/Home
jgarnett: have a list of everything you consider important.
mauricio: ok good
jgarnett: the list is based on "fix for UDIG 1.2-M0"
jgarnett: so if you see anything in that list that you do not *need* for capetown
jgarnett: please mark is as 'fix for' something later ...
No comments:
Post a Comment