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
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.htm.... This isnt something we do by voting.
Rahul
On 1/4/07, Rahul Sundaram wrote:
See http://www.redhat.com/archives/fedora-maintainers/2006-November/msg00006.htm.... 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
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.
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
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
Otto Rey (otto_rey@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?
On Thu, 2007-01-04 at 16:54 -0700, Stephen John Smoogen wrote:
On 1/4/07, Bill Nottingham notting@redhat.com wrote:
Otto Rey (otto_rey@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"
On Thu, 4 Jan 2007, Bill Nottingham wrote:
Otto Rey (otto_rey@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.
alan (alan@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
On Fri, 2007-01-05 at 14:00 -0500, Bill Nottingham wrote:
alan (alan@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
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@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
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@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.
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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
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 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)
On 1/6/07, dragoran drago01@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
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.
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
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 !
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.
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
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
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.
alan alan@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.
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-6ebf09953da14bdd...
CU thl
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-6ebf09953da14bdd...
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
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-6ebf09953da14bdd...
Maybe it needs to be extended to core.
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-6ebf09953da14bdd...
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
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
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. ;)
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
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
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
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
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
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...
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
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
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@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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
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
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
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
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
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