dflplot/Plot2Kill, Most Mature *nix GUI For D2

[Johannes Pfau]

On 16.07.2010 17:01, Johannes Pfau wrote:
> On 16.07.2010 15:34, dsimcha wrote:
>> == Quote from Lars T. Kyllingstad (public at kyllingen.NOSPAMnet)'s article
>>> On Fri, 16 Jul 2010 02:41:01 +0000, dsimcha wrote:
>>>> I've refactored my dflplot lib to the point where the GUI-specific stuff
>>>> is well abstracted from the GUI-agnostic stuff in preparation for a port
>>>> to a GUI lib that supports rotated fonts, saving bitmaps, and/or *nix.
>>>> The plan is to support multiple GUI libs, including DFL (already working
>>>> except for rotated fonts and saving) and at least one or two more.
>>>>
>>>> I started trying to do a port to gtkD, but found the API to be
>>>> intolerable in that it's poorly documented and requires you to use the
>>>> low-level C APIs (read:  raw pointers and
>>>> functions_named_like_this_to_prevent_naming_collisions()) for basic
>>>> stuff like constructing a drawing context.
>>> Are you sure?  I admit, I have only played around with it, and never
>>> actually used it for serious work, but I never ran across any C-style
>>> interfaces while doing so.
>>> gtkD seems to be modeled on GTK++, and its documentation comments seem to
>>> be copied verbatim from the GTK++ docs.  So if you're looking for very
>>> basic documentation (i.e. what does what?), this could be a good starting
>>> point:
>>>   http://library.gnome.org/devel/gtk/stable/
>>> That said, could this be what you need?
>>>   http://www.dsource.org/projects/gtkd/browser/trunk/src/gtk/DrawingArea.d
>>>> [...]
>>>>
>>
>> What turned me off was the Drawable class, which I'd be using heavily.  There's no
>> way to construct it w/o explicitly creating a pointer to a C struct and then
>> passing it in.  See
>>
>> http://www.dsource.org/projects/gtkd/browser/trunk/src/gdk/Drawable.d
>>
>> Also, only the SVN version compiles on 2.047, not any releases.  Again, I'm not
>> knocking gtkD's long-term viability.  I'm just saying it needs more time to mature.
>>
>> On the other hand, the more you encourage me to look at it, the more I think that
>> the omission of any "real" c'tor for Drawable is a single oversight rather than a
>> general trend.  Initially I had decided that I was simply unwilling to mess w/ any
>> crufty C APIs to create this plotting library, but if I have to do it in one small
>> place to work around this omission, then I'll do it.
> 
> That's a general problem with the gtk api, it's not directly related to
> GTKd. (gtk generally sucks at custom drawing, see
> http://federkiel.wordpress.com/2008/03/12/gtk-30-getting-serious/ about
> canvas for example)
> 
> You need to do the following to draw to a Widget:
> 1. Create a drawing area Widget
> (http://gtkd.mikewey.eu/src/gtk/DrawingArea.html)
> 2. Get the DrawingAreas window using DrawingArea.getWindow()
> 3. A Window is a subclass of Drawable. So you can draw to that window.
> 
> In the best case you'd encapsulate all that in a subclass of
> DrawingArea. But I'm not sure if that works with gtkd.

Ah, btw: you might want to use cairo to render to that Drawable. As far
as I know, everyone uses cairo nowadays when drawing gtk widgets.
http://gtkd.mikewey.eu/src/cairo/Context.html
And you also get cross platform offscreen rendering for free
(ImageSurface, PdfSurface, SvgSurface are keywords to look up). I think
gtkds cairo api should be mature enough to do all that.

-- 
Johannes Pfau