MonoDevelop

I started the XWT 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 Xamarin! Anyway, let’s go ahead. XWT is an open-source cross-platform UI toolkit for Mono and ... [More] .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:GTK backendCocoa backendI 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.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:The designer running on GTK in MonoDevelopThe designer running on WPF in Visual StudioXWT vs Native ToolkitsAt 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?XWT has three important design features: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.XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets.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. 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.Design PrinciplesXWT 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: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.Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK).No concept of GdkWindow. You have a widget, that’s all.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.FeaturesHere are some details about what’s currently supported by XWT:XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows).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.The basic widget library is mostly complete.It has a drawing API, very similar to Cairo.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.XWT can be extended in different ways.Applications can create subclasses of XWT widgets, or create new widgets.New backends can be plugged into XWTExisting backends can be extendedThe API is not yet stable and can change at any time.FutureThe 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.If you are interested in XWT, you can get the source code from here:https://github.com/mono/xwtThere is also a mailing list:http://groups.google.com/group/xwt-listAnd an IRC channel:irc://irc.gimp.org/xwtContributions are welcome! [Less]

I started the XWT 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 Xamarin! Anyway, let’s go ahead. XWT is an open-source cross-platform UI toolkit for Mono and ... [More] .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:GTK backendCocoa backendI 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.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:The designer running on GTK in MonoDevelopThe designer running on WPF in Visual StudioXWT vs Native ToolkitsAt 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?XWT has three important design features: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.XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets.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. 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.Design PrinciplesXWT 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: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.Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK).No concept of GdkWindow. You have a widget, that’s all.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.FeaturesHere are some details about what’s currently supported by XWT:XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows).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.The basic widget library is mostly complete.It has a drawing API, very similar to Cairo.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.XWT can be extended in different ways.Applications can create subclasses of XWT widgets, or create new widgets.New backends can be plugged into XWTExisting backends can be extendedThe API is not yet stable and can change at any time.FutureThe 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.If you are interested in XWT, you can get the source code from here:https://github.com/mono/xwtThere is also a mailing list:http://groups.google.com/group/xwt-listAnd an IRC channel:irc://irc.gimp.org/xwtContributions are welcome! [Less]

I started the XWT 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 Xamarin! Anyway, let’s go ahead. XWT is an open-source cross-platform UI toolkit for Mono and ... [More] .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: GTK backend Cocoa backend 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.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: The designer running on GTK in MonoDevelop The designer running on WPF in Visual Studio XWT vs Native ToolkitsAt 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?XWT has three important design features: 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. XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets. 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.  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.Design PrinciplesXWT 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: 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. Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK). No concept of GdkWindow. You have a widget, that’s all. 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.FeaturesHere are some details about what’s currently supported by XWT: XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows). 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. The basic widget library is mostly complete. It has a drawing API, very similar to Cairo. 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. XWT can be extended in different ways. Applications can create subclasses of XWT widgets, or create new widgets. New backends can be plugged into XWT Existing backends can be extended The API is not yet stable and can change at any time. FutureThe 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.If you are interested in XWT, you can get the source code from here:https://github.com/mono/xwtThere is also a mailing list:http://groups.google.com/group/xwt-listAnd an IRC channel:irc://irc.gimp.org/xwtContributions are welcome! [Less]

I started the XWT 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 Xamarin! Anyway, let’s go ahead. XWT is an open-source cross-platform UI toolkit for Mono and ... [More] .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: GTK backend Cocoa backend 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.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: The designer running on GTK in MonoDevelop The designer running on WPF in Visual Studio XWT vs Native ToolkitsAt 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?XWT has three important design features: 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. XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets. 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.  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.Design PrinciplesXWT 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: 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. Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK). No concept of GdkWindow. You have a widget, that’s all. 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.FeaturesHere are some details about what’s currently supported by XWT: XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows). 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. The basic widget library is mostly complete. It has a drawing API, very similar to Cairo. 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. XWT can be extended in different ways. Applications can create subclasses of XWT widgets, or create new widgets. New backends can be plugged into XWT Existing backends can be extended The API is not yet stable and can change at any time. FutureThe 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.If you are interested in XWT, you can get the source code from here:https://github.com/mono/xwtThere is also a mailing list:http://groups.google.com/group/xwt-listAnd an IRC channel:irc://irc.gimp.org/xwtContributions are welcome! [Less]

