Variable (a.k.a Properties) in Visual Studio's Deployment Project

I use Windows Installer Deployment in Visual Studio. It's simple to use and make quite a decent installer and it's good enough. It is basically wrappers and helper-tools around the native Windows Installer service in Windows. However, having start directly using the helper instead of the native one makes me occasionally wondering how to do certain things in the IDE tools which is quite obvious in the native ones. I guess, it's the usual case of convenience versus completeness of using helpers/wrappers/tools versus the native support.

One of the important case of this is when I wanted to write to the registry using some dynamic value (e.g: Destination Path which will be decided by user later) instead of the hardcoded one. I can't find an info on this on the visual studio help on the IDE part and only after some searching around that I got into reading the native Windows Installer service documentation on the "Wind32 and COM Development" part of MSDN. There's a thing called Properties that I could use for this kind of problem. In this case I would need to use "[TARGETDIR]" which later would be substituted on runtime with the installation path.

So, I guess the lesson is when something not clear on the tools/wrapper level try looking on the native/lower level.

Building and Customizing ff-activex-host Browser Plugin

I need to use ff-activex-host, "An NPAPI based plugin for Firefox that enables the use of ActiveX controls", to enable me to build firefox's browser plugin using activex (for simplicity reason). It's a very helpful bridge without which we need to write different code for different browser.

We need to customize and build the plugin ourselves to be able to use it in a secure way i.e: avoiding any arbitrary activex can be run. Here's the main documentation on building. I find it still too general and requires us to build firefox source which takes a long time. After collecting some infos on the project site, forums and after some "fun" trial and error (including building the firefox source which is a bit painful and still not work in the end :) ) I finally able to build it in a less painful way. So, here's the summary of the steps that got me to it :

• Checkout ff-activex-host source
• Get the latest firefox source from here. Follow the instruction there to get the path to the latest source, in my case it's : ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.5.5/source/firefox-3.5.5.source.tar.bz2
• Get xulrunner-sdk from here. I downloaded the one titled "Gecko 1.9.1 (Firefox 3.5)"
• I used Visual Studio 2005, so I need to update the .sln and .vcproj file of the original source of ff-activex-host which is a Visual Studio 2008 ones. Here's the article on how to convert vs2008 solution and projec file to vs2005. In my case, I only changed "Version="9,00"" entry to "Version="8,00"" in the .vcproj file, make a new blank .sln file and mount the updated .vcproj file and it works straight away
• Change the additional include directories in ffactivex project as follow : change any "c:\src\mozilla\objdir\dist" to your xulrunner-sdk path, change the rest of "c:\src\mozilla" to firefox's source path. Here's the discussion that mention it somewhere in the middle, if you're interested.
  
• Build the solution

To make an installer for the plugin, here's the summary :

• Install Inno Setup (isetup-5.3.6.exe as of this writing) and it's QuickStart Pack (ispack-5.3.6.exe as of this writing). You can download them here
• Use ISTool to open "install\ffactivex.iss" and update the line
  #define xbasepath "c:\src\ff-activex-host\ff-activex-host\"
  to the directory where your solution file reside
• Compile and run the installer script

You should now see the "Activex hosting plugin for Firefox" on your browser's plugin list.

This path is basically just replace the step of compiling the firefox's source in the formal documentation with using xulrunner-sdk, adding some technical details and stuff specific to my situation.

To Flip or not to Flip, Image Orientation in Directshow

Here's a good insights regarding the cases where you need image flipping when coding filter in Directshow. There's quite lengthy narration on the history and the details on the article, but here's some important point :

• Some Color Format use top-down orientation (the start of the image is on upper-left corner, e.g: RGB) other use bottom-up (start from lower-right corner, e.g: YUV)
• The given height value show whether the image follow the orientation. Positive means the data follow the orientation, negative means it is inverted

