[Compcomm] So what's going on code-wise? Or what we're working on.

[Danny Baumann]

Hi,

> Compizutil (not libcompizutil ;)) is exactly the same as libbs and
> offers more or less the same features (e.g. talks to compiz over various
> backends, profiles-system). The major differences are: 

THIS IS NOT TRUE. And you know that. Compizutil takes a completely
different approach, so it's just plain wrong to say it's exactly the
same.

> - compizutil has 5% of the codesize of libbs (the whole compizutil-lib
> including all (full-text) documentation, comments and the dbus-backend
> are still SMALLER than only the main.c of libbs ;) ...)

And it does much less than libbs, namely no offline settings
reading/writing, no DE integration support (using your DEs default WM
settings), no profile support and no settings import/export. In other
words: It does NOTHING libbs currently does.
BTW: You know as good as I do that compizutil will/would be as large as
libbs if it actually did all the things libbs does. Besides that, your
number is absurd.

> - compizutil is a pure python module and not meant for any language but
> python (because nearly all modern GUI-apps for Linux are written in
> python anyway), it has NO depandancies and doesn't need to be built like
> a C-library

It has a dependency which is python, so it has more dependencies than
libbs which is Compiz only (obviously). No end user will care if the
software needs to be built or is running in an interpreter.

> - compizutil is a higher-level library with an object-oriented design

And the advantage of that is what?

> And to avoid any speculations: Yes, I think libbs is useless - and I
> further think unless it gets another (more descriptive) name I wouldn't
> expect it to be used by anyone but the people who wrote it. 

Problem here is that there actually _are_ people using it besides the
people who wrote it. You are right about the name, however.

> If someone could tell me a single use-case where this libbs-thing is
> really needed, then I maybe understand why we need a binary library for
> that. 

Disable DBUS in your settings manager and you'll see the problem. Or try
to configure a plugin before loading it.

> As far as I know it is highly recommended to NOT write GUI-apps in
> C in the 21th century ... So where should libbs come into play? If
> someone wants to write settings-tools in C# or boo? To make mono a
> dependancy of the "new project"? Surely not.

Hmm, what are you trying to say here? That Python is better than Mono?
That's nonsense.
Besides that, in case you haven't noticed, there actually are people who
are not using Python. The mail client I type this mail into (Evolution)
for example, is written in plain old C. You seem to have forgot that the
vast majority to today's Linux apps are written in non-interpreted
languages (mostly C and C++) - perhaps mostly written by masochists. The
KDE4/Qt4 people seem to be masochists, too, as they are using C++.

> The library itself isn't generally bad - it is just like with vBulletin,
> why would we need to spend time and effort with something that is going
> to be never actually used?

We should we keep pretending noone will use stuff we (as in: you) won't
ever use?

> It is clear that all settings-apps will be written in python. 

Who said that?

> Why should
> I use a python-binding for libbs if I can just use python-compizutil and
> have a high-level, python-oriented way to work with compiz - without any
> library-overhead??

Perhaps because python-compizutil (I thought it's named Compizutil,
isn't it?) still isn't the holy grail? Because not everyone loves
Python? Because this python library still needs to talk directly to
Compiz plugins (if DBUS isn't available) without any level of
abstraction although it is "high level"?

Regards,

Danny