summaryrefslogtreecommitdiffstats
path: root/kjsembed/docs/TODO
diff options
context:
space:
mode:
authortoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
committertoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
commit90825e2392b2d70e43c7a25b8a3752299a933894 (patch)
treee33aa27f02b74604afbfd0ea4f1cfca8833d882a /kjsembed/docs/TODO
downloadtdebindings-90825e2392b2d70e43c7a25b8a3752299a933894.tar.gz
tdebindings-90825e2392b2d70e43c7a25b8a3752299a933894.zip
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
Diffstat (limited to 'kjsembed/docs/TODO')
-rw-r--r--kjsembed/docs/TODO81
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
+
+
+