Posts Tagged ‘os x’

File Open Dialog in Cocoa

The Objective-C code from Rick’s World,

int i; // Loop counter.

// Create the File Open Dialog class.
NSOpenPanel* openDlg = [NSOpenPanel openPanel];

// Enable the selection of files in the dialog.
[openDlg setCanChooseFiles:YES];

// Enable the selection of directories in the dialog.
[openDlg setCanChooseDirectories:YES];

// Display the dialog. If the OK button was pressed,
// process the files.
if ( [openDlg runModalForDirectory:nil file:nil] == NSOKButton )
{
// Get an array containing the full filenames of all
// files and directories selected.
NSArray* files = [openDlg filenames];

// Loop through all the files and process them.
for( i = 0; i < [files count]; i++ )
{
NSString* fileName = [files objectAtIndex:i];

// Do something with the filename.
}
}

I was actually messing around with Monobjc and wondering how to work with NSOpenPanel, the code above provided a bit of a starting point for me. Here’s my code, which is not a translation of what’s above, but gives an example of how things work with C# and Monobjc,

NSOpenPanel openPanel = new NSOpenPanel();
openPanel.AllowsMultipleSelection =
false;
openPanel.CanChooseFiles =
true;
openPanel.CanChooseDirectories =
false;
openPanel.SetContentSize(
new NSSize(600, 600));

int dialogResult = openPanel.RunModal();
if (dialogResult == NSPanel.NSOKButton)
{
picFileName = openPanel.Filename.ToString();
}

The properties are self-explanatory and the code is simple enough, so I won’t bother with any sort explanation.

Mono PlatformID on MacOS X

Unfortunately, the method mentioned in the Mono Technical FAQ, where you can check System.Environment.OSVersion.Platform for a value of 6 doesn’t work (as of Mono 2.6). I got the following code from this thread, which works well enough,

[DllImport("libc")]
static extern int uname(IntPtr buf);

static bool IsRunningOnMac()
{
IntPtr buf = IntPtr.Zero;
try
{
buf =
Marshal.AllocHGlobal(8192);
if (uname(buf) == 0)
{
string os = Marshal.PtrToStringAnsi(buf);
if (os == "Darwin") return true;
}
}
catch { }
finally
{
if (buf != IntPtr.Zero) Marshal.FreeHGlobal(buf);
}
return false;
}

Mono Winforms on OS X

Despite some issues, my experience porting .NET C#/Winforms 2.0 code to a Linux system running Mono was surprisingly pleasant. Unfortunately, the same cannot be said for porting to OS X. Put simply, Mono Winforms on OS X sucks… it sucks bad… to the point where I question why it was even released.

fragmentsync mono winforms issues

The biggest and most apparent issues seems to be visibility and z-order issue. The image above is a form containing a few panels, however, only the panel containing the green header and the “sync with” label should the displayed. The others should be invisible (Control.Visible = false). Furthermore, making one control visible and another invisible or bringing a control to the front (Control.BringToFront()) such that it obscures others is a crapshoot; sometimes it’ll work correctly, other times you’ll see the correct control briefly before it disappears and your staring at a control that should be invisible or obscured.

Performance is atrocious. Winforms itself, even under .NET on Windows, is not a terribly high-performance windowing system, but it’s unbearable under OS X, to the point where you can see very prominent visual delays as events are processed and/or controls are being rendered.

Stability is awful. It’s not uncommon to reach a point where the application’s UI simply freezes up and no longer responds to events. Worse yet, disposal of Controls don’t seem to occur properly. I’ve noticed this on dynamically created controls, on a few occasions; clicking a control resulted in a crash because the control had already been disposed, but the control was still, incorrectly, being rendered in the UI and responding to events (hence the crash).

All of these problems seem to point to an issue with Mono’s per-windowing system driver for OS X. The Mono Project Roadmap indicates an upcoming Winforms update for OS X this September with the Mono 2.6 release, hopefully, it’ll address these (and I’m sure other) critical issues, so that Winforms can become truly cross-platform. As of right now, if your looking to use Mono Winforms as a solution for porting to OS X, you’ll likely only be able to pull off a port of the simplest of applications.

On a side note, Cocoa# looks like a pretty interesting project, but the website hasn’t been updated in months, so it’s possible the project is dead.

