- Oct 12, 2013
-
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
We're keeping the old preferences definitions, so that the migration path can still potentially work.
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
With GSettings, every setting item must correspond to a predefined schema. As we were quite liberal in our use of configuration entries, this causes some challenges. So this commits introduces a new approach, based on a few principles: * Schema definition is maintained manually * Everything is relocatable * Path structure must match schema id In GSettings, a schema normally has a fixed path that determines where the settings are stored in the global tree of settings. However, schemas can also be 'relocatable', i.e. not equipped with a fixed path. We need to use relocatable schemas quite a lot. For example, each source has its own set of preferences, located under a node that is the unique identifier of the source. And the set of possible sources is unknown: one for each DAP device, each DAAP server, etc. So instead of trying to figure out which schema is relocatable, we just assume all of them are. Preferences are accessed by their namespace, which is converted to a path. Then we try to find an existing schema id by assuming they have the same structure, and going up the tree until we find a match. So for example, the path /org/gnome/banshee/sources/Foo/Bar will correspond to the schema with the id org.gnome.banshee.sources This means that preferences must always have a path that matches their schema id. Automatically extracting the schema from the code will not work without major impact on everything using preferences: we can't figure out both the schema id and the path without those notions leaking out everywhere in the code base. So I just used the GSettingsSchemaExtractor to get a first rough cut of the schema, and edited it manually to add all the keys that were not extracted automatically. Missing keys are easy to find, as GSettings just aborts when trying to read a key not defined in the schema. That means that the GSettingsSchemaExtractor are the related infrastructure can be removed. The build system is also modified so that the schema file gets translated and included in the source tarball. Also updated Hyena to bring in the latest git master which doesn't reference GConf at all anymore.
-
Andrés G. Aragoneses authored
Previous commit [1] contained an accidental change in the name of the tee pad to be retrieved. [1] https://git.gnome.org/browse/banshee/commit/?id=87c3e217c482f9dee289c54a23a5d711cb56e4b5
-
Andrés G. Aragoneses authored
If retrieving the tee pad doesn't work, it's better to throw an InvalidOperationException right away, instead of causing a NRE at a later stage.
-
Andrés G. Aragoneses authored
The nested class PlayerEngine.AudioSinkBin already contains a method to get the request pad of audiotee, so it's better to reuse it from all the places where it does the same.
-
Bertrand Lorentz authored
This fixes the build with the latest gtk-sharp from git master, as GLib now has its own DateTime class, which would clash with System.DateTime.
-
- Oct 11, 2013
-
-
Marek Černocký authored
-
Piotr Drąg authored
-
Andrés G. Aragoneses authored
-
Rafael Ferreira authored
-
Мирослав Николић authored
-
- Oct 10, 2013
-
-
Bertrand Lorentz authored
-
Bertrand Lorentz authored
Just because it looks better than 0.11.99...
-
-
Bertrand Lorentz authored
This fixes scrolling with the mouse wheel on the ListView.
-
- Oct 09, 2013
-
-
Andrés G. Aragoneses authored
It turns out all the Banshee codebase has explicit accessors, even if `private` is normally the default when there is no accessor. This rule will deter people from using new MonoDevelop's SourceAnalysis facilities (or Resharper in the case of VS.NET) to cleanup code in an incorrect way.
-
Andrés G. Aragoneses authored
Cleanup the code a bit: - Remove unused usings. - Simplify return expression. - Mark some fields as readonly which don't change.
-
Andrés G. Aragoneses authored
The removal of these deprecated comparisons that was recently committed[1] missed the CoverArtSpec class, which is done now. [1] https://git.gnome.org/browse/banshee/commit/?id=896af90924d6803ef5197b6da1ed4f2f174c143d
-
Andrés G. Aragoneses authored
PlayerEngine class has a Dispose() method so it should inherit from IDisposable.
-
- Oct 08, 2013
-
-
Andrés G. Aragoneses authored
Also: - move all data/ items together. - fix tabs vs. spaces nit mistake in recent commit related to this
-
After the fix for bgo#691696 landed, the target $DLL_MAP_VERIFIER_ASSEMBLY is defined in two places. This commits avoids this, by making the Makefile from the build/ dir include the generic build.rules.mk like other Makefiles in the build already do. The only change in this commit that seems to not be related is the move of the 'if ENABLE_TESTS' block. The reason for it was to avoid this build failure which would happen if it's not moved: Running automake --gnu --add-missing --force --copy -Wno-portability -Wno-portability ... build/build.rules.mk:11: LINK must be set with `=' before using `+=' No change of behaviour in this commit.
-
Andrés G. Aragoneses authored
-
Andrés G. Aragoneses authored
Also add the generated appdata to CLEANFILES list for the clean target.
-
Andrés G. Aragoneses authored
Also fix a nitpick in the NEWS file.
-
Bertrand Lorentz authored
-
Andrés G. Aragoneses authored
-
Andrés G. Aragoneses authored
-
- Oct 07, 2013
-
-
The LibraryWatcher extension has recently changed its dependencies [1] and there was no corresponding MSBuild fix for it. Signed-off-by: Andrés G. Aragoneses <knocte@gmail.com>
-
When using the latest versions of Mono and .NET (i.e.: the ones that include the .NET 4.5 profile), even if you decide to use the .NET 3.5 Profile (whose C# language version was 3.0), it allows you use language features from higher versions of the language. This is the reason why the build wasn't failing on mono even when using the 'gmcs' compiler. However, we still advertise in our dependencies only the .NET 2.0 Profile, so a Windows developer could try to build Banshee with a version of Visual Studio which still doesn't support the "optional parameters" language feature. We fix this by providing simply additional overloads that account for the cases in which the parameter is not supplied, in a way in which we don't break any API. To avoid this problem arising in the future, we also add the proper flag to pass to the Mono compiler to error on language features that are too new for the .NET profile that we target. However, in the very near future we should probably just switch to .NET 4.0 to make things more simple (not in the stable branch though, which is where this commit is going to be cherrypicked too). Signed-off-by: Andrés G. Aragoneses <knocte@gmail.com>
-
Andrés G. Aragoneses authored
This stops your IDE from highlighting many semantic errors, and allows code completion to work properly for these libraries. This brings an update to hyena as well, to bring the same type of fix for it [1]. (This didn't affect real compilation because we still use Makefiles for that.) [1] https://git.gnome.org/browse/hyena/commit/?id=78ea867777807b4fa546448261e8bcfd04374187
-
Andrés G. Aragoneses authored
The version of our Mono dependency was raised recently [1]. The gtk-sharp related dependencies need to be updated as well, and gtk-sharp-beans doesn't exist anymore, so we're removing it for good. [1] https://git.gnome.org/browse/banshee/commit/?id=b2c76dd4a9a9192ba63e04e13b6b1cfd7a48a9c7b2c76dd4a9a9192ba63e04e13b6b1cfd7a48a9c7
-
Andrés G. Aragoneses authored
As Boo became non-default recently[1], remove the dependency from the deps list in the script from extras called "create-release-notes". Also: move the m4 check in the configure script a bit further down, where the other optional dependencies are. [1] https://git.gnome.org/browse/banshee/commit/?id=e1263f866625847abc5aa2e216433edc0a9936dc
-
Andrés G. Aragoneses authored
This nitpick was missed when merging the gtk3 branch [1]. [1] https://git.gnome.org/browse/banshee/commit/?id=ca240160c3fb34c103aa92c5a002ee389ab257ae
-
Andrés G. Aragoneses authored
These references being missing were causing some misleading errors being highlighted in MonoDevelop.
-
- Oct 06, 2013
-
-
Andrés G. Aragoneses authored
-