Re: [Banshee-List] Bugs, Features & Forks

[Nicholas Little <arealityfarbetween googlemail com>]

Hi all,

Sorry I've been incognito this week - it's sad that after a day of
work I've often no juice left for working on the things I actually
use...

Replies inline:

On 8 January 2017 at 19:45, IBBoard <ibboard gmail com> wrote:
> On 08/01/17 17:28, Nate Graham wrote:
> > On 01/08/2017 03:08 AM, Nicholas Little via banshee-list wrote:
> > > Hi Nate,
> > >
> > > The album explorer was a filter so it's not included in the new user
> > > interface, if you don't --enable-treeview and run with --classic then
> > > you'll get access to it, course then you'll essentially just be
> > > running banshee master with a couple of MTP tweaks and minor bugfixes,
> > > but that's cool - I want to maintain the classic user interface too.
> > >
> > > I haven't included filters because you can get the same functionality
> > > by using search and they take up too much screen estate as they're
> > > currently implemented - eventually I'd like to reintroduce them but
> > > perhaps have them integrated with search.
> > >
> > > Another idea I've been toying with is displaying album art in the main
> > > track list - I like eye-candy as much as the next guy.
> >
> >
> > That would be nice!
> > Nate
>
>
> I'm intrigued. I think it needs a mock-up of what that could look like

That would be great communication but I am terrible with those
programs... I'd probably just try a couple of things out in a new
branch and see how it goes.

So, my initial idea sprung from the simple example [1] where they use
genres as tree branches, we could use album for that, and assuming
it's possible to swap out the widget that the expander functions with
then we could feasibly put the art and we'd probably have to include
some description or statistics there - number of tracks, duration,
anything 'album' really - otherwise there'd be lots of unused space.

I don't know though, it might turn out terrible, the only other
possibility I see is a completely custom widget, but that's a bit too
much GUI programming for my taste, the idea in switching to
Gtk.TreeView as a base class was so that it would take care of a bit
more.

For example, the ListView in my fork of Hyena suffers from a green
outline when re-ordering tracks in the PlayQueue, I'm not sure if I
caused that (it's totally possible) or if it's a quirk of using
gtk-sharp from git, anyway, TreeView doesn't suffer from it,
re-ordering looks a bit different but, well, progress. ;)

[1] http://www.mono-project.com/docs/gui/gtksharp/widgets/treeview-tutorial/#creating-a-tree

On 10 January 2017 at 16:31, Christian Perreault
<christian perreault 2 gmail com> wrote:
> Hi Nicholas,
>
> I have questions concerning this:
>
> if you don't --enable-treeview and run with --classic then
> you'll get access to it, course then you'll essentially just be
> running banshee master
>
>
> Just to be sure, does that mean that to get a "classic"/regular Banshee from
> your feature/lite branch,
>
> One first has to run autogen.sh without passing --enable-treeview?
> Run with "--classic", does that mean to execute "banshee --classic"?
> If so, is it possible to pass the --classic argument without installing the
> compiled Banshee, but through "make run" (A quick search indicates to me
> that such a thing is not that simple) ?
>
> Thanks again

Couple of things first:

- stop using autogen.sh and instead use autoreconf, I intend to remove
autogen.sh eventually;
- unless it's a fresh git clone or you're making changes to the
autotools system (the stuff under build/) you don't need to autoreconf
for every change, just use ./configure.

Apart from those things, you got it. It was before Christmas when I
looked but I'm fairly certain the run target will pass any additional
content after run to the command line - take a look in the top level
directory's Makefile.am, it should have the details for the run
target.

Cheers!

<snip />

-- 
Registered Linux User #392373