[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] questions about uDig 1.0
|
Emilio Mayorga wrote:
Thank you. It was a very easy, smooth installation (I was afraid I'd
have to install a couple of components separately). I spent an hour or
two playing with it. I'd be happy to provide feedback now and in the
future, but I suspect this list is not the best venue. Let me know how
I can help.
Actually any venue is pretty good - communication is the important bit.
- For actual bugs and errors - the Jira bug tracker is the way to go.
- For things like websites being down and so on the email list is very good.
- For new ideas, questions on how things are supposed to work, or
suggestions it would be nice to talk about them on email, and then make
some Jira issues when we have enough community input.
Glad you liked the install process.
While I ran into a ton of error messages and things that didn't
respond properly, the application never, ever crashed!
That is good about the non crashing part, I assume you were running the
release candidate? The release candidate is missing the printing
subsystem right now which may account for some of your errors.
Actually what I am most interested in is this - were you able to look at
your data? (I had to run around and add prj files to all my shapefiles
to get them on screen).
For reference I test on a Athalon 1.7, during our testing on Friday
the uDig process was using 150 megs of ram. The only time I have
found uDig to be slow was a old laptop with 16 megs of shared video
ram, switching to only Web Map Server layers fixed this the
performance problem.
Thanks. I shouldn't have used such formal language. I just want to
hear opinions about how it might work with less than stellar hardware.
BTW, I tested it on a Pentium III, about 1GHz, 512MB RAM, Win2000,
with other software running. It never felt slow, it simply became
buggier and less functional over time.
Well there is some good and bad news in that, but I appriacte the
platform information. And should start a wiki page to capture this
information. This is one of the things that open source software does
best - expose a codebase to a wide varity of platforms.
- I understand you'll be delivering a French localization. Is there
any talk of a Spanish one??
Actually there has been some interest, we are going to focus on
internationalization in March. Being an open source project we
welcome collaboration.
Great! I've never done internationalizations. IF we decide to go with
uDig, I'll discuss this with my partners. I suspect the donors (a
foreign aid agency) won't fund it directly, but I can bring it up to
GIS groups in Nicaragua.
Note that GeoServer also supports internationalization, and I think
there is already a spanish translation available. What the work consists
of is copying around 20 files that look like this:
search.label=Search
search.tooltip=Search for Spatial information
search.icon=etool16/search_co.gif
...
And providing the spanish translations on the right hand side. You can
also replace icons and splash screens as required (and indeed you may
want to do this if you set up your own udig based application).
- Are there plans to allow customization/scripting via languages
more accessible than Java? Say, Python.
There has been talk of this, the use of the Groovy language is one of
the best features of JUMP. My focus has been on making a strong,
clear object model. This would support the use of the whichever
scripting language to community would care to implement. (I know If
I get some volunteer time I would work with Groovy myself, perhaps
with a JUMP facade to allow simple scripts to inter operate).
I'd never heard of Groovy, but it sounds intriguing. Glad to hear the
team is thinking about this issue.
Groovy is an attempt at a agile language for the Java virtual machine
(like Ruby or Python). Their are many things that go into an agile
language the most interesting to me are: Object Oriented scripting
language, per instance methods, and closures (like good old lisp). The
idea with all of these is to let the programmer do what is needed, at
runtime if need be.
Cheers,
Jody
