Wednesday, December 10. 2008KDE4 on OS X 10.4![]() (From left to right: Konqueror, KPatience, KStars) So it turns out KDE4 isn't just being ported to Windows, but Mac as well (universal binaries, both PPC and x86). It runs slow for now, and a lot of stuff doesn't work, but the games and education programs work alright. Very exciting stuff. Soon as Konqueror and Amarok 2 start working properly it'll be a happy day for OS X users, or... not. The new Konqueror will be using Webkit (Safari's engine, which itself is based on KHTML, Konqueror's current engine), and iTunes will likely run faster than Amarok. But at least tech demos can be done natively... all the easier to then lure people to an FOSS system =) Packages available at:http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X#Installation
Wednesday, December 10. 2008Amarok 2.0 released!We are happy to finally get our baby out of the door. Read the release announcement here: http://amarok.kde.org/en/releases/2.0, check abby’s screenshot tour and help us spread the word on digg, Twitter, your blog and wherever else you hang around :) This is just the beginning of a long journey. Join us on our way and party with us! Monday, December 8. 2008
Let me introduce you to: Linux Lancers! Posted by Mark Kretschmann
in markey at
19:28
Comments (4) Trackbacks (0) Let me introduce you to: Linux Lancers!![]() Heya, it does not happen very often that I blog about advertisements for companies. This one is an exception. I'm feeling good about it, since this company I'm blogging about could actually prove useful to the KDE/FOSS community. The company I'd like to introduce to you is Linux Lancers. Let me sum up in a nutshell what they offer: 1) For the job seeker: A place to find freelance and permanent FOSS jobs (and free advice). 2) For the company: A place to find competent FOSS programmers. Freelancing is an attractive job opportunity for many contributors in the Software Libre scene. Myself I have done several freelance jobs, and nowadays I am glad that opportunities are emerging that bring us Free Software experts closer to the companies seeking our knowledge. Disclaimer: I do not have any financial interests in this company. I'm posting this purely because I believe that the company offers a service that could be useful for our community, plus I'm friends with the company owner and I enjoy seeing his baby succeed. Friday, December 5. 2008
From the Post 2.0.0 Git Vaults, ... Posted by Nikolaj Hald Nielsen
in freespirit at
21:15
Comments (16) Trackbacks (0) From the Post 2.0.0 Git Vaults, Amarok Urls and Bookmarks
Amarok 2.0.0 has been tagged! Short of any really bad bugs showing up the release will be upon us shortly, just as soon as the packagers from the different distros have had a chance to do their thing! This release has been nearly 2 years in the making, and all of us developers have shed blood, sweat and tears trying to make Amarok 2 live up to the vision that has driven us all along. Overall, I am very pleased with the result. Some people will initially miss their favorite feature from 1.4.x but Amarok brings so many new thing to the table, that at least for me personally, it is a far superior player to 1.4.x already.
But this blog post is really not about Amarok 2.0.0 at all. You can be sure that his will be covered in great detail, reviewed, tested, loved, hated, praised, FUD'ed, criticized (both constructively and not so...) and all that in the weeks to come. What I will try to do here is give you a small glimpse into the future, the great big world beyond 2.0.0. You would think that having worked on Amarok 2 for 2 years, we would need a break. But actually, it seems that nearly all developers have big projects that they are ready to start on as soon as the feature freeze is lifted, or are already happily hacking along on new stuff in Git branches. I currently have 3 such branches containing post 2.0.0 features in different states of completion, and in this blog I will show some of the stuff I am working on in one of them. Remember that all this stuff is fresh raw and untested from my own git branch and may change in any number of ways before it ever gets near a release Amarok Urls The idea behind Amarok urls is to give amarok a concise way of referring to different "views" within the application and allow these views to be easily passed around, shared and stored. An Amarok url is simply a url with the protocol "amarok" followed by a command and a series of arguments encoded as a url. For instance "amarok://navigate/service/Magnatune.com" is an Amarok url that will cause the Magnatune service to be shown ( if enabled ). In my git branch, the "navigate" command has been fully implemented, and you can navigate in all the browsers. Amarok also installs a protocol handler, so clicking the link above will startup Amarok ( if not already running ), and make it show the Magnatune service. Actually the navigate command supports additional arguments, so a more complex url could be constructed that would not only show the Magnatune.com service, but also set the sorting mode and filter. So If I wanted to direct you to one of my favorite Magnatune.com artist, "Brad Sucks", I could write a url like this: "amarok://navigate/service/Magnatune.com/artist-album/artist:"Brad Sucks"". In this form, these urls are already useful. For instance, they provide a very easy way for context apples to provide "guided searching" in the browsers where clicking on an album cover in the context view actually browses to this album in the browser. Additionally they could be used if you want to blog about a cool new artist in one of the services, as you could simply provide a link similar to the one above, or online services could provide a "browse in Amarok" link for their content. There are many possibilities! Bookmarks A bookmark in my git branch is actually exactly the same as an Amarok Url, but the context in which it is used is different. A url is most often something that comes from an external source, whereas a url that is used internally to store a favorite view is what I call a bookmark ( I am very open for suggestions for a better terminology ). So without further ado we have the first screenshot of the evening, the (very much work in progress) "Bookmark Manager" applet: This applet allows you to grap the url of whatever state the browser is currently in. So browsing somewhere, setting a view mode and entering a filter, and then pressing the "Get Current" button will generate the corresponding url. The manager allows basic operations such as saving, renaming, deleting and of course applying (activating) bookmarks. I have not quite gotten drag and drop organization working, but that will be possible as well. This is also nice if you want to share a cool view with someone, as you don't have to think about how to manually construct the url, but can simply press "Get Current". Oh as i am sure some people will ask why I made this an applet and not a browser, the reason is simply that since these bookmarks actually "work on" the browser, it makes sense to be able to play around with the bookmarks without the manager getting hidden as soon as you activate a bookmark as it navigates somewhere else in the browsers. Then someone came up with a use for this that I had not considered. A wish list item on our bugzilla asked for a way of bookmarking content for later. The example given was the user finding a cool Magnatune.com album, but not having time to actually purchase it right now. While the bookmark manager can certainly be used for this, the fact that you have to manually type in the query to isolate the album or artist that you are interested in is less than optimal. So today, during a very long train ride, I came up with this: Now all albums and artist in all collections (using a nice system I actually implemented to allow the last.fm service to add the "Play Similar Artists from Last.fm" action to all Artists in all collections with out hard-coding anything) have an option to bookmark them. This system does not work in all cases for all services yet (mainly because filtering does not work exactly the same way in all services), but for the local collection, Magnatune and Jamendo, it works perfectly already This will likely make it into Amarok 2.1.0, so even though Amarok 2.0.0 is, in my opinion, already a great player already, development is in no way slowing down, and we have 100's of really cool ideas that we will work on implementing in future versions. I have other git branches with post 2.0.0 features lying around, so depending on the response to this post, I might blog about those later Tuesday, December 2. 2008
Avast, We Be Getting Slandered, Yar Posted by Jeff Mitchell
in jefferai at
18:20
Comments (33) Trackbacks (0) Avast, We Be Getting Slandered, YarPoisonous people. They exist everywhere, sucking the light and good out of things and repurposing them for all sorts of nasty activities. Like the rest of KDE, and the rest of the software world (both free and non-free) in general, the Amarok team has taken its fair share of abuse over the years. Normally I ignore it. However, today I got my KDE 4.0 Release Event talk twisted around in malicious ways and the blame placed right at my own feet. So I'm rising to the bait. The latest perpetrator of bile and venom is one Antal István Miklós. This I'm not going to pick apart all of the technical wrongheadedness he portrays with MySQL/e, Akonadi, and the capabilities therein -- Nikolaj posted a nice response to the blog, and the guy would be very well served to fully read my posting about mysqle (as well as many of the comments). Much of the blog can also easily be decoded as baseless, factless trolling ("amarok1.x is the slowest KDE3 program, if not it's surely in the top 3 slowest KDE3 programs"), and the-developers-don't-agree-with-me-so-they're-wrong syndrome. But I am going to defend my statements at the Release Event. Let me explain, up front, the format of my Release Event talk. I presented a short introduction to Amarok, for those that did not know it. I then stated some drawbacks we found with the KDE3 platform. With these drawbacks, plus a desire to go cross-platform like many other media players (VNC, Banshee, iTunes, etc.), we had considered the possibility of switching to a Qt-only architecture. But then, KDE4 comes along, with elegant solutions to our problems -- Phonon, Solid, Plasma, targeting multiple platforms, and more. Boom -- the thoughts of Qt-only go out of our heads, and we commit ourselves fully to KDE4. Far from a long series of complaints, it's a success story, showing how the benefits the KDE4 platform offer to us solved our problems, and how they could solve yours too. Apparently, however, it simply shows -- from Antal's blog post title, and probably because he hasn't bothered to watch past five minutes in -- how we just don't get KDE4. This may not be apparent to everyone, but Amarok was an early poster child for adoption of many of the Pillars of KDE. We are the only application, to date, that has embedded Plasma inside of our application (with our developers doing a large amount of work to make that possible). (Update: we are technically the first, outside of the plasma workspace, but there are others playing with that now.) Device detection completely relies on Solid (which is one reason Mac and Windows ports have no device support right now). And we have completely standardized on Phonon for our media engine. We've also had Oxygen team members working on our icons and our interface. It's hard to imagine ways for us to more fully integrate with KDE4 than what we are doing. We've gone for KDE4 whole-hog, and it's ludicrous to suggest otherwise. Picking out random Pillars that we don't fully integrate with (yet) does not mean that we are not KDE4-oriented. After all, right now we don't have a use for Marble (who knows? that could change) -- but does that mean we don't get KDE4? it just reminds me of one of the KDE4.0 release event, where a KDE dev complained that how KDE3 sucked, because they couldn't port Amarok to Windows, and KHTML had bad performance It'd be nice for Antal to realize that there is a difference between complaining, and listing drawbacks of a platform. (This doesn't really fit into how trolls work, of course.) Yes, I said that two of KDE3's drawbacks were that it made it impossible to port Amarok to Windows (and Mac) and that KHTML rendering was found to be slow. No, I did not say that KDE3 sucked. But there's nothing new here. It's not like Amarok was alone in wanting to port to other platforms. The Release Event had showcases of KDE4 applications running on both Windows and Mac. But Antal has this fixation that Windows and Mac are suddenly all we care about, taking an out-of-context "consider the majority" statement someone (he doesn't say who) made on IRC about some topic (he doesn't say what, only that it's vaguely somehow about performance): Using mysqle mostly benefits non-KDE4 desktops, because as I said earlier KDE4 will probably have a mysql server anyway, but isn't improving the KDE4 user experiance top release priority anymore? Is amarok on Windows on Mac more important than getting the best out of amarok on KDE4? I think Antal fails to realize that KDE is not just a desktop. Windows and Mac users that might be using Amarok are going to be using lots of KDE technologies in the process. Regardless of his mistake, there is certainly no evidence that Amarok cares more about Windows and Mac users, or thinks them the majority of our users. Speaking as a developer, I can tell you that the exact opposite is true. Antal also clearly doesn't realize that Akonadi is not a requirement of KDE to run (even if it's installed), and therefore the best Amarok could do would be to integrate with Akonadi, but not to depend or rely upon it. Maybe he kind of gets it when he says, my emphasis, "KDE4 will probably have a mysql server anyway" -- we can't rely on probably, or maybe. We need to use what works, always. He even contradicts himself: He begins with complaining, how slow was rendering amarok's context with KHTML, so it looks like performance matters in amarok, not that anyone forced them to use KHTML for rendering context... Make up your mind, Antal. You're right that no one forced us to use KHTML for rendering context, although WebKit wasn't available back then, and hooking into Mozilla was a non-starter. But you want us to be integrating with other KDE technologies...right? One last point: Jeff Mitchell the developer who spoke at the event that I was referring to, referenced KDE as a family, but where is the love now? The lack of communication between Amarok and the rest of KDE4(Akonandi) doens't seem to back up Amarok as being a family member. It is not surprising, given how little he understands of Amarok, KDE, and the integration thereof, that he thinks both that there is a lack of communication between Amarok and the rest of KDE4, and that he implies that Akonadi is the entire rest of KDE4. I've covered a small fraction of the untruths and inaccuracies in his post, but it's enough -- I've made my points. I love KDE, I have not publicly disparaged it, we Amarok developers are fully committed to the platform, and we are not putting the Windows and Mac ports at a higher priority than the *nix base. Any comments will be read, but I may decide not to post them. Continue reading "Avast, We Be Getting Slandered, Yar" |
Amarok LinksCalendarQuicksearchArchivesCategoriesSyndicate This BlogBlog Administration |

