Menu
▾
▴
xmlvm-users
|
From: Panayotis K. <pan...@pa...> - 2009-10-11 01:11:38
|
OK, now things start to get a bit dirty! The urge of this post was my effort to compile ibutton test (to do some real work at last :P ) This demo does not compile, since java.awt.Color is missing. So, although methods in java.lang.Math seem to be straight forward how to implement them ;-) , this gets a bit more complicated (since it doesn't exist at all). And it gets even more complicated if I had a look at "mixed" files, such as UITextView and UIButton. I have to admit it, I am totally lost :) UITextField is pretty clear what it does, no surprises there. What is on the java-side is also on the obj-c side. UIButton though is completely out of sync. Except the static method which created the UIButton (which makes sense) and setTitle forState, all other methods are missing! Are missing methods actually methods *not* really allowed to be executed in the obj-c environment (e.g. for emulation purposes?). Is for example "setPressedBackgroundColor(Color)" one of them? At the end of the day, is org_xmlvm_iphone_UIButton actually a UIButton? Let's go back to the original problem: UILabel.setBackgroundColor wants a Color argument. Is this on purpose? Isn't there a confusion whether UIColor or Color should be used? Can this be solved? What exactly should I do to implement the missing link? And a question out of curiosity: is java.lang.String a NSMutableString after all? Too many questions, I know, but I's all new (and exciting) for me… and I want to help :) |
|
From: Wolfgang K. <wol...@xm...> - 2009-10-11 07:06:06
|
The only features a UIButton supports right now is creation, setting its title and to register an event handler. Especially all the color stuff you mentioned is currently not supported. What you saw in the Java version of UIButton (these methods based on java.awt.Color) are only used inside our Java emulator to create a UIAlertView with properly colored buttons. This Java implementation should be fixed as soon as we support color operations based in UIColor. And thanks for mentioning the UIButtonTest. Since this uses the java.awt.Color based methods it cannot be cross-compiled. I think we should remove that from the repository to avoid confusion. Coming to the String question. I lately noticed that the java_lang_String implementation is based on NSMutableString. This should be fixed since in Java strings are immutable. That's one thing I have on my list - but not with highest priority. -- Wolfgang Panayotis Katsaloulis wrote: > OK, now things start to get a bit dirty! > > The urge of this post was my effort to compile ibutton test (to do > some real work at last :P ) This demo does not compile, since > java.awt.Color is missing. > So, although methods in java.lang.Math seem to be straight forward how > to implement them ;-) , this gets a bit more complicated (since it > doesn't exist at all). > And it gets even more complicated if I had a look at "mixed" files, > such as UITextView and UIButton. > > I have to admit it, I am totally lost :) > > UITextField is pretty clear what it does, no surprises there. What is > on the java-side is also on the obj-c side. > > UIButton though is completely out of sync. Except the static method > which created the UIButton (which makes sense) and setTitle forState, > all other methods are missing! > Are missing methods actually methods *not* really allowed to be > executed in the obj-c environment (e.g. for emulation purposes?). Is > for example "setPressedBackgroundColor(Color)" one of them? > At the end of the day, is org_xmlvm_iphone_UIButton actually a UIButton? > > Let's go back to the original problem: > UILabel.setBackgroundColor wants a Color argument. Is this on purpose? > Isn't there a confusion whether UIColor or Color should be used? Can > this be solved? > What exactly should I do to implement the missing link? > > And a question out of curiosity: is java.lang.String a NSMutableString > after all? > > Too many questions, I know, but I's all new (and exciting) for me… and > I want to help :) > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Panayotis K. <pan...@pa...> - 2009-10-11 09:55:07
Attachments:
uiswitch.patch
|
On 11 Οκτ 2009, at 10:05 π.μ., Wolfgang Korn wrote: > The only features a UIButton supports right now is creation, setting > its > title and to register an event handler. Especially all the color stuff > you mentioned is currently not supported. What you saw in the Java > version of UIButton (these methods based on java.awt.Color) are only > used inside our Java emulator to create a UIAlertView with properly > colored buttons. This Java implementation should be fixed as soon as > we > support color operations based in UIColor. And thanks for mentioning > the > UIButtonTest. Since this uses the java.awt.Color based methods it > cannot > be cross-compiled. I think we should remove that from the repository > to > avoid confusion. > > Coming to the String question. I lately noticed that the > java_lang_String implementation is based on NSMutableString. This > should > be fixed since in Java strings are immutable. That's one thing I > have on > my list - but not with highest priority. > So, for example I found that the UIControlEventValueChanged is not understood in the simulator, while it is perfectly understood in the native application. In order to implement things like that in the emulator, is something like this patch appropriate? it still has some issues but I just want to understand the main idea. In order to catch more than one of these events, should I double the request like here, or I can do something like ( UIControlEventTouchUpInside | UIControlEventValueChanged ) |
|
From: Wolfgang K. <wol...@xm...> - 2009-10-11 17:37:40
|
The patch you sent makes sense to me. Its pretty much the same as it is implemented in UIButton. To catch more than one event type with the same target it is possible to provide the ORed values of the corresponding UIControlEventValues. The iPhone SDK reference says: For example, you could request a certain action message be sent to a certain target when a finger touches down in a control or is dragged into it (|UIControlEventTouchDown <http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIControl_Class/Reference/Reference.html#//apple_ref/c/econst/UIControlEventTouchDown>| | |UIControlEventTouchDragEnter <http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIControl_Class/Reference/Reference.html#//apple_ref/c/econst/UIControlEventTouchDragEnter>|). -- Wolfgang Panayotis Katsaloulis wrote: > > On 11 Οκτ 2009, at 10:05 π.μ., Wolfgang Korn wrote: > >> The only features a UIButton supports right now is creation, setting its >> title and to register an event handler. Especially all the color stuff >> you mentioned is currently not supported. What you saw in the Java >> version of UIButton (these methods based on java.awt.Color) are only >> used inside our Java emulator to create a UIAlertView with properly >> colored buttons. This Java implementation should be fixed as soon as we >> support color operations based in UIColor. And thanks for mentioning the >> UIButtonTest. Since this uses the java.awt.Color based methods it cannot >> be cross-compiled. I think we should remove that from the repository to >> avoid confusion. >> >> Coming to the String question. I lately noticed that the >> java_lang_String implementation is based on NSMutableString. This should >> be fixed since in Java strings are immutable. That's one thing I have on >> my list - but not with highest priority. >> > > > > So, for example I found that the UIControlEventValueChanged is not > understood in the simulator, while it is perfectly understood in the > native application. > In order to implement things like that in the emulator, is something > like this patch appropriate? > it still has some issues but I just want to understand the main idea. > > In order to catch more than one of these events, should I double the > request like here, or I can do something like > ( UIControlEventTouchUpInside | UIControlEventValueChanged ) > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ------------------------------------------------------------------------ > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Wolfgang K. <wol...@xm...> - 2009-10-13 21:09:20
|
I just committed a refactoring of the Objective C String class implementation. java.lang.String is now based on NSString while java.lang.StringBuffer is still based on NSMutableString. So Strings are immutable now as they are in Java. -- Wolfgang On Sun, Oct 11, 2009 at 5:37 PM, Wolfgang Korn <wol...@xm...> wrote: > The patch you sent makes sense to me. Its pretty much the same as it is > implemented in UIButton. To catch more than one event type with the same > target it is possible to provide the ORed values of the corresponding > UIControlEventValues. The iPhone SDK reference says: > > For example, you could request a certain action message be sent to a > certain target when a finger touches down in a control or is dragged into it > (UIControlEventTouchDown<http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIControl_Class/Reference/Reference.html#//apple_ref/c/econst/UIControlEventTouchDown>| > UIControlEventTouchDragEnter<http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIControl_Class/Reference/Reference.html#//apple_ref/c/econst/UIControlEventTouchDragEnter>). > > > -- Wolfgang > > > > Panayotis Katsaloulis wrote: > > > On 11 Οκτ 2009, at 10:05 π.μ., Wolfgang Korn wrote: > > The only features a UIButton supports right now is creation, setting its > title and to register an event handler. Especially all the color stuff > you mentioned is currently not supported. What you saw in the Java > version of UIButton (these methods based on java.awt.Color) are only > used inside our Java emulator to create a UIAlertView with properly > colored buttons. This Java implementation should be fixed as soon as we > support color operations based in UIColor. And thanks for mentioning the > UIButtonTest. Since this uses the java.awt.Color based methods it cannot > be cross-compiled. I think we should remove that from the repository to > avoid confusion. > > Coming to the String question. I lately noticed that the > java_lang_String implementation is based on NSMutableString. This should > be fixed since in Java strings are immutable. That's one thing I have on > my list - but not with highest priority. > > > > > So, for example I found that the UIControlEventValueChanged is not > understood in the simulator, while it is perfectly understood in the native > application. > In order to implement things like that in the emulator, is something like > this patch appropriate? > it still has some issues but I just want to understand the main idea. > > In order to catch more than one of these events, should I double the > request like here, or I can do something like > ( UIControlEventTouchUpInside | UIControlEventValueChanged ) > > > ------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now!http://p.sf.net/sfu/devconference > > ------------------------------ > > _______________________________________________ > xmlvm-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > > |
|
From: Panayotis K. <pan...@pa...> - 2009-10-13 22:42:17
|
On 14 Οκτ 2009, at 12:09 π.μ., Wolfgang Korn wrote: > I just committed a refactoring of the Objective C String class > implementation. java.lang.String is now based on NSString while > java.lang.StringBuffer is still based on NSMutableString. So Strings > are immutable now as they are in Java. > > -- Wolfgang Nice! I was thinking that, since I do a lot of work on the library and on the obj-c part, I am afraid that after some time without reviewing my patches, it would be impossible to synchronize. I have a few issues before I finish my part, but the work that I've done is already a lot. Right now, all java-based things work, and some native need to tweak them a bit more. Do you believe should i do a patch even at this time, and upload it to the site? There are a lot of changes and they will accumulate when time goes by. I don't want to fork, I want to stay in your track. I think the best thing I could do is create a super-patch with all changes (I think from version 536) and upload it there. A diif with "diff -ruN" is more or less 390K !!! What do you think? ( Right now I am writing a tool to automatically create skeleton files from java files to objective-c files, so that creating the native part from the java library to be as easy as possible) |
|
From: Arno P. <ar...@pu...> - 2009-10-19 05:49:27
|
OK. I'm finally back online again... 2009/10/14 Panayotis Katsaloulis <pan...@pa...> > ( Right now I am writing a tool to automatically create skeleton files > from java files to objective-c files, so that creating the native part > from the java library to be as easy as possible) > This interests me. Right now it takes a lot of effort to write both the Java and Objective-C wrapper. I have been musing for some time about a way to automate this process as much as possible. If I understand you correctly, you want to generate the ObjC file from the Java wrappers? I think the problem is more complicated and deserves more thinking. ObjC has great reflection mechanisms. It is possible to "traverse" the Cocoa (binary) libraries and extract all required signature information (I believe that is how the free gcc toolchain guys generate the .h files that an application needs to #import). Ideally, I would like to do the same to create both the XMLVM-specific ObjC wrappers as well as skeletons for Java. The libraries that come with the iPhone SDK would serve as input to our XMLVM-wrapper-skeleton generator. There are several issues that come immediately to mind: - the Java skeletons would be manually edited with implementation for our Java emulator (of course, only if one wanted to continue the XMLVM-specific iPhone emulator written in Java). Here we have the typical problem of code generation tools where the output needs to be manually edited: update cycles become tricky (if you re-generate the Java code you might overwrite the hand-written part from the previous iteration). - things get even trickier when you consider the ObjC wrapper. While for most parts these wrappers are fairly "symmetric", there are numerous exceptions: for memory management, value types (structs), C-functions, pointer-to-pointer to mimic call-by-reference, just to name a few that come immediately to mind. I don't think such a wrapper-generator can do its work completely autonomous. What might be required is some kind of "meta-mapping file" that gives hints to this wrapper-generator (i.e., how to map ObjC signatures to Java). I would love to move in that direction. It would remove the error prone process of hand-coding all wrappers and skeletons and we have a realistic chance not to loose the battle with new SDK versions. But I don't believe that a "drive-by-coding" solution will be sufficient. Anyone interested to discuss this problem? In particular those who know ObjC well? Arno |
|
From: Panayotis K. <pan...@pa...> - 2009-10-19 07:59:49
|
On 19 Οκτ 2009, at 8:25 π.μ., Arno Puder wrote: > > OK. I'm finally back online again… Welcome back :) > If I understand you correctly, you want to generate the ObjC file > from the Java wrappers? Yes, that was the idea. "Was", because now I am trying to improve the emulator. The current xmlvm Cocoa Touch support is extremely limited. Actually is supporting *only* what the Xokoban and iRemote applications need. ;-) Since I'd preferred a more complete environment, I'm heading towards this direction first. > I think the problem is more complicated and deserves more thinking. … I agree with your thoughts. My consideration was to at least have a nice wrapper where we can start from. It probably be able to understand empty selector implementations and implementations already be done, and don't change the latter. Doing everything completely automatic is interesting but it's not trivial (although we're here to discuss it). What I did at the end, as a temporal solution, is to make xmlvm create for me the ObjC wrapper of the library, as if it was code I'd like to use it (like android library). Then I manually edited the file and quickly added the implementation. To make sure that, in existing implementations I wouldn't overwrite anything useful, I created a batch script that compares the two .h files and displays only the differences. That is of course far away from the optimal, but at least it improved my speed with tools already existing. Now, about parsing the ObjC binary - I don't think this is the direction to go on. I find it safer to parse .h files from the SDK, since this is the actual "showcase" of the application. |
|
From: Sascha H. <sa...@xm...> - 2009-10-13 22:50:30
|
Hi Panayotis, first of all, I think the earlier you have a patch that is consistent and doesn't break anything, the better it is. If the patch is too large it will take us too long to review it. So I think it is your responsibility to try to break the patch down into manageable chunks. 390.000 lines of code sounds strange to me. Does this include a bunch of auto-generates empty stubs? // Sascha 2009/10/14 Panayotis Katsaloulis <pan...@pa...> > > On 14 Οκτ 2009, at 12:09 π.μ., Wolfgang Korn wrote: > > > I just committed a refactoring of the Objective C String class > > implementation. java.lang.String is now based on NSString while > > java.lang.StringBuffer is still based on NSMutableString. So Strings > > are immutable now as they are in Java. > > > > -- Wolfgang > > Nice! > > I was thinking that, since I do a lot of work on the library and on > the obj-c part, I am afraid that after some time without reviewing my > patches, it would be impossible to synchronize. > I have a few issues before I finish my part, but the work that I've > done is already a lot. Right now, all java-based things work, and some > native need to tweak them a bit more. > > Do you believe should i do a patch even at this time, and upload it to > the site? > There are a lot of changes and they will accumulate when time goes by. > I don't want to fork, I want to stay in your track. > > I think the best thing I could do is create a super-patch with all > changes (I think from version 536) and upload it there. > A diif with "diff -ruN" is more or less 390K !!! > What do you think? > > ( Right now I am writing a tool to automatically create skeleton files > from java files to objective-c files, so that creating the native part > from the java library to be as easy as possible) > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Panayotis K. <pan...@pa...> - 2009-10-13 23:44:56
|
On 14 Οκτ 2009, at 1:49 π.μ., Sascha Haeberling wrote: > Hi Panayotis, > ... > 390.000 lines of code sounds strange to me. Does this include a > bunch of auto-generates empty stubs? oops, you misunderstood 390.000 BYTES of code ;) |
|
From: Panayotis K. <pan...@pa...> - 2009-10-13 23:31:50
|
On 14 Οκτ 2009, at 1:49 π.μ., Sascha Haeberling wrote: > Hi Panayotis, > > first of all, I think the earlier you have a patch that is > consistent and doesn't break anything, the better it is. If the > patch is too large it will take us too long to review it. So I think > it is your responsibility to try to break the patch down into > manageable chunks. > > 390.000 lines of code sounds strange to me. Does this include a > bunch of auto-generates empty stubs? > > // Sascha No, but it had some refactoring, since as I said I separated the view of the GUI elements from the model, and so the public methods (of the GUI elements again) are clear and reflect what they really support. They are not really 390K of code, since diff puts some extra headers in the beginning and in the end. A typical diff -ruN xmlvm xmlvm.patched | grep '^\+' | wc gives ~5600 lines of code The changes now are in *so* many places that I don't think it's possible to make smaller patches. I can only break it into (e.g.) patches for obj-c support library and patches for xmlvm core itself. But I'm not sure if this will help at all :) I can not even distinguish the patches for the demos, since some of them depend on the support library PS: I tried to upload the patch to http://xmlvm-reviews.appspot.com/ new but every time I select a file I get an error message saying Patch set contains no recognizable patches PS2: Is there already a tool to create auto-generated empty stubs? Because I am coding one right now, and if there is it will save my time. |
|
From: Sascha H. <sa...@xm...> - 2009-10-14 01:01:10
|
Hi, well 5600 LOC sounds much better. But again, it is quite big and I would like you to give us feedback as early as possible. While we highly look forward to your contribution, we should make sure you don't make major changes that we might have disagreements on. We probably won't but as I haven't seen your patch, I want to make sure no time is wasted. So try to assemble a patch as soon as possible for us to reviews. In general, the smaller a patch the better it is and the more effective it is for us to review. About the error: Make sure your patch is created from the correct root. The root should be: http://xmlvm.svn.sourceforge.net/svnroot/xmlvm/trunk/xmlvm/ So in your patch file, the paths should start with 'src/'. If you don't get it to work, feel free to send the patch to my e-mail address and I will take a look. Thanks // Sascha PS: I am sure you read it, but just to remind you: Please make sure your code is formatted according to our code guidelines and is well documented ( http://xmlvm.org/contribute/) This will help us maintain a good quality of the code and will make it easier for us to review. Thanks! 2009/10/14 Panayotis Katsaloulis <pan...@pa...> > > On 14 Οκτ 2009, at 1:49 π.μ., Sascha Haeberling wrote: > > > Hi Panayotis, > > > > first of all, I think the earlier you have a patch that is > > consistent and doesn't break anything, the better it is. If the > > patch is too large it will take us too long to review it. So I think > > it is your responsibility to try to break the patch down into > > manageable chunks. > > > > 390.000 lines of code sounds strange to me. Does this include a > > bunch of auto-generates empty stubs? > > > > // Sascha > > No, but it had some refactoring, since as I said I separated the view > of the GUI elements from the model, and so the public methods (of the > GUI elements again) are clear and reflect what they really support. > They are not really 390K of code, since diff puts some extra headers > in the beginning and in the end. > A typical > diff -ruN xmlvm xmlvm.patched | grep '^\+' | wc > gives ~5600 lines of code > > The changes now are in *so* many places that I don't think it's > possible to make smaller patches. I can only break it into (e.g.) > patches for obj-c support library and patches for xmlvm core itself. > But I'm not sure if this will help at all :) > I can not even distinguish the patches for the demos, since some of > them depend on the support library > > PS: I tried to upload the patch to http://xmlvm-reviews.appspot.com/ > new but every time I select a file I get an error message saying > Patch set contains no recognizable patches > > > PS2: Is there already a tool to create auto-generated empty stubs? > Because I am coding one right now, and if there is it will save my time. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Arno P. <ar...@pu...> - 2009-10-19 09:43:07
|
Panayotis Katsaloulis wrote: > Now, about parsing the ObjC binary - I don't think this is the > direction to go on. I find it safer to parse .h files from the SDK, > since this is the actual "showcase" of the application. well, I would argue that it is generally easier to parse binaries (especially when you have a powerful reflection mechanism) than source code (that is also the reason why we read byte codes and not Java source code in XMLVM). Think about the nasty things you can do even in ObjC .h files: from pre-processing directives to constant expressions. All that goes away if you parse the binary versions of the libraries. A small prototype might be an interesting first step to evaluate the complexity of the various approaches. Arno |
|
From: Markus H. <ma...@ti...> - 2009-10-19 10:25:33
|
Hi, Maybe this could be a starting point: http://code.google.com/p/jnaerator/ It parses c and ObjC headers and generates wrappers for java. I wanted to try it with xmlvm, but haven't found the time yet. Markus Am Montag, den 19.10.2009, 11:19 +0200 schrieb Arno Puder: > > Panayotis Katsaloulis wrote: > > Now, about parsing the ObjC binary - I don't think this is the > > direction to go on. I find it safer to parse .h files from the SDK, > > since this is the actual "showcase" of the application. > > well, I would argue that it is generally easier to parse binaries > (especially when you have a powerful reflection mechanism) than source > code (that is also the reason why we read byte codes and not Java source > code in XMLVM). Think about the nasty things you can do even in ObjC .h > files: from pre-processing directives to constant expressions. All that > goes away if you parse the binary versions of the libraries. > > A small prototype might be an interesting first step to evaluate the > complexity of the various approaches. > > Arno > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X