We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles.
I have created a wiki page to track the feature capabilities and plans. There is also a "Visual Profiler" category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion will occur on mono-devel-list.
Tuesday, August 4, 2009
Tuesday, April 21, 2009
Gtk# for .net
Forgot to blog about this when it happened, but since I've gotten a couple of questions lately...
In February, we released a new version of the Gtk# for .net installer. It packages Gtk# 2.12.8 and the associated gtk+ binaries, including the registry keys necessary to build projects with MSBuild and add references using the references dialog in VS.
This single installer combines the managed development functionality previously provided by both the SDK and Runtime installers in a significantly smaller download than the old SDK installer, since it no longer ships many of the C development files packaged in the old installers. This installer also works properly on XP and Vista, unlike previous versions.
In the near future, we will be announcing the availability of additional installers supporting the use of mono libraries like Mono.Posix, Mono.GetOptions, and Mono.Addins on .Net and maybe a new application installer or two as well. Stay tuned.
In February, we released a new version of the Gtk# for .net installer. It packages Gtk# 2.12.8 and the associated gtk+ binaries, including the registry keys necessary to build projects with MSBuild and add references using the references dialog in VS.
This single installer combines the managed development functionality previously provided by both the SDK and Runtime installers in a significantly smaller download than the old SDK installer, since it no longer ships many of the C development files packaged in the old installers. This installer also works properly on XP and Vista, unlike previous versions.
In the near future, we will be announcing the availability of additional installers supporting the use of mono libraries like Mono.Posix, Mono.GetOptions, and Mono.Addins on .Net and maybe a new application installer or two as well. Stay tuned.
Wednesday, December 10, 2008
Gtk# for .Net installers
Tuesday, September 2, 2008
Hack Week: 1WPF
For Novell Hack week, instead of hacking on exert as I did in the past, I chose to spend some time on a MonoDevelop Gtk designer restructuring project I've been considering: one widget per design file.
The current designer architecture is based on project-level design files, saved in a special hidden directory along with generated source files needed to compile the designs. This design decision builds upon the existing stetic project-based file format. It complicates several common operations, however, some of which have open bug reports.
One problem is the ability to either copy or move widgets between projects. Another, is the ability to add existing widgets to new projects as "external files" so that a single design can be reused by multiple projects. When the design of the widget is saved as a child element of a project-level xml document, all of the above operations are considerably more complicated than if the widget design is contained in a standalone file.
I'm implementing this redesign as a new addin in MonoDevelop, so that I won't have to pay as much attention to feature parity with the existing designer. The hope is that at some point we can just switch the default designer to the new addin, once it reaches maturity. Based on the amount of work remaining, this will clearly be post-2.0.
Thus far, I've ported the existing addin extension code and begun the rework of the stetic WidgetDesigner. Currently supported features include:
Once I get the widget editor working, I'll probably go ahead and check in the addin for people to play around with. No current estimates on when that might be other than, "when it's ready."
The current designer architecture is based on project-level design files, saved in a special hidden directory along with generated source files needed to compile the designs. This design decision builds upon the existing stetic project-based file format. It complicates several common operations, however, some of which have open bug reports.
One problem is the ability to either copy or move widgets between projects. Another, is the ability to add existing widgets to new projects as "external files" so that a single design can be reused by multiple projects. When the design of the widget is saved as a child element of a project-level xml document, all of the above operations are considerably more complicated than if the widget design is contained in a standalone file.
I'm implementing this redesign as a new addin in MonoDevelop, so that I won't have to pay as much attention to feature parity with the existing designer. The hope is that at some point we can just switch the default designer to the new addin, once it reaches maturity. Based on the amount of work remaining, this will clearly be post-2.0.
Thus far, I've ported the existing addin extension code and begun the rework of the stetic WidgetDesigner. Currently supported features include:
- SolutionPad display bindings and extensions
- Grouping of related source, design, and codebehind files.
- A CodeDom based project template to create Application projects in mulitple languages.
- Project Compilation extensions to generate codebehind files, capable of compiling template projects.
- CodeDom templates for ActionGroups, Dialogs, Widgets, and Windows.
- Toolbox provider and loader.
- WidgetEditor built on existing stetic wrappers and class descriptions, currently view-only.
Once I get the widget editor working, I'll probably go ahead and check in the addin for people to play around with. No current estimates on when that might be other than, "when it's ready."
Friday, June 6, 2008
GObject Property Registration
Christian Hoff submitted a nice patch to Gtk# supporting GObject property registration on managed subclasses. This is a feature request we've seen off and on for a while now, especially from people writing Custom CellRenderers. Until this patch, it was necessary to use a CellDataFunc with custom cell renderers instead of using the SetAttributes mechanism exposed by Gtk.
I committed a little sample along with the patch to demonstrate its use.
I committed a little sample along with the patch to demonstrate its use.
Sunday, April 20, 2008
Standings and Exert Features
As of this evening, 5 quarters are finished. The prognostication standings:
Mike: 5
Maggie the Monkey and Jackson: 2
Been adding some new features to exert the last couple weekends. Last weekend, it was a couple new icons for swimming and cycling:
I also hacked EntryCategory editing and creation in the Preferences dialog. It supports editing of category names and icons, plus a "visible" checkbutton to indicate if you want the category shown in the Entry dialog combobox.
This weekend, I added a status tray icon and menu.
I've got a list of features I want to add, but I will probably kick out another release soon. The Garmin device support deserved a release months ago.
Mike: 5
Maggie the Monkey and Jackson: 2
Been adding some new features to exert the last couple weekends. Last weekend, it was a couple new icons for swimming and cycling:
I also hacked EntryCategory editing and creation in the Preferences dialog. It supports editing of category names and icons, plus a "visible" checkbutton to indicate if you want the category shown in the Entry dialog combobox.
This weekend, I added a status tray icon and menu.
I've got a list of features I want to add, but I will probably kick out another release soon. The Garmin device support deserved a release months ago.
Wednesday, April 9, 2008
Hockey talk
Jackson took a group of us non-Canadians to a Bruins/Blackhawks game in Boston last fall, and rekindled my interest in the Blackhawks. Seeing as Jackson has posted his picks for the first round, I figured I would post my completely novice guesses just so I can belittle him if I happen to guess correctly.
West:
'Wings d Preds in 6. Ellis is gonna win 2.
Sharks d Flames in 4. Flames are going down hard.
Avs d Wild in 6. Wild are too boring to win.
Stars d Ducks in 7. Could go the other way in 7.
East:
Montreal d Boston in 5. Boston will win one at home.
Pittsburgh d Ottawa in 5. Crosby with 16 points.
Caps d Flyers in 6. Caps are gonna drop one at home, probably game 1.
Rangers d Devils in 7. Though I couldn't care less.
If you place any bets based on these picks, I will expect my usual commission.
West:
'Wings d Preds in 6. Ellis is gonna win 2.
Sharks d Flames in 4. Flames are going down hard.
Avs d Wild in 6. Wild are too boring to win.
Stars d Ducks in 7. Could go the other way in 7.
East:
Montreal d Boston in 5. Boston will win one at home.
Pittsburgh d Ottawa in 5. Crosby with 16 points.
Caps d Flyers in 6. Caps are gonna drop one at home, probably game 1.
Rangers d Devils in 7. Though I couldn't care less.
If you place any bets based on these picks, I will expect my usual commission.
Subscribe to:
Posts (Atom)
