!!! PLEASE WRITE TO THE MAILING LIST !!!
To check of your solution is right make the change. Compile the code.
Run Mixxx an check if you can still reproduce the bug. Just try it out
there is nothing that you can break this way
Best Max
On Wed, 2014-01-15 at 21:23 +0430, Ben Sollars wrote:
> Hey
The best way is to pick a bug and fix it.
Bugfix workflow
http://www.mixxx.org/wiki/doku.php/bugfix_workflow
Easy beginner bug
https://bugs.launchpad.net/mixxx/+bug/1258776
To solve this you have to find out where we tell mixxx which database
columns are internal only and add the 'KEY_ID' column
That worked (it launched the program at least, although I managed to crash
it soon after).
What's the best way to start understanding the code, structure, language
etc.?
Thanks again for the help y'all.
B
On 7 January 2014 00:15, RJ Ryan wrote:
> Yea, we already do on OS X. It would be good
Yea, we already do on OS X. It would be good to do this for all. (not just
for res/schema -- resource directory itself)
On Mon, Jan 6, 2014 at 2:43 PM, Owen Williams wrote:
> We've been seeing this problem a lot. Should we detect when there's a
> res/schema file in the immediate subdirectory o
We've been seeing this problem a lot. Should we detect when there's a
res/schema file in the immediate subdirectory of the running executable
and try to use that by default?
On Mon, 2014-01-06 at 13:07 -0500, RJ Ryan wrote:
> Hey Ben,
>
>
> You should run the compiled executable like this:
>
>
Hey Ben,
You should run the compiled executable like this:
./mixxx --resourcePath res/
It's most likely looking for its resource files in /usr/share/mixxx which
could either not exist or be the data from a prior version of Mixxx if you
have installed Mixxx from the Ubuntu repositories.
On Mon,
