Platform API todo

Andreas Pakulat apaku at gmx.de
Fri May 25 00:26:29 UTC 2007


Hi,

with the upcoming move of lib to the new module I'd like to clear up a
few question regarding the Platform API TODO list in the wiki. I'm
putting my comments inline.

* compile libkdevelop.la with -DQT_NO_CAST_FROM_ASCII

Thats something we should try, I guess.

* move stuff from the public API to private/internal headers 

Thats covered by krazy, the duchain move introduced a few new problems
(and possibly false positives), but I think I can fix that next week.

* remove booleans from the API (we should use enums) and Q_DECLARE_FLAGS stuff 

IIRC pretty much all public API has flags instead of
booleans now.

* try to use interfaces (== Q_INTERFACE, Q_DECLARE_INTERFACEm and so on..) 
* qobject_cast no dynamic_cast 
* singleton using Q_GLOBAL_STATIC 

All covered, its rather K_GLOBAL_STATIC though.

* we should avoid the use of QList<Blah*> in the public API 
  it's very difficult using QVariable/QMetaType to wrap such methods 
  instead of exposing QList<> we should use something like: 
  int documentCount() const;
  Document *documentAt(int index) const; 

Do we want to enforce this? 

* we should try to remove things like setFoo()

What does that mean? Remove setFoo()??? Or is that in terms of
setCurrentProject()?

* we should make our interface state-less 
  the point is one plug-in can change the state of the encoding and
  another plug-in expectes/requires a different state == a mess (more or
  less what we have in kdev3) 

We're on the right track here, I think.

* no assumption about having a project local, have support for remote projects

We can load/save project files from remote places, I'm not sure about
the project managers though or loading/saving files. I know for sure
that the designer plugin is not kio-aware yet.

Andreas

-- 
Cold hands, no gloves.




More information about the KDevelop-devel mailing list