Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On 03/25/2013 04:28 PM, Pekka Paalanen wrote: You only need the Weston fork, just use libwayland from upstream. noupe. Scott actually just needs to fork desktop plugin or maybe not even that, just to create a new desktop client for starting his . I've created two examples of repository here demonstrating the idea. 1. https://github.com/tiagovignatti/weston-desktop-plugin This repository just holds a standalone copy of the Shell Desktop plugin from Weston freedesktop.org -- simple, easy to understand and modularized. Relies on Weston and its SDK for spawning the plugin process with the right API. It is using wl_shell_surface high-level wrapper of wl_surface for defining the desktop UI aspects and semantics, as defined in Wayland core protocol. Hawaii desktop could use weston-desktop-plugin but instead of relying on wl_shell_surface can wrap another interface with wl_surface. Scott can do the same for his minimize/maximize/whatever ideas. 2. https://github.com/tiagovignatti/gtk-shell It's an example how to have a desktop shell client for Weston based on a real toolkit. The idea is that this client and any other based on any toolkit can be interchangeable to use with a single desktop plugin like the weston desktop plugin. In summary, the idea is to have one compositor (say Weston) and a single desktop plugin can be used as a foundation for building different shell UIs (clients) based on different graphics toolkits. ...should be simple like that ;) What do you say Scott? Tiago ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On segunda-feira, 25 de março de 2013 15.12.47, Scott Moreau wrote: > > Try to do your changes in a different extension. Copy the current wl_shell > > into a new one and modify it to your heart's desire. If, at the end of > > your experiment, you conclude that the current wl_shell is flawed by > > design, then Wayland should deprecate it and adopt yours. On the other > > hand, if we conclude that your improvements can be added incrementally, > > we can simply do exactly that. > > This sounds great but this is not the solution I have come up with. Ok, understood. Can you tell us why your solution is better than the above? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 3:08 PM, Thiago Macieira wrote: > On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote: >> Northfield stands on the shoulders of giants, years worth of work and >> history to get to the point where we are today. It has been some 8 >> years since compiz has exposed these many restrictions found in X >> protocol. We want certain effects to be readily possible and are not >> inherently restricted by certain caveats of the display server >> protocol. I expect that wayland core protocol will be added to support >> the basic functionalities expected as part of todays Linux Desktop. I >> believe that there wont be any problems with this particular effect >> and others. However, I want to make absolutely sure of that. > > Scott, > > What we're asking is that you avoid forking Wayland at all. Don't change the > library, don't change the default extensions (including wl_shell), don't add > new default extensions. You said you want to avoid incompatible changes: well, > avoiding the fork also avoids the temptation. > > Try to do your changes in a different extension. Copy the current wl_shell > into > a new one and modify it to your heart's desire. If, at the end of your > experiment, you conclude that the current wl_shell is flawed by design, then > Wayland should deprecate it and adopt yours. On the other hand, if we conclude > that your improvements can be added incrementally, we can simply do exactly > that. This sounds great but this is not the solution I have come up with. > > I'll ping you on IRC to discuss this. Several people have asked you to do it > and you have either missed the point or failed to explain to us why the fork > is necessary. > > PS: compiz is also a bad example. It might have been a great experiment and > resulted in improvements in most existing WMs, but it was a horrible WM. It > had bugs with its core WM functionality that went unfixed for years. I think compiz is in fact the very model example of what a compositing manager for the Linux Desktop should be. Yes, it has had many bugs over the years but many of these are because the X protocol is extremely difficult to work with and inherently problematic. We can do the same things now, but this time, uninhibited, thanks to the driver situation. I am sorry that you feel this is unnecessary but I disagree. - Scott > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote: > Northfield stands on the shoulders of giants, years worth of work and > history to get to the point where we are today. It has been some 8 > years since compiz has exposed these many restrictions found in X > protocol. We want certain effects to be readily possible and are not > inherently restricted by certain caveats of the display server > protocol. I expect that wayland core protocol will be added to support > the basic functionalities expected as part of todays Linux Desktop. I > believe that there wont be any problems with this particular effect > and others. However, I want to make absolutely sure of that. Scott, What we're asking is that you avoid forking Wayland at all. Don't change the library, don't change the default extensions (including wl_shell), don't add new default extensions. You said you want to avoid incompatible changes: well, avoiding the fork also avoids the temptation. Try to do your changes in a different extension. Copy the current wl_shell into a new one and modify it to your heart's desire. If, at the end of your experiment, you conclude that the current wl_shell is flawed by design, then Wayland should deprecate it and adopt yours. On the other hand, if we conclude that your improvements can be added incrementally, we can simply do exactly that. I'll ping you on IRC to discuss this. Several people have asked you to do it and you have either missed the point or failed to explain to us why the fork is necessary. PS: compiz is also a bad example. It might have been a great experiment and resulted in improvements in most existing WMs, but it was a horrible WM. It had bugs with its core WM functionality that went unfixed for years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
Hi Casey, On Mon, Mar 25, 2013 at 2:28 PM, Casey Dahlin wrote: > On Mon, Mar 25, 2013 at 02:14:23PM -0600, Scott Moreau wrote: >> Sorry, I misspoke here. What I meant was, "This isn't about the >> wayland core protocol, the core wayland developers have this part >> covered. This is about raising the bar on the effects users expect to >> see in a wayland compositor and thus, forwarding wayland indirectly as >> Beryl did with Compiz." > > I'm not questioning your intentions. The effects they might have is what's > worrying. Since when have compiz effects become worrisome? > > --CJD To complete my initial point regarding minimize protocol specifically, X has never had a sane way to do Live Minimized Window Previews. This feature suggests that you would be able to minimize a video player, and still be able to view it in a scaled down version, in response to a hover event on the taskbar item for example. Or, while a window switcher (i.e. Alt+Tab) could show the scaled down preview in a graphical list. Or, a Scale effect (aka osx expose effect) could show the video while still playing. This should be considered when writing the protocol if your intent is to be able to support this effect. The specific implementation implications will only be known after an implementation is in place and any potential bugs are found. This could provide insight as to what cases might be problematic for this feature. Northfield stands on the shoulders of giants, years worth of work and history to get to the point where we are today. It has been some 8 years since compiz has exposed these many restrictions found in X protocol. We want certain effects to be readily possible and are not inherently restricted by certain caveats of the display server protocol. I expect that wayland core protocol will be added to support the basic functionalities expected as part of todays Linux Desktop. I believe that there wont be any problems with this particular effect and others. However, I want to make absolutely sure of that. - Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 02:14:23PM -0600, Scott Moreau wrote: > Sorry, I misspoke here. What I meant was, "This isn't about the > wayland core protocol, the core wayland developers have this part > covered. This is about raising the bar on the effects users expect to > see in a wayland compositor and thus, forwarding wayland indirectly as > Beryl did with Compiz." I'm not questioning your intentions. The effects they might have is what's worrying. --CJD pgpYxfof_a3FY.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
> > Casey: The point is, this isn't just a frivolous fork. This isn't > about wayland. Sorry, I misspoke here. What I meant was, "This isn't about the wayland core protocol, the core wayland developers have this part covered. This is about raising the bar on the effects users expect to see in a wayland compositor and thus, forwarding wayland indirectly as Beryl did with Compiz." > It's about focusing the energy of a collective group of > people who want to see and do cool things on the Linux Desktop. > > - Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 1:11 PM, Casey Dahlin wrote: > On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote: >> Hi Casey, >> >> On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote: >> > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote: >> >> Yes, there is no reason to fork libwayland. And I don't feel this is a >> >> true fork, just a temporary rename to avoid the confusion it might >> >> otherwise cause, remaining under the 'wayland' name. Wayland has been >> >> in my github repo since I've uploaded it there. The only difference >> >> now is, the name has been changed and an official fork announcement >> >> has been made by request. >> > >> > ...ok. I'll leave how exactly that's less confusing as an exercise to the >> > reader. >> > >> > Seriously, if you'd just forked Weston and left Wayland alone I'd be on >> > your >> > side. Even happy. This, however, is just making a political mess. >> > >> > --CJD >> >> I'm not sure where the confusion is. Northfield == Wayland but with a >> few changes to wl_shell_surface interface for minimize/maximize/close >> stuff. These changes are actually being discussed on the mailing list >> for possible review and inclusion. Once these basic events/requests go >> upstream, there will not be a need for northfield as a patched version >> of wayland. In reality, this is just a project name that !wayland. The >> need for this custom libwayland is only necessary until the new >> protocol is pushed upstream at which point, this need should be >> eliminated. >> > > Shell surface was in weston for awhile. Why not just wl_new_shell_surface in > your forked weston's protocol extensions? > > --CJD There are multiple parts to the shell in the code. You have the core protocol in wayland, weston's shell plugin and the desktop-shell client also in weston. The wl_shell_surface is somewhat of a catch-all interface for any client that wants to display its surface in a wayland compositor. In order to do basic features such as move, resize, maximize, minimize, etc you need certain event/requests, often times in pairs. Currently, maximize is in core wayland wl_shell_surface interface protocol and it only makes sense, to put minimize in the same place as maximize, in the code. You could do it as a local weston protocol and have clients connect to this, yes. However, this is a core desktop functionality and belongs in the core. Also, more work would be required to move the code from weston to wayland. The amount of work is negligible but it still has to be done. This could possibly be error prone. Also, the discussion about this protocol should be done in the light and realization by all, that this is in fact a core functionality and an expected part of todays desktop functionality per specs. However, I think you're not seeing the bigger picture here, so please allow me to explain a bit. There are certain implications that we've had with X that make it very difficult to do certain things in a compositing manager for X. For example, Sam Spilsbury was one of the very first people to try and get input redirection (IR) work in X, under compiz. He worked very diligently with IRL colleague Joel Bosveld to try and convince X to fake certain input events so that you could use a transformed surface. See http://www.youtube.com/watch?v=YHEisy-ORvY and take note of the date. This is extremely problematic in X, yet I think people don't realize that we've never been able to do IR properly in X. There are other things that wayland makes far simpler than the X+compiz model. Yet, we still have the same capabilities. It is noteworthy here, that not only did Sam Spilsbury work on IR, but we also worked on a ton of other cool things for compiz, including a Head Tracking plugin when wiimotes first came out http://www.youtube.com/watch?v=5M7ejHp2NM8 again, notice the date. Sam Spilbury pushed compiz forward immensely and drove compiz development with massive contribution including but not limited to: - Awesome Compiz Videos These videos were not particularly easy to shoot. It was not as easy as it is today with weston's built-in wcap recorder. You'd have to 1) Acquire the right hardware. 2) Install your drivers. This could be absolute nightmare depending on whether or not you needed XGL and what hardware you had. 3) Install compiz/beryl. Even with the code installed, documentation was scarce and developers had to figure things out for themselves. 3) Shoot the video. There was a special vidcap recorder plugin introduced in Beryl that allowed shooting a video (even with optional watermark image). He would do all editing to make the video stellar as an advertisement https://www.youtube.com/user/smSpillaz/videos?query=compiz - Driving Development He single handedly drove development by keeping the channels alive, upbeat and active, asking all of the pertinent thought provoking questions and submitting countless patches and ideas. - Countless Plugins Sam also wrote tons of plugins, some of whi
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, 25 Mar 2013 12:51:07 -0600 Scott Moreau wrote: > Hey Casey, > > On Mon, Mar 25, 2013 at 12:46 PM, Casey Dahlin wrote: > > On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote: > >> "The key point to understand is, that this is not a new protocol in its > >> own right. It *is* the wayland protocol, with a few minor additions > >> that make it possible to do new interesting things." > > > > Then don't fork the library. > > I did not want to call it a fork since I don't feel that it is. > However, I have now changed the name and announced it as a fork at > Kristian's request. You seem to be unable to distinguish Wayland and Weston. Fork Weston all you want. Not Wayland. > > "A few minor additions" can exist outside the codebase. Hell, all of the > > shell > > protocol exists outside the wayland codebase. All of THE DRM CODE exists > > outside of the wayland codebase. > > > > If what you say is true about not forking the protocol then there is NO > > reason > > to fork libwayland. > > > > --CJD > > Yes, there is no reason to fork libwayland. And I don't feel this is a > true fork, just a temporary rename to avoid the confusion it might > otherwise cause, remaining under the 'wayland' name. Wayland has been > in my github repo since I've uploaded it there. The only difference > now is, the name has been changed and an official fork announcement > has been made by request. I totally agree with Casey here. Why do you need to rename it, or point people to your fork of libwayland, if you are not modifying it? There is no need for you to fork or rename libwayland, or advertise your own repo for libwayland. It is hard to not break the protocol or ABI - the very thing you said you would not do. And if you commit there something, it will stick there for a long time, and you will have to live with it. So if you can't deal with the review process, don't go there. Or are you perhaps planning to break your own protocol additions? I even moved the sub-surface protocol from libwayland to weston, because it is easier to develop that way. If you want to change wl_shell_surface interface, you can start by copying it under a different name. That only gives you more power, as you can now also modify and remove already existing protocol that was not good enough. That is the kind of power you really want, to not be hindered by existing things. If you don't want to copy it and rename a load of stuff, you can add a new interface similar to wl_shell_surface, but parallel to it. That way you don't even need to care about protocol versioning at first. You can change the protocol all you want for a long time, and when you are happy with it, then see how it will integrate into wl_shell_surface, or should we just deprecate wl_shell_surface altogether. You only need the Weston fork, just use libwayland from upstream. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote: > Hi Casey, > > On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote: > > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote: > >> Yes, there is no reason to fork libwayland. And I don't feel this is a > >> true fork, just a temporary rename to avoid the confusion it might > >> otherwise cause, remaining under the 'wayland' name. Wayland has been > >> in my github repo since I've uploaded it there. The only difference > >> now is, the name has been changed and an official fork announcement > >> has been made by request. > > > > ...ok. I'll leave how exactly that's less confusing as an exercise to the > > reader. > > > > Seriously, if you'd just forked Weston and left Wayland alone I'd be on your > > side. Even happy. This, however, is just making a political mess. > > > > --CJD > > I'm not sure where the confusion is. Northfield == Wayland but with a > few changes to wl_shell_surface interface for minimize/maximize/close > stuff. These changes are actually being discussed on the mailing list > for possible review and inclusion. Once these basic events/requests go > upstream, there will not be a need for northfield as a patched version > of wayland. In reality, this is just a project name that !wayland. The > need for this custom libwayland is only necessary until the new > protocol is pushed upstream at which point, this need should be > eliminated. > Shell surface was in weston for awhile. Why not just wl_new_shell_surface in your forked weston's protocol extensions? --CJD pgp0mCjWYAYf8.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
Hi Casey, On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote: > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote: >> Yes, there is no reason to fork libwayland. And I don't feel this is a >> true fork, just a temporary rename to avoid the confusion it might >> otherwise cause, remaining under the 'wayland' name. Wayland has been >> in my github repo since I've uploaded it there. The only difference >> now is, the name has been changed and an official fork announcement >> has been made by request. > > ...ok. I'll leave how exactly that's less confusing as an exercise to the > reader. > > Seriously, if you'd just forked Weston and left Wayland alone I'd be on your > side. Even happy. This, however, is just making a political mess. > > --CJD I'm not sure where the confusion is. Northfield == Wayland but with a few changes to wl_shell_surface interface for minimize/maximize/close stuff. These changes are actually being discussed on the mailing list for possible review and inclusion. Once these basic events/requests go upstream, there will not be a need for northfield as a patched version of wayland. In reality, this is just a project name that !wayland. The need for this custom libwayland is only necessary until the new protocol is pushed upstream at which point, this need should be eliminated. - Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote: > Yes, there is no reason to fork libwayland. And I don't feel this is a > true fork, just a temporary rename to avoid the confusion it might > otherwise cause, remaining under the 'wayland' name. Wayland has been > in my github repo since I've uploaded it there. The only difference > now is, the name has been changed and an official fork announcement > has been made by request. ...ok. I'll leave how exactly that's less confusing as an exercise to the reader. Seriously, if you'd just forked Weston and left Wayland alone I'd be on your side. Even happy. This, however, is just making a political mess. --CJD pgpoQatfjKE24.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
Hey Casey, On Mon, Mar 25, 2013 at 12:46 PM, Casey Dahlin wrote: > On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote: >> "The key point to understand is, that this is not a new protocol in its >> own right. It *is* the wayland protocol, with a few minor additions >> that make it possible to do new interesting things." > > Then don't fork the library. I did not want to call it a fork since I don't feel that it is. However, I have now changed the name and announced it as a fork at Kristian's request. > > "A few minor additions" can exist outside the codebase. Hell, all of the shell > protocol exists outside the wayland codebase. All of THE DRM CODE exists > outside of the wayland codebase. > > If what you say is true about not forking the protocol then there is NO reason > to fork libwayland. > > --CJD Yes, there is no reason to fork libwayland. And I don't feel this is a true fork, just a temporary rename to avoid the confusion it might otherwise cause, remaining under the 'wayland' name. Wayland has been in my github repo since I've uploaded it there. The only difference now is, the name has been changed and an official fork announcement has been made by request. - Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote: > "The key point to understand is, that this is not a new protocol in its > own right. It *is* the wayland protocol, with a few minor additions > that make it possible to do new interesting things." Then don't fork the library. "A few minor additions" can exist outside the codebase. Hell, all of the shell protocol exists outside the wayland codebase. All of THE DRM CODE exists outside of the wayland codebase. If what you say is true about not forking the protocol then there is NO reason to fork libwayland. --CJD pgpvJG6pcKOvX.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
Hi Casey, On Mon, Mar 25, 2013 at 12:00 PM, Casey Dahlin wrote: > On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote: >> What Northfield *is not* >> - A fork that will change protocol in fundamental ways that diverts >> from the wayland EGL spec >> - A project that aims to cause divisions in the community or the Linux >> Desktop code >> - A project that breaks core wayland protocol in unrepairable ways >> - Diverting significantly from wayland >> - An unfriendly 'takeover' >> - Unnecessary >> >> The key point to understand is, that this is not a new protocol in its >> own right. It *is* the wayland protocol, with a few minor additions >> that make it possible to do new interesting things. It uses the same >> EGL drivers in Mesa implementing the wayland-egl specification. This >> will not change. Northfield will always use the same driver stack as >> wayland. The difference is, that I now have the time to dedicate to >> being a (hopefully very) responsive maintainer. >> > > Then fork Weston and leave Wayland alone. > > More and different and better compositors have always been expected. Forking > the wayland libs itself is just creating confusion and giving yourself the > opportunity to break the protocol (which is extensible by default, and Weston > already adds features to it). > > This is just making a mess after Canonical has already confused things with > Mir. I'm already cringing at the thought of how Phoronix is going to cover > this. > > --CJD I know the post is long winded, but please read it in its entirety before jumping to conclusions. These excerpts from the original post should have alleviated your concern: "The key point to understand is, that this is not a new protocol in its own right. It *is* the wayland protocol, with a few minor additions that make it possible to do new interesting things." "What Northfield *is not* - A fork that will change protocol in fundamental ways that diverts from the wayland EGL spec - A project that aims to cause divisions in the community or the Linux Desktop code - A project that breaks core wayland protocol in unrepairable ways - Diverting significantly from wayland" "Perhaps it will come to stand on its own as a new wayland compositor, but not a new core protocol as is the case with Mir." Thanks, Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote: > What Northfield *is not* > - A fork that will change protocol in fundamental ways that diverts > from the wayland EGL spec > - A project that aims to cause divisions in the community or the Linux > Desktop code > - A project that breaks core wayland protocol in unrepairable ways > - Diverting significantly from wayland > - An unfriendly 'takeover' > - Unnecessary > > The key point to understand is, that this is not a new protocol in its > own right. It *is* the wayland protocol, with a few minor additions > that make it possible to do new interesting things. It uses the same > EGL drivers in Mesa implementing the wayland-egl specification. This > will not change. Northfield will always use the same driver stack as > wayland. The difference is, that I now have the time to dedicate to > being a (hopefully very) responsive maintainer. > Then fork Weston and leave Wayland alone. More and different and better compositors have always been expected. Forking the wayland libs itself is just creating confusion and giving yourself the opportunity to break the protocol (which is extensible by default, and Weston already adds features to it). This is just making a mess after Canonical has already confused things with Mir. I'm already cringing at the thought of how Phoronix is going to cover this. --CJD pgpRbF6fvOr9s.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
As you said in the other email thread, it seems that your end goal is
more related with desktop aesthetics and building a pretty DE. Thus core
compositor and protocol development is not the priority.
So in my opinion I'm not sure that forking Wayland/XWayland/Mesa or any
of the projects being carried by Kristian is the answer. What you could
aim instead is a new tree with your own shell plugin and stack over the
core protocol another high level surface protocol (i.e. not use
shell_surface probably), so you will be entirely free to do whatever you
want in terms of UI. And this wouldn't be a fork in any way but the
opposite cause would just build up Weston and related projects more --
I'm sure you would have to stitch these projects a bit, but the work
there would be small most definitely. I'd like to point this blog entry:
http://vignatti.wordpress.com/2013/03/05/ui-customization-on-wayland/
in summary, the idea is to build a DE for Weston using a real toolkit
library. I believe this is what Hawaii desktop is going towards.
But in any case I appreciate and applaud your efforts, Scott. I'm just
not sure the way you exposed is the best way of dealing with the situation.
Tiago
On 03/25/2013 05:43 AM, Scott Moreau wrote:
Ok, I admit it, you caught me. As much as I tried to say it isn't, it
is. GH Next was a preliminary code name for the patches housed on the
'next' branches of wayland/weston in github. However, it is now
officially a fork at the request of Kristian Høgsberg.
soreau: it's a fork
have the guts to call it what it is
soreau: I think it's time you pick a name for you project
start an irc channel for it
and go there
This does not accurately represent the entirety of what was said but
these are the key bits relevant to this discussion. I do not intend
this as an unfriendly fork. I was hoping that the idea of gh next
would be embraced by the core wayland developers but it was not
unfortunately. I was asked by Kristian to pick a different name for
these efforts. This is well within reason to avoid confusion, for the
time being. I will now shed some light on why I feel this fork is in
fact a necessary requirement to further wayland development.
History repeats itself. It is a known fact. This is the case now, as
was the case with compiz. I personally have been learning how to use
Linux since a few months before compiz exploded onto the Linux Desktop
in '05. I was totally blown away by what I saw my lowly computer
doing.
Compiz was the very first popular X window manager to allow for
amazing quality accelerated effects on the Linux Desktop. Compiz
development was originally started by a company called Novell, in
2005. This task at hand has largely insane, however Novell employed
mastermind David Reveman to make the compiz magic happen. It exploded
onto the Linux desktop scene. Not only could you do accelerated
effects, but the possibilities grew exponentially. This excited a
large group of people. Reveman did all of the original compiz work
including but not limited to:
- The original XGL implementation (which was later discarded in favor
of Høgsberg's AIGLX)
- Original compiz work on mplayer (to get it working correctly with
the new extensions required to do compiz compositing properly with xv
video playback)
- Work on GLX_EXT_texture_from_pixmap (the core extension required to
run compiz)
- xwinwrap (have movies or screensaver as your desktop wallpaper)
- many of the core compiz plugins ('desktop cube' is the very essence
and iconic symbol of compiz)
- compiz itself (maintained for several years)
Reveman was crazy - but in a good way. He was the mastermind that
developed an intimate understanding of X over time, which is the other
key component besides the required graphics driver knowledge to
develop the specifications. I have followed the compiz project very
closely since its inception. I noticed that there was a major
communication problem because davidr would only communicate through
IRC once in a blue moon, on a specific network on a specific
suse-specific channel. He would schedule a meeting with someone[TM]
who would then notify the community compiz devs about the time of the
IRC session. If any member wanted to ask a question, they would have
to make their schedule fit around this time frame. Clearly, this not
an optimal way to communicate.
Frustrated by the situation and knowing what compiz was capable of,
the community forked Compiz into a project called Beryl around 2006
(this might not be the exact date, however it's not relevant to the
point I am making here). After the fork, there was a huge flamewar and
many hurtful things were said. Over the course of a year or two, the
projects were simultaneously developed in tandem. The final outcome
was that eventually the two projects came to an agreement. Compiz and
Beryl merged to form Compiz Fusion. Over time, the Fusion name was
dropped and we were left once again with Compiz, only this time with
tons more
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
> The original compiz implementation is written in C. At the very end of > 2008, 12/24, Compiz++ was unveiled. Compiz++ was a C++ version of > compiz that was intended to be more easily maintainable. > Unfortunately, all of the plugins had to be ported. The majority of > this work was done by an aspiring college student, Sam Spilsbury. > Eventually, Canonical realized that they wanted to do Unity but didn't > really have the manpower required to do something entirely original. > instead, the ployed to use compiz as a base platform for their Unity > implementation. To this day, I still do support in #compiz. These > days, it's mostly complaints about how 0.9.x is broken in fundamental > ways that make the desktop unusable. Canonical severely damaged the > compiz image with their disruptive and ever-so-misleadingly-named, > Unity idea. Now, users are completely confused as to why compiz no > longer works and why the stable version remains unpackaged and unused > by distributions. > > It is noteworthy, that the original C implementation still works great > to this day. The latest version is 0.8.9 and it can be found in the > compiz-0.8 branches of compiz master. If anyone wants to help the > compiz situation immediately, please go get this code and package it > for ubuntu cgit.compiz.org http://wiki.compiz.org/Installation/Stable > as many users will appreciate it. I know I would. I appreciate that you want to move forward, but there is no need to bash other projects or developers publicly, and incite animosity and disunity in those projects. Best Regards, Sam > > > Sincerely, > > Scott Moreau > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
Ok, I admit it, you caught me. As much as I tried to say it isn't, it
is. GH Next was a preliminary code name for the patches housed on the
'next' branches of wayland/weston in github. However, it is now
officially a fork at the request of Kristian Høgsberg.
soreau: it's a fork
have the guts to call it what it is
soreau: I think it's time you pick a name for you project
start an irc channel for it
and go there
This does not accurately represent the entirety of what was said but
these are the key bits relevant to this discussion. I do not intend
this as an unfriendly fork. I was hoping that the idea of gh next
would be embraced by the core wayland developers but it was not
unfortunately. I was asked by Kristian to pick a different name for
these efforts. This is well within reason to avoid confusion, for the
time being. I will now shed some light on why I feel this fork is in
fact a necessary requirement to further wayland development.
History repeats itself. It is a known fact. This is the case now, as
was the case with compiz. I personally have been learning how to use
Linux since a few months before compiz exploded onto the Linux Desktop
in '05. I was totally blown away by what I saw my lowly computer
doing.
Compiz was the very first popular X window manager to allow for
amazing quality accelerated effects on the Linux Desktop. Compiz
development was originally started by a company called Novell, in
2005. This task at hand has largely insane, however Novell employed
mastermind David Reveman to make the compiz magic happen. It exploded
onto the Linux desktop scene. Not only could you do accelerated
effects, but the possibilities grew exponentially. This excited a
large group of people. Reveman did all of the original compiz work
including but not limited to:
- The original XGL implementation (which was later discarded in favor
of Høgsberg's AIGLX)
- Original compiz work on mplayer (to get it working correctly with
the new extensions required to do compiz compositing properly with xv
video playback)
- Work on GLX_EXT_texture_from_pixmap (the core extension required to
run compiz)
- xwinwrap (have movies or screensaver as your desktop wallpaper)
- many of the core compiz plugins ('desktop cube' is the very essence
and iconic symbol of compiz)
- compiz itself (maintained for several years)
Reveman was crazy - but in a good way. He was the mastermind that
developed an intimate understanding of X over time, which is the other
key component besides the required graphics driver knowledge to
develop the specifications. I have followed the compiz project very
closely since its inception. I noticed that there was a major
communication problem because davidr would only communicate through
IRC once in a blue moon, on a specific network on a specific
suse-specific channel. He would schedule a meeting with someone[TM]
who would then notify the community compiz devs about the time of the
IRC session. If any member wanted to ask a question, they would have
to make their schedule fit around this time frame. Clearly, this not
an optimal way to communicate.
Frustrated by the situation and knowing what compiz was capable of,
the community forked Compiz into a project called Beryl around 2006
(this might not be the exact date, however it's not relevant to the
point I am making here). After the fork, there was a huge flamewar and
many hurtful things were said. Over the course of a year or two, the
projects were simultaneously developed in tandem. The final outcome
was that eventually the two projects came to an agreement. Compiz and
Beryl merged to form Compiz Fusion. Over time, the Fusion name was
dropped and we were left once again with Compiz, only this time with
tons more effects (plugins) and decorations (emerald). Some may
remember Beryl but it's name did not live on. The code that was
developed by the community members under this project name does live
on however. You can still see traces of beryl in the official upstream
compiz repositories.
After compiz was 'done', it was solid and worked great. Distros
packaged it an everyone was happy. Awesome Desktop Effects on Linux -
check. We're done, game over, right? Unfortunately, this is not the
end of the compiz story.
The original compiz implementation is written in C. At the very end of
2008, 12/24, Compiz++ was unveiled. Compiz++ was a C++ version of
compiz that was intended to be more easily maintainable.
Unfortunately, all of the plugins had to be ported. The majority of
this work was done by an aspiring college student, Sam Spilsbury.
Eventually, Canonical realized that they wanted to do Unity but didn't
really have the manpower required to do something entirely original.
instead, the ployed to use compiz as a base platform for their Unity
implementation. To this day, I still do support in #compiz. These
days, it's mostly complaints about how 0.9.x is broken in fundamental
ways that make the desktop unusable. Canonical severely damaged the
compiz image
