Hello to all interested!
I went silent since there was no feedback (lately I was inaccessible from
irc, and mail?... I don't read it anyway). So I had to take the hard way
of polishing things. By dogfooding them on my commercial software
currently in development.
As soon as I figure out how to post changes from my newly setup notebook
to svn on sourceforge version 1.0.0 will be out.
What it does and what it doesn't do. Ok, here we go:
What it doesn't:
- It won't make pigs fly, that's for sure. But object data and forms are
another subject. Those do fly
- Doesn't provide direct connection to database. This topic is better
described in FUTURE part of the message
What it provides:
- Connection to any object you create and live data transfer between
object and form or form and object. Live editing is the name
- All widget types with DataBindings enabled. Each having two datasources
(DataSource and BoundaryDataSource. Mappings and BoundaryMappings.
DataSource inheritance for both original and boundary
- Pointer like DataSource structure. Show the (Pointer) Adaptor as
DataSource and you can simply change its Target once and change it across
your application. Adaptor on Adaptor to provide more complex data bounding
is also possible
- Posting method to notify databindings they should update for that
object. Usable if you edit object outside any form. Best usage is to put
that line in set part of the property
- Automatic posting of notifications if changes come from form
- Complex IconView, Treeview and ComboBox mappings
- TreeView drag/drop rearranging of actual data or rearranging it from
code with live update of items
- Usable from monodevelop. Just reference library and controls are usable
in stetic
- Observable object and Observable lists. Those are subject to move in
version 2.0.0 because I don't believe Gtk.DataBindings is the best
namespace for them. And since moving triggers and making them generic is
part of 2.0.0 those will become subject to move (I appreciate any
suggestion on namespace, but read FUTURE first)
- 5 usage samples (2.0.0 will feature a lot more in extra widgets library)
- documentation (which has to change in regards with boundary
databindings. Dogfooding showed me completely different usage that it was
originally planned. And this small change is the last one gtk-databind-lib
will get before 1.0.0)
FUTURE
======
There is already 1.9x in the works which sanitizes sources and makes them
more sensible if this would be taken as the start for some other
DataBindings.
Plan for 2.0 (will be finished in about 2 months if I get feedback):
- Moving events and connections to System.Data.Triggers and make them
applicable to any framework not just Gtk#. Gtk# will become just example
how to plug anything inside trigger messaging. (System.Data.Triggers is
not the default name, but so far this is most suitable name. Either this
or Mono.Data.Triggers, which I don't like so because it will work on
MS.NET also. Any suggestion is welcome). This is in the first plan,
meanwhile I'll be only working on database bindings on paper based on the
feedback I get. If there won't be any feedback, there won't be any
database bindings from me. Simple as that. 50% done
- Complete set of additional specialized widgets (part to demonstrate the
use, part to provide more complex widgets). gtk-extrawidget-lib is the
name. Mostly done already.
- Make the database bindings. But here I will need feedback from anyone
interested. (and nope, not the feedback like Databound Treeview in
january). If you're interested into database bindings I will accept only
usage cases (where you provide samples which contain SQL script (or mono
executable source) to create table and simple console application where
you connect to database, list records into console and maybe change one
record, delete...). Based on those I will create databindings to work with
all (sane) cases. I'm very interested in anyone brainstorming this as long
as it is generic applicable.
p.s. Only databases on linux are taken as valid samples. I don't have
windows computer at the moment and I don't even remotely plan to have one.
p.p.s. Before anyone thinks about TreeView bindings and why there are no
database bindings... My goal was to provide fully featured bindings for it
and ComboBox. And since TreeView was named Tree... for a reason and
database data is single dimensional...
Preferred method of contacting me is irc. Usually I'm on either on
#monodevelop or #mono as mm. If I'm not there (my irc is almost always
open) just leave me a message and I will contact back ASAP. You can
contact me even if it is only help with databindings you need.
mm