From: Duncan C. <dun...@wo...> - 2007-12-13 15:23:05
|
We should make some bug reports out of these so we do not forget. I've already replied and agreed with most. I pointed out cairo as the better api, but we should probably advertise in the gdk docs that you should really use cairo unless you have a very good reason not to. Duncan -------- Forwarded Message -------- > From: Martijn Schrage <ma...@cs...> > To: Duncan Coutts <dun...@wo...> > Subject: Re: [Fwd: Re: [Haskell-cafe] Re: wxHaskell / Proxima (was > Tetris)] > Date: Tue, 11 Dec 2007 12:09:01 +0100 > > Hi Duncan, > > One of my students forwarded this e-mail to me, since he is not really > involved in the Proxima project yet. > > I was already planning to mail you for quite a while, since I made a > list of aspects in which gtk2hs was slightly harder to use than wx, but > I never got around to this. But now I ran into something which seems a > typical bug, and I might as well send the rest of my comments with it. > > Porting Proxima to gtk was actually quite easy, it only took a couple of > days. And the functionality for manipulating bitmaps allowed me to > implement an incremental renderer, which was out of the question with > wx. Thanks for that! > > The bug that I ran into is that gtk2hs seems to catch exceptions that > occur in the event handlers, and then terminates the program. Thus, > putting a `catch` around your main does not actually catch all > exceptions, and you need to add exception handlers explicitly to each > event handler. It is not a major problem, but took me some time to > figure out (I first thought it was a GHC bug), and is probably not hard > to fix. > > I will put the rest of my suggestions below. They are not nicely > formatted, and some might benefit from more actual examples, but now at > least you have them (otherwise I will leave them lying around for > another 6 months again :-). > > > Suggestions/problems: > > - Events are not instance of Show (Just like most other data > structures). Having the events showable makes it much easier to > experiment with event handlers. Similarly, gc values like CapStyle and > JoinStyle are also not instance of Show, which could be useful if you > want to find out what their value is. > > - strikethrough and underline don't work for pango under windows. (don't > know about other platforms) > > - drawRectangle does not take a Rectangle as its argument > > - There is no drawCircle. > > - Arcs of width/height 1 and 2 are not drawn at all. > > - Widths and heights of filled and transparent structures are inconsistent: > drawRectangle dw gc True x y w h has size w h > drawRectangle dw gc False x y w h has size w+1 h+1 > drawArc dw gc False x y w h 0 (360*64) has size w-1 h-1 > drawArc dw gc True x y w h 0 (360*64) has size w h > drawPolygon also seems to get smaller when filled, but it is not > clear to me what happens exactly > > - drawLines and drawPoly are strange. drawPoly [(0,0),(100,0)] does not > draw in (100,0), but drawPoly [(0,0),(100,0),(100,1)] does. similarly: > drawLines [(0,0),(100,0)] draws the same pixels as (0,0) (100,0), but > adding another point drawLines [(0,0),(100,0),(0,0)] is again one pixel > shorter. > JoinStyle round solves this. Maybe make it standard? > > - Filling rectangles and circles with a different color is not possible, > and doing it by first drawing a filled one and then the outline is > awkward due to the changing widths and heights. > > - Setting attributes for a drawing is rather verbose. > > - There is no easy draw text function. You have to use the pango layout > system. > > - wx has many more utility functions Eg. for Rectangles, only the > constructor is available in Gtk. > > - Documentation for drawing primitives is hard to read. Often parameters > are not named and you have to guess. > > - glyphItemExtents: doc says it returns logical and ink extents, but it > is (ink, logical), which is not clear from the documentation. (actually, > after checking the source, I think this might be because of a mistake in > the module GlyphStorage: the parameters to glyph_string_extents are swapped) > > - Functions like windowSetDefaultSize take width and height as > parameters, instead of something like a tuple or a Size or Dimensions > data structure. This is inconvenient if you want to put the size in a > variable (eg. now I have windowSetDefaultSize window (fst > initialWindowSize) (snd initialWindowSize)) > > - Sometimes the parameter order is a bit awkward, eg. in > (drawWindowInvalidateRect dw region False). Now we cannot mapM this > function without using a lambda function. > > > If anything in the list is unclear, please let me know. > > Keep up the good work! > > Cheers, > Martijn |