From: John V. <ve...@co...> - 2005-02-07 23:14:59
|
On Mon, Feb 07, 2005 at 07:50:50PM +0000, Duncan Coutts wrote: > On Sun, 2005-02-06 at 16:51 -0800, John Velman wrote: > > First, my main reason for writing this is to say thanks, and complement the > > developers. I was concerned originally about the dearth of documentation, [snip] > > I think it would be straightforward to translate the gtk c binding tutorial > > to cover gtk2hs (as has been done for other languages, IIRC). Is anyone > > doing this? I would be possibly be interested in participating, if this is > > under way. > > Gour mentioned that he was thinking of doing tutorial similar to the > Ruby Gtk tutorial http://ruby-gnome2.sourceforge.jp/hiki.cgi?tutorials > and Kenneth Hoste is thinking of writing an introductory article for the > first edition of "The Monad.Reader" > http://www.haskell.org/hawiki/TheMonadReader > So it's definitely worth us all talking so we can coordinate what we are > doing and share demo code etc. I'd like to get all these sort of > demos/screenshots/FAQs and tutorials up on our website. I'd be very interested in participating in this. Some of my early learning efforts might be useful for demo's. Maybe with some with supporting text they could be used in a mini-tutorial. I don't think I could bite off leading a tutorial effort, since I never seem to have as much time as I think I will. I agree that we should coordinate efforts--I suspect that others have pretty much the same kind of time availability problem that I do, if not worse, and it will be a shame to duplicate efforts. Next steps? > > > Now a couple of questions -- I gather that gtk itself has neither bezier > > curves, spline curves, nor ability to dump pictures in postscript (or svg). > > Thus, neither does gtk2hs. I may be missing something by not getting the > > right key words into my searches, but I can't find any of these. Does > > anyone have any suggestions for a) postscript or SVG output of pictures > > drawn? b) curves? > > Sadly, Gnome's vector imaging story is rather patchy. There are a number > of technologies for different things. In the future Cairo is supposed to > sort all of this out for us providing a consistent drawing/printing API. > > So the options are: > * generate SVG directly using a Haskell XML library (eg HaXml). > Pixbufs support loading from svg files so that would deal with > display. This will work now with the current gtk2hs release but > might be a bit of work to generate the svg appropriately, I'm > not sure of the details of svg. This sounds worth looking into. I'll put it on my list :-) > * make a binding for gnomeprint. It can do curves etc. This > library can apparently produce ps output. It will not do svg. > * libart is another gnome library (used by the canvas). It can do > curves, affine transformations and other vector operations and > it produces high quality anti-aliased output but it only outputs > as bitmaps not in any vector format. > * gnomecanvas provides another style of interface to libart (you > create persistent objects and can then change them so it's good > for things that you need to animate). It is aimed primarily at > display. The gnomeprint people aim to be able to print stuff > done using the canvas, but I don't know if they've implemented > that yet. > > > I'm a way from needing either of these at the moment, but will want them > > eventually. Can imagine putting together either a metapost or raw > > postscript output of my figures (which will be quite simple line drawings > > with text), so that's not a killer by any means. I'm not sure how much > > I'll want curves yet! > > Is it essential that the output format be vector? If you just need to > draw images for display, the gnomecanvas would be a reasonable bet and > it shouldn't be too hard to add to gtk2hs. Most of the code can be > generated automatically with our new tool. I'd like vector output for inclusion in documents. I think it's possible to get from *most*?* common vector formats to eps or pdf, and the drawings I have in mind at the moment are all pretty much boxes and lines with text here and there. Sometimes bitmaps are unavoidable (e.g., screenshots), but take up lots of bits. > > Duncan > > |