Wednesday, December 10, 2008
Gtk# for .Net installers
Today, by popular demand, we announced the availability of win32 installers for Gtk# version 2.12.6. Runtime and SDK installers for .Net similar to those provided in the past by Medsphere are now being provided from the Mono project downloads page.
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.
Friday, March 21, 2008
gio-sharp
Been getting quite a few requests for libgio bindings. I whipped up a new module in mono svn to provide an unstable binding for people who want to experiment and help refine the API. It is my intention to eventually, most likely in gtk-sharp 2.14, merge this binding into gtk-sharp and eliminate the standalone package. Until then, it will install per the Mono Guidelines for Unstable Library Deployment outside the GAC.
For the extremely impatient and adventurous, you can find it at trunk/gio-sharp. You will need GAPI from trunk/gtk-sharp to build it. It still throws tons of generation warnings. I have made zero attempts to use it. It has no docs. If it melts your laptop, don't complain to me.
Feel free to file bug reports for anything out of order. I'll try to be responsive to any reports, and as always, patches are welcome.
Enjoy.
For the extremely impatient and adventurous, you can find it at trunk/gio-sharp. You will need GAPI from trunk/gtk-sharp to build it. It still throws tons of generation warnings. I have made zero attempts to use it. It has no docs. If it melts your laptop, don't complain to me.
Feel free to file bug reports for anything out of order. I'll try to be responsive to any reports, and as always, patches are welcome.
Enjoy.
Friday, February 15, 2008
Hack Week II Exertion
This week was Hack Week 2 at Novell, and I decided to spend the week adding Garmin Forerunner import support to exert. I had hoped to maybe move on to some heart rate graphs and lap display, but time ran out.
All track, lap, and run data is importing correctly into the exert sqlite database, at least as far as I can tell from some sql querying. The visible entries are coming in cleanly and displayed properly, but there may still be some glitches in the lap summary and GPS track point data.
Here's a rather boring screenshot of the end result.
Current support is limited to the ForeRunner 305, but it should be easy enough to add other devices if people are interested. I just didn't feel like implementing the entire protocol up front.
The code is on svn at sourceforge. I will probably hold off on a release until I can display more of the data visually. I want to add heart rate graphs, route maps, and lap tables. Maybe next hack week...
All track, lap, and run data is importing correctly into the exert sqlite database, at least as far as I can tell from some sql querying. The visible entries are coming in cleanly and displayed properly, but there may still be some glitches in the lap summary and GPS track point data.
Here's a rather boring screenshot of the end result.
Current support is limited to the ForeRunner 305, but it should be easy enough to add other devices if people are interested. I just didn't feel like implementing the entire protocol up front.
The code is on svn at sourceforge. I will probably hold off on a release until I can display more of the data visually. I want to add heart rate graphs, route maps, and lap tables. Maybe next hack week...
Subscribe to:
Posts (Atom)