After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323933 - party mode for UI
party mode for UI
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: User Interface
HEAD
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 329900 (view as bug list)
Depends on:
Blocks: 467681
 
 
Reported: 2005-12-12 22:19 UTC by William Jon McCann
Modified: 2017-03-07 21:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initial patch (10.69 KB, patch)
2006-02-10 22:28 UTC, William Jon McCann
none Details | Review
patch2 (25.22 KB, patch)
2006-02-16 21:43 UTC, William Jon McCann
none Details | Review
patch 3 (25.73 KB, patch)
2006-02-16 22:31 UTC, William Jon McCann
committed Details | Review
patch (3.08 KB, patch)
2006-02-17 15:39 UTC, William Jon McCann
committed Details | Review
backtrace (17.63 KB, text/plain)
2006-02-18 05:58 UTC, Adam Zimmerman
  Details
ask for password using pam (1.07 KB, patch)
2007-02-19 05:20 UTC, David Keijser
none Details | Review
pam patch in unified format (1.28 KB, patch)
2007-03-11 21:40 UTC, David Keijser
needs-work Details | Review

Description William Jon McCann 2005-12-12 22:19:53 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?
Comment 1 William Jon McCann 2006-01-07 19:10:50 UTC
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
Comment 2 William Jon McCann 2006-01-07 19:13:28 UTC
Oh, and disable Trashing, deleting, and tag editing.
Comment 3 James "Doc" Livingston 2006-02-05 06:01:40 UTC
*** Bug 329900 has been marked as a duplicate of this bug. ***
Comment 4 James "Doc" Livingston 2006-02-05 06:04:00 UTC
Bug 32990 suggests that it also enqueues when you double-click on a track rather than playing it immediately.
Comment 5 William Jon McCann 2006-02-10 22:28:20 UTC
Created attachment 59111 [details] [review]
initial patch

Beginnings.  Queues on activation, disables trash/delete/etc., toggles fullscreen.  More to do.
Comment 6 James "Doc" Livingston 2006-02-11 03:14:06 UTC
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.
Comment 7 Alex Lancaster 2006-02-11 04:01:23 UTC
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.
Comment 8 William Jon McCann 2006-02-16 21:43:24 UTC
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
Comment 9 William Jon McCann 2006-02-16 22:31:42 UTC
Created attachment 59536 [details] [review]
patch 3

This one presents the window again when it is iconified.
Comment 10 James "Doc" Livingston 2006-02-17 04:39:20 UTC
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).
Comment 11 William Jon McCann 2006-02-17 15:11:42 UTC
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.
Comment 12 Alex Lancaster 2006-02-17 15:23:58 UTC
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.
Comment 13 Alex Lancaster 2006-02-17 15:36:20 UTC
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)


Comment 14 William Jon McCann 2006-02-17 15:39:32 UTC
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.
Comment 15 Alex Lancaster 2006-02-17 15:44:10 UTC
(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.)
Comment 16 Alex Lancaster 2006-02-17 15:50:52 UTC
(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.

Comment 17 Alex Lancaster 2006-02-17 15:52:01 UTC
(In reply to comment #14)
> Created an attachment (id=59580) [edit]
> patch
> 
> This should fix the clipboard stuff.

Thanks.  Patch fixed that problem.
Comment 18 William Jon McCann 2006-02-17 15:57:16 UTC
Ok, I committed that too.
Comment 19 William Jon McCann 2006-02-17 17:07:35 UTC
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.
Comment 20 Christophe Fergeau 2006-02-17 17:30:13 UTC
It's possible to tell s-j to auto-rip tracks when it starts up using a command line option iirc
Comment 21 Alex Lancaster 2006-02-17 17:40:31 UTC
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.
Comment 22 Adam Zimmerman 2006-02-18 05:57:17 UTC
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.
Comment 23 Adam Zimmerman 2006-02-18 05:58:17 UTC
Created attachment 59625 [details]
backtrace
Comment 24 Cyphase 2006-12-29 22:41:37 UTC
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.
Comment 25 Alex Lancaster 2007-02-10 07:44:14 UTC
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
Comment 26 David Keijser 2007-02-19 05:18:29 UTC
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.
Comment 27 David Keijser 2007-02-19 05:20:23 UTC
Created attachment 82865 [details] [review]
ask for password using pam
Comment 28 Sam Morris 2007-03-10 14:38:31 UTC
(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'?
Comment 29 David Keijser 2007-03-11 21:40:43 UTC
Created attachment 84401 [details] [review]
pam patch in unified format
Comment 30 Christophe Fergeau 2007-03-11 21:44:23 UTC
int rhythm_conv(int n, const struct pam_message **msg, struct pam_response **resp, void *data) should be declared as static.
Comment 31 Martin Ejdestig 2007-07-20 22:04:03 UTC
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.
Comment 32 Martin Ejdestig 2007-07-20 22:36:31 UTC
I filed bug 458806 for the party mode vs visualization part. Sorry for the spam.
Comment 33 Marc-Andre Lureau 2007-09-09 20:12:09 UTC
Guy, I like the idea of "party-mode", but the meaning of Full-Screen should remain the same... see bug 467681.
Comment 34 Christophe Fergeau 2007-09-09 20:23:26 UTC
(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 35 Martin Ejdestig 2007-09-09 20:29:06 UTC
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.
Comment 36 Christophe Fergeau 2007-09-09 20:33:20 UTC
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, ...) ?
Comment 37 Martin Ejdestig 2007-09-09 20:42:31 UTC
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.
Comment 38 Martin Ejdestig 2007-09-09 21:10:40 UTC
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?).
Comment 39 Martin Ejdestig 2007-09-10 00:08:46 UTC
And oh, btw, Epiphany's toolbar changes radically when you go into fullscreen mode.
Comment 40 André Klapper 2014-12-02 01:40:04 UTC
Party mode does exist now under "View > Party Mode" in 3.0.
What is left here?
Comment 41 André Klapper 2017-03-07 21:27:11 UTC
(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.