With that two point in mind you could decide when to flip it or not. For example, if you need image with top-down orientation and got RGB with positive height value (means it's bottom-up oriented) you need to do the flipping while if the height value is negative (RGB but with top-down orientation) you don't need to.

Using Workrave

I am a user of a Workrave for sometime now. I was once having a quite disturbing eye-strain that made me need to rest from computer activity several days. I decided to avoid to have to gone through it again and it was the time workrave starting to be on my desktop (with RSIBreak as it's counterpart in KDE one).

Workrave is the kind of the application that you need to tweak a lot to be really effective. It tends to break my flow in my early use. I am quite used to it now and the break has become more natural and less distracting. Here's the current setup and convention that I use currently (note : I do mainly programming/software/research work) :

• per 15 minutes microbreak. This correlate nicely to one simple microtask, so when it hit it usually near the end of the task or start of the new one. This way, the break can also be used for retrospecting on what currently being done or the next thing to do. The trick with microbreak is not to treat it as a break where you put everything down, but as a short pause where you still hold your current memory on your mind but let your eyes, breathing, brain and muscle rest and stretch
  
• per 1 hour reast break. One small task is usually within 1-hour boundary and even for 2 hour or more task, 1 hour break and evaluation is a good way to keep it focused. For this kind of break, I walk around, do some stretching or just get outside
  
• no daily limit set :)
• skip break button is active but not to be pressed. I was once doing skipping a lot that it become a habit. This kind of usage is really missing the point of using it at all, so I deactivated skip button after it. However, after sometime, think it's better to have it available for emergencies. I activated it again but with a stricter use this time
  
• postpone button is active, set to three-strike rule. I don't think postponing break should be disable if you want to have minimum distraction to your working flow. I rarely postpone on microbreak alarm but quite often on rest-break. The reason is that you need to align task completion and/or setup necessary context-switching to be able to have effective long break which is quite useless if your mind is not cleared yet
  
• idle-detection is on. I find that if idle-detection is off the break is really distracting and could hurt productivity and flow. The reminder would popup while I am thinking and doing nothing on screen.
  

Using break-reminder application is not as simple as I first think but it's quite worth it. The above list has been stable for quite some time now. I find it quite suitable for my work-style and I haven't had eye-strain incidents lately so I guess it's on the right area of balance. You might find it suitable with yours or you might not, but the bottom line is to search the one really suitable for yourself.

Use Personal/Manual Clipboard while Coding

Coding involve lots of copy/cut and pasting and many of those are hard or confusing to do if you are relying only on unseen standard clipboard buffer. You need more powerful clipboard function that only full text editor can provide.

I find it helpful to use text editor as "manual" clipboard when coding and only relying on standard clipboard for only the tiniest need. I personally use JEdit for that, as it is also my all-purpose text-editor, but any text-editor will do. I use it liberally to put everything that has transient existence there. Here's some example when it can helo:

• changing system's environment variable like PATH. I copy paste the current one to JEdit twice and edit and paste back the second one (much easier than to have to edit it on the dialog box like on Windows), the first one is for backup when something goes wrong
  
• edit critical code. I copy paste the existing one to JEdit before editing the one on the IDE. I do this for relatively long code piece while for short ones, I do my safe-coding on it.
• store frequently-referenced code. There are part of code that you frequently need to refer to while you code on several places e.g: important struct that being passed around everywhere. I copy it to JEdit for convinient referring. You will need to have dual-monitor setup to have this felt really useful although switching between JEdit and IDE still a bit faster then switching back and forth within one IDE
• copying several piece of code on several places and not exactly the same everytime. I wouldn't want to do it without having text editor to buffer code pieces for this. This kind of coding task is probably the fastest way to confuse your mind and ruin your day :), you need strategy and buffers to do it safely and, hopefully, fun
• editing build config. Build config usually needs a lot of copy and paste and although you could do it using system's clipboard you will find that editing and storing related part on the text editor first will ease the task a lot. It will minimize jumping and recopying that will almost certainly happen often
  
• cutting code that you are not really sure you want to see that part you cut is gone forever (beyond the recovery-limit of undo)
  

That's just some of what I can think of right now, there will be lots of other cases you will find much easier to do if you remember you can always buffer it to text editor first.

The more powerful text editor will help you even more relative to less powerful one, you will have all the leverage that the text editor have as the leverage of your "manual" clipboard too like syntax-coloring, structure parsing e.g: SideKick in JEdit, autosave.

You could think your text editor as a side kick of your IDE, it shares the burden and make coding less burdensome.

Boost's program_options versus TCLAP

I have upgraded Boost to 1.37 and I feel like trying the program_options (po) part. I wrote about TCLAP sometime ago and pretty happy with it so far, so I would like to see how this boost's one compare with it. If it works well, I will consider replacing tclap with it and have less scattered dependencies since it is part of boost.

However, after the first compile, I don't feel like it's going to replace tclap for me, at least not for simple-to-middle argument parsing needs. Here's the comparison.

Adding Arguments

Here's in boost's :

po::options_description desc("Allowed options");
desc.add_options()
("help", "produce help message")
("compression", po::value<int>(), "set compression level")
;

and here's adding option in tclap :

CmdLine cmd("myProgram", ' ', VERSION);
ValueArg<int> arg0("","arg0","Description",true, 0, "Type Description");
cmd.add( arg0 );

which is more comfortable to me. The boost's one look a little counter-intuitive (in standard C++/OOP way). Here's from the documentation on why it has the form like that :

The add_options method of that class returns a special proxy object that defines operator(). Calls to that operator actually declare options.

I could live with a little hackery and magically-looking code, in fact sometime I like this kind of thing, so I could tolerate it a bit, but the next difference put me off.

Parsing and Accessing Arguments

Here's how you parse and use the arguments in boost's :

po::variables_map vm;
po::store(po::parse_command_line(ac, av, desc), vm);
po::notify(vm);

cout << vm["compression"].as<int>();

and in tclap :

cmd.parse( argc, argv );
cout << arg.getValue();

I doubt that I need to explain why the second one looks better, but here it goes anyway:

• the type info is no longer needed to be typed since it is aumatically resolved
• I have direct access to the arguments instead of having to access it through argument map data structure
  
• overall easier syntax

Of course, if you look into it more thoroughly, boost's po is a much more robust and powerful argument parser. If you make something like compiler or a program with tons of tweakable configurations, it will be a very handy tool in your hand while tclap might probably push you to make workarounds and compromises. Still, in general case, I would use tclap by default unless there's a hint that I need to use boost's po instead.

Some note on code snippet :

• I don't use exact one-to-one variable naming, just conviniently and lazily copy-paste them, but the general idea is more or less the same
• no error/exception handling shown, but both use quite similar try-catch scheme

Multipanel in AllinOne Sidebar Extension in Firefox

I find Multipanel when I installed Firefox's All-in-One Sidebar extension. It opens up the page what you currently viewing right now on the sidebar in single column view by default. It is very useful when you want to have certain page to be sticky like when the page is in a referential nature.

However, the very good thing about it is that it opens up any link that you click on that sidebar on your current main tab instead on itself. One really major use that I find for it is when opening a page with some kind of table of content on top that has links to anchors within the same page or links to other page. Without it, I have to switch back and forth within the same page or switching between tabs which is distracting and break the focus. With Multipanel, I just load the page on the side and click the links from there, very handy.

What does Visual Means in Visual C++

Visual in Visual C++ does not neccessarily means because you can do your programming by manipulating graphical symbol ala Model-Driven stuff or design GUI using designer (although now you could much more conviniently than on the age of Visual C++ 6.0). It seems to me it means more that :

You can not do development with it (at least not conviniently) without mouse.

I do my early work using gcc and vi, console/xterm (it's kterm in KDE). With that as a background I don't question much the "visuality" of Visual C++. To me, it basically means visual in the way that it is a graphical IDE as oppose to a console/terminal-based one. I think that will put our expectation in a more apropriate place.

The confusion probably comes from the fact that it is bundled within Visual Studio where you have Visual Basic/C#/J# in it that have more "visual" feel to it i.e: start new windows forms project, add buton, double click the button, add code within event handling skeleton, add more widgets, add more event handlings and so on.

To Use or Not to Use Libraries

My work lately reminds me of a comment on Slashdot long ago about the use of library. I did not keep the link of it but it goes something like this :

1. When you make a code that will be (re)used by other developers e.g: libraries, components, avoid using third party library/framework whenever possible
   
2. When you make an application that will be used by the end-user, do use libraries freely as you needed as long as you bundle them in your installer/package
   

I think it's a good guideline.

The first item make the second one possible. If library developers use third party libraries liberally, the application developer would have to bring all those burden along with him including potential conflict with other included libraries, and it's dependencies, and it's dependencies of dependencies. Well, you get the idea.

Setting up Environment for Directshow Development

We were upgrading our Directshow SDK since it is felt a little outdated now. We were still using the one from the age where it is still under DirectX SDK. There's currenlty nothing felt wrong or there were errors, we just would like to have it not too far from the latest release available to avoid the code stuck too long in the past.

The needs :

• Multimedia Application Development : need standard Directshow library
• Filter Development : Directshow Baseclasses would need to compile

To fulfill those, The current state of available SDKs from Microsoft require me to install two separate (and large) package, that is :

• Microsoft Windows SDK : to access what is considered to be standard feature available in Windows. Apparently, now Directshow is considered standard so it is included in this base SDK while it used to be under Directx SDK.
  
• DirectX SDK : you could only do straightforward Directshow development like file playing using Windows SDK, you need another package (below) if you want to access the complete API in Directshow since some headers from DirectX is still needed when accessing more complex part of the Directshow API. You'll see why it is needed below.
  

My existing setup is Visual Studio (VS) 2005 Professional SP1 on Vista. I have also Visual C++ 2008 Express installed.

A good page for all things Windows SDK can be seen here. It contains a list of existing downloads, the latest available together with the previous ones, and there's also links to supportive materials i.e: forums, related SDKs and downloads.

I started with installing Windows SDK 7 since it's on the top of the download list (It is cutely-named "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: BETA"). The download took a while, and you better have something else to do rather than waiting for it. The installation went long also but finish well. I checked the VS and it seems it's not registered yet despite the release notes say that if you install the SDK after you have the VS installed it should register itself. Simple enough, there's Visual Studio registration tool on the Program Menu to do it semi-manually.

It does not work, however, at least not with VS 2005. When I try to build a simple player, it complained about Strmiids.lib debugging information corrupt. Testing with Visual C++ 2008 Express prooved succesful. After googling around, it seems the error usually come when the SDK no longer support certain compiler. So, I get the next SDK on the list (6.1, a.k.a "Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5") and do some more waiting...

Long story short, it fixed the problem, I could build the simple Directshow application with it. But to make something more complex you'll get into trouble with dxtrans.h not found. So, according to this, I need to download and install DirectX-SDK-August-2007. So, time to download and wait some more...

After the install (it automatically register itself to VS), It directly fixes the problem and unlike being said on the webpage linked above, no manual copying of files needed.

Now the development environment ready for some "fun" time with Directshow. Hopefully, no more waiting for SDK downloads needed.

The Need to "Catch" Emerging Task While Coding

Coding is a thought-consuming task and that makes the utilization of the brain very high which leaves little space for anything else including other coding task. So, if programmer has another task that come up in the middle of doing a coding task, it is most likely that he will get overwhelmed.

I think this is where the perception that programming is hard comes from, at least one from many other reason. There are just so many things that should be put in the brain's RAM. There are lots of abstraction and associations to keep in mind at the same time. However, knowing this we could make it less hard by not putting too much of it in our brain.

Let's illustrate a little. Let's say thought capacity of our brain is a 100. If a thought-consuming task takes 80 then we only have 20 left, so there's no way another 80 point task could fit in there or anything not under 20 for that matter. To make things flowing, just keep the brain from being too occupied. Keep what's in it within manageable (and fun) amount. In short, keep it sustainable.

We then need to put the surplus aside first and this is why programmer need system and discipline to do this in effective manner. I don't think we can do middle to large programming task without some kind of checklist to keep the subtask in order and cath the emerging tasks along the way. We need to only allow stuff related to current "theme" in our head and push others out of it immediately to other system before our brain start the chain reaction of spawning the emerging thought (or distraction) into someting that disrupt or flow of thinking. We could revisit this buffer afterwards, prioritize and pick the next task.

The system could be pencil and paper, text editor or, in my case, mind mapping application. It doesn't matter as long as you can depend on it as thought-catcher i.e: simple, instant entry and keep your mind clear on one single task.

There's one "sacred" principle here : There should always be task. If the task, when you work on it, proven to be insignificant or false or you find that it should be something else, do something about it first before doing something else. Cross it, rename it, whatever as long as you don't just uncounsciously forget it. One forgetting could lead your mind to wandering state and after some unproductive time you end up with "mmhh, what am I trying to do just now?". Don't let our mind do the thinking just for the fun of it. We are not maintaning our mind, give it good food and rest, just so it can have fun by itself aren't we :).

I find that being really strict to just doing one, relatively small, very concrete, well-defined thing at one time help in get more programming task done (meaing more feature added, bug fixed, etc... as oppose to more mess :) ).

