On 12/15/05, Mike Kestner <[EMAIL PROTECTED]> 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. In
> > 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 (imo),
> > and even if you did, its still not a good path to rainbows and puppies.
>
> 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
widgets:
http://www.mono-project.com/GtkSharp#Additional_Widgets
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
advocate/maintainer.
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 the library.
Gwl.Controls/ - only control-type widgets here (shall all controls be derived from something like Control.cs?)
DataGrid.cs
DataGridColumn.cs
DataGridChangeEventArgs.cs
...
TreeView.cs
...
Plot.cs - i.e. Gtk# widget as a wrapper of NPlot
PlotSurface.cs
...
Gwl.Docking/ - more complex/higher level (controls manager)
DockManager.cs
DockContent.cs
...
Gwl.Workflow/ - commands, tasks, events, etc. (base library to be use in final applications).
Command.cs
CommandAttribute.cs
CommandExecuteEvent.cs - Executed / Executing events for the command.
CommandManager.cs
...
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 common
library.
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, Netron, etc.
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 separate folder.
4. don't make more levels in the directory tree so that everything will be very clean.
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+).
--Gena
--
Mike Kestner <[EMAIL PROTECTED]>
_______________________________________________
Gtk-sharp-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
