On 29/08/13 16:44, Rikki Cattermole wrote:
On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote:
On 29/08/13 16:11, Rikki Cattermole wrote:
I will say this, one thing about D that has annoyed me from the
beginning is the state of the gui libs. Hence why in last month I've
been having a real good play around with OpengGL and creating my own
library [1].
On this topic, I started looking at porting one of my PyGTK
applications to GtkD and found that the knowledge of PyGTK API wasn't
a great deal of help in this endeavor. I think the problem is
Python's "duck typing" and dynamic typing allow for a very flexible
API that is much simpler than GTK+'s and GtkD's is much like GTK+'s.
The problem is complicated by the fact that the amount of
documentation is huge and it's often difficult to find where something
is defined.
Anyway, long story short, I've decided to investigate the feasibility
of rewriting the parts of GTK+ that I like directly in D. It's early
days yet and the code is in a private repository on github. I'll keep
it private until I have some useful subset working at which time I'll
make it public. Of course, if I find that it's all too hard I'll just
delete it.
Early indications are that the code will be much simpler than the
original as GTK+ implements its own OOP and GC where I'll just
delegate that to D. :-)
Peter
Nice :)
Although be careful it was designed for more Posix environment.
I'm keeping DOOGLE as far limited in terms of platform dependence.
So porting is literally implement the OpenGL context creation and Window
creation classes.
Also for anyone interested I'm keeping the controls that require text
out of DOOGLE because of the font rasterizer dependency.
I'm starting at the top and working towards the "down and dirty" bits so
issues such as platform dependence haven't arisen yet. My strategy is
to look at the header file for a widget and extract its public interface
and then implement a D class with that interface using the widget's C
source file for guidance.
My thinking is that when I get to the bottom I define an abstract
interface for the "down and dirty" part and then implement it for the
back end of my choice leaving others to do the same for the back end of
their if they can't wait for me to get around to it. Design of this
interface is probably something I will need assistance from people
familiar with Windows/Mac/X11/Weyland so that the interface is
implementable and not biased towards one or another.