Pocket Freemind, Continuing After 0.5 Release

Below are my updates on Pocket Freemind project, after the last 0.5 release. I just code away for a while, seeking to see how some ideas will be in concrete form. Now it seems apropriate to take a break and write some notes and update about it.

• The extraction of libPocketFreemind and new-more-modularized GUI. I've extraced the object model and start a new GUI on top of it to allow more flexibility to enhance more the user interface. The original GUI is still intact sharing the same libPocketFreemind (which extracted from it relatively painless) .
  
• Soft-key menu is back, complemented with custom toolbar. Standard .NET CF toolbar makes the standard soft-key unusable so I make the custom toolbar that does not interfere with it. I use picture box, panel, imagelist and a little hack. Hopefully user would still feel it as a toolbar :).
• Individual color picking instead of predefines set of style. There is now color picker for node's font and background color. Thanks to TamPPC for the code. Node style would be revisit later with editable style list.
  
• Dialogless note window. It use splitter to share screen with the map's View. It is now looks more like Freemind on the desktop. I think this way the note can be more useful and more comfortbable to enter
  
• Icon dialog updated. It now has (emulated) upper right close window button
• More align with the desktop version. The menu, term, bahavior use the desktop version for reference as long as it still makes sense. The special case of pocketpc should be considered too of course.

