go ahead and commit! :o)
stefan
Michaël Michaud schrieb:
> Hi,
>
> Sorry to come back with these database access suggestions.
> I'd like to commit the changes proposed here after as I need it to
> access my postgis database and I'd rather keep my local version of
> OpenJUMP synchronized with t
Hi together,
I run a little script [1] against the source of OpenJUMP
to find out the improper use of 'import' statements.
Here's the result:
'*' import(s): 507
Star imports are name space polluters and should be better
written as a list of explicit imports. Star imports are
often used for
i have no concern.
But I have to add, that I left the imports as they have been in the Jump
cvs, to avoid to much confusion when i do updates/sync with the original
Jump by Vividsolutions (using the eclipse diff tool). But as they don't
develop further since 5 months..
stefan
Sascha L. Teichm
I would suggest to remove the duplicates and the needless ones.
The unfolding of the star imports can be done later.
I'm willing to do this.
If you do the next JUMP/OJ merge rerun the script to find
out which new defects are introduced.
- Sascha
Stefan Steiniger schrieb:
> i have no concern.
>
>
Hi,
I did not do much comparisons between jump versions but identified
several bottlenecks in zoombar code and just committed an optimized
version :
1 - I prevent the renderer to display invisible layers as wireframes
during mouse dragging
2 - I used Larry's coordinate's decimator to render fea
Memory release : again :-(
Another bug with the memory-release problem appears when you remove a
layer from the LayerNamePanel while this layer as an open table view :
the view stay opened, and the memory is not released, even after the
table view is closed.
Michael
> I tested your fix and fo
