blob: 38c3eafe0216bdb06c9ae409dbd2762e3f6508eb (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
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:
- 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
|