I guess that's it for now. Now, to close, it's time for some mandatory screenshot. Here we go :



The new note view with resizable splitter. It synched as the node is navigated. There is the node with individual color and background too.


The above is the new look of icon dialog.


And here is the new color picker. The base code is in vb. I wrapped the code relatively as it is in user control (adding an event handler), put it in a dialog, add a preview, and use it in c# project (the benefit of multilanguageness of .net :) ).

Thankfully, it came at the right time, there used to be only commercial color picker component around.

Using JEdit for AutoIt Development

I work with AutoIt today and as a JEdit user, I feel reluctant to install another Text Editor just for it. So, I searched around for JEdit-based solution. Some searching around later, got me this link. It is actually a frame from this site, I shortcut it here since it's not that obvious if you go from the main page.

It took time to follow all the instruction, even to the point I doubt whether this is all worth it :). Hopefully it will be integrated with JEdit's built-in plugin manager later for seamless installation. However, it works nicely in the end and my JEdit setup now very comfortable to work for the task.

Using Custom Action in Visual Studio 2005 Deployment Project (under Vista)

There are some quirk using Custom Action in Visual Studio 2005 and if your development machine is Vista you have even more trouble to sort. Here are what I faced recently :

• Unhelpful error message. See : "Windows Installer fails on Vista with 2869 error code.". In my case, I just run the resulting installer in an XP machine to get more informative message.
  
