www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dflplot/Plot2Kill, Most Mature *nix GUI For D2

reply dsimcha <dsimcha yahoo.com> writes:
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.  It might be a good choice when it matures,
the docs improve and the C cruft is wrapped better, but in the short run I
don't think a gtkD port is happening.

OTOH, I realize that much, possibly the majority, of the D community, is *nix
users and my plotting lib is useless to them as long as it's DFL only.  I also
want to be able to create plots on some *nix machines I SSH into.  Therefore,
I want to get a *nix port working in the near future.  What is the most mature
GUI lib for D2 that supports *nix?  By mature, I mean:

1.  Any low-level C APIs are well wrapped in nice D OO APIs to the point where
you don't need to use the C APIs at least in the common cases.

2.  It compiles out of the box on 2.047.

3.  Preferably the documentation is decent, though I got by without this for
the original DFL version.

Also, I've tentatively named the multiple GUI lib version of this plotting lib
Plot2Kill.  Is this reasonable, or do we want to keep the names of our
scientific libs more boring and politically correct?
Jul 15 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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
 [...]
 
 OTOH, I realize that much, possibly the majority, of the D community, is
 *nix users and my plotting lib is useless to them as long as it's DFL
 only.  I also want to be able to create plots on some *nix machines I
 SSH into.  Therefore, I want to get a *nix port working in the near
 future.  What is the most mature GUI lib for D2 that supports *nix?  By
 mature, I mean:
 
 1.  Any low-level C APIs are well wrapped in nice D OO APIs to the point
 where you don't need to use the C APIs at least in the common cases.
 
 2.  It compiles out of the box on 2.047.
 
 3.  Preferably the documentation is decent, though I got by without this
 for the original DFL version.

The wxD library hasn't been updated for a year or so, but at that time it did work with D2. Perhaps you could check with the authors just how much work it would take to bring it up to date with the latest DMD? http://wxd.sourceforge.net/ As an added bonus, wxWidgets is available for all platforms, so by using wxD you wouldn't have to do the GUI abstraction yourself. BTW, gnuplot uses wxWidgets, so it's definitely usable for plotting.
 Also, I've tentatively named the multiple GUI lib version of this
 plotting lib Plot2Kill.  Is this reasonable, or do we want to keep the
 names of our scientific libs more boring and politically correct?

I see no reason why scientific libs should have more boring names than other libs. Besides, I think the world is ready for a D library that doesn't have a 'D' in its name. ;) -Lars
Jul 16 2010
next sibling parent F. Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article
 The wxD library hasn't been updated for a year or so, but at that time it
 did work with D2.  Perhaps you could check with the authors just how much
 work it would take to bring it up to date with the latest DMD?
   http://wxd.sourceforge.net/
 As an added bonus, wxWidgets is available for all platforms, so by using
 wxD you wouldn't have to do the GUI abstraction yourself.
 BTW, gnuplot uses wxWidgets, so it's definitely usable for plotting.
 Also, I've tentatively named the multiple GUI lib version of this
 plotting lib Plot2Kill.  Is this reasonable, or do we want to keep the
 names of our scientific libs more boring and politically correct?

other libs. Besides, I think the world is ready for a D library that doesn't have a 'D' in its name. ;) -Lars

Yes, I am an avid wxWidgets user (in C++, at least) and I too would love to see a D counterpart on par with it (a truly cross-platform GUI library). The problem wxD faces is that it is an indirect binding: it uses a pure C export binding (wxC) on top of the C++ library in order to allow linking to D. Needless to say, with more extensive use of C++ features such as templates in later versions of wxWidgets, compatibility with C is broken, wxC is no longer possible, and an actual binding to D becomes more difficult. What we should do is fork wxD (or call it wxWidgets if you prefer), use the low level C API of wxWidgets and take advantage of D's superior strings and version() statements to make a platform agnostic library. std.gui? One can always dream :D
Jul 16 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public 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.

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.
 OTOH, I realize that much, possibly the majority, of the D community, is
 *nix users and my plotting lib is useless to them as long as it's DFL
 only.  I also want to be able to create plots on some *nix machines I
 SSH into.  Therefore, I want to get a *nix port working in the near
 future.  What is the most mature GUI lib for D2 that supports *nix?  By
 mature, I mean:

 1.  Any low-level C APIs are well wrapped in nice D OO APIs to the point
 where you don't need to use the C APIs at least in the common cases.

 2.  It compiles out of the box on 2.047.

 3.  Preferably the documentation is decent, though I got by without this
 for the original DFL version.

