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

So now I finally have time to finish up some things. Like developing linear only ListStore (will be much more suited to create DataGrid like solution), not that now it doesn’t work, but code could be much simpler and event resolving much easier with faster filling.

So, probably sunday I’ll finally upload new things to svn as soon as I clean up my prototyping out of my branch.

On the other hand, I’m getting a lot of thank you messages here, so I wonder if people are using gtk-databind-lib. I know for a fact that at least 10 commercial apps will use/uses gtk-databindings (3 of those are mine and I can say without one single hickup, not even one case of crashing in 4 months of use). But strangely,… I don’t know even one piece of free software using it. Which is kinda strange, I wrote it as OSS for that specific purpose mostly.

DateEntry as it is now in my personal branch:

3 clickable parts (Calculator, Clear and Picker) and one editable part. Every widget part should be able to activate with keyboard.

Press ‘+’ or ‘-’ and calculator pops up. Calculator is nothing but a simple SpinButton

Now with calculator you either control Spin with up and down or simply enter number by keyboard. Result on parent widget should be alive as calculator needs to handle both Esc and Enter. Press Esc and parent widget reverts back to what it was or press Enter and apply calculation.

Clear is a bit trickier. The biggest mistake every widget does is that it clears data. Not that it is always stupid, but in case of date? Yes, it is. DateEntry invokes ClearData event. By default it means revert to today. But what if you want to handle something like Due pay. By default, clear data would either mean setting it to the same date as the bill or (bill date + customers default due pay time).

This is a lot related to editing. DateEntry doesn’t have cursor (for its editing it uses Label not entry). Always selects complete part you’re editing. For example if you edit day and enter 4? There in no double digit day starting with 4. So it simply skips to next part, but if separator is pressed after this widget ignores it as it was already handled. Same goes with month the only double digit months are starting with 1, anything else skips to next part. But year is a little different. Its prediction has to be good enough when widget exits. Enter 0-9? obvious 2000, but only now, when we will be 2010? 0 will have to mean 2010 not 2000. 1 on the other hand is a bit trickier (if we’re entering this on december 2010? yes it should predict 2011… well this prediction is one of the things I’m still working on). And so on prediction should select most sensible year. Keys Left and right simply walk between day, month and year.

And last one thing? Picker, yes the only viable use for default gtk date selector.

Ok, so why all this? Simply because now CellRenderer to edit date is possible. And good CellRenderer classes are the only thing that separate people from having DataGrid.

Well, there is another annoying thing. The only widget that specifies Editable is Entry. All others only have Sensitive, but… wtf? Sensitive makes it disabled according to theme and mostly makes widgets unreadable. Every Widget should have editable not only one. Same as ClearData event. Another example for ClearData. Financial entry specifying cost of item? You calculate it differently, but then decide you’d go with original price… press Del and instead of setting it to zero? invoke a lookup in inventory and set default price or default price with calculated customers default prices? There is a little lesson. Some widget just don’t need Insert editing mode and some should control it by default for most sensible use. But if you want to go level above normal stupidity, the only way is to go with more sensible data editing.

No, it isn’t dead. I just went into custom widget prototyping and searching for perfect interaction with some really needed widgets.

Most notable example… How the hell can you use Date Widget in GTK in some financial application. Takes whole lot of space. Works awful with keyboard, not to mention entering the date manually is impossible. Same for financial numbers, etc…

It will also be the nicest explanation why converters and validators are deprecated in my opinion.

That will be part of the next upload in svn. As soon as I fix problem or two. Next blog post will feature DateEditor Widget, its use and a little screencast to go with it.

This is one of long overdue needs to create really cool DataGrids and such. Widgets which is usable to enter date in CellRenderer, but with more than perfect layout, control and features. Working nice with mouse and keyboard. And as long as I talk about usability, there will be a bit of brainstorming on my part why some things should be completely rethinked and redone to make applications perfect for users by default.

And please… if you respond to this… FFS, DON’T EVEN MENTION MASKEDEDIT!!!!! It is most horrible widget ever. Allowing you to solve something, but whenever you solve that with using it, solution is less worth than most crippled solution. MASKEDEDIT IS THE MOST HORRIBLE IDEA EVER!

Since this is WIP (work in progress). Best way to work with this library is to
- Update library from svn
- Add projects System.Data.Bindings and gtk-databind-lib to your solution
- Reference your solution to those two projects and that is it

Now, you can freely update it from svn and your own project will reflect changes asap.

For first and obvious plan is to squash as many bugs as they’re found.

Other plans (more serious)

A little FAQ

Ok, so now to explain something that I was asked quite a few times. “How can I help?”. Like first by starting providing help on CellRenderers and Custom Widgets, this work requires the least knowledge of any SDB part. Make workable widget class and then either provide Gtk.DataBindings aware extension (even if extension id not provided, work is so simple that it’ll take me few minutes to make that data widget data aware). Same goes for CellRenderers, example of how to make it data aware is in sample1.

Another thing people ask is “I would need this or that”, one way is to hack it your self and ask if you need help on parts you don’t know. Maybe,… maybe…. if idea is good I might even hack it my self. And FFS! Don’t as me to help you with something it is not SDB and GDB related.

The more annoying part is “MS has this and that”, MS databindings are also plagued by insanity. Main feature of Data bindings is to separate gui code from data code. Last thing you want is to have form code as large as ms can become by simple databinding. By that, first provide with problem, don’t start hacking some solution

And most heard continuation of previous argument is “Tried hacking into your source, but couldn’t find anything, so I started writing my solution”. Well, before you start doing that, try asking.

Nicest example are converters and validators.

private DateTime somedate = DateTime.Now;
public DateTime SomeDate {
  get { return (somedate); }
  set {
    if (somedate == value)
      return;
    somedate = value;
    if (PropertyChanged != null)
      PropertyChanged (this, new PropertyChangedEventArgs("SomeDate"));
  }
}

// Every .Net editor can fold this region
#region SOMEDATE_CONVERTERS

public int Day {
  get { return (somedate.Day()); }
  set {
    // insert validation if you want
    if (somedate.Day == value)
      return;
    SomeDate = new DateTime(somedate.Year, somedate.Month, value);
  }
}

public string Month {
  get { return (MonthNames[somedate.Month]); }
  set {
    int i = MonthNames.IndexOf(value);
    if ((i == -1) || (i == somedate.Month))
      return;
    SomeDate = new DateTime (somedate.Year, i, somedate.Day);
  }
}

public string SomeDateAsString {
  get { return (SomeDate.ToString()); }
}

#endregion SOMEDATE_CONVERTERS

public string StatusDate {
  get { return ("Today is " + SomeDateAsString); }
}

note,… all properties are alive and boundable. And all widgets are updated when you change any of those. All code is validated, and everything is converted correctly according to your needs.

Although data Converter/Validator is really simple to integrate (and I might even allow it as it doesn’t enforce any strain on user, but then again promotes having whole bunch of non-sense code). But I won’t be writing one single line of code for them, because they are non sense in my eyes.

And what about widget validation? Simple solution, when writing for example DateEntry, DON’T USE HALF ASSED APPROACH by using some MaskedEntry, make widget really usable and specifically for Date editing.