Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
dsimcha wrote: == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Sat, 17 Jul 2010 13:08:01 +, 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? 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 -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
dsimcha wrote:
== Quote from dsimcha (dsim...@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
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On 17.07.2010 07:57, Jérôme M. Berger wrote:
dsimcha wrote:
== Quote from dsimcha (dsim...@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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
Johannes Pfau wrote:
On 17.07.2010 07:57, Jérôme M. Berger wrote:
dsimcha wrote:
== Quote from dsimcha (dsim...@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.
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
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
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 (jeber...@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 (dsim...@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:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@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--
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Johannes Pfau (s...@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.
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On Sat, 17 Jul 2010 13:08:01 +, 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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Sat, 17 Jul 2010 13:08:01 +, 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.
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Sat, 17 Jul 2010 13:08:01 +, 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?
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On Fri, 16 Jul 2010 02:41:01 +, 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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Lars T. Kyllingstad (pub...@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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Fri, 16 Jul 2010 02:41:01 +, 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.
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On Fri, 16 Jul 2010 02:41:01 + (UTC), dsimcha dsim...@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.
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On 16.07.2010 15:34, dsimcha wrote: == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Fri, 16 Jul 2010 02:41:01 +, 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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
On 16.07.2010 17:01, Johannes Pfau wrote: On 16.07.2010 15:34, dsimcha wrote: == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article On Fri, 16 Jul 2010 02:41:01 +, 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
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from Johannes Pfau (s...@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.
Re: dflplot/Plot2Kill, Most Mature *nix GUI For D2
== Quote from dsimcha (dsim...@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();
}
dflplot/Plot2Kill, Most Mature *nix GUI For D2
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?
