Compiz Project Releases C++ Based v0.9.0 237
werfu writes "Compiz 0.9.0, the first release of Compiz rewritten in C++, has been announced on the Compiz mailing list. See the announcement for more info." Compiz has for years been one of my favorite ways to make Windows users envious, despite my (Linux) systems' otherwise low-end graphics capabilities. Besides the switch to C++ from C, this release "brings a whole new developer API, splits rendering into plugins,
switches the buildsystem from automake to cmake and brings minor functionality improvements."
Re:Objects... (Score:3, Interesting)
I think it's because if you want all the shiny bits of objects and encapsulation then you use Java. If you want raw speed & dirty tricks then you use C.
I favor C++ myself, but I'm a huge fan of breaking encapsulation.
Summary Fail (Score:5, Interesting)
The relevant words from the announcement are "complete rewrite". Or in simpler terms for the users, you do not want to run this until it reaches 0.10 (also as per the article.) This is a development and not stable release. (Sure would be nice if they would go 1.0 instead of .10 if it's going to be a stable release...)
Here's the stuff from the announcement interesting to users:
Everything else is of interest only to developers...
Re:favorite way (Score:5, Interesting)
Re:Objects... (Score:3, Interesting)
The point is that its niche. The range of situations where you need raw speed, yet by-the-book OOP doesn't slow you down too much is very very small. Games and large commercial desktop apps are basically it. Line of business apps will usually go .NET or Java, web apps will go PHP, .NET, Java, PERL, Python, whatever. Drivers will go C/Assembly, specialized backend systems will go C/Assembly, etc.
There's exceptions to everything and i realize this is a gross generalization, but overall it stands, leaving C++ in a pretty small (but significant nevertheless) niche as opposed to C. You need too much speed to use the more high level solutions, but not enough speed to require C or assembly...
Re:favorite way (Score:5, Interesting)
I use a variety of POSIX operating systems 95% of the time, at work through necessity, and at home through choice. And because I use them, rather than despite it, I am compelled to respond.
And drunken cheerleaders get date raped more than shut-in nerd chicks. Personally, I prefer nerd chicks, and you likely do too, but most people don't. Really, they don't, and there's no use telling them that their opinion is wrong.
If you don't value your time. For the latest of many, many examples down the years, I 'invested' 3 hours this weekend trying to get WiFi with WPA working again after upgrading my wife's box from Ubuntu 9.10 to 10.04. Verdict: the rt73usb driver has (yet again) returned to a state of porkage, so it was (yet again) ndiswrapper and Windows drivers for the eventual win.
Until of course you try and run a script written for fooshell on barshell, i.e. when a distro changes its shell [ubuntu.com].
Can be made to run on it, given enough time.
If you limit "ever" to "older than two years or so". But sure, many of the drivers give the appearance of working tolerably well, for a surprising amount of the time! And when they don't, well, there's ndiswrapper, or we'll-fix-it-in-the-next-release, or you've-got-the-source-compile-a-previous-version-yes-we-know-it-doesn't-build-against-your-kernel-headers-or-gcc-version-fix-it-yourself-you-filthy-M$-shill.
Ain't seen on one Windows for years.
Granted. Oh, unless you've got a driver bug, which you almost certainly do if your hardware was designed this millennium. Then see above.
By that measure, that would mean...
...that.
This is not the year of Linux on the desktop (or the netbook). I thought we were there with Ubuntu 10.04, but it's actually a regression from 9.10. I'd just recommend 9.10, but that's effectively abandonware now, just like all previous versions of all Linux distros, "LTS" included.
Again: I'm writing this from Ubuntu 9.10. I've got RHEL5 in that VM over there, SUSE 11 yonder, Solaris in that shell, and even SUA on Windows (tastes a bit like POSIX). I'm happy with POSIX OSen. But I would not recommend them to a Joe Windows user, ever, since I don't want to be their Support Guy from now until there's a distro that actually Just Works.
You mean, nothing for you, right? (Score:3, Interesting)
I have to agree that the cube is useless (and I don't use it).
There are a number of plugins that increase productivity a lot though, namely the scale, desktop wall, expo, app switcher and zoom plugin. Problem is: the default configuration is not designed to be useful, but to be easy.
While installing new systems, I install the CompizConfig Settings Manager, and then set up the plugins for efficiency: I basically map common window functionality to screen edge/corner clicks with the mouse.
Base setup is 6 (2x3) desktops. I move between these desktops by clicking one of the edges (depending on which direction I want to go - up/down/left/right) of my screen with the right mouse button.. See the overview (expo) with right click to the top-right edge. Alt-tab/Alt-shift-tab with mouse button clicks to the top left edge (app switcher), and see open window overview with right/left clicks to the bottom-left corner of the screen (scale).
This (combined with select - emulated middle button pasting) effectively enables me to do all activity you'd normally need mouse+keyboard to do with keyboard only.. and that very fast and instinctively.
Guess what you wanted to say is: the default configuration could use some tuning. Problem is: though this improves baseline productivity and is very fun when being used to it, it violates the common desktop paradigm that every desktop function has to be an icon, or context menu. In other words, setting it up in a useful manner involves thinking and learning a bit, which most folks seem to avoid by all means. (no offense).
Re:Objects... (Score:3, Interesting)
Why would you want to break encapsulation?
Speed. Lazy. Debugging.
And in C you can have encapsulation, polymorpism and all other goodies OOP provides. C++ just makes it easier. For example many libraries don't export the contents of structures in the exported header files. zlib for example gzopen() returns a "gzFile" which is a typedef void*, and doesn't expose any internals.
Re:You mean, nothing for you, right? (Score:3, Interesting)
Ah, sorry, wrong wording. Actually, I just wanted to expand your comment. In my experience (and I spent quite some time on it) much of the usefulness of compiz is a matter of configuration.
So I'd rephrase my leading comment to "the desktop cube is useless to me". But that's what I like about being able to adopt compiz to my bidding. People are different, and I can adopt compiz to my preferences while not bothering you. :)
People should be aware of how the work and see how they can adopt the tools to make the process more efficient. And in the content of the comment I tried to show a method, well my method of how I did this.
Context: I'm a horribly lazy person. That's why I spend a lot of time optimizing things. I learned Dvorak SDK and VIM for that reason, and did the same for compiz for exactly the same reason. I admit, the customizations that I did are not really obvious.
Re:Objects... not as easy as they sound (Score:3, Interesting)
I would imagine that the biggest performance hit for C++ vs C is just the fact that most objects make extensive use of memory allocations. C++ makes this 'safer' than in C, and so most C++ users use it. In C, I tend to avoid memory allocation. You end up defining arrays sized to some reasonable maximum, but there's no performance penalty for that. Occasionally, this does cause problems when that maximum was underestimated, but most of the time it's pretty effective.
Where I work, we have a transaction processing system that was developed in C. Most of the library code is in C, and multiple attempts to build applications in C++ have resulted in something much more complex and less supportable than the 'standard' C apps. I don't know if this is due to unskilled C++ programmers, or if maybe the particular environment, being highly optimized for C coding, just doesn't gain many of the advantages C++ could provide had the platform been object oriented in the first place.
For example, our standard apps maintain state persistence by simply writing out one or more C structures to a temp file on disk. These files are simply read back in on the next transaction, requiring no code and no serious overhead (the data's usually in cache anyway). It sounds crude, but it's amazingly effective. C++ coders could continue to do this, of course, but they've assumed they needed to use objects for this purpose, leading to complex schemes for streaming those objects out to disk for persistence.
Then you get the programmers that attempt to build a pseudo MVC view around a platform that was designed to be a back-end system with a smart terminal front end. In this platform, all the code is on the back end, and the 'view' and the 'controller' are pretty much intertwined. But they persist and build these arbitrary separations which have to then communicate back and forth and each have to persist their own states. After the fact, they've all agreed that what they've built is harder to support than the C stuff they were building before. .Again, maybe this is bad coding or a misunderstanding of the OOP model, but it does point out a problem with C++. Unless you're just building code around an existing, well defined C++ framework, you're not likely to implement a great object model on the first (or fifth) try.
Re:favorite way (Score:3, Interesting)
I run compiz on several Atom 230 and 330. This are mini-itx mobos that have integrated Intel GMAs (Pineview series). I am checking this as we speak over SSH.
Compiz CPU usage: 2% Ram: 34MB.
This is with all settings turned up to 11, and, since this machines are surveillance systems, 4 windows showing 352x288 video @30fps each, plus a fullscreen browser window that is constantly updated.
Total CPU usage is ~3.4%.
Re:favorite way (Score:4, Interesting)
Excuse me, what part of "since this machines are surveillance systems, 4 windows showing 352x288 video @30fps each, plus a fullscreen browser window that is constantly updated. Total CPU usage is ~3.4%." You didn't understand?
It's not compiz itself eating up that much processing power. It's the 4 threads capturing 352x288 video @30 fps, and displaying it in 4 different windows.
Also, it is IMPOSSIBLE for any operating system to be actively displaying how much CPU it is using while using 0% CPU. Answer: WINDOWS IS LYING TO YOU.
On the other hand, even if windows created some magic way to run out of thin air while using 0 processor power, it would mean nothing because it would still be completely useless.