- what is up
- code sprint prep
- nogenerics must die
- swing widgets Q&A
jgarnett: jdolive did you get the gtbot code?
groldan n=gabriel@217.130.79.209 entered the room.
jgarnett: or are we on manual...
jdeolive: manual
jdeolive: never got hte bot
jgarnett: so we have ...
jgarnett: 0) what is up
jgarnett: 1) code sprint prep
jgarnett: 2) nogenerics must die
jgarnett: (anyone else ...)
Eclesia: questions about swing widget? if anyone have some
jgarnett: the way we do it is just "Grab an agenda item" .... so ....
jgarnett: 4) swing widgets Q&A
jgarnett: jdeolive the FM work; is that going to be covered by code sprint prep ? Or are you good ...
jdeolive: sure
aaime n=aaime@host227-95-dynamic.50-82-r.retail.telecomitalia.it entered the room.
jgarnett has changed the topic to: 0) what is up 1) code sprint prep 2) nogenerics must die 4) swing widgets Q&A
jgarnett: I need to change the proposal name so we can vote on the GeometryBuilder api addition.
CIA-9: jeichar 1.1.x * r27016 udig/udig/plugins/ (13 files in 6 dirs): merged in refresh fix from branch
CIA-9: jeichar * r27017 udig/plugins/ (12 files in 6 dirs): merged in refresh fix from branch
jgarnett: 0) what is up
jgarnett: jody - foss4g prep
groldan: gabriel - udig fun with edit tool modes
jdeolive: justin - geapi feautre model
simboss n=chatzill@host236-221-dynamic.117-80-r.retail.telecomitalia.it entered the room.
jgarnett: hey simboss - what is up? literally ...
aaim1 n=aaime@host227-95-dynamic.50-82-r.retail.telecomitalia.it entered the room.
jgarnett: 1) code sprint prep
aaim1: aaime - foss4g and beta3 release
jgarnett: So thigns are starting to look up, I talked to cholmes and he is going to buy us pizza on the saturday.
jgarnett: We are taken care of on the friday as part of the conference.
simboss: hi guys
jgarnett: And I am inviting anyone interested to my place for a BBQ saturday evening ...
jgarnett: So food prep is done ....
jgarnett: Justin how about FM prep?
jdeolive: coming along
jdeolive: i have updated geoapi interfaces based on peoples feedback
jdeolive: so i thin kthe model itself is generally ready to go
jdeolive: now i am working on updating geotools trunk to get ready for the sprint
acuster: so the sprint is FM
acuster: ?
acuster: next time it should be something totally frivilous and fun
jgarnett: The sprint is FM, but it is the part where we update the geotools library internally not to use deprecated stuff. And also geoserver and udig at the same time.
jgarnett: http://wiki.osgeo.org/index.php/FOSS4G2007_CodeSprint
jgarnett: So justin we have a checklist of things we need for the sprint: it amounts to a good code example and a class diagram.
jgarnett: So far we only have four developers listed ... are more people expecting to attend?
jdeolive: yup, on my list, 1. update trunk, 2. make sure examples are good, 3. class diagram
jgarnett: sweet
jgarnett: There will be other groups of developers around; but I would like to make sure we have as many hands as possible for this code sprint.
jgarnett: Since we will all be using svn this can be a constant breakout IRC as well.
jgarnett: okay so the prep is mostly you justin; please tag us all in for help as often as needed.
jgarnett: 2) nogenerics must die
jgarnett: Jesse_Eichar77 this one is yours from email.
Jesse_Eichar77: ok
simboss: (quick question when is the gt codesprint going to be held?)
Jesse_Eichar77: basically I've been trying to get feature editing working with geotools 2.4+
Jesse_Eichar77: .. go ahead
simboss: (so that I can give my fundamental
apport!)jgarnett: http://www.foss4g2007.org/code_sprint/
jgarnett: (Friday September 28th ... we are going to keep the love going for Saturday and Sundary as well. Refractions is providing space for the Saturday and TOPP is providing pizza)
ticheler n=ticheler@d83-181-227-95.cust.tele2.it entered the room.
simboss: (great, I am in for friday, not sure about saturdady, checking...)
Jesse_Eichar77: back to me?
aaim1: sure
Jesse_Eichar77: ok so gettting editing working
Jesse_Eichar77: I encountered an error that confused the heck out of me
Jesse_Eichar77: Essentially I had an featureId Object
Jesse_Eichar77: and I called getID() on it.
Jesse_Eichar77: However it threw an exception
Jesse_Eichar77: something like a AbstractMethodException I think
Jesse_Eichar77: I looked at my jars and saw that the jar had the method implemented.
Jesse_Eichar77: There were no compile errors
Jesse_Eichar77: so Jody came up with the idea that because uDig uses the generic version of GeoAPI
Jesse_Eichar77: uDig couldn't identify the correct method in the geotools implementation
Jesse_Eichar77: ....
Jesse_Eichar77: that make sense?
jgarnett: It does; at the bytecode level the method is marked differently if it is implementing an interface.
jgarnett: two levels of indirection rather than just one.
jgarnett: Justin I belive you tried using the normal geoapi jar and found a compile error in referencing - can we have more details?
Jesse_Eichar77: so basically I have to move uDig to nogenerics or geotools moves to the generics jar for me to fix this issue
jgarnett: (some of the library uses the normal geoapi jar right now)
aaim1: 2.4.x cannot move to jdk 1.5.x
aaim1: (imho)
Jesse_Eichar77: I'm ok with that
aaime left the room (quit: Read error: 110 (Connection timed out)).
Jesse_Eichar77: I don't expect 2.4 to move to 1.5 my self
Jesse_Eichar77: not this late in the release cycle.
Jesse_Eichar77: but 2.5 should be ok yes?
aaim1: Yes, trunk is already using jdk 1.5
aaim1: you cannot compile it anymore with 1.4 afaik
Jesse_Eichar77: but not the geoapi generics jar.
Jesse_Eichar77: correct?
aaim1: I think I've seen both of them in the classpath but I'm not sure (which would be even worse)
jgarnett: They are both used by different modules.
Jesse_Eichar77: well I just wanted to let you know that I'm encountering this issue.
Jesse_Eichar77: so we probably want to address it soon
Jesse_Eichar77: because I won't be the only one before long.
jgarnett: jdeolive do we need to address this before the code sprint?
aaim1: I guess there is nothing against moving trunk to geoapi-generic... anyone?
jgarnett: I know of one compile error in referencing - but Justin has the details.
jgarnett: In general the normal geoapi jar is way nicer to work with.
jgarnett: One of the reasons we use it in uDig.
jdeolive: yeah, there are a few other errors besides feature model
jdeolive: but not that manu
jdeolive: many
jdeolive: so i am ok with moving trunk to geoapi with generics...
jgarnett: +1
jdeolive: although i have not looked too deeply into the issues in the other modules
jgarnett: it would make geotools easier to use w/ maven; right now I have to provide a bunch of <exclude> statements so I do not get conflicts on the geoapi jar.
aaim1: Ah, because that may potentially trigger a pile of compile errors, right?
aaim1: (I mean, switching to the geoapi with generics version)
jdeolive: yeah.. thats probably smarter
jdeolive: keep geoapi-generics, but exclude the feature model teh erasure
jdeolive: so its as andrea says, geoapi-withSomeGenerics
jgarnett: that sounds horrible.
jgarnett: however I think we are not going to make a decision here because we do not have enough specifics
***acuster doesn't understand at all.
jgarnett: (so we are all wondering how bad can it be)
aaim1: Is there anybody with enough time to try out a switch and see how big is the river that we must cross?
jdeolive: i just di
jdeolive: d
jdeolive: one sec, i will try to sum up teh rrors
jgarnett: I will try it out; if only so justin can stay focused on the FM
jdeolive: its tough to guage in main, since there is also all teh chagnes from teh feature model
jgarnett: I can try on a 2.4.x checkout and get a better impression.
jdeolive: one thing that pisses me off about generics
acuster: jgarnett, why is the non generic geoapi nicer to work with?
jgarnett: because it is more specific.
jgarnett: so often a geoapi interface will return getTelephones(): List
jdeolive: is that List<B> is not considered a type narrowing of Collection<A>
jgarnett: when it actually means getTelephones():List<Telephone>
jdeolive: when B is a subclass of A
jgarnett: jdeolive++ we fixed most of that for the metadata interfaces; but they do not plan a good fix until Java 7
jdeolive: actually wait a sec... that is what ? extends A is for
jgarnett: indeed.
***jdeolive wonders if they made a mistake adding generics to java
jgarnett: they made several; but mostly by only going halfway and letting the compiler do it
jgarnett: (rather then the VM)
jgarnett: type erasure is compile time safety only; not runtime safety.
jdeolive: anyways, i cant really guage the work to port the rest until i update the feature model
jgarnett: jdeolive I will send an email after trying the 2.4.x experiment.
jgarnett: 4) swing-widgets Q&A
jgarnett: Eclisia welcome to the team.
Eclesia: thx
Eclesia: i juts udpated the wiki page so everyone can test the demo
Eclesia: http://docs.codehaus.org/display/GEOTOOLS/widgets-swing-pending
Eclesia: (if anyone have questions)
jgarnett: First of all nice docs, and thanks for picking up this aspect of GeoTools - we have not had a volunteer on this front for years.
Eclesia: me objective is to have the basic swing component to make application
jgarnett: Although I have been helpful setting you up, Martin is going to be your major point of contact/feedback ...
jgarnett: ... I am sorry he is not here today.
jgarnett: I think someone already mentioned putting the demo code in demos/
jgarnett: are you cool with that?
acuster: Is there any reason to limit these widgets to j2me?
Eclesia: i use it to test my work and i change it often, so for now i would like to keep it in my module
acuster: the thought occurred to me just now
jgarnett: okay; when your module goes supported we would like to move these demos out to where people can use them.
acuster: looks cool
Eclesia: acuster : they won't work on j2me
Eclesia: i already made changes to make it work on 1.5 so on j2me...
aaim1: Eclesia, I'm getting the impression these widgets impose a look and feel, icon set, label alignments and such... is this true?
***acuster is using j2me only to mean the minimal environment of handhelds
Eclesia: yes, but icons can change
aaim1: Look and feel should be managed outside of the code
Eclesia: see here : http://docs.codehaus.org/display/GEOTOOLS/IconBundle
simboss: (impressive work man, congrats!)
aaim1: in a proper laf set of classes
aaim1: I mean, what if I have to integrate those components in an application that uses another laf
aaim1: with different fonts, alignements and so on?
Eclesia: no problems
Eclesia: i don't use any precise laf
aaim1: I see centered labels for titles, and borders around panels
Eclesia: just the header of the tree but that's all
aaim1: This should be part of a laf
Eclesia: ha... i see what you mean
aaim1: if these are set in code
Eclesia: yes they are
aaim1: when you put those components in an application that uses, says, the jgoodies laf
aaim1: they would look totally out of place
Eclesia: i should try and see
Eclesia: but i don't think it will be all messed up
Eclesia: i used netbeans matisse and the grouplayout to place everything
Eclesia: so i should be correct even if you use the jgoodies laf
aaim1: No, I did not mean the layout of the form
aaim1: Consider this one: http://docs.codehaus.org/download/attachments/10747962/ex_SLD1.jpg
aaim1: "Contour" is centered
acuster: aaim1, is there a good example widget to start from?
aaim1: but it should not under kmost laf
aaim1: Not that I know of acuster
simboss: I saw that eclsia
simboss: is using
simboss: swingfx
aaim1: most swing widgets are much more basic
simboss: am I right eclseia?
Eclesia: yes
simboss: than on their website
simboss: or docs
simboss: youo should find guidelines
simboss: but also
simboss: you can check the advanced
simboss: swing tutorials and guides from sun
jgarnett: two mins left for the meeting.
simboss: it is a rether boring task to use laf
simboss: but aaime is right
simboss: it is needed
simboss: to have "nice java" stamp
jgarnett: Eclisa for the data icons I would like to take those off to the rendering module
Eclesia: i will do what i can, with waht i know
jgarnett: (ie for the icon generated by a SLD for example)
aaim1: Another simple question
jgarnett: Please accept all this feedback as us being exicited
Eclesia: icons or glyph?
jgarnett: what do you find easier?
aaim1: is the example app going to become a separate project? I mean, a sort of udig made in swing?
Eclesia: aaim1 : lol, i had them in netbeans plateform to see
Eclesia: http://altersig.developpez.com/pages/snapshots/altersig_root4.jpg
groldan: geowidgets is dead?
Eclesia: not dead
aaim1: I guess, at least comatose
Eclesia: the work i'm doing (i hope) will be added in geowidget when it will be cleaned
groldan: cool
jgarnett: there is a little confusion here groldan
groldan: so are you in contact with the geowidgets developer at all?
jgarnett: the geowidgets developers are missing
jgarnett: the code is the same as it was in our geotools spike with some added translations.
jgarnett: so who knows?
groldan: I see
well, best of luck with this project Eclesia jgarnett: thanks for the Q&A
jgarnett: that is it for the meeting everyone; I will post the logs.
jgarnett: thanks!
Labels