Blog
Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 38 39 40 41 42 43 44 45 46 ... 50 ... 55 ... 60 ... 65
Carbon/ATSUI fonts
Date: 1/2/2007
I mentioned I was working on the fonts in the previous entry and well I've got it almost all sorted out. I needed to use the CGContextRef from the kEventControlDraw event and plug it into the ATSU layout object. That fixed the kerning and anti-aliasing but broke the positioning. A few flips of the context's CTM and that was sorted out as well.

Then I turned on font substitution, a feature that you have to implement yourself on Windows and Linux and all the international characters magically appeared. Ohoooo Arhhhhh!

Finally all that is left is that all my text looks like it's drawn in a bold font. I'm retreiving the current system font and setting that up as the default application font, and I'm not setting the bold property... so I'm a bit confused over that one.
(0) Comments | Add Comment

Scribe/Mac
Date: 29/1/2007
I created an xcode project for Scribe today. I'm really starting to get a handle on xcode's project system. Most of last week was just working out how to build a product into a shippable download. I'm refining that process this week.

To build Scribe the code required a bit of clean up. Most prominant was getting the scripting engine to build without using wide string literals, i.e. L"some string". That works on windows but not on Mac because the API is expect utf-16 and the compiler generates utf-32 string literals. Nice eh?

So I've got my Scribe project building and I ran it up for the first time. It got as far as the language selection dialog and all of the internation characters were missing. But the flags were there :) Then it asserted just after that so I didn't get to see the main window. Also the fonts look awful since I implemented GetSystemFont correctly. I must fix the global drawing context for ATSUI.

So the work continues.
(0) Comments | Add Comment

i.Ftp/Mac Changelog
Date: 26/1/2007
Test1:
  • Dismal failure, doesn't find the Lgi framework properly.


Test2:
  • Re-did my entire project file to get the private framework installed and working inside the app bundle.


Test3 (unreleased):
  • Help -> About crash
  • Help -> Help now works...
  • You can now close the Sceduling window.
  • Cmd-Q now works.
(0) Comments | Add Comment

Smoke Test
Date: 25/1/2007
Can someone with a PPC Mac download this app and see if it runs?

Update: Ok, the first attempt was a failure. But I've worked out how to embed a framework in a bundle after much head scratching and reading copious amounts of documentation.

So the download link is the same, but I've updated the file it points to. Have at it then!
(5) Comments | Add Comment

What I Fixed Tonight
Date: 23/1/2007
Well lets see, I fixed the list control selecting a whole range of items in one click. I fixed the combo box not painting it's content. I fixed modal dialogs gettings hidden behind the owning window. I made the text on buttons darker. I fixed the saving of account settings, which brings me to the lovely topic of printf formatting.

Ah printf formatting. It's nice and universal between platforms and every coder knows the basics by wrote. But it seems that the humble printf is to blame for a number of bugs in my software, mostly to do with the processing of 64bit integers. In the case of a 64bit integer passed to printf, 8 bytes are put onto the stack instead of the usual 4, so you have to instruct the printf command to expect that when crafting the format string. And this is where the trouble starts. Each platform has it's own lingo for that:
  • Windows: "%I64i"
  • Linux: "%Ld"
  • Mac: "%lli"
These all format a 64bit integer into a decimal string. So I've abstracted that out and now I use a define for that, and conveniently C will concatenate adjact strings together so you can do this sort of thing:
int64 Value = 1234;
char s[256];
sprintf(s, "Value = " LGI_PrintfInt64 "\n", Value);
Where LGI_PrintfInt64 is the format string for 64bit ints for your platform.

The other case where it bit me is where I pass a single 64bit int to printf and use "%i" as the format. On Intel machines this works for values <4gb because of the byte ordering. On my PPC mac mini of course it doesn't work at all because the bytes are the other way around. Nevertheless you shouldn't do that, either cast it to an int or use the proper int64 formatting string.

So I've uploaded a file and downloaded a file, created an account. i.Ftp is pretty usable right now. The only thing really outstanding is deleting local files, a few asserts in the FTP protocol code and working out how to package it into a .dmg release.

But I feel good. The hard part is over... it's really down hill from here.
(0) Comments | Add Comment

Porting...
Date: 23/1/2007
Ok context menus are working. I had to catch the message received in the owning window and route it back to GMenu::Float instead of receiving the value back from ContextualMenuSelect. Someone from the carbon-dev list helped me out there.

Then the menus were coming up in the wrong place... had to get the x,y ordering right to initialize the Point variable. Fixed.

Then the combobox menus were coming up in weird places. Which was due to a bug in GView::PointToScreen(...). Fixed.

Then fixed a bug in i.Ftp that would send you to ".." when you use the context menu command "Change Dir" on the ".." entry. Which wasn't related to Lgi and the Mac port, but a bug none-the-less.

Now there is a little issue with the saving and restoring of account information in the connect dialog. And after that a little more testing to make sure the basic functionality is working and then I'll release it.

I'm also looking for some good documentation on how to build a .dmg to distribute the application.

Reeeeeeaally close now :)
(0) Comments | Add Comment