[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.
> Hmmm - I don't know if I should answer at all because you obviously
> never had a single look at the compizutil-module and have absolutely no
> clue of what you are talking about. 

Honestly, I don't know Python at all. That's why I haven't had a look at
the source code of compizutil yet. But obviously the same applies vice
versa.

> What you are telling is totally wrong. Compizutil takes exactly the same
> approach, it only does it more elegant, with less code and from a
> higher-level language.

> > > - 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 has no gconf/ini-backends yet - it is a 0.0.1 version -
> otherwise it has everything - even basic profiles-support (in
> XML-format).

Including DE integration, offline settings reading/writing and all that
stuff? Interesting.
How do you want to avoid code duplication in the backends that is always
seen as the worst problem of libbs?

> > 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.
> Danny, you should know that is ridiculous. If you see python as a
> "dependancy" then I have to add that libbs also has C and the whole
> compiz-"build-deps" as dependancies ... Should I list them all here?
> Please stop spreading false details ...

You obviously don't differentiate between build time and run time
dependencies. I also never said that the Python dependency is a problem
at all - libbs just has _even less_ dependencies.

> > > - compizutil is a higher-level library with an object-oriented design
> > 
> > And the advantage of that is what?
> It is not as "ancient" as procedural programming ... But some C-coders
> seem to love their thirty years old language too much to realize that.

I never said I actually love C. I like OOP way better; but I strongly
dislike interpreted languages. I also never said Python is a bad
language, but the term "higher-level library with an object-oriented
design" says exactly nothing.

> > > 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.
> Uhhhm - compizutil uses different backends so I don't get the point.

Where are those?

> Though I still see it like Mike - if compiz is configured properly,
> settings-tool produce no errors and plugins are written well, there is
> no need to configure compiz whilst it is not running.

If Compiz is configured properly, we don't need any settings manager at
all :-P

> > > 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.
> "Better" is a really subjective term. Python is the "official" and
> entirely free Linux-desktop language and should be prefered exactly for
> that reason. It will become part of the LSB sooner or later - you think
> mono will?

No, I don't think so. I still think that thinking Python is the only
"valid" language to write settings managers is ridiculous.

> You seem to take things I say much too personal. Higher-level languages
> should always be prefered over "fast languages" if the use-case is not
> speed-critical ... That's simply good practice. Masochism is kinda
> selfish, right? :D
> 
> E.g. all gnome apps will be rewritten in python sooner or later -

Link?

> remember that computers in general are getting faster day by day ...

So it's a good idea to waste this speed and memory by making all our
applications interpreted? I see.

> > > 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?
> Again - please give me some examples of (useful) applications that
> already use libbs ...

libbs-settings. Python bindings are in the works in case you haven't
noticed.
Please now show me one useful application that already uses Compizutil.
You see this game is silly?

> > > It is clear that all settings-apps will be written in python. 
> > 
> > Who said that?
> All people who are going to write the (useful) apps agreed on that ages
> ago (even Quinn followed that idea since quite a while). I don't really
> care for some low-level "heros" who can't let off their "everything in
> C"-approach  ...

You don't get my point. I didn't say writing those in Python is a bad
idea. I say excluding all people _not_ wanting to use Python is a bad
idea.

> > 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"?
> So please take the time and have a look at python-compizutil before you
> further try to argue about it without even knowing a single bit of how
> it works ... Maybe then I can take you more serious ;) ...

Frankly speaking, that's a bit arrogant as I obviously can't know what
you _plan_, but only can judge from what currently _exists_. Perhaps you
should shed a bit of light what it's exactly supposed to do when it's
out of 0.0.1 instead of talking in buzzword terms.

Regards,

Danny