Re: [Banshee-List] Summer of Code / Improve Banshee mac os x port



2012/4/9 Alexander Kojevnikov <alexk gnome org>:
> On 4 April 2012 23:21, gnomeuser gmail com <gnomeuser gmail com> wrote:
>> 2012/4/4 Timo Dörr <timo latecrew de>:
>>>
>>> Hi everyone,
>>>
>>> I've been a banshee on mac user for quite some time after beeing fed up with
>>> iTunes and its slow media import / general laggyness. About half a year ago,
>>> I've hacked together the FolderSync plugin for banshee which got accepted
>>> into BCE (see
>>> https://mail.gnome.org/archives/banshee-list/2011-September/msg00087.html)
>>> mainly to be able to perform simple android device/ folder based syncing on
>>> OS X aside the heavily linux-tied banshee device syncing.
>>>
>>> After I read on the gnome ideas page that this years Summer of Code has a
>>> proposal for improving the mac port of banshee, along with adopting the BCE
>>> build system for OS X I thought I should check whether to apply for it,
>>> since I'd be excited to improve the mac port, which really needs more love.
>>> When I developed the FolderSync plugin I ran into the problem that the build
>>> system only works for linux, so I already had to perform all coding work in
>>> a virtual machine on my macbook to develop the plugin only for copying the
>>> resulting managed .dll into the mac Appbundle for each test run on OS X. So
>>> I definetely support the task of changing the BCE buildsystem to work on mac
>>> (or maybe integrate into bockbuild?) and I am very confident I can complete
>>> this task.
>>>
>>> I also have some ideas about banshee on mac that I'd further like to work on
>>> (open for more):
>>>
>>> * Use MonoMac to support media keys on macbooks (play, pause, skip etc.)
>>> * better hardware support, especially device syncing for at least folder/usb
>>> mass storage support using banshees internal already existing code,
>>> rendering my FolderSync plugin mostly unneccessary
>>> * fix A LOT of obvious bugs in the mac port to increase stability (i.e.
>>> drag-n-drop leads to crash, volume slider not working correctly, etc)
>>>
>>> However, especially the last point is very tricky. For a few days now, I've
>>> been messing around with bockbuild to build banshee from source on my
>>> macbook. I've done that task half a year ago based on the bl8/bockbuild repo
>>> on github from bertrand, and I remember I had to fiddle a lot with bockbuild
>>> (bumping versions, fixing deps) at that time. Same happend to me last few
>>> days when I realized there is no official/documented bockbuild repo on
>>> github. I found the fork from xamarin/bockbuild and DavidNielsen/bockbuild
>>> to be the best candiates, but after checking them out none of the actually
>>> worked to build banshee out-of-the-box. The xamarin tree actually could
>>> build all the deps, but building banshee failed (problem with missing DBus).
>>> The DavisNielsen tree failed to build in the dependency stage. If fixed some
>>> bugs in both trees (i.e. missing .xz support, wrong libcroco build order)
>>> but afterwards only hit new ones - only to find out that bug is often fixed
>>> in the opposite tree already. After 2 days of working into the bockbuild
>>> system, I finally managed to merge both trees into a single one and get the
>>> dependency tree and banshee to fully compile. But sadly I had to find out,
>>> banshee crashes upon start. I hit the same bug David Nielsen describes in
>>> this bugreport: https://bugzilla.gnome.org/show_bug.cgi?id=647969. I've put
>>> my merged bockbuild repo onto github: https://github.com/Dynalon/bockbuild
>>> and verified with a fresh checkout that all deps and banshee from git can be
>>> compiled (as of today on an intel mac on Lion) without any modifications to
>>> the build system.
>>>
>>> So right now I am somewhat stuck. I've opened a bugreport on gnome's
>>> bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=673497), but since the
>>> bug is likely to be somewhere in pango/gtk+ quartz backend/cairo there is
>>> not much I can do about it expect to hope that it get fixed someday, since
>>> those projects are complex beasts themselves and digging into them with gdb
>>> without prior knowledge isn't really an easy task.
>>>
>>> I would really love to apply for GSoc's Banshee mac porting, but I think
>>> besides the above mentioned feature implementation a major task to *really*
>>> improve the mac port is to hunt such kind of (non C#/mono related) bugs and
>>> work with the according maintainers to get them fixed. But I am not sure if
>>> this ok with the GSoCs guidelines of doing only coding work, as well as the
>>> banshee mentors conception for this GSoC task. Any feedback and statements,
>>> especially from the responsible future-mentors would be greatly appreciated
>>> before I think about filling out an application with google :)
>>
>> I declare you hero of the year if you can manage to get the Mac port
>> to be more fully featured. I readily admit that while I build the Mac
>> release, my primary media player is iTunes. I will help any way I can.
>
> Decent proposal, but unfortunately I won't have enough time to take a
> second SoC project this year, I also know very little about OSX.
>
> If someone is interested in becoming a mentor for this project, please
> comment on Melange:
> https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dynalon/1

I just got a mail from the GNOME GSoC people and they feel that Timo's
application is strong. However we desperately need a mentor for this
project. I will as I said love to see this happen and I will help any
way I can but I do not know the Banshee internals sufficiently well to
mentor (nor OS X for that matter, but I do wangle bockbuild well by
now).

So here is my offer, a bottle of whiskey to whomsoever volunteers to
mentor for Timo. It sounds like he already has a firm grasp on the OS
X side which I suspect would be the weak side for any of our current
developers. I can likely hook Timo and his mentor up with the right
people and bribe some Xamarin people to help out with that part. So
someone who knows Banshee, step up and claim your alcohol.

- Desperate Dave


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]