From: Axel S. <A....@ke...> - 2005-10-16 15:11:45
|
All/Duncan, I stripped the cairo prefix from cairoRectangle and cairoRegion in the Gtk/Cairo drawing functions. I thought this is more consistent since all other cairo drawing functions have no prefix. These names clash: 'rectangle' is already taken by Cairo. I renamed this to 'area'. Now 'area' and 'region' are already defined in 'Event' (in Widget), so I hid them in Gtk.hs. I added a comment that one has to import these two names qualified. Tell me if that's ok, we can always revert. Another thing: There are these "primitive" text functions in the cairo binding. It might be better to remove those, so that we don't confuse people too much. Pango works well now with Cairo - I changed the demo so that it only uses Pango. The rotation matrix works fine, too! Axel. |
From: Duncan C. <dun...@wo...> - 2005-10-16 15:53:40
|
On Sun, 2005-10-16 at 16:09 +0100, Axel Simon wrote: > All/Duncan, > > I stripped the cairo prefix from cairoRectangle and cairoRegion in the > Gtk/Cairo drawing functions. I thought this is more consistent since all > other cairo drawing functions have no prefix. These names clash: > 'rectangle' is already taken by Cairo. That's why I'd left it with the prefix. (though only as a temporary solution). > I renamed this to 'area'. Now 'area' and 'region' are already defined > in 'Event' (in Widget), so I hid them in Gtk.hs. I added a comment > that one has to import these two names qualified. > Tell me if that's ok, we can always revert. I'm rather of the opinion that all the event record names should be qualified with their event name. It's really not ok to export such generic names as "x" and "y". For the specific case of the Gtk rectangle it's almost so simple as to be pointless. The region one is useful however. We could get away with removing the gtk rectangle one after all, look at it's code: cairoRectangle (Rectangle x y width height) = Cairo.rectangle (realToFrac x) (realToFrac y) (realToFrac width) (realToFrac height) It's just converting Int -> Double and calling the existing cairo rectangle api function. And the Haskell binding doesn't even use the Gtk Rectangle thing very much. I doubt people would miss the function if we removed it. > Another thing: There are these "primitive" text functions in the cairo > binding. It might be better to remove those, so that we don't confuse > people too much. Pango works well now with Cairo - I changed the demo so > that it only uses Pango. The rotation matrix works fine, too! Hmm, I think we'll need to keep the "toy" text api since people using cairo without gtk will need it. However we should make clear in the documentation that it is only the toy api and refer them to the pango/cairo module. Duncan |
From: Axel S. <A....@ke...> - 2005-10-17 08:20:10
|
Things to do before the release: - tidy up the naming in the Cairo module... I can't actually think of anything else. Pango is nearly complete; it would be possible to complete it, what's lacking is: - tab stops (~9 functions) - Font and FontSet; both not useful in practise as far as I can see So maybe that's something to do. apiGen only gives me a skeleton, it doesn't actually bind any function properly. But then it's fewer than 10 functions. As to the naming issue: On Sun, 2005-10-16 at 16:54 +0100, Duncan Coutts wrote: > > I renamed this to 'area'. Now 'area' and 'region' are already defined > > in 'Event' (in Widget), so I hid them in Gtk.hs. I added a comment > > that one has to import these two names qualified. > > > Tell me if that's ok, we can always revert. > > I'm rather of the opinion that all the event record names should be > qualified with their event name. It's really not ok to export such > generic names as "x" and "y". Ok. That makes sense. We could force the user to import Graphics.UI.Gtk.Gdk.Events explicitly. It's just that the name is quite a mouthful. We could introduce some sort of "Graphics.UI.Gtk.LowLevel" module (but we can always do so later). > For the specific case of the Gtk rectangle it's almost so simple as to > be pointless. The region one is useful however. We could get away with > removing the gtk rectangle one after all, look at it's code: > > cairoRectangle (Rectangle x y width height) = > Cairo.rectangle (realToFrac x) (realToFrac y) > (realToFrac width) (realToFrac height) > > It's just converting Int -> Double and calling the existing cairo > rectangle api function. And the Haskell binding doesn't even use the Gtk > Rectangle thing very much. I doubt people would miss the function if we > removed it. Ok, on the other hand, we can keep it, and the 'region' if we just make Events a qualified export. > > Another thing: There are these "primitive" text functions in the cairo > > binding. It might be better to remove those, so that we don't confuse > > people too much. Pango works well now with Cairo - I changed the demo so > > that it only uses Pango. The rotation matrix works fine, too! > > Hmm, I think we'll need to keep the "toy" text api since people using > cairo without gtk will need it. However we should make clear in the > documentation that it is only the toy api and refer them to the > pango/cairo module. Yes, a comment is probably sufficient. In case Cairo gets factored out of Gtk2Hs again, we need to convince people that they keep the comment. If you say yay to all these, I will proceed. Axel. |
From: Duncan C. <dun...@wo...> - 2005-10-17 10:17:19
|
On Mon, 2005-10-17 at 09:18 +0100, Axel Simon wrote: > Things to do before the release: > > - tidy up the naming in the Cairo module... > > I can't actually think of anything else. Pango is nearly complete; it > would be possible to complete it, what's lacking is: > > - tab stops (~9 functions) > - Font and FontSet; both not useful in practise as far as I can see > > So maybe that's something to do. apiGen only gives me a skeleton, it > doesn't actually bind any function properly. But then it's fewer than 10 > functions. Yes it needs to be taught how to marshal new types. One of the things to do in the apigen rewrite would be to make it generate marshaling code based on what kind of glib type it is (gobject/boxed/etc). > As to the naming issue: > > On Sun, 2005-10-16 at 16:54 +0100, Duncan Coutts wrote: > > > I renamed this to 'area'. Now 'area' and 'region' are already defined > > > in 'Event' (in Widget), so I hid them in Gtk.hs. I added a comment > > > that one has to import these two names qualified. > > > > > Tell me if that's ok, we can always revert. > > > > I'm rather of the opinion that all the event record names should be > > qualified with their event name. It's really not ok to export such > > generic names as "x" and "y". > > Ok. That makes sense. We could force the user to import > Graphics.UI.Gtk.Gdk.Events explicitly. It's just that the name is quite > a mouthful. We could introduce some sort of "Graphics.UI.Gtk.LowLevel" > module (but we can always do so later). Well from what I can see most libs just prefix the constructor name onto the record name. That'd give things like buttonX buttonY etc. Or we could make people import it qualified, though it's not what we make people do elsewhere. > > For the specific case of the Gtk rectangle it's almost so simple as to > > be pointless. The region one is useful however. We could get away with > > removing the gtk rectangle one after all, look at it's code: > > > > cairoRectangle (Rectangle x y width height) = > > Cairo.rectangle (realToFrac x) (realToFrac y) > > (realToFrac width) (realToFrac height) > > > > It's just converting Int -> Double and calling the existing cairo > > rectangle api function. And the Haskell binding doesn't even use the Gtk > > Rectangle thing very much. I doubt people would miss the function if we > > removed it. > > Ok, on the other hand, we can keep it, and the 'region' if we just make > Events a qualified export. Oh you mean rename rectangle to area and keep region since it doesn't clash with Event.region. > > > Another thing: There are these "primitive" text functions in the cairo > > > binding. It might be better to remove those, so that we don't confuse > > > people too much. Pango works well now with Cairo - I changed the demo so > > > that it only uses Pango. The rotation matrix works fine, too! > > > > Hmm, I think we'll need to keep the "toy" text api since people using > > cairo without gtk will need it. However we should make clear in the > > documentation that it is only the toy api and refer them to the > > pango/cairo module. > > Yes, a comment is probably sufficient. In case Cairo gets factored out > of Gtk2Hs again, we need to convince people that they keep the comment. > > If you say yay to all these, I will proceed. Add as much Pango stuff as you like. For the event naming, I'd rather just prefix-qualify the event record members. Then we can keep region and rename rectangle to area or just drop it entirely. Duncan |
From: Axel S. <A....@ke...> - 2005-10-17 10:55:08
|
On Mon, 2005-10-17 at 11:18 +0100, Duncan Coutts wrote: > On Mon, 2005-10-17 at 09:18 +0100, Axel Simon wrote: > > Things to do before the release: > > > > - tidy up the naming in the Cairo module... > > > > I can't actually think of anything else. Pango is nearly complete; it > > would be possible to complete it, what's lacking is: > > > > - tab stops (~9 functions) > > - Font and FontSet; both not useful in practise as far as I can see > > > > So maybe that's something to do. apiGen only gives me a skeleton, it > > doesn't actually bind any function properly. But then it's fewer than 10 > > functions. > > Yes it needs to be taught how to marshal new types. One of the things to > do in the apigen rewrite would be to make it generate marshaling code > based on what kind of glib type it is (gobject/boxed/etc). I don't know if it is worth the trouble. One argument for a better apiGen is that most stuff we haven't bound is the non-straight-forward world of the clipboard, styles, preferences, etc. One argument against a better apiGen is that it might be a waste of time if most of these functions elude automatic binding anyway. Although even an empty skeleton is helpful. > > As to the naming issue: > > > > On Sun, 2005-10-16 at 16:54 +0100, Duncan Coutts wrote: > > > > I renamed this to 'area'. Now 'area' and 'region' are already defined > > > > in 'Event' (in Widget), so I hid them in Gtk.hs. I added a comment > > > > that one has to import these two names qualified. > > > > > > > Tell me if that's ok, we can always revert. > > > > > > I'm rather of the opinion that all the event record names should be > > > qualified with their event name. It's really not ok to export such > > > generic names as "x" and "y". > > > > Ok. That makes sense. We could force the user to import > > Graphics.UI.Gtk.Gdk.Events explicitly. It's just that the name is quite > > a mouthful. We could introduce some sort of "Graphics.UI.Gtk.LowLevel" > > module (but we can always do so later). > > Well from what I can see most libs just prefix the constructor name onto > the record name. That'd give things like buttonX buttonY etc. > > Or we could make people import it qualified, though it's not what we > make people do elsewhere. I see. I'd be happy to prefix all field names in Event with 'event'. I'd still like to separate the documentation out of Widget, since it kind of clutters the Widget documentation. > > > For the specific case of the Gtk rectangle it's almost so simple as to > > > be pointless. The region one is useful however. We could get away with > > > removing the gtk rectangle one after all, look at it's code: > > > > > > cairoRectangle (Rectangle x y width height) = > > > Cairo.rectangle (realToFrac x) (realToFrac y) > > > (realToFrac width) (realToFrac height) > > > > > > It's just converting Int -> Double and calling the existing cairo > > > rectangle api function. And the Haskell binding doesn't even use the Gtk > > > Rectangle thing very much. I doubt people would miss the function if we > > > removed it. > > > > Ok, on the other hand, we can keep it, and the 'region' if we just make > > Events a qualified export. > > Oh you mean rename rectangle to area and keep region since it doesn't > clash with Event.region. That was my original idea. If we prefix Event.region with as eventRegion, then we can keep region in Cairo. Although the naming of Cairo is then inconsistent with the rest of Gtk. But I like short names. So I'd suggest we use short names for all function that have type Render a. > > If you say yay to all these, I will proceed. > > Add as much Pango stuff as you like. > > For the event naming, I'd rather just prefix-qualify the event record > members. > > Then we can keep region and rename rectangle to area or just drop it > entirely. Ok, I think I'll drop the 'area' function. Axel. |
From: Duncan C. <dun...@wo...> - 2005-10-17 11:13:58
|
On Mon, 2005-10-17 at 11:53 +0100, Axel Simon wrote: > On Mon, 2005-10-17 at 11:18 +0100, Duncan Coutts wrote: > > Yes it needs to be taught how to marshal new types. One of the things to > > do in the apigen rewrite would be to make it generate marshaling code > > based on what kind of glib type it is (gobject/boxed/etc). > > I don't know if it is worth the trouble. One argument for a better > apiGen is that most stuff we haven't bound is the non-straight-forward > world of the clipboard, styles, preferences, etc. One argument against a > better apiGen is that it might be a waste of time if most of these > functions elude automatic binding anyway. Although even an empty > skeleton is helpful. Yes, at the moment and just for that issue it would not be worth it. However when the glib introspection stuff gets included with glib/gtk, I'm planning to improve the apigen prog to take advantage of that data and do a generally better job. > > > > I'm rather of the opinion that all the event record names should be > > > > qualified with their event name. It's really not ok to export such > > > > generic names as "x" and "y". > > > > > > Ok. That makes sense. We could force the user to import > > > Graphics.UI.Gtk.Gdk.Events explicitly. It's just that the name is quite > > > a mouthful. We could introduce some sort of "Graphics.UI.Gtk.LowLevel" > > > module (but we can always do so later). > > > > Well from what I can see most libs just prefix the constructor name onto > > the record name. That'd give things like buttonX buttonY etc. > > > > Or we could make people import it qualified, though it's not what we > > make people do elsewhere. > > I see. I'd be happy to prefix all field names in Event with 'event'. Ok, that would be fine. > I'd still like to separate the documentation out of Widget, since it > kind of clutters the Widget documentation. Yes that is a good idea. > > > Ok, on the other hand, we can keep it, and the 'region' if we just make > > > Events a qualified export. > > > > Oh you mean rename rectangle to area and keep region since it doesn't > > clash with Event.region. > > That was my original idea. If we prefix Event.region with as > eventRegion, then we can keep region in Cairo. Yes, lets do that. > Although the naming of Cairo is then inconsistent with the rest of > Gtk. Yes that's true. > But I like short names. Me too. (and it's something I'd like to look at for gtk in the future) > So I'd suggest we use short names for all function that have type > Render a. Yes. > > Then we can keep region and rename rectangle to area or just drop it > > entirely. > > Ok, I think I'll drop the 'area' function. Yep. Duncan |