did work with D2. Perhaps you could check with the authors just how much work it would take to bring it up to date with the latest DMD? http://wxd.sourceforge.net/ As an added bonus, wxWidgets is available for all platforms, so by using wxD you wouldn't have to do the GUI abstraction yourself.

The GUI abstraction was actually fairly easy b/c only a very small portion of the GUI stuff is used for plotting. It would be nice if people could use my lib no matter what GUI toolkit they prefer. Also, gtkD works on Windows.
Jul 16 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 16.07.2010 15:34, dsimcha wrote:
 == Quote from Lars T. Kyllingstad (public 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.

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. -- Johannes Pfau
Jul 16 2010
next sibling parent Johannes Pfau <spam example.com> writes:
On 16.07.2010 17:01, Johannes Pfau wrote:
 On 16.07.2010 15:34, dsimcha wrote:
 == Quote from Lars T. Kyllingstad (public 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.

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
Jul 16 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Johannes Pfau (spam example.com)'s article
 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.

1. Doesn't Window mean that the plot would have to exist in its own window? I'd like to be able to make a plot go to one section of a larger window. 2. When I do: drawable = (new DrawingArea(800, 600)).getWindow(); drawable somehow ends up null.
Jul 16 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 1.  Doesn't Window mean that the plot would have to exist in its own window? 
I'd
 like to be able to make a plot go to one section of a larger window.
 2.  When I do:
 drawable = (new DrawingArea(800, 600)).getWindow();
 drawable somehow ends up null.

Never mind, I figured this stuff out, though the documentation is rather obtuse and in serious need of examples of how to accomplish simple things. However, I can't get the DrawingArea to actually show up on the screen. I just get a blank window. Here's a reduced test case. Can someone tell me what's wrong w/ it and/or provide minimal example code to get stuff drawn via DrawingArea to show up on screen? import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable, gdk.Color; void main(string[] args) { Main.init(args); auto win = new MainWindow("Hello, world"); win.setDefaultSize(800, 600); auto drawingArea = new DrawingArea(800, 600); win.add(drawingArea); drawingArea.realize(); auto drawable = drawingArea.getWindow(); auto gc = new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); drawingArea.showAll(); drawingArea.queueDraw(); win.showAll(); Main.run(); }
Jul 16 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

dsimcha wrote:
 =3D=3D Quote from dsimcha (dsimcha yahoo.com)'s article
 1.  Doesn't Window mean that the plot would have to exist in its own w=


 like to be able to make a plot go to one section of a larger window.
 2.  When I do:
 drawable =3D (new DrawingArea(800, 600)).getWindow();
 drawable somehow ends up null.

Never mind, I figured this stuff out, though the documentation is rathe=

 and in serious need of examples of how to accomplish simple things.  Ho=

 can't get the DrawingArea to actually show up on the screen.  I just ge=

 window.  Here's a reduced test case.  Can someone tell me what's wrong =

 and/or provide minimal example code to get stuff drawn via DrawingArea =

 on screen?
=20
 import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable,=

     gdk.Color;
=20
 void main(string[] args) {
     Main.init(args);
=20
     auto win =3D new MainWindow("Hello, world");
     win.setDefaultSize(800, 600);
     auto drawingArea =3D new DrawingArea(800, 600);
     win.add(drawingArea);
     drawingArea.realize();
=20
     auto drawable =3D drawingArea.getWindow();
     auto gc =3D new GC(drawable);
     gc.setForeground(new Color(255, 0, 0));
     gc.setBackground(new Color(255, 255, 255));
     drawable.drawLine(gc, 0, 0, 100, 100);
=20
     drawingArea.showAll();
     drawingArea.queueDraw();
     win.showAll();
=20
     Main.run();
 }

it won't remember what you draw on it. There are two solutions to this: - Use a Canvas widget. There isn't one in gtk, but there are some options out there. I don't know if any of them have a D wrapper; - Define a callback for the "expose_event" signal on your drawingArea and put your drawing code in there. Try the following (untested) code: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8<--------------------------= -------------- import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable, gdk.Color; bool onExposeEvent (GdkEventExpose*, Widget drawingArea) { auto drawable =3D drawingArea.getWindow(); auto gc =3D new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); } void main(string[] args) { Main.init(args); auto win =3D new MainWindow("Hello, world"); win.setDefaultSize(800, 600); auto drawingArea =3D new DrawingArea(800, 600); win.add(drawingArea); drawingArea.realize(); drawingArea.addOnExpose ((GdkEventExpose* event, Widget drawingArea) { auto drawable =3D drawingArea.getWindow(); auto gc =3D new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); return true; }); drawingArea.showAll(); drawingArea.queueDraw(); win.showAll(); Main.run(); } ---------------------------------------->8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 16 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 17.07.2010 07:57, "Jérôme M. Berger" wrote:
 dsimcha wrote:
 == Quote from dsimcha (dsimcha yahoo.com)'s article
 1.  Doesn't Window mean that the plot would have to exist in its own window? 
I'd
 like to be able to make a plot go to one section of a larger window.
 2.  When I do:
 drawable = (new DrawingArea(800, 600)).getWindow();
 drawable somehow ends up null.

Never mind, I figured this stuff out, though the documentation is rather obtuse and in serious need of examples of how to accomplish simple things. However, I can't get the DrawingArea to actually show up on the screen. I just get a blank window. Here's a reduced test case. Can someone tell me what's wrong w/ it and/or provide minimal example code to get stuff drawn via DrawingArea to show up on screen? import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable, gdk.Color; void main(string[] args) { Main.init(args); auto win = new MainWindow("Hello, world"); win.setDefaultSize(800, 600); auto drawingArea = new DrawingArea(800, 600); win.add(drawingArea); drawingArea.realize(); auto drawable = drawingArea.getWindow(); auto gc = new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); drawingArea.showAll(); drawingArea.queueDraw(); win.showAll(); Main.run(); }

it won't remember what you draw on it. There are two solutions to this: - Use a Canvas widget. There isn't one in gtk, but there are some options out there. I don't know if any of them have a D wrapper; - Define a callback for the "expose_event" signal on your drawingArea and put your drawing code in there. Try the following (untested) code: ========================================8<---------------------------------------- import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable, gdk.Color; bool onExposeEvent (GdkEventExpose*, Widget drawingArea) { auto drawable = drawingArea.getWindow(); auto gc = new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); } void main(string[] args) { Main.init(args); auto win = new MainWindow("Hello, world"); win.setDefaultSize(800, 600); auto drawingArea = new DrawingArea(800, 600); win.add(drawingArea); drawingArea.realize(); drawingArea.addOnExpose ((GdkEventExpose* event, Widget drawingArea) { auto drawable = drawingArea.getWindow(); auto gc = new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); return true; }); drawingArea.showAll(); drawingArea.queueDraw(); win.showAll(); Main.run(); } ---------------------------------------->8======================================== Jerome

return. ("TRUE to stop other handlers from being invoked for the event. FALSE to propagate the event further.") But with these small fixes, it's working. dsimcha there's an example in the gtkd source: demos/cairo/cairo_clock The gtkd Makefile doesn't compile it for some reason, but it is working with D2. -- Johannes Pfau
Jul 17 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Johannes Pfau wrote:
 On 17.07.2010 07:57, "J=C3=A9r=C3=B4me M. Berger" wrote:
 dsimcha wrote:
 =3D=3D Quote from dsimcha (dsimcha yahoo.com)'s article
 1.  Doesn't Window mean that the plot would have to exist in its own=




 like to be able to make a plot go to one section of a larger window.=




 2.  When I do:
 drawable =3D (new DrawingArea(800, 600)).getWindow();
 drawable somehow ends up null.




 and in serious need of examples of how to accomplish simple things.  =



 can't get the DrawingArea to actually show up on the screen.  I just =



 window.  Here's a reduced test case.  Can someone tell me what's wron=



 and/or provide minimal example code to get stuff drawn via DrawingAre=



 on screen?

 import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawabl=



     gdk.Color;

 void main(string[] args) {
     Main.init(args);

     auto win =3D new MainWindow("Hello, world");
     win.setDefaultSize(800, 600);
     auto drawingArea =3D new DrawingArea(800, 600);
     win.add(drawingArea);
     drawingArea.realize();

     auto drawable =3D drawingArea.getWindow();
     auto gc =3D new GC(drawable);
     gc.setForeground(new Color(255, 0, 0));
     gc.setBackground(new Color(255, 255, 255));
     drawable.drawLine(gc, 0, 0, 100, 100);

     drawingArea.showAll();
     drawingArea.queueDraw();
     win.showAll();

     Main.run();
 }

it won't remember what you draw on it. There are two solutions to this=


 - Use a Canvas widget. There isn't one in gtk, but there are some
 options out there. I don't know if any of them have a D wrapper;
 - Define a callback for the "expose_event" signal on your
 drawingArea and put your drawing code in there.

 	Try the following (untested) code:
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


-----------------
 import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC,
     gdk.Drawable, gdk.Color;

 bool onExposeEvent (GdkEventExpose*, Widget drawingArea) {
     auto drawable =3D drawingArea.getWindow();
     auto gc =3D new GC(drawable);
     gc.setForeground(new Color(255, 0, 0));
     gc.setBackground(new Color(255, 255, 255));
     drawable.drawLine(gc, 0, 0, 100, 100);
 }

 void main(string[] args) {
     Main.init(args);

     auto win =3D new MainWindow("Hello, world");
     win.setDefaultSize(800, 600);
     auto drawingArea =3D new DrawingArea(800, 600);
     win.add(drawingArea);
     drawingArea.realize();

     drawingArea.addOnExpose ((GdkEventExpose* event,
                               Widget drawingArea) {
         auto drawable =3D drawingArea.getWindow();
         auto gc =3D new GC(drawable);
         gc.setForeground(new Color(255, 0, 0));
         gc.setBackground(new Color(255, 255, 255));
         drawable.drawLine(gc, 0, 0, 100, 100);
 	return true;
     });

     drawingArea.showAll();
     drawingArea.queueDraw();
     win.showAll();

     Main.run();
 }
 ---------------------------------------->8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


=3D=3D=3D=3D=3D
 		Jerome

return. ("TRUE to stop other handlers from being invoked for the event.=

 FALSE to propagate the event further.")
 But with these small fixes, it's working.
=20

for onExposeEvent, I forgot to remove it when I put the code directly in an anonymous delegate. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 17 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
Thanks.  The GTK port is officially off the ground, i.e. I've now at least got a
basic plot window up.  Now, to decipher gtkD's font API.

== Quote from "Jérôme M. Berger" (jeberger free.fr)'s article
 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 --------------enigEB95B6E017DCC321C6AC57B2
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 dsimcha wrote:
 =3D=3D Quote from dsimcha (dsimcha yahoo.com)'s article
 1.  Doesn't Window mean that the plot would have to exist in its own w=


 like to be able to make a plot go to one section of a larger window.
 2.  When I do:
 drawable =3D (new DrawingArea(800, 600)).getWindow();
 drawable somehow ends up null.

Never mind, I figured this stuff out, though the documentation is rathe=

 and in serious need of examples of how to accomplish simple things.  Ho=

 can't get the DrawingArea to actually show up on the screen.  I just ge=

 window.  Here's a reduced test case.  Can someone tell me what's wrong =

 and/or provide minimal example code to get stuff drawn via DrawingArea =

 on screen?
=20
 import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable,=
     gdk.Color;
=20
 void main(string[] args) {
     Main.init(args);
=20
     auto win =3D new MainWindow("Hello, world");
     win.setDefaultSize(800, 600);
     auto drawingArea =3D new DrawingArea(800, 600);
     win.add(drawingArea);
     drawingArea.realize();
=20
     auto drawable =3D drawingArea.getWindow();
     auto gc =3D new GC(drawable);
     gc.setForeground(new Color(255, 0, 0));
     gc.setBackground(new Color(255, 255, 255));
     drawable.drawLine(gc, 0, 0, 100, 100);
=20
     drawingArea.showAll();
     drawingArea.queueDraw();
     win.showAll();
=20
     Main.run();
 }

it won't remember what you draw on it. There are two solutions to this: - Use a Canvas widget. There isn't one in gtk, but there are some options out there. I don't know if any of them have a D wrapper; - Define a callback for the "expose_event" signal on your drawingArea and put your drawing code in there. Try the following (untested) code: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8<--------------------------= -------------- import gtk.DrawingArea, gtk.Main, gtk.MainWindow, gdk.GC, gdk.Drawable, gdk.Color; bool onExposeEvent (GdkEventExpose*, Widget drawingArea) { auto drawable =3D drawingArea.getWindow(); auto gc =3D new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); } void main(string[] args) { Main.init(args); auto win =3D new MainWindow("Hello, world"); win.setDefaultSize(800, 600); auto drawingArea =3D new DrawingArea(800, 600); win.add(drawingArea); drawingArea.realize(); drawingArea.addOnExpose ((GdkEventExpose* event, Widget drawingArea) { auto drawable =3D drawingArea.getWindow(); auto gc =3D new GC(drawable); gc.setForeground(new Color(255, 0, 0)); gc.setBackground(new Color(255, 255, 255)); drawable.drawLine(gc, 0, 0, 100, 100); return true; }); drawingArea.showAll(); drawingArea.queueDraw(); win.showAll(); Main.run(); } ---------------------------------------->8=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr --------------enigEB95B6E017DCC321C6AC57B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxBRmkACgkQd0kWM4JG3k9XSQCcC3JbX8BbPAhKP10SCVnWkEaM ELYAnjxrivlSDZC54vcx5wJtIqOYXVTF =RscJ -----END PGP SIGNATURE----- --------------enigEB95B6E017DCC321C6AC57B2--

Jul 17 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 17.07.2010 15:08, dsimcha wrote:
 Thanks.  The GTK port is officially off the ground, i.e. I've now at least got
a
 basic plot window up.  Now, to decipher gtkD's font API.

Great! Are you using cairo now? I think the cairo api should be nicer than the native gtk api. And if you need advanced text rendering you can use pango with cairo: http://www.dsource.org/projects/gtkd/browser/trunk/demos/pango/pangocairo.d -- Johannes Pfau
Jul 17 2010
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Johannes Pfau (spam example.com)'s article
 On 17.07.2010 15:08, dsimcha wrote:
 Thanks.  The GTK port is officially off the ground, i.e. I've now at least got
a
 basic plot window up.  Now, to decipher gtkD's font API.

Are you using cairo now? I think the cairo api should be nicer than the native gtk api. And if you need advanced text rendering you can use pango with cairo: http://www.dsource.org/projects/gtkd/browser/trunk/demos/pango/pangocairo.d

No, I'm not using Cairo right now. Adding Cairo to the list of backends supported will probably be a todo later, but right now native GTK maps more cleanly to the abstractions I've chosen, and to me seems to have an easier API.
Jul 17 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article
 On Sat, 17 Jul 2010 13:08:01 +0000, dsimcha wrote:
 Thanks.  The GTK port is officially off the ground, i.e. I've now at
 least got a basic plot window up.  Now, to decipher gtkD's font API.

-Lars

If you (or anyone else) wants to play around, I've got a more-or-less working, but admittedly buggy and unpolished version of Plot2Kill that works w/ both DFL and gtkD up. By more-or-less working I mean you **will** run into significant bugs trying to use it (the biggest one being no Y-axis text), but even the GTK version is functional enough to produce this screenshot w/o any crazy workarounds: http://cis.jhu.edu/~dsimcha/plot2killGTK.png The code is at: http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting Eventually it will be moving to its own dsource project. You need either gtkD SVN or DFL release candidate installed before you start. Then, simply download all the D files and compile all them with to a lib with -version=gtk to use GTK or -version=dfl to use DFL. (It doesn't matter if you pass in the GTK-related files to the compiler when compiling the DFL version or vice-versa because all the irrelevant code will be versioned out.) Right now, the DFL version is less buggy and I recommend it unless you either want to develop the GTK version or aren't using Windows.
Jul 17 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article
 On Sat, 17 Jul 2010 13:08:01 +0000, dsimcha wrote:
 Thanks.  The GTK port is officially off the ground, i.e. I've now at
 least got a basic plot window up.  Now, to decipher gtkD's font API.

-Lars

Now for one last request for help from the audience: I've got rotated text (meaning Y-axis labels) and saving working. The only major hangup left is that the subplot window is horribly broken w.r.t. resizing and zoom. What's the proper way to forward a resize event of a parent window to all child windows in gtkD?
Jul 17 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

dsimcha wrote:
 =3D=3D Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s ar=

 On Sat, 17 Jul 2010 13:08:01 +0000, dsimcha wrote:
 Thanks.  The GTK port is officially off the ground, i.e. I've now at
 least got a basic plot window up.  Now, to decipher gtkD's font API.

-Lars

Now for one last request for help from the audience: =20 I've got rotated text (meaning Y-axis labels) and saving working. The =

 hangup left is that the subplot window is horribly broken w.r.t. resizi=

 zoom.  What's the proper way to forward a resize event of a parent wind=

 child windows in gtkD?

You need to use the "size-request" and "size-allocate" signals. The first one allows a child to tell the parent what size it would prefer to have and the second allows the parent to tell the child what size it is actually given. Both are called during a resize event of the parent window. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 18 2010
prev sibling parent Mike Wey <mike-wey example.com> writes:
On 07/16/2010 03:34 PM, dsimcha wrote:
 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.

gdk.Drawable is meant to be used as either a gdk.window or a gdk.Pixmap it more or less acts as a abstract class. Or you can get the Drawable of a Drawing Area like this: DrawingArea area = new DrawingArea(); Drawable draw = area.getWindow(); You're probably going to use cairo for drawing so it might be a good idea to look at the cairo demos/examples: http://www.dsource.org/projects/gtkd/browser/trunk/demos/cairo/text_image/text_image.d Cairo also allows drawing to files: png. svg, pdf and ghostscript. -- Mike Wey
Jul 17 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sat, 17 Jul 2010 13:08:01 +0000, dsimcha wrote:

 Thanks.  The GTK port is officially off the ground, i.e. I've now at
 least got a basic plot window up.  Now, to decipher gtkD's font API.

Awesome! :) Can't wait to try this out. -Lars
Jul 17 2010
prev sibling parent Byron Heads <bheads emich.edu> writes:
On Fri, 16 Jul 2010 02:41:01 +0000 (UTC), dsimcha <dsimcha yahoo.com> 
wrote:
 I've refactored my dflplot lib to the point where the GUI-specific 

 well abstracted from the GUI-agnostic stuff in preparation for a 

 lib that supports rotated fonts, saving bitmaps, and/or *nix.  The 

You could use SDL to do your drawing. SDL_ttf would handel fonts, but you would have rotate them yourself ( not hard in. SDL ). -- Sent from my droid.
Jul 16 2010