Gemli.Data Runs On Mono (So Far)

by Jon Davis 20. September 2009 00:44

I was sitting at my Mac Mini to remote into my Windows 7 machine and I had this MonoDevelop 2.0 icon sitting there (I had installed it a couple days ago just to see it install and run) and I thought I should give Gemli.Data a quick, simple test run.

Screen shot 2009-09-20 at 12.38.02 AM

(Click to view)

Notice the “Application output” window. It werkie!!

I was concerned that Mono hadn’t been flushed out well enough yet to be stable with Gemli.Data, I do a lot of reflection-heavy stuff with it to get it to infer things, not to mention System.Data dependency stuff. But it seems to work fine.

This isn’t by any means a real test, more of a quick and dirty mini smoke test. I was very happy to see that it works fine, and my confidence in Mono just went up a notch.

Not shown in the screen shot, I expanded it a little tiny bit to have multiple records, then I added sorting in the query. Apparently Gemli doesn't have sort support in the MemoryDataProvider yet so I used LINQ-to-Objects. Yes, LINQ syntax worked in Mono, too! Nifty!

Book: Beginning iPhone Development

by Jon Davis 30. November 2008 20:05

I've made a couple false-starts in learning iPhone development, but this time I'm not finding myself sputtering to a halt. In fact, I'm having a blast.

This weekend I'm reading through this book:

Beginning iPhone Development: Exploring the iPhone SDK

.. and I've posted the following review:

When this book arrived, and I saw the book cover, I knew I got something different. Not a cookie-cutter book but an original piece of work where somebody really intended to teach something.

I just got this book a few days ago and with this 4-day Thanksgiving weekend and living alone I have been having a blast focusing just on this book. I haven't read through it all yet, still just a quarter of the way through, but I'm not trying to cram. This book does exactly what I want a book to do (as opposed to an online reference resource): stop and talk about every little thing that is really useful to know in the workflow of applications programming on an iPhone.

These guys know how to write. They don't leave the reader with presumptuous word choice and leave the reader hanging; every time they say something it's like they read the mind of the reader, "Now you might be wondering, what about... or why not do ... Well, let's talk about that." Nearly every corner is covered, and where I still have questions it's usually not directly related to the topic, i.e. I have an Obj-C question. Even then, after I return from surfing the web for answers, I return to the book and turn the page and the book says, "You should read up on this stuff at [URL]"... I kid you not, this book had me floored.

Looking towards the latter pages of the book, I can't help but be astounded, thinking, wow, I get to learn about THAT? And in the same style of learning that I've been enjoying so far? This is great!

There are very few errors, mostly just little things that the reader can spot just by paying attention. There are plenty of enough illustrations and tips to keep the reader engaged and constantly learning not just the basics but how to get comfortable in the workflow of iPhone development.

My only disappointment is that the book assumes knowledge of Obj-C, but fortunately it comes with plenty of URLs and references to complete those prerequisites as well, and really, to discuss Obj-C in detail, beyond the rather brief coverage-as-we-go that is indeed in this book, would have been beyond the scope of the book so that's fine.

There's just nothing I can say bad about this book, and everything good. It is by far the funnest technical book I've owned and cracked open in months, if not years.

By the way, coming from a C# background (and Java and VB5/6 before that), lightweight programming of the iPhone is EASY!! It's different, but it's easy, particularly compared to C++ programming which I've had a number of false starts. For me, if I can go from VBScript to VB6 to Java to C#, I can go from C# to Obj-C. Also, the workflow of Xcode + Interface Builder is somewhat analogous to the workflow of Visual Studio + Expression Blend 2 for WPF programming, if indeed event handlers would have been set up in the Blend designer in a drag-and-drop way. I must also add, learning how to develop software in Xcode forces the developer to learn MVC. I don't know why people who are used to Visual Studio programming dislike the MVC-ness of Xcode programming, but I love the change of workflow, and I think there is much to take back with me when I return to C# development.

