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

Danny Baumann dannybaumann at web.de
Mon Apr 30 08:43:04 EDT 2007


Hi,

> > Yes, of course you are right that there might be solutions in 99% of all
> > cases as long as not all configuration plugins are disabled. However,
> > this is still not completely offline.
> >   
> 
> I am still not really sure of the benefit of offline configuration.
> I do not think they are worth the extra effort to rewrite all the
> settings backends.
> 
> Surely we are aiming for compiz to always be running?

Yes, we are. But with a growing number of plugins there is the growing
problem of misconfiguration which could lead to inusability. Without
offline configruration, we have a totally unsuable window manager at
that point.

> > I do not really like the official vs. unofficial separation that much
> > because I think people will use what will suit their needs best (or
> > least what they think will suit their needs best) no matter if its
> > official or unofficial.
> >   
> 
> This is what you always say ;)

I know - and I say that because I believe in it :-)
If something is not in the FDO repo, it's not per se worse.

> >> It would also be much easier to maintain because the code
> >> would be much smaller and would serve one purpose which
> >> you can isolate easily.
> >>     
> >
> > While I agree in principle, did you have a look at the libbs sources?
> > It's no voodoo and issues can be tracked down pretty easily - I did that
> > numerous times last week ;-)
> >   
> 
> Thats kind of my point ;)

You had no bug at all in ini.c? ;-)

> > I don't see how this is related to dbus and fuse. Of course it can be
> > done with different approaches, too, but I believe that abstracting the
> > profile support from the actual settings manager is a good thing.
> >   
> 
> dbus and fuse are ways to access settings without worrying
> about the backend so they can be used easily to dump settings
> in a neutral format.

Yes, right, but they still need Compiz to be running and need to be
loaded - see above ;-)

> > Libbs IS this libcompizutil ;-)
> > The functions are pretty distinct, and I also think we should not have a
> > couple of libraries which only deal with settings management. IMO (yes,
> > I know I'm biased) we should develop one single solution in a way so
> > that everyone can and wants to use it.
> >   
> 
> Libbs requires that you do not use configuration plugins
> and forces everyone to use libbs + bset + all other libbs apps.
> 
> Its just not going to work ;)

If you use a libbs settings manager, you need to use bset, that's
correct. Still I can't see the functional disadvantages in that ;-)

> > Libbs provides a function which automatically sorts the plugin load
> > order. Of course you are free not to use this function and keep your
> > unsorted (or manually sorted) list.
> >   
> 
> Again this is a fairly trivial task.
> 
> Look at the code to my python web server, I have 1 function
> which makes sure that plugins are loaded in the correct order.
> The GUI just requests 'load rotate' and it will make sure that
> cube is loaded and they are all in the correct order.

I never said this task is complicated. I just said avoiding duplicating
it might be a good idea.

> >>> I'm not sure if you don't want to understand the point here. Noone wants
> >>> to repackage Compiz, but create easy-to-use packages around Compiz. I am
> >>> not sure if there is any Linux distribution that packages the kernel
> >>> under a different name than "kernel". 
> >>>   
> >>>       
> >> Are you REALLY sure about that?
> >>
> >> It seems like thats exactly the idea at least some people have.
> >>     
> >
> > Yes, I am REALLY sure here. Whom are those "some people" you mean?
> > Perhaps they can comment on it, but I have still to hear anyone who
> > wants to repackage Compiz.
> >   
> 
> I am sure your email client has some sort of search facility.
> 
> I am not allowed to name names.  Search for things like package,
> distribution, 'new software', 'not compiz'.

Come on, this is a public mailing list. Please show the posts you mean
so we can discuss about it if neccessary.

> Nothing has ever been made clear about what is what.  People just
> assume its what they want to hear without any clarification.
> 
> Either way its a pointless idea (that should snuff em out ;))

I think you got the idea now, and I also think we are in agreement
here. ;-)

Regards,

Danny




More information about the CompComm mailing list