The contentIDToLowRendererFactoryMap contains renderers that paint below the
layers e.g. gridlines.
The contentIDToHighRendererFactoryMap contains renderers that pain above the
layers e.g. scale bar, selection handles, etc.
This code just grabs the renderer from one collection or the other and
r
I was able to look at the source code for the
RenderingManager.createRenderer() method today at lunch. I found the
answer to the earlier question, and inadvertently or accidentally
answered another question I had about JUMP's rendering system. I'm
posting my discovery for others benefits, and will
Ok.. thats a bit heavy.
So we should try to make an external plugin. But maybe a few other
people have a different opinion.
stefan
Ugo Taddei schrieb:
> Hi Stefan,
>
> I think he meant having it as a plugin. If you opt for a thin core, then
> you can rule out the WFS. It depends on deegree (wei
Hi,
I understood Jukka's request the same way as Ugo : an external plugin
compatible with all jump versions.
Having a thin core and many plugins is also my preferred option.
I don't know if the plugin framework is ready to manage features as jump
version compatibility and plugin dependencies, bu
eyed and frozen.
Only four minutes left diGriz. Put on the suit. Ill fix the beard.
for action in this civilized universe. The search will be a simple one
get my thoughts together. Im going to take a walk back down the wall,
Come back here, you!
we had received at the archway had been too spontane
I've updated the notes about OpenJUMP's rendering system at the JPP Wiki.
http://thejumppilotproject.pbwiki.com/Notes-On-OpenJUMPs-Rendering-System
I've got some more notes on my home computer. When I have time I'll
try to combine these with the notes on the Wiki to come up with a more
comprehens
Hi Stefan,
I think he meant having it as a plugin. If you opt for a thin core, then
you can rule out the WFS. It depends on deegree (weighing in 3,5 MB) plus
a few other libs (mainly for XML parsing and HTTP stuff).
Cheers,
Ugo
> Hei Jukka,
>
> so if i understand correctly you would like to have
Thanks Stefan. I'm going to take another look at the code today over
lunch to see if I can figure it out.
The Sunburned Surveyor
On 12/13/06, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> i guess the only ones who knows why they did that are Jon and Martin
>
> stefan
>
> Sunburned Surveyor schrie
Hei Jukka,
so if i understand correctly you would like to have the WFS function in OJ?
@all: anybody against this idea (opting for a thin core ;)
stefan
Rahkonen Jukka schrieb:
> Hi,
>
> I do know there is deeJUMP with WFS support and I am even lucky enough
> to have an old deeJUMP supporting
i guess the only ones who knows why they did that are Jon and Martin
stefan
Sunburned Surveyor schrieb:
> I working on the patch to add pluggable renderers to Vivid's JUMP,
> based on code that is already in OpenJUMP. Most of my work revolves
> around the createRenderer() method of the RenderingM
Hi,
I do know there is deeJUMP with WFS support and I am even lucky enough
to have an old deeJUMP supporting WFS version 1.0. I have also read
that OpenJUMP the Merge has WFS support. Could it be possible to have
WFS as a plugin so it could be used with any JUMP variety, or is there
something fu
11 matches
Mail list logo