Mac OS X: Notes On Upgrading A Bootable Hard Drive With Boot Camp Support

by Jon Davis 27. November 2008 22:27

I lost last weekend to a hard drive upgrade for my Mac Mini, the last "pimpage" I will do to this Mac. My Mac Mini now has 4GB RAM and a 320 GB hard drive (the largest I could find in 2.5" laptop hard drive class while retaining 7200 RPM), upgraded from 2GB RAM and 150GB 5400 RPM drive.

This was supposed to go smoothly. Oops.

First while doing the physical install, it was about 1:00 am. I snapped off the orange ribbon at its base--as in, permanent destruction, pins yanked from their soldered sockets. Mac Mini computers have these ribbons and they look kind of like old PATA ribbons for laptops so I was pretty much convinced I lost my computer altogether. I Googled a bit and discovered that this was an audio cable, not a hard drive I/O cable. Whew! I also discovered that you can replace the board for much cheaper than the cost of a new machine. First I ordered this and then I realized that it is probably this that broke on the opposite face so I ordered that.


Creative Xmod is a safe way to get audio back if you break your Mac Mini orange ribbon.

But I canceled both orders and realized, hey you know what, I don't need no stinkin audio ribbon in this thing. I do need audio, but I'm quite content with my Creative Xmod which works fine on the Mac.

I used Disk Utility to copy the actual bytes over from one drive to the other. OS X booted on the new drive fine, but then I noticed that VMWare Fusion didn't see the Boot Camp drive, and of course Boot Camp itself didn't work.

I think I repartitioned and reformatted at least five times over the weekend. Googling didn't seem to help, forum threads mostly led to "You have to reinstall OS X and set up from scratch," which I thought was an awful notion. Nonetheless, after so much time wasted, I started down that path. The whole time my original hard drive was untouched so I had nothing to lose.

But then the OS X installer disc refused to install. Looking it up online, Apple's site said that I have to repartition the drive using a GUID Partition table. Buried in one of the advanced settings in Disk Utility (and easily overlooked), there it was, the radio button that let me choose GUID Partition table. The default was Apple Partition table, which is intended for PowerPC computers I suppose. (WHY IS THAT THE DEFAULT IF DISK UTILITY IS ALREADY RUNNING ON AN INTEL?! EARTH TO APPLE??!) I repartitioned again, then I realized rather than doing a byte-for-byte data transfer from my old hard drive I should restore all using my Time Machine backup. Time Machine literally backed up my entire system, something I didn't expect because the Time Machine backup consumed much less space on its drive than the data on the original hard drive (even accounting for excluded files such as VMWare Fusion VMs); I guess Time Machine uses compression, which makes sense.

The Vista partition did not have a backup, though, and attempting a byte-for-byte transfer from the original hard drive failed. Vista was there but it refused to boot. I tried using the Vista installer disc to "Fix startup", "bootrec /fixmbr", "bootrec /fixboot", "bootrec /rebuildbcd", etc. (I should have looked for this rather than just randomly flip switches LOL..) I also got stumped by another problem: Boot Camp refused to give me a boot drive selector when I held the Option key down. This ended up being caused by having too many USB peripherals and a race condition resulting, so I disconnected everything except for my keyboard and mouse and it worked fine. Ten or so reboots later, I gave up, deleted the Vista partition, and reinstalled Vista from scratch. It's okay though, I wanted to claim the extra space and get a fresh OS start anyway.

This blog entry is posted from my fresh Vista partition on my Mac Mini.

Finally, I had to manually restore my iTunes Music library, including the XML files. Somehow that didn't make it onto my Time Machine backup; might be because I had excluded it, I don't remember.

 

 

Mutability, Linked Lists, and Enumerators (C# vs. Objective-C 2.0)

by Jon Davis 30. August 2008 22:22

A few job interviews ago, I was asked about the meaning and/or significance of the term "immutable". I knew that immutable means doesn't and cannot change, and that value types (numbers and strings) and structs in C# are immutable. I knew that structs being value types get stored on the stack, and, if small, tend to be more performant. But I didn't have the background to put two and two together, so I wasn't able to explain why it mattered.

I'm still trying to wrap my hands around how stack optimizations really work, actually. But meanwhile, another job interview asked me what I knew about data structures and, "if .NET had no arrays, how would you manage multiple objects"? I was shocked with myself. These were rediculously simple questions, going back to the basics of computer science. But, for that matter, these were among those rare questions that favor the value of college education, which I lack, over experience. But it takes neither college education nor much experience to suggest a "delimited list in a string" which I didn't even think about for some weird reason--although, technically, any such serialization requires an array of char or byte.

I could be wrong but I *think* the correct answer to "in the absence of .NET arrays, how could you manage a set of n objects" would be to create a linked list. Having been abstracted from how lists work for so long, I never even looked this simple thing up until now.

http://en.wikipedia.org/wiki/Linked_list

http://en.wikipedia.org/wiki/Stack_(data_structure)

Glad that's over. I feel so dumb (and no, darn it, I did NOT ride the short bus to school!!), but refreshing myself on that is finally behind me.

Anyway, back to the mutable vs. immutable discussion, the Cocoa API in the Mac OS X world makes a strong emphasis on isolating certain objects, most notably collection objects (NSSet, NSArray, NSDictionary) as either mutable (NSMutableSet, NSMutableArray, NSMutableDictionary) or immutable. They're completely different classes, that perform the same function but with different optimizations, so the immutable (unchanging) version, which is the default (lacking the "Mutable" in the name), is extremely performant.

C#'s APIs and compiler abstract this stuff so significantly that most C# developers (like me) would likely find all this really odd.

Here's the blog post that motivated me to post this. http://cocoadevcentral.com/articles/000065.php 

Incidentally, I noticed something else about Cocoa. In C#, the syntactically-ideal iteration loop for a collection looks like this:

foreach (string s in myArray) {
    Console.WriteLine(s);
}

The problem is that foreach typically has a performance hit versus using

for (int i=0; i<myArray.Length; i++) {
    string s = myArray[i];
    Console.WriteLine(s);
}

.. which happens to be fuglier. And, to be honest, it shouldn't be faster when working with lists because an indexer has to iterate through the list from the top to find the i node, whereas an enumerator on a linked list should require no reiteration. So I don't get it.

Meanwhile, though, C# 2.0 introduced List<string>, which offers the delegate-driven ForEach( delegate ( string s) { .. } );, which is far more performant.

C# 2.0:
myList.ForEach ( delegate (string s) {
    Console.WriteLine(s);
} );

C# 3.0:
myList.ForEach( s => Console.WriteLine(s); );

In C#, AFAIK, foreach internally just instantiates an IEnumerable object's IEnumerator object and then calls its MoveNext() method, but then so does List<T>.ForEach, so I don't know (haven't looked at the MSIL or Reflector) what it's doing different between the two.

But Objective-C 2.0 apparently went through a wholly different process of evolution, where its foreach equivalent is actually much faster than its enumerator MoveNext() equivalent.

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_8_section_1.html
http://cocoawithlove.com/2008/05/fast-enumeration-clarifications.html

Interesting stuff.

http://theocacao.com/document.page/510

Objective-C ~ C# 3.0

by Jon Davis 26. August 2008 10:50

Just a quickie note, as a side interest (for fun) I'm trying to get back into Cocoa development (still in newbie stage) and I'm watching the iPhone introductory videos. There's a part of one of the videos related to Cocoa Touch that had me reminded of C# 3.0.

  1. Objective-C uses delegates as an alternative to method overrides. I don't recall, outside of callbacks / function pointers, whether C/C++ supported "delegates" in the first place. But the approach taken by Cocoa here really surprised me, how significantly it looked like my Evented Methods pattern [ 1, 2, .. ] I proposed a few days ago, since technically events are just anonymized delegate invocations. Kinda gave me goose bumps, seeing evidence that I was on the right track.
    • On a similar vein, @selector returns a SEL, which is the type name for a selector but the value is just a const char* that is the method name. Selectors are good for invoking methods you don't know the name of until runtime.
  2. Objective-C has something called "categories", which I feel is a terrible name, but given the description given by the presenter in the video it sounds like Objective-C's categories are functionally the same as C# 3.0's extension methods, although not in form. So, Objective-C supports extension methods, they're just called "Categories", which, again, is a really weird name.
  3. It's easy to take C# constructors for granted. In Objective-C, the equivalent functionality is the far less elegant invocation of an "init" method (an initializer).
  4. Properties, as being different from methods, functions, and fields, are assumed in Objective-C, as they are in C#. The C# 3.0 compiler supporting the syntax of myType myProp { get; set; } as an inferred implementation of myType _myProp = default(myType); myType myProp { get { return _myProp; } set { _myProp = value; } } is actually not new to C# 3.0, either. While the form is different, Objective-C has something similar. It has a @synthesize keyword that generates the implementation code for the getter and the setter.
Note: this blog entry might (or might not) grow.

Currently rated 1.0 by 1 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Software Development | Mac OS X

Mac OS X Best Practices: Installers

by Jon Davis 9. June 2008 03:37

One of the things I really like about Mac OS X versus what I've seen in Windows et al is the way third party software gets installed. I've always heard people whine and complain about how applications for Windows should never use the Registry, should never touch the system directories, etc. In my mind, I saw such software practices as a necessary evil, and things are far worse in the Linux world, where the directories and file paths are far less predictable. I had thought these complaints were coming from Linux folks, but apparently not, they're coming mostly from Mac folks, I bet, because the Mac world has proven this stuff out.

Most apps are installed by copying the application directly into the Applications folder. The End.

Well, not quite, but that's pretty much it as far as the user is concerned. From the developer's / distributor's perspective, there are a few things to note.

  1. An application may appear as an individual file that has lots of resources embedded in it (I was a big tinkerer of ResEdit back in the day), but this is a facade in the OS X world. Applications are actually directories with a .app extension, and Finder (the Windows Explorer equivalent) treats these directories like files when browsing them, in that the folder has the application's icon, and double-clicking the icon opens the appropriately mapped executable file inside. (This behavior and other metadata is maintained with a file inside that has a .plist file extension. It's kind of like an app.config file in the Visual Studio .NET world, but it's not the same format at all.) "Power users" (or any user who's Mac savvy, or newbies like me who have experienced friends to show them this stuff) can access the contents of the folder by right-clicking (or Control + Left-clicking) the icon and choosing "Show Package Contents".
    I'm not sure yet what all goes on in here but I wouldn't be surprised if global application settings (like Windows' .ini files) can be modified here. Meanwhile, user preferences are managed in the user's home directory.
  2. Somewhat similar (IMO) to the custom folder display features in Windows' Active Desktop--which in Windows is partially incomplete on the directory/file shell level, was deprecated, and is rarely used because it was too powerful and too prone to abuse and malicious hacks, or maybe just too easy to be confusing and inconsistent in deployments--the Finder allows directories to be customized in layout and style so that when you open a CD-ROM (or disc image) and view its contents, it might appear elegantly like a running program that displays instructions on how to install (drag and drop to Applications), but really it's just a Finder view of the directory contents, with a custom background image and custom positioning of folders and files.
  3. Whereas Windows users must download Spyware-ridden Daemon Tools (even recommended by Microsoft) to mount .iso's to a drive letter, Mac OS X allows you to mount disc images (.dmg's) by double-clicking them. There is no drive letter, they just show up on the desktop and open automatically in the Finder (no annoying "what do you want to do with this?" dialogue, either).
  4. There is usually an alias to the /Applications directory right in the disk image's root folder, so basically when the customized layout displays text that says "drag and drop this icon to the Application folder", it is actually the distributed application's icon on the left, the Applications' folder alias on the right, and big, bold right arrow in the middle. (We all know what arrows mean, it's like a universal language.)
  5. Sometimes when an application gets dragged and dropped into the Applications directory, a quick script might execute. (Or, this is what a friend has told me, I'm still discovering all this.) I imagine that this allows for the initial creation of application environment settings. I'm not sure what the security or runtime constraints are on this, though. And I think--but am not certain--that this would be done in either AppleScript or Javascript.
  6. Sometimes an application needs to be installed, as in, integrated into the system. Services and developer tools are very frequently in this boat; application frameworks belong in several different directories, for example. For these situations, OS X uses a "package" or .pkg file, which is very similar to a Windows .msi file. Opening a .pkg file works much the same way as opening an .msi file, except a) I don't think it auto-detects prior installations and offers to uninstall or repair (??), and b) most of the .pkg installers that give installation path options seem to only offer hard drive selection, not folder selection. This kind of dumbs things down a bit but might be for the greater good of average users.

