dvfs api and toolkits
eikke at eikke.com
Tue Apr 5 18:00:30 EEST 2005
> As mentioned before, I don't expect apps to directly use D-VFS, but
> instead to use a toolkit-specific wrapper. If the glib wrapper wants to
> be OO, that's perfect. My question is, should the D-VFS API itself,
> which will normally be hidden/abstracted behind a toolkit API, also be
> implemented in its own OO knock-off or something simpler? Which would
> be easier to make both OO and non-OO wrappers in?
Making an OO wrapper lib to a non-OO lib seems much easier to me than
the other way around.
The DBUS also take this approach: a non-OO base structure, which in
theory shouldn't be used too much by applications directly, and
glib/Qt/Python/Mono/... OO or non-OO wrappers on top of it.
If the basic framework is OO based, I dont think people will write
non-OO accessor functions etc, because thats a hassle (non-OO to OO is
already automated for some languages, not the other way around), and if
no non-OO bindings are provided a lot of people wont be willing to use
DVFS I think.
Take this as an example: both Glib GObjects and QT C++ classes are
"objects", but they differ a lot at lower level (I'm not talking about
the languages (C/C++) here, but the low-level object representations,
functionality,...). My knowledge to this subject is very limited
More information about the xdg