Banshee 1.5.5
Gapless Playback / Playbin2
Banshee now uses the playbin2 GStreamer element. With this comes support for gapless playback, which is the default now for users with GStreamer > 0.10.25.2.
Grid View
We are debuting a new grid mode for our custom list widget, visible in the modified Album browser. It will be used for Videos, Audiobooks, and more in future releases.
Album browser, now as a grid
YouTube Extension
This extension shows YouTube videos in the Context Pane related to what you're playing, and lets you watch them within Banshee. You can enable it in the Extensions tab of the Preferences dialog.
Contextual YouTube videos
Banshee Community Extensions Update
We also released Banshee Community Extensions 1.5.5, including five new extensions: CoverWallpaper, LiveRadio, Magnatune, Telepathy, and Ubuntu One Music Store (not ready for users yet).
The Mirage shuffle/fill by-similar mode has been greatly improved. It's smarter, now looking for tracks similar to the last several you've played, and dissimilar from ones you've skipped.
Enhancements and Fixes
- Improve search responsiveness on large libraries
- Add icons for Nexus One and Audiobooks
- Play Queue item count, size, duration now ignores old tracks
- Muinshee fixes: disable Auto-DJ, allow reordering, hide previous song
- Fix a very common, SQL-related crash in 1.5.4
- Fix saving equalizer settings in culture-invariant way
- Jumping to a source's prefs via its context menu works again
- Usage data not submitted more than every 48 hours
- Fix repeatedly resyncing some files to a device b/c transcoded
- Clear the redo stack on shuffle mode change
- Accept feeds with empty title
- Uri encode file location queries, making them work properly
- Fixes to the OS X build
Plans
We are now string frozen in preparation for our 1.6 release on March 31st - so translators, full steam ahead! We might do a RC 2 in a couple weeks for additional testing and fixes. File bugs for any issues you find, and help us make Banshee 1.6 the best release ever!
Member
wstephensonDevelop Javascript Plasmoids on openSUSE
Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.
So it's even easier to take part in the Plasma Javascript Jam Session competition now.
And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!
FLISOL 2010 in Nicaragua
The folks of the openSUSE Community in Nicaragua, are preparing a great event in the city of Granada, Nicaragua, in Central America.
After some considerations and discussion within the Nicaraguan LUGs Community, SUSE-Ni was appointed to carry on with the FLISOL event on April 24th.
FLISOL stands for “Festival Latinoamericano de Instalación de Software Libre”: Free Software Installation Latinamerican Festival, where we make live demostrations and installation of Linux on the computers being carried by the crowd.
Nicaragua’s plans are to host 3 FLISOL events in 3 different cities: Managua, Granada and Leon (for the moment), leaving the management and direction in every site to one particular LUG.
For us, the openSUSE Group in Nicaragua, this is a great opportunity to participate in leading one of the main groups and to send personnel to the remaining places, so we can provide a permanent and effective presence in the Country.
Our Main event will take place at the Casa de los 3 Mundos, a Cultural Meeting place, administrated by Mr. Dieter Stadler. The house has enough room for us and for the visiting public.
More to come in the following days, detailing our plans and organization for the event.
Tomboy 1.1.4 Brings Automatic Synchronization
Here are some facts about autosync:
- It assumes the server is always right when conflicts occur, so if you actually found Tomboy's conflict-handling UI useful, don't use autosync
- When a sync occurs, it desensitizes all note windows, because Tomboy sync is still a bit insistent on believing in transactions.
- But in theory this should never be a problem for you, because Tomboy will never sync while you are editing a note. It will wait until *at least* one minute has passed where you have not been editing.
- Besides this desensitization of note windows, there is no indication at all that a sync has occurred. Next cycle, I intend to use libnotify bubbles and/or status icon changes where they make sense to let the user know if new updates have been downloaded, or if the sync server appears to be down, etc. Right now this feature is totally silent, though you can get a few details if you run from a terminal with --debug.
It's unfortunate that I've been too busy to publicize this feature until so very late in the cycle. I'd appreciate any testing, feedback, bug reports, etc. At this point all I can say is that it Works For Me.
Other sync-related news:
- Rumor has it that Ubuntu One note sync can no longer mangle your notes, unless you use their web editor, in which case the mangling is much less severe than in the past. I keep getting emails from Launchpad saying that Rodrigo has fixed yet another of the old irritating bugs, to the point that I've lost track and think he may have gotten the last of them! :-) This is great news for U1 users, who previously suffered from a few serious sync bugs.
- I've started the ball rolling on deploying Snowy on GNOME servers (this would be known as Tomboy Online, if the marketing team approves...I still need to email them).
- We have another Snowy planning meeting this weekend.
- Many thanks to Leon Handreke and Sander Dijkhuis for their valuable contributions to Snowy in git.
- Tomdroid 0.3.1 is out, and although it doesn't yet include web sync, the merge is impending!
Another feature in Tomboy 1.1.4 makes me very happy, might upset Tomboy old-timers, and could possibly cause Alex Graveley to destroy my very soul:
By default, when you rename a note, Tomboy will no longer automatically update all of the text that used to link to that note. Instead, if other notes link to the renamed note, Tomboy will show you a dialog (lame, I know, I intend to bind GtkInfoBar for next cycle to eliminate all dialogs in Tomboy) that lets you choose what to do. Here's an example screenshot, with the Advanced section expanded:
Some have argued that automatic link renaming is part of Tomboy's magic, but many many users (including me) consider this dark magic to be a serious potential data loss bug. If you've ever had a note called "Linux", and renamed it to "openSUSE", and been dismayed to find that everywhere in your notes where it used to say "linux" it now says "openSUSE", you know what I'm talking about.
In the future, I'd like to allow folks to have more control over note linking behavior. Many users have expressed a desire to turn off automatic linking, or to be able to link arbitrary text to another note (not just text that matches the note's title). Enough people have asked for it that it'll probably happen, though of course patches would make it happen faster.
Next time you hear from me, Tomboy 1.2.0 should be out, and we should be making progress on getting Tomboy Online deployed!
Chemnitzer LinuxTage
Looking forward to making this a great event where we cultivate innovation and creativity to further the development of the Fedora Project and it's contributors. See you there ;-)
On benchmarks
KDE Project:
Do you know this one?
Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).
Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.
So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.
And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.
Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.
And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.
Build your own Google Earth rpm
The last days I’ve spent some time to investigate how to package Google Earth into an rpm. There was already a script called make-google-package available on the internet, but this one creates a debian package only. However, it was a good start to get me going to create a Google Earth (GE) rpm. Although I met quite some obstacles, which is not to uncommon in package building, I was still able to come up with a procedure a get GE packaged. The biggest problem I encountered were incorrect library dependencies, for which I opened issue 702 in the Google Earth issue tracker. Anyway to make a long story short: the rpm installs Google Earth system wide, corrects file permissions, for openSUSE_11.2 it takes care that the font is rendered correctly, the rpm takes care that Google Earth integrates nicely with the rest of the openSUSE system.
The procedure to build the rpm can be found in the openSUSE wiki. One word of caution about the procedure, you need to be an experienced linux user and you need to have access to the openSUSE Build Service (OBS) to be able to build the rpm. This is due to library dependency problem, which prevents it to build without modification to the base system.
If you like and you have the knowledge how to build an rpm with the tool ‘build’, it would be great if you can extend the howto with steps how to do this (build a GE rpm with ‘build’) to the before mentioned page. The same is valid for a procedure that uses VirtualBox to build the rpm.
Last but not last; a procedure or even a script, that uses ”’rpmbuild -ba”’ to build the rpm, would be very welcom as well.
Panel Drawers in KDE
- Create a folder somewhere eg ~/Desktop/My Favourite Apps
- Drag and drop the folder onto a panel
- Choose "Folder View" from the popup that appears
- Drag apps from the menu, documents from Dolphin and other stuff onto the new panel icon
- Click it and enjoy your new menu!
Community Discussion - Part1
Improving in the MonoDevelop user interface
