GNOME Bugzilla – Bug 323933
party mode for UI
Last modified: 2017-03-07 21:27:11 UTC
It would be really cool to have a "Party mode" or "Jukebox mode" where the interface is in full screen mode and prevents the user from accessing anything else except Rhythmbox. This would be really nice to let people control the interface but not have access to the computer (say, at a party). After a period of inactivity the screen might start showing visualizations. If implemented using a grab then it would have to do without dialogs/menus/drag-n-drop. Crack? Probably. Useful? Maybe. What do you think?
Also: http://mail.gnome.org/archives/rhythmbox-devel/2006-January/msg00003.html Might be able to do: - gtk_window_stick (TRUE) - gtk_window_set_keep_above (TRUE) - inhibit the screensaver - monitor the "window_state_event" signal - change the Quit action to Quit Party Mode - require the user's password to quit party mode
Oh, and disable Trashing, deleting, and tag editing.
*** Bug 329900 has been marked as a duplicate of this bug. ***
Bug 32990 suggests that it also enqueues when you double-click on a track rather than playing it immediately.
Created attachment 59111 [details] [review] initial patch Beginnings. Queues on activation, disables trash/delete/etc., toggles fullscreen. More to do.
Looks good. Personally I think that Party Mode should replace Fullscreen. The only reason I can think of for someone wanting RB fullscreen, while acting normally, is that they want the extra space that would be otherwise taken by the window borders. I'm fairly sure that anyone who wants that will be able to use their WM's fullscreen-window option.
One thing I noticed is that if an entry is selected, and before you enter party mode you right-click on properties, you see the "Remove" in the menu. But if you click party mode, then right-click the same entry, "Remove" is still in the menu. You have to move to another entry before the menu greying-out takes effect. The same is true coming out of party mode. Another entry needs to be selected before the "Remove" item is de-greyed-out.
Created attachment 59528 [details] [review] patch2 Replace existing fullscreen mode. Disable deleting playlists. Disable close/quit. Disable window delete. Stick window on all workspaces and set to stay on top. Still to do: - Figure out how to do password. Can we ask for the user's own password? - inhibit screensaver
Created attachment 59536 [details] [review] patch 3 This one presents the window again when it is iconified.
Looks good so far to me. If you're happy with it, this could probably be committed now, and the other bits added later. Whether or not we should use the user's password, or a special password, I'm not sure. * Using the user's password has the advantage of being easier to use. * Using a special password has the advantage of allowing you to give the password to other "trusted" people, without having to trust them enough to potentially give them root access (if the user can sudo with their own password). I would probably say that the latter is more important, and also means that we don't need to depend on pam (or whatever).
Right, I've committed this since I think it is pretty good. Obviously, it should not be considered "secure" but should be useful to impede tinkering. Your bullets regarding the password mirror my thoughts. The advantage of the first is that no configuration is required - the user already knows the password and we use it. But I'm not sure.
Thanks. But the problems I mentioned in comment #7 remain. If a particular song is selected in the entry view just before Party Mode is enabled, after the mode is enabled, you can right-click that song and "Remove", and it *will* remove the song. Vice-versa for coming out of party mode. Changes to the right-click menu should take effect the moment it is enabled, so that when a song is right-clicked, the "Remove" is greyed-out or enabled immediately.
Other things that should be disabled: Import File Import Folder (I could add tracks both ways) Import Audio CD (sound-juicer started) Scan Removable Media Playlist menu (I could create new manual and automatic playlists, I could also add new songs to my old manual playlists, by drag-and-drop, I definitely don't want people mucking up my existing playlists at parties) New Internet Radio Station New Podcast Feed (These didn't appear to create new streams, but the dialogs should not appear)
Created attachment 59580 [details] [review] patch This should fix the clipboard stuff. I don't think I agree with disabling the stuff you have mentioned. I think if someone walks up with a CD they should be able to import it.
(In reply to comment #13) > Playlist menu > (I could create new manual and automatic playlists, I could also add new songs > to my old manual playlists, by drag-and-drop, I definitely don't want people > mucking up my existing playlists at parties) Also for consistency: if you can't edit automatic playlists, you shouldn't be able to create them, and if you can't remove items from manual playlists, you shouldn't be able to add them (obviously you can them to the Play Queue, though). Another idea might be to switch to Play Queue as sidebar mode automatically if it isn't already enabled, since that gives the best view of the upcoming music, and it hides all the stuff you shouldn't be messing around with anyway (like podcasts, playlist etc.)
(In reply to comment #14) > Created an attachment (id=59580) [edit] > patch > > This should fix the clipboard stuff. > > I don't think I agree with disabling the stuff you have mentioned. I think if > someone walks up with a CD they should be able to import it. Yeah, but they shouldn't be able to add stuff to your existing playlists, and it only makes sense, since they can't remove items from it. People could really mess up playlists that you've carefully created that way. Also adding new podcasts and radio stations could clutter up your sources really quick. Perhaps there could be two levels: total lockdown (good for big parties, more like an internet kiosk) and a partial one where users could add radio stations etc, but not modify existing ones.
(In reply to comment #14) > Created an attachment (id=59580) [edit] > patch > > This should fix the clipboard stuff. Thanks. Patch fixed that problem.
Ok, I committed that too.
Of course, import cd just starts s-j which will pop up behind the UI and no be usable. We really need built-in cd ripping support.
It's possible to tell s-j to auto-rip tracks when it starts up using a command line option iirc
As I suggested above perhaps there could be a more locked-down "jukebox" mode in addition, that would be completely read-only (just like a jukebox), you can add things to the queue, reorder, remove things to your heart's content, but you couldn't affect playlists, podcast, radio, CDs. You can browse and search the library of course. It would not be desirable to be able to rip tracks for true jukebox mode.
Found a bug: Rhythmbox crashes when the following steps are performed: 0. Make sure the queue is empty 1. Start playing a song 2. Switch to party mode 3. Double click a song to add it to the queue - The song information changes to "Not Playing", while the song continues to play (another bug) - If you click next, the queued song starts playing, and the information is correct again 4. However, if you let the playing song finish, rhythmbox crashes when the song is done.
Created attachment 59625 [details] backtrace
Instead of having to decide if people should be allowed to change playlists, import music, add radio stations, etc, why not allow users to configure everything via the Preferences dialog? It could have pre-configured profiles, i.e. Jukebox, Party Mode, etc, and allow for custom profiles as well.
There is a discussion on the ML relevant to this bug, the thread is: http://mail.gnome.org/archives/rhythmbox-devel/2007-February/thread.html#00050 and the initial post is: http://mail.gnome.org/archives/rhythmbox-devel/2007-February/msg00050.html
Hi. I made a little proof-of-concept code to show how pam can be used to ask for the users password when leaving partymode. im using the misc_conv function from pam_misc to ask for the password as for now, so the password prompt appears in the terminal. im not to familiar with automake, so didnt even try to make a patch for the scripts there. but you will need to link with libpam och libpam_misc.
Created attachment 82865 [details] [review] ask for password using pam
(In reply to comment #27) > Created an attachment (id=82865) [edit] > ask for password using pam > Could you please regenerate your patch in unified diff format, using 'diff -u'?
Created attachment 84401 [details] [review] pam patch in unified format
int rhythm_conv(int n, const struct pam_message **msg, struct pam_response **resp, void *data) should be declared as static.
I really don't understand why the menu entry has to be named "Party Mode" instead of "Fullscreen" like in most other apps. Seems like it was a consequence of replacing some old code more than anything else? Also, I like the idea of integrating it more with visualizations as mentioned in comment 1. Is this still in the pipeline? The current situation with party mode vs visualization mode (embedded/fullscreen/window) is kind of weird.
I filed bug 458806 for the party mode vs visualization part. Sorry for the spam.
Guy, I like the idea of "party-mode", but the meaning of Full-Screen should remain the same... see bug 467681.
(In reply to comment #31) > I really don't understand why the menu entry has to be named "Party Mode" > instead of "Fullscreen" like in most other apps. Seems like it was a > consequence of replacing some old code more than anything else? > It's called party mode because it does more than making RB fullscreen, it also locks down some parts of the UI, see comment #8 for example...
Comment #8 doesn't really explain why it is a good idea to replace the term "Fullscreen" with "Party Mode" in the UI. Why is it a good idea? Does it meen anything to the user? (I don't think so.) It is more likely than not a source of confusion.
The party mode is a locked down mode meant to be used during parties... Is it a good idea to call something "Full Screen" which indeed goes to fullscreen, but also sticks the window so that it shows up on all desktops, disables some features (playlist modifications, ...) ?
Also, two questions to consider: 1) What does the HIG say about this type of behaviour? 2) Is it such a good idea to behave fundamentally different from other applications that have a full screen mode? If the HIG is silent, ponder on #2. :) Some things might be justified though... but I don't know. You are after some sort of more locked down mode? Maybe this can be solved in some other way? Or maybe it's not worth it... meh, what do I know.
Is it a good idea in the first place to have it show up on all desktops? I don't think its wrong with disabling some features and still calling it full screen. There are other applications that have a "kiosk mode" and still call full screen full scree (e.g. Epiphany have other means of locking down the UI... right?).
And oh, btw, Epiphany's toolbar changes radically when you go into fullscreen mode.
Party mode does exist now under "View > Party Mode" in 3.0. What is left here?
(In reply to André Klapper from comment #40) > Party mode does exist now under "View > Party Mode" in 3.0. > What is left here? No reply, hence assuming this is fixed.