[Gvsig_english] Call for Mac Community contributors.

[Cèsar Ordiñana]

El 26/05/11 11:00, Jordi Torres escribió:
> Hi Jorge, Joaquin, and Manuel:
>
>     We've been discussing here Manuel, Joaquín and me and well, we think
>     your approach is not the best way to improve the gvSIG code. When one
>     needs to do changes or improvements on the code branching should
>     be the
>     last resource as you are taking the decision of work aside the rest of
>     the developments, aren't you?
>
>     IMHO it is more reasonable to try to improve the current code for
>     everyone and maybe do some work to plug your work on a separate
>     extension if it's only for the Mac distro.
>
>
> 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.

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.

Just for curiosity, why is needed that approach in MacOSX? Is there any 
problems in the gvSIG JNI libraries?

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.

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.

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.

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.

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.

Regards,

-- 
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20110526/028d4286/attachment.htm