3:27 p.m.
What do you think about to replace Compiz with Beryl, and merge "Desktop
Effects" with "Beryl Manager" in FC7?
My vote: +1
Otto Rey
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
4:27 p.m.
Otto Rey wrote:
What do you think about to replace Compiz with Beryl, and merge
"Desktop
Effects" with "Beryl Manager" in FC7?
My vote: +1
See
http://www.redhat.com/archives/fedora-maintainers/2006-November/msg00006.....
This isnt something we do by voting.
Rahul
6:01 p.m.
On 1/4/07, Rahul Sundaram wrote:
See
http://www.redhat.com/archives/fedora-maintainers/2006-November/msg00006.....
This isnt something we do by voting.
But at least the maintainer of beryl, reads and listens to its
users/bug report, whereas that of compiz, he never replied to bug
reports on bugzilla.
Chitlesh
--
http://clunixchit.blogspot.com
4:34 p.m.
On 04-Jan-2007 21:27.06 (GMT), Otto Rey wrote:
What do you think about to replace Compiz with Beryl, and merge
"Desktop
Effects" with "Beryl Manager" in FC7?
Out of the box, Fedora is simple to install and easy enough to use (even
*with* compiz) that a newcomer should find it mostly simple enough to use.
beryl's settings panel is a UI road traffic accident in the making, and may
well not be simple enough to make sense to a newcomer by the time FC7 is
readied.
I'd have to disagree that it's ready for general consumption just yet. Not
to mention the fact that some GLX/AIGLX implementations aren't mature enough
yet to run it stably and without issues like the screen turning white.
--
rob andrews :: pgp 0x01e00563 :: rob(a)choralone.org
4:50 p.m.
On Thu, 2007-01-04 at 13:27 -0800, Otto Rey wrote:
What do you think about to replace Compiz with Beryl, and merge
"Desktop Effects" with "Beryl Manager" in FC7?
My vote: +1
When beryl learns what a sensible UI looks like, we'll talk. The
current incarnation is a horror Hieronymus Bosch would be proud of.
- ajax
5:54 p.m.
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
Otto Rey (otto_rey(a)yahoo.com.ar) said:
> What do you think about to replace Compiz with Beryl, and merge "Desktop
Effects" with "Beryl Manager" in FC7?
Dear god no. Beryl is COMPLETELY INSANE.
How about JUST sugarUI?
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
6:29 p.m.
On Thu, 2007-01-04 at 16:54 -0700, Stephen John Smoogen wrote:
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
> Otto Rey (otto_rey(a)yahoo.com.ar) said:
> > What do you think about to replace Compiz with Beryl, and merge "Desktop
Effects" with "Beryl Manager" in FC7?
>
> Dear god no. Beryl is COMPLETELY INSANE.
>
How about JUST sugarUI?
If Rahul hadn't already posted the note about voting, I'd +1 this just
for the audacity of the idea :-)
-Toshio "Who wonders if it's feasible to package SugarUI for
Extras^WFedora"
10:44 a.m.
On Thu, 4 Jan 2007, Bill Nottingham wrote:
Otto Rey (otto_rey(a)yahoo.com.ar) said:
> What do you think about to replace Compiz with Beryl, and merge "Desktop
Effects" with "Beryl Manager" in FC7?
Dear god no. Beryl is COMPLETELY INSANE.
Why do you say that? In my experience, Beryl has been more stable and
easier to configure than Compiz. I have not looked at the code, however.
--
"Invoking the supernatural can explain anything, and hence explains nothing."
- University of Utah bioengineering professor Gregory Clark
1 p.m.
alan (alan(a)clueserver.org) said:
>Dear god no. Beryl is COMPLETELY INSANE.
Why do you say that? In my experience, Beryl has been more stable and
easier to configure than Compiz. I have not looked at the code, however.
beryl-settings.
[ ] slowness fix
Toggle this option if beryl is slow or choppy. On some cards, enabling
it makes beryl smoother, and on others disabling makes beryl smoother.
The applet.
Has an option to 'force nvidia, aiglx, or xgl'.
That was after playing for less than a minute.
So... maybe if all the UI bits were taken out and shot. :)
Bill
1:10 p.m.
On Fri, 2007-01-05 at 14:00 -0500, Bill Nottingham wrote:
alan (alan(a)clueserver.org) said:
> >Dear god no. Beryl is COMPLETELY INSANE.
>
> Why do you say that? In my experience, Beryl has been more stable and
> easier to configure than Compiz. I have not looked at the code, however.
beryl-settings.
[ ] slowness fix
Toggle this option if beryl is slow or choppy. On some cards, enabling
it makes beryl smoother, and on others disabling makes beryl smoother.
Haha, that's just plain laziness. They need to figure out what the
problem is, and fix it, or else figure out how to auto-detect which
setting works for which cards. And lazy programmers are not what we
need. The last thing you ask users to do is start toggling various
random settings in the hope that it makes a problem go away, without a
clear idea of _why_ the setting makes a difference.
Go beryl.
Dan
The applet.
Has an option to 'force nvidia, aiglx, or xgl'.
That was after playing for less than a minute.
So... maybe if all the UI bits were taken out and shot. :)
Bill
1:41 p.m.
On Fri, 2007-01-05 at 14:10 -0500, Dan Williams wrote:
On Fri, 2007-01-05 at 14:00 -0500, Bill Nottingham wrote:
> alan (alan(a)clueserver.org) said:
> > >Dear god no. Beryl is COMPLETELY INSANE.
> >
> > Why do you say that? In my experience, Beryl has been more stable and
> > easier to configure than Compiz. I have not looked at the code, however.
>
> beryl-settings.
>
> [ ] slowness fix
>
> Toggle this option if beryl is slow or choppy. On some cards, enabling
> it makes beryl smoother, and on others disabling makes beryl smoother.
Haha, that's just plain laziness. They need to figure out what the
problem is, and fix it, or else figure out how to auto-detect which
setting works for which cards. And lazy programmers are not what we
need. The last thing you ask users to do is start toggling various
random settings in the hope that it makes a problem go away, without a
clear idea of _why_ the setting makes a difference.
Go beryl.
One of the major problems I've seen with people writing GL applications
for Linux is that they expect that the drivers are not fixable, and
therefore they just hack around things. The people writing GL apps are,
in fact, the people who can best tell us where the bugs are, and what
paths need to go fast. And, in fact, Mesa is not hard (it's an absolute
joy to work with compared to some closed GL implementations), and
getting these things fixed in the DRI drivers is achievable by mere
mortals; but because they expect that the driver is a black box, it just
never happens that way.
This is what closed source does to people!
Given the choice between the kind of project with a Magic / More Magic
switch, and the kind of project that submits fixes to the components it
depends on, I'm going to go with the latter, every time.
- ajax
2:16 p.m.
On Fri, 2007-01-05 at 14:41 -0500, Adam Jackson wrote:
On Fri, 2007-01-05 at 14:10 -0500, Dan Williams wrote:
> On Fri, 2007-01-05 at 14:00 -0500, Bill Nottingham wrote:
> > alan (alan(a)clueserver.org) said:
> > > >Dear god no. Beryl is COMPLETELY INSANE.
> > >
> > > Why do you say that? In my experience, Beryl has been more stable and
> > > easier to configure than Compiz. I have not looked at the code, however.
> >
> > beryl-settings.
> >
> > [ ] slowness fix
> >
> > Toggle this option if beryl is slow or choppy. On some cards, enabling
> > it makes beryl smoother, and on others disabling makes beryl smoother.
>
> Haha, that's just plain laziness. They need to figure out what the
> problem is, and fix it, or else figure out how to auto-detect which
> setting works for which cards. And lazy programmers are not what we
> need. The last thing you ask users to do is start toggling various
> random settings in the hope that it makes a problem go away, without a
> clear idea of _why_ the setting makes a difference.
>
> Go beryl.
One of the major problems I've seen with people writing GL applications
for Linux is that they expect that the drivers are not fixable, and
therefore they just hack around things. The people writing GL apps are,
in fact, the people who can best tell us where the bugs are, and what
paths need to go fast. And, in fact, Mesa is not hard (it's an absolute
joy to work with compared to some closed GL implementations), and
getting these things fixed in the DRI drivers is achievable by mere
mortals; but because they expect that the driver is a black box, it just
never happens that way.
I got permanently scared off from hacking on the internals
of X (and
thus GL) after an afternoon of pain spent trying to deal with the
monolithic build.
Thanks to all the effort to modularize X, it's now _much_ more amenable
to people stepping in and fixing individual drivers themselves. But I
think the horror that was the old monolithic X build has scared away
many potential contributors.
This is what closed source does to people!
Given the choice between the kind of project with a Magic / More Magic
switch, and the kind of project that submits fixes to the components it
depends on, I'm going to go with the latter, every time.
6:36 p.m.
Compiz is the upstream original, Beryl is a fork.
Compiz uses gconf which is pretty standard and works well with gnome
obviously, Beryl uses flat file.
Beryl has (had?) some additional plugins, but plugins are being written
for compiz all the time as well, look at compiz-extras.
Beryl has a theme manager, compiz uses cairo, metacity, or KDE themes.
They look the same to me but Compiz just seems to be the better
integrated of the two.
http://en.wikipedia.org/wiki/Beryl_(window_manager)
http://en.wikipedia.org/wiki/Compiz
On Thu, 2007-01-04 at 13:27 -0800, Otto Rey wrote:
What do you think about to replace Compiz with Beryl, and merge
"Desktop Effects" with "Beryl Manager" in FC7?
My vote: +1
Otto Rey
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
10:20 p.m.
On Fri, 2007-01-05 at 09:36 +0900, Naoki wrote:
Compiz is the upstream original, Beryl is a fork.
Compiz uses gconf which is pretty standard and works well with gnome
obviously, Beryl uses flat file.
Beryl has (had?) some additional plugins, but plugins are being written
for compiz all the time as well, look at compiz-extras.
Beryl has a theme manager, compiz uses cairo, metacity, or KDE themes.
They look the same to me but Compiz just seems to be the better
integrated of the two.
And as of the last version, compiz had a horrid configuration (read
almost none) for the different plugins, etc.
That needs to be fixed. I like the GREAT configurability of Beryl.
Trever
--
"Magazines all too frequently lead to books and should be regarded by
the prudent as the heavy petting of literature." -- Fran Lebowitz
3:05 a.m.
On Thu, 2007-01-04 at 21:20 -0700, Trever L. Adams wrote:
And as of the last version, compiz had a horrid configuration (read
almost none) for the different plugins, etc.
Nearly if not all of it is through GConf. While no graphical preferences
capplet or similar exists for it yet, the keys are listed in detail in
gconf-editor and modifying them gets you the results you need/want.
That needs to be fixed. I like the GREAT configurability of Beryl.
That configurability comes at the cost of a disastrous UI and many cases
of Not-Invented-Here syndrome (using flat files for storage instead of
GConf, using its own themes instead of those of Metacity/Cairo/GTK, et.
al). That, and the fact that the people of Beryl is purportedly much
less strict about the quality and consistency of code accepted.
I've got three words for that: No thank you.
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com/blog/
3:24 a.m.
Peter Gordon wrote:
On Thu, 2007-01-04 at 21:20 -0700, Trever L. Adams wrote:
> And as of the last version, compiz had a horrid configuration (read
> almost none) for the different plugins, etc.
>
Nearly if not all of it is through GConf. While no graphical preferences
capplet or similar exists for it yet, the keys are listed in detail in
gconf-editor and modifying them gets you the results you need/want.
there is a configuration tool for compiz that comunicate with compiz
using dbus
http://www.go-compiz.org/index.php?title=Compiz-Settings
I would like to see this in extras (but requires compiz > 0.3.3) so only
devel for now
> That needs to be fixed. I like the GREAT configurability of
Beryl.
>
That configurability comes at the cost of a disastrous UI and many cases
of Not-Invented-Here syndrome (using flat files for storage instead of
GConf, using its own themes instead of those of Metacity/Cairo/GTK, et.
al). That, and the fact that the people of Beryl is purportedly much
less strict about the quality and consistency of code accepted.
I've got three words for that: No thank you.
+1
for me beryl is nothing but a hack (much less stable than compiz)
3:37 p.m.
On 1/6/07, dragoran <drago01(a)gmail.com> wrote:
Peter Gordon wrote:
there is a configuration tool for compiz that comunicate with compiz
using dbus
http://www.go-compiz.org/index.php?title=Compiz-Settings
I would like to see this in extras (but requires compiz > 0.3.3) so only
devel for now
Another one: http://gandalfn.wordpress.com/gnome-compiz-manager/
My package awaiting review: http://bugzilla.redhat.com/216734
11:02 a.m.
On Fri, 5 Jan 2007, Peter Gordon wrote:
On Thu, 2007-01-04 at 21:20 -0700, Trever L. Adams wrote:
> And as of the last version, compiz had a horrid configuration (read
> almost none) for the different plugins, etc.
Nearly if not all of it is through GConf. While no graphical preferences
capplet or similar exists for it yet, the keys are listed in detail in
gconf-editor and modifying them gets you the results you need/want.
Saying it is in gconf is like saying to a Windows user that "You can just
make changes in the registry to configure it". It is a non-obvious
configuration option.
> That needs to be fixed. I like the GREAT configurability of
Beryl.
That configurability comes at the cost of a disastrous UI and many cases
of Not-Invented-Here syndrome (using flat files for storage instead of
GConf, using its own themes instead of those of Metacity/Cairo/GTK, et.
al). That, and the fact that the people of Beryl is purportedly much
less strict about the quality and consistency of code accepted.
I am not certain why gconf is a "better" solution. It makes moving users
from one version to another difficult. (More than once, I have had all
the configuration data tied up in the gconf blob. Not easy to say "pull
all the configuation for app x".) Gconf is just repeating the mistakes of
the Windows registry without the extra obfuscation of uid keys.
Compiz themes are different from Metacity themes. They just added to
them.
As for the code quality, I have not investigated that (yet).
I do know that I have been able to get Beryl to work consistantly. With
Compiz, I am lucky to get the window decorations to come up most of the
time.
I've got three words for that: No thank you.
To each his own. I would prefer to see both. But looking at both
projects, the interesting and fun stuff all seems to be going on in Beryl,
not in Compiz.
--
"Invoking the supernatural can explain anything, and hence explains nothing."
- University of Utah bioengineering professor Gregory Clark
11:11 a.m.
alan wrote:
To each his own. I would prefer to see both. But looking at both
projects, the interesting and fun stuff all seems to be going on in
Beryl, not in Compiz.
We *already* have both. Beryl is in Fedora Extras currently. With the
merge in place, the only argument is what should be the default and here
is where code quality does matter.
Rahul
11:20 a.m.
On 1/5/07, Rahul Sundaram wrote:
We *already* have both. Beryl is in Fedora Extras currently. With
the
merge in place, the only argument is what should be the default and here
is where code quality does matter.
And fedora packager reponse quality as well !
--
http://clunixchit.blogspot.com
11:28 a.m.
Chitlesh GOORAH wrote:
On 1/5/07, Rahul Sundaram wrote:
> We *already* have both. Beryl is in Fedora Extras currently. With the
> merge in place, the only argument is what should be the default and here
> is where code quality does matter.
And fedora packager reponse quality as well !
We cant change defaults just because the package maintainers within
Fedora dont respond. The solution to that is to post to this list with
bug reports to check on progress if there is none for a unreasonable
amount of time. This is one of the reasons why I have been advocating
weekly irc development meetings. Raise the issue there and solving it
should make it more transparent.
Rahul.
11:40 a.m.
On Fri, 2007-01-05 at 22:58 +0530, Rahul Sundaram wrote:
Chitlesh GOORAH wrote:
> On 1/5/07, Rahul Sundaram wrote:
>
>> We *already* have both. Beryl is in Fedora Extras currently. With the
>> merge in place, the only argument is what should be the default and here
>> is where code quality does matter.
>
> And fedora packager reponse quality as well !
We cant change defaults just because the package maintainers within
Fedora dont respond. The solution to that is to post to this list with
bug reports to check on progress if there is none for a unreasonable
amount of time. This is one of the reasons why I have been advocating
weekly irc development meetings. Raise the issue there and solving it
should make it more transparent.
Careful. There's lots of bugs that could pop up like that. Without
some kind of "importance" system, you'll get lots of noise. For
example, I have a vim bug opened long ago that has just sat there. Is
it critical? No. Is it damn annoying? Yes.
"Unreasonable amount of time" is subjective.
josh
11:40 a.m.
Josh Boyer wrote:
Careful. There's lots of bugs that could pop up like that.
Without
some kind of "importance" system, you'll get lots of noise. For
example, I have a vim bug opened long ago that has just sat there. Is
it critical? No. Is it damn annoying? Yes.
"Unreasonable amount of time" is subjective.
Yes. I wasnt trying to define policy but one clearly documenting what
someone can do if a "critical" bug report gets ignored for a
"unreasonable" amount of time for good defined values of critical and
unreasonable would be useful to have.
Rahul
12:40 p.m.
On Fri, 5 Jan 2007, Josh Boyer wrote:
On Fri, 2007-01-05 at 22:58 +0530, Rahul Sundaram wrote:
> Chitlesh GOORAH wrote:
>> On 1/5/07, Rahul Sundaram wrote:
>>
>>> We *already* have both. Beryl is in Fedora Extras currently. With the
>>> merge in place, the only argument is what should be the default and here
>>> is where code quality does matter.
>>
>> And fedora packager reponse quality as well !
>
> We cant change defaults just because the package maintainers within
> Fedora dont respond. The solution to that is to post to this list with
> bug reports to check on progress if there is none for a unreasonable
> amount of time. This is one of the reasons why I have been advocating
> weekly irc development meetings. Raise the issue there and solving it
> should make it more transparent.
Careful. There's lots of bugs that could pop up like that. Without
some kind of "importance" system, you'll get lots of noise. For
example, I have a vim bug opened long ago that has just sat there. Is
it critical? No. Is it damn annoying? Yes.
"Unreasonable amount of time" is subjective.
I have had bugs sit in bugzilla for *years* without any attention. Some
bugs seem to get orphaned or assigned to dead people or something and no
follow-up is ever performed.
Maybe we need a report that shows the open bugs that have been sitting
without update for more than 30/60/90 days.
--
"Invoking the supernatural can explain anything, and hence explains nothing."
- University of Utah bioengineering professor Gregory Clark
12:52 p.m.
alan <alan(a)clueserver.org> wrote:
On Fri, 5 Jan 2007, Josh Boyer wrote:
[...]
> Careful. There's lots of bugs that could pop up like that.
Without
> some kind of "importance" system, you'll get lots of noise. For
> example, I have a vim bug opened long ago that has just sat there. Is
> it critical? No. Is it damn annoying? Yes.
>
> "Unreasonable amount of time" is subjective.
I have had bugs sit in bugzilla for *years* without any attention.
Some bugs seem to get orphaned or assigned to dead people or something
and no follow-up is ever performed.
So? Low-impact bugs, bugs in little used packages, ... just won't get the
attention a security problem in the kernel gets. I've got 22 open bugs
currently, some of them might sit there for many years and make no (or
almost no) difference to anybody (else).
Maybe we need a report that shows the open bugs that have been
sitting
without update for more than 30/60/90 days.
That is not enough, too much noise.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
1:02 p.m.
alan schrieb:
Maybe we need a report that shows the open bugs that have been sitting
without update for more than 30/60/90 days.
Extras has something like this already:
http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-6ebf09953da14...
CU
thl
1:12 p.m.
Thorsten Leemhuis wrote:
alan schrieb:
> Maybe we need a report that shows the open bugs that have been sitting
> without update for more than 30/60/90 days.
Extras has something like this already:
http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-6ebf09953da14...
Same for all of Fedora in fact. See
http://fedoraproject.org/wiki/FedoraTesting and the recent regular
meetings logs for additional details. Of course this work is not full
fledged yet and lots of details needs to be worked out.
Rahul
1:14 p.m.
On Fri, 5 Jan 2007, Thorsten Leemhuis wrote:
alan schrieb:
>
> Maybe we need a report that shows the open bugs that have been sitting
> without update for more than 30/60/90 days.
Extras has something like this already:
http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-6ebf09953da14...
Maybe it needs to be extended to core.
--
"Invoking the supernatural can explain anything, and hence explains nothing."
- University of Utah bioengineering professor Gregory Clark
1:19 p.m.
On Fri, 2007-01-05 at 11:14 -0800, alan wrote:
On Fri, 5 Jan 2007, Thorsten Leemhuis wrote:
> alan schrieb:
>>
>> Maybe we need a report that shows the open bugs that have been sitting
>> without update for more than 30/60/90 days.
>
> Extras has something like this already:
>
http://www.fedoraproject.org/wiki/Extras/PackageStatus#head-6ebf09953da14...
Maybe it needs to be extended to core.
There soon won't be core. Perhaps you meant it should be continued with
the merged repo.
josh
1:21 p.m.
On Fri, Jan 05, 2007 at 10:40:23AM -0800, alan wrote:
> Careful. There's lots of bugs that could pop up like that.
Without
> some kind of "importance" system, you'll get lots of noise. For
> example, I have a vim bug opened long ago that has just sat there. Is
> it critical? No. Is it damn annoying? Yes.
>
> "Unreasonable amount of time" is subjective.
I have had bugs sit in bugzilla for *years* without any attention. Some
bugs seem to get orphaned or assigned to dead people or something and no
follow-up is ever performed.
Maybe we need a report that shows the open bugs that have been sitting
without update for more than 30/60/90 days.
Some package owners are just way, way overloaded.
Recieving more email telling me I'm not looking at bugs isn't going to make
me look at more bugs any more than dealing with dozens of "Is anyone looking
at my bug?" bugmails.
Typically kernel bugs get dealt with by severity (and I don't mean
the severity pulldown in bugzilla -- having that user-visible is the
worst idea ever). Low hanging fruit gets fixed up pretty quick too
if I spot it, but there's so many bugs, there's just not enough
hours in the day to give them all equal attention.
Dave
--
http://www.codemonkey.org.uk
1:08 p.m.
On Fri, 2007-01-05 at 09:02 -0800, alan wrote:
On Fri, 5 Jan 2007, Peter Gordon wrote:
> On Thu, 2007-01-04 at 21:20 -0700, Trever L. Adams wrote:
>> And as of the last version, compiz had a horrid configuration (read
>> almost none) for the different plugins, etc.
Saying it is in gconf is like saying to a Windows user that "You can just
make changes in the registry to configure it". It is a non-obvious
configuration option.
It may be non-obvious, but it is there; and it allows you to change
virtually any aspect of Compiz's behaviour and/or appearance. This is
hardly "almost none" as you had stated.
I am not certain why gconf is a "better" solution.
From a corporate administrative stand point it has things like lock-down
and standard profile capabilities. From the standpoint of a user, it
also means that the preferences are applied immediately (yay for
inotify!) and for developers means that the information-manipulating
code is already written; i.e., one does not need to write code to parse,
read, and write file foo.cfg for various aspects and can instead simply
call the various GConf library functions to read or write data in
various configuration parameters. It also makes for having such code be
reusable by virtually any application that needs to store configuration
data. This is called encapsulation and abstraction; and it is nearly
always a very good segment of one's program design.
For example:
Beryl might (I haven't checked the code) do a configuration algorithm
such as:
1. Create a file descriptor and map it to the file
~/.config/beryl/user.cfg, opened in read-only text mode
2. Read the file contents and parse them into a configuration
storage structure
3. Poll the config file every so often for changes and re-read them
into that structure if there are any
4. Call wrapper functions on that structure to retrieve specific
data pieces as needed
Whereas with GConf it's theoretically quite a bit simpler:
1. Call gconf_client_add_dir and gconf_client_notify_add to
register a callback function for when the configuration is
changed.
2. Call gconf_client_get or other gconf functions as needed to
retrieve a specific key
3. That's it :)
Also, the GConf on-disk structure is XML, which makes it much better
suited for automated manipulation tools.
It makes moving users
from one version to another difficult. (More than once, I have had all
the configuration data tied up in the gconf blob. Not easy to say "pull
all the configuation for app x".)
Actually it is. The tree of gconf keys should contain a /apps/app-name/
subtree that you can pull with a simple cp or mv (the
~/.gconf/apps/app-name/ directory on-disk).
Compiz themes are different from Metacity themes. They just added to
them.
Right, but work is underway in Compiz to have both it and Metacity use
the same theming/rendering infrastructure, as I've read on various
Planets. Does Beryl have similar intention of desktop integration?
I do know that I have been able to get Beryl to work consistantly.
With
Compiz, I am lucky to get the window decorations to come up most of the
time.
The fact that something works and whether or not it is functioning and
designed properly are two entirely separate things. ;)
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com/blog/
2:09 a.m.
On Fri, 2007-01-05 at 09:02 -0800, alan wrote:
On Fri, 5 Jan 2007, Peter Gordon wrote:
> That configurability comes at the cost of a disastrous UI and many cases
> of Not-Invented-Here syndrome (using flat files for storage instead of
> GConf, using its own themes instead of those of Metacity/Cairo/GTK, et.
> al). That, and the fact that the people of Beryl is purportedly much
> less strict about the quality and consistency of code accepted.
I am not certain why gconf is a "better" solution. It makes moving users
from one version to another difficult. (More than once, I have had all
the configuration data tied up in the gconf blob. Not easy to say "pull
all the configuation for app x".) Gconf is just repeating the mistakes of
the Windows registry without the extra obfuscation of uid keys.
What do you mean by "pull all the configuration for app x"?
If you mean tell me what is the configuration, try either of the
following:
gconftool-2 -R '/apps/gnotime'
gconftool-2 --dump '/apps/gnotime'
If you mean, get rid of your customizations, try:
gconftool-2 --recursive-unset '/apps/gnotime'
-Toshio
5:58 p.m.
On Fri, 2007-01-05 at 01:05 -0800, Peter Gordon wrote:
That configurability comes at the cost of a disastrous UI and many
cases
of Not-Invented-Here syndrome (using flat files for storage instead of
GConf, using its own themes instead of those of Metacity/Cairo/GTK, et.
al). That, and the fact that the people of Beryl is purportedly much
less strict about the quality and consistency of code accepted.
I've got three words for that: No thank you.
Give me the ability to select the plugins, configure colors, speed,
effects for vairous things with a nice UI and I wiould take compiz.
However, telling people to use gconf-editor is not always the answer.
I agree, things should use standard tools. However, they target KDE as
well, so gconf is not necessarily part of the solution. However,
Metacity/Cairo/GTK do not, as of yet (as far as I have seen), have
transparent themes, etc. This is another problem.
So, yes, if you can get some of these user side problems (including
theme candy) fixed, then yes, compiz would be better.
My big complaint, probably my biggest, is the lack of an Expose like
functionality. I love it, it helps me work faster.
Trever
6:08 p.m.
On Fri, 2007-01-05 at 16:58 -0700, Trever L. Adams wrote:
My big complaint, probably my biggest, is the lack of an Expose like
functionality. I love it, it helps me work faster.
Compiz has one. It's even enabled by default, last I checked. Make
sure 'scale' is listed in
/apps/compiz/general/allscreens/options/active_plugins
and then check the settings in
/apps/compiz/plugins/scale
- ajax
7:03 p.m.
On Fri, 2007-01-05 at 19:08 -0500, Adam Jackson wrote:
On Fri, 2007-01-05 at 16:58 -0700, Trever L. Adams wrote:
> My big complaint, probably my biggest, is the lack of an Expose like
> functionality. I love it, it helps me work faster.
Compiz has one. It's even enabled by default, last I checked. Make
sure 'scale' is listed in
/apps/compiz/general/allscreens/options/active_plugins
and then check the settings in
/apps/compiz/plugins/scale
- ajax
Ajax, thank you. This is helpful, but it illustrates my point. You want
me to go into a configuration editor that is not as clear (though
probably less cluttered) than that of beryl. This is what I mean that
compiz needs a graphical one.
Trever
10:30 a.m.
On Fri, 2007-01-05 at 18:03 -0700, Trever L. Adams wrote:
On Fri, 2007-01-05 at 19:08 -0500, Adam Jackson wrote:
> On Fri, 2007-01-05 at 16:58 -0700, Trever L. Adams wrote:
>
> > My big complaint, probably my biggest, is the lack of an Expose like
> > functionality. I love it, it helps me work faster.
>
> Compiz has one. It's even enabled by default, last I checked. Make
> sure 'scale' is listed in
>
> /apps/compiz/general/allscreens/options/active_plugins
>
> and then check the settings in
>
> /apps/compiz/plugins/scale
>
> - ajax
Ajax, thank you. This is helpful, but it illustrates my point. You want
me to go into a configuration editor that is not as clear (though
probably less cluttered) than that of beryl. This is what I mean that
compiz needs a graphical one.
I was never arguing that point.
- ajax
6:48 p.m.
On Fri, 2007-01-05 at 16:58 -0700, Trever L. Adams wrote:
I agree, things should use standard tools. However, they target KDE
as
well, so gconf is not necessarily part of the solution. However,
Metacity/Cairo/GTK do not, as of yet (as far as I have seen), have
transparent themes, etc. This is another problem.
Can you outline in what way "transparent themes" would help our users ?
UIs are generally better if you can actually see them...
7:02 p.m.
On Fri, 2007-01-05 at 19:48 -0500, Matthias Clasen wrote:
On Fri, 2007-01-05 at 16:58 -0700, Trever L. Adams wrote:
> I agree, things should use standard tools. However, they target KDE as
> well, so gconf is not necessarily part of the solution. However,
> Metacity/Cairo/GTK do not, as of yet (as far as I have seen), have
> transparent themes, etc. This is another problem.
Can you outline in what way "transparent themes" would help our users ?
UIs are generally better if you can actually see them...
Maybe translucent would be the better word. I have a theme, that until
some recent problems with beryl (off currently) would allow me to see
things underneath decorations for none active windows. I liked this.
Beyond some simple helps, it was eye candy, yes, but useful.
Purely transparent, obviously that would be a problem.
Trever
11:28 p.m.
fre, 05 01 2007 kl. 16:58 -0700, skrev Trever L. Adams:
My big complaint, probably my biggest, is the lack of an Expose like
functionality. I love it, it helps me work faster.
The Scale plugin does this and it is both shipped and enabled by
default. Moving the cursor to assigned "hot spot" will enable it, by
default this is the top right corner (though endlessly configurable
through our friend GConf)
- David
12:03 a.m.
GConf editor is not a desktop user's configuration system. I'll
consider using Compiz when there is a graphic config system. Does
anyone know whether someone is developing a Compiz configuration
manager for KDE, or is Compiz considered to be solely targeted to the
Gnome environment?
Miles
On 1/6/07, David Nielsen <david(a)lovesunix.net> wrote:
fre, 05 01 2007 kl. 16:58 -0700, skrev Trever L. Adams:
> My big complaint, probably my biggest, is the lack of an Expose like
> functionality. I love it, it helps me work faster.
The Scale plugin does this and it is both shipped and enabled by
default. Moving the cursor to assigned "hot spot" will enable it, by
default this is the top right corner (though endlessly configurable
through our friend GConf)
- David
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
12:18 a.m.
lør, 06 01 2007 kl. 01:03 -0500, skrev Miles Lane:
GConf editor is not a desktop user's configuration system.
I'll
consider using Compiz when there is a graphic config system. Does
anyone know whether someone is developing a Compiz configuration
manager for KDE, or is Compiz considered to be solely targeted to the
Gnome environment?
a) Nothing GNOME specific about GConf
b) Desktop effects provides a nice simple interface for more complicated
needs there's the compiz configurator or indeed for those of us who like
that kind of thing there's direct interaction with GConf via CLI or the
gconf-editor.
c) Developers of other DEs can use DBus to configure Compiz so to allow
for the right amount of options in the right places. Poke your DE
developers till code falls out or write it yourself if such code does
not exist. You can't expect upstream to provide anything more than the
tools to write them and a proof of concept.
- David
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
2:07 a.m.
On Sat, 2007-01-06 at 01:03 -0500, Miles Lane wrote:
GConf editor is not a desktop user's configuration system.
I'll
consider using Compiz when there is a graphic config system. Does
anyone know whether someone is developing a Compiz configuration
manager for KDE, or is Compiz considered to be solely targeted to the
Gnome environment?
Luckily, GConf makes it extremely simple to write a configuration
editor. Any python programmer could whip you out a configuration editor
specific to compiz in a week or less.
The problem is that configuration editors need UI love just as much as
the main application. Have your wife/father/ten-year-old try to find a
few *specific* options in Beryl and tweak them and you'll see what I
mean. The interface exposes all the options but it doesn't organize it
sanely.
-Toshio
2:13 p.m.
Naoki wrote:
Compiz is the upstream original, Beryl is a fork.
Compiz uses gconf which is pretty standard and works well with gnome
obviously, Beryl uses flat file.
Beryl has (had?) some additional plugins, but plugins are being written
for compiz all the time as well, look at compiz-extras.
Beryl has a theme manager, compiz uses cairo, metacity, or KDE themes.
They look the same to me but Compiz just seems to be the better
integrated of the two.
Add:
Beryl supports dual head xinerama properly.
Compiz does not.
Compiz is preferred here otherwise, but no dual head is a show stopper.
Mark
8:51 p.m.
man, 08 01 2007 kl. 15:13 -0500, skrev Mark Heslep:
Naoki wrote:
> Compiz is the upstream original, Beryl is a fork.
>
> Compiz uses gconf which is pretty standard and works well with gnome
> obviously, Beryl uses flat file.
>
> Beryl has (had?) some additional plugins, but plugins are being written
> for compiz all the time as well, look at compiz-extras.
>
> Beryl has a theme manager, compiz uses cairo, metacity, or KDE themes.
>
> They look the same to me but Compiz just seems to be the better
> integrated of the two.
>
>
>
Add:
Beryl supports dual head xinerama properly.
Compiz does not.
Compiz is preferred here otherwise, but no dual head is a show stopper.
Mark
Beryl supports this via a nasty hack as I'm to understand. Dave Reveman
opposed including it in Compiz as he was working on a non-hack solution,
which is present in the development version of Compiz (currently
available in your Fedora Development repo and thus in F7). Ergo, a
complete non-issue unless you have bugzilla entries to show me wrong?
- David Nielsen
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
9:53 p.m.
> Add:
> Beryl supports dual head xinerama properly.
> Compiz does not.
>
> Compiz is preferred here otherwise, but no dual head is a show stopper.
>
> Mark
>
Beryl supports this via a nasty hack as I'm to understand. Dave Reveman
opposed including it in Compiz as he was working on a non-hack solution,
which is present in the development version of Compiz (currently
available in your Fedora Development repo and thus in F7). Ergo, a
complete non-issue unless you have bugzilla entries to show me wrong?
- David Nielsen
Checked Fedora Dev aka Compiz 0.3.4 and confirm dual head works for me
now, thank you.
-Mark
7:18 a.m.
On Thursday 04 January 2007 9:27 pm, Otto Rey wrote:
What do you think about to replace Compiz with Beryl, and merge
"Desktop
Effects" with "Beryl Manager" in FC7?
My vote: +1
Otto Rey
So far this thread appears to have focused on the configuration of beryl
versus compiz plus packaging. These are important of course but what about
performance ?
Just to add my experience of running both, I have found compiz much better. I
have an nvidia go 5640 with 128M. compiz runs perfectly smoothly, the effects
look great and don't slow things down. With beryl, the effects are more jerky
and no where near as smooth.
Reading around the mailing lists I also understand that beryl is not as well
implemented as compiz. It requires two pixmaps per client window whereas
compiz only needs one (someone please correct me here if I am wrong). So it
simply uses more video ram to do the same things.
So please, can we also bring performance into the discussion. From my
experiences beryl is not yet ready to replace compiz, but maybe others have
different experiences. I for one would like to see both beryl and compiz
being kept available, just to see how both projects pan out.
Chris
6347
days inactive
6360
days old
46 comments
25 participants
participants (25)
-
Adam Jackson -
Alan -
Bill Nottingham -
Chitlesh GOORAH -
Chris Jones -
Dan Williams -
Dave Jones -
David Malcolm -
David Nielsen -
drago01 -
Horst H. von Brand -
John Mahowald -
Josh Boyer -
Mark Heslep -
Matthias Clasen -
Miles Lane -
Naoki -
Otto Rey -
Peter Gordon -
Rahul Sundaram -
Rob Andrews -
Stephen John Smoogen -
Thorsten Leemhuis -
Toshio Kuratomi -
Trever L. Adams