Bug 935 "APPLICATION CLOSE"
I can post a patch for this tomorrow morning.
Recall that when I tried to start it from the command line, the program displayed the splash logo and then immediately became unresponsive. It was using the CPU fully and it was failing to quit when asked to do so.
My initial experience opening it via the GUI, on the other hand, was that it opened fine, though it failed to find ImageMagick, and then crashed only when I tried to do something in the drawing window.
I opened it a second time and then closed it without doing anything else in order to create a preferences file, which I then edited to give the path to ImageMagick. I then found that when I opened it again via the GUI, it behaved exactly the same as when I had previously executed it from the command line (for which paths to ImageMagick were defined by my shell).
In other words, it is ImageMagick, most likely convert (since that appeared in the ps listing) that caused Xtreme to hang on start-up. I just thought this behavior might be significant to somebody. Clearly I will have to disable the path to IM again in order to successfully start Xtreme again, unless someone can suggest another fix.
Since I haven't received the email with registration confirmation for that forum yet (I'm not sure whether a delay is normal or not), I'll just continue posting here for now.
It might be better to have this discussion on the dev list (see http://www.xaraxtreme.org/community/) by the way, there are more Mac folks there. I'm not sure they are a huge amount further forward than you though...
Also, I may have to at least temporarly scale back my efforts to get Xtreme working, because I just discovered, and successfully installed, the package Inkscape, which looks like it might accomplish most of what I was looking for in a drawing package.
Thanks to both Ben and Alex for your efforts on behalf of getting Xtreme running on my Mac ... I'll try to stay tuned for news on this front.
I guess one thing I never found out is whether *anyone* out there has a more or less functioning copy of Xtreme running on an Intel-based Mac?
I do assure you that that the Linux edition of the Xara LX is held in high regard, and we expect that it only a matter of time and continued effort before the Mac version reaches parity with it; and of course, your comments and the account of your experiences has indeed been a help and stimulus!
I figured I'd keep this going with my experience, in case someone's listening.
I built Xara without any difficulties at all, first try, by following the XCode instructions on the site. Now, I'm running XCode 2.3 on a PowerBook G4 (1.25 gig of ram) with fink 0.80 and OSX 10.4.7. Because of Blender I also have my gcc set to v3.3; this might make a difference.
Anyway, compiled fine with very few issues; the biggest problem was that I ran out of hard disk space. (After building, the total size of all compiled object files and the executable is 1.84 gig. That's insane.) Lemme hit you up with a few screen shots:
First run was much as stated above -- I got windows, and the menus are built, but Xara->About did nothing and any attempt to use a tool caused a crash. On reload of the program I got the lock file message above. I tried deleting the .xara-xtreme folder and restarting, but that didn't seem to have any effect.
I get the imagemagick error on every load, but I only got the font error on first load. Also, I'd like to attach the console output:
Some of that's repeated from multiple launches. The thing eating up all processor cycles seems to be the crash reporter; let it run long enough and Xara crashes properly, with the log written out. For the curious the log from the above is available at http://ministryofdoom.org/cloud/xara....crash.log.zip -- wasn't sure if people wanted me attaching it here.Code:[Debug] 21:09:58: Launching: convert [Debug] 21:09:58: wxMacExecute Bad bundle: convert [Debug] 21:09:58: pid=22040 [Debug] 21:09:58: no task_for_pid() [Debug] 21:09:58: Process ended [Debug] 21:10:30: Unrecognized accel key 'NUMPAD 1', accel string ignored. [Debug] 21:10:30: Unrecognized accel key 'NUMPAD 1', accel string ignored. [Debug] 21:10:30: Unrecognized accel key 'NUMPAD .', accel string ignored. [Debug] 21:10:30: Unrecognized accel key 'NUMPAD 2', accel string ignored. [Debug] 21:10:30: Unrecognized accel key 'NUMPAD 2', accel string ignored. [Debug] 21:10:30: Unrecognized accel key 'NUMPAD *', accel string ignored. [Debug] 21:10:55: ../src/mac/carbon/bitmap.cpp(229): assert "m_rawAccessCount == 0" failed. [Debug] 21:22:56: Launching: convert [Debug] 21:22:56: wxMacExecute Bad bundle: convert [Debug] 21:22:56: pid=22047 [Debug] 21:22:56: Successfully added notification to the runloop [Debug] 21:22:56: Process ended [Debug] 21:23:47: Launching: convert [Debug] 21:23:47: wxMacExecute Bad bundle: convert [Debug] 21:23:47: pid=22057 [Debug] 21:23:47: Successfully added notification to the runloop [Debug] 21:24:36: Process ended Aug 25 21:24:36 starbuck crashdump: XaraLX crashed Aug 25 21:24:38 starbuck crashdump: crash report written to: /Users/*****/Library/Logs/CrashReporter/XaraLX.crash.log
Things about the build that I noticed right off the bat:
- Two windows -- wxWindows is attempting to set up an MDI interface which is basically not possible / not preferred on the Mac. Once it stops crashing and starts displaying icons that's the first thing that needs to be fixed.
- The icons -- is that part of the endian troubles that were mentioned? I thought I'd read that the icons are 32-bit .png files, in which case endian troubles don't make any sense. (I've compiled the same code using libpng on both PC and Mac and run across no problems.) Unless the icons are put into those .xar files? I haven't really given it more than a five-minute look.
- The splash screen says Linux Edition. Mac version should say Mac Edition, in my opinion. (I won't go into how the color scheme makes me think of the good old CGA days, either. ^_^; )
Anyway, I'd like to play with it more. Where's a good place to start for Mac folks? Are there any code primers?
If it locks up when you use a tool, that's normally a symptom of not running from the package.
What happens is a script called buildresources.pl is run which makes a zip file (called "resources.xrs") containing all the png files. This is then converted to an .h file (don't ask) with an array of all the bytes in the zip file and bound into the executable. wxWidgets contains a VFS like thing (wxFileSystem) which can be used to load files from it. Somewhere or other this process is failing. However, the resource file itself is clearly being build OK, because the xrc (XML) for the bar definitions is in there (also loaded through the wxFileSystem) as are the strings. Somewhere or other the bitmaps (only) are failing to load. The relevant file is wxOil/camresource.cpp if you want a poke around.
www.xaraxtreme.org and look at the "Developers" section. If you are debugging bitmap loading, look specifically at the section marked "Resource System". Also, the -dev mailing list is pretty friendly.
You mentioned bundles -- I ran the executable outside the bundle. Trying to run it from within the bundle simply didn't work.
I hope I didn't sound rude; I sometimes come off as more acidic than I intend over text. I just mean that the Mac will need its own set of rules for that, as MDI is the one thing that doesn't port. Photoshop's a good example-- MDI on PC, but it uses those... weird window types (the ones that are only visible when the program has focus, I forget the name right now) for everything else.It does whatever wxWidgets does with a wxMDIWindow on the Mac (at the moment). This isn't intended to be a permanent proposition...
I also assume that the people behind Xara already know this. ^_^;
That's really interesting... Stranger still, I changed PRELOAD_BITMAPS to 1 in cameresource.cpp and the program now loads and exits properly. I also seem to have some icons loading:Yes that's odd, especially as other people have got the icons working on the Mac. What happens is a script called buildresources.pl is run which makes a zip file (called "resources.xrs") containing all the png files. This is then converted to an .h file (don't ask) with an array of all the bytes in the zip file and bound into the executable. wxWidgets contains a VFS like thing (wxFileSystem) which can be used to load files from it. Somewhere or other this process is failing. However, the resource file itself is clearly being build OK, because the xrc (XML) for the bar definitions is in there (also loaded through the wxFileSystem) as are the strings. Somewhere or other the bitmaps (only) are failing to load. The relevant file is wxOil/camresource.cpp if you want a poke around.
I get the message "No handler found for image type" twice now on each startup; that's a new one.
If I mouseover the icons, the icons appear perfectly, though. That wasn't the case before, so for whatever reason the issue is in the generation of those grey icons.
I'm going to keep playing. One more note that should be added to the Mac notes -- the project file comes with ZeroLink turned off, and turning it on actually seems to make the program load faster.
Oh, now that the debugger is loaded, the crash when clicking on the canvas comes from wxWindowBase::ScreenToClient(), at DoScreenToClient(). I think I'll leave that one alone for a moment; if you don't click, the program allows a graceful exit.
If you crash the program out, on subsequent reloads it always crashes in CCamApp::HandleKeyPress (camelot.cpp line 1311). This continues happening until you either relink the program or close and reopen XCode. I think it also happens when you hit run, but then switch immediately to another program before Xara has a chance to load.
Oh, and since you're the same Alex who wrote this code, I can't thank you enough for how beautiful and well-commented it is. This is the first time, ever, for me where I downloaded an open-source project and was able to step through the program flow without some sort of Rosetta stone. (Especially one written by a commercial software vendor.) Kudos! A lot of it's over my head, and I've only used wxWindows once before, but it's still very followable with grep and a cup of coffee. ^_^
Anyone have an executable file for mac yet? I would love to try out what is done so far but am not very experienced with code stuff. Thanks.
This is the error I get when compiling. I am sure it is pretty easy t fix but I have no idea what I am doing when it comes to Xcode. If anyone knows how to fix this error, please let me know how.Code:/usr/bin/ld: Undefined symbols: CBrushEditDlg::Init() CNameBrushDlg::Init() OpSelectBrush::Declare() CInitBrushNameDlg::Init() OpDeactivateBrush::Declare() OpChangeBrushDefinition::Declare() CBrushEditDlg::GetState(String_256*, OpDescriptor*) /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CBrushEditDlg::Init() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CNameBrushDlg::Init() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpSelectBrush::Declare() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CInitBrushNameDlg::Init() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpDeactivateBrush::Declare() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpChangeBrushDefinition::Declare() /Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/freeinfo.o reference to undefined CBrushEditDlg::GetState(String_256*, OpDescriptor*) collect2: ld returned 1 exit status
If someone can send me the executable or tell me how to fix this build error, I will go ahead and host it for everyone.
If I forget to come back to this thread, my email is daykyle (at) gmail (dot) com