diff options
Diffstat (limited to 'kjsembed/docs/TODO')
-rw-r--r-- | kjsembed/docs/TODO | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/kjsembed/docs/TODO b/kjsembed/docs/TODO new file mode 100644 index 00000000..06cfb0e4 --- /dev/null +++ b/kjsembed/docs/TODO @@ -0,0 +1,81 @@ + 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: + - QColorGroup & + - QPainter * + +Bindings +======== + +- Add more Bind_XXX classes. + +- Move to the same pattern as the KJS/DOM bindings for better + inheritence support. + +- Support for QSignal + +- A generic wrapper for QStyle 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 + + + |