Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 36 37 38 39 40 41 42 43 44 ... 45 ... 50 ... 55 ... 60 ... 65
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

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

Mac Port Update
Date: 22/1/2007
So I've got the scrollbars all sorted out. They paint correctly and work when you click on them. I havn't implemented any sort of mouse capture yet but it's good enough for a beta release.

Then I noticed that the context menus don't work, so I implemented GView::GetMouse and then everything just stopped working. This was because the mouse hook thread was hanging. So I've disabled that for the moment, as it doesn't add any important functionality for a beta release. My current issue with the contextual menus is that when I call ContextualMenuSelect it shows the menu fine, and I can click on an item and it flashes briefly but then it returns userCanceledErr (-128). There must be something I'm not adding to the menu items I guess. I've posted on the carbon dev list about it and hopefully someone will know the answer.

Still hoping to scrape in by the end of Jan.
(0) Comments | Add Comment

Mac Port Progress
Date: 21/1/2007
I struggled with getting the mouse handling to work at the same time as resizing the window, but after several hours I've got it sorted. Turns out that I need to detect the mouse being inside the title bar OR the resize box and return "not handled" otherwise I need to handle the click and return "no error" for things like up clicks AND resizing to work correctly. The docs were less than complete in that regards.

The point of that little diversion was getting the scrollbars working. Initially I thought that I hadn't implemented a native control, but no I had actually already put in place the X-platform control. What was going on was that I hadn't hooked up the layout control to actually ATTACH the scroll bars... yeah ok moving on. So now that is sorted out but I had to fix it crashing when the scrollbar is removed.

So now I need to get the scrollbars painting properly... they are all out of alignment with the parent window right now and then maybe things will be ready for packaging.


I say maybe because everytime I think I'm getting really close I find some other show stopping bug. I think I'll make the first release a zip or something so I don't have to waste more time figuring out .dmg files. Unless they are like 5 minutes of work...?
(0) Comments | Add Comment

Speed Speed Speed
Date: 18/1/2007
Well now that I have a Macbook C2D with 802-11 "n" wireless hardware it occured to me that a nice 802-11 "n" access point wouldn't go astray. Lo and behold Apple release just such an 802-11 "n" access point/router/internet gateway called the Airport Extreme. Knowing that just such an Apple product would interoperate perfectly with the "n" wireless hardware on my Macbook, I swished out the credit card and was seriously thinking about clicking "Buy" button, but fortunately (unfortunately?) I double checked the tech specs first.

Lets see, what have we here.
  • 10/100 uplink port for 'net access: tick.
  • The usual NAT/DHCP/VPN tech: tick.
  • Wireless a/b/g/n: tick.
  • Plausable price: sigh, but 'tick'.
  • Looks the business: tick.
  • Usb2 jack for external hard-disk/printer: BIG ASS TICK!
  • 3 x 10/100 wired ethernet ports: W. T. F. >:-(
How can in this day and age can Apple in all seriousness release a wired ethernet switch product that only has 10/100base-T? I mean all their computers have 1000base-T right? And this is the age of high-flippin-definition TV and gigabyte media files? The network is the weak link in my local setup:
  • Memory bus: 2GB/s
  • HD: 30+MB/s
  • Network: 7-8MB/s
  • (Cable: 1MB/s)
And 2 of the 3 computers I own do gigabit. One of the applications for a faster network would be to stream SD digital TV from the main PC that does recording to the Macbook for viewing. SD digital weighs in at about 7mb/s which is right on the edge of the bandwidth limits of (my) 100base-T network. In fact I've tried it and it skips like a young billy goat. So I need some gigabit action if I'm going to get that working smoothly. A better 100base-T switch might work, but if I'm getting something anyway, why not just do it properly and get 1000base-T?

To put things in perspective, CodingHorror goes into some detail about the various actual throughputs you can expect on various networks. A lot of people will get 30MB/s on gigabit but it's possible to get more with the right tuning. Even 100MB/s. Anyway, a good read if your at all interested.

Also the Airport Express comes with a CD to "update" your Mac computer use 802.11n, which would be a nice little bonus considering that Apple is going to charge us US$5 to enable the existing "n" hardware that we've already paid for. A practice that I find both disturbing and unethical. I don't give a hoot about your Sarbanes and your Oxley, you can shove that pile of steaming. I have every faith in the hacker community to make a free solution to that very issue widely available any time now.

So back to square one, I want some gigabit, some network attached storage, some 'net sharing and some wireless "n" that works with my Macbook. For less than $200 AUD. Is that even possible?

Update: Well it appears after a little sleuthing that a few alternative products do exist, but the info is kinda thin and the prices kinda max:
  • D-link DIR-655: Pre-N, 4 x Gigabit Eth, but NO NAS despite having a USB port on the back. Looks nice though. ~$150USD
  • Linksys WRT350N: Pre-N, 4 x Gigabit Eth, USB2 NAS, but hideously ugly. ~$150USD
Only the DIR-655 is available here for $320AUD, which is a good $100AUD more than the Apple product, although you get gigabit ethernet and lose the NAS.

One would be tempted to get the Airport Extreme and pair it with a Gigabit switch (D-link do a 5 port for $60AUD!!! *blink*) but then what is the point of 802.11n if your server is stuck behind a shared 100Mbit link between the Airport Extreme and the Gigabit switch? And you can't use that 540Mbit of "Pre-N" goodness to access your files?

Argh, it's all nafted I tell you... nafted.
(0) Comments | Add Comment