gtk-databindings work blog and ramblings

currently I’m working on Gtk.DataBingingsInterface which is…

simple interface which enables any kind of data binding to plug into ordinary gtk widgets. plan is very simple (one of the reasons for that is that I plan to provide streming MVC after 2.1 is out):
- allow different databinding solutions to be used in the same form as soon as developer references them without need to use special widgets, this provides integration of data bindings into already finished product and also provides place where other data binding engine can plug in
- allow developer to interact with (all plugged) databindings without need for specifics
- not one line in gtk-sharp is needed

plan in effect is something like this (these commands are Gtk.DataBindings specific):

Gtk.TreeView myTreeView;

myEntry.Bind (selecteditem, “Name”);
or
myEntry.SetDataSource (a);
myEntry.SetMappings (”Name”);

this code will simply fill up treeview with data (and create columns). and code:

Adaptor a = myTreeView,GetCurrentSelection();

is returning adaptor reference which will follow selection in treeview. as soon as next item is selected entry will start pointing on that one.

common api on the other hand only enables user to control data flow over all connections to specific widget: Freeze(), Thaw(), Start(), Stop(), Disconnect()

myWidget.DataBinding().Freeze();

this looks rather nice and simple

One of my biggest goals for data bindings was writing a book about it. How to use and how simple it is. Book is finally progressing and I won’t release 2.0 until it is finished.
Introduction
Chapter 1
Chapter 2
Chapter 3
Chapter 4

And so on… This is just a base for finished product which will follow after 2.0. But having some at least basic documentation about it would be nice for 2.0

second stage of stetic patch. first public version which is commonly usable. patch is made against 2.0 release of monodevelop and I don’t plan to test it with trunk. next stable release is the first version which will receive my attention as I simply don’t have time to compile md daily and even less time to be annoyed with daily regressions (those are simply must be when you use work in progress). using bleeding edge just isn’t my game anymore.

what:
- disabled hardlinking to my assemblies (I needed that to test usage and loading)
- added code which resolves if assembly is gac based and then reloads it the hard way

stetic now works with real instances of widgets if they were added from gac assembly.

next?
Property editors… based on MS specs.

Download:
Patch

Don’t get me wrong, I actually like designing in stetic if I use classic widgets… But its design and internals scare the s*** out of me as I work with custom widgets 99% of time whenever I only think about working with it.

First the good… and why stetic is really great
1) Designing complex widgets, kudos and a beer keg
2) Really sensible interface and nice layout, again kudos

But why is stetic completely unusable for me?
(Which is completely different than my opinion about the rest of the Monodevelop. Monodevelop is in my eyes best IDE since sliced bread was invented and all my kudos with additional beer keg to developers.)
1) objects.xml overrides .Net attributes. This is not serious, actualy quite simple to correct
… now the really bad things (but knowing how much work it would take to fix this, I know why everyone is avoiding this like a plague. There is no time which is probably the first reason. The second reason is providing remoting service which can communicate all functionalities to IDE and back. Major work
2) any usage of class outside of gtk lib. you either get a wrapper with base class inside… uaaaaahhh. Or you get even worse result, stetic simply decides base widget has 0,0 size and widget disappears into nothing. Even wrapper approach is bad (for example, you set property value and there is no visual feedback on the form)
3) works trough cecil for everything outside base gtk-sharp library, which CAN’T invoke your widget and you end up with some wrapper c*** again.
4) No custom property designers

Number 1 probably derives from the fact that original designer didn’t even look at .Net framework but rather reinvented the whole wheel completely against .Net. Well, actual problem is just the priority where description is first taken. It should be attributes not xml. xml should be used for possible additional information. No more than 1 hour of work.

Now… 2, 3 and 4 all derive from the same problem. .Net can’t unload assembly. So what to do… For real soluion? Nope, there is no time. But providing simple but crippled solution… Yep more than possible. Personally, I don’t even see any crippling. And neither has anyone I talked to about this.

About patch

Well if one can’t unload assembly… He can unload IDE. But if references are only made to libraries referenced from GAC? Those can’t get recompiled, those can’t change. so worst case scenario is MD reload when I want to edit that library (or rather work on it as separate user in my case). Which is really rare.

Ok, so… rather than constantly bitching for next few years, I started patching stetic to fill my needs.

and goal 1 is achieved. Stetic now shows real widgets instead of fakes. and even more… they are live as seen here

Here is my DateEntry inside of stetic (for information… this is not combo box. It is derived from DrawingArea)

And these are properties. One widget has them set on false, one on true. Basically, you see what you design. Hell, you can even edit value if you want and it is stored back to stetic.

What is left to do?

Second step is to figure out which references are GAC based and pass only those to stetic instead of hardlinking as I did to be able to test invokation. This shouldn’t take long.

And last 3rd step is checking on solution load if solution is already loaded and… if it is simply exit monodevelop with exit code and rerun from script with new solution. This might take more time.

Bah, I know solution is far from perfect… but losing 3-4 seconds per project change instead of losing time working with invisible forms or forms without feedback? I don’t see the problem.

I completely stopped working on 1 and there were no more updates. Version 2 would already be out if there weren’t few showstoppers. But now I simply decided it is not important to me anymore as I can’t really do anything about fixing them.

New things in version 2…
- Real MVC approach to TreeModels with QueryModelAttribute and shells from which one can derive its own models by simply overriding 3-5 methods which provide data. QueryModelAttribute is far more than just attribute. It registers your model with specific data type and this means auto creation of it as soon as one specifies ItemsDataSource=myData
- Query models for arrays, lists, DataView, DataTable
- Registration of views for data so treeview column mapping can now simply be {MyType} #viewname# and it reads attribute description for that type and gets its columns defined by that view
- Sort and Filter observable lists (both generic and non generic ones). Simply connect Filter to some Observable list and here is live filtering, same goes for sorting
- DbObservableList, simply wraps DataTable or DataView and you use it like ordinary list, which is in effect compatible with filter and sort lists
- TypedDataTable, generic variant of DataTable
- Complete widget creation framework (by using drawing cells). Complex widget creation as in monodevelop mostly sucks because you’re imposing complex windowing architecture and thus your application consumes more ram and cpu. Same cells are reusable with reports in cairo, cellrenderers and classic widgets
- Widget style cells, which enable one to draw entry or button look alike in matter of one line.
- Various description attributes
- Various new widgets (like for example, usable DateEntry)
- Widget and Cell Factory for autogeneration of widgets based on property description
- DataAutoWidget, which generates its workings based on the property it edits
- Few cell renderers
and so on, practically this is just few changes, not all…
Basically v2 and v1 differ for more than 100% of functionallity and this is the reason why I stopped working on v1 and worked silently on v2. V2 will maybe need few lines edited, but otherwise is 99.99% compatible with v1

Showstoppers I don’t care about:
https://bugzilla.novell.com/show_bug.cgi?id=510176
https://bugzilla.novell.com/show_bug.cgi?id=523306

First one simply doesn’t allow full functionality for databinding to be effective as there is no correct delegating.
Second one is already in progress of fixing

Now I just have to clean up some things and v2 is out.
Plan after v2? v2.1
- LESS FUNCTIONALITY, MORE DOCUMENTATION…
- fixing things if needed
- AutoLayoutContainer (sharing the same workings as TreeView columns)
- Property grid
- More cellrenderers and more custom widgets (now that drawing cell approach is working… easy)
- Preparing for Gtk#3