obsolete D libraries/modules

[Peter Williams]

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.