MonoDevelop 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.The first new big feature is support for GIT. This was long time due, especially since Mono and MonoDevelop ... [More] itself moved to GIT. I already blogged about it 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.We have also spent some time improving all the version control views. 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.Another big change in this release is the new MCS based parser and formatting engine. 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.We also added in this release support for user defined policies. 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.Another feature we added is support for IL disassembly in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies.Finally, we also have a brand new add-in manager, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in addins.monodevelop.com, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users.Update: forgot to mention one important improvement that has been requested by Mac users for long time: support for native OSX dialogs. Message and file dialogs on Mac now use the native UI toolkit.There are many other improvements and new features in this release. Take a look at What's new in MonoDevelop 2.6 if you want to know more. [Less]

MonoDevelop 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.The first new big feature is support for GIT. This was long time due, especially since Mono and MonoDevelop ... [More] itself moved to GIT. I already blogged about it 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. We have also spent some time improving all the version control views. 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. Another big change in this release is the new MCS based parser and formatting engine. 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. We also added in this release support for user defined policies. 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. Another feature we added is support for IL disassembly in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies. Finally, we also have a brand new add-in manager, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in addins.monodevelop.com, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users. Update: forgot to mention one important improvement that has been requested by Mac users for long time: support for native OSX dialogs. Message and file dialogs on Mac now use the native UI toolkit. There are many other improvements and new features in this release. Take a look at What's new in MonoDevelop 2.6 if you want to know more. [Less]

MonoDevelop 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.The first new big feature is support for GIT. This was long time due, especially since Mono and MonoDevelop ... [More] itself moved to GIT. I already blogged about it 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. We have also spent some time improving all the version control views. 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. Another big change in this release is the new MCS based parser and formatting engine. 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. We also added in this release support for user defined policies. 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. Another feature we added is support for IL disassembly in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies. Finally, we also have a brand new add-in manager, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in addins.monodevelop.com, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users. Update: forgot to mention one important improvement that has been requested by Mac users for long time: support for native OSX dialogs. Message and file dialogs on Mac now use the native UI toolkit. There are many other improvements and new features in this release. Take a look at What's new in MonoDevelop 2.6 if you want to know more. [Less]

MonoDevelop 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.The first new big feature is support for GIT. This was long time due, especially since Mono and MonoDevelop ... [More] itself moved to GIT. I already blogged about it 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.We have also spent some time improving all the version control views. 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.Another big change in this release is the new MCS based parser and formatting engine. 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.We also added in this release support for user defined policies. 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.Another feature we added is support for IL disassembly in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies.Finally, we also have a brand new add-in manager, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in addins.monodevelop.com, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users.Update: forgot to mention one important improvement that has been requested by Mac users for long time: support for native OSX dialogs. Message and file dialogs on Mac now use the native UI toolkit.There are many other improvements and new features in this release. Take a look at What's new in MonoDevelop 2.6 if you want to know more. [Less]

MonoDevelop 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 ... [More] sort of random locks and crashes.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:https://github.com/slluis/gui-thread-checkTo use it, build and install the module, and then run your application withthe command: mono --profile=gui-thread-check yourapp.exeIf the profiler is properly installed, you'll see an output like this:*** Running with gui-thread-check ****** GUI THREAD INITIALIZED: 2861676352While the application is running, if the profiler detects a non-gui threadinvoking gtk methods, it will print a warning message together with astack trace. For example:*** GTK CALL NOT IN GUI THREAD: Widget.gtk_widget_get_parent Widget.get_Parent SourceEditorWidget.get_TextEditor SourceEditorWidget.get_Document SourceEditorWidget.HandleParseInformationUpdaterWorkerThreadDoWork BackgroundWorker.OnDoWork BackgroundWorker.ProcessWorker [Less]

MonoDevelop 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 ... [More] sort of random locks and crashes.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:https://github.com/slluis/gui-thread-checkTo use it, build and install the module, and then run your application withthe command: mono --profile=gui-thread-check yourapp.exeIf the profiler is properly installed, you'll see an output like this:*** Running with gui-thread-check ****** GUI THREAD INITIALIZED: 2861676352While the application is running, if the profiler detects a non-gui threadinvoking gtk methods, it will print a warning message together with astack trace. For example:*** GTK CALL NOT IN GUI THREAD: Widget.gtk_widget_get_parent Widget.get_Parent SourceEditorWidget.get_TextEditor SourceEditorWidget.get_Document SourceEditorWidget.HandleParseInformationUpdaterWorkerThreadDoWork BackgroundWorker.OnDoWork BackgroundWorker.ProcessWorker [Less]