The pull request made by @freqlabs is much more readable, because it
also gets rid of the hardcoded grid coordinates.
So this is mainly a rebase of his commit 04f5d1d92c3cc8b2d0312961b4d589
in #9 on top of my changes:
Use a QMap to simplify CasterBoard
Instead of using separate member variables for every player, a
single map can both store the players and provide a convenient
mechanism for mapping key press events to the appropriate player.
The map uses a Qt::Key symbol as the key and stores the pointer to
each widget as the value.
To populate the map, we iterate over each character in a string,
where the characters correspond to the labels of the hotkey widgets.
The corresponding Qt::Key values are stored in another array that is
accessed in parallel. A counter keeps track of the offset in the
keys array and is also used to calculate the grid position of each
widget.
Instead of a map I'm still using a QHash, because it doesn't allow for
duplicates and is also faster in lookup.
I've also noticed that he's been using C++11 constructs, so I'm also
using these for saveLayout() and restoreLayout() as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @freqlabs
We already have a map of all the keys and their corresponding
CasterBoardLayout values, which link to the corresponding widget.
So when closing the window, the layout is saved using QSettings within
the [boards] section in an array mapping from the key id to the file
name, which looks like this:
[boards]
1\49=/path/to/foo.ogg
1\title=aaa
2\69=/path/to/bar.flac
2\title=bbb
size=2
Of course, if we have more complex layouts which doesn't involve a grid,
this will fall short, but we can still implement this once that's the
case.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #3
Having all the keys copy & pasted all over the place is a lot of churn
and doesn't need to be like that.
We're heading on to saving the state of the board layout and duplicating
even more of these lines all over the place is not magically cleaning up
the code.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This was the reason audio wasn't working for me so far.
In the long term however I think it would be a good idea to actually
show an error dialogue with detailed information if that happens.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is mainly useful because I'm using a tiling WM and don't have a lot
of applications available (well, except Chromium, but that's still very
much annoying while testing) for dragging and dropping files into
CasterSoundboard.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This not only gives a bit more information about what's going on within
a specific player tile, but we now have a single state property which we
can use to boil down all the various states of the subwidgets to the
CasterPlayer class.
Right now we do not yet take into account the QMediaPlayer's state, but
that's something for future improvements.
So the result is now that the user now should no longer be in the dark
if Qt Multimedia fails to load a file.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If the player doesn't work correctly (which currently is the case on my
system) or can't load the file immediately (like for example from a
network resource) it's a good idea to actually show in the tile that
it's still trying to load the source.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is mainly so that you could easily have a nix-shell with the
dependencies set up and also a way to build a package out of it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This adds an "install" target to the resulting Makefile, so it's easier
to be packaged for distributions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
