|
|
|
|
Planned Changes
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
Core
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
- Handle non-standard signatures (that are combinations of supported
|
|
|
|
|
types). [Working, but variant support is incomplete]
|
|
|
|
|
|
|
|
|
|
- The factory class needs to become responsible for the bindings as
|
|
|
|
|
well as the creation of the objects themselves. [Partially working]
|
|
|
|
|
|
|
|
|
|
- At the moment a lot of the standard bindings etc. are rebound for
|
|
|
|
|
each proxy. This is ridiculous and totally unnecessary.
|
|
|
|
|
|
|
|
|
|
- When a proxy is created, it should use create-on-first-use semantics
|
|
|
|
|
to define the JS object defining its class. This object can then be
|
|
|
|
|
used to store the method and property wrappers. In addition, by
|
|
|
|
|
setting the prototype correctly for the created instance we can get
|
|
|
|
|
inheritence working properly.
|
|
|
|
|
|
|
|
|
|
- Extend the type handling code in slotutils.cpp to support opaque pointer
|
|
|
|
|
types properly.
|
|
|
|
|
|
|
|
|
|
- Enable emission of signals from JS that can be connected in C++
|
|
|
|
|
|
|
|
|
|
- DOM Level 2 support.
|
|
|
|
|
|
|
|
|
|
- Clean up slot handeling code.
|
|
|
|
|
|
|
|
|
|
- Clean up opaque proxy so the pointers can be GCed.
|
|
|
|
|
|
|
|
|
|
- Clear up ownership issues with respects to objects generated from
|
|
|
|
|
applications that embed KJSEmbed and wrap internal objects with
|
|
|
|
|
opaque proxies.
|
|
|
|
|
|
|
|
|
|
Bind Wizard
|
|
|
|
|
===========
|
|
|
|
|
|
|
|
|
|
- Missing arg types:
|
|
|
|
|
- TQColorGroup &
|
|
|
|
|
- TQPainter *
|
|
|
|
|
|
|
|
|
|
Bindings
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
- Add more Bind_XXX classes.
|
|
|
|
|
|
|
|
|
|
- Move to the same pattern as the KJS/DOM bindings for better
|
|
|
|
|
inheritence support.
|
|
|
|
|
|
|
|
|
|
- Support for TQSignal
|
|
|
|
|
|
|
|
|
|
- A generic wrapper for TQStyle so you can write styles in JS.
|
|
|
|
|
|
|
|
|
|
License Clarification
|
|
|
|
|
=====================
|
|
|
|
|
|
|
|
|
|
<kupid> I talked to Matthias and we'll have to explictly state somewhere in the license that you're not
|
|
|
|
|
allowed to create the widgets with it. They way he saw it is that there should be any problem because
|
|
|
|
|
if you write a script and it's internal and you don't redistribute it then it can be whatever you want, if you
|
|
|
|
|
do redistribute it then it's a script and the code is right there so you might as well make it explicit that
|
|
|
|
|
it's gpl or lgpl
|
|
|
|
|
<richmoore> i don't quite follow
|
|
|
|
|
<richmoore> are you saying that if you use the widget factory then the license degrades from LGPL to
|
|
|
|
|
GPL?
|
|
|
|
|
<richmoore> (this would make sense btw)
|
|
|
|
|
<kupid> Yes, that's the thing, we just can't allow people to use GPL licensed Qt classes under LGPL
|
|
|
|
|
<richmoore> that's fair enough
|
|
|
|
|
<richmoore> i was aware of that
|
|
|
|
|
<richmoore> i think the easiest solution is to allow a script to specify a license and use that to
|
|
|
|
|
determine the available bindings (and to provide a pure-LGPL build target with no qt support)
|
|
|
|
|
<richmoore> a 'check-license' mode is also a good idea
|
|
|
|
|
<richmoore> the same situation will apply when i add bindings for Kalle's charting library
|
|
|
|
|
<richmoore> this is one of the reasons why i want the bindings to be dynamically loaded
|
|
|
|
|
<richmoore> thanks for checking this, it is good to know the trolls opinion here
|
|
|
|
|
<kupid> That sounds great (sorry for having a slow response time but I'm running around the labs)
|
|
|
|
|
<richmoore> no problem
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
