tag:blogger.com,1999:blog-64406045755619807112024-03-13T19:15:36.059+01:00Food for MonkeysLluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-6440604575561980711.post-6030775338919863072012-11-13T17:41:00.000+01:002012-11-13T18:51:13.925+01:00XWTI started the <a href="https://github.com/mono/xwt">XWT</a> project almost one year ago and athough I talked about it at FOSDEM, I never found the time to formally present it. Those are busy days at <a href="http://www.xamarin.com/">Xamarin</a>! Anyway, let’s go ahead.
<br />
<br />
XWT is an open-source cross-platform UI toolkit for Mono and .NET. What’s special about XWT is that it is built on top of the native widget toolkit of each supported platform. So rather than a new widget toolkit implemented from scratch it is an abstraction that wraps the native toolkits using a common API. The end goal of XWT is to allow building applications which look and feel native in each platform. Here are some screenshots of a sample application running with the GTK and Cocoa backends:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-oLSru63bk-o/UKJVFQ8ieSI/AAAAAAAAFv8/djBA-OHN1EA/s1600/xwt-gtk.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="248" src="http://2.bp.blogspot.com/-oLSru63bk-o/UKJVFQ8ieSI/AAAAAAAAFv8/djBA-OHN1EA/s320/xwt-gtk.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">GTK backend</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-lhskkJ203aE/UKJVGBTiu5I/AAAAAAAAFwA/GKE1EiYf0jk/s1600/xwt-mac.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="254" src="http://3.bp.blogspot.com/-lhskkJ203aE/UKJVGBTiu5I/AAAAAAAAFwA/GKE1EiYf0jk/s320/xwt-mac.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Cocoa backend</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<a href="http://3.bp.blogspot.com/-lhskkJ203aE/UKJVGBTiu5I/AAAAAAAAFwA/GKE1EiYf0jk/s1600/xwt-mac.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;">
</a>
<br />
I initially created XWT with the idea of building MonoDevelop on top of it. Around this time last year we had a discussion about how we could improve the look & feel of MonoDevelop in Mac and Windows. MonoDevelop is built with GTK# 2, which worked very well on Linux, but which had (and still has) some issues on other platforms. Although GTK is a cross platform toolkit, not all backends have the same quality, and not all features are completely implemented. So XWT would allow us to have a native look and still reuse most of the code. However, rebuilding MonoDevelop with XWT is a lot of work and we needed to fix the Mac and Windows issues as soon as possible, so we decided to invest our efforts in fixing the most annoying GTK bugs instead of going the XWT route.<br />
<br />
Even though we are not going to immediately migrate all of MonoDevelop to XWT, at Xamarin we have started using it for some UI code that needs run in MonoDevelop and Visual Studio. An example of this is the Android designer. The designer is implemented in XWT, and we use the GTK backend when running MonoDevelop and a WPF backend when running on Visual Studio:<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-Bc0RG6K689o/UKJbKfcSX5I/AAAAAAAAFwU/25lWUAgaqlA/s1600/xwt-designer-md.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="335" src="http://1.bp.blogspot.com/-Bc0RG6K689o/UKJbKfcSX5I/AAAAAAAAFwU/25lWUAgaqlA/s400/xwt-designer-md.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The designer running on GTK in MonoDevelop</td></tr>
</tbody></table>
<div style="text-align: left;">
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-_TiWsHilDm0/UKJbMYxZxtI/AAAAAAAAFwc/yf7LwKqm8ak/s1600/xwt-designer-vs.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="360" src="http://1.bp.blogspot.com/-_TiWsHilDm0/UKJbMYxZxtI/AAAAAAAAFwc/yf7LwKqm8ak/s400/xwt-designer-vs.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The designer running on WPF in Visual Studio</td></tr>
</tbody></table>
<h3>
XWT vs Native Toolkits</h3>
At Xamarin we have always advocated for using the native toolkit of each platform in order to take advantage of all features offered by the platform and be able to build the most visually rich and performant applications. How does XWT fit on this idea?<br />
<br />
XWT has three important design features:<br />
<ul>
<li>User interfaces implemented using XWT can be embedded inside a native UI. It means you can build your application using the native toolkit when you need advanced platform features, and you can use XWT for more simple UI that can be shared.</li>
<li>XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets.</li>
<li>XWT is a UI toolkit abstraction, so it’s about abstracting common UI idioms as widgets. XWT will have support for the most common widgets such as entries or buttons, but it will also provide higher level widgets which are more “semantic”. It means that XWT applications will be constrained to use those higher level UI idioms, but each of those idioms can have a platform-specific implementation which takes full advantage of the native toolkit features, and which can abide for the platform UI guidelines. </li>
</ul>
There is a tradeoff between portability and functionality. XWT is not for everybody. It wont have the richness and the low level features of a native toolkit, so it will not be suitable for applications which require advanced UI features.<br />
<h3>
Design Principles</h3>
XWT looks like GTK#. It uses a similar layout model and class names. That’s basically to make it easier to migrate GTK# code to XWT, not because GTK# is superior to everything else (although maybe it is). However, there are notable differences. The API design has an important focus on simplicity and usability. Here are some important differences with respect to GTK:<br />
<ul>
<li>The widget hierarchy is mostly flat. There is a Widget class and most of other classes directly subclass it. There are no unnecessary infrastructure classes. For example, there is no Container class, any widget can have children if they need to.</li>
<li>Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK).</li>
<li>No concept of GdkWindow. You have a widget, that’s all.</li>
</ul>
I’m a firm believer of usability-oriented API design. Many libraries are designed using complex class hierarchies and abstractions whose purpose is to make the library code easier to reuse and maintain. That is, the code is designed to facilitate the work of the library developer, not the work of the library consumer. That’s a bad approach since the library will be implemented by only few developers, but potentially consumed by thousands of developers.<br />
<h3>
Features</h3>
Here are some details about what’s currently supported by XWT:<br />
<ul>
<li>XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows).</li>
<li>XWT can instantiate more than one backend at a time, and run those side by side (with some limitations). For example, you can have XWT use Gtk and Cocoa in the same application, depending on what is hosting your code.</li>
<li>The basic widget library is mostly complete.</li>
<li>It has a drawing API, very similar to Cairo.</li>
<li>There is no visual designer yet, nor any markup language for representing windows. My plan is to use XAML or a simplified version of it.</li>
<li>XWT can be extended in different ways.</li>
<li>Applications can create subclasses of XWT widgets, or create new widgets.</li>
<li>New backends can be plugged into XWT</li>
<li>Existing backends can be extended</li>
<li>The API is not yet stable and can change at any time.</li>
</ul>
<h3>
Future</h3>
The work on XWT will continue, there is still a lot to do. XWT is already already included in the MonoDevelop core. Although we don’t plan to do a big migration effort, we plan to gradually use XWT in the implementation of new features.<br />
<br />
If you are interested in XWT, you can get the source code from here:<br />
<a href="https://github.com/mono/xwt">https://github.com/mono/xwt</a><br />
<br />
There is also a mailing list:<br />
<a href="http://groups.google.com/group/xwt-list">http://groups.google.com/group/xwt-list</a><br />
<br />
And an IRC channel:<br />
<a href="irc://irc.gimp.org/xwt">irc://irc.gimp.org/xwt</a><br />
<br />
Contributions are welcome!<br />
<br />Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com4tag:blogger.com,1999:blog-6440604575561980711.post-65916703582444163672011-03-02T18:21:00.001+01:002011-03-02T19:22:38.284+01:00First beta of MonoDevelop 2.6MonoDevelop 2.6 beta 1 was released yesterday. Like every major release, it has many new features. Here is a summary of what have we done.<br /><br />The first new big feature is <span style="font-weight:bold;">support for GIT</span>. This was long time due, especially since Mono and MonoDevelop itself moved to GIT. I already <a href="http://foodformonkeys.blogspot.com/2010/10/ngit.html">blogged about it</a> a few months ago, but basically we are using NGit, a C# port of JGit, as the core for the GIT add-in. It hasn't been easy to make this port fully operational, but we now have a GIT core that can be easily updated and which is fully portable.<br /><br /><div><div>We have also spent some time improving all the <b>version control views</b>. I like especially the new changes view integrated in the source editor, and the log view (which btw can show gravatar icons of committers). We plan to keep improving those views to make them even more functional.</div><div><br /></div><div><a href="http://2.bp.blogspot.com/-0_i5grnArf4/TW56gHLhC-I/AAAAAAAACBA/_eYSV7YrXiU/s1600/md26-ChangesView.png"><img src="http://2.bp.blogspot.com/-0_i5grnArf4/TW56gHLhC-I/AAAAAAAACBA/_eYSV7YrXiU/s400/md26-ChangesView.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5579531680460377058" style="cursor: pointer; width: 400px; height: 282px; " /></a></div><div><br /></div><div>Another big change in this release is the new <b>MCS based parser and formatting engine</b>. Mike Krueger (in charge of the C# support) and Marek Safar (maintainer of the MCS compiler) have been collaborating to make the MCS parser usable in MonoDevelop. By using MCS, we'll be able to quickly have support for the latest C# features, and we'll be able to report syntactic errors on-the-fly that exactly match those reported by the compiler. Also thanks to MCS, the C# formatter is more reliable and will allow to properly implement on-the-fly formatting on all contexts.</div><div><br /></div><div>We also added in this release support for<b> user defined policies</b>. The concept of "Policies" was introduced in MonoDevelop 2.4. Policies are settings which can be applied per-solution and per-project. Policies include settings like code formatting rules, standard header for files or naming policies. Until now, we supported setting the default values for those policies, which would be used when creating new projects. Beside this, we now also support creating named sets of policies. So for example, an user could define a "Company" policy set with formatting rules and file headers specific for company projects. It could also define a "Open Source" policy set with different rules. When creating a project, the user can then chose which policies to use.</div><div><br /></div><div><a href="http://3.bp.blogspot.com/-EOVaxKe-B1s/TW56x-qXkmI/AAAAAAAACBI/eh4WRJ8o63o/s1600/md26-CustomPolicies.png"><img src="http://3.bp.blogspot.com/-EOVaxKe-B1s/TW56x-qXkmI/AAAAAAAACBI/eh4WRJ8o63o/s400/md26-CustomPolicies.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5579531987411505762" style="cursor: pointer; width: 400px; height: 295px; " /></a></div><div><br /></div><div>Another feature we added is support for <b>IL disassembly</b> in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies.</div><div><br /></div><div><a href="http://1.bp.blogspot.com/-o0E77yIF57g/TW565ewf8yI/AAAAAAAACBQ/UYOxXODzqaI/s1600/md26-Disassembly.png"><img src="http://1.bp.blogspot.com/-o0E77yIF57g/TW565ewf8yI/AAAAAAAACBQ/UYOxXODzqaI/s400/md26-Disassembly.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5579532116286239522" style="cursor: pointer; width: 400px; height: 299px; " /></a></div><div><br /></div><div>Finally, we also have a brand new <b>add-in manager</b>, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in <a href="http://addins.monodevelop.com/">addins.monodevelop.com</a>, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users.</div><div><br /></div><div><a href="http://3.bp.blogspot.com/-w2N9d-lB_Ro/TW58EVsF5CI/AAAAAAAACBY/AEHPirBdMis/s1600/md26-AddinManager.png"><img src="http://3.bp.blogspot.com/-w2N9d-lB_Ro/TW58EVsF5CI/AAAAAAAACBY/AEHPirBdMis/s400/md26-AddinManager.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5579533402342024226" style="cursor: pointer; width: 400px; height: 294px; " /></a></div><div><br /></div><div><b>Update</b>: forgot to mention one important improvement that has been requested by Mac users for long time: <b>support for native OSX dialogs</b>. Message and file dialogs on Mac now use the native UI toolkit.</div><div><br /></div><div>There are many other improvements and new features in this release. Take a look at <a href="http://monodevelop.com/index.php?title=Download/What's_new_in_MonoDevelop_2.6">What's new in MonoDevelop 2.6</a> if you want to know more.</div><div><br /></div><div><br /></div><div><br /></div></div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com6tag:blogger.com,1999:blog-6440604575561980711.post-232841894252961542011-03-01T12:35:00.002+01:002011-03-01T12:47:49.307+01:00gui-thread-checkMonoDevelop often makes use of threads to run operations on the background. Although we make sure to invoke all GUI update methods through the main GUI thread, sometimes there is a bug and an update is done in the secondary thread, which causes all sort of random locks and crashes.<br /><br />To make it easier to track down those bugs, I created a simple profiler module for Mono which can detect invocations to GTK# methods from a thread other than the main GUI thread. This module is available here:<br /><br /><a href="https://github.com/slluis/gui-thread-check">https://github.com/slluis/gui-thread-check</a><br /><br />To use it, build and install the module, and then run your application with<br />the command:<br /><br /> mono --profile=gui-thread-check yourapp.exe<br /><br />If the profiler is properly installed, you'll see an output like this:<br /><br />*** Running with gui-thread-check ***<br />*** GUI THREAD INITIALIZED: 2861676352<br /><br />While the application is running, if the profiler detects a non-gui thread<br />invoking gtk methods, it will print a warning message together with a<br />stack trace. For example:<br /><br />*** GTK CALL NOT IN GUI THREAD: Widget.gtk_widget_get_parent<br /> Widget.get_Parent<br /> SourceEditorWidget.get_TextEditor<br /> SourceEditorWidget.get_Document<br /> SourceEditorWidget.HandleParseInformationUpdaterWorkerThreadDoWork<br /> BackgroundWorker.OnDoWork<br /> BackgroundWorker.ProcessWorkerLluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com2tag:blogger.com,1999:blog-6440604575561980711.post-63703527607454813952011-02-04T14:43:00.004+01:002011-02-04T15:00:17.681+01:00I'm flying to Brussels in a few minutes, heading to Fosdem. I'm not giving a talk this year, but if you are interested in knowing more about Mono and MonoDevelop don't miss the Mono track on Saturday afternoon. Many nice talks, and a good chance to meet Mono developers and contributors.<br /><br /><a href="http://www.fosdem.org/"><img src="http://www.fosdem.org/promo/going-to" alt="I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting" /></a>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com1tag:blogger.com,1999:blog-6440604575561980711.post-11139989448113217332010-10-27T16:03:00.003+02:002010-10-27T18:49:00.058+02:00NGitOne of the features we want to include in the next MonoDevelop release is integrated support of Git. I committed a first version of a git add-in some months ago which works by invoking the git command and parsing the results. This solution satisfied some basic needs (Mono was moving to git at that time), but it was done as a short term solution, since parsing git output is not very reliable, and has portability issues.<div><br /></div><div>The next obvious step was to use <a href="http://www.eqqon.com/index.php/GitSharp">GitSharp</a>, a fully managed .NET library which implements most of git commands. This library is basically a port of <a href="http://www.eclipse.org/jgit/">JGit</a>, a Java library for doing the same. I started replacing the git invocations by calls to GitSharp classes, and I could implement the basic functionality, but I found some limitations that were not easy to overcome. On one hand, GitSharp was a bit outdated, lacking some of the recent features and bug fixes done in JGit. Bringing GitSharp up to date with JGit would be a lot of work, since every JGit commit had to be manually translated from Java to C#. On the other hand, GitSharp depends on a set of cryptographic libraries (required for the ssh protocol support) which we can't easily include in MonoDevelop due to export regulations.</div><div><br /></div><div>I then decided to try a different approach: the idea was to use <a href="http://developer.db4o.com/Projects/html/projectspaces/db4o_product_design/sharpen.html">Sharpen</a>, a free Java to C# translator implemented by db4o, to automatically convert the JGit code to C#. </div><div><br /></div><div><div>After some weeks of work, I have been able to generate a C# library (which I call <b>NGit</b>) with all the JGit code. Most of the work went into tunning and fixing Sharpen, and into implementing in C# some core Java classes which didn't have direct replacement in Mono. This was more complex and took more time than I expected, but I think the effort is worth it. The generation of the library is automatic, although not perfect since it requires some patches in the java code and some patches in the generated code, but the patches are small and easy to maintain. Keeping NGit in sync with JGit is very easy, since it is just a matter of pulling the java code and running the conversion (I already have the conversion process automated in a makefile).</div></div><div><br /></div><div><div>I've also been able to convert and run the JGit unit tests, and got 90% of tests working. The failures of the remaining 10% are in general due to different behavior of Java vs C#, or JUnit vs NUnit, and are not real NGit bugs (although I still have to review some of them).</div></div><div><br /></div><div><div>In the process, I also converted Jsch, which is the library used by JGit for the ssh communication. The new NSch library only has Mono.Security as external dependency, so it will be much easier to distribute for us.</div><div><br /></div><div>So, we now have a fully managed git library with ssh support without any dependency external to Mono. The library has around 56000 lines of generated C# code (including the unit tests). I recently published the <a href="http://github.com/slluis/ngit">source code in github</a>.</div></div><div><br /></div><div>I'm now implementing the git add-in using NGit. Most of the commands are already implemented, although I'll have to do some testing before I push it to master. There are still some performance issues I'm tracking down, but things are looking good. I intend to submit my fixes to JGit. My fist patch has already been accepted and <a href="http://egit.eclipse.org/w/?p=jgit.git;a=commit;h=07cae6e6c1d6982cf6b919e90e79330793c74a15">pushed</a>, and conveniently <a href="http://github.com/slluis/ngit/commit/10db67aaa331ec4e3e4d05db47d98e2cd21c50ae">ported</a> to NGit.</div><div><br /></div><div><b>Update</b>: I'd like to clarify the relation of NGit with GitSharp. GitSharp is composed by two libraries: GitSharp.Core.dll and GitSharp.dll. GitSharp.Core.dll is a manual port of JGit. GitSharp.dll is a more high level and .NET friendly API that wraps GitSharp.Core.dll. NGit can be a replacement for GitSharp.Core.dll, but GitSharp.dll is still useful, since NGit may be a bit too low level and java-ish for some use cases.</div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com26tag:blogger.com,1999:blog-6440604575561980711.post-82988898521913860312010-10-20T16:19:00.002+02:002010-10-20T16:35:12.737+02:00Cydin source publishedI just published the source code of <a href="http://foodformonkeys.blogspot.com/2010/06/hack-week-project-cydin.html">Cydin</a> in <a href="http://github.com/slluis/cydin">github</a>. Cydin is an add-in repository for applications based on Mono.Addins. The latest version is currently running the <a href="http://addins.monodevelop.com">MonoDevelop add-in repo</a>. I have many ideas to keep improving Cydin. Here are a few:<div><ul><li>Add support for multiple applications. That's almost done, but there are still some issues to be fixed. The idea is that a single Cydin installation could be used as add-in repository for many applications (for example, MonoDevelop, F-Spot, Tomboy, etc). The add-in repo for each application would be independent, but they would share some services, such as user authentication and the build service. It would be nice to have in the future a single web server which can be used by all Mono.Addins based applications to host add-ins.</li><li>Add support for multiple add-ins per project. Right now, a project can only generate one add-in. In some cases it may be useful to be able to generate several related add-ins without having to create a project for each of them.</li><li>Add a search and browse views, so users can look for add-ins.</li><li>Add support for 1-click install. This would allow users to install add-ins by clicking on them in the web site, instead of having to do it through the add-in manager in the application. That's partially implemented, but requires changes in the application (that is, MonoDevelop).</li></ul><div>So, quite a lot of work to do. I'm open to contributions :)</div><div><br /></div></div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com2tag:blogger.com,1999:blog-6440604575561980711.post-9158442018439775402010-08-04T12:13:00.000+02:002010-08-04T12:18:37.897+02:00Comunity add-in repository for MonoDevelopYesterday I published a beta version of what is going to be a <a href="http://addins.monodevelop.com">Community add-in repository for MonoDevelop</a>. This web site is based on the <a href="http://foodformonkeys.blogspot.com/2010/06/hack-week-project-cydin.html">Cydin project</a>, developed during the last hack-week at Novell.<div><br /></div><div>The functionality it has is basically what explained in my last <a href="http://foodformonkeys.blogspot.com/2010/06/hack-week-project-cydin.html">blog post</a>:</div><div><ul><li>The add-in developer creates a new project in the web site by specifying a name, description and version control urls to the source code. It currently supports Subversion, Git and Bazaar.</li><li>A build service pulls the code from the version control repositories and builds it.</li><li>The built add-ins are published in an standard Mono.Addins add-in repository in the web site.</li><li>Users can subscribe that repository and install the add-ins.</li></ul>This site is still under development and needs testing, so I'd like people to start publishing add-ins to see how it works. I intend to publish the source code of Cydin so that other Mono.Addins based application can create their own add-in repositories. However, before doing it I want to polish a bit the code and add some documentation (and that requires time).</div><div><br /></div><div>The long term goal is to have a kind of add-in marketplace site, where developers can publish add-ins and users can browse, download, rate and comment them.</div><div><br /></div><div>For now, I'm happy with having a place where contributors can make add-ins easily available to all users. So if you have developed an add-in for MonoDevelop, please <a href="http://addins.monodevelop.com">register it</a>!</div><div><br /></div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com0tag:blogger.com,1999:blog-6440604575561980711.post-78304695661876353632010-06-17T13:00:00.000+02:002010-06-17T13:05:57.808+02:00Hack Week project: CydinLast week was a Hack Week at Novell, so I spent some time working on a new idea I've been cooking in the past weeks: a Community Add-in Repository for MonoDevelop, which I'm calling Cydin.<div><br /></div><div>The idea is to have a web site where add-in developers can publish their MonoDevelop add-ins and make them available to all users. The site works like a build bot: it pulls the source code of add-ins from version control repositories, builds and packages them, and then publishes them in an add-in repository, to which MonoDevelop will be subscribed.</div><div><br /></div><div>In one week I've been able to implement the basic functionality, although it still needs some polish before I can make it publicly available. I implemented the site using ASP.NET MVC. I didn't know much about MVC in ASP.NET, so it has been also great to learn something new. </div><div><br /></div><div>Beware: I put zero effort to the visual design.</div><div><br /></div><div>So, how does it work? This is the home page:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/TBnyCNYX0vI/AAAAAAAABcA/pCyckfHRMLw/s1600/cydin-home.png"><img src="http://3.bp.blogspot.com/_cHnO0qtZD7s/TBnyCNYX0vI/AAAAAAAABcA/pCyckfHRMLw/s400/cydin-home.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483680141065835250" style="cursor: pointer; width: 400px; height: 285px; " /></a></div><div><br /></div><div>The first thing you have to do is to log in. Authentication will be based on OpenID, but this is not yet fully functional (I'm using the DotNetOpenAuth library but I'm having trouble making it work on Linux).</div><div><br /></div><div>The home page is very simple. It shows a list of the projects owned by the user and a list of recent releases. I planed to include add-in browse and search options, but I had no time for this.</div><div><br /></div><div>The Create Project link allows creating a new add-in project:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/TBn8djyRNCI/AAAAAAAABcU/-sT_YTBPoYM/s1600/cydin-newproject.png"><img src="http://3.bp.blogspot.com/_cHnO0qtZD7s/TBn8djyRNCI/AAAAAAAABcU/-sT_YTBPoYM/s400/cydin-newproject.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483691606052779042" style="cursor: pointer; width: 400px; height: 285px; " /></a></div><div><br /></div><div>This page allows entering the add-in name, the identifier and a description. When clicking on Create, the source definition page is shown:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_cHnO0qtZD7s/TBn8SXFHO8I/AAAAAAAABcM/FkS_AP-1Wqg/s1600/cydin-newsource.png"><img src="http://4.bp.blogspot.com/_cHnO0qtZD7s/TBn8SXFHO8I/AAAAAAAABcM/FkS_AP-1Wqg/s400/cydin-newsource.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483691413663595458" style="cursor: pointer; width: 400px; height: 285px; " /></a></div><div><br /></div><div>This page allows specifying the location of the source code of the add-in. Right now it only supports Subversion, but I plan to add support for GIT soon.</div><div><br /></div><div>When specifying the URL of the subversion repo, there is a twist: if the URL ends with "/*" the build service will pull all directories bellow that URL, and each directory will be considered a </div><div>different release. So for example, if you specify:</div><div><blockquote>https://test.googlecode.com/svn/trunk/tags/test-project/*</blockquote></div><div>then all tags of test-project will be pulled as independent releases.</div><div><br /></div><div>If the auto-publish checkbox is set, the build service will automatically publish new versions of the add-in at every commit.</div><div><br /></div><div>After saving the changes, the project home page is shown:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/TBn8nB5NHmI/AAAAAAAABcc/rYgCZvr532k/s1600/cydin-project-home.png"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/TBn8nB5NHmI/AAAAAAAABcc/rYgCZvr532k/s400/cydin-project-home.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483691768753757794" style="cursor: pointer; width: 400px; height: 330px; " /></a></div><div><br /></div><div>The page will be empty because pulling and building the source code may take some time. </div><div><br /></div><div>Source code is pulled and built by a <b>Build Service</b>. The build service is independent from the web site and can run in a different host. Communication between the two is done through a web service.</div><div><br /></div><div>So after a bit we'll see:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn8ua6xBWI/AAAAAAAABck/98S6SU_iE0s/s1600/cydin-project-home2.png"><img src="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn8ua6xBWI/AAAAAAAABck/98S6SU_iE0s/s400/cydin-project-home2.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483691895730275682" style="cursor: pointer; width: 400px; height: 330px; " /></a></div><div><br /></div><div>This shows that the build service found six directories below the specified svn url, and pulled all of them. Then it started building.</div><div><br /></div><div>Notice that the build service extracts some information from the add-ins: the add-in version, the MonoDevelop version that the add-in is targeting, and the target platforms.</div><div><br /></div><div>Sources with the 'Ready' status are already built and packaged, but not yet available in the add-in repository. To make them available, you have to click on the 'Publish' link. This is not necessary if the auto-publish option is set for this SVN source (in this case the release would be automatically published after building).</div><div><br /></div><div>This is how the page looks like after publishing some releases:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn83Zxh7rI/AAAAAAAABcs/4krPu1ttR3Q/s1600/cydin-project-home3.png"><img src="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn83Zxh7rI/AAAAAAAABcs/4krPu1ttR3Q/s400/cydin-project-home3.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483692050041925298" style="cursor: pointer; width: 400px; height: 330px; " /></a></div><div><br /></div><div>The site administrator has some control over which releases are published. By default, new projects releases have to be validated by an administrator.</div><div><br /></div><div>Published add-ins can be installed using the MonoDevelop add-in manager:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn8_BDOcPI/AAAAAAAABc0/34xLWNzRKKg/s1600/cydin-manager.png"><img src="http://2.bp.blogspot.com/_cHnO0qtZD7s/TBn8_BDOcPI/AAAAAAAABc0/34xLWNzRKKg/s400/cydin-manager.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5483692180844212466" style="cursor: pointer; width: 400px; height: 303px; " /></a></div><div><br /></div><div>There is still some work to do, but I hope I can publish the site as a beta soon so you can start experimenting with it.</div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com5tag:blogger.com,1999:blog-6440604575561980711.post-62789170271988060422010-03-08T14:50:00.000+01:002010-03-08T14:56:03.638+01:00Improving in the MonoDevelop user interfaceIn the past weeks (actually, months) I've been doing some changes in the MonoDevelop GUI to make it more functional and better looking. Here is the result:<div><br /></div><div><b>Before</b><br /><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/S5T_w_ThTDI/AAAAAAAABao/vv2FZ14legM/s1600-h/NewGuiBefore.png"><img src="http://3.bp.blogspot.com/_cHnO0qtZD7s/S5T_w_ThTDI/AAAAAAAABao/vv2FZ14legM/s400/NewGuiBefore.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446259066489883698" style="cursor: pointer; width: 400px; height: 238px; " /></a></div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/S5Tmsqf2EsI/AAAAAAAABZ4/yD6OZBesVwo/s1600-h/NewGuiBefore.png"></a><b>After</b><br /><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/S5T_4uXh-sI/AAAAAAAABaw/oe0lGxxuTrY/s1600-h/NewGuiAfter.png"><img src="http://2.bp.blogspot.com/_cHnO0qtZD7s/S5T_4uXh-sI/AAAAAAAABaw/oe0lGxxuTrY/s400/NewGuiAfter.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446259199382256322" style="cursor: pointer; width: 400px; height: 238px; " /></a></div><div><br /></div><div><b>Changes in the Status Bar</b></div><div><br /></div><div>Everything started with the idea of removing the status bar, in order to save space in the main window. The plan was to use something similar to Chrome's status popups, which are visible only when there is actual information to show to the user. However, after playing with the idea and thinking about how would it fit in MonoDevelop, I decided to try something else. Instead of removing the status bar, we would make a better use of the space it takes. So in the new GUI I merged the status bar and the bottom dock bar. The dock bar is the area where the title of pads in auto-hide mode are shown (for example, the Test Results pad in the above screenshots). When you hover over the title, the pad is shown in a popup window, with a nice sliding effect. The bottom dock bar is now shown next to the status bar, growing as more space is required.</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5TtMdYR-ZI/AAAAAAAABaI/Q1VhVQB682A/s1600-h/NewGuiStatusBar.png"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5TtMdYR-ZI/AAAAAAAABaI/Q1VhVQB682A/s400/NewGuiStatusBar.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446238647698454930" style="cursor: pointer; width: 400px; height: 10px; " /></a></div><div><br /></div><div>I also added support for custom pad labels. So for example, the Errors List pad now shows the error and warning count, instead of just the "Errors List" label. In this way pads can show some status information while they are minimized.</div><div><br /></div><div><b>Less intrusive output pads</b></div><div><br /></div><div>Temporary output pads such as logs for Version Control or Find in Files operations are now shown in autohide mode by default. Until now, those pads were shown docked at the bottom, taking space from the text editor. I also removed the standalone Build Output pad. The build output is now available in the Errors List pad, by clicking on the Build Oputput button:</div><div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5T025_r3QI/AAAAAAAABaY/ZKUoTaYwYNc/s1600-h/NewGuiBuildPad.png"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5T025_r3QI/AAAAAAAABaY/ZKUoTaYwYNc/s400/NewGuiBuildPad.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446247073515822338" style="cursor: pointer; width: 400px; height: 327px; " /></a></div></div><div><br /></div><div><b>Visual improvements</b></div><div><br /></div><div>A noticeable visual change is that the main window new has a darker background, with some subtle shading effects. The pads look more "physical" and better delimited. The pad toolbars are now integrated in the docking system, improving the overall visual consistency.</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_cHnO0qtZD7s/S5TzPTug6xI/AAAAAAAABaQ/Woa9tHuu6SE/s1600-h/NewGuiPadToolbar.png"><img src="http://4.bp.blogspot.com/_cHnO0qtZD7s/S5TzPTug6xI/AAAAAAAABaQ/Woa9tHuu6SE/s400/NewGuiPadToolbar.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446245293716728594" style="cursor: pointer; width: 288px; height: 299px; " /></a></div><div><br /></div><div><b>Configurable GUI compactness</b></div><div><br /></div><div>One thing I learned while working in MonoDevelop is that it is hard to find the right balance in the use of padding between the gui components (specifically, between the components shown in the main window). Using more padding makes the GUI more visually pleasant, and the components are better delimited. On the other hand, padding may be a waste of space when working on small resolutions.</div><div><br /></div><div>I added a configuration option for selecting the level of compactness of the GUI. There are five levels, from Very Compact to Very Spacious. So for example, the screenshots shown above are using the 'Spacious' level. In that level, there is some padding always visible between the pads, the window borders and the main menu. There is no such padding in 'Normal' mode.</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/S5T7gpCeMXI/AAAAAAAABag/t5DmI-D5E8I/s1600-h/NewGuiCompactOptions.png"><img src="http://3.bp.blogspot.com/_cHnO0qtZD7s/S5T7gpCeMXI/AAAAAAAABag/t5DmI-D5E8I/s400/NewGuiCompactOptions.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446254387588378994" style="cursor: pointer; width: 400px; height: 287px; " /></a></div><div><br /></div><div><b>Zoomable tree views</b></div><div><br /></div><div>MonoDevelop has an option which allows choosing the font to use for the tree view pads such as the Solution pad or the Class pad. Those trees may be large for big projects, so users find it convenient to use a small font, which allows seeing more information at once.</div><div><br /></div><div>To make font reduction easier and more handy, I added a Zoom capability to the tree pads. So to zoom, all you have to do is hold the Control key and move the mouse wheel up and down (the standard zoom shortcuts can also be used for this, including Control+0 to reset the zoom). This screenshot shows the solution and class pads with different levels of zoom:</div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5UBJZdcbaI/AAAAAAAABa4/aHzR5IHzGbo/s1600-h/NewGuiZoomableTreeViews.png"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/S5UBJZdcbaI/AAAAAAAABa4/aHzR5IHzGbo/s400/NewGuiZoomableTreeViews.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5446260585339317666" style="cursor: pointer; width: 400px; height: 327px; " /></a></div><div><b><br /></b></div><div><b>Conclusion</b></div><div><br /></div><div>The changes I described are part of an ongoing effort to make MonoDevelop easier to use. There is more to come. It would be great to have feedback on the changes we are doing, so that we can further fine tune the interface for the 2.4 release.</div></div></div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com24tag:blogger.com,1999:blog-6440604575561980711.post-65277694857251921802010-02-24T17:11:00.003+01:002010-02-24T17:25:10.197+01:00Loading executables as MonoDevelop projectsMiguel recently <a href="http://tirania.org/blog/archive/2010/Feb-20.html">blogged</a> about a trick for loading an executable assembly as a project inside MonoDevelop. I have now added native support for this feature, which means that it is now possible to directly open a .exe or .dll as a project, or add it to an existing solution. Also, MonoDevelop will get the list of source code files from the debug info of the assembly (when available). For example, this is what you get when you open gmcs.exe:<div><div><div><br /></div><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/S4VR_np_KDI/AAAAAAAABZw/QlMgIZE2ZOw/s1600-h/asm-project.png"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/S4VR_np_KDI/AAAAAAAABZw/QlMgIZE2ZOw/s400/asm-project.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5441845878165809202" style="cursor: pointer; width: 400px; height: 331px; " /></a><br /><div><br /></div><div>The code just landed in SVN.</div></div></div></div>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com1tag:blogger.com,1999:blog-6440604575561980711.post-90084447412171987322009-09-29T19:19:00.002+02:002009-09-29T19:27:48.885+02:00.NET/Mono Code Camp: Registration is openRegistration for the upcoming .NET/Mono Code Camp in Spain is open and filling up quickly, so if you are interested in attending, <a href="http://codecamp.es/Reg%C3%ADstrate.aspx">register now</a>!<br /><br />The agenda has also been published. It includes talks about Mono, MonoDevelop, mocking frameworks running on Mono, iPhone development (with MonoTouch), Moonlight, .NET to Linux portability, Mono.Addins and other stuff.<br /><img src="file:///tmp/moz-screenshot.png" alt="" /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.codecamp.es"><img style="cursor: pointer; width: 112px; height: 66px;" src="http://codecamp.es/Portals/0/logos/sticker2.png" alt="" border="0" /></a>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com3tag:blogger.com,1999:blog-6440604575561980711.post-24045688160156132372009-08-31T23:33:00.004+02:002009-09-08T20:07:21.319+02:00.NET/Mono Code Camp in Tarragona: Call for Papers<table><tbody><tr><td>We have started planning the sessions for the <a href="http://codecamp.es/">.NET/Mono Code Camp</a> in Tarragona (Spain). The sessions are being organized in two tracks: a Mono track and an MSDN track. I plan to give at least a couple of talks: one about the upcoming release of MonoDevelop, and one about application extensibility based on Mono.Addins.<br /><br />If you are interested in giving a talk, it is now time let us know. You'll find <a href="http://codecamp.es/Speakers/tabid/65/language/es-ES/Default.aspx">here</a> a form you can use to submit your proposal. We will select the proposals we find more interesting, and we plan to pay the travel expenses for all speakers. Update: sessions are going to be held in spanish.<br />Update 2: we don't have a big budget, so we may not be able to pay full expenses to people coming from outside Spain.<br />Update 3: the deadline for the call for papers is September 11th.<br /><br />I like how the Code Camp is shaping up so far. It will be a chance to meet with spanish Mono hackers and users, but it will also be a good chance to talk about Mono and Linux to an audience which typically is very Microsoft-centric.<br /></td><td valign="top"><a href="http://codecamp.es/"><img src="http://1.bp.blogspot.com/_cHnO0qtZD7s/SktXcKy3pfI/AAAAAAAABF8/JuigJEosS9E/s1600/logo100.png" border="0/" /></a></td></tr></tbody></table>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com1tag:blogger.com,1999:blog-6440604575561980711.post-43715054242855149942009-08-03T22:17:00.000+02:002009-08-03T22:20:06.683+02:00MonoDevelop API OverviewI added a new document to the <a href="http://monodevelop.com/Developers/Articles">MonoDevelop developers documentation</a> page: <a href="http://monodevelop.com/Developers/Articles/API_Overview">API Overview</a>.<br /><br />The public MonoDevelop API is really extensive, and it is not easy for add-in developers to find out which part of the API they have to use to do certain operations. This document is basically a high level description of all functionality provided by the API, with information about which classes and objects provide that functionality. The document doesn't give much detail about how to use the API, this will come in separate feature-specific documents.<br /><br />I hope you find it useful.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com0tag:blogger.com,1999:blog-6440604575561980711.post-44478264935353866132009-07-30T12:13:00.000+02:002009-07-30T12:51:42.750+02:00Building with MSBuild/XBuild in MonoDevelopI committed today very basic support for building projects using <span style="font-weight: bold;">MSBuild / XBuild</span> instead of MonoDevelop's own build system. <a href="http://ankitjain.org/blog">Ankit</a> has been doing a lot of progress in XBuild, and it is mature enough to build complex projects. XBuild support is for now disabled by default. To try it, you'll have to enable it in the <span style="font-weight: bold;">Edit / Preferences / Build</span> options panel.<br /><br />The integration right now is simple because all it does is to launch the xbuild command in a separate process. That's not the best way of doing it, but the most straightforward. A more optimal option is to use the MSBuild API to load the project and launch the build. That's my next step, but there are some issues with it.<br /><br />The main problem is that MonoDevelop now supports multiple target runtimes and frameworks. Multiple frameworks are not a problem because MSBuild already has support for that, but it doesn't have support for multiple runtimes.<br /><br />Multiple runtimes means that for example when running MD on Windows, I can select either Mono or MS.NET as target runtime, and MD will build the project using the selected runtime. Each runtime has its own GAC and set of installed packages, even its own MSBuild version, so I can't use the MSBuild API to load and build the project. The only option in this case is to launch in an external process.<br /><br />There is however and additional and more hard to fix problem. To get the list of assemblies referenced by a project (for example to do code completion), MonoDevelop right now just enumerates the reference elements defined in the project. When using MSBuild that's not fully correct anymore, since custom targets and tasks may inject references which are not explicitly set in the project. So the only way of getting the real list of references is by loading the MSBuild project and evaluating it, and that won't work when targeting a runtime other that then one running MD.<br /><br />Anyway, this basic support we have now is good enough for many projects. I'll go step by step.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com1tag:blogger.com,1999:blog-6440604575561980711.post-62532718792566375032009-07-01T14:15:00.004+02:002009-07-01T14:37:15.516+02:00.NET/Mono Code Camp in Tarragona, Spain<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/SktXcKy3pfI/AAAAAAAABF8/JuigJEosS9E/s1600-h/logo100.png"><img style="cursor: pointer; width: 100px; height: 87px;" src="http://1.bp.blogspot.com/_cHnO0qtZD7s/SktXcKy3pfI/AAAAAAAABF8/JuigJEosS9E/s400/logo100.png" alt="" id="BLOGGER_PHOTO_ID_5353468723505636850" border="0" /></a><br /><br />It's official: there will be a .NET/Mono Code Camp in Spain in October. The proposal was made some months ago by CatDotNet, a local .NET user group. Several other .NET user groups quickly joined. The initial idea was to do a traditional Microsoft.NET Code Camp, but I though it would be a good chance of putting together .NET and Mono developers, since after all we have a lot to share. Everybody thought this was an awesome idea.<br /><br />This will be a good chance for learning and sharing knowledge about .NET and Mono, but I'd also like it to be a meeting point for the Spanish Mono community. I'll be there giving some talks, and I hope other Mono hackers can come too. If you want to propose a talk, or you want to contribute please join the <a href="http://groups.google.com/group/codecamp-tarragona-2009">official forum</a>.<br /><br />More info about the Code Camp in the official web site: <a href="http://www.codecamp.es/">www.codecamp.es</a>.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/SktXiNyMWkI/AAAAAAAABGE/YDx0h65HtPg/s1600-h/sticker2.png"><img style="cursor: pointer; width: 112px; height: 66px;" src="http://2.bp.blogspot.com/_cHnO0qtZD7s/SktXiNyMWkI/AAAAAAAABGE/YDx0h65HtPg/s400/sticker2.png" alt="" id="BLOGGER_PHOTO_ID_5353468827387320898" border="0" /></a>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com0tag:blogger.com,1999:blog-6440604575561980711.post-917219330159001872009-06-25T21:02:00.004+02:002009-06-30T03:12:22.223+02:00How to build MonoDevelop with Visual StudioHow to build MonoDevelop with Visual Studio in five easy steps:<br /><ul><li>Install GTK# (get installer <a href="http://monodevelop.com/Download/Windows_Preview">here</a>)</li><li>Install the Mono Libraries (get installer <a href="http://monodevelop.com/Download/Windows_Preview">here</a>)</li><li>Get MonoDevelop from SVN (<span style="font-weight: bold;">update</span>: instructions <a href="http://monodevelop.com/Download#Getting_MonoDevelop_from_the_Subversion_repository">here</a>)<br /></li><li>Open main/Main.sln in Visual Studio</li><li>Press F5 (<span style="font-weight: bold;">update</span>: make sure you have the configuration <span style="font-weight: bold;">DebugWin32</span> and platform <span style="font-weight: bold;">x86</span> selected).<br /></li></ul>Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com5tag:blogger.com,1999:blog-6440604575561980711.post-78098697231578625072009-06-19T12:07:00.003+02:002009-06-19T12:27:43.473+02:00New MonoDevelop installer for WindowsA new MonoDevelop installer for Windows is available. This release has many fixes and improvements:<br /><ul><li>Performance of the text editor greatly improved, thanks to a new text rendering logic cooked by Mike Krüeger.</li><li>The debugger is now more reliable, it properly handles enum values, and it now has an 'immediate' console.</li><li>The NUnit add-in now works.</li><li>Version Control now has a new Create Patch command, thanks to Levi Bard.</li><li>A new C# formatter, with support for per-project/solution formatting options.<br /></li><li>MD now logs debug and error output to a file located in your AppData/MonoDevelop/log.txt, so if you get a crash or something you may find some info there.</li><li>Many other bug fixes.</li></ul>The new installer is available <a href="http://monodevelop.com/Download/Windows_Preview">here</a>. Worth trying!Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com19tag:blogger.com,1999:blog-6440604575561980711.post-48422588560273559942009-06-03T21:13:00.004+02:002009-06-03T22:11:40.295+02:00MonoDevelop installer for WindowsSince my last blog post about <a href="http://foodformonkeys.blogspot.com/2009/05/monodevelop-on-windows.html">MonoDevelop on Windows</a>, things have improved a lot. I focused my work in making MD good enough to be used for everyday MD hacking. We are still not there, but close. Here are some improvements done in the past week:<br /><ul><li>Fixed the <span style="font-weight: bold;">GTK# designer</span> add-in. It is now fully working.</li><li>Implemented a new backend for the <span style="font-weight: bold;">Subversion add-in</span>. I tried using the add-in we have for Linux, but the libraries I could find for Win32 have some differences in the API and the bindings doesn't work. I finally decided to refactor a bit the SVN add-in to support different backends, and implemented a new one based on SharpSvn. So the SVN add-in is also fully working.<br /></li><li>Added support for <span style="font-weight: bold;">debugging</span>, based on the debugger that comes with .NET. This is still work in progress, although most of features already work: stepping, breakpoints, inspecting variables with drill down and evaluation of expressions.<br /></li><li>Support for <span style="font-weight: bold;">.NET 4.0</span>. This new version can now be selected in the project properties.</li><li>Improved the look of the main window. Reduced some spacing, improved the rendering of the tabs when docking several pads together, and other cosmetic fixes.<br /></li><li>Improved the performance of the text editor. It now feels more responsive.</li><li>... and many other fixes.<br /></li></ul>There are still some stability issues, and are several add-ins are still untested, but MD is starting to look great on Windows. GTK+ with the Vista theme looks really nice. Here are some screenshots of the GTK# designer and the debugger:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/SibYVc5hvzI/AAAAAAAABFU/0WOVGVOtJbM/s1600-h/SteticWin32.png"><img style="cursor: pointer; width: 400px; height: 301px;" src="http://3.bp.blogspot.com/_cHnO0qtZD7s/SibYVc5hvzI/AAAAAAAABFU/0WOVGVOtJbM/s400/SteticWin32.png" alt="" id="BLOGGER_PHOTO_ID_5343195870968004402" border="0" /></a><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_cHnO0qtZD7s/SibYdgzKReI/AAAAAAAABFc/AsXptlb83qg/s1600-h/DebuggerWin32.png"><img style="cursor: pointer; width: 400px; height: 301px;" src="http://1.bp.blogspot.com/_cHnO0qtZD7s/SibYdgzKReI/AAAAAAAABFc/AsXptlb83qg/s400/DebuggerWin32.png" alt="" id="BLOGGER_PHOTO_ID_5343196009453995490" border="0" /></a><br /><br />Now, here is what you've been waiting for: a <span style="font-weight: bold;">MonoDevelop installer for Windows</span>. You can get it from the <a href="http://monodevelop.com/Download/Windows_Preview">Windows Preview</a> page in the MD site. Read carefully the instructions in that page. You'll have to install the latest GTK# package, also linked in that page. Also, beware that this is a <span style="font-weight: bold;">preview</span> built from trunk, so you can expect to find stability issues. In any case, bug reports are always welcome. Enjoy!Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com30tag:blogger.com,1999:blog-6440604575561980711.post-1347673749764513472009-05-06T13:00:00.005+02:002009-05-06T13:30:16.206+02:00MonoDevelop on WindowsBesides the efforts to make MonoDevelop play nice in MacOS X, we've also been doing progress in the Windows side. This is how it looks right now:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/SgFvBoOF8uI/AAAAAAAABE8/qxrb_yAQS5o/s1600-h/MDWin32.jpg"><img style="cursor: pointer; width: 400px; height: 318px;" src="http://3.bp.blogspot.com/_cHnO0qtZD7s/SgFvBoOF8uI/AAAAAAAABE8/qxrb_yAQS5o/s400/MDWin32.jpg" alt="" id="BLOGGER_PHOTO_ID_5332665507550458594" border="0" /></a><br /><br />What you see above is MonoDevelop running on Windows Vista using Microsoft.NET. A lot of effort has gone into making it easy to build MonoDevelop. Mike Kestner has been working on an installer that provides the core libraries on which MD depends on (such as Mono.Addins), and I hope it will be soon available so that people can start using it. We've also fixed the MD project files, so now MD can be built by just opening the main solution in Visual Studio and clicking on build.<br /><br />A new feature I had to add to MD in order to properly support Windows, is support for multiple runtimes. Thanks to that feature it is possible to select in the IDE which runtime you want to use for building and running a solution. It can be done using a combo box in the toolbar:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/SgFxXovd2GI/AAAAAAAABFE/dkeadQjA3nA/s1600-h/MDWin32Runtimes.jpg"><img style="cursor: pointer; width: 164px; height: 188px;" src="http://3.bp.blogspot.com/_cHnO0qtZD7s/SgFxXovd2GI/AAAAAAAABFE/dkeadQjA3nA/s400/MDWin32Runtimes.jpg" alt="" id="BLOGGER_PHOTO_ID_5332668084670814306" border="0" /></a><br />There is also a "Run With" menu which shows all runtimes, so you can run a specific project using a specific runtime. Notice that support for multiple runtimes is not specific to Windows, it is also supported in Linux. In this case, you can register several mono runtimes versions installed in different prefixes (I'll blog with more detail about that soon).<br /><br />The basic funcitonality already works in Windows: loading a project, building running. Other features still don't work, such as the gtk# designer, the nunit add-in or the Subversion add-in. I haven't yet tried none of the add-ins in 'extras'.<br /><br />I hope we'll be able to make a 2.2 release with a very decent Windows support. I'll keep posting and <a href="http://twitter.com/slluis">twittering</a> updates.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com11tag:blogger.com,1999:blog-6440604575561980711.post-46204614447295984192009-02-17T17:33:00.004+01:002009-02-17T19:51:55.594+01:00MonoDevelop 2.0 beta 1Yet another step towards 2.0 release. We released Beta 1 last week with many fixes and some new interesting features (here are the <a href="http://www.monodevelop.com/Release_notes_for_MonoDevelop_2.0_Beta_1">release notes</a>).<br /><br />The one I like more is the support for <span style="font-weight: bold;">per-project policies</span>. This feature has been planned for long time but other work has been delaying it. Me and Michael Hutchinson had a chance to talk quite a lot about it while I was at Boston a couple of months ago. The policies model allows setting properties at global, solution, folder and project levels. Settings such as tab width can be defined in any of those levels and will cascade down to the lower levels (where it can be overriden if required). Many settings are already available in this way, and many more will be in future releases.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cHnO0qtZD7s/SZsGYJTx0sI/AAAAAAAAA-g/_0J6uSm8o38/s1600-h/md-commit-policies.png"><img style="cursor: pointer; width: 400px; height: 292px;" src="http://3.bp.blogspot.com/_cHnO0qtZD7s/SZsGYJTx0sI/AAAAAAAAA-g/_0J6uSm8o38/s400/md-commit-policies.png" alt="" id="BLOGGER_PHOTO_ID_5303839998044394178" border="0" /></a><br /><br />Another new feature, or rather improvement, is the support for <span style="font-weight: bold;">multiple frameworks</span>. MD already had support for targeting the 1.1/2.0 CLR for quite a long time, but did not have the concept of 'target framework', which is more generic. For example, .NET 3.0 is based on the 2.0 CLR and it just includes some additional assemblies. What complicates things a bit is that Mono does not follow the .NET releases, so for example Mono 2.0 includes bits from all .NET versions. To simplify all this and to be compatible with MSBuild, it is now possible to select the target .NET framework, which includes 1.1, 2.0, 2.1 (Silverlight), 3.0 and 3.5. The project system is fully aware of the chosen target framework, so for example it won't let you reference a 3.5 project from a 3.0 project.<br /><br />The source editor keeps improving in many ways. Mike Krueger has spent quite a lot of time fixing issues in code completion, which now works in many more contexts. My contribution on code completion (besides stabilization work in the parser database) is support for completion of generic types with constraints. For example, in the following class code completion is showing the Dispose method because there is a constraint forcing the generic argument to implement it:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_cHnO0qtZD7s/SZsE_-ZpYcI/AAAAAAAAA-Y/yO8rDCqXOGk/s1600-h/md-constraint-completion.png"><img style="cursor: pointer; width: 357px; height: 105px;" src="http://2.bp.blogspot.com/_cHnO0qtZD7s/SZsE_-ZpYcI/AAAAAAAAA-Y/yO8rDCqXOGk/s400/md-constraint-completion.png" alt="" id="BLOGGER_PHOTO_ID_5303838483287728578" border="0" /></a><br /><br />There are other improvements, such as the new Go to File dialog I <a href="http://foodformonkeys.blogspot.com/2009/01/one-of-most-unknown-yet-most-useful.html">blogged about</a> some time ago, better support for completion in ASP.NET projects, and fixes in the GTK# designer. There is still a lot of work to do, but we are getting close to 2.0.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com8tag:blogger.com,1999:blog-6440604575561980711.post-70239590654205288152009-01-14T13:35:00.004+01:002009-01-14T14:06:51.778+01:00One of the most unknown, yet most useful feature of MonoDevelop is the Go to File dialog. This dialog can be quickly opened by pressing <span style="font-weight: bold;">Alt + Shift + O</span>, and it can be used to quickly find and open a file of the project.<br /><br />Some weeks ago I did several performance improvements, and introduced support for <span style="font-weight: bold;">acronym matching</span>. The filtering algorithm tries to find the best match, not only by searching substrings, but also by splitting the search string in several parts and trying to match them through all the words that compose the string being checked. This is an example:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_cHnO0qtZD7s/SW3icLy8h_I/AAAAAAAAA-A/9uZw6tVShnI/s1600-h/md-goto-file.png"><img style="cursor: pointer; width: 400px; height: 322px;" src="http://4.bp.blogspot.com/_cHnO0qtZD7s/SW3icLy8h_I/AAAAAAAAA-A/9uZw6tVShnI/s400/md-goto-file.png" alt="" id="BLOGGER_PHOTO_ID_5291134111060887538" border="0" /></a><br /><br />When filtering files, the algorithm tries to match the file name, and if it fails, then it tries to match the whole file path. This allows filtering by directory. Following the example, if I type 'xml/ccomdata', it will fill find results under the MonoDevelop.XmlEditor.Completion directory. When there are several files with the same name, the list shows the parent directory name next to the file (inside brackets), so you can decide which one is the good one. Besides filtering, the dialog automatically highlights what it considers the best match.<br /><br />After several weeks of use, I'm very happy about how the matching algorithm is working. Most of the time it manages to highlight the file I'm looking for by just typing 3 or 4 letters.<br /><br />BTW, the same dialog supports searching by type name, using the same algorithm. In this case the shortcut is Control+Shift+T.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com1tag:blogger.com,1999:blog-6440604575561980711.post-86572835425738699682008-11-24T22:43:00.002+01:002008-11-24T23:37:18.504+01:00MonoDevelop 2.0 alpha 2 is outLast Friday we released MonoDevelop 2.0 alpha 2. This is an exciting release because for the first time it includes debugger integration. This integration is not yet perfect, the debugger is not yet 100% stable and not all features are available, but we finally have some debugging support. This has been the #1 feature request for long time. You can take a look at my <a href="http://foodformonkeys.blogspot.com/2008/07/debugger-screenshotting.html">previous post about the debugger</a> to get an idea of what it looks like.<br /><br />In addition to the Mono Debugger (<span style="font-weight: bold;">MDB</span>), I also have spent some time improving the <span style="font-weight: bold;">GDB</span> integration. We now have support for expression evaluation, which can be used in conditional breakpoints and tracepoints. The debugging service in MonoDevelop is extensible, so we can plug support for different debuggers into it. I hope we can add support for debugging other non-.net based languages in the future.<br /><br />Anyway, here is a screenshot of a debug tooltip in a GDB debug session:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_cHnO0qtZD7s/SHSrgtPv26I/AAAAAAAAAns/Qe8XrBAuazk/s400/DebugCapturaTipCompletionGdb.png"><img style="cursor: pointer; width: 400px; height: 268px;" src="http://bp3.blogger.com/_cHnO0qtZD7s/SHSrgtPv26I/AAAAAAAAAns/Qe8XrBAuazk/s400/DebugCapturaTipCompletionGdb.png" alt="" border="0" /></a><br /><br />The other big improvement in alpha 2 is the <span style="font-weight: bold;">new code completion engine</span>, on which Mike Krueger has been working. The new engine supports "aggresive" code completion, which means that the completion window will be shown in any context by just typing the first char of an identifier. It also has some nice features such as automatic insertion of event handlers or anonymous methods when completing an event subscription. In addition, the C# parser has been upgraded to support <span style="font-weight: bold;">C# 3</span>, and we already support some of the new C# features, such as completion of extension methods. The new engine still needs polishing and performance improvements, but it is looking great.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.monodevelop.com/files/thumb/7/7d/800px-Md-event-completion.png"><img style="cursor: pointer; width: 638px; height: 122px;" src="http://www.monodevelop.com/files/thumb/7/7d/800px-Md-event-completion.png" alt="" border="0" /></a><br /><br />Michael Hutchinson has done a great job improving the editing experience for <span style="font-weight: bold;">ASP.NET, HTML</span> and <span style="font-weight: bold;">XML</span> files. There is better support for code completion and CodeBehind files. Compatibility with Visual Studio 2008 has improved, and we now have preliminary support for creating <span style="font-weight: bold;">Moonlight projects</span>. Many hackers will also be interested in the new <span style="font-weight: bold;">vi mode</span> that has been implemented for the text editor.<br /><br />The <span style="font-weight: bold;">GTK# designer</span> has also some improvements. Mike Kestner became the maintainer of the designer some months ago, and he's been learning about the inner workings, and doing some fixes and improvements. One of the main changes is the simplification of the GTK# settings panel. It is not necessary to explicitly enable GTK# support on projects in order to use the designer. Now it can be done by just adding a reference to GTK#. Also, exporting a widget so it can be used in another project is as simple as applying a [ToolboxItem] attribute to the widget class.<br /><br />Ankit Jain did a great job with the new <span style="font-weight: bold;">Override/Implement dialog</span>, which allows to easily implement members defined in a base class or interface. Here is a screenhot:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.monodevelop.com/files/1/1e/Md-override-members.png"><img style="cursor: pointer; width: 409px; height: 338px;" src="http://www.monodevelop.com/files/1/1e/Md-override-members.png" alt="" border="0" /></a><br /><br />Ankit is now working behind the scenes to complete <span style="font-weight: bold;">xbuild</span>, our MSBuild implementation. The mid term plan is to replace MD's build system by xbuild, but this won't happen before MD 2.0.<br /><br />There are many other improvements in version control support, project management and others, but you'll have to take a look at the <a href="http://www.monodevelop.com/Release_notes_for_MonoDevelop_2.0_Alpha_2">release notes</a> to know more.<br /><br />In the following weeks we are going to focus on bug fixing, and we plan to release a 2.0 Beta 1 soon (the plan was to release before Christmas, but holidays may not permit it). In the meanwhile I hope you find alpha 2 useful and file any bug you can find so we can fix it to make MD 2.0 an awesome release.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com5tag:blogger.com,1999:blog-6440604575561980711.post-58336171808314907482008-09-06T02:08:00.002+02:002008-09-06T02:32:29.242+02:00Planning a short stay in BostonSince my girlfriend wants to learn English and I'll probably have to attend a meeting in Boston, we decided to put it all together and we are planning to stay a couple of months in Boston, from end October to end December. After 5 years working alone at home, it will be refreshing to work in an office together with non-virtual coworkers. It also comes at a good timing because we are planning to release MonoDevelop 2.0 around the end of the year.<br /><br />This is going to be an interesting end of year.<br /><br />BTW, I'm currently looking for a small apartment (or big room) to rent, ideally around Cambridge. Unfortunately I'm not having much success, since apartments I found are either too expensive, or not available for those two months. So if you know about some good place, information will he highly appreciated! (mail lluis at novell dot com).Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com6tag:blogger.com,1999:blog-6440604575561980711.post-89353766844651768702008-07-09T14:21:00.003+02:002009-06-21T23:21:55.704+02:00Debugger screenshottingThe debugger integration in MonoDevelop is progressing, lots of work in the past weeks. I'm going to show what is supported right now, altough much work is still left to make everything stable.<br /><br />Everything I'm showing here works both for the <span style="font-weight: bold;">MDB</span> and <span style="font-weight: bold;">GDB</span> backends, unless explicitly stated.<br /><br />First of all, this is the Attach to Process window. Notice the "Debugger" combo at the bottom. It allows you selecting which debugger you want to use to start the debug session (MDB or GDB):<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_cHnO0qtZD7s/SHSWlE2GCcI/AAAAAAAAAmk/xeCi6iIuzyE/s1600-h/DebugCapturaAttachProcess.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_cHnO0qtZD7s/SHSWlE2GCcI/AAAAAAAAAmk/xeCi6iIuzyE/s400/DebugCapturaAttachProcess.png" alt="" id="BLOGGER_PHOTO_ID_5220963431729203650" border="0" /></a><br /><br />Breakpoints have a nicer look, and there is support for enabling/disabling. Also, when starting a debug session, invalid breakpoints (e.g. breakpoints placed in lines without statements) will be rendered as disabled.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_cHnO0qtZD7s/SHSZurqIuII/AAAAAAAAAm0/7rD4dm_RKRU/s1600-h/DebugCapturaBreakpoints.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_cHnO0qtZD7s/SHSZurqIuII/AAAAAAAAAm0/7rD4dm_RKRU/s400/DebugCapturaBreakpoints.png" alt="" id="BLOGGER_PHOTO_ID_5220966895301736578" border="0" /></a><br /><br />The dissassembly window shows the assembler mixed with the source code when available. This mixed view is not supported in MDB, due to limitations in the API (for MDB, dissassembly without source code will be shown). The disassembly view supports single-stepping of assembler instructions.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_cHnO0qtZD7s/SHSbMBz3YcI/AAAAAAAAAm8/OaOWPjlc7qw/s1600-h/DebugCapturaDisassembly.png"><img style="cursor: pointer;" src="http://bp1.blogger.com/_cHnO0qtZD7s/SHSbMBz3YcI/AAAAAAAAAm8/OaOWPjlc7qw/s400/DebugCapturaDisassembly.png" alt="" id="BLOGGER_PHOTO_ID_5220968498975957442" border="0" /></a><br /><br />Big improvements in the Watch View. The list now has icons for each type of member. Drill down has been improved, for example big arrays are now split in 'ranges' which makes easier to locate elements.<br /><br />The Watch View now supports expressions. The expression evaluator is based on NRefactory, and although not all C# expressions are supported, many of them are (for example, arithmetic operations, method calls, array access, conditional expressions, etc). Expressions can be used both to select what to show in the view, and to assign values to variables or members. For GDB, the GDB expression evaluator is used. The screenshot below shows some examples. In one of the examples, the value of an expression will be assigned to the variable 'n':<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_cHnO0qtZD7s/SHSmw5n0WEI/AAAAAAAAAnE/UtdUrMqismk/s1600-h/DebugCapturaExpressions.png"><img style="cursor: pointer;" src="http://bp1.blogger.com/_cHnO0qtZD7s/SHSmw5n0WEI/AAAAAAAAAnE/UtdUrMqismk/s400/DebugCapturaExpressions.png" alt="" id="BLOGGER_PHOTO_ID_5220981227061008450" border="0" /></a><br /><br />The Watch View can also be used to inspect types. The view will show all static members of a type. Namespaces are also supported. For example, you can enter the namespace 'System' and drill down through all types and inspect their static members (not supported in GDB):<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_cHnO0qtZD7s/SHSnr0OvPeI/AAAAAAAAAnM/HzLqdRIphso/s1600-h/DebugCapturaTypeDrilldown.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_cHnO0qtZD7s/SHSnr0OvPeI/AAAAAAAAAnM/HzLqdRIphso/s400/DebugCapturaTypeDrilldown.png" alt="" id="BLOGGER_PHOTO_ID_5220982239225920994" border="0" /></a><br /><br />The Watch View also supports code completion (both for entering expressions and values). Code completion is based on data from the debugger backend, not on the MonoDevelop parser database, so it works for MDB and GDB, and even when debugging an application for which there isn't a MonoDevelop project:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_cHnO0qtZD7s/SHSpNk0sSwI/AAAAAAAAAnU/Xr527RB7GGI/s1600-h/DebugCapturaCompletion.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_cHnO0qtZD7s/SHSpNk0sSwI/AAAAAAAAAnU/Xr527RB7GGI/s400/DebugCapturaCompletion.png" alt="" id="BLOGGER_PHOTO_ID_5220983918717324034" border="0" /></a><br /><br />Another nice feature is the support for debug tooltips in the editor. When moving the mouse over a variable or member, a tooltip will show its value. The tooltip is interactive and allows drilling down and modifying values just like the watch window:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_cHnO0qtZD7s/SHSqQoUPDLI/AAAAAAAAAnc/Imm8a0g3208/s1600-h/DebugCapturaTooltip.png"><img style="cursor: pointer;" src="http://bp3.blogger.com/_cHnO0qtZD7s/SHSqQoUPDLI/AAAAAAAAAnc/Imm8a0g3208/s400/DebugCapturaTooltip.png" alt="" id="BLOGGER_PHOTO_ID_5220985070706166962" border="0" /></a><br /><br />It is also possible to use tooltips to inspect the value of expressions:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_cHnO0qtZD7s/SHSqsM-3aQI/AAAAAAAAAnk/1XDtbw5ADCg/s1600-h/DebugCapturaEvalTooltip.png"><img style="cursor: pointer;" src="http://bp1.blogger.com/_cHnO0qtZD7s/SHSqsM-3aQI/AAAAAAAAAnk/1XDtbw5ADCg/s400/DebugCapturaEvalTooltip.png" alt="" id="BLOGGER_PHOTO_ID_5220985544405117186" border="0" /></a><br /><br />And works for GDB too! This final screenshot shows a Mono process attached with GDB, a debug tooltip for a MonoMethod, and a member of that struct being modified using code completion:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_cHnO0qtZD7s/SHSrgtPv26I/AAAAAAAAAns/Qe8XrBAuazk/s1600-h/DebugCapturaTipCompletionGdb.png"><img style="cursor: pointer;" src="http://bp3.blogger.com/_cHnO0qtZD7s/SHSrgtPv26I/AAAAAAAAAns/Qe8XrBAuazk/s400/DebugCapturaTipCompletionGdb.png" alt="" id="BLOGGER_PHOTO_ID_5220986446419057570" border="0" /></a><br /><br />That's all for now. If you want to try it you'll have to get everything from SVN (see my <a href="http://foodformonkeys.blogspot.com/2008/06/debugger-integration-in-monodevelop.html">last post</a>).Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com22tag:blogger.com,1999:blog-6440604575561980711.post-6120979409348946632008-06-26T10:24:00.001+02:002008-06-26T10:24:53.547+02:00Debugger integration in MonoDevelopMany people has been asking about the status of the debugger integration in MonoDevelop, so I thought it would be a good idea to post a quick status report.<br /><br />The short answer is that we are working on it. The debugger integration work has started, and there is already support for breakpoints, stepping, call stack view, current frame selection, basic variable watch window, and attaching/detaching to/from running processes. All this is working in MonoDevelop from SVN (still with some stability issues).<br /><br />And here are some big news: we are integrating not only MDB (the Mono debugger), but also GDB, and thanks to the debugger abstraction layer we built in MD, we'll be able to use the same GUI for both debuggers. Two debuggers for the price of one!<br /><br />We are going to do a MonoDevelop release next week. However, this release will not include the debugger integration because it still depends on Mono and MDB from SVN and we would not be able to package it. If you want to try the debugger (beware, this is work in progress), you have to do the following:<br /><ul><li>Get and build Mono from SVN.</li><li>Get and build the Mono Debugger from SVN.</li><li>Get MonoDevelop from SVN.</li><li>At the MonoDevelop's top-level directory, run './configure --select'. Make sure the extras/MonoDevelop.Debugger.Mdb add-in is selected (and/or extras/MonoDevelop.Debugger.Gdb if you want GDB support).</li><li>Build MonoDevelop.<br /></li></ul>If you only want to try GDB, you don't need Mono and MonoDebugger from SVN, getting latest MonoDevelop is enough.Lluishttp://www.blogger.com/profile/16329464095855853723noreply@blogger.com4