Submitted by Two more articles on Beryl. The first one is on drag and drop in Beryl: “What does Beryl add to the drag and drop picture? Well, for a start, if you’ve got a lot of windows open, it’s easier to find the target if you can see all the windows at once. Also, if you want to drop a file/text on an application on another desktop, you can do this much more easily. This is a cool little feature that allows you to drag and drop files between applications on the same desktop, or different desktops.” The second one is a performance tweak for Beryl.
…just like with expose
it doesn’t seem to work for me with expose. i tried dropping a video file on vlc while in expose mode.
You probably have to drag the item over the target window, wait two seconds to “activate” the window and then drop it. If it works only that way though, I think Apple should change it.
If you start to drag then go to expose and hold the cursor over the window for about 5 seconds it’ll flash and be selected.
Then when expose exists you can D&D. It’s a good behaviour, although I wish you could speed the process by alternate clicking.
This feature was added to compiz on November 28 and copied into beryl on November 29. See the original commit (http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=043…) and the beryl commit (http://bugs.beryl-project.org/changeset/1449). As you can see, the Beryl changelog mentions the real author, too bad that nobody reads changelogs. So the beryl fanboys can keep prattling that “beryl innovates and compiz lags behind.”
Edited 2007-02-27 23:30
“This feature was added to compiz on November 28 and copied into beryl on November 29. See the original commit (http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=043…..) and the beryl commit (http://bugs.beryl-project.org/changeset/1449). As you can see, the Beryl changelog mentions the real author, too bad that nobody reads changelogs. So the beryl fanboys can keep prattling that “beryl innovates and compiz lags behind.” ”
I don’t believe anyone said anything of the kind. So what if Compiz had it first?!?
Edited 2007-02-28 01:05
The thing is that David Reveman does most of the work with compiz while beryl just imports the changes and start hyping them “Look at all the amazing features we have!”, without acknowledging compiz mostly. The contributions made back to compiz has also been very few and the fact that Quinn choosed a different licensing makes it even more difficult. Beryl gets allt the attention and all contributors while David Reveman is basically alone with compiz. This is bad in the long run because it’s in compiz all the real development on the core technologies are happening, that beryl and other compositing window managers would be nothing without. Of course beryl is perfectly allowed to do this.
Edited 2007-02-28 08:47
This feature was added to compiz on November 28 and copied into beryl on November 29.
This is perfectly acceptable and even encouraged by the free software model. If Beryl was a simple copy of Compiz, then the two project would compete based on the resources of their respective user communities, and Beryl would probably get more users than Compiz. But Beryl also sports poorly-designed workarounds for various features that are still under development in Compiz, resulting in more functionality. So Beryl has both the biggest feature-set and the most active user community.
So it should attract a lot more users than Compiz, at least until the Compiz developers get so pissed off that they either stop making GPL releases or halt development altogether. Either way, the desktop effects effort will be badly damaged, since the Beryl development community has very little interest in doing any useful work on the core compositing functionality. They’re content to make snazzy plugins for the meager framework we have today.
What Beryl is doing has a legitimate purpose backed by real demand. They’re building demo-quality desktop effects, driving interest and confidence in the future of the free software desktop. But they’re going about it in the wrong way. In the incomparable words of The Dude: “No, you’re not wrong, Beryl, you’re just an ASSHOLE!”
I disagree. Beryl is not trying to “be an asshole”, they are trying to stimulate innovation on all sides. Without Beryl, Compiz would have less motivation to innovate. Beryl is upping the ante, much as–might I mention–XGL did for AIGLX when it was released.
Why do you assume that Compiz will just give up and fold, rather than improving and trying to compete? And why is it so bad that Beryl is providing work-arounds for non-implemented functionality? I’m sure that when the Compiz project implements said functionality, Beryl will incorporate it into its codebase as well.
(Btw I’m curious about what these workarounds for features in development are; perhaps you could fill me in on what you’re referring to.)
Why do you assume that Compiz will just give up and fold, rather than improving and trying to compete? And why is it so bad that Beryl is providing work-arounds for non-implemented functionality? I’m sure that when the Compiz project implements said functionality, Beryl will incorporate it into its codebase as well.
Now they changed the project description on their homepage again, giving more props to David Reveman than before… this is a step in the right direction, though it is not enough to compensate for the damage beryl can do on the long run. Sounds dramatic, yes? But why did quinnstorm change the license so code can only flow in one direction (compiz –> beryl, and not vice versa)? Why introduce incompatible plugin formats? Why make it hard (or illegal – see license change) for compiz to benefit from beryl, while beryl could not simply exist without compiz? Why not call them an ASSHOLE when you have no more reasonable answers to these questions
I begin with beryl, and still use beryl, because I can’t use compiz (no compiz-settings port for FreeBSD yet, and I hate gconf). I like beryl, and I can put up with its instability. I want it to succeed. But its success depends on compiz, and when beryl developers deliberately change things so only beryl can benefit from compiz and not vice versa, when it becomes more and more clear that the reason for forking was bogus, that the only reason for adopting the GPL is cement that fork in legalese, well, I’m dissapointed.
The two projects should help each other instead of “compete” with each other – because this is not real competition. Beryl simply uses compiz, imports new changes even in the late RC phase of their release cycle breaking things for a lots of people, while more ofthen than not, they take credit for all the bling (as I mentioned, I just noticed they changed the text on their about page, which is a step in a right direction). The problem is that beryl has become an egotrip to quinnstorm – s/he would not listen, doesn’t want to listen. He forked because David rejected his/her patches because they were not up to the quality standards of the compiz project. Now quinnstorm and his codevelopers had ample time (half a year now) to prove that the fork is justified, and they can develop beryl in new directions, and compete with compiz on merits. Instead, what happens right now as we speak is that beryl desperately imports latest changes from compiz into their tree, and guess what, quinsstorm relicenses beryl so it becomes incompatible with compiz/xorg’s MIT license, so while beryl can take take take (code, mindshare, users) it cannot give back anything to compiz – nor does it want to (at least not quinnstorm, s/he stated that s/he will NOT change the license back – that would foster just too much cooperation I guess).
Disappointing.
Edited 2007-02-28 09:35
While I agree with you in that the license change is wrong I do not think it malicious. I would attribute it to immaturity and idealism more than maliciousness.
Beryl takes the changes from Compiz because they are useful, not because they are desperate. Further the structural changes were not malicious, merely a difference in opinion. If they were as radical as you suggest it would not be so easy to port Compiz changes to Beryl. There are two basic things holding back cooperation: license and quality. License we have already covered, quality is something that would improve from seeing the adjustments needed to go upstream (except license interferes).
Well, my words might have been a bit harsh, and my choice of words not very accurate – yeah, you are right about “desperate”
I intended to describe how beryl developers completely lost control over the release process. I never saw a project where the beta (and more importantly, the RC) phase introduced so many new features and code, and broke so many things that people began reverting from RC2 to a beta release because that was more stable for them. I don’t see a clear direction, clear ideas of where they want to go – workarounds are dead ends, new _correct_ solutions are only developed by David and his team, while Kristian cites one of the reasons for the fork the quality of David’s code: http://dev.beryl-project.org/~kristian/beryl/7/the-future-of-beryl/
Ideally, beryl could define itself as a “development” platform for new ideas and plugins, with an explicit aim of providing temporary workarounds for the backend (the core) while also striving to cooperate with compiz in finding long term solutions. Licensing changes MUST go for this to work, but quinn is adamant that this is not going to happen. You are right that changes are not that radical yet, except that I consider the license change itself a radical measure preventing free flow of code between the two projects.
I laid emphasis on the legal aspect so far, a few words about the technical issues. Beryl project proclaimed their intention to further diverge multiple times (they did that with core – then backpedaled somewhat -, and they definitely still do it with the plugin formats, trying to make beryl bling exclusive to beryl). This is wrong, because there are actually no technical reasons to change (except maybe the settings format, but that’s really a non-issue). Even if there were, wouldn’t be more reasonable to try to overcome those technical issues instead of just going ahead and making changes that makes the job of compiz devs harder?
What really bothers me that the solution is so simple and straightforward. The existence of beryl as a separate project is perfectly fine under the terms described above: workarounds help developers create new ideas, help users try out these ideas and comment on them, etc. This is a very important aspect that compiz lacks. But on everything else, they should work together: keep the plugin system a separate standard, and strive for complete transparency. DE specific window decorators are another part of the code they could share (while beryl can still maintain its own emerald windeco and its themes). They seem to be stuck with a fork that is almost a fork but not quite. They invested lots of emotions in justifying the need for the fork, so they cannot backpedal now, even though it would make a lot of sense to redefine the projects goals. They are trying, I can see that in the new project description (or the old one? someone commented here that the same description was there months ago but they changed it, then they changed it back now) – but this goes nowhere as long as they are unwilling to lift the barriers – both legal and technical – that they have built between the two projects, to maintain the illusion of a fork.
Edited 2007-02-28 18:05
The performance tweak listed is already available under the nvidia troubleshooting page of the beryl wiki
http://wiki.beryl-project.org/wiki/Troubleshooting_nVidia
Although it may be possible that it effects XGL as well as nVidia’s aixgl. Cranking up the refresh artificially to 200 is a waste of cpu cycles. Note that that doesn’t change your actual monitor refresh but simple the refresh of the animation effects in beryl. Put the refresh to 60 or 70 or whatever your monitor refresh is at – if you set it higher any percieved performance increase should be if anything false perception.
Although it may be possible that it effects XGL as well as nVidia’s aixgl.
The term is AIGLX (Accelerated Indirect GLX), and you can use beryl/compiz with the nVidia drivers without having to use either XGL or AIGLX. The nVidia drivers support the necessary X extension (Composite) and the necessary OpenGL extension (GLX_EXT_texture_from pixmap), all with Direct Rendering.
Put the refresh to 60 or 70 or whatever your monitor refresh is at – if you set it higher any percieved performance increase should be if anything false perception.
Except that the beryl internal frame limiter is broken. In addition, the developers point out that some users report improved overall performance when setting the refresh rate to 200.
Besides, in the end, isn’t the user experience all about perception. Even if it’s false perception, it’s sill what that user perceives.
Adam
There is a definite improvement in performance when implementing the screen refresh tweak. If that’s just perception, so be it. All I have is perception, so a perceived change is enough for me.
The term is AIGLX and it is Xorg’s GLX extension not Nvidia’s. Novell releases XGL and Redhat releases AIGLX. XGL is basically an OpenGL X running on top of a standard X. AIGLX is an extension to standard Xorg. XGL is compatible with more Linux 3d drivers than AIGLX, in fact when AIGLX was first released it would not work with the then current Nvidia drivers.
The only times I’ve seen Beryl working on my machines were when using Kororaa or Sabayon preconfigured Live-CDs. Its been dead as a dodo in Debian and Frugalware. Thanx for that ATI.
Why blame ATI? Beryl works just fine with XGL on ATI cards using the fglrx driver, and works fine on radeon cards that support AIGLX (any of the r100 through the r400 generation cards).
Adam
I can’t get it to work, alas. I keep getting failures about the goddamn texture_from_pixmap extension. I am on Gentoo, but it worked a few months ago, and now it doesn’t.
Are you using the fglrx drivers from ATI? If so, that error probably means you’re not running XGL when you try to launch Beryl.
Unfortunately, I don’t know enough about Gentoo to give an educated guess as to why XGL isn’t running
Adam
Off topic
=========
This is not a gentoo forum. There is an extensive posts on there of how to get your card working under Beryl.
“goddamn texture_from_pixmap” the problem you are describing is the reason to choose a card with supported open source drivers, the propriatry drivers from AMD do not support this extension which is needed for *AIGLX*
seriously forum…irc, although I will point out until X-org 7.2 has been around a little time, and beryl 2.0 has been released I would probably hold off till then. When things are easier to get working under Gentoo.
You ought to send a mail to [email protected] – if you’re not subscriped to the mail-list you ought to hurry up. Just a good advice for a fellow gentoo’er.
BTW: Larry the transsexual cow rules
… but it worked a few months ago, and now it doesn’t.
[sarcasm]That’s because Beryl-project gave a new meaning to beta and RC stages. Usually beta (and especially RC) means no extensive changes to the codebase, no new features, just fixing the bugs and stabilizing the code. In beryl’s vocabulary RC and beta releases mean exactly the opposite: forget that the next release will be RC1 after Beta-2, and import latest and greatest code from compiz, then see how things break for half of ATI users, and then release RC2 that breaks things for more people (but look at how *shiny* is our new ring switcher plugin).[/sarcasm]
Remember that the drag and drop infrastructure was actually added by David R in compiz. This was subsequently ported from compiz to Beryl with little or no acknowledgement [1]
Proper input redirection support is also being worked on by David R and will appear in Compiz soon. No doubt the feature will also make it to Beryl at which point OSAlert will run a story on it.
[1] http://blog.beryl-project.org/?p=5#comments
Edited 2007-02-28 00:24
There is acknowledgement, but not in the blog. But check copyright notices and cvs. That’s where acknowledgement has to be at the very minimum.
It may be unethical not to put it on the website, but it’s not necessary to do so, unless the license explicit demands this. And the license doesn’t.
So what?
Did anyone say it wasn’t legal what was done here? No!
It was all about that credit wasn’t given in a way the bigger audience would notice it, AND about the fact that the bigger audience, or OSAlert, is very Beryl-centric.
And I think, this sucks. Perhaps at least the bigger audience or OSAlert could perhaps change their perspective a bit.
Actually, you are wrong. There is credit on the website. And credit in sources. All is well.
Anyway – who cares about Beryl? I for sure don’t.
What is the problem here? Compiz is under the GPL, and Beryl has incorporated some of its code into it’s plugin. There is nothing in the GPL that requires attribution other than through inclusion of an “appropriate copyright notice”, in fact the FSF people get upset when people start requiring attribution greater than that. Notwithstanding that point, one of the very points of using the GPL license is to allow others to use, develop and enhance code for the benefit of all. Beryl is simply exercising the very freedoms that the developers of Compiz gave them by distributing compiz it under the GPL. They should be applauded for pushing development of these technologies, as should the original compiz authors.
Squabbling over attribution in the context of GPL licensed code seems silly to me.
As for the timing of the article, all the dnd stuff has only started working properly for me in the last week or so. Previously, hovering over a window did not deactivate scale, and once that started working, it only handled objects selected from gtk apps, and not kde apps. Now all of that seems to work.
Who said anything about a problem? nzjrs (and ghepeu) simply provided additional context to the news item, which I for one appreciate.
The fact that the GPL does not enforce any special attribution doesn’t make it less but rather more important that we avoid misunderstandings about original authorship in my opinion.
@dumbkiwi: You appear to be mistaken.
Firstly, compiz is under multiple licenses, due to its nature (plugin based) and place in the stack (close to the X server, code to flow to/from compiz into X).
Beryl is GPL. This means that fixes in Beryl cannot easily be ported back to compiz. Justify that?
And I wasnt
Squabbling over attribution I was pointing out another example of the nature of the beryl project (all take and no give, be it code, attribution, or whatever).
Edited 2007-02-28 02:07
I was pointing out another example of the nature of the beryl project (all take and no give, be it code, attribution, or whatever).
Take and no give? What’s the GPL about then? They are giving Beryl code according to the GPL terms. Get a clue. Besides, author attribution is in the source code, where it belongs and where all other coders usually find author names. Everything else is plain vanity.
Compiz is licensed under MIT License, Beryl under GPL, so, code can flow from compiz to beryl, not the opposite. By the way -> compiz-core is the way to go, beryl-core is only a piece of ugly and dirty hacks to make everything do blings and dings. (some beryl plugins are cool… i’m talking about core here
)
Edit: By the way, show me where at the beryl project website some credit is give to DavidR or Compiz… I couldn’t find..
Edited 2007-02-28 02:31
So because Compiz chose a different license, this is Beryl’s fault how? They release their source as required by the GPL. If the Compiz people have chosen a license that prevents its inclusion, that cannot be laid at the doorstep of Beryl. It is difficult in this circumstance to say that Beryl is not giving anything back.
Not that I really care, other than not understanding the animosity you display toward the Beryl project.
Don’t… compiz-core is licensed as MIT License because the whole X.org uses this license, this way, all code from compiz can be added without a problem into X. Compiz was the original thing, Beryl is the fork, so, Beryl choosed to be incompatible…
I was just trying to make everything clear, I don’t speak english very well, so, sorry if I sound angry or anything.
BTW the beryl developers could dual license beryl (MIT/GPL) so everyone would be happy… but quinnstorm himself already told that this will not happen.
Edit: Just to make it clear: Beryl is a fork from Compiz. It is well know that beryl-core didn’t advanced from what originally was compiz-core, there are some beryl developer’s blog posts about it
Edited 2007-02-28 03:36
Quinnstorm is a woman
But see your point.
Quinn Storm is transgender and prefers the feminine “she”. Given the beard however it is a confusing topic to me.
On an unrelated note I tend to think it impolite and fork Compiz as GPL since it does present problems feeding back upstream. It seems at least some of the developers are willing to help send their patched upstream though.
Quinnstorm is a woman
But see your point.
Well, it’s not that simple (see this interview with “her”):
http://www.lulu.tv/?p=4346
Quinn Storm is a man.
Edit: By the way, show me where at the beryl project website some credit is give to DavidR or Compiz… I couldn’t find..
How about the homepage? http://beryl-project.org/
“Beryl is a fork of the Compiz project, started by David Reveman of Novell. We continue to port new changes from compiz, and consider them essentially our upstream. Beryl could not have existed were it not for the heavy lifting done both server side by David…”
There are also a couple comments in the blogs to that effect but I figured the homepage qualified.
Wow, this was added when the project launched (before the hd crash thing I think), but then was removed for a long time now, when I visited the page this morning I didn’t see it, maybe I was reading a cached page or something. Well, kudos to the beryl project to add this explanation again
Start to drag, hit your key to start Expose, move the file over the window you want to drop on, hit the expose key again your selected window will come to the front, drop.
This speeds up the process quite a bit.
the only disappointing thing really is that people fall over each other here. Some say that beryl has a wrong license; you can switch that around.
Some people say that not enough credit is given but the code clearly states it has.
Some people will argue about code quality — others don’t.
Even if beryl-core is a quick hack, there is no reason to believe that it will change; so is the “cleaner” compiz version (that may end up being a piece of code that doesn’t resemble anything.
Fact is that a few things are here: we seem to have two parties. One party likes compiz and defends all the stuff for compiz, and the other party does the other way around.
It’s all about choosing whatever is appropiate/stable/fancy enough for you, right?
Nobody stole code from nobody. It’s all legal. No need to speak up words to the “other camp”.
the fork and whether it is justified is not as simple as is portrayed by all parties involved. I think the fork is justified and a good thing, though Beryl have made a few mistakes along the road.
Let me start by saying I am a Beryl user. I tried to install Compiz and it failed, then Beryl and it worked. I am sure the problem was mine but to be honest do not want to be bothered. I like to try things in Linux but do not waste time fixing problem installs anymore. I use Linux as my OS not as my playground. If beryl starts proving unstable for me it will be off as fast as it went on, but so far it has been problem free for me.
Now onto why the fork was a good thing. DR is a disciplined coder and he understands X11 architecture better than the whole Beryl team combined. He also is slow and deliberate about what he releases and when. Beryl however are more experimental, they can and will try things that would not have ever been released in Compiz, either because the code as not up to DR’s standards or because it did not fit his vision.
Input enabled Zoom in Beryl is an example of this, Beryl is using something that is a bit of a hack to get around the lack of input redirection in X. DR on the other hand is working to patch X to achieve input redirection and do the feature in a more proper way. This is used as a criticism for Beryl in that the patch for X is more proper, however the fact is no one on the Beryl team has the expertise in X programing to write that patch properly. This is not a knock on the Beryl team, core level X programming is not something most people need to understand. So input enabled zoom in Beryl is a stopgap. The code itself is not bad, it is just not the proper way to do the functionality.
Now another change was the refactoring of configuration to remove dependence from dbus. This is a change that I happen to agree with though one that is very contentious. Dbus and gconf will almost definitely always be at the core of Compiz. Here we see a simple difference of opinion. Neither side is right or wrong, both have merit.
I have done a casual review of both projects but since I have no intention of getting involved just touched the surface. Compiz is written by a steadier, more experienced, hand in my opinion. The code does however show some weaknesses of being a one man project. There are sections of code that are well nigh unreadable, and others that while clean are not commented well if at all because DR is either not done with or considers obvious enough not to need comments. Beryl on the other hand is much less disciplined and in some places a little scary, but it gets the job done. Much of Beryl would not get accepted in the state it is in to Compiz, but the quantity and depth of the problem is somewhat exaggerated in my opinion. Kristian in particular shows quite a bit of promise.
So two different philosophies with two distinct methodologies and visions. Compiz is steady and deliberate, Beryl more loose and agile. I do not think the two projects can or should merge. Compiz development would be hurt by the style of coding in Beryl. On the other side Beryl would be stifled by the conservative approach of Compiz.
The two projects can and do benefit from each other though. Beryl in particular makes use of the core improvements in Compiz. I see no problem with this and would treat Beryl as a more experimental vision. Meanwhile the upstream changes from Beryl to Compiz are more limited due to a combination of license, coding quality, and structural differences. This too is fine for the most part.
Where I disagree with Beryl is in their choice to change the license from MIT to GPLv2. This move was ostensibly done to ensure that Novell does not take the code and not give back to the community. i.e. Make sure the code “remains free”. However DR has shown no indication of hiding the code or trying to do anything underhanded, indeed he has been somewhat open for a primarily one man project. This change of license is somewhat ill advised and in my opinion harmful to both projects. It makes it harder for patches to go upstream and significantly hampers any cross project cooperation. So instead of two projects sharing different visions but code and ideas, you have one leeching of the other. In the meantime some changes go upstream, but at the cost of more work by DR rather than less.
In short I think the branch is a good idea, but that the change in license was ill thought out and shows a distinct lack of respect for the work DR is doing by not offering nearly as much in return. If later down the line Beryl’s fears about Compiz turn out right, then they should change the license at that time. Right now all they are doing is generating friction with the license change. There is friction due to other reasons as well, but at least this one is unnecessary and harmful IMHO.
I’d like to play with Beryl, but what is the best way in OS X?
Would it be better to run Beryl under OS X’s X11 app, or run a Linux VM?
How hard is it to install? I ask because I never could get FVWM Crystal installed on an x86 box, I just gave up with all the dependencies. Is Beryl as bad in that respect?
Edited 2007-02-28 19:35
I do not believe Beryl will work in OS X (be very surprised if it did) nor would I recommend trying it in a VM. Either install Linux somewhere or try a live CD that will boot on your hardware. Saboyan (sp?) would be my recommendation.
Compiz is now included in Universe for Feisty, though is disabled by default. Since I had never gotten it working before I decided to try with these packages and all went well. I also ended up installing gandalfn’s manager app to help with configuration.
First thoughts:
1) Configuration is not as detailed or as flexible as Beryl’s using the manager app.
2) I really like being able to assign a mouse button to corners for actions.
3) I do not like that when I trigger scale I can not stop scale by hitting the corner again.
4) CPU usage is higher in compiz, but this is not a big deal for me.
5) I miss input enabled scale and zoom. Input enabled scale in particular I have a hard time without. I use it extensively to bring up GAIM and terminals for quick notes.
overall I find the 2 comparable, and if I had any problems with stability in Beryl I would have little problem switching to Compiz. They both “get the job done” for me. The one thing that made me switch back after playing around with Compiz for the last 3 hours is input enabled scale. I simply use that too much now.
Let me stress I think both are fine implementations, however I found configuration in Beryl more to my liking and input enabled scale missing. DR is working on a proper way to do that missing feature however so that is a short lived inequity.
People comment about the stability and usability of Beryl quite often as a negative, I have to assume with reason. I however have never had a problem with this, so I will stick with Beryl for now and revisit Compiz as things progress.
P.S. As an addendum in a previous article someone had posted problems with wobbly being active for menus. I criticized him since I had never seen it active in Beryl. It does seem to be active in Compiz for Feisty at least. So while he was still wrong on criticizing Beryl for this, in the sense of fairness I bring this up to show he was not completely off base. (Wobbly menus are awful too by the way.)
P.P.S. This is not meant to be a thorough comparison of the two or a measure of merit as to which is better. I quite literally simply got Compiz working on the first try and for a few hours, as I came across something, wrote it down.
Shouldn’t it be absolutely the opposit? Weird if that really helps.