[GeekShadow]

So, I'm currently at Poland this weekend for the MozCamp
https://wiki.mozilla.org/MozCampEU2012

After seeing the schedule, talking about Nightingale seemed a bit off-topic.
I don't think it's today we will attract more Mozilla contributors to help us upgrade the core of Nightingale.

There are several reasons :
* We are using a outdated version of XULRunner (matching Firefox 3.6 which is now outdated)
* Our XULRunner have a lot of custom patches from Songbird
* Mozilla is moving their code from XUL to HTML

At this point, only ilikenwf and Mook worked on the new core update but it seems like development has stalled.
Without Mozilla help, the road to up-to-date XULRunner could be long and I think we should focus on something new, writing from scratch.

From scratch ? Not totally.
I was thinking of starting from latest XULRunner or developing a Web app instead. Mozilla is currently writing a Music app for their Firefox OS (phones). https://github.com/mozilla-b2g/gaia/tree...apps/music

What if we fork it and make it also a desktop/tablet application ?
Working along with Mozilla could be really effective, while working with Songbird proved they are not even looking at
our patches.
We could even have an hybrid app : XULRunner + webapp...

POTI decisions are quite obscure now, if you have followed latest you certainly saw that they have launched a "Social" app working on Facebook. Other than this, they didn't update the core of Songbird at all, and I doubt they will in the near future.

Some cases of moving out of XUL :
- TomTom were using a XUL app for Navigation GPS, they have moved to a browser plugin instead.
- Flickr had a XUL app too to import photo, they finally upgrade their import photos webpage.

Forking Songbird was a lot of challenge and there is still a lot to do, mostly fixing bugs from the platform itself but also replace
stuff that POTI didn't provide such as real add-ons and translate platform.

Should we continue the long way of forking the current Songbird, or should we jump in the future ?

I'm not totally objective since I'm also a Mozilla contributor and Mozilla Reps, so I want to know what do you think about it.

I want to add that my current skills and time doesn't allow me to work on the XULRunner "upgrade", I would rather help on feathers, add-ons, l10n and patches.

[ilikenwf]

I can understand where you're coming from, but people genuinely want an iTunes type of library application. We follow their paradigm, and our users are the types that don't want everything to be web-based, or part of a browser.

I understand that some companies are moving to browser based plugins instead of using xulrunner, which is understandable in their positions, but I don't see how we should let it affect us. The only real transition from xul to HTML5 would be layout and UI. The core would remain...

I see no point in rewriting unless we end up building a frontend that still uses our same (improved over time of course) backend/mediacore, and uses the existing xulrunner/gecko (whatever they call it after HTML5 conversion is done) binaries on Linux systems, and depends on it's own on Windows and Mac...

Going with a new app would negate having addons, which are also a big pull - I realize that the whole mozilla webapps thing is happening, and while it's nice and all, I'm not sure it's for us. HTML5 doesn't support FLAC playback, and all the other crazy codecs that our mediacore does, and that's another HUGE draw to Nightingale for many of our users (http://hpr.dogphilosophy.net/test/ - html5 codec test).

