Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.

BUG:215923


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdebindings@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

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
+
+
+