sontek ( John M. Anderson )

The point of Trace.WriteLine and Debug.WriteLine is to give you the ability to monitor certain areas of your code when debugging or tracing but avoid cluttering your screen or hard drive with useless output when you aren’t. When most people stumble upon Trace/Debug they think it should “Just work”–without any setup–this isn’t the case.

Another great benefits of using Trace/Debug instead of the old Console.WriteLine is you can define exactly where to log to in your app config or with environment variables, so sometimes you might want direct output to the Console but other times you might want to log to a file.

To get your output from Trace/Debug you first need to define either DEBUG or TRACE in your preprocessor directives.

You can do this in code by placing:

#define TRACE

in your code or by passing it at compile time:

gmcs -d:TRACE

after you have your preprocessor directives setup, you have to define where to log to. You can do this by defining it in your app config:

<configuration>
  <system.diagnostics>
    <trace autoflush="false" indentsize="4">
      <listeners>
        <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="TextWriterOutput.log" />
        <remove name="Default" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

or you can define it with the environment variable MONO_TRACE_LISTENER:

export MONO_TRACE_LISTENER=Console.Out

and then you can start your logging with System.Diagnostics.Trace.WriteLine(”Hello World”).

To learn more about Trace/Debug check out:the docs here and here. To learn more about other environment variables you can use with mono ‘man mono’ or click here.

I just finished porting Tomboy’s print code to GTK so that we would be more portable and I thought other Mono apps looking to move from libgnomeprint or wanting to add printing support might find a code example helpful.

First, To start printing you do something like:

private void PrintButtonClicked (object sender, EventArgs args)
{
Gtk.PrintOperation op = new PrintOperation ();
op.BeginPrint += new BeginPrintHandler (OnBeginPrint);
op.DrawPage += new DrawPageHandler(OnDrawPage);

op.Run (Gtk.PrintOperationAction.PrintDialog, this.Window);
}

after the PrintOperation is set off you need to handle the BeginPrint event. The main things that need to be done are finding out how many lines will fit on a page and how many lines you have:

public void OnBeginPrint(object sender, Gtk.BeginPrintArgs args)
{
PrintOperation op = (PrintOperation)sender;
lines_per_page = (int)Math.Floor ((double)args.Context.Height / (double)font_size);
Gtk.TextIter start_iter, end_iter;
this.Buffer.GetBounds (out start_iter, out end_iter);
lines = this.Buffer.GetText (start_iter, end_iter, false).Split ('\n');
op.NPages = (int)Math.Ceiling ((double)lines.Length / (double)lines_per_page);
}

Finally, now that you have the printing setup, you need to actually render the data to be printed:

public void OnDrawPage(object sender, Gtk.DrawPageArgs args)
{
PrintOperation op = (PrintOperation)sender;
Cairo.Context cr = args.Context.CairoContext;

int line = args.PageNr * lines_per_page;
int num_lines = 0;
if (args.PageNr+1 != op.NPages)
num_lines = line + lines_per_page;
else
num_lines = lines.Length;

cr.MoveTo (0, 0);

for (int i = 0; i < lines_per_page && line < num_lines; i++)
{
Pango.Layout layout = args.Context.CreatePangoLayout ();
Pango.FontDescription desc = Pango.FontDescription.FromString (”sans ” + font_size);
desc.Size = (int)(font_size * Pango.Scale.PangoScale);
layout.FontDescription = desc;

layout.SetText (lines[line]);
Pango.CairoHelper.ShowLayout (cr, layout);
cr.RelMoveTo (0, font_size);
line++;
}
}

This does not take into account styles but will give you the basic idea of what needs to be done.

Matt Asay has posted a blog here claiming that Miguel de Icaza is wasting away his talents by “cloning” C#/.NET with mono, rather than

“going back to the innovation in GNOME that originally made you one of the most interesting developers on the planet”

C# and CLI are open standards, so they are just implementing an open standard, not cloning it. This short sighted outlook on the future of Linux and GNOME shows the difference between Miguel and Matt. Miguel and his team at Ximian/Novell have been leading innovation in Linux for over 10 years with GNOME and Evolution and the reason they began

“Squandering one of the industry’s best open source talents”

by working on Mono was because they realized that Linux could not compete with Windows without a better development environment, so rather than always trying to play catch up to the proprietary world, Miguel and his team set out to even the playing field.

And Joe Shaw points out the most frivolous point in Matt’s post here.

Matt says:

“You [Miguel], personally, would convince more by going back to the innovation in GNOME that originally made you one of the most interesting developers on the planet. I want the old Miguel (and Nat - where has Nat Friedman been?) back, the one who demo’d Nat’s Dashboard with Nat at OSCON. The one who led and pushed GNOME forward for so many years.”

Dashboard is one of the very first C#/.NET/Mono desktop applications on Linux. It is still one of the most innovative applications on the Linux desktop, and Matt agrees with this, which shows just how great Mono is.

Miguel isn’t only allowing for innovation on the Linux desktop but he is also allowing corporations that were mainly a C#/.NET shop to be able to port their applications to the Mac and Linux platforms.

Matt, I respect your opinion and believe you did great things when pushing open source at Novell, but I think you need to look at the bigger picture and get past the fact that .NET was designed by Micrososft. C# is a great language and the .NET class library makes it easy to quickly develop desktop applications such as F-Spot, Beagle, Tomboy, and Banshee.

Jeffrey Steadfast also provides an interesting view on this here.