<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
El 26/05/11 11:00, Jordi Torres escribió:
<blockquote
cite="mid:BANLkTim+Lnz37Lis+t8WSK6Z=zQyjWXzgw@mail.gmail.com"
type="cite">Hi Jorge, Joaquin, and Manuel: <br>
<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">We've been discussing here Manuel, Joaquín
and me and well, we think<br>
your approach is not the best way to improve the gvSIG code.
When one<br>
needs to do changes or improvements on the code branching
should be the<br>
last resource as you are taking the decision of work aside the
rest of<br>
the developments, aren't you?<br>
<br>
IMHO it is more reasonable to try to improve the current code
for<br>
everyone and maybe do some work to plug your work on a
separate<br>
extension if it's only for the Mac distro.<br>
<br>
</blockquote>
<div><br>
There are points where I cannot see a way, for example when
loading ecw layers. At this moment we are using Gdal plugin to
load this layers. gvSIG for linux and win uses a shared
library present in the code. How would you face this problem?
In the other side the ui changes could be sensible in other
platforms, beacuse it could imply some dialog type changes. I
am not supporting to branch the whole gvSIG, only a few
projects, where the code is sensible to have impact over the
other distributions. <br>
</div>
</div>
</blockquote>
<br>
About the use of gdal to load ecw, mrsids and others, it would be
great to use it instead of the ecw or mrsid libraries directly for
all platforms, it would relieve a bit of our maintenance work. But
AFAIK there are performance and writing ability problems with that
option, so it seems we could not replace our current ecw, mrsid,
etc. providers.<br>
<br>
Just for curiosity, why is needed that approach in MacOSX? Is there
any problems in the gvSIG JNI libraries?<br>
<br>
If that option is needed and you need your own branch, you could use
the same gvsig-desktop repository. I think that way it will be
easier for you to merge changes between the trunk and your branch,
as you would be making changes on the same gvsig projects.<br>
<br>
For gvSIG 2.0, we will need more testing but I think we currently
support that one format might be supported by many different
providers, so the user is allowed to select which one to use. For
example, in linux when the user opens an ecw file, he could select
if he wants to open it through gdal or the current direct provider.
For mac, if the direct one does not work, it would not be included
in the installation.<br>
<br>
That way we could have both approaches in the main branch. Well, in
that case not even in the gvsig-desktop svn repo, as from gvsig 2.0
onwards, the raster support has its own OSOR project and repository
where you could work also.<br>
<br>
And the UI changes, I think the main problem is related to panels
which use absolute positioning, instead of relative positioning
using any of the available standard swing layouts. If those panels
are updated, I think that would solve another problem we have when
the Look & Feel is changed, as I think it is the same problem
you might have in macOSX. If we were lucky and that would be the
case, we could use the new Nimbus L&F, much more interesting
IMHO.<br>
<br>
And if that is not the case, and branching is the only way to go, as
I said you could use the gvsig-desktop project repository also, I
think it will make life easier for you.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (<a class="moz-txt-link-freetext" href="http://www.disid.com">http://www.disid.com</a>)
</pre>
</body>
</html>