gtk-databindings work blog and ramblings

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)

Add Bind(object, object, *property mapping*[]) to DataBinder - this will allow to bind to many properties simultaneously

Remove Boundary***, since DataBinder allows just this and in the end it showed as not so usable as I thought at first, removal is very possible

Add IReadOnly interface - since there is only one widget that actually has readonly defined (Gtk.Entry) there is too much hassle to provide readonly gui interface. It would be so much nicer if one could simply say (Dialog, Window or Container).ReadOnly = true and widgets are not editable

Sanitize source with regions - SDB is a lot of source, and could be much more mainainable if regions would be specified

Speedup with using generics in main engine - At first I wanted to stay 1.1 compatible, but now I ask my self where is the sense in that decision. Gtk doesn’t run on 98… so???

DataDialog and DataWindow as templates in MD - Now I had to provide DataSource property in source manually when creating it in stetic, by being able to define those two, well… not needed anymore and the fact that forms would be extended if those two would be

CellRenderers - Well, I seriously hope I’ll get help on those by public, currently TreeView is very cumbersome to edit. Mainly because editors don’t exist

Custom Widgets - Again I hope on external help. For example date editing in Gtk??? Simply sucks. I don’t want some crippled masked edit like usual, they never worked. Main part of work (ComplexEdit - aka. HBox that draws it self as Entry and provides place for entry widgets along with pre and post widgets, for example [[CheckBox Active[]] [Entry,Label,Entry,Label,Picture,Entry] [Label,Picture]]) is already done, just not in svn yet.

Widget Flasher - Again already done in basic form and provides custom flashing of widgets (infinite or nr. of flashes with time interval), mostly because it would be really nice to e able to provide more sensible and visible interface

Interactor, IDataEditor, GenericDataEditor and DataEditorAttribute - Auto usage of gui by saying for example Interactor.Edit (mydata) and correct dialog with correct posting method would be auto invoked would be really nice

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.