If I wanted something that was browser based, even a webapp (which I'm sure these companies will release later), I'd use Google Music, Soundcloud, Grooveshark, Last.FM, etc exclusively...furthermore, I don't want to have to open Firefox to listen to my music..

I say we stay the course and roll with the gecko changes.

Furthermore, by doing that, we'll be fighting against those like Microsoft and Apple, and in some ways these web app proponents, who are trying to do away with general purpose computing, which keeps data more private, and leaves open doors for possibilities, rather than constraining users per device unless they use the cloud and host their data where government and other people can view it.

[GeekShadow]

(09-09-2012, 02:49 PM)ilikenwf Wrote: Going with a new app would negate having addons, which are also a big pull - I realize that the whole mozilla webapps thing is happening, and while it's nice and all, I'm not sure it's for us. HTML5 doesn't support FLAC playback, and all the other crazy codecs that our mediacore does, and that's another HUGE draw to Nightingale for many of our users (http://hpr.dogphilosophy.net/test/ - html5 codec test).

Not if we are using a new add-on system with an API.
Starting from around version 18, Firefox will support GStreamer to play anything, based on codecs you have installed on your system.

(09-09-2012, 02:49 PM)ilikenwf Wrote: ...I don't want to have to open Firefox to listen to my music..

It will be as a WebApp, so not really running in the main Firefox but as a separated window and process.

I think it's up to you to update Gecko since I don't really have the skills/energy/time to mess with C++/libs/build things. But I think I would be ok to try something from scratch on a fresh vanilla XULRunner/Gecko or a webapp.

[freaktechnik]

I think we are in a critical stage of the project, where we need to keep the development alive. Since we aren't a lot of developers, it's never good to loose the focus. However I can see GeekShadows disappointment in the actual situation. Nightingale, as fork of Songbird is really messy to code. It can't be called stable or reliable at all. And if you don't have the motivation to do something you won't put much energy in it. I'd be ok, if GeekShadow'd say "I'll start on planning a future product". And maybe building something like a prototype of it. If we get devs, who join the project to work on this, I'd be just happy because we got devs. Just, if this new "sidespin" is going final and we see, that we still haven't moved in the Gecko port I think it'd be better to abandon it. However it still needs to be expandable. Because thats the core on how we can actually fight against other music players. Everything else is just UX. And UX is pretty simple to change (and actually pretty streamlined across media players).

I think GeekShadow will build an advanced webmusic app anyways. That's at least what I would do. Because that's his project. We could just say yeah, we will support you in doing that and integrate it into the Nightingale project. So it's actually pretty nice of him offering us to be able to be a part of this. And you never know.
The desktop client will still be important: how do you sync devices from a webapp? Sure the cloud. But not everyone likes her. It would be neat to tie both products together nicely. But that's not the discussion right now.

I can't decide what's better. Both things have disadvantages. I think we shouldn't decide for one. Because that's what POTI did. And then they were unpopular. They chose Discovery over Android over Desktop. And that's why we exist. We should learn from that.

[nighthawk]

I can see where Geekshadow is coming from and see the reasoning behind what he is saying but I also agree with what ilikenwf says.

I love nightingale as it is but feel that it is to dependent on Songbird development and with the current direction of Songbird I feel that Nightingale needs to become less dependent and there is still great potential its development but there is much to do to bring it up to date. However, I think it would be a mistake to take it in the direction where it is a web app. The reason for this concern is that many people have music on their computers and have no need or require connection to the web. Also, a web app depends on a web connection to be able to use it, I often work away and have no 'net connection or if the connection at home was interrupted then I would not be able to listen to music with my favorite music player.

I am no developer as past examples a tests to but I am willing to help in any other way.

[freaktechnik]

Webapps don't require an internet connection or the music to be stored in the web.

The "full" version of nightingale will continue. One of the reasons is OS integration. As long as people use windowed OSes, this will be important (including me). Plus we will try to improve what we have right now.
However there might be some developers (including GeekShadow) working on the webapp, as of what I understand from now. I haven't heard anyone being like "no, we can't support a webapp". I think as long as the development of the standalone player continues, people won't care much.

[nighthawk]

(09-12-2012, 06:51 AM)freaktechnik Wrote: Webapps don't require an internet connection or the music to be stored in the web.

The "full" version of nightingale will continue. One of the reasons is OS integration. As long as people use windowed OSes, this will be important (including me). Plus we will try to improve what we have right now.
However there might be some developers (including GeekShadow) working on the webapp, as of what I understand from now. I haven't heard anyone being like "no, we can't support a webapp". I think as long as the development of the standalone player continues, people won't care much.

Thanks for the reply, I may have been misguided in believing webapps were called that because they relied on the web to work.

[ilikenwf]

I can see a benefit from leaving the Songbird codebase, as well. I just hate the idea of tossing out a codebase with so much development behind it, but it is very true that Nightingale's base is very messy as it is.

Being that I'm not really up to date on what can/can't be done with the webapps, if they indeed will support sqlite, and gstreamer natively (and actually play FLAC files), all we'd need would be a taglib wrapper to rebuild Nightingale as a webapp - of course, device syncing and such would be an interesting journey to make, but if we can make a webapp have the same sort of layout and functionality in terms of the addons, database, and playback of MANY formats, I'd support the move, or at least concurrent development on a webapp.

As for OS integration, we could surely do that in a webapp... I also feel that a webapp would probably fit my skills in a better way as well, as I wouldn't be using someone else's code - and it'd be a lot easier to get music stores, Google Music, etc integrated into Nightingale if we did things this way.

If we go this way, we should do one more release with as many bugfixes, etc as possible to hold people over while we develop the webapp. We need to probably wait until firefox 18 is released?

We probably should replicate the most used parts of Nightingale in a webapp and make sure they all work before we make a final decision. I figure I will still keep the old codebase up to date with Songbird until it's gone, if nothing else to keep an archive anyway...

GeekShadow, if you do start on this, feel free to call it Nightingale and add it to the repos. For now we could call it "Nightingale Beta" or something beta and bird related...either way, I guess I'm going to say a tentative yes...and that I'd be happy to help.

[Timmythepirate]

I personally would support whichever direction Nightingale would take. The only thing, that I think needs to be taken into consideration is to try to keep the look and feel of Nightingale the same. I personally hate it when apps drastically change their interface for no apparent reason (e.g., GNOME 2 vs GNOME 3)

[rsjtdrjgfuzkfg]

I personally agree with ilikenwf. Moving to a new codebase is terrible, but can be a right decision. However, I don't think the web app concept is ready for big desktop applications yet.

From me scrolling through some documentation I see that we have nicely wrapped media stuff, which is great from the Nightingale point of view. If the wrapper properly rely on system or bundled gstreamer or multiple media cores, that's great. Even if this is not implemented yet in Firefox, it probably will until we're finished.
However, I cannot see good apis for multiple (partly modal) windows (think of running the same webapp on a mobile device vs. on desktop), metadata, local file access (not sure there, but from what I see there is no unlimited access to files, which is great for (mobile/windows8) apps, but terrible for big desktop applications imho) and add-ons. I personally hate the idea of bringing tablet/mobile UI concepts to the desktop (Windows 8...), and thus would not use a desktop Nightingale based on these concepts. Having an Web App mobile Nightingale is surely a great thing, though.

Wrapping it up I see that all advantages of web apps are also in using a recent XULrunner, I'd prefer to clean up (and probably remove much code for media core, etc.) and use the HTML5 video and audio objects instead of gstreamer directly once gstreamer is supported in Firefox. However, I don't see any advantages on moving to a Web app (except for an additional web app with support for desktop Nightingale). So I'm for staying XULrunner.

We might discuss if it is better to start from scratch importing old code into the new XULrunner code, though. This would probably make us rethink the concepts we don't need with recent XULrunner features, as well as give us a better code overview. Not sure which way takes longer.