The Initial User Experience: Dashboard vs. Yahoo! Widgets

I recently got a Mac Mini and begun playing around in OS X. One of the first things I stumbled upon is Dashboard, which brings up an overlay displaying widgets, small apps that display things like weather, time, calendar, etc. I thought this was incredibly cool (especially because of the weather widget, as I hate going to weather.com and having to type in my zip code every time I want to know what’s happening outside). As a feature it’s very well designed; it looks great, it’s easy to get to, it didn’t pollute my desktop in any way, the information was useful and informative, and in less than a minute I implicitly understood how it worked.

I figured there must be something similar for Windows, if not I was even thinking it might be a fun project to make something similar. I did try Google Desktop a while back, but the experience was not the same, and was definitely not pleasant. I didn’t like that it was essentially a panel (a large one at that) pasted into a corner of my desktop. I like my desktop. I want my stuff on it. I don’t want to cede the real estate to a third-party. In the end, I uninstalled Google Desktop, and was left with an overall negative impression of the product. I haven’t used Vista as much, but the Vista sidebar seems to make the same mistake.

After some searching I found Yahoo! Widgets. It seemed perfect. However, after I installed it, I was disappointed, it looked cool, but it didn’t seem to function like Dashboard at all. After some twiddling I did finally massage it into working akin to Dashboard; however, I been less patient or not as tech savy, I would have quickly uninstalled it and deemed by discovery worthless.

So, what’s the point? The point is pretty simple (and I don’t think I’m breaking new ground here): the initial experience a user has with a piece of software is vitally important and if the developer fails to provide a positive experience to the end-user after setup, the software is a failure (users will simply uninstall it), no matter how cool the interface is, the potential productivity gain, or the hundreds of cool features. My experience with Yahoo! Widgets and Dashboard exemplify this perfectly.

So what’s wrong with Yahoo! Widgets? Technically, I don’t think anything is wrong with it. It seems stable, powerful, has nice features, and the widgets seem cool (personally, I really only cared about the weather and a calendar). However, after installation, it stuck this dock panel on my desktop along with a bunch of widgets. Now, as I already mentioned, I hate things assuming they have the right to pollute my desktop. Ownership is important. So I was not a fan of the dock nor the widgets themselves, which, unlike the dashboard widgets, didn’t fade in and out with an overlay. This was annoying. I wanted my desktop back.

So I went to preferences and found out I could press F8 to active the overlay. Great! (however, I’m going into the Preferences window to actually figure this out – why wasn’t this mentioned sooner). The overlay shows up, kinda disappointed that the taskbar isn’t covered, but I can live with that. I deactive the overlay. damn! the dock and widgets are still stuck on my desktop.

I play around in the Preference window for a while and look at the options for the dock. I discover I can get rid of the dock, that’s good, but I’m thinking this isn’t for me, and about ready to uninstall.

I continue playing around. With the overlay off, I close all the widgets. I accidentally hide one of them. I hit F8. Wait! That’s the effect I wanted! But what did I do? I realize that there are 2 options to get rid of a widget, Close and Hide. Close gets rid of the widget altogether and Hide only show the widget when the overlay is active. Why didn’t I know this, like the F8 key, this was never explained to me (remember me, the end-user, the one using the product). It’s not in the product tour, there’s no tooltip, and I certainly didn’t spot anything in the help.

I’m happy now! I customize the system to show the widgets I want and I hit F8 whenever I want to see them 🙂

So that’s the story. Ultimately, from my experience with both applications, I learned:

  • The desktop belongs to the user, don’t pollute it unless they allow you to. (this might be more of a personal preference than anything else)
  • Present important app-specific information ASAP and make things as intuitive as possible. Avoid having users discover features by reading documentation or going into a settings/preferences window.
  • The initial user experience is important. Don’t fuck it up.
yahoo widgets

I do realize there is a bias here as I was looking for something that functioned like Dashboard, but if the default post-setup environment for Yahoo! Widgets is how the developers see others using their application, that seems totally weird to me because it’s assuming a whole lot of users have so much free space on their desktop that they’d obviously want to stick a bunch of widgets on it. Hmm, I don’t know, maybe I’m wrong and most users do have a lot of free space on their desktop, but my desktop certainly doesn’t fit into this category, and even if it did, I’m not sure I’d want a widget on it (I like my wallpaper).