It’s seeming increasingly likely that reports regarding the future of Banshee, Tomboy, and the rest of the Mono stack in the default Ubuntu desktop install are accurate. Ubuntu 12.04 will likely be the first Ubuntu release since 5.10 not to ship with any Mono apps in the default install – ending a run of 12 releases over 6 years. The decision seems to have come about during the “default apps” session at the Ubuntu Developer Summit just ended in Orlando, Florida. Prior to heavy vandalism, the only reasons cited for the change in the UDS session log are “Banshee not well maintained” and “porting music store to GTK3 is blocked on banshee ported to GTK3”. Other reasons mentioned but not in the session logs are complaints that it doesn’t work on ARM.

I’m using a lot of conjecture in this first paragraph because the “news” about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory.

So first, a word on the cited reasoning.

Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I’ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors – the target ARM platform for Canonical’s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware – and none of us owns an ARM system matching Canonical’s target.

That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK#’s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time.

As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself.

I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I’m unconvinced that Rhythmbox is a technically superior app to Banshee – several features which were gained by the first app swap will be lost again – but that’s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced.

Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that’s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don’t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even – and call me crazy – providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical’s target hardware?

And here’s where it gets more astonishing for me – Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn’t think it was worth bothering to perhaps inform him “hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session”.

So I’m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I’m cross that I heard about it from fucking Boycott Novell.

Regardless of your opinions regarding Banshee or its stack, if you read the above and don’t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there’s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono’s book. It’s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading.

[edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it’s a good place for ongoing technical discussion.

129 Responses to “Bansheegeddon”

  1. sir, just apt-get install banshee, problem solved.. i really don’t see the point

  2. @bombo, you might want to read the whole article instead of just the title. Or reread it if you did read through it all.

    The applications in question is not the point, the failure of communication is. I fail to see how apt-get will correct in communication issues.

  3. I don’t use Banshee (I prefer winamp-style players such as deadbeef or audacious), and I certainly don’t dislike Mono. What puzzles me about this change is, despite the removal of Mono and related apps, the default iso will be 750mb in size…after that point I see no reason to not include Mono.

    Furthermore, what packages can possibly bump the default install 50mb above Oneiric, considering the disk savings from Mono’s removal, and that Oneiric includes both GTK2 and 3 already?

    Deeper “political” concerns aside (which are just a facade after all, as Mono, Banshee and everything is still in the repositories, and the software center is very accessible), the raw numbers are kind of odd.

  4. I am just a normal user but I can follow your entire argumentation and think I share at least your astonishment about the decision (especially as ‘appriciation of community’ was such a big topic at uds). I would be very interested to read about reactions from Canonical to this topic. I would appreciate it if you could write a follow up to this if there are news so I could read it at planet.ubuntu.
    I was angry using Banshee quite sometimes for different reasons, maybe because music is one of the most important and used features on Ubuntu for me. But after all I am rather happy with it and like the plus of features compared to rhythmbox.
    So just to leave this here too: I think I noticed quite well how much effort many people invested while getting banshee into Ubuntu and afterwards and I am very thankful for that!!! I hope this can be sorted out somehow and banshee is staying default in 12.04.

  5. @Timo Schneemann, Speaking as an upstream Banshee bug guy, I would welcome your bug reports. and are good resources to ensure that your bug report has the required information to allow for examination and hopefully quick resolution.

  6. @David Nielsen, Thank you very much for the reply. I try to file only as many bug reports as I have time to follow and support eg with further data. At the moment I have already filed three bugs with other programs and fearing send some more if I am not sure I can answer questions following the report.
    Most of the anger I have with banshee is rather not bug-related. For example it starts very, very slow an I have to minimize it two times every start because it pops up not being started completely. And for me as an audiobook-junkie the only partly integration of a special audiobook-area is a little bit annoying while rather not a bug.
    My problem with video-files is maybe a bug. They are only found and shown in menue by Banshee when it is running while I copy a new video-files in the video-folder. I promise to check If something matching this is already filed as a bug.
    Keep up the great work with banshee and thanks again!

  7. @Timo Schneemann,

    Startup time should improve, I think the main cause of being ultra slow in Oneiric is a bug in the U1MS extension (I can’t rightly recall and I don’t have a O box nearby to test with). With that solved (or I suspect the extension disabled) there should be some improvement. There is also the fact that Banshee is executed with Just In Time compilation which does have a cost on startup. Some of that might be able to be shaved by your distribution Ahead Of Tme compiling libraries Banshee depends on. Of course there are other places of possible improvement in that area.

    The Audiobook section, as a audiobook junkie myself, is really subpar I have to say. I have to admit I don’t use it myself for that very reason. You are absolutely right that it should be improved.

    Banshee doesn’t monitor your directories when it is not running, that would require something external to Banshee that was running all the time. Tracker e.g. is a solution that does this which applications can tap into for such functionality. For now, add videos while Banshee is running, long term that is likely something that would need to be solved but it is sadly a non-trivial issue (e.g. having Tracker or a similar solution running all the time can drain battery, lead to unpredictable performance and so on).

  8. @David Nielsen,

    It’s funny how one of you claimed Ubuntu music store was upstreamed as part of rolling out the red carpet for Ubuntu, with no objections, and now that they’re dropping Banshee, you turn around and blame its abysmal startup time on the extension you upstreamed without saying “Hey this sucks, fix it”.

    It seems to be a case of convenient timing.

    Banshee has never been real fast at starting up on any platform or distribution I’ve tried it on. That’s IF it started up at all or didn’t have some weird crash bug that should have never gone unnoticed before reaching a stable build. (Remember when it crashed just because you clicked on Now Playing?)

    Banshee is garbage.

  9. As a C# developer I am disappointed by the decision. But I disagree with you on the assumption that just because it is not shipped in the default install that it doesn’t matter. Banshee is a great music player. Many people used Banshee on Ubuntu it before it became default. The work that has gone into is far from a waste. I understand your initial emotional reaction to this news but UDS has only just finished. Many decisions can be refined, reversed and discussed further.

  10. I don’t know how much this was known in advance to the default apps session. I’m pretty sure many within Canonical where pretty surprised at this decision. I even heard some say things like “even though Rhthymbox is the worst piece of software ever written in history” and things like that. My understanding is that moving towards away from GTK2 and removing Mono, purely for the saved disk space, where the two driving factors, and the decision to do this was not made before this session.
    It’s too bad that this session wasn’t video taped. I wonder if the audio stream is around anywhere for download.
    The decision definitely wasn’t aimed at Mono specifically for any of the reasons the boycott Novell people cite. It was all about library consolidation.

  11. @maxolasersquad, yes, the audio is available,

  12. I’ve been against Banshee since the first release. I could care less about mono. But it’s spelted Ban Sidhe and plus there are all the stereotypes that the difference in spelling creates.

    So I knew the Banshee people were evil…EVIL muahahahah! Er wait..

    Anyhow thats as good a reason as hating Mono.

  13. Not to add fuel to the fire…. but this has got me thinking about the U1MS.

    I really have to wonder what the roadmap is for U1MS.
    If I’m reading the launchpad material correctly….
    The rhythmbox u1ms plugin doesn’t work in 11.10 and the bugreport has been marked as won’t fix.

    Also looking at the code revision history the development of the plugin itself appears to have been dormant for months now. Only automatic translation updates in trunk.

    Is this correct? Is the rhythmbox u1ms plugin effectively dead for 11.10 and has seen no active development in trunk at all for 6+ months?

    If my observations are correct it really begs the question, is Canonical planning on shuttering its U1MS service entirely in the 12.04 timeframe? I don’t understand, from a business perspective, how they can revert to rhythmbox when they’ve let the U1MS plugin bitrot for as long as they have. It seems to me that the least expensive option to keep U1MS viable is to help fix that gtk# bug that is biting banshee. But if they have given up on U1MS entirely, then the decision appears more reasonable as a business decision (if it costs Canonical less in staffed manpower to switch than to fix.)

    In the scope of U1MS as it currently stands, the decision is a head scratcher. There is a piece of information missing. Was U1MS discussed at all during this UDS?


  14. @Jef Spaleta,
    U1MS doesn’t work with Rhythmbox because it is a GTK+ 2 widget and Rhythmbox has been ported to GTK+ 3. Mixing different GTK+ major versions in one process is a big no-no.
    Of course, porting U1MS to GTK+ 3 would mean it wouldn’t work anymore with the current version of Banshee…

  15. @Bertrand,

    Now see that’s even more of a head scratcher. The _lack_ of a gtk3 port to banshee is a stated reason to punt banshee as default. That would imply to me there is a gtk3 U1MS plugin in active development somewhere. I didn’t fin that somewhere. Can you point me to a launchpad tree with _any_ active gtk3 plugin development that is suitable for gtk3 based rhythmbox?


  16. @Jef Spaleta,
    I don’t know anything about the current status of a port of U1MS to GTK+ 3.
    My guess is that they were waiting for the default media player to be GTK+ 3 based, and that it is going to happen during this cycle.

    Disclaimer: I’m a Banshee developer 🙂

  17. @Bertrand, It was mentioned during the session that porting U1MS to GTK3 is a couple of hours work (plus the inevitable bugfixing), but the Ubuntu One team didn’t want to support building both a GTK2 and GTK3 version of the lib.

  18. @Jef Spaleta,

    I am not aware of any plans to close the U1MS; as far as I am aware it remains a key Ubuntu One service. I think the U1 team are just going to swallow the development overhead to deliver it in RB.

  19. @Jono Bacon,

    Not to be a broken record or anything. But can you _please_ point me to the gtk3 code branch or failing that a blueprint for the gtk3 based plugin deliverable for rhythmbox. Anything _publicly_ archived concerning roadmapping that does not come down to Canonical watercooler discussions among employees. Anything in the public record at all please with regard to plans for gtk3 based plugin development this cycle.


  20. @Jef Spaleta,

    I wasn’t involved in the discussions, so I am unaware of the blueprint or of any code branches. I have pinged the Ubuntu One team to see if they can respond.

  21. @Jono Bacon,

    Right “not a part of the discussion.” I didn’t expect that you were, but you felt compelled to answer _before_ you got concrete information to share instead of word of mouth. Stop that before it becomes a habit, and you end up having to go on meds because you’ve consuming too much fatty foot tissue. Feet do taste good, but you need to think about your overall health and cut back a weebit. Consider eating something healthier instead like a Beefy Miracle.


  22. @Jef Spaleta, There is an educational equivalence bug in your logic. The GTK# issues require a much more highly trained developer than the U1MS Gtk3 port and I don’t know if Canonical have access to the talent to do the former.

    Not all developers are created equally, I wish more Canonical peeps were Kernel hackers, much to my disappointment 😉

  23. @Martin Owens, there is no need to be so condescending.

    The bug in question is pretty well documented. However, whether it is fixed or not, doesn’t change the facts. Much of the underlying platform on which Banshee depends on, is not currently well maintained; and it is not particularly well architected, nor are there any concrete plans to follow the direction of upstream GTK+/GNOME in terms of bindings technology. Fixing the one bug may make the GTK+ 3.x port work, but I would hardly call it a stable platform on which to build the future. It still really needs a lot of work, which almost certainly is not going to be done within the next 4 months.

  24. @Rodney Dawes, There is no condensation and I’m getting tired of your nastiness Rodney.

    I’m not even a fan of Mono or Banshee, I can’t believe you would feel the need to defend the decision to me of all people.

  25. @Martin Owens, you were condescending. This quote is condescending:

    “There is an educational equivalence bug in your logic. The GTK# issues require a much more highly trained developer than the U1MS Gtk3 port and I don’t know if Canonical have access to the talent to do the former.”

    There is no “nastiness” in my post. I simply stated facts, rather than making an ad hominom about the skills of developers. Nor am I defending the Rhythmbox v. Banshee decision to you. I am explaining further the issues surrounding a specific bug, on a comment, on a publicly visible blog, so that perhaps yourself, as well as anyone else, may come to a greater understanding of the issues involved. Simply put, I was refuting your condescending statement about the skills of myself, and hundreds of other developers.

  26. @Rodney Dawes, We would love to use GObject-Introspection to generate bindings and in fact we did have an entire hackfest with the aim to create the tools for such an undertaking. However the fact sadly remains that for .NET (and Java) bindings to be generatable using gir additional annotations to the gir format will be needed. Upstream gir seems to be aware of these needs but are AFAIK uninterested in assisting in resolving the situation.

    It is a really sad situation overall and it would be fantastic to finally get it resolved so that we might move away from our current gapi based bindings which are admittedly less than optimal in a number of cases.

    What is really needed is to sit people from both camps with in depth knowledge in a room but so far any attempt at doing that has failed. It is one of my dearest hopes that GNOME will eventually be able to step in to help.

    So not a reluctance to move to the new GNOME3 tooling, a technical hinderance which needs to be resolved not by Mono people but by GNOME3 tooling people (well in honesty in cooperation between the two).

  27. @Martin Owens,

    I acknowledge what your saying to some degree. If Canonical needs a tighter more integrated..coherent..stack..they should probably lay the framework for that..make some well communicated decisions on what the supported stack is, and then pick/build applications that conform to that stack.

    But Martin, so far that’s not the case. The fact that Unity2D depends on qt says Canonical still doesn’t really have a plan or the discipline for a coherent stack.. a stack they can advertise to app developers. They are still driving the bus in opportunistic mode.

    I’m trying really hard to bite my tongue with regard to the pressing need to throw out mono (and banshee as a result). I’m no fan of mono as a stack either. But this feels like this discussion is running backwards. If mono as a technology is now viewed as unsustainable there should be a discussion about _that_ instead of banshee specifically. Banshee developers can’t adequately argue the viability of mono, the upstream mono devs will need to be pinged as well.

    The more Rodney is poked in the eye and talking about the structural integrity of mono as a supportable stack, the more clarity is needed on whether Canonical is planning to provide lsupported ibubuntuone bindings for mono in the gtk3 port of libubuntuone.

    If Canonical is dropping support for those bindings, all of this is essentially pointless. We all know banshee won’t be the default if U1MS wont be available as a workable option. And unless I’m misunderstanding things, mono bindings as provided in libubuntuone are critical for continued operation of the U1MS store in the banshee codebase.


  28. @Jef Spaleta, I can agree with that.

  29. I’m a normal User and I’m very upset by your reaction. How selfish are you ? you now complain against the made decision, but what has Gnome done when Rhythmbox was remove ? you should be fair. Gnome could have done the same as you do now, but they were fair. Just be fair. Decision had to be taken. first time it was Rhythmbox and now it is Banshee. your user base will still continue to use Banshee

  30. @Shindz, A fairly key difference is that Rhythmbox is maintained in Ubuntu by a Canonical employee, not by community volunteers. Other than that, it’s worth noting that the decision to move to Banshee was first widely reported in mid 2009 dependent upon a set of technical improvements in Banshee, and the assumption of zero progress in Rhythmbox – those technical requirements were met in late 2010 along with zero progress in Rhythmbox. Was there any further communication from Canonical to the Rhythmbox team? I don’t know. But it was hardly a snap decision between “this is the right move” and “we’re enacting it”

  31. @Shindz, Your reaction makes no sense to me. You should be knowing that both Rhythmbox and Banshee are hosted on gnome infrastructure.

    Why do you think Rhytmbox removal should have upset gnome people? If they were upset by Rhytmbox removal then they should be upset by Banshee removal too.
    I am not sure, but doubt that Rhytmbox is part of GNOME release process.

  32. I’m not a huge fan of Banshee because of its sluggishness and instability, but you raise an incredibly important point about the way Canonical treats the teams creating its applications. Another point I’d like to add is about continuity. Applications need to be kept consistent. A music player does not suffer so much because interfaces are quite similar across the board, music libraries are recreated without a fuss and it is largely accessed through either the Dash or the Sound Menu; however, people who jumped on to Ubuntu in Oneiric or Natty may be surprised to see applications switched around. The bigger issue in this regard is Tomboy: is Gnote going to be shipped? Is there a migratory path for notes stored locally and on U1? Nobody’s answering these questions.

    @Anon- The 750MB thing is just a cap. Several developers including Bilal Akhtar have said that with the removal of Mono, it is quite likely that the final Precise release will be under 700MB in size.

  33. My only words against Banshee. It hangs for me 5 times a day…
    P.S. I am not sure for the reason of that and maybe the fix is already committed but it does not work for me…only for the very reason i was clapping at UDS over the decision.

  34. @Omer Akram,

    Do I need to point you to – at least telling us about your problem in the form of a bug report (with a debug log attached) is infinitely more productive than complaining in a blog comment.

  35. @Jef Spaleta, the music store isn’t going anywhere. The fact that there is no rhythmbox plug-in for it in 11.10, and the bug being marked won’t fix, is more the result of what /is/ in 11.10 than anything. The burden of having both was just not acceptable as we’d have to ship it twice, built against two separate toolkit/webkit stacks.

    The U1 Music Store will also be significantly better in 12.04, on the whole.

  36. @Rodney Dawes,

    Great. Can you _please_ point me to the code branch in launchpad where the active development on the rbox plugin is ongoing?

  37. @Jef Spaleta, lp:rhythmbox-ubuntuone and lp:libubuntune is where the magic will happen. Fixing the rhythmbox plug-in side itself is quite trivial, as it’s basically already ported to the introspected API in RB. The libubuntuone code where the bulk of things happen though, needs a bit more work; but not too much.

  38. @Rodney Dawes,

    Are there plans to do the work necessary to keep the mono
    bindings as part of the new liboneubuntu?


  39. @Jef Spaleta, those bindings are automatically generated, so shouldn’t stop working, really. Though, it’s probably better to drop them and only have the gobject-introspection bindings. It’s not entirely clear what the best route for mono bindings is at the moment, as the platform (gtk#, etc) is not very well maintained for now.

  40. @Rodney Dawes,

    So mono binding support in the 12.04 timeframe for libubuntuone is an unknown at this point? Why does the U1 team plan to make a final decision on supporting mono bindings?

    Uhm to be fair to the banshee developers who depend on them to keep the U1store plugin working…shouldn’t know…make a decision on that soon..and communicate that decision so they can know whether or not to drop that extension from their upcoming releases? Only fair right? Isn’t this exactly the sort of decision that should be made tenatively at UDS and communicated via bleuprint proposals?


  41. @Jef Spaleta, don’t you think the Banshee developers should have perhaps asked the people working on the U1MS extension where they wanted it to be hosted/released from? Having code you’re actively working on suddenly disappear out from under you is not a pleasant surprise to wake up to one morning.

    Maybe you should ask the person who is actively working on that extension, what he wants to do with it, rather than making poor assumptions about the status of everything.

  42. @Rodney Dawes,

    I’m not making any assumptions I’m asking questions. Questions whose answers should already be in a blueprint somewhere and publicly accessible. If you aren’t the right person to be answering them feel free to stop providing misleading information. And better yet get the right person to document the roadmap somewhere where I can read it. You know who that person is.


  43. @Jef Spaleta, you are making assumptions and asking pointless questions based on those assumptions. Rather than trying to spread FUD by doing so, you could have done the tiniest bit of research to determine that perhaps I am not the person to try and have such unfounded and pointless argument with.

    All of these “questions” you are “asking” about the U1 music store extension are completely unrelated to which app is the default in Ubuntu. And whether the bindings are gapi generated, or just introspected via gir, is even doubly irrelevant. There doesn’t need to be a roadmap or blueprint for it; and it doesn’t need to be discussed here.

  44. @Rodney Dawes,

    Pointless questions? Wasn’t the reason why banshee removal as default was brought up at all in this session was because of the gtk3 blocker issue associated specifically with libubuntuone? That’s what I got from the audio after hearing it. Am I wrong about the stated reason in the audio? Which person in the room put banshee on the agenda for discussion for removal?

    There is a communication breakdown here with regard to established requirements that a music player must meet. Clearly gtk3 is one of those requirements because libubuntuone is planned to be ported to gtk3 and the U1MS is a required deliverable. Would you disagree with that statement? Do you feel that was adequately communicated as a requirement ahead of this UDS session?

    Until the gtk3# bug that is preventing banshee from being ported is fixed, then banshee can’t be the default..given those requirements. I think the banshee proponents would have to reluctantly agree with that because they know Ubuntu isn’t going to ditch the U1MS.

    So if the bug is fixed then banshee is still a viable default _assuming_ the mono bindings for libubuntuone are going to continue to be supported. And I refuse to make that assumption, so I’ve asking for clarification on that.


  45. @Jef Spaleta, you seem to be assuming that GTK# is and will continue to be supported. However, that is not the case. The current maintainer doesn’t have time to put into getting it up to date and maintaining it. And the fixes to get it basically working enough for Banshee to use are pretty much stop-gap fixes to make it usable on GTK+ 3.x. They are not a sustainable path for future maintenance and development as a platform. How mono bindings are dealt with for libubuntuone is basically irrelevant to the discussion. The default player is the one that has to get support, as evidenced by the lack of support for Rhythmbox in 11.10.

    There was a communication breakdown, indeed. And the bringing up of Rhythmbox at the UDS session was to resolve that confusion, that has existed over the past several months. The confusion was on who was blocking on who for U1 to have a GTK+ 3.x based solution. Had that confusion been worked out 4 months ago, then Rhythmbox would probably have been the default for Ubuntu 11.10 anyway, and there wouldn’t have been a need to discuss it at UDS.

    The only requirement for U1MS, is that it has to work in the default player. Beyond that, anything else is extra. To get GTK+ 2.x off the CD, we would need a GTK+ 3.x based player as the default. Currently, the only real option here is Rhythmbox.

  46. @Jef Spaleta,

    Let’s be clear. When you say GTk# maintainer. Do you mean the upstream maintainer or the package maintainer in the scope of Ubuntu packaging work?

    And did you learn all of this via private undocumented discussion, or is any of what you said publicly documented somewhere in their own words? Not calling you a lair..but we are in a “game of telephone” situation here and clarity demands some authoritative documented sources from the person(s) whom you are speaking on behalf of.


  47. @Jef Spaleta,


    I just want to be as crystal clear on this as possible,

    In your view, the need to move libubuntuone to a gtk3-only codebase was compelling enough 4 months ago to merit _not_ having a public discussion on this at all? You would have just flipped the switch to rbox based solely on the U1’s team desire to move to gtk3 and ditch gtk2?


  48. @Jef Spaleta, when I say GTK# I mean upstream. If the GTK+ 2.x based version continues to be well packaged, it is irrelevant to the support of GTK+ 3.x, and stability issues which may ensue.

    The desire to move to GTK+ 3.x is not the U1 team’s, but the Ubuntu distribution. If the default media player was written in Qt, we’d still need to provide support for it. However, the default would be the priority. In the GTK+ world, moving to GTK+ 3.x is going to have to happen at some point. It would be better to do it earlier, than at the last minute in an LTS cycle that has to be supported for 5 years.

    And no, these discussions _were_ public. Just because you weren’t in the IRC channel at the time, doesn’t mean it wasn’t. The state of affairs with GTK# has been discussed on #banshee multiple times, and gtk3/gtk2 wrt rb/banshee were discussed in #ubuntu-desktop. No, I don’t remember when exactly or have logs, nor do I know who does necessarily have logs.

  49. Rodney,

    I’m sure there were IRC discussions. But please understand that referencing them just adds to the “telephone game” problem.

    So in my continuing effort to get past the “telephone game” the maintainer from IRC that you are referring to whom can corroborate your memory of a conversation about the suitability and timeliness of gtk# being ported to gkt3 is Gabriel Burt?

    If you can’t locate actual archived logs, then the next best thing is to find the upstream devs with whom you were having the discussion and get them to corroborate.


  50. @Jef Spaleta, I guess you had to be there.

    No, Gabriel does not maintain GTK#. I don’t remember who exactly was in that conversation. Basically, it was relayed that mkestner doesn’t have much time to put into gtk-sharp now. And “telephone” or not (you can stop using that reference I made now, btw), a full and proper port to the new GTK+ bindings architecture is going to take much longer than 4 months.

  51. Rodney.

    1) You can’t locate archived discussion where concerns over gtk# were talked over.

    2) You can’t remember with whom you actually spoke with.

    3) Anyone who is trying to understand your view and how things evolved to this point now about the difficulties facing gtk# “had to be there.”

    Oh no sir, you were exactly right. “Telephone game” is exactly the analogy that is appropriate. Don’t sell yourself short. You nailed it. Snark or no, you nailed it.

    What is needed now is for someone to ping gtk# upstream and see if they can commit to a release within a workable deadline. It would be good if someone would stick their neck out and go on record and define what an acceptable deadline is.


  52. @Jef Spaleta,

    1) AFAIK, #banshee is not logged by a bot. I don’t log it. If anyone else does, or know where any logs are with the conversation, they are free to post.

    2) I remember the important bits, not the meaningless ones. And I didn’t speak with anyone. I read the text in my IRC window at the time, which was pertinent to the work I was doing. Do you remember everything that was said in every IRC channel you’re sitting in, from 4+ months ago? Neither does anyone else.

    3) By Anyone I must presume you mean yourself.

    You still completely ignore what was said, and are looking to badger and try to push your self-centered agenda with your comments. Making a release of GTK# that “works” with GTK+ 3.x isn’t enough. It needs consistent releases. And it needs work to move forward in the direction of using gobject-introspection, as the rest of the world has. If the argument against Rhythmbox not having consistent releases is that its last release was 8 months ago, well gtk-sharp was last released almost 2 years ago (March 2010).

    Are you volunteering to maintain gtk-sharp, get it moved onto gobject-introspection, get banshee/tomboy ported, make timed and consistent releases, and do the necessary testing to ensure stability? I’m not. I don’t have the time/want/need to do it. And even if I did, it would simply be faster and easier, for me to just write a new media player in Vala, that is already more stable and has better features and integration with the system. If nobody else has the time/want/need to see the maintainership of gtk# and the rest of the various underlying platform pieces that Banshee depends on through to the future, then there’s no point arguing about it.

  53. @Rodney Dawes, We specifically moved the U1MS extension on a request from one of the Canonical people.

    They were concerned that keeping U1MS in BCE would mean that all of BCE needed to be in Ubuntu Main, which again meant that they would be stuck with supporting every extension and their dependencies (including things like the Tao Framework). A state Ubuntu were not happy with. As a favor to get that resolved Banshee moved the U1MS extension from it’s prior life in BCE.

    As for GAPI vs. GIR, the sad reality is that GIR is not suitable for generating proper .NET (or Java) bindings. The format needs additional annotations, upstream GIR are aware of this but have elected so far to ignore any such concerns. That is one reason why GTK#3 is such a problem right now, we are still using GAPI since we cannot rely on GIR to generate bindings. Help getting communication working with GIR upstream about the needs of platforms such as .NET and Java would be most valuable.

  54. @David Nielsen, I know why it was moved. However, the people actually working on the extension at Canonical, were not consulted about it. I had no idea it was being moved, until after the move was done. And that was while I was actively working on a set of changes to it. Simply trying to justify its movement based on the request of a discussion on the Ubuntu Platform team which didn’t involve the person working on the thing, is very hypocritical of the very argument you are trying to make about the current discussion of switching back to Rhythmbox.

  55. @Rodney Dawes, as an outsider and only going on the information in this thread, to be honest whilst I can appreciate it would be annoying for your upstream VCS repo to suddenly disappear, I’d have thought Canonical’s governance would be good enough that if one person had requested the change, the other folks were already aware of it. And so far as I can see no code was lost… I don’t think there’s any justification for harbouring any resentment of the banshee team.

  56. @Jon, I am not harbouring any resentment. The plans for the U1MS extension will go forward regardless of which player is the default. I quickly moved past the ignorance of the changes made that affected my workload, and got on with life. I didn’t go attempt to spawn a whole thread of hate against the offending party, as David seems to be doing. Moving that code was not a decision of Canonical. It was the result of some small discussion at UDS, in which the Ubuntu One developer working on the extension, was not involved. The circumstances surrounding the move of that code from BCE to Banshee are basically an exact replica of the circumstances involving the discussion of Rhythmbox as a default for 12.04.

    I am simply making the point that David’s resentment is hypocritical, as Banshee isn’t the pinnacle of perfection either. Acting like it is, and trying to play the sad puppy card, is just annoying. While I’m sure the contributions he has made with bug triage and such are greatly appreciated, he is not a core developer as his blog/g+ posts seem to try and make him out to be. He acts like Banshee is his personal baby, and that he has a very vested interest in it being the default player in Ubuntu, which are just not true. As a user, I’m sure he’s upset; but life is full of unexpected changes.

  57. @Rodney Dawes, That is an issue you will have to take up with your manager. From the Banshee point of view it was asked that such a move was made by Ubuntu and we have to assume that the person assigned to contact us speaks with authority on the matter.

    A lack of debate between the different departments at Ubuntu surely isn’t my fault, I don’t see why you are so personally upset with me nor why you claim I spread hate.

    The fact regardless of your apparent unhappiness with the move, is that it happened solely because of a request by our Ubuntu contact person, to solve a problem for Ubuntu. That is Banshee doing Ubuntu a solid, if you are unhappy with that assertion I really think that is a problem to take to your manager not me. If only to let your concerns over this be noted for any future such interactions with potential default applications where Ubuntu developers have a stake.

  58. Banshee did not work for us on most ARM hw tested in 11.10.

    Unfortunately we only tested and caught the issue towards the end of the cycle, even if it probably manifested itself much earlier, probably after the 2.10 transition.
    So beagleboard, freescale mx53, panda, tegra2 based ac100.
    See for details.
    It has since been fixed upstream.

    It was definitely not OMAP4 specific – at least not this bug.
    We have toolchain and build options different from Debian or Xamarin’s Android targets and it is possible that this is the cause of the issue. And at least in the last when asking in #mono and #debian-mono when encountering issues, we most of the times got ‘works for me on Debian’ or ‘fix your toolchain bugs’ and less often actual debugging from people intimately familiar with mono or banshee.

  59. @jani, Please do not file bugs against Ubuntu if you want upstream Banshee to look at the issue.

    We also have very poor access to ARM hardware. So poor in fact that I have personally had to sponsor a Genesi smarttop to one of our developers just so someone with deep knowledge of Banshee would be capable of working on such issues. Also Andrew Wafaa of openSUSE has kindly offered to do testing on his array of ARM porting hardware (and has confirmed the OMAP4 bug on a Linaro build). It would be a great help if Ubuntu could sponsor a PandaBoard to one of our developers.

  60. @David Nielsen, do you still need Pandaboards? That seems like a good fundraising / sponsorship goal. Are the relevant devs located in countries easy enough to ship to? Would the forthcoming Raspberry Pi help here, or do you think the Panda is really the key target?

  61. Maybe because Mark Shuttleworth announced that they will be soon on smartphones and tablets.
    Microsoft is asking money to all the companies shipping with Android, maybe he thinks that having Mono could scare hardware companies to choose his OS.

  62. @Marco, maybe. Without a more transparent announcement, all we have is conjecture.

  63. Hi Jo,

    I can understand your concerns, and I am going add a caveat to this comment that I was not involved in either the decision or the discussion, but just wanted to offer some general points.

    Ubuntu has always set out to ship the best and the brightest in the Open Source world, and this involves picking what we as a project feel are the best apps for our users. With the elastic nature of Open Source…with maintainers coming and going, codebases becoming active and inactive, these decisions naturally change from time to time. I wish we had a world where we could pick one app and stick with it, but Canonical does not have the resources to fund development of all the apps with ship on the disc to ensure they remain the same.

    From what I can tell, there is a feeling that Banshee upstream is less active than it was, and there have been some quality concerns expressed (speaking personally, as a huge Banshee fan, I found it’s quality worse than RB in 11.10, and I did file bugs for my issues), and I think these elements contributed to the decision.

    Of course, there is a wonderful community of Ubuntu contributors who help to make Banshee rock in Ubuntu, but I suspect that the concerns lie less with these contributors as opposed to upstream activity, particularly with this release being a 12.04 LTS release.

    Of course, nothing is ever final in Ubuntu, and if Banshee upstream re-stokes the fire, I see no reason why the pendulum could swing back in a future release.


  64. @Jono Bacon,

    Considering you are the community manager, I feel your reply focused too much on your personal conjectures about why the decision was made and less on the core of the article, which is the failure in communication.

    The only slightly on-topic point you raised was availability of resources, but that only applies to the ARM subject. It does not apply to much cheaper things like, you know, sending an email to the Banshee developers before the UDS.

  65. @Conscious User,

    As far as I am aware there was no prepared plans to remove Banshee drawn before UDS.

  66. @Jono Bacon,

    It sounds very unlikely that *no* Banshee developer or maintainer was available at an IRC channel at that time, or would read an email before the session ended.

  67. @Jono Bacon, Jono, you say you have reported the bugs you found in Banshee, and I just did a quick query on BGO, to not find anything. Can you point me the mistake I’m doing when searching? Thanks

  68. @Andrés G. Aragoneses,

    I saw some bugs, but I think they were already reported. I did report though.

  69. @Jono Bacon, Please do file bugs upstream if you intend them to be fixed Jono. You cannot expect any upstream to trawl through every downstream bugtracker, that would be unreasonable.

  70. @David Nielsen, should perhaps the downstream packagers do the work here? (I do for most of my Debian bug reports)

  71. @Jon, yes, and they do. And pretty much all of the upstreamed bugs include a link to the original report on Launchpad as well. There are a lot of Banshee bugs which have been upstreamed from Launchpad.

  72. I knew I would hit Submit too soon.

    I think the other point is that what comes by default on the disc really doesn’t matter as much as it did. The Ubuntu Software Center shines a lens on the wonderful tapestry of Free and Paid For software available for the platform.

    If Banshee doesn’t ship on the disc, it would not surprise me if it becomes a hugely popular option in the software center.

  73. @Jono Bacon,
    With a dormant RB development I suggest to get rid of it/not include at all.
    The movie player can provide the live CD playing of tunes.

    Once installed the software centre will jump in.

    To me this reads as if somehow the UDS session got hijacked by the banshee replacement topic although there where no plans or intentions beforehand to replace it. Things where said and the internet took it from there.

  74. To be clear, there was no plan ahead of UDS to switch Banshee back to Rhythmbox. The concerns I heard coming out of the session (I wasn’t there, so this is based on later discussion) were that Banshee seems to be unresponsive to patches from Ubuntu. (Agreed that “not maintained” isn’t a good way to phrase that, but please forgive the volunteer notetaker, whoever they were.) No clear idea why Banshee is unresponsive, maybe they’re just busy with other things. But, it’s also possible that they’re unhappy with the affiliate deal, don’t feel like they can do anything about it, and so are quietly dropping Ubuntu patches. If so, the best thing we can do is let them go and move on.

    This isn’t some kind of big planned change, it’s an idea that started at UDS, like many ideas do. There are a lot of unknowns here. Rhythmbox has some recognized usability issues, so if it became the new default, there would need to be some substantial work put into it over the next 6 months. One of the considerations in switching to Banshee in the first place was that the Rhythmbox developers said they weren’t planning on continuing an active development schedule (notice the last release of Rhythmbox was Jan 2011). So, work needs to be done, and it’s not yet clear who would do it. In general, Ubuntu tries to avoid changing default applications during an LTS development cycle, so the natural inclination will be to stick with Banshee. CD space is a real concern, though, and every cycle sees some tough cuts made to meet the size restriction.

    Don’t take this as an edict from the Ubuntu community members who attended UDS (both volunteer and paid). Take it as the start of discussion and planning that will cross multiple teams, upstreams, and downstreams.

  75. @Allison Randal,

    Bashee less responsive to Canonical pathes than rhythmbox? Wow are you sure you want to make that suggestion based on private off-the-record conversations? Are you _sure_ you want to be on the hook for making that statement in a publicly archived space? Really? I’m not sure the public historic record supports that..especially considering that banshee upstream included the U1MS store into their core offering instead of as a community extension.

    The perceived lack of forewarning and communication in this situation is bad enough as it is. Don’t make it worse with a suggestion of “upstream is unresponsive” just because its an easy card to play after the fact. But hey… your call. Can you point me to specific bugs and specific patches you personally believe were mishandled by upstream?


  76. Dropping the insinuation that the revenue episode might have something to do with it is also questionable to say the least.

  77. @Jef Spaleta,

    I believe it’s important to publicly acknowledge when you’ve made a mistake and seek the best path to make up for it. Canonical did make a mistake, and then tried to find a solution that worked. But, I wouldn’t blame the Banshee developers if they were less-than-motivated to work on patches from Ubuntu, I don’t think anyone would blame them. The Banshee developers aren’t on trial. It’s clear they’re doing great work on Banshee. Really, the Banshee developers are the only people who can say whether they want to be an Ubuntu default or not. Everyone else is just guessing (that includes me).

  78. @Allison Randal,

    How this turn into a guessing game about motivation? You are walking yourself deeper and deeper into trouble and you don’t even realize it.

    Fact 1:
    There is a bug in gtk# that is delaying a port of banshee to gtk3. Help is needed to pin it down and fix it.
    Fact 2:
    Canonical wants to only support one version of libubuntuone based on gtk3 and kick gtk2 to the curb.

    Canonical could _help_ find the gtk# bug and kill it dead and earn some pretty sweet street cred in the process.

    If on the other hand banshee does not get ported to gtk3 the U1MS store plugin in banshee will have to load a libunbuntuone that is gtk3 based as Canonical will not be making available the gtk2 version any longer. I have no idea if this is a technical non-starter, having an app load both gtk2 and gtk3..but it seems like a really bad idea.

    You don’t need to walk yourself into any discussion about whether past actions where demotivational for current collaboration. This whole line of discussion you have brought up is completely full of fail. There’s no walking out of it with a positive outcome.

    Right here…right now..there is a bug.. a subtle bug in the gtk3# stack that needs to be fixed by someone. If it gets fixed in time for 12.04 every stakeholder comes up a winner. Banshee can be a default option without having to suck in gtk2. If it doesn’t, U1MS integration in banshee is potentially jeopardized because of needing gtk2 and gtk3 to run the app+plugin. And if that happens then I’m the only person who benefits (because I’ve made some private wagers in the past about Canonical’s long term interest in mono that are going to pay off big for me).


  79. @Jef Spaleta, This isn’t a Canonical decision, it’s an Ubuntu project decision. I suspect Canonical would generally prefer sticking with Banshee, because they wouldn’t need to invest developer time in moving over all the U1 and Music Lens integration.

  80. @Allison Randal,

    Who was in the room making the decision? Who specifically is the person in the audio talking about a lack of upstream support? Who is the person talking about U1 blocking on gtk3 default music app?

    Was the move from banshee even listed in the blueprint prior to UDS to give notice this was even on the table? If not why not?

    Was the package maintainer for banshee in the room? Or on remote? if not why not? Was anyone from upstream banshee or the mono stack in the room or on remote? if not why not?


  81. @Jef Spaleta, No decision was made in the room, it is still ongoing, and probably won’t be made until Alpha2 or later (similar to the Thunderbird decision last cycle). I don’t know who the various speakers were, I wasn’t there. And no one asked the Banshee or Rhythmbox developers to show up for the session, because no one knew ahead of time that it was going to come up as a topic: it wasn’t planned, wasn’t on the blueprint.

  82. @Allison Randal,

    Do you understand the failure there? If it wasn’t on the blueprint why was it appropriate for it to be discussed there before giving the people who have the ability to respond to concerns a chance to be in the discussion. Cart before the horse.

  83. @Jef Spaleta, In a session specifically planned to discuss the “Default Apps”, it’s fair to talk about any of the default apps. It’s also fair to recognize that a new idea started in the session needs more information collected, and further discussion with relevant stakeholders. Which is exactly what happened.

    Sebastien Bacher just posted an insightful summary on the ubuntu-desktop list, outlining the core technical questions in the Banshee/Rhythmbox decision:

  84. @Jef Spaleta, most of the discussion about U1 blocking on default music store app for gtk3 support, was probably pitti and myself.

  85. @Rodney Dawes,

    Is a detailed summary of those concerns about blocking published anywhere publicly? Or are these concerns basically bouncing around the Canonical watercooler and its just assumed that external contributors know where the pain points are in the libubuntuone roadmap? This is the sort of stuff that needs to be written down for public consumption ahead of go-no-go meetings.


  86. @Jef Spaleta, no. If by “watercooler” you mean “Atlantic ocean and public IRC channels” then sure, I guess it was a watercooler discussion. Do you have a relevant point to make, or are you just trying to further your own agenda by trolling? What “external contributors” are you talking about?

  87. @Jef Spaleta,
    After reading every one of your replies on this article, I feel that you need someone to tell you that you need to work on your people skill, rather badly. You’re basically the most obnoxious person I’ve seen online for months, and I’m a Slashdot reader.

    Calm down and ask real questions in a real form instead of leading the discussion to your obviously sore spot.

  88. @Allison Randal, in regards to your assertion of “upstream being unresponsive to Ubuntu patches”, can you point a single URL of a patch developed by Ubuntu contributors not included in upstream?
    Because I don’t remember anyone.


  89. @Andrés G. Aragoneses, I haven’t looked into it in detail. But, one lesson I’ve learned as a software architect is not to ignore a concern that’s been brought to my attention independently by multiple experienced members of a project. At the very least, if Banshee continues as default, the Ubuntu project will need to actively work on improving communication channels with them as an upstream.

  90. @Allison Randal,
    > The concerns I heard coming out of the session (I wasn’t
    > there, so this is based on later discussion) were that
    > Banshee seems to be unresponsive to patches from Ubuntu.

    I am the package maintainer for Banshee. If there were patches that Canonical/Ubuntu wanted in Banshee, then why didn’t I hear about them? If upstream Banshee was unresponsive to patches from Ubuntu, we could have shipped them downstream, or they could have been brought up to my notice so that I could poke people on IRC.

    > (Agreed that “not maintained” isn’t a good way to phrase that, but please
    > forgive the volunteer notetaker, whoever they were.)

    It wasn’t the notetaker’s fault, whoever they were. Someone mentioned that Banshee was unmaintained in the audio track. I have no idea who he was though, but I would be personally interested in hearing from him, to know where this is coming from. It sounded like it was coming from someone whose pet bug didn’t get enough attention, which happens all the time in other main packages as well.

    > But, it’s also possible that they’re unhappy with the affiliate deal, don’t
    > feel like they can do anything about it, and so are quietly dropping Ubuntu
    > patches.

    Now, seriously, if you actually look at the noise made during the Amazon decision, you would have noticed that it was coming mostly from Banshee users, not the upstream developers. I have personally sensed no hostility from the upstream myself, so it would be nice if you dropped that idea altogether.

  91. @Chow Loong Jin,

    “Someone mentioned that Banshee was unmaintained in the audio track.”

    I don’t know who it was, but I suggest that the healthy way to handle this is not to go after the person with bad information (who may have simply been misinformed), but instead to participate in a reasoned conversation on which application makes the most sense as default in Ubuntu.

    Jason had already planned to reach out to the Banshee and Rhythmbox developers this week, so that will be going on in the next few days, may have already started. (Nothing happens in the weekend after UDS, people are too busy traveling home and recovering from jetlag and/or ubuflu.)

    “I have personally sensed no hostility from the [Banshee] upstream myself, so it would be nice if you dropped that idea altogether.”

    Happy to do so.

  92. @Allison Randal,
    I have a reply saved up in drafts somewhere to that post. It’s pretty long and I’d get to get my facts in order before posting, so I won’t send it out immediately.

    “I don’t know who it was, but I suggest that the healthy way to handle this is not to go after the person with bad information.”
    Don’t misunderstand. I’d like to hear his side of the story, that’s all.

  93. @Allison Randal,

    no, it was said that upstream Banshee maintenance is quite good, it was just undermaintained in Ubuntu. Now, in oneiric we did see quite a lot of uploads (thanks to Chow and Iain mostly), so I’m not really sure what this is about.

    Please cf. for some more details.

  94. @Allison Randal, If we were so unhappy with your affiliate changes I doubt we would have actually committed changes to make it easier for you (and everyone else) to do so, retaining only a note asking you not to.

    I believe everyone else has amply covered the “less than motivated” to accept your patches question by asking you to produce links to our bugzilla where such incidents have taken place. I cannot think of a single case of this happening. (I can think of cases where patches have been sitting in Bugzilla for a long time but that shameful reality occurs in most projects)

  95. @David Nielsen, AFAICT, you are not Gabriel Burt. I am pretty sure that commit you referenced had nothing to do with making it easier for Canonical to change the redirect URL, and is more for ease of upstream maintainership, if the redirector needs to move servers or something in the future.

    I’m pretty sure the developers who were required to do the work to change the redirect URL are smart enough to have done it without it being a config value.

  96. What happened to Moonlight?

  97. @foo, I removed it, due to lack of obvious continuation from upstream post-Xamarinization.

  98. @directhex, off topic rant, but I wish they’d make clear statements about what they do not work on anymore. It’s not the first time they silently drop something (WinForms comes to mind). I know these aren’t nice announcements to make, but transparency is good. It may also motivate potential contributors to know they won’t get any new things or fixes if they don’t jump in. Oh well.

  99. @directhex, I was always afraid of that, and hoped I was just paranoid.

  100. Okay ive listened to the UDS audio. I don’t understand something. if the U1MS plugin in banshee is written in C#…and not in C…. I don’t understand the argument that supporting banshee U1MS plugin _AND_ a rhythmbox plugin would be more work. They are entirely different codebases regardless of gtk2/gtk3. Are they not? Doesn’t c# abstract away enough of the differences between gtk2 and gtk3 to the point where the Banshee U1MS extension codewould be exactly the same? Am I wrong about that? I don’t understand how banshee stuck on gtk2# would be a blocker for gtk3 based C language work to build the rbox plugin.


  101. @Jef Spaleta, The U1MS addin is a thin wrapper around libubuntuone, which provides a music store GTK+ widget. The only heavy lifting in the addin is to hook up events like the “Download Finished” event into Banshee’s “add to library”.

    That widget itself is a GTK+2 widget.

  102. @directhex,

    Ah thanks, that makes more sense now. My C# reading ability is still pretty low. Thanks for the clarification.

  103. Hi, you say “A port to GTK+3 is almost complete”, but I haven’t been able to find any current branches for GTK# ported to Gtk+3 or GI. Could you point me in the direction where this new GTK# is being prepared ?

  104. @pixelpapst,

    You can find the gtk3 branch of Banshee here:

  105. @Jeffrey Stedfast, thank you, but I’d found that one before. I had asked for the GTK+3-port of GTK# specifically. Daniel Nielsen informs us below that this work has moven into GTK# master.

  106. The planning discussion for this topic is ongoing on the public ubuntu-desktop mailing list. Please contribute your thoughts to the thread:

  107. Has gtk# been ported to gtk+ 3.0 yet?

  108. @Daniel Morgan,

    Yes the work is currently in gtk#’s git master branch.

  109. Can someone release a “technical preview” or “beta” of the gtk# bindings for gtk+ 3.0 please?

    This will help those big time who want to port their gtk# applications to gtk# 3.0.

    I wish someone would blog or email the gtk-sharp-list so others will know.

  110. @Daniel Morgan, Getting a GTK#3 release out would certainly be a great step forward.

    Mike Kestner has expressed a desire to do an initial tech preview release to occur with the port of Banshee[1] (being a major consumer of GTK#). However this adds even more pressure to get the imfamous last GTK# bug fixed[2].


  111. @David Nielsen,

    Hmm is there any chance you can get Kestner to re-affirm that desire? As this particular recollection over what he intends seems to differ materially between people. And while I like the effort to link back to an archived discussion. The discussion you linked to is prefaced with AFAIR, which doesn’t provide the necessary clarity. What this does clarify is this particular point is now in dispute.

    It seems this conversation is stuck at what people remember about what Kestner may or have may not have said at some point in the past. Clarity as to what he can commit to and what is blocking the tech preview release of the new gtk# code tree is needed to make sure the decisions being made are…informed ones…based on correct information.

    All human memory is fallible and selective. And without calling anyone a liar, getting an updated understanding of the gtk# porting status seems to be an important consideration.


  112. @Jef Spaleta, I’ll reach out to Mike and ask him for a comment. For now I would take the above as being in need of verification (though I do recall having heard the gist of it before).

    However the bad news is that Xamarin are only interested in providing bugfixes for GTK#2 as, understandably, they see porting MonoDevelop (their major GTK# based offering) as being an expense they cannot justify at this time. So we are probably out of luck getting paid development time on GTK#3 at this time from their side.!/migueldeicaza/status/134659378098876417!/migueldeicaza/status/134659470625214464

  113. […] logs are complaints that it doesn’t work on ARM.”In a blog entry entitled “Bansheegeddon,” Shields details his objections to the decision to exclude Banshee, presumably in favor of […]

  114. […] So recently a lot of dust hs been kicked up over the fact that Ubuntu at UDS recently decided to take Banshee and Tomboy Notes off the default CD image. I won’t speak to the technical reasons other than to say that I feel they are rather weak, especially since the exact same reasoning was used to switch Rhythmbox with Banshee last time around. (Full disclosure department: being a Tomboy contributor it’s pretty obvious that I think Tomboy’s the best thing since sliced bread and grilled cheese and that removing it sucks.) What I am going to talk about is the total lack of communication and transparency in the decision-making process. Obviously I’m not the first to have opinions on this: Go to Jo Shield’s blog for a long and well-argued comment on the subject. […]

  115. Typical Canonical. Instead of fixing a bug upstream they rather change default applications again.

  116. Just use Amarok or Clementine, they are vastly more stable and useful than any gtk based option.

    stop using gnome, it sucks. KDE FOREVER!

  117. […] Banshee和Mono开发者Joseph Michael Shields称, […]

  118. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  119. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  120. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  121. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  122. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  123. […] of Mono from Ubuntu is one who pushed it into Debian an Ubuntu a few years back. This Mono booster is unhappy to see Mono going away from Ubuntu and he will mostly likely work to ensure that it stays inside […]

  124. […] include poor maintenance and also potential incompatibilities with ARM, according to a post-Summit blog post by Banshee developer Joseph Michael Shields, who disputes both assertions. No final decision […]

  125. I see in these comments lots of complaints about Banshee being slow, slow-to-start, or ‘hanging’. All I can say is that I run Banshee [on openSUSE] all day long. It seems responsive to me and the only stability issues I’ve had relate to managing devices [such as iPods]. Otherwise it just runs and runs. It plays music, streaming radio, audio books, downloads and plays podcasts,… in general it does everything I expect it to do without any issues. Banshee is an excellent example of *quality* Open Source software.

    To all the Banshee developers – Great Work! And this openSUSE user expects to continue using Banshee.

    And I make all my Amazon purchases via Banshee – so I get to support upstream development of GNOME. What could be better?

    To all the anti-mono bigots – you’re just silly and your arguments are built on a fundamental misunderstanding of both the technology and the law. But have a great holiday season anyway.

  126. […] Banshee estaban el poco mantenimiento y sus incompatibilidades potenciales con equipos ARM, según informó el desarrollador de Banshee Joseph Michael Shields, que disputa ambas afirmaciones. No hay una decisión final […]

  127. […] Banshee estaban el poco mantenimiento y sus incompatibilidades potenciales con equipos ARM, según informó el desarrollador de Banshee Joseph Michael Shields, que disputa ambas afirmaciones. No hay una decisión final […]

  128. I’m an ignorant layman and don’t care what kind of player comes as default on Ubuntu, as long as it satisfies the following:

    1) It’s layout should be iTunes like.

    2) – and THIS IS IMPORTANT! – It MUST have an equalizer. It should be considered worthless if it does not. Banshee has one. So does iTunes. Rhythmbox does not.

    Without an equalizer, the user has no control over the color and texture of their music. This is important when switching between good speakers and bad speakers/headphones. I don’t want to have to use my old iMac to fully enjoy my music.

    If Ubuntu overlooks this, it will be a shame, for an equalizer alone gives Linux and ABSOLUTE advantage over Mac and Windows in terms of music experience. Same sound quality, same intuitive player layout, but with more codec support and no DRM. That’s a serious selling (or sharing) point that could really help.

  129. […] als 10.000 US-Dollar jährlich, den das Projekt sicher besser gebrauchen konnte als Canonical. Nun beklagt Joseph M. Shields, einer der Banshee-Entwickler, die schlechte Informationskultur von Ubuntu. Die […]

Leave a Reply