search

spiderbit / canta

The main public repo for the Canta project - a free karaoke game
http://www.canta-game.org
16 stars 2 forks source link

can not allow for users to edit songs in /usr/share #13

Closed glixx closed 11 years ago

glixx commented 11 years ago

Now canta crashes.

glixx commented 11 years ago

Warning is better for the first time, but in future better to save edited songs in /home or in directory on user case. Now there is no mechanism to open for editing any songs from any directory and to save in any other directory.

spiderbit commented 11 years ago

ok it makes no sense to allow opening songs in system, but not be able to save changes you made, but to select freely another directory would kill some usabiltiy and its not so easy to create a filedialog with soya-pudding.

So solution 1: could be to not show system songs (easy) solution 2: automaticly copy songs from system to home and save your changes to that file

solution 2 would have another problem, if you select in system song-xy save it and then try to play it you would think you changed the song in "system". so you would need another message on opening or saving that says you "saved changed version under home" or something like that.

solution 3: would be to completly rewrite the song chooser, remove the chooser between home and system, home could act like a layer over system, so you have only one song list, and if you save stuff it gets saved into home, and if you find in home a version and in system you only see the version in home. then a search field like in gnome-shell to find the songs would be also nice.

I think solution 1 is best solution for 0.2 stable branch.

glixx commented 11 years ago

Yes, solution 1 is best solution for 0.2 stable branch.

glixx commented 11 years ago

I like solution 3. Directory /home will keep only changed files and will have higher priority for song browser.

spiderbit commented 11 years ago

Yes but I dont think It would be a good idea to develop that feature for the stable branch, there should be only added small bugfixes and lokalisation added.

I think that is better for 0.3, there its ok if I create 1-2 new bugs in some cornercases that crash canta ^^.

in new unstable tree its ok to add 2-3-4 new big features and create with that 2-5 new bugs, but not for this "stable" version. ok the restart thing isnt very stable ^^

But I could make a "feature-branch" to implement that feature there, and if I really dont complete a 0.3 version in a longer time and that version in that branch is tested well I maybe can add that than to the 0.2-stable branch

glixx commented 11 years ago

For stable branch you can ban to write to /usr/share (even without warning), but program must not crash.

spiderbit commented 11 years ago

removed the selection screen in propose_0.2 screen so user dont see system songs and because of that they will not try to edit songs in system path and are pissed when save did not work, like they maybe accepted.

So fixed in proposed_0.2