Here's an important documentation page I just stumbled across, and the motivation for posting this blog entry:

http://developer.apple.com/tools/installerpolicy.html

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Software Development | Mac OS X

How My Microsoft Loyalty Is Degrading

by Jon Davis 7. June 2008 16:59

I've sat in this seat and often pronounced my discontent with Microsoft or a Microsoft technology, while still proclaiming myself to be a Microsoft enthusiast. Co-workers have often called me a Microsoft or Windows bigot. People would even give me written job recommedations pronouncing me as "one who particularly knows and understands Microsoft technologies".

But lately over the last year or two I've been suffering from malcontent, and I've lost that Microsoft spirit. I'm trying to figure out why. What went wrong? What happened?

Maybe it was Microsoft's selection of Ray Ozzie as the new Chief Software Architect. Groove (which was Ozzie's legacy) was a curious beast, but surely not a multi-billion-dollar revenue product, at best it was a network-based software experiment. Groove's migration to Microsoft under the Office umbrella would have been a lot more exciting if only it was quickly adopted into the MSDN vision and immediately given expansive and rich MSDN treatment, which it was not. Instead, it was gradually rolled in, and legacy SDK support just sort of tagged along or else "fell off" in the transition. Groove was brought in as an afterthought, not as a premier new Microsoft offering. Groove could have become the new Outlook, a rich, do-it-all software platform that brought consolidation of the team workflows and data across teams and diperate working groups, but instead it became just a simple little "IM client on steroids and then some" and I quickly abandoned it as soon as I discovered that key features such as directory sharing weren't supported on 64-bit Windows. So to bring Ozzie in and have him sit in that chair, and then have that kind of treatment of Ozzie's own Groove--Groove being only an example but an important, symbolic one--really makes me think that Microsoft doesn't know what on earth it's doing!! Even I could have sat in that chair and had a better, broader sense of software operations and retainment of vision, not that I'm jealous or would have pursued that chair. The day I heard Ozzie was selected, I immediately moaned, "Oh no, Microsoft is stuck on the network / Internet bandwagon, and has forgotten their roots, the core software platforms business!!" The whole fuzzy mesh thing that Microsoft is about to push is a really obvious example of where Microsoft is going as a result of bringing in Ozzie, and I hardly find a network mesh compelling as a software platform when non-Microsoft alternatives can so easily and readily exist.

