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