SS,
I still think we should have the core and each module have it's own
trunk, branches and tags, that way each one can have it's own releases.
Paul
Sunburned Surveyor wrote:
> I think I have completed the migration to Subversion. Please check it
> out when you get a chance and let me know if
I think I have completed the migration to Subversion. Please check it
out when you get a chance and let me know if you see something wrong.
You will find the main sport for development commits in /trunk/core.
There is also a spot for plug-in development in /trunk/plug-ins.
The stable branch for
Sascha,
Check my last message on the e-mail to answer your question.
SS
On 6/18/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> SS,
>
> I had a brief look at the ViewVC front end of the the subversion
> repository and now it looks pretty good. Have you started
> the conversion process again
no.. i guess i am the only one who knows the features transfered (at
least until michael started :)
i only did the online doc at the wiki and the cvs doc.. thats why i
always was looking for somebdody to make a user-doc
stefan
Larry Becker schrieb:
> I guess OpenJump has support for this now t
Sascha,
I replaced the ThreadQueue.Listener with the following code:
panel.getRenderingManager().getDefaultRendererThreadQueue().add(
new Runnable() {
public void run() {
try {
flash(geometries, panel);
SS,
I had a brief look at the ViewVC front end of the the subversion
repository and now it looks pretty good. Have you started
the conversion process again?
- Sascha
Sascha L. Teichmann schrieb:
> SS,
>
>> [...]
>> That is a good thing. It means that we don't have to mess with
>> creating a new
I guess OpenJump has support for this now too. Am I the only one who
has trouble keeping up with the OpenJump feature set?
Larry
On 6/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> I think deeJUMP has SLD support:
>
> "Output as SLD: users can change the styles with deeJUMP and let a
> plug-in
I think deeJUMP has SLD support:
"Output as SLD: users can change the styles with deeJUMP and let a
plug-in to generate an OGC-conform style"
Larry
On 6/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> Hei,
>
> to my knowledge sld is "styled vector descriptor" it preserves the style
> of you
oh man.. :oI
i did mean:
"styled layer descriptor"
Stefan Steiniger schrieb:
> Hei,
>
> to my knowledge sld is "styled vector descriptor" it preserves the style
> of your layer as it currently is.
> I think UMN Map server and other wfs/wms can handle this. As far as i
> understand it is simp
ok... on more comment:
i think the replace value tool for tables is also in OJ 1.2 B and not
only in pirol/sigle (i transfered it a while ago). but i really don't
get what he whishes for an improvement and what he wants with postgis
featurerequests
stefan
Stefan Steiniger schrieb:
> below som
Sascha,
> Don't you have the same effects with the original one?
I begin to see... I can reproduce flash problems easily in JUMP
and OpenJump, but not in SkyJUMP. That explains why we are both
surprised. I have no idea why there is a difference, but I will
investigate further.
regards,
La
Hei,
to my knowledge sld is "styled vector descriptor" it preserves the style
of your layer as it currently is.
I think UMN Map server and other wfs/wms can handle this. As far as i
understand it is simply a file that contains some layout/style
specifications that enables to let a person to see
Larry,
_exactly_ this the thread lottery we are playing with the
assumption that no running threads means there no more rendering jobs!
I get the same irritating behavior with the original ThreadQueue.
I put an System.err.println("flash!") into the listener of
the zoom plug-in. Sometimes it gets
below some text which i found on the wiki in the wrong place (in
Experiences developing with Jump .. or so)
I post it for the record and as a reminder to see what pirol has changed
on their postgis access
stefan
---
I am impressed by the performance of the vector GIS - JUM
Sascha,
Thanks for your patience. I like the idea of preserving the
original behavior, however this version doesn't seem to flash
consistently. Sometimes it doesn't flash, sometimes it does.
regards,
Larry
On 6/18/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Larry,
>
> there is prob
Larry,
there is probably somebody out there (younger than us)
how says that 400ms feels slow too.
I've thought a bit about the compromise and came to the
conclusion that we don't need a make a compromise here.
We have simply to restore the behavior of the
original TheadQueue. The original one fi
Sascha,
I tried one second, and it feels slow. When I am arrowing through a
selection of records in View/Edit Attributes it makes me wait for the
flash before I move on. Really, this is becoming an issue of
compromising the interactivity of the application to achieve some
theoretical benefit
17 matches
Mail list logo
