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 simple
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 and
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
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
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
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 someone
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 of
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
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 simply
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
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
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
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
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 managed
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
JUMP
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 pages,
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
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:
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
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 can
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
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
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.
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 mean by
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's
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 the
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 Organization
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
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
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
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
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
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
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
===
*
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
This
46 matches
Mail list logo
