Missing Stuff
=============

- Extract functions for Dates and Times
- Ability to have a 'standard library of js'

--------------------------------

Ian's List:
* Slot return types should use the value factories so all
  bound types are supported.
* Ability to layer bindings.
	- Matt says that by using QCoreApplication we get a large
	  speedup.  If we can layer the bindings so that users
	  could start with only core Qt.  Then we give the ability
	  to add on KDE and Qt gui bindings at run time.  This
	  will keep small scripts with out guis fast, but not
	  make adding KDE support harder.
* Bindings for KParts (be able to load readonly and readwrite parts)
* Bindings for KIO (net access api)
* Bindings for DCOP (dbus or what ever it is this week)
* Handle QPixmap and Image gracefully in QPainter bindings.

Rich's List:

* A good example of how to embed the interpreter.

  The editor example is a good start for this.

* Get the bindings like bind_qworkspace I did in Malaga into the main
  tree (they're in editor at the moment).

* Improve the documentation so people can use this stuff!

* Get f'ing QListWidget working so we can port the docviewer properly.

* Check the design of the JS-side APIs to ensure they're what we
  really want rather than just "because that's how did it when we
  we're trying to get stuff working".

Comments from pmax:

<pmax> richmoore: how do we encapsulate all of KJS in kjsembed so we don't expose the KJS API?
<richmoore> pmax: currently we don't
<richmoore> pmax: if people want to add custom bindings then unless they define them as QObjects and use the automagic bindings they need to interoperate with kjs at some level (as you do in kst)
<pmax> right
<pmax> we need a plan to encapsulate that
<richmoore> pmax: if we need to encapsulate it then we could though by adding a wrapper that allows you to add methods etc. to objects
<pmax> yes
<pmax> this would be ~awesome
<richmoore> i'll have a think about how we can do that
<richmoore> i can see some ways it could be approached that would be fairly easy given the implementation of the new bindings
<richmoore> basically at the moment we use templates to 'glue' to the C++, there's no reason we couldn't do the same at the JS end of things
<pmax> makes sense
<richmoore> another approach would be a singleton class that knows about the internals and provides methods to operate on them
<pmax> even better if we could make this KDE-independent too
<pmax> because then I think Apple would adopt it
<richmoore> it would have to be as kjsembed supports qt only mode
<richmoore> i have to head out in 5 minutes, but i'll have a think about how we could do this
<pmax> even Qt-independent
<richmoore> i don't think it would be too hard from our current position
 pmax might be able to throw some developer time at it
<richmoore> i think it could be qt independent too, as it only needs to know about kjs
<richmoore> it might need some declared but unimplemented methods to handle qstring conversions (as kjs already has) but that's no biggy
<pmax> actually I don't think it needs it
<pmax> we can make it compile-time optional
<richmoore> yeah, that would work
<pmax> since KJS will become an internal API, the platform can decide which implementations to provide
<richmoore> yes
<richmoore> the facilities the wrapper would need are quite simple
<richmoore> even now, we don't really do much with the internals of kjs - we just use a small number of bits of the api

Erik's List:
* Load sub-sets of the built-in bindings
  - core, file access, gui, etc.

* Automatic binding generator.

  This is needed at the very least to make it easy for people to be
  able to bind their own classes into the interpreter when embedding.

* Add seperate QApplication binding

* Add support for loadable bindings (like lua require) from:
  * built-ins
  * Qt style Plugin
  * js file 
  * KPart (someone else can do this part)
  * Loadable support will include optional support for 'require' syntax (like in lua)
