GNOME Bugzilla – Bug 762265
no need for track change notification
Last modified: 2018-01-10 14:49:18 UTC
Created attachment 321587 [details] media controls on top serve a better purpose of information & control. With the new media control landing in the shell, Music no longer needs to duplicitly notify me of a track change.
Can I work on this? Although I have contributed to open source projects, this will be my first time contributing to something significant as GNOME or Linux.
(In reply to Ashhar Hasan from comment #1) > Can I work on this? Although I have contributed to open source projects, > this will be my first time contributing to something significant as GNOME or > Linux. sure.
I am more accustomed to the pull and merge concept. How do I generate a patch once I have committed my changes? And do I need to squash my commits into a single commit or can I add multiple commits.
(In reply to Ashhar Hasan from comment #3) > I am more accustomed to the pull and merge concept. How do I generate a > patch once I have committed my changes? You can use git format-patch or git-bz (which I recommend). And do I need to squash my commits > into a single commit or can I add multiple commits. Add as much commits as necessary.
Hi! I've a patch for this bug. Wondering if I should go ahead and submit it in case Ashhar is not working on it anymore.
(In reply to Gaurav Narula from comment #5) > Hi! I've a patch for this bug. Wondering if I should go ahead and submit it > in case Ashhar is not working on it anymore. Go ahead. I had some issues with setting up the dev environment behind a proxy. It'll take me time.
Created attachment 322561 [details] [review] remove notification on track change The patch removes the listeners and handlers for track change events in notification.py.
Review of attachment 322561 [details] [review]: Thanks for your patch.
I think this needs to be reopened/reworked. I don't think media controls equals notifications, they're two different things. With the current design we actually never get a (pop-up) notification on track change. The shell date/time (center) menu has no indication theres actually anything going on there in terms of music change/controls when it's closed. The only duplicity is the track being shown in the date/time MPRIS based media section and in the notification section of the date/time menu. I think that's something for the shell to handle (there seems to be no way around it afaics). If the notifications are gone and we want to keep it that way, then the whole class can be ditched. notification.py is non-functional code as it is right now.
(In reply to Marinus Schraal from comment #9) > I think this needs to be reopened/reworked. > > I don't think media controls equals notifications, they're two different > things. With the current design we actually never get a (pop-up) > notification on track change. The shell date/time (center) menu has no > indication theres actually anything going on there in terms of music > change/controls when it's closed. > > The only duplicity is the track being shown in the date/time MPRIS based > media section and in the notification section of the date/time menu. I think > that's something for the shell to handle (there seems to be no way around it > afaics). > > If the notifications are gone and we want to keep it that way, then the > whole class can be ditched. notification.py is non-functional code as it is > right now. I agree. I would like to hear what Allan Day thinks about it.
(In reply to Felipe Borges from comment #10) > (In reply to Marinus Schraal from comment #9) > > I think this needs to be reopened/reworked. > > > > I don't think media controls equals notifications, they're two different > > things. With the current design we actually never get a (pop-up) > > notification on track change. The shell date/time (center) menu has no > > indication theres actually anything going on there in terms of music > > change/controls when it's closed. > > > > The only duplicity is the track being shown in the date/time MPRIS based > > media section and in the notification section of the date/time menu. I think > > that's something for the shell to handle (there seems to be no way around it > > afaics). > > > > If the notifications are gone and we want to keep it that way, then the > > whole class can be ditched. notification.py is non-functional code as it is > > right now. > > I agree. I would like to hear what Allan Day thinks about it. I agree with Jakub's original bug report - I don't think we want duplication of the notifications in the shell's drop down. And I don't think that showing notifications for every track change is a good default behaviour - it's far too distracting.
(In reply to Allan Day from comment #11) <snip> > I agree with Jakub's original bug report - I don't think we want duplication > of the notifications in the shell's drop down. And I don't think that > showing notifications for every track change is a good default behaviour - > it's far too distracting. Well this is rather non-conforming behaviour then, all notifications have a corresponding entry in the gnome-shell drop down, except music: it is in the notification block, but it doesn't have a notification. The whole media control thing in a drop down is low discoverable, if you didn't know it was there you would never look for it. It's all rather odd. Personally I find it at times useful to know whats coming up, so I can skip or change music completely (think of shuffling lots of songs) . Yes, it can be distracting, but notifications can be disabled in gcc if need be.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-music/issues/54.