On 16.07.2010 17:01, Johannes Pfau wrote: > On 16.07.2010 15:34, dsimcha wrote: >> == Quote from Lars T. Kyllingstad (pub...@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