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

Sat Apr 28 14:16:33 EDT 2007

I suppose I can agree to a degree with the idea of libbs just handling
plugin sorting, an access API, etc, but in my opinion it still seems
like the best way to do offline settings reading, which is critical.

I'm not sure I agree to the benefits of stability and ease of code
maintenance. At least, I don't think there is a large difference
anyway.

Looking at it from another perspective, we have had a lot of work
built around the settings library design since before extra settings
plugins for Comipz, DBUS in a working fashion, and the other things
even existed. So from our point of view these were all duplication of
work.

Clearly it at least requires discussion, and I think onestone or Quinn
might be better informed than I to comment on this specifically.

On 4/28/07, Mike Dransfield <mike at blueroot.co.uk> wrote:
> Robert Carr wrote:
> > On 4/28/07, Mike Dransfield <mike at blueroot.co.uk> wrote:
> >
> >> Robert Carr wrote:
> >>
> >>> It seems like you disagree with how we want to do settings. You've
> >>> said you disagree with the concept of making a specific distribution
> >>> around Compiz in the manner we plan to do it. You've also mentioned
> >>> disagreeing with how we want to do decorators, etc. Furthermore you've
> >>> insulted most of us personally and called us various things from
> >>> dishonest to dimwits.
> >>>
> >>>
> >> I do not disagree, I just never get answers to simple questions
> >> like why are you duplicating effort?
> >>
> >> libbs is clearly duplicating effort.  I do not think anyone can
> >> disagree on that.
> >>
> >>
> >
> > It might be duplicating effort (in that is does a very similar thing),
> > but those of us think it's accomplishing the task in a better fashion.
> >
>
> Isn't this the same attitude that we are trying to stop?
>
> Why not discuss together for a solution where everyone is
> happy?
>
> > It has all sorts of nice features from providing a coherent API for
> > different things to access settings regardless of the backend, to
> > providing a way to import profiles from a least common denominator
> > backend in to the users backend, to offline settings reading.
> >
>
> So why not use the existing compiz backend plugins to do
> the reading and writing?
>
> To me this would make an awful lot more sense because it
> would stop most of the duplication, then libbs could become
> more of an integrated part.  People could use compiz with or
> without libbs and bugs will be much easier to track down.
>
> The benefit for you is that you do not have to maintain extra
> code which will just slow you down.
>
> > Furthermore it removes the settings backends from Compiz plugins (Do
> > we really want more plugins than we have to have?), and provides a
> > very very simple interface for writing settings backends. In my
> > opinion it's just a different way of accomplishing a similar task.
> >
>
> Which is duplication of effort isn't it?
>
> The whole point of compiz is that the features are provided
> by plugins.  The only work required would be to create a kconf
> plugin (although this is not vital) and then create a library
> which can read settings through an existing compiz plugin.
>
> This does have its benefits, the main ones being stability and
> ease of code maintainence.
>
> >
> >> BCOP is duplication of effort, maybe opinion is split on that
> >> one but time will tell.
> >>
> >>
> >
> > In my opinion the biggest advantage here is that it lets you change
> > the option interface without changing every single plugin.
> >
> >> I have never mentioned decorators at all because I have little
> >> interest in them and I do not know much about them.  I know
> >> RYX has done a lot of research into how to make a better
> >> decorator and I was simply agreeing that we should look at
> >> making the best rather than quickly rewriting emerald.
> >>
> >> I have never called you dishonest, the only people who I
> >> consider dishonest are the ones who spread lies like the
> >> classics surrounding gconf.  I have personally duplicated
> >> someone elses effort when my time could have been much
> >> better spent so I think I have a reason to be upset.
> >>
> >> I have never used the word dimwit (except then ;)) so I am
> >> not sure why you would say that.
> >>
> >>
> >>> However it seems like we agree on a lot of the things STRICTLY related
> >>> to Compiz (as in not unique to CompComm), so I don't see why rather
> >>> than just work with us there, you also insist on coming here and
> >>> arguing about everything we do.
> >>>
> >>>
> >> Right... Ill just leave you all to decide on what forum to use
> >> and then you will be away :D
> >>
> >> I am trying to impose some stability and direction but it seems
> >> like creating a distribution of compiz under another name is
> >> much more important to you.  What other software is redistributed
> >> under another name and package like this?  Do not mention the
> >> mozilla debian thing, you know thats a totally different issue.
> >>
> >>
> >>
> >
> > David seems to feel the same way about the name. He hopes (as do most
> > of us), that people will want to create several distributions around
> > Compiz, use the core for their own window manager, etc. So one reason
> > for a new name is to differentiate the distribution, including things
> > like desktop managers, and software packages.
> >
> > Another point is that the distribution compromises a LOT more than
> > just Compiz. A month or so ago Compiz trunk was 54k lines of code,
> > Beryl trunk (not counting beryl-mesa or beryl-settings-bindings
> > autogenerated code) was close to 200k. Granted, a lot of it was
> > plugins, but, this becomes an even more important distinction as the
> > plan is to move a lot of plugins out of f-d.o Compiz.
> >
> > So. We could just distribute a package of software (not just a tarball
> > of source) under the name "Compiz-extras", but eventually this would
> > probably grow even bigger than Beryl, and Compiz would become smaller,
> > so when you have a 200k LOC distribution with artwork, etc, around a
> > 20-40k LOC core+some plugins the infrastructure, becomes so large that
> > it makes sense to organize this "package of software" as it's own
> > project, and at this point it makes sense to have a name to separate
> > it from Compiz, both for the users (to separate it from any other
> > package of plugins/software distributed around Compiz), and to prevent
> > it from being viewed as a 'part' of Compiz.
> >
> > Similar to how a user can install X.org and then choose to install KDE
> > on top of it, we want a user to be able to install compiz-core and
> > then install CompComm on top of it and have everything he needs to
> > have a great accelerated desktop. Our goals and code will be distinct
> > from Compiz, so to me it almost seems rude to distribute it under that
> > name.
> >
> > Regards,
> > Robert
> >
> >
> >>> On 4/28/07, Mike Dransfield <mike at blueroot.co.uk> wrote:
> >>>
> >>>
> >>>> Robert Carr wrote:
> >>>>
> >>>>
> >>>>> Because frankly, you disagree with more or less everything we are
> >>>>> doing, and have made that imminently clear. Furthermore you have made
> >>>>> it equally care that you care nothing about what is going on here and
> >>>>> you will "continue to develop for Compiz". So I don't understand why
> >>>>> you are even on this mailing list. Any discussion relevant to your
> >>>>> interests will occur on the Compiz mailing list. Not this one, as this
> >>>>> is for things specific to the CompComm set of plugins and packages
> >>>>> around Compiz. So, you can go back to maintaining your collection of
> >>>>> Beryl plugins, and we can go back to working on what we are working on
> >>>>> now. We've heard your criticism, and we've disagreed with it, so if
> >>>>> all you have to do is repeat the same few talking points over and
> >>>>> over, we're tired of it, and want you to leave us alone.
> >>>>>
> >>>>>
> >>>>>
> >>>> As far as I know the only things I disagree with are
> >>>> dropping the forums and dreaming up a new name for
> >>>> everything.
> >>>>
> >>>> What else do I disagree with again?
> >>>>
> >>>>
> >>>>
> >>>>> Regards,
> >>>>> Robert
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I think I have contributed 10 times as much as you have to
> >>>>>> these shared goals.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> CompComm mailing list
> >>>>>>> CompComm at Rock3d.org
> >>>>>>> http://www.ubaight.com/mailman/listinfo/compcomm
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> CompComm mailing list
> >>>>>> CompComm at Rock3d.org
> >>>>>> http://www.ubaight.com/mailman/listinfo/compcomm
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> CompComm mailing list
> >>>>> CompComm at Rock3d.org
> >>>>> http://www.ubaight.com/mailman/listinfo/compcomm
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> CompComm mailing list
> >>>> CompComm at Rock3d.org
> >>>> http://www.ubaight.com/mailman/listinfo/compcomm
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> CompComm mailing list
> >>> CompComm at Rock3d.org
> >>> http://www.ubaight.com/mailman/listinfo/compcomm
> >>>
> >>>
> >> _______________________________________________
> >> CompComm mailing list
> >> CompComm at Rock3d.org
> >> http://www.ubaight.com/mailman/listinfo/compcomm
> >>
> >>
> > _______________________________________________
> > CompComm mailing list
> > CompComm at Rock3d.org
> > http://www.ubaight.com/mailman/listinfo/compcomm
> >
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>