28.05.2010, 10:00
|
RouteConverter and Mac OS X
|
My application is not correct. It only runs on the build system.
Anyhow: You can still use the Routeconverter.icns Some observations: did you see the forum thread at sourceforge about the eventpump (first 2 posts)? Also: you (and some others too) specify the "-XstartOnFirstThread". However, java on OSX is Quartz based, not X11 based. Next to that are the (Snow)Leopard Xwindows versions on OSX also Quartz based and no longer on the "old fashioned" X11 basis. X11 applications use the functions in the Xwindows/client system, which are Quartz on OSX. It means that java applications on OSX do not need to call X11 (as first thread) at all, but display directly via Quartz. Most probably that's the reason why attempts to use "java -XstartOnFirstThread -jar Routeconverter.jar" result in a hanging application: X11 is simply not started by OSXes java. (I started X11 in advance as well and then used the same command, but that also resulted in a hanging app). (27.05.2010, 22:16)routeconverter Wrote: That assumption is not valid for my release process. The prereleases are always the latest versions you can get. And I update them at least once a week.Well, the release version mentions 1.33 where as the Prerelease mentions 1.31.3 with a new version 1.32 available. That's confusing and that's why I assumed that the prelease versions were older. (27.05.2010, 22:16)routeconverter Wrote: I'm using the Maven osxappbundle-maven-plugin and thought it would produce reasonable bundles... Any hints regarding the pom.xml are appreciated.I did have a look at it but it's really java related and really complicated and it seems that it packages all dependent jars as such in the bundle whereas your complete jar already contains all these dependendency jars ("jar tf jarfile" is one of the few commands I know). That's also why the java -jar Routeconverter.jar works (apart from the map): it contains everything and is completely portable. (27.05.2010, 22:16)routeconverter Wrote: From which in conclude that this does not start the Java 6 but the Java 5?The java preferences tool on OSX mentions an immediate switch. To be sure I rebooted and the message is no longer displayed. I assume the java tool does switch it but maybe there were some java-5 left-overs in memory. Just to report as complete as possible see the startup messages from a "clean" java-6 start: Code: java -jar RouteConverter.jar (27.05.2010, 22:16)routeconverter Wrote:On OSX the file handle can be: "file", "folder", "file+folder". I assume the third is used but I don't know java. Only AppleScript and some basic C.(27.05.2010, 18:23)hvdwolf Wrote: It starts with an error "Can't open <blah blah> due to unknow file type" (note:translated back to english from dutch) for the source. This is due to the fact that the application somehow tries to open a folder instead of a file. (27.05.2010, 22:16)routeconverter Wrote: This is the real issue - can you manage to use the 32-bit Java 6 version? Or is it easier if I'd package a RouteConverter with an 64-bit SWT-library?The non-standard java-6 for Leopard only comes as a 64bit version. A 64bit RouteConverter.jar with a 64bit swt would be very nice. I'm verry happy to test it. My java-5 system version is a universal "ppc7400/i386/x86_64". Maybe you already know about the "Universal" concept. In that case you can skip the following <Universal>section, otherwise please read it. <Universal> Mac comes from ppc hardware and switched early 2006 to intel. For this they "invented" the universal concept. Every binary and library is built for the specific hardware and then "lipo merged". Tiger was ppc/i386. Leopard is mostly ppc/i386/x86_64, partly ppc/i386 and in some libraries/binaries/frameworks "ppc/i386/ppc64/x86_64". SnowLeopard abandoned the ppc platform and is "i386/x86_64". On snowLeopard you have the option (for Universal apps) to right-click the app->Get Info and set it to "automatic", "always run as 32bit", "always run as 64bit". Java can be set via the Java tool in the Utilities folder in the Applications folder. </Universal> The bundle principle: The bundle is actually nothing more then a special folder structure and due to some special files the OS and file manager (Finder) recognises it as an App and displays it as a single file. The bundle principle has the advantage that you can stuff everything in it that is not standardly supported on the OS or the OS version. It might be possible to pack the entire java 1.6 inside the bundle. This will blow up the bundle from the current 6 MB to 135MB and maybe more when more dependencies need to be bundled. I don't like that approach, but did have a look at it using the soylatte BSD ported 32bit java6 version. That one is based on OpenMotif which makes the gui look terribly ugly and doesn't make the app work better. It makes it even worse. The map is not displayed either. (27.05.2010, 22:16)routeconverter Wrote:I did them all I think. More options? (a 64bit swt perhaps?(27.05.2010, 18:23)hvdwolf Wrote: Do you have more options for me to test?  )
28.05.2010, 23:34
(28.05.2010, 18:48)hvdwolf Wrote: I did have a look at it but it's really java related Yes (28.05.2010, 18:48)hvdwolf Wrote: and really complicated Yes (28.05.2010, 18:48)hvdwolf Wrote: and it seems that it packages all dependent jars as such in the bundle whereas your complete jar already contains all these dependendency jars Not really, the .jar is Mac-specific due to the Eclipse SWT dependency. And the .app is an experiment to become better on the Mac. How do you build your .app's? Is it possible to minimize the files? Quote: seems to be a lot. (28.05.2010, 18:48)hvdwolf Wrote:(27.05.2010, 22:16)routeconverter Wrote:On OSX the file handle can be: "file", "folder", "file+folder". I assume the third is used but I don't know java. Only AppleScript and some basic C.(27.05.2010, 18:23)hvdwolf Wrote: It starts with an error "Can't open <blah blah> due to unknow file type" (note:translated back to english from dutch) for the source. This is due to the fact that the application somehow tries to open a folder instead of a file. Good hint. I think I found the bug. (28.05.2010, 18:48)hvdwolf Wrote:(27.05.2010, 22:16)routeconverter Wrote:I did them all I think. More options? (a 64bit swt perhaps?(27.05.2010, 18:23)hvdwolf Wrote: Do you have more options for me to test? Have a look a the prereleases page :-)
--
Christian (28.05.2010, 23:34)routeconverter Wrote: How do you build your .app's? Is it possible to minimize the files?Yes it is. Sorry I wasn't more specific. The zip contains the application and the icons package. The application is only the file structure shown below: Quote: The icons "package" is the file RouteConverter.icns (which you already used for the new prerelease) OSX puts some zip indexing "garbage" in a zip file as "semi-hidden" 0byte files. It allows OSX to view big, complicated zip files very fast in the file manager. I had not thought of that and it looks really weird on Linux or Windows. I should have used the command line zip. Sorry. So all of the mentioned __MACOSX can be removed. It's waste on all other platforms. (28.05.2010, 23:34)routeconverter Wrote: Good hint. I think I found the bug.I'm not sure where RouteConverter stores it's preferences and so on. I found ~/.java/.userPrefs/slash which I removed. I started the "old" Routeconverter and it generated the error and then builds(?) or indexes(?) it's conversion options. The new RouteConverter64 does not generate the error. Did I check this correctly? (28.05.2010, 23:34)routeconverter Wrote: Have a look a the prereleases page :-)Nice one. Unfortunately the Application still doesn't start, but it does contain a nice icon The .jar starts correctly. I first used "java -jar RouteConverterPrereleaseMac64.jar" and it opens correctly showing the following messages (only relevant ones): Code: java -jar RouteConverterPrereleaseMac64.jar Code: slash.navigation.converter.gui.RouteConverter6.main(RouteConverter6.java:48)As you can see it mentions the "-XstartOnFirstThread". So it starts correct but doesn't show the map. Then I started the .jar with "java -XstartOnFirstThread -jar RouteConverterPrereleaseMac64.jar". Now it starts correct and it does show the map. It does show an error message: "Unable to call RouteConverter from Webbrowser via port 53465. Please check your firewall." So I opened my firewall for that port. On restart it throws another port error. After about 6 errors in the same range I decided to open a port range in my router firewall from 53400-53999 and completely opened my Apple macbooks firewall, but this still doesn't stop the error. It keeps on generating port errors in the same 53xxx range which I already completely opened. What is this? Other observations: - without the map loaded I can resize the screen, which is necessary as some buttons are obscured behind the window borders. With the map loaded the application hangs when trying to resize the screen. I can resize the map/text panes inside the application using the center spacer. - The map never fills the entire left map pane. Zooming in/out on the map does work correctly. Dragging of the map sometimes results in only half a map, or 75% map or little more, but the entire map pane is never filled. - Right-clicking works apart from Insert/Remove - The application now has a menu (file, Edit, View, Tools, Extra and Help). Is this new design or is it due to the now working swt? - I do miss the handy on-screen "open" and "Save" buttons for conversion. On purpose as a design decision? Thanks so far your work in trying to help us.
29.05.2010, 10:27
(This post was last modified: 29.05.2010, 10:31 by routeconverter.)
(29.05.2010, 09:33)hvdwolf Wrote: The zip contains the application and the icons package. The application is only the file structure shown below: The Maven Plugin I use generates this structure: Quote:RouteConverter.app/ Let's see if I can come closer to your structure. (29.05.2010, 09:33)hvdwolf Wrote: The icons "package" is the file RouteConverter.icns (which you already used for the new prerelease) Thank you for helping me. (29.05.2010, 09:33)hvdwolf Wrote: OSX puts some zip indexing "garbage" in a zip file as "semi-hidden" 0byte files. It allows OSX to view big, complicated zip files very fast in the file manager. I had not thought of that and it looks really weird on Linux or Windows. I should have used the command line zip. There will never be one JAR/ZIP/whatever as long as there is platform-specific code for gpsbabel and Eclipse SWT. Which means: I'd like to build the best Mac OS X ZIP that's possible even if it's larger. Linux and Windows user use their own .exe and .jar files. (29.05.2010, 09:33)hvdwolf Wrote: So all of the mentioned __MACOSX can be removed. It's waste on all other platforms. But it would make sense on Mac OS X? (29.05.2010, 09:33)hvdwolf Wrote:(28.05.2010, 23:34)routeconverter Wrote: Good hint. I think I found the bug.I'm not sure where RouteConverter stores it's preferences and so on. I found ~/.java/.userPrefs/slash which I removed. I don't know but I guess that's where Java programs store their preferences. (29.05.2010, 09:33)hvdwolf Wrote: The new RouteConverter64 does not generate the error. That's the intended behaviour ;-) (29.05.2010, 09:33)hvdwolf Wrote:(28.05.2010, 23:34)routeconverter Wrote: Have a look a the prereleases page :-)Nice one. I didn't expect that - finally, we're doing remote debugging here with one Mac-OS-X-but-not-Java-expert at the one end and one Java-but-not-Mac-OS-X-owner at the other end. Please be patient I think we still can make progress. (29.05.2010, 09:33)hvdwolf Wrote: Then I started the .jar with "java -XstartOnFirstThread -jar RouteConverterPrereleaseMac64.jar". Cool. So -XstartOnFirstThread is needed. (29.05.2010, 09:33)hvdwolf Wrote: It does show an error message: "Unable to call RouteConverter from Webbrowser via port 53465. Please check your firewall." That is the embedded (WebKit?) Browser-process that tries to call the RouteConverter-Java-process via HTTP. It's needed for interactions that start from the map or that come from Google Maps API callbacks. (29.05.2010, 09:33)hvdwolf Wrote: So I opened my firewall for that port. On restart it throws another port error. After about 6 errors in the same range I decided to open a port range in my router firewall from 53400-53999 and completely opened my Apple macbooks firewall, but this still doesn't stop the error. It keeps on generating port errors in the same 53xxx range which I already completely opened. What is this? Opening the firewall is generally a bad thing. But maybe you could allow that the Mac OS X browser connects to the RouteConverter process on the local loopback device (i.e. it calls http://localhost:<some port number above 1024>/...) (29.05.2010, 09:33)hvdwolf Wrote: Other observations: Do you see errors on the console or inside the log? (29.05.2010, 09:33)hvdwolf Wrote: - The map never fills the entire left map pane. Zooming in/out on the map does work correctly. Dragging of the map sometimes results in only half a map, or 75% map or little more, but the entire map pane is never filled. But a map is displayed? That would mean you've managed to get where noone has been before since I switched the map to Eclipse SWT. (29.05.2010, 09:33)hvdwolf Wrote: - Right-clicking works apart from Insert/Remove There for example I need the backchannel from the browser to the Java process (29.05.2010, 09:33)hvdwolf Wrote: - The application now has a menu (file, Edit, View, Tools, Extra and Help). Is this new design or is it due to the now working swt? That's the new design I'm working on. (29.05.2010, 09:33)hvdwolf Wrote: - I do miss the handy on-screen "open" and "Save" buttons for conversion. On purpose as a design decision? I'm not sure if I use menu- and toolbar or switch to Ribbons. I had only on-screen buttons but for switching to menu- and toolbar plus context menu I have to restructure the complete action handling of the application... so I'm focusing on that since it enables me to have not just one but as many user controls for one action. What do you think about Ribbons from the Mac OS X standpoint? (29.05.2010, 09:33)hvdwolf Wrote: Thanks so far your work in trying to help us. Thank you for helping me. (You say us?)
--
Christian (29.05.2010, 10:27)routeconverter Wrote: The Maven Plugin I use generates this structure:As far as I can judge from the "jar tf jarfile" command your mac jar contains already everything. That's why my application is so much simpler. The Maven plugin assumes that you did not yet pack everything in the jar and checks automatically which dependencies are needed to also put in the bundle (the bundle concepts makes it possible to put "everything" in the bundle). On the other hand, the Maven plugin is not so smart that it detects that every dependency is already inside the Routeconverter jar and therefore it adds it again redundantly. The Platypus option I used is based on the fact (my understanding) that everything was already in the jar. Once the Platypus structure has been built it is also very simple to maintain it by hand on a Linux or windows system. It only requires you to pack a new jar inside the folder structure and update two ASCII xml files for version numbers/dates and so on. I will send you the instructions once we have a good working version. (29.05.2010, 10:27)routeconverter Wrote:No, not really. OSX only uses this as some quick preview AFAIK, but it can handle every zip file. For smaller zip files, the quick view has no added value as a small zip can be interpreted fast enough.(29.05.2010, 09:33)hvdwolf Wrote: So all of the mentioned __MACOSX can be removed. It's waste on all other platforms. I "normally" always use the command-line zip as I hate to put all these extra stuff into a zip. I also work on linux and at my work on windows. I don't want this rubbish inside my zips. (29.05.2010, 10:27)routeconverter Wrote: I didn't expect that - finally, we're doing remote debugging here with one Mac-OS-X-but-not-Java-expert at the one end and one Java-but-not-Mac-OS-X-owner at the other end. Please be patient I think we still can make progress.I have no problem in bug-fixing and troubleshooting any further. I have been in this kind of processes many times on the other projects where I'm a real contributor for the OSX part. I'm new to RouteConverter as my pda first with TomTom and in the past 2 years with IGO8 using .kml's finally crashed after 6 years and I had to buy a new one: a Navigon 1410 using ".freshroute" as route format. (29.05.2010, 10:27)routeconverter Wrote: Cool. So -XstartOnFirstThread is needed.Yes, apparently. I must have been all wrong when concluding that it had to do with X11. (29.05.2010, 10:27)routeconverter Wrote: Opening the firewall is generally a bad thing. But maybe you could allow that the Mac OS X browser connects to the RouteConverter process on the local loopback device (i.e. it calls http://localhost:<some port number above 1024>/...)I don't like to open the firewall either, but I was troubleshooting. I have already closed everything again. With regard to the localhost "thing": I need some guidance here: how do I do that, add something in my service file or so? Also: it "auto chooses" another port at every new startup. Can you set a fixed port for this? Otherwise it will remain a moving target I'm affraid. (29.05.2010, 10:27)routeconverter Wrote:No, it does not. Once it's hanging no new entries are added to the RouteConverter.log and neither to the systemlog nor to the OSXes "CrashReporter" logs.(29.05.2010, 09:33)hvdwolf Wrote: Other observations: (29.05.2010, 10:27)routeconverter Wrote:Yes, and I'm very happy with it.(29.05.2010, 09:33)hvdwolf Wrote: - The map never fills the entire left map pane. Zooming in/out on the map does work correctly. Dragging of the map sometimes results in only half a map, or 75% map or little more, but the entire map pane is never filled. (29.05.2010, 10:27)routeconverter Wrote:With ribbons I assume you mean the Office 2007 like feature for swt as described here?(29.05.2010, 09:33)hvdwolf Wrote: - Right-clicking works apart from Insert/Remove I still have to get used to the Office 2007 ribbons menu in my daughter's and son's pcs. It's not logical to me and I keep searching for commands and options, but it can be me just being too dumm to understand it. I prefer a simple menu structure like you have now, especially as I don't foresee RouteConverter getting as many commands and options as Office 2007. But my first wish is to get a nice working application and I will manage to adapt to every menu you throw at me. (29.05.2010, 10:27)routeconverter Wrote:(29.05.2010, 09:33)hvdwolf Wrote: Thanks so far your work in trying to help us. With "us" I mean the OSX users. For delivering such a nice tool to "us", which seems to get even better in the near future for which "we" are all very grateful. Vielen Dank. ps: If necessary I can also participate in the german forums. I do read and understand (almost) everything. My writing is not good but that requires some flexibility from the german users. 
With regard to the crash when resizing the screen with the map visible: I started the jar with "java -verbose -XstartOnFirstThread -jar RouteConverterPrereleaseMac64.jar". Now this verbose option generates loads of messages. When trying to resize the window the following messages are generated. I hope it gives you some extra info.
Code: [Loaded apple.awt.CWindow$14 from /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar]When starting the application and select from the menu "View -> Maximize Map", I get the complete map and can scroll, move, zoom in/out. When I then select "View -> Show Map and Position list" I can also scroll, move, zoom in/out. It's not 100% stable yet, but in case it's again partially visible I do the "maximize, map&postion" trick again. I now get the idea that the map window size is not correctly determined/initialized, until you maximize it (known screen size) and then set it back where it now "remembers" the original size and intitializes it correctly. The right-click insert/remove still doesn't work due to that not working webkit internal http connection that you explained.
More observations.
Please note that I'm not complaining about the functionality. I just try to be a good test user. Map: - Coordinates work "more or less", but the map coordinates are not correct. When using the right-click "Center Map", a position about 30% left from the map ("outside" the map) is set as center on the map (the map shifts to the right). - It is possible to add coordinates to the position list by moving to a specific spot and use the "Insert position" button. Again, the coordinates are about 30% off center to the left. Also: when selecting a position in the position list, the red google upside-down "bulb" is displayed on the map. - When going into the "Browse" pane, and selecting a route/track, it is displayed correctly on the map. Again, the center position is "off center" to the right, which means that the route/track is displayed too far to the right, meaning that the right "half" of the route is more or less displayed "behind" the position list (Not visible off course, just meant as example). (Btw: Nice to have such a route "database" in the application) Menu: - When clicking on a menu, and then switching to another application, the expanded menu stays floating on top of everything. When going back to Routeconverter and closing the menu by clicking it again, it is closed and removed. - When opening a menu option, and then dragging the application by it's top window bar, the opened menu doesn't move with the application but "stays behind". The menu options still function though. - When selecting from the View menu, "Maximize Position List" and then again "Show Map and Position List", the Map is positioned too far left leaving a grey area on the right side of the map (same as not correct coordinates mapping?). When selecting "Maximize Map" and then "Show Map and Position List", it's working correct. Application: - Sometimes the Application stays the front-most application even when switching to another application. This other application does have the working focus but stays behind the RouteConverter screen. I do not know yet when this exactly happens. I will try to track that down.
01.06.2010, 10:35
(29.05.2010, 14:18)hvdwolf Wrote: When starting the application and select from the menu "View -> Maximize Map", I get the complete map and can scroll, move, zoom in/out. (30.05.2010, 10:43)hvdwolf Wrote: Map: Solved with modified routeconverter.html from this thread. |
|
« Next Oldest | Next Newest »
|
![[Image: routeconverter.jpg]](http://panorama.dyndns.org/Routeconverter/routeconverter.jpg)
Users browsing this thread: 5 Guest(s)