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?


 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


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 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.


 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.


 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.


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.


 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.
-- 
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.


 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
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:
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=




indow?  I'd

 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.


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


r obtuse

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


wever, I

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


t 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?
=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();
 }


	The problem is that gtk.DrawingArea is stateless. This means that
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();
 }


 	The problem is that gtk.DrawingArea is stateless. This means that
 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


It's missing the gtk.Widget import and onExposeEvent is missing a
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:
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=








 window?  I'd

 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 rat=






her 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 wron=






g w/ it

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






a to show up

 on screen?

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






e,

     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();
 }


 	The problem is that gtk.DrawingArea is stateless. This means that
 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


 It's missing the gtk.Widget import and onExposeEvent is missing a
 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


	Well, I didn't check the imports from the original message :) As
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=




 indow?  I'd

 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.


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


 r obtuse

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


 wever, I

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


 t 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?
=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();
 }


 	The problem is that gtk.DrawingArea is stateless. This means that
 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.


 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


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 parent reply "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
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.


 Awesome! :)  Can't wait to try this out.
 -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.


 Awesome! :)  Can't wait to try this out.
 -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:
dsimcha wrote:

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


ticle

 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


=20
 Now for one last request for help from the audience:
=20
 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. resizi=


ng and

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


ow to all

 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 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 


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

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