Maybe it's Microsoft's audacity to abandon their legacies in their toolsets, such as they have done with COM and with VB6. There still remains zero support for easily building COM objects using the Visual Studio toolsets, and I will continue to grumble about this until an alternative component technology is supported by Microsoft that is native to the metal (or until I manage to get comfortable with C/C++ linked libraries, which is a skill I still have to develop 100% during my spare time, which is a real drag when there is no accountability or team support). I'm still floored by how fast Microsoft abandoned DNA for .NET -- I can completely, 100% understand it, DNA reached its limits and needed a rewrite / rethink from the bottom up, but the swappage of strategies is still a precedent that leaves me with a bad taste in my mouth. I want my personal investments in software discovery to be worth something. I'm also discouraged--the literal sense of the word, I'm losing courage and confidence--by the drastic, even if necessary, evolutionary changes Microsoft keeps doing to its supported languages. C# 2 (with stuff like generics support) is nothing like C# 1, and C# 3 (with var and LINQ) is nothing like C# 2. Now C# 4 is being researched and developed, with new support for dynamic language interop (basically, weak typing), which is as exciting as LINQ was, but I have yet to adopt even LINQ, and getting LINQ support in CLR object graphs is a notorious nightmare, not that I would know but everyone who tries it is pronouncing it as horrible and massive. Come to think of it, it's Microsoft's interop strategy that has been very frustrating. COM is not Remoting, and Remoting is not WCF. WCF isn't even supported in Mono, and so for high performance, small overhead interprocess communications, what's the best strategy really? I could use WCF today but what if WCF is gone and forgotten in five years?