• When you add Custom Action for Commit phase you need to include your Custom Action Library to Install phase although you don't do anything on it e.g: override it. If you don't do this it you will have error can not save state or something. More about it here.

Thanks to google, the solutions are only one (or several) search away.

Using Directshow in .Net : DirectshowNet vs. C++/CLI

There are two usable option for using Directshow in .Net so far (excluding the abandoned-managed-directshow) :

1. Purely in .Net using DirectshowNet : code -> directshownet
   
2. Get a little bit dirty using C++/CLI : code -> c++/cli bridge-> directshow

Having tried both, I prefer using the second one for several reason :

1. You don't need to translate between what's on the directshow manual with what you need to write. On many cases you could just paste and code many boiler plate code as is and it just run. Using directshownet you have to do some mental gymnastic to do it.
   
2. Debugging would be more comfortable in native language.
   
3. You can hide the complexities of Directshow/COM exclusively in native code and have your managed code stay clean. You'll most likely end up with three layer modularisation : .net code -> c++/cli -> native c++ that access directshow. In the middle layer (c++/cli) you could provide your managed code with clean interfaces using native .net construct e.g: Properties, Event Handler.
   

However, the downside is quite obvious : you need to be comfortable with C++.

To sum up : You'll do better using C++/CLI when :

• You already familiar with C++
• Want to make application rapidly utilizing .Net

