xmlvm-users

[xmlvm-users] NSBundle paths

[Panayotis K. <pan...@pa...>]

In the file 
src/xmlvm2objc/compat-lib/java/org/xmlvm/iphone/NSBundle.java
I've seen that there is one more hack, in order to support Android.
I am talking about the extra code of the method

public String bundlePath()

which makes some tricks in oder to make some things visible to the android emulator.

I believe this should not be like this. I think that any (strange) resolve of Android paths should be done in the Android compatibility layer.
I'd provide a patch, but right now I am trying to sync my repository with XMLVM's (it is some time…) and I don't want to do any changes right now, or else it will be a moving target.

Re: [xmlvm-users] NSBundle paths

[Wolfgang K. <wol...@xm...>]

Panayotis,

without having a look into NSBundle.java I suggest not changing the
implementation right now. We are currently improving the Android
compatibility layer to support Android's resolution of alternative
resources (the resource folders with trailing modifiers like large, hdpi
etc in their names). I agree with you that all that strange Android
stuff should be removed from NSBundle.java. After adding support for
alternative resources in the Android compatibility layer we might get
rid of that stuff anyway. So I propose to postpone the changes to
NSBundle.java and see what is left to do when we are done with the
resource resolution implementation. Does that make sense to you?

-- Wolfgang


Panayotis Katsaloulis wrote:
> In the file 
> src/xmlvm2objc/compat-lib/java/org/xmlvm/iphone/NSBundle.java
> I've seen that there is one more hack, in order to support Android.
> I am talking about the extra code of the method
>
> public String bundlePath()
>
> which makes some tricks in oder to make some things visible to the android emulator.
>
> I believe this should not be like this. I think that any (strange) resolve of Android paths should be done in the Android compatibility layer.
> I'd provide a patch, but right now I am trying to sync my repository with XMLVM's (it is some time…) and I don't want to do any changes right now, or else it will be a moving target.
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>   

Re: [xmlvm-users] NSBundle paths

[Panayotis K. <pan...@pa...>]

On 14 Σεπ 2010, at 9:49 μ.μ., Wolfgang Korn wrote:

> Panayotis,
> 
> without having a look into NSBundle.java I suggest not changing the
> implementation right now. We are currently improving the Android
> compatibility layer to support Android's resolution of alternative
> resources (the resource folders with trailing modifiers like large, hdpi
> etc in their names). I agree with you that all that strange Android
> stuff should be removed from NSBundle.java. After adding support for
> alternative resources in the Android compatibility layer we might get
> rid of that stuff anyway. So I propose to postpone the changes to
> NSBundle.java and see what is left to do when we are done with the
> resource resolution implementation. Does that make sense to you?


Yes I agree.
The problem also right now is that I have this huge patch pending, and I am trying to make it work with the current version of XMLVM.
It sounds again that a more liberal  repository is required ;) like mercurial, so that I could see the core developer's current changes (which will not affect the "stable" branch) and you could see mine :)

In any case, I am more than happy with your proposal :)