html is my favourit as well
(and i think more or less we already support html..? -- see the hello
world plugin)
stefan
Larry Becker schrieb:
> It seems like to me that for most kinds of simple help that it would
> be better to use html and store the documents in the jar. Java can
> display simp
Yep.. because we have people like Larry, Paul, Michael and Geoff that
seem to take care fulltime around Jumps :)
thank you guys.. and i hope some one pays it back, not only with words
stefan
Martin Davis schrieb:
> Great work!
>
> What I like about this list is that you can throw out an idea a
Hei,
i just got some email by somebody who worked on an italien translation.
But (as i have not seen it yet) i guess the last new developments are
missing. I will come back to this.
stefan
-
This SF.net email is sponsored
In Windows simply using:
start anyfile.pdf
will open the associated viewer for PDF files.
I have no idea for Linux and MacOS.
Maybe Java itself have something to abstract OS differencies...???
Bye
Paolo Rizzi
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTEC
Adrian,
true, true .. well told story rhat ... thanks alot.
just to make a point:
if bursa wolf parameters are missing, the parameters for an accurate
ellipsoid shift are missing, so results will be (very?) inaccurate?
kind regards ede
--
> Hey,
>
> In the "for dummies" collection, "geodesy for
Great dramatization Adrian!!!
>From a more practical point of view, my experience with Bursa-Wolf
was mostly for PostGIS. Here we use the EPSG:3003 system for
Italy mainland and the spatial_ref_sys table of PostGIS doesn't have
the TOWGS parameter for EPSG:3003. This resulted in _very_ bad transfo
Edgar Soldin wrote:
>Adrian,
>
>true, true .. well told story rhat ... thanks alot.
>
>just to make a point:
>if bursa wolf parameters are missing, the parameters for an accurate
>ellipsoid shift are missing, so results will be (very?) inaccurate?
>
>
yes... usually in the dimension of 100m +
Hi Michaël,
Guessing a 64 bit OS is required to run Java64, so I checked out Vista
64 last night. Apparently I can get a copy just by asking, but from
what I hear on the net, there are practically no device drivers for it
yet, so it isn't too practical.
I suppose the situation on Linux might be
Hei Paul,
sorry for this very late response.
As far as I remember you got a couple of positive responses on the
openfile wizard. Michael agreed to adapt his drivers and probably only
the PostGIS driver needs to be checked by somebody else as Uwe has no time.
Therefore I would like to ask you if
Hi Stefan,
since I paln to work on Italian translation, I would
like to contact him to share the work
Peppe
--- Stefan Steiniger <[EMAIL PROTECTED]> ha scritto:
> Hei,
>
> i just got some email by somebody who worked on an
> italien translation.
> But (as i have not seen it yet) i guess the la
Peppe,
I have dowwnloaded the zip file you sent, but I haven't looked at it
yet. I will try to do so today.
SS
On 9/18/07, Giuseppe Aruta <[EMAIL PROTECTED]> wrote:
> Thanks SS,
> I was alittle afraid to work in a foreign language
> (for me) as English.
> I also saw my mistakes but I wanted some
Hi Peppe,
HTML is no harder than PDF and works much the same. Just work as
normal and choose Save As (HTML) from OpenOffice Writer (or Word).
regards,
Larry
On 9/18/07, Giuseppe Aruta <[EMAIL PROTECTED]> wrote:
> Hi,
> the idea of using PDF was strictly connected to
> "internationalization"
Another (more complex) option is to write the documents in DockBook
(XML) and then you can use stylesheets and Apache FOP to generate HTML
and PDF documents from them.
Unfortunately it's quite a bit of work to get the stylesheets setup in
the first place.
Paul
Sunburned Surveyor wrote:
> I perso
Does anyone have a problem with my adding a method to the DialogUtil
class? This method would accept a JListBox and a reference to a
LayerManager as arguments. It would then set name of each Layer in the
LayerManager as the values in the JListBox.
If this method is not appropriate for the DialogUt
Hi,
the idea of using PDF was strictly connected to
"internationalization" of OpenJUM, since it is easier,
I think, to translate quickly any word/openwriter docs
in pdf. I have no idea how to work in html :-<.
Peppe
--- P.Rizzi Ag.Mobilità Ambiente
<[EMAIL PROTECTED]> ha scritto:
> In Windows si
Thanks SS,
I was alittle afraid to work in a foreign language
(for me) as English.
I also saw my mistakes but I wanted someone "more
Englished" to correct them.
Thank you for your job.
BTW Did you give a look to my proposal of
International OJ wiki pages?
Peppe
--- Sunburned Surveyor <[EMAIL PRO
Stefan,
I can start to integrate in the Open File changes, what I propose is
that I create a new branch under branches/paustin where I will checkin
my changes and then other can review this branch to make sure the
changes work. Then I can merge this branch into the trunk.
Paul
Stefan Steiniger w
I personally prefer PDF format over HTML, but I think this is a matter
of taste. The main reason for my preference of PDF is the exact
control I am allowed over layout and appearance.
I'll keep whatever code I write to open PDF "help" files local to my
plug-ins and out of the core. I will keep the
I must admit I'm a big fan of Scribus and Inkscape. I can easily
produce professional looking documentation with those two (2) tools,
and they are both open source. (They also both run on Linux!)
So this is probably use these two (2) programs to write my help docs
and then I will launch the PDF re
You are right Larry, the problem is that working with
HTML means to separate the original opendoc in
different pages, since "save to" HTML page saves to
only one big page, difficult to manage.
I have no idea how to split the opendoc and save it to
different HTML saving the links between them.
More
Hi Landon,
For building a bunch of different JUMP plugins I am using maven to
simplify the process. I've just managed to complete the final piece of
the puzzle which is to be able to create easily custom bundles of JUMP
with additional plugins.
I'll see if I can put some instructions together to
The only reservation I have is to note that this class exists only in OpenJump.
regards,
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Does anyone have a problem with my adding a method to the DialogUtil
> class? This method would accept a JListBox and a reference to a
> Layer
I'm interested in learning to use Maven and would definitely use the
instructions if you wrote them.
The Sunburned Surveyor
On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> Hi Landon,
>
> For building a bunch of different JUMP plugins I am using maven to
> simplify the process. I've just mana
True. The trick is recognizing the difference between reusing code
and creating dependencies.
Larry
On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> I think where ever possible we should start to use reusable Utility
> methods or UI components, there is a lot of local code and classes in
> J
Your right, Peppe. There is certainly a role for both formats and no
need to limit ourselves to only one.
regards,
Larry
On 9/18/07, Giuseppe Aruta <[EMAIL PROTECTED]> wrote:
> You are right Larry, the problem is that working with
> HTML means to separate the original opendoc in
> different page
Larry,
Would there be a solution that would work for SkyJUMP? I will be
putting together an surveyos_openjump_utilities JAR file, and I could
put a DialogUtil class in there if it is a better fit.
I'm just trying to keep duplication to a minimum.
The Sunburned Surveyor
On 9/18/07, Larry Becker
SS,
If you are already using the other methods in DialogUtil, then don't
worry about it, otherwise why not just keep the method local?
thanks,
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Larry,
>
> Would there be a solution that would work for SkyJUMP? I will be
> putting
I think where ever possible we should start to use reusable Utility
methods or UI components, there is a lot of local code and classes in
JUMP which do exactly the same thing.
The biggest case is a whole bunch of ActionListener classes which then
call say xxx_actionPerformed on the main class. If
Paul wrote: "I think where ever possible we should start to use reusable Utility
methods or UI components, there is a lot of local code and classes in
JUMP which do exactly the same thing."
This is my goal Paul. Thank you for putting it so concisely.
Larry wrote: "The trick is recognizing the dif
Landon,
Can you paste the implementation of the method?
Cheers,
Paul
Sunburned Surveyor wrote:
> Paul wrote: "I think where ever possible we should start to use reusable
> Utility
> methods or UI components, there is a lot of local code and classes in
> JUMP which do exactly the same thing."
>
> One way to enforce this would be to modularise open JUMP and enforce the
> dependencies.
I suppose this is doable by making OpenJUMP a separate plugin jar.
We do kind of need to formalize some guidelines on this. I just
created the SelectablePlugIn similar to the vividsolutions
EditablePlugin
In one of the other threads we have talked about the modularization of
code so I thought I'd start a thread on the topic.
To do this I think that we need to move to maven as the build system as
it can help with the multi module builds and cross module packaging.
We would need the following module
Agree totally,
In my environment I have the following dependency tree where you can
only access classes up the tree. So the Vivid JUMP should not depend on
Open JUMP, I just did a quick search and there are 21 matches to the
keyword openjump in the com.vivid packages. In these cases either the
ref
i write you back..
got the file now.. but it seems to be from March 2007.. so a couple of
strings are missing.
stefan
Giuseppe Aruta schrieb:
> Hi Stefan,
> since I paln to work on Italian translation, I would
> like to contact him to share the work
>
> Peppe
> --- Stefan Steiniger <[EMAIL PR
ok.. but some of the improvements need to be referenced in the original jump
a) menu functions that need to be initialized in JUMPConfiguration
b) the link to OpenJUMP configuation
c) functions that add something to existing dialogs (i imagine the style
dialogs)
stefan
Paul Austin schrieb:
> Ag
FWIW:
I don't think that there will be a strong need going forward to keep the
OJ codebase and the Vivid codebase rigorously separate. The momentum is
definitely with OJ now, and I wouldn't expect to see very much if any
further independent development to the Vivid codebase. So if
maintainin
sounds good to me :)
stefan
Paul Austin schrieb:
> Stefan,
>
> I can start to integrate in the Open File changes, what I propose is
> that I create a new branch under branches/paustin where I will checkin
> my changes and then other can review this branch to make sure the
> changes work. Then I
Or Alternatively we ditch the JUMPConfiguration with an Openjump
equivalent sub class.
Paul
Stefan Steiniger wrote:
> ok.. but some of the improvements need to be referenced in the original jump
>
> a) menu functions that need to be initialized in JUMPConfiguration
> b) the link to OpenJUMP conf
Martin,
Eventually I will see the need for further separation as we add
different reusable libraries under the openjump banner such as the
DataObject framework. By using maven with its dependency management we
can slowly add further modularization as it makes sense. There will also
ben reusable UI
Is there a standard copyright header for open jump, who owns the copyright?
Paul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mr
Paul,
This question does not have a simple answer. I'll do my best to
provide an explanation.
Vivid Solutions holds the copyright for all of the original JUMP
source code. Most code in OpenJUMP that is not part of the original
JUMP code is held by the respective programmers or their
organizations
Martin wrote: "It would be nice to add wheel-zooming to the current
Pan tool. This
would give a single tool to accomplish all view movement. And
right-drag would still be available for something else - or maybe it
should just be left for the context menu?"
I also agree. This is how AutoCAD works
> I would really like our default "navigation" behavior to work for each
> of the CursorTools. I think this means the mouse listeners need to be
> registered with the LayerViewPanel, and not with an individual plug-in
> like the pan tool. but maybe this is too complicated?
I'm not sure what you me
Why don't you just do:
argList.setListData(argManager.getLayers().toArray());
and skip the whole method.
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> I have attached my implementation of the setLayerNamesAsListData
> method. I was thinking about placing this method in Sigle
I had some trouble with this a few days ago, but it is probably
because I'm a doofus. I'll try it again.
The Sunburned Surveyor
On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> > I would really like our default "navigation" behavior to work for each
> > of the CursorTools. I think this means
That works for me Paul. I'm not going to push the copyright issue
until someone else feels that it is important.
The Sunburned Surveyor
On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> I'm going to use the following header for my new classes, if at some
> point JPP becomes an actual Organizat
I have attached my implementation of the setLayerNamesAsListData
method. I was thinking about placing this method in Sigle's DialogUtil
class.
Someone asked to see my implementation, and I didn't want to cloud up
the other thread, which has moved onto other topics.
The Sunburned Surveyor
P.S. -
Paul,
If you want to have a standard copyright holder maybe we could say
something like:
"Copyright held by Vivid Solutions and other contributors."
SS
On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> I copyright everything we write in our company's name (ISA). Since
> everything is GPL,
I copyright everything we write in our company's name (ISA). Since
everything is GPL, I think the important thing is for someone to claim
copyright, since only the copyright holder can relicense.
regards,
Larry
On 9/18/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> Is there a standard copyright he
I'm going to use the following header for my new classes, if at some
point JPP becomes an actual Organization then I'll be happy to use that
instead.
/* *
The Open Java Unified Mapping Platform (OpenJUMP) is an extensible
Yes, makes sense to me. Using package hierarchy definitely seems like
the way to document/enforce/promote the modularization strategy.
I can't comment on Maven's impact on this, but it seems to me like the
modularization is orthogonal to the use of Maven. Maven probably makes
it easier to bu
Larry,
Maybe I am totally missing something with my programming style. I will
try to explain my reasoning for wanting this in a separate method, and
then you can correct whatever bad programming habits that appear. :]
First of all, I really try to avoid chaining method calls like you
have done in
Paul wrote: "To do this I think that we need to move to maven as the
build system as it can help with the multi module builds and cross
module packaging."
I'm open to this as long as we keep it as simple as possible. :]
Paul wrote: "Are the dee jump and pirol plugins distributed as part of
the co
OK, then:
public static void setLayerNamesAsListData(LayerManager
argManager, JList argList) {
argList.setListData(argManager.getLayers().toArray());
}
I can cope with creating the utility method, just not the horrible
implementation.
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL
So we don't have an issue with my using a utility method. That is good.
What is horrible about my implementation? Can you please provide details?
I know I am using two (2) more lines of code than your implementation
would, but I tried to explain my reasons for this. I want to write
rookie-friendl
I assume you mean the revised version:
Collection layers = argManager.getLayers();
Object[] layersAsArray = layers.toArray();
argList.setListData(layersAsArray);
and not the original. Nothing wrong with that.
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> So we don't have an
OK. We are on the same page then. :]
Sorry for the long-winded e-mail.
SS
On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> I assume you mean the revised version:
>
> Collection layers = argManager.getLayers();
> Object[] layersAsArray = layers.toArray();
> argList.setListData(layersAsArray)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Everyone
This topic again?
If you don't mind me asking... what's the need to discuss copyrights
again?
Is there a **need** for it?
I, for once, agree with Landon on his last remark: neutral, 3rd party,
licensing ...
Shoot me for perhaps being a
Sunburned Surveyor wrote:
>
> Martin wrote: "It would still be worth having a well-defined strategy
> for what can
> depend on what. I would suggest a further partition within OJ itself:
>
> core non-UI components
> - core Workbench components
> -- plugins"
>
> This is a good idea. I believe thi
FWIW, and without wanting to get into a philosophical flame war - SS,
the coding principles that you've listed are pretty right in line with
the way I code as well.
The good news is that with Java and modern IDE's, code understandability
is much less dependent on these details than it was in th
Hei,..
took me a long time to come to this email.
It is longer than intended .. and i actually don't want to start the
discussion on this now, as some people are still in holidays and i am
busy with other things as well.
1) my comments on the release strategy
===
* first
my 2 cents:
do what you want, but the GPL notice is necessary.
I personally add my own name for the copyright... because one never
knows if one can need the code for something else.
stefan
Pedro Doria Meunier schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Everyone
>
> T
62 matches
Mail list logo