Although for those who still does not like to bother with C++/C quirks and overhead/headaches e.g: builds, linking, compilations, DirectshowNet route can provide more convinience with a "little" cost of translation and more "shady" debugging.

The better option from all these would be a .Net library that encapsulate Directshow in a more .Net-friendly way, not just a collection of "typedef"s. An even better one would be a much friendlier multimedia framework (assuming currently directshow's existing codecs and filters ported there too :) ).

Summarizing (Heavily) the Use of Event Handling Framework in .Net

I have been doing lots of code using callbacks recently and it happen to be in .Net (C#). I need some time to get used to the term, conventions and helpers that is available in .Net but in the end it is actually quite convenient with lots of predefined construct available.

Here's to sum things a little :

• For "raw" callback there's delegate. It's only a little higher than C's function pointer i.e: provide type checking.
• Above it there's event construct. It restricts delegate so the client can only add and remove itself to it but not others. Having that restriction it can now be viewed as broadcaster-subscriber model implementation (or signal-slot in qt term).
• Now, it gets more interesting : there are predefined Event Handling Framework that can be used so I can save some typing and maintenance. For typical purpose, you could use default non-generic version. What you need to do is declare the Event on the broadcaster :
  
  public event EventHandler SomethingHappen;
  
  and on the client, make the handling function based on the predefined argument pattern,
  
  private void OnPlayFinished(Object sender, EventArgs e) { ... do work... }
  
  and subscribe it somewhere :
  
  broadcasterObject.SomethingHappen += OnPlayFinished;
  
  This is what being used throughout WindowsForms-related code in VisualStudio that we could use for our own purpose too.

Doing callback-related code has already quite mind-occupying so useful help like this is very much welcome.

Get Current Position On Encoding in Directshow

When doing encoding in directshow, getting the current position (needed when you want to show progress of current encoding process) is not as obvious as for playing. I try to use the code from playing operation first i.e: get IMediaSeek interface and do GetDuration and GetCurrentPosition, but the progress is very inaccurate. The graphedit behave inaccurately also.

I found the solution later after some browsing around in Directshow help. To summarize, the solution/explanation :

IMediaSeek you got from Graph only accurate for playing operation. For file related e.g: on encoding operation, get IMediaSeek from AVIMux instead of the Graph.

The rest are the same with playing.

Children and Human's Low Level API

One of the privilege you got from having children (I have two myself) is you got the chance to see layers of human behavior API. It is exposed incrementally so you got the chance to differentiate which one is inherent to every human, what is character. If you have more than one you have even greater chance to compare things and search for invariants.

I see for myself how certain characteristic are already within a person without us do anything special to develop it. Being very attentive or very extrovert is shown in babies even when we don't condition them to be (I always thought this was very conditioned). Of course, later you can teach them and manage some of their trait to be more effective but inherently they are already have certain tendencies.

The most interesting thing for me is to see how we learn. It's really incredible to see how children learn and reflect on how we ourselves learn. You will see how those principles in AI books come from. I think you could actually subtitle any AI text-book as "how babies learn" :).

In physical level it is quite the same too. You see how those hair, teeth grow and how the faces change and shape up. Watching them learn how to walk is fun and refereshing and you see how those muscle strengthen.

It's probably a little inhuman to call it API, you could say it instead : if you'd like to learn and know more about yourself inner-workings, have a children.

Programmer Maturity and Estimation Skill

How do you measure a programmer maturity?. Recently, I am beginning to think that it is reflected on how they estimate the project and task that they need to do.

Programmer that only work on small number of code and problem tend to highly overestimate or underestimate the complexity of a project/task. So, mature programmer is not (just) someone who could code, and estimate, very good and precise in well-known problem using language that he knows well. A mature programmer would also :

• know quite clearly what he need to do/learn/research on matters that he is not used to
  
• how much/how certain/uncertain the time to take to tackle it, substask and trouble that potentially come up
  
• make clearly-thought estimation, and most importantly
  
• not emotionally attached to a problem which means not knowing or estimate something as long/hard/unknown/impossible is nothing to be embarassed/defensive about instead it's for the best if everyone being clear on what can and cannot be done
  

Less mature one would tend to be more "aggresive" and eager to prove himself by estimating too optimistically or underestimating a complexity of certain task (by fear of losing credibility or eagerness to be accepted/approved).

I think it's the same as maturity in life, you are less needing of approval/praise or trying to satisfy/impress anybody too much and more focus on doing what you can do best and keeping your integrity checked.

It does not mean we need to avoid the unknown and avoid adventure, but being mature means being clear of it and not promising something beyond our integrity to accomplish it. Say something is risky when it is and let the stakeholder decide (and share consequences later), say something certain when you have a reference/experience of it and ready to take consequence if you are proven to be wrong (you learn something new anyway).

Running .Net Winforms Application in Mono

I am curious to try running .Net Winforms application for several reason :

• Most portable GUI-based .Net app is written not using Winforms but something else e.g: gtk.
• Want to see how far the Mono team in dealing with GUI application so far (I have used server application written in .net in mono but no winform application yet).
• I have written pure and relatively simple/common winform application that supposed to run in any "good enough" winform port. Before it, my use of winforms had to goes into win32 specific "hack" which less likely to run in non-win32 .Net port.
  

So, here goes the result : it runs quite well. I only copied the binaries compiled by visual studio and the neccessary dll in windows to linux (after changing code for file/directory path to a more neutral convention) and run :

mono quicktask.exe

and the application "magically" run. Screenshot below :



It's the quicktask app from my previous post, so you could compare with the screenshot on that post. There's only some odd pixels in textbox borders but beside that, things are running fine.

Now, as long as you don't use anything strange with winform, it seems to be quite a portable development platform now. Pretty convinient if you would like to stay developing in winform or already have a codebase in it and want port it to platform that can run mono.

One note though, if you have more need like more integrated look and feel you probably want to look other alternative e.g: gtk sharp, since currently winform in mono feels like the early java gui toolkit i.e: it uses it's own rendering instead of using native widgets. It's good enough to make things run but probably won't impress too much consdering how user interfaces is getting shinier these days.