obsolete D libraries/modules

[Peter Williams]

On 06/09/13 14:18, Peter Williams wrote:
> On 29/08/13 16:34, Peter Williams wrote:
>> 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. :-)
>
> Reality check :-) - this is a huge job.  So I've amended my goals a
> little.  New plan is to start with just replacing the gtk+/gtk component
> and use wrappers to gdk, pango etc.  I did think about chucking it in
> altogether and using GtkD but the API in there hints that the onus of
> managing memory is placed on the user and that just makes writing a GUI
> that much harder.
>
> I'm hoping that my wrappers can be implemented in such a way that memory
> management is hidden inside them.

One thing that's obvious with my progress so far is that a huge amount 
of the code in GTK+ is there to implement coding features/conveniences 
that come for free with D (with much simpler APIs).  I reckon that if D 
had been around to implement the original GTK+ the source would be an 
order of magnitude smaller and a lot easier to understand.

Peter