Maybe it's the fact that I don't have time to browse the blogs of Microsoft's developer staff. They have a lot of folks over there, and while it's pretty tempting to complain that Microsoft "codes silently in a box", the truth is that there are some pretty good blogs being published from Microsofties, such as "If broken it is, fix it you should", albeit half of which I don't even understand without staring at it for a very long time. Incidentally, ScottGu does a really good job of "summing up" all the goings on, so thumbs-up on that one.

I think a lot of my abandonment of loyalty to Microsoft has to do with the sincerity of my open complaint about Internet Explorer, how it is the most visible and therefore most important development platform coming from Redmond but so behind-the-times and non-innovative versus the hard work that the Webkit and Mozilla teams are putting their blood, sweat, and tears over, that things like this [http://digg.com/tech_news/Time_breakdown_of_modern_web_design_PICTURE] get posted on my wall at the office, cheerily.

Perhaps it's the over-extended yet limited branding Microsoft did with Vista, making things like this [http://reviews.cnet.com/8301-13549_7-9947498-30.html] actually make me nearly shed a tear or two over what Windows branding has become. That Windows Energy background look looks neat, but it's also very forthright and "timestamped", kind of like how disco in the 70's and synth-pop in the 80's were "timestamped", they sounded neat in their day but quickly became difficult to listen to. That's what happens with too strong of an artistic statement. Incidentally, Apple's Aqua interface is also "timestamped", but at least it's not defaulting with a strong artistic statement plastered all over the entire screen. I like the Vista taskbar, but what's up with the strict black, why can't that or other visual aspects be tweaked? At least it's mostly-neutral (who wants a bright blue or yellow taskbar?), but it's still just a bit imposing IMO.

I'll bet it has to do with the horrifying use of a virtualized Program Files directory in Windows Server 2008 where the practice was unannounced. This is the sort of practice that makes it VERY difficult to trust Microsoft Windows going forward at all. If Windows is going to put things in places that are different from where I as a user told them to be placed, then we have a behavioral disconnect--software should exist to serve me and do as I command, not to protect me from myself while deceiving me.

At the end of it all, I think my degrading sense of loyalty could just be the simple fact that I really am trying to spread out and discover and appreciate what the other players are doing. I mentioned before that Mac OS X is still the ultimate, uber OS, but now that I have it, I confess, I had no idea. Steve Jobs is brilliant, and it's also profound how much of OS X is open source, basically all of the UNIXy bits, which says a lot about OSS. Mind you, parts of the Mac I genuinely do not like and have never liked, such as the single menubar, which violates very key and important rules for UI design. I also generally find it difficult to manage multiple applications running at once, for which I much prefer the Windows taskbar over the Dock if only because it's more predictable, and although it violates UI principles I prefer Alt+Tab for all windows rather than Command+Tab just for applications because every window is its own "workflow" regardless of who owns it. But, among other things, building on PostScript for rendering, for example, was a fantastic idea; on the other hand, Microsoft's ClearType would have been difficult to achieve if Windows used PostScript for rendering. Anyway, meanwhile, learning and exposing myself to UNIX/Linux based software is good for me as a growing software developer, and impossible to cleanly discover in Windows-land without using virtual machines.

In other words, the only way one can spread out and discover the non-Microsoft ways of doing things, and appreciate the process of doing so, is to stop swearing by the Microsoft way to begin with, and approach the whole thing with an open mind. In the end, the Microsoft way may still prove to be the best, but elimination of bias (on both sides) is an ideal goal to be achieved before pursuing long-term personal growth in software.

Currently rated 3.9 by 10 people

  • Currently 3.9/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

General Technology | Operating Systems | Software Development | Microsoft Windows | Mac OS X

New York Times proves out Silverlight integration in a native Mac application

by Jon Davis 24. May 2008 19:46

New York Times has migrated their popular WPF-based New York Times Reader to the Mac, using Silverlight and native Cocoa windowing and application logic, and using the Safari / WebKit API as a Silverlight wrapper. (Darn it, I knew it was both doable and legal!)

http://firstlook.nytimes.com/?p=49 

It doesn't have the text flow feature that WPF was so fantastically good at, but being as text flow is rumored as "coming soon", either for NY Times' reader or for Silverlight, I'm pretty excited about the future of that. 

I blogged about the feasability of this (native, non-web cross-platform apps with Silverlight rendering) just days ago, motivating myself to outright buy a Mac since I didn't see anyone bothering to try. Now that someone has not only tried but succeeded and released a significant product based on it, I feel a little mixed -- part bummed that I didn't get to post first-discoveries, but part excited that Silverlight has potential for an Adobe AIR-like wrapper, both technically and legally.

The NY Times Reader for Mac sure isn't running on WPF, though, and it shows. The user experience is clunky and the lack of text flow is painful (try resizing the window or scaling the text). The whole thing is nothing like the WPF version, except only for the initial screenshot appearance (without interacting) and, perhaps, the actual content.

kick it on DotNetKicks.com

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Microsoft Windows | Web Development | Mac OS X | WPF

"Things OS X" link

by Jon Davis 20. May 2008 18:49

A friend gave me this link for great introductory reference to Mac OS X. This for my reference:

http://www.magicpubs.com/mac/macosx.html  

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Mac OS X

My First Mac-Ported C# App

by Jon Davis 17. May 2008 22:10

Here's a screenie of my little GDI+ (System.Drawing) based game engine ported to the Mac using MonoDevelop. The sandbox "game" instance is just some bouncing balls that collide against the walls, the rectangular blocks, and each other, with fairly realistic physics, emitting dual-light draw drop-shadows, etc. In Windows, DirectSound is also used to create stereo "bump" sound effects that make the bumping balls feel a little more realistic.

Wow, this only took about ten minutes, from "I wonder if .." to "wow, look at that, it's working!" My steps:

  • Add my home Subversion server as a SCM repostitory in MonoDevelop
  • Check out my game engine (called "Level1Engine") to ~/Documents/dev/Level1Engine
  • Watch MonoDevelop puke on the absolute UNC path of one of the project references
    • Manually add the missing .csproj file to the solution
      • MonoDevelop exits unexpectedly
    • Reopen MonoDevelop, reopen solution
    • Create a new project with the same name/directory as the broken project
    • Remove the generated sample .cs file
    • Add the existing .cs files to the project, in-place
  • Comment out the DirectSound references from the game engine class library. (Sadly, that means there's no sound yet.)
  • Let 'er rip

Overall, this blog post took me about twice as long as porting my app!

The result is not flawless, though. Rendering performance is about 1/3 what it is in GDI+ (in Windows), and apparently the 2D matrix transformations (which I had to touch for the drop shadows) are a little buggy in Mono because that text on the top left, which is rendered with System.Drawing, jiggles around erratically by about two pixels.  

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Pet Projects | Software Development | Mac OS X


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  November 2019  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678

View posts in large calendar