[Kde-bindings] Qyoto on Windows

[Steven Boswell II]

Thanks for the link to the Smoke documentation -- I'll get on that.

Re: "special casing", I think that's the best option.  The alternative is to document what's going to screw up if the client code doesn't special-case it.  But from what I can tell, that hasn't even been done -- witness the letter to this list from June 2009, the one that never got answered.  Therefore, I think that proceeding with these special cases, and waiting for testers to note where more needs to be done, is the right way to go.

Steven Boswell



________________________________
 From: Arno Rehn <arno at arnorehn.de>
To: Steven Boswell II <ulatekh at yahoo.com>; kde-bindings at kde.org 
Sent: Friday, December 2, 2011 10:20 AM
Subject: Re: [Kde-bindings] Qyoto on Windows
 
On Friday 02 December 2011 06:21:14 you wrote:
> That's OK, I understand how things are.  But could you (or someone else on
> this list) point me in the direction of some developer documentation that
> would allow me to understand how Qyoto and Smoke work?  The source-code
> comments aren't much to go on.
There's http://techbase.kde.org/Development/Languages/Smoke with information 
about how Smoke works and how to generate a Smoke library. The example is 
still using the monolithic smoke qt lib, which doesn't exist anymore in the 
newer Smoke versions. But the principle is still the same, except that now you 
do "init_qtcore_smoke", "init_qtgui_smoke" etc...
Qyoto is only a bridge between the Smoke stuff and C#, adding custom 
marshallers (QList<type> -> System.Collections.Generic.List, etc.) and some 
garbage collection handling.

> BTW, in response to my earlier query about SetModel() doing something to
> prevent garbage-collection of the incoming item model, it appears the
> solution is easy, though it involves editing kalyptus-generated files that
> say "DO NOT EDIT".  All I did was add "protected QAbstractItemModel
> m_Model" to QAbstractItemView, and "m_Model = model;" to
> QAbstractItemView.SetModel() and QTreeView.SetModel().  This takes care of
> the problem that I was reproducing in my code.  Granted, there are many
> other places where this would have to be done, but other than editing
> machine-generated files, the idea appears to be sound.
Yep, that's what I meant with 'special casing' specific methods. The problem is 
that there may be more than one way to set a model. So it might work for this 
specfic function call, but in general it still screws up. Iff there's more than 
one way, you have to make sure you keep them all in sync, otherwise it might 
screw up again, etc...


> Steven Boswell
> 
> 
> 
> ________________________________
>  From: Arno Rehn <arno at arnorehn.de>
> To: Steven Boswell II <ulatekh at yahoo.com>; KDE bindings for other
> programming languages <kde-bindings at kde.org> Sent: Friday, December 2, 2011
> 7:01 AM
> Subject: Re: [Kde-bindings] Qyoto on Windows
> 
> On Friday 02 December 2011 05:50:00 Steven Boswell II wrote:
> > OK, I'll try your changes sometime today.
> > 
> > I wanted to build my own binaries because I wanted the opportunity to
> > track down bugs.  Your binaries aren't totally functional yet, after
> > all.  Also, I was hoping that someone on this mailing list would know
> > how to modify the existing projects the right way to cope with the
> > Windows build issues.
> 
> If I had more time, I would be willing to help, so that at least the
> buildsystem would work fine on Windows. However I'm quite busy atm and can't
> spare much time.
> I'm afraid your on your own, more or less. But I'll help whenever I can
> spare the time.
-- 
Arno Rehn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20111205/852bc11b/attachment.html>