My side project, FileSharper, is now open source on GitHub:
https://github.com/adv12/FileSharper
You can install an alpha-quality build from here:
http://www.flamingtortoise.com/FileSharper/
There are YouTube videos here and here.
Andrew's Code
Sunday, October 15, 2017
Friday, May 1, 2015
Why Firefox Occasionally Returns Search Results from a (Seemingly) Random Search Engine
I finally figured out why Firefox sometimes decides to run my search on a non-default search engine. It only happens sometimes, and I was worried it was due to some kind of malware. But it's much simpler than that--it's all about where your mouse pointer happens to be when you hit Enter. Behold:
Here I've typed "electron" as my search term, and the autocomplete drop-down appears to show related searches. It correctly shows Google as my default search engine. But note the blue highlight there near the bottom. That's the DuckDuckGo search engine that's highlighted. But how did it get highlighted? By a bump of my mouse, which stole focus from the search box and placed it on the DuckDuckGo icon, over which the pointer happened to be hovering. I didn't make the connection until today, when hitting Enter didn't search at all, but rather opened the Search Settings in the Options window.
Here I've typed "electron" as my search term, and the autocomplete drop-down appears to show related searches. It correctly shows Google as my default search engine. But note the blue highlight there near the bottom. That's the DuckDuckGo search engine that's highlighted. But how did it get highlighted? By a bump of my mouse, which stole focus from the search box and placed it on the DuckDuckGo icon, over which the pointer happened to be hovering. I didn't make the connection until today, when hitting Enter didn't search at all, but rather opened the Search Settings in the Options window.
Saturday, August 10, 2013
Update
So I took a break from this blog, and in switching jobs I lost access to the Retina MBP about which I started a series of posts. Windows 8 on MBP is probably old news by now anyway. I may post more here if I start a new iOS app or a small webapp for work.
Friday, April 26, 2013
Tuesday, November 27, 2012
What I Did Instead of the Xamarin Contest
So I really did intend to throw together an entry for the Xamarin contest, but realistically I didn't have time in my evenings and Saturday mornings to get anything substantial built. In light of reality, it was nice to stumble across an article with a silly signature and post a Facebook status that escalated into a more suitably-scaled diversion. Here's two weeks' worth of my free time:
68 74 74 70 3a 2f 2f 62 69 74 2e 6c 79 2f 57 75 65 62 63 39
Note: I failed to test on a touch device until just now, and it doesn't work. Use a real computer.
Post your answers as comments on this entry. Hints are available, within reason. Enjoy!
68 74 74 70 3a 2f 2f 62 69 74 2e 6c 79 2f 57 75 65 62 63 39
Note: I failed to test on a touch device until just now, and it doesn't work. Use a real computer.
Post your answers as comments on this entry. Hints are available, within reason. Enjoy!
Tuesday, November 20, 2012
Mono for Mac Scripting: Rawr!
I take it all back. In the end, I'm unable to use Mono to script my little project on the Mac, because:
- I can't wait for processes to complete. I call System.Diagnostics.Process.Start(myStartInfo).WaitForExit(), but files written by the command-line programs I'm calling aren't on disk by the time I open them for processing in the next step. I read several places that you need to set UseShellExecute = false to have the process called directly rather than via the "open" command (which returns immediately by default), so I set this property, but it didn't help.
- The PNG support in libgdiplus is apparently busted. [Link here when I bother to find the blog post/bug report again.]
Saturday, November 17, 2012
Serious Mono Development on the Mac: Why Not?
I've had Mono installed on my Macs for years now. Mostly it was a novelty--occasionally I'd test some CLI or trivial Windows Forms app I'd written at work, just to see if it would run. I wrote one quick image stitching program on the Mac for a friend's wife's blog (using GDI+, which actually worked, which in hindsight I realize is pretty impressive), but I've never done any "real" C# development on the Mac, for a few reasons:
When Mono on the Mac felt like an unsupported hack (I don't really know what kind of support Novell provided), I wouldn't have thought to use C# for anything but personal tinkering. In particular, the thought of distributing a Mono app was out of the question, not because it was technically impossible, but because of point 4 and the whole packaging problem. You can't distribute a Windows Forms app to Mac users; they'll hate and shame you. The same probably goes for a GTK# app, with the possible exception of MonoDevelop. So you had to develop a Cocoa# app, which felt both unsafe and unappealing. And even if you completed one of those funky Cocoa# apps, you'd either have to somehow package it together with Mono or tell your users to go download this weird experimental Windowsy runtime platform to run your app. Since very few users would have Mono installed by default, that would mean a huge download either way, even if your application itself were trivial.
But Mono on the Mac doesn't seem nearly so wrong now. Even without Xamarin, C# on the Mac is probably here to stay thanks to the Unity folks. For GUI development, MonoMac is ostensibly a decent set of Cocoa bindings that is well supported or at least has the interest of Miguel de Icaza, which goes a long way. There's a MonoDevelop plugin with MonoMac project types, a packaging system for bundling only the assemblies used by your app, and even support for deploying to the Mac App Store. Combine that with MonoTouch gaining traction as a real solution for iOS development, and MonoMac really doesn't sound too scary anymore.
There are other perks of an IDE, of course, like automatic syntax checking (love those red squigglies), GUI access to the file structure, streamlined builds, and so on. These are all things provided by IDEs like Visual Studio on Windows and XCode on the Mac. If I'm going to do C# development on the Mac, I'm going to do it in an IDE. And that's partly why, to date, I haven't done C# development on the Mac.
When I wrote that quick C# app on my Mac for a friend, it took longer than it should have because I was editing my program in a text editor with no syntax checking or Intellisense and compiling from the command line. I don't remember if MonoDevelop existed at the time, but if it did, I was probably turned off for the following reasons:
I fired up MonoDevelop and created a Console solution. Aesthetically un-awesome, but behaviorally not unlike Visual Studio project setup. I started typing and got some lovely code completion, with a few gotchas:
All that said, I think it's good enough. Here are some things it does right:
- That's just wrong.
- I didn't have a good IDE (more on that in a bit).
- Compiling and running from the command line is gross. (Yes, I know, MonoDevelop, getting to that...)
- I mostly wanted to do GUI stuff, the Windows Forms support was only partial, GTK sounds gross because it's not native to either .NET *or* the Mac, I didn't know any Cocoa, and Cocoa# sounded like a pretty experimental hack when I first read about it anyway.
Not So Wrong Anymore
I think I've gotten past point 1. It comforts me somehow that Mono is now something of a commercial product thanks to Xamarin's work on MonoTouch, which presumably has positive implications for the desktop Cocoa bindings, etc.When Mono on the Mac felt like an unsupported hack (I don't really know what kind of support Novell provided), I wouldn't have thought to use C# for anything but personal tinkering. In particular, the thought of distributing a Mono app was out of the question, not because it was technically impossible, but because of point 4 and the whole packaging problem. You can't distribute a Windows Forms app to Mac users; they'll hate and shame you. The same probably goes for a GTK# app, with the possible exception of MonoDevelop. So you had to develop a Cocoa# app, which felt both unsafe and unappealing. And even if you completed one of those funky Cocoa# apps, you'd either have to somehow package it together with Mono or tell your users to go download this weird experimental Windowsy runtime platform to run your app. Since very few users would have Mono installed by default, that would mean a huge download either way, even if your application itself were trivial.
But Mono on the Mac doesn't seem nearly so wrong now. Even without Xamarin, C# on the Mac is probably here to stay thanks to the Unity folks. For GUI development, MonoMac is ostensibly a decent set of Cocoa bindings that is well supported or at least has the interest of Miguel de Icaza, which goes a long way. There's a MonoDevelop plugin with MonoMac project types, a packaging system for bundling only the assemblies used by your app, and even support for deploying to the Mac App Store. Combine that with MonoTouch gaining traction as a real solution for iOS development, and MonoMac really doesn't sound too scary anymore.
A Real IDE
Realistically, I'm not going to do any serious coding without an IDE. One of the things that makes .NET such a productive platform is its discoverability via IDE tools. In C, how do you learn what you can do with a string? Get a book? Google "string manipulation?" In C#, how do you learn what you can do with a string? Type a period after the variable name or string literal. I'm productive in typed, object-oriented, garbage-collected languages not just because of the high-level abstractions provided by the languages but because the typing system, object-orientation, and garbage collection all lend themselves to library design where all functionality pertinent to an object can be accessed via a method on that object. This means I don't need to know an entire library before I start working with it or interrupt my workflow for an internet search every time I need to call a new method. I do a quick Google search for a "starting point"--the main class of interest--and Intellisense my way to a working program. This is huge.There are other perks of an IDE, of course, like automatic syntax checking (love those red squigglies), GUI access to the file structure, streamlined builds, and so on. These are all things provided by IDEs like Visual Studio on Windows and XCode on the Mac. If I'm going to do C# development on the Mac, I'm going to do it in an IDE. And that's partly why, to date, I haven't done C# development on the Mac.
When I wrote that quick C# app on my Mac for a friend, it took longer than it should have because I was editing my program in a text editor with no syntax checking or Intellisense and compiling from the command line. I don't remember if MonoDevelop existed at the time, but if it did, I was probably turned off for the following reasons:
- It's GTK. Ugh. Nothing against GTK *on Linux*, but this is my Mac and you're making it ugly. Not even because GTK is especially ugly, but because you're clashing with the rest of my system.
- The non-native L&F leads me to expect non-native behaviors (awkward keyboard shortcuts, swapped button order in dialogs, etc.). Basically I expect the developers to make it Mac-like only as a half-hearted afterthought. Seriously, if you expect me to Ctrl-C for Copy on my Mac, we're done.
- I've used enough OSS GUI apps to keep my expectations really low.
I fired up MonoDevelop and created a Console solution. Aesthetically un-awesome, but behaviorally not unlike Visual Studio project setup. I started typing and got some lovely code completion, with a few gotchas:
- Code completion is case sensitive. Gah! I can't tell you how many times in an evening I typed "System.io<TAB>" and ended up with "System.IndexOutOfRangeException." Hopefully there's a setting to configure this. If not I may submit a feature request. They'll probably just tell me I'm spoiled by VS.
- In general it appears pickier than Visual Studio, especially VS 2010+, which match any text within a suggestion, not just the first word.
All that said, I think it's good enough. Here are some things it does right:
- Project creation and organization is nice.
- Build and run works as expected, with configurable "Custom Execution Modes" for saving lists of command-line arguments and whatnot.
- The keyboard shortcuts are correct! It behaves like a native Mac app for the shortcuts I use frequently, and that's enough.
Better Than the Alternatives
What I realized tonight was that developing a quick C# console app in MonoDevelop was my best choice for the task at hand. I had lots of scripting languages to choose from, but I know C# better and I have a decent environment for writing and running it, so why not? I'm thinking about how this logic extends to real Mac GUI development. If the Cocoa bindings are decent, MonoDevelop is an acceptable IDE (XCode is certainly nothing to write home about anyway), and C# beats the pants off of Objective-C. There's a real developer community around the iOS stuff, and presumably there's some trickle-up to the Mac. I don't have the time or interest to get good at Objective-C, but I could see learning enough of the Cocoa API to string a GUI to some good, sensible C# model/controller code. Mono might actually get me developing for the Mac.
Subscribe to:
Posts (Atom)