[Gtk-sharp-list] DataGrid control, data binding, ObjectViews, Swf,
don at env.com.ua
Thu Dec 15 19:17:51 EST 2005
On 12/15/05, Mike Kestner <mkestner at novell.com> wrote:
> On Thu, 2005-12-15 at 10:08 -0500, Scott Ellington wrote:
> > > #5) SWF controls are not easy/helpful to port to gtk# in all honesty.
> > > fact, they suck to port. Everything is pretty different, and you don't
> > > want to use System.Drawing on Linux if you can use Cairo directly
> > > and even if you did, its still not a good path to rainbows and
> > Indeed. But a DataGrid type object in gtk# would be sweet.
> Data binding is one of the two highest priority features for the next
> feature addition interval, which will not be until after 2.8.0 is
> shipped. So yes, some form of DataGrid is likely to make it into Gtk#
> at some point.
> > Aren't NodeView, NodeStore, and NodeSelection custom gtk# widgets that
> > have been rolled into the gtk# library? I'm not sure that throwing tons
> > of custom widgets in their is a great idea.
> 1) NodeView, Store, and Selection are all attempts to expose the
> TreeView API in a C# friendly manner, not custom widget implementations
> from scratch.
> 2) I am NodeStore's author and consulted on NodeView/Selection which are
> thin wrappers of their Tree* equivalent. The likelihood of me
> maintaining a from-scratch widget that I didn't implement or even
> consult on is pretty slim, unless it's really really good code and a
> really general-use and compelling widget. Custom widgets are for the
> most part outside the scope of Gtk#.
> > I'd just like some official
> > library that gtk# developers can share, so if Lluis makes some
> > improvements or fixes to DockToolbar I get them without having to patch
> > my own copy.
> The reality is that this just doesn't work. There have been numerous
> experiments in widget aggregation in GNOME from gal to egg. For that
> matter, libgnomeui. Most of the general purpose widgetry is already
> contained in Gtk#. Do you really want your users to have to download
> and install the NPlot widget to be able to use DockToolbar? And do you
> really want the developers of DockToolbar to have to synchronize their
> release schedule with the developers of WidgetA thru WidgetZ?
> We have already put in place the beginnings of what I think makes the
> most sense regarding a widget/control repository for Gtk# derived
> I think it would be good to turn it into a table with licensing
> information available at a glance. As it starts to grow, it can be
> categorized by styles of widgets and so on. All it needs is an
> I think a referential repository of independently released widget
> libraries that can be imported into or referenced by projects makes much
> more sense long term than the
> gtk-sharp-extra-widgets-of-all-shapes-and-sizes.dll approach.
Well, it can be a repository of *independent* widgets in the SVN and as a
table on the web site so the
everyone can download them but probably having everythin in one library
could be also not so bad, just grab
the last binary release of it and use :). .. Like use log4net.dll,
nhibernate.dll, etc. If you need to take a source and extend it -
then probably it is better to put an effort to extend original control in
Gwl.Controls/ - only control-type widgets here (shall all
controls be derived from something like Control.cs?)
Plot.cs - i.e. Gtk# widget as a wrapper of NPlot
Gwl.Docking/ - more complex/higher level (controls manager)
Gwl.Workflow/ - commands, tasks, events, etc. (base library to be
use in final applications).
CommandExecuteEvent.cs - Executed / Executing events for the command.
Just some brainstorming, any other ideas? (About suggested Gwl name .... by
the way, it is similar to Gtk, also abbreviation ;)) but I don't insist.
But a repository of available widgets for the beggining would be also very
nice for the beggining and then it would be possible to make design of the
And a few more suggestions:
1. do *not* include there a widgets which are already available for Gtk and
well maintained by someone (if it is forgotten - then probably yes :)).
2. if there is some very nice widget/library which has lack of Gtk# wrapper
- this wrapper also could be a target to be included (NPlot, ZedGraph,
but named as Diagram, DrawingCanvas, ... so that everything will be easy).
3. if it is not a control - don't put it in Controls folder, ... probably
add there something like Utils for all comon helper classes or make a
4. don't make more levels in the directory tree so that everything will be
5. maintain all controls and libraries so that they will be independent
(could be grabbed as a set os sources and used separately).
I would target a library as "Gtk# Widgets Library is a library which extends
standard Gtk# widgets set by a higher level set of controls and utilities
required to build a high quality user interface desktop applications. The
controls of the library are either constructed as a customization of the
available Gtk# widgets but are wrapped to be more consistent and
developer-friendly for use in .NET applications development. The library
also aggregation some free third-party controls which lack implementation
for the Gtk# but are needed by the community." :) sorry, I'm not a native
wneglish speaking, probably some mistakes.
Another need to build something like this library could be the fact that
Gtk# sticks too much to the Gtk+ interfaces (which is maybe very good so
that it is easy to use it by people who have experience with Gtk and also to
maintain when something is changing in Gtk+).
> Mike Kestner <mkestner at novell.com>
> Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gtk-sharp-list