I still miss 'window title search' and 'show all windows for an app' that I had in compiz.....
Window title search: https://extensions.gnome.org/extension/317/window-display/ shows the matching windows in the Overview as you type.
Show all Windows for an app: Maybe I'm missing something but I use Cycle through the apps with Alt-TAB, Cycle throught the windows for an app with Alt-AboveTAB. Which means to cycle through the windows for the current app, one press of Alt-AboveTAB shows the set. I use the cursor keys in Alt-TAB to navigate as well - not sure that is in Vanilla Gnome 3.4.
whine. whine whine whine. NOT WHING.
Actually, the root of whinging is whinge and if you haven't spent time in the British Isles, you probably don't recognise the term.
From the freedictionary.com
whinge (hwnj, wnj)
intr.v. whinged, whinging, whinges Chiefly British
To complain or protest, especially in an annoying or persistent manner.
[Dialectal alteration of Middle English whinsen, from Old English hwinsian.]
If you aren't appreciating the work you are doing now, consider asking your favourite local charity what software they need or what information they would like to gather and try and produce something that actually helps someone you can meet and talk to.
I've just been working on a prototype project for a local hospital who are trying to work their way through the social networking jungle, trying to assess whether their messages and fund raising is actually getting out there. You'll probably find that your local charity is awash with similar concerns but has no money to invest. Most experienced programmers can quickly pull a twitter aggregator, a facebook search app, a database and any amount of free software together and actually answer some of their questions. Or write a mobile app for them to distribute. Or help them improve their web service.
Biggest problem with this fast deblurring appears to be ringing artifacts - the Shan paper has a better algorithm for ringing suppression. I suspect a hybrid approach could get the best of both worlds.
I also note that the crowd scene in the Adobe MAX demonstration is actually in the supplemental pdf for the link you quoted, although that may just show that all the researchers in this area have a standard set of "problem" images to demonstrate their algorithms against. I'm guessing that that Photoshop implementation is GPU based and I also suspect that those configurations that were loaded in the demo were known-good starting parameters for each of the pictures posted. Reading through the various papers last night, it was fairly clear that the final image quality is quite sensitive to some of the noise parameters and that may prove to be one of the hardest parts to automate for productization.
This uses a single image as input, and tries to determine a local prior (L) and a motion kernel (f). It switches between optimization of each in turn, and produces results similar to the demo seen in the video. Given that Aseem works for Adobe, I suspect this work is now close to release.
As far as user interfaces go, it is Havoc Pennington's way or the highway. Havoc has this crazy "usability comes from crippling" approach that dumbs down GNOME for entry-level users but makes it wholly unusable for power users.
I'd most definitely stick myself into the power user category. I've been a GNOME user since 1.4, anything I do more than once has been scripted or bound to custom keys and I have Kupfer for the fast access to anything I can think of, including custom plugins for work-specific tasks. GNOME stays the hell out of my way and that's the way I like it. When I need to reach for something unusual, I can normally hook it via DBus or gconf.
That's why I cannot stand Gnome. Sometimes it's very nice, like the customized versions for NetBooks, but the default version for PCs which has NO option to tweak it (unless you count recompiles which are worse than Windows registry edits) make it so that I don't and won't use it.
Pretty much every Gnome tweakable can be changed with gconftool-2 or similar. If you want to hack the code to pieces and compile in something new, feel free, but it's mostly wasted effort because almost everything important can be altered. That the main GUIs are NOT cluttered by dozens of options actually makes a fair bit of sense. Alterations made with gconftool-2 are typically instantaneous, so if you want to change the spacing between buttons or enable compositing, it'll be done as soon as you make the change.
"Seems to be just as slow as V2 though."
Indeed. 8 cores and still >10 seconds until something happens when I press a button.
You've got Malware!
Seriously, scrolling is instantaneous on my laptop, a T61p vintage 2006 with Core Duo. Loading a page with 100 comments - about 1 second. Loading this 1300 comment monstrosity - about 4 seconds to interactive display, about 15 seconds to complete. Firefox 4.0b9, F14.
Firefox 4.0 beta 9 is still landing features
There's your problem. No new features should be introduced this close to release. Traditionally, no new feature should be added to a beta, period! They're asking for it.
I agree, up to a point. It used to be (when I was young and we had to walk uphill to and from school) that alphas were previews of some new features and betas were feature complete but still buggy.
These days, the beta label is more like an alpha and the term "release candidate" means feature complete. It should also be noted that Firefox landing features is quite different from developing new features in the trunk. These features are only enabled now because they have gone through an extensive bug squashing procedure on their development branch.
You clearly have never worked on a large software product.
During development of a product, you will see new bug rates go much higher than fixed bug rates. This imbalance will continue until you stop adding new features and focus purely on stabilization and product delivery. Firefox 4.0 beta 9 is still landing features (some of which have been baking for a long time in separate branches) so their bug rates look pretty sane to me. All products ship with known bugs - you just try to trim the list down to things that users are highly unlikely to see.
For web browsers, crash bugs are the most dangerous. They may represent routes through the code where bad pointers are being consumed and these can potentially lead to remote exploits. All reproducible crash bugs should be fixed as soon as possible.
Having browsed through the outstanding bug list for Firefox 4.0 and looked at the planned schedule (late February release), it looks reasonable. If some of the new features lead to a burst of new defects, I suspect that date will move out or features will get blacklists (like the WebGL/ Hardware acceleration blacklists for Linux)
That said, there is a really annoying bug in Beta 9 - some of my tabs, after I close them, still exist in the ether somewhere and the Awesomebar wants to "switch to tab" when I go to that URL, and there's no tab to switch to, making me press alt+enter to open a new tab.
Check the new Panorama feature to see if it has eaten your tabs.
My only concern is that last time I looked Wayland wasn't ready for primetime, and the intent with Wayland wasn't to be a full replacement for X for most users.
If Mark Shuttleworth was proposing Wayland for prime-time inclusion in Ubuntu 11.04 or even 11.10, I'd be concerned. But if you actually follow this news story to the original source at http://www.markshuttleworth.com/archives/551 you would find this:
Timeframes are difficult. I’m sure we could deliver *something* in six months, but I think a year is more realistic for the first images that will be widely useful in our community. I’d love to be proven conservative on that
So the first likely viewing of this would 11.10 and real integration into the entire stack is more likely in the 14.10/15.04 time frame.
So this is a classic storm in a teacup right now. The reality is "promising project will be supported by major Linux player for future inclusion".
Premature optimization is the root of all evil. -- D.E. Knuth