From: Jorg S. <Jor...@gm...> - 2006-08-30 14:48:54
Attachments:
path_4_buttons.diff
|
Marcelo Varanda wrote: > Again... but now with -u option and sent to a file (attached) I was looking at your 'path_4_buttons' since I didn't want to dissect the later patch you have sent. Should be quite nice with the following changes: 1) no '//' for comments 2) get rid of the new static variable selected_tracks_dspl -- it's not needed. tools_play_tracks() does not require the GList passed after it returns. 3) Buttons should be on the right side 4) I'm used to having the Play button in the middle -- if that's just me, leave it as it is. 5) Comments at the beginning of complex functions explaining what it does. 6) The Next/Prev buttons should actually play the next/Prev entry, I would think. Cheers, JCS. P.S.: Patch attached for reference. |
From: Jorg S. <Jor...@gm...> - 2006-09-12 12:29:24
|
Hi Marcelo, I've finally found time to look at your patch. I think the "Next" button should actually select and play the next track, not just select it. The buttons should be on the right side, not the left. "//" cannot be used to indicate comments, use "/*...*/" instead. The patch should address the prev/next/play buttons only, not the cell edit feature -- I'm trying to think of something else. If you send a revised patch I think I will submit it to CVS. Cheers, JCS. Marcelo Varanda wrote: > - The current Play Button in my patch does the same then Play cmd in > Context menu; > > - "Next" >>, selects next track (from latest selected row); > > - "Prev"<< , selects prv. track (from latest selected row); > > The << and >>buttons do not interact with playlist in progress. > > If you have chance apply the patch and play with those cmds a bit. > Cheers, > > > */Jorg Schuler <Jor...@gm...>/* wrote: > > Marcelo Varanda wrote: > > "The Next/Prev buttons should actually play the next/Prev entry, I > > would think." > > > > I am thinking that it might be better just leave the "Play" button > > (remove Next/Prev as it might be confusing). > > Sorry, now I'm confused. What good should the Play button alone do? It > wouldn't even be clear what it would play (selected playlist, tab > entry, > track(s)? Then I'd definitely prefer the context menu. > > A quick way to listen to the selected tracks and move forward/backward > from within gtkpod would certainly be convenient. > > JCS. |
From: Marcelo V. <mva...@ro...> - 2006-09-12 13:11:27
|
Hi Jorg, I was willing to use the right side to add a small panel to control the player in the future. However, I can move the buttons to the right now and by the time the panel is added then re-arrange the entire bar. However, users might be a bit lost with this lay-out changes as I do not think I will add this panel anytime soon. Please confirm what you would like better and then I will change that accordingly. Lock edit cells: I think the best option would be a simple "edit" command in context menu (no need lock/unlock and disregard click events for getting into that mode). note: it might get difficult to separate patches (well... not for this one). We would need to have as many as CVS copies for each new feature. We might also have dependencies over incremental changes making it even harder. I would appreciate your suggestion in how to keep patches isolated. btw... I could not find yet a Brazilian to translate gtkpod (and lib) to pt. Cheers, Marcelo Jorg Schuler <Jor...@gm...> wrote: Hi Marcelo, I've finally found time to look at your patch. I think the "Next" button should actually select and play the next track, not just select it. The buttons should be on the right side, not the left. "//" cannot be used to indicate comments, use "/*...*/" instead. The patch should address the prev/next/play buttons only, not the cell edit feature -- I'm trying to think of something else. If you send a revised patch I think I will submit it to CVS. Cheers, JCS. Marcelo Varanda wrote: > - The current Play Button in my patch does the same then Play cmd in > Context menu; > > - "Next" >>, selects next track (from latest selected row); > > - "Prev"<< , selects prv. track (from latest selected row); > > The << and >>buttons do not interact with playlist in progress. > > If you have chance apply the patch and play with those cmds a bit. > Cheers, > > > */Jorg Schuler /* wrote: > > Marcelo Varanda wrote: > > "The Next/Prev buttons should actually play the next/Prev entry, I > > would think." > > > > I am thinking that it might be better just leave the "Play" button > > (remove Next/Prev as it might be confusing). > > Sorry, now I'm confused. What good should the Play button alone do? It > wouldn't even be clear what it would play (selected playlist, tab > entry, > track(s)? Then I'd definitely prefer the context menu. > > A quick way to listen to the selected tracks and move forward/backward > from within gtkpod would certainly be convenient. > > JCS. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Gtkpod-devel mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
From: Jorg S. <Jor...@gm...> - 2006-09-12 13:41:44
|
Hi Marcelo, Marcelo Varanda wrote: > Hi Jorg, > > I was willing to use the right side to add a small panel to control the > player in the future. However, I can move the buttons to the right now > and by the time the panel is added then re-arrange the entire bar. > However, users might be a bit lost with this lay-out changes as I do not > think I will add this panel anytime soon. Please confirm what you would > like better and then I will change that accordingly. I'm getting confused by having the buttons on the left side, so by just moving them to the right, maybe with a separator bar, should be a good start. > Lock edit cells: I think the best option would be a simple "edit" > command in context menu (no need lock/unlock and disregard click events > for getting into that mode). I'm still trying to come up with something different. > note: it might get difficult to separate patches (well... not for this > one). We would need to have as many as CVS copies for each new feature. > We might also have dependencies over incremental changes making it even > harder. I would appreciate your suggestion in how to keep patches isolated. Two ways, I guess: 1) keep different checkouts. 2) once you created a patch, un-apply it (patch -R) and continue with the next one. Patches may collide, but this happens fairly rarely. In these cases the rejected hunks have to be combined manually. Not really a problem in almost all cases. > btw... I could not find yet a Brazilian to translate gtkpod (and lib) to pt. Thanks for trying! Cheers, JCS. > Cheers, > Marcelo > > */Jorg Schuler <Jor...@gm...>/* wrote: > > Hi Marcelo, > > I've finally found time to look at your patch. > > I think the "Next" button should actually select and play the next > track, not just select it. The buttons should be on the right side, not > the left. "//" cannot be used to indicate comments, use "/*...*/" > instead. The patch should address the prev/next/play buttons only, not > the cell edit feature -- I'm trying to think of something else. > > If you send a revised patch I think I will submit it to CVS. > > Cheers, > > > JCS. > > > Marcelo Varanda wrote: > > - The current Play Button in my patch does the same then Play cmd in > > Context menu; > > > > - "Next" >>, selects next track (from latest selected row); > > > > - "Prev"<< , selects prv. track (from latest selected row); > > > > The << and >>buttons do not interact with playlist in progress. > > > > If you have chance apply the patch and play with those cmds a bit. > > Cheers, > > > > > > */Jorg Schuler /* wrote: > > > > Marcelo Varanda wrote: > > > "The Next/Prev buttons should actually play the next/Prev entry, I > > > would think." > > > > > > I am thinking that it might be better just leave the "Play" button > > > (remove Next/Prev as it might be confusing). > > > > Sorry, now I'm confused. What good should the Play button alone > do? It > > wouldn't even be clear what it would play (selected playlist, tab > > entry, > > track(s)? Then I'd definitely prefer the context menu. > > > > A quick way to listen to the selected tracks and move > forward/backward > > from within gtkpod would certainly be convenient. > > > > JCS. |
From: Marcelo V. <mva...@ro...> - 2006-09-12 15:36:16
|
Hi Jorg, Just a comment where you say " I think the "Next" button should actually select and play the next track, not just select it." problem: User select multiple tracks and press "Play". If in this case he press "Next" then what ? It gets a little confusing. I would suggest to keep the way I did by just selecting the next track but not issueing another play request. Tks, Marcelo Jorg Schuler <Jor...@gm...> wrote: Hi Marcelo, Marcelo Varanda wrote: > Hi Jorg, > > I was willing to use the right side to add a small panel to control the > player in the future. However, I can move the buttons to the right now > and by the time the panel is added then re-arrange the entire bar. > However, users might be a bit lost with this lay-out changes as I do not > think I will add this panel anytime soon. Please confirm what you would > like better and then I will change that accordingly. I'm getting confused by having the buttons on the left side, so by just moving them to the right, maybe with a separator bar, should be a good start. > Lock edit cells: I think the best option would be a simple "edit" > command in context menu (no need lock/unlock and disregard click events > for getting into that mode). I'm still trying to come up with something different. > note: it might get difficult to separate patches (well... not for this > one). We would need to have as many as CVS copies for each new feature. > We might also have dependencies over incremental changes making it even > harder. I would appreciate your suggestion in how to keep patches isolated. Two ways, I guess: 1) keep different checkouts. 2) once you created a patch, un-apply it (patch -R) and continue with the next one. Patches may collide, but this happens fairly rarely. In these cases the rejected hunks have to be combined manually. Not really a problem in almost all cases. > btw... I could not find yet a Brazilian to translate gtkpod (and lib) to pt. Thanks for trying! Cheers, JCS. > Cheers, > Marcelo > > */Jorg Schuler /* wrote: > > Hi Marcelo, > > I've finally found time to look at your patch. > > I think the "Next" button should actually select and play the next > track, not just select it. The buttons should be on the right side, not > the left. "//" cannot be used to indicate comments, use "/*...*/" > instead. The patch should address the prev/next/play buttons only, not > the cell edit feature -- I'm trying to think of something else. > > If you send a revised patch I think I will submit it to CVS. > > Cheers, > > > JCS. > > > Marcelo Varanda wrote: > > - The current Play Button in my patch does the same then Play cmd in > > Context menu; > > > > - "Next" >>, selects next track (from latest selected row); > > > > - "Prev"<< , selects prv. track (from latest selected row); > > > > The << and >>buttons do not interact with playlist in progress. > > > > If you have chance apply the patch and play with those cmds a bit. > > Cheers, > > > > > > */Jorg Schuler /* wrote: > > > > Marcelo Varanda wrote: > > > "The Next/Prev buttons should actually play the next/Prev entry, I > > > would think." > > > > > > I am thinking that it might be better just leave the "Play" button > > > (remove Next/Prev as it might be confusing). > > > > Sorry, now I'm confused. What good should the Play button alone > do? It > > wouldn't even be clear what it would play (selected playlist, tab > > entry, > > track(s)? Then I'd definitely prefer the context menu. > > > > A quick way to listen to the selected tracks and move > forward/backward > > from within gtkpod would certainly be convenient. > > > > JCS. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Gtkpod-devel mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
From: Paul W. <pa...@bl...> - 2006-09-12 15:51:30
|
On Tue, Sep 12, 2006 at 11:36:07AM -0400, Marcelo Varanda wrote: > problem: User select multiple tracks and press "Play". If in this case he > press "Next" then what ? It gets a little confusing. I would suggest to Playback moves to the track after the one currently playing? -- Paul |
From: Jorg S. <Jor...@gm...> - 2006-09-12 16:01:43
|
Marcelo Varanda wrote: > Hi Jorg, > > Just a comment where you say " I think the "Next" button should actually > select and play the next track, not just select it." > > problem: User select multiple tracks and press "Play". If in this case > he press "Next" then what ? It gets a little confusing. I would suggest > to keep the way I did by just selecting the next track but not issueing > another play request. I don't think you need a button to just select the next track. I also don't think you need a button to remote-control xmms or whatever to play the next track in the playlist. The way I imagine the play/next/prev are used is to 1) select tracks and have a shortcut to play them 2) move forward/backward in the playlist AND play the track At least that's what I expected to happen when I used the buttons. Some people may want the next button to move xmms to the next track -- could be configured in the prefs. At a later time. Cheers, JCS. |
From: Marcelo V. <mva...@ro...> - 2006-08-30 17:36:24
|
"The Next/Prev buttons should actually play the next/Prev entry, I would think." I am thinking that it might be better just leave the "Play" button (remove Next/Prev as it might be confusing). Thanks Jorg Schuler <Jor...@gm...> wrote: Marcelo Varanda wrote: > Again... but now with -u option and sent to a file (attached) I was looking at your 'path_4_buttons' since I didn't want to dissect the later patch you have sent. Should be quite nice with the following changes: 1) no '//' for comments 2) get rid of the new static variable selected_tracks_dspl -- it's not needed. tools_play_tracks() does not require the GList passed after it returns. 3) Buttons should be on the right side 4) I'm used to having the Play button in the middle -- if that's just me, leave it as it is. 5) Comments at the beginning of complex functions explaining what it does. 6) The Next/Prev buttons should actually play the next/Prev entry, I would think. Cheers, JCS. P.S.: Patch attached for reference. Index: gtkpod/gtkpod.glade --- gtkpod/gtkpod.glade 24 Jun 2006 15:39:18 -0000 1.212 +++ gtkpod/gtkpod.glade 23 Aug 2006 05:28:08 -0000 @@ -1339,6 +1339,60 @@ True + + True + Add Files or Directories + Play + True + gtk-media-play + True + True + False + + + + False + True + + + + + + True + Add Files or Directories + Prev. + True + gtk-media-rewind + True + True + False + + + + False + True + + + + + + True + Add Files or Directories + Next + True + gtk-media-forward + True + True + False + + + + False + True + + + + True Try to load contents of all connected iPods. For each iPod a separate repository must be set up. Index: gtkpod/gtkpod.gladep --- gtkpod/gtkpod.gladep 15 Jun 2003 15:39:02 -0000 1.3 +++ gtkpod/gtkpod.gladep 23 Aug 2006 05:28:08 -0000 @@ -4,5 +4,6 @@ Gtkpod gtkpod + src_glade FALSE Index: gtkpod/src/display.c --- gtkpod/src/display.c 24 Jun 2006 15:39:22 -0000 1.149 +++ gtkpod/src/display.c 23 Aug 2006 05:28:09 -0000 @@ -48,6 +48,9 @@ GtkWidget *gtkpod_window = NULL; +static GList *selected_tracks_dspl = NULL; + + /* used for stopping of display refresh */ gint stop_add = SORT_TAB_MAX; @@ -2004,3 +2007,34 @@ message_sb_no_itdb_selected (); } } + + +void +play_toolbar_button_event (GtkToolButton *toolbutton, + gpointer user_data) +{ + if (selected_tracks_dspl) g_list_free (selected_tracks_dspl); + selected_tracks_dspl = tm_get_selected_tracks(); + if(selected_tracks_dspl) + { + tools_play_tracks (selected_tracks_dspl); + } + +} + + +void +rewind_toolbar_button_event (GtkToolButton *toolbutton, + gpointer user_data) +{ + tm_select_next_row(1); +} + + +void +next_toolbat_button_event (GtkToolButton *toolbutton, + gpointer user_data) +{ + tm_select_next_row(0); +} + Index: gtkpod/src/display.h --- gtkpod/src/display.h 24 Jun 2006 15:39:22 -0000 1.115 +++ gtkpod/src/display.h 23 Aug 2006 05:28:09 -0000 @@ -339,4 +339,6 @@ void spl_edit (Playlist *spl); void spl_edit_new (iTunesDB *itdb, gchar *name, gint32 pos); +void tm_select_next_row (gint Next0_Prev1); + #endif Index: gtkpod/src/display_songs.c --- gtkpod/src/display_songs.c 23 Jun 2006 16:03:05 -0000 1.111 +++ gtkpod/src/display_songs.c 23 Aug 2006 05:28:14 -0000 @@ -2438,3 +2438,49 @@ C_FREE (buf); return TRUE; } + +void tm_select_next_row (gint Next0_Prev1) +{ + if (track_treeview) + { + GtkTreePath *path; + GdkRectangle rect; + GtkTreeSelection *selection; + gint delta; + + gtk_tree_view_get_cursor ( track_treeview, + &path, + NULL); + + if (path == NULL) return; + + gtk_tree_view_get_cell_area (track_treeview, + path, + NULL, + &rect); + if (path == NULL) return; + + if (Next0_Prev1) delta = -rect.height/2; + else delta = rect.height + rect.height/2; + + gtk_tree_view_get_path_at_pos (track_treeview, + 1, rect.y + delta , &path, NULL, NULL, NULL); + + if (path == NULL) return; + + /* deselect current rows */ + selection = gtk_tree_view_get_selection (track_treeview); + gtk_tree_selection_unselect_all(selection); + + gtk_tree_selection_select_path ( selection, + path); + + gtk_tree_view_set_cursor ( track_treeview, + path, + NULL, + FALSE ); + + gtk_tree_path_free (path); + + } +} Index: gtkpod (copy)/src/display.h =================================================================== RCS file: /cvsroot/gtkpod/gtkpod/src/display.h,v retrieving revision 1.115 diff -u -r1.115 display.h --- gtkpod (copy)/src/display.h 24 Jun 2006 15:39:22 -0000 1.115 +++ gtkpod (copy)/src/display.h 23 Aug 2006 05:28:22 -0000 Index: gtkpod (copy)/src/display_songs.c =================================================================== RCS file: /cvsroot/gtkpod/gtkpod/src/display_songs.c,v retrieving revision 1.111 diff -u -r1.111 display_songs.c --- gtkpod (copy)/src/display_songs.c 23 Jun 2006 16:03:05 -0000 1.111 +++ gtkpod (copy)/src/display_songs.c 23 Aug 2006 05:28:22 -0000 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________ Gtkpod-devel mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
From: Jorg S. <Jor...@gm...> - 2006-08-31 13:10:20
|
Marcelo Varanda wrote: > "The Next/Prev buttons should actually play the next/Prev entry, I > would think." > > I am thinking that it might be better just leave the "Play" button > (remove Next/Prev as it might be confusing). Sorry, now I'm confused. What good should the Play button alone do? It wouldn't even be clear what it would play (selected playlist, tab entry, track(s)? Then I'd definitely prefer the context menu. A quick way to listen to the selected tracks and move forward/backward from within gtkpod would certainly be convenient. JCS. |
From: Marcelo V. <mva...@ro...> - 2006-08-31 15:40:04
|
- The current Play Button in my patch does the same then Play cmd in Context menu; - "Next" >>, selects next track (from latest selected row); - "Prev"<< , selects prv. track (from latest selected row); The << and >>buttons do not interact with playlist in progress. If you have chance apply the patch and play with those cmds a bit. Cheers, Jorg Schuler <Jor...@gm...> wrote: Marcelo Varanda wrote: > "The Next/Prev buttons should actually play the next/Prev entry, I > would think." > > I am thinking that it might be better just leave the "Play" button > (remove Next/Prev as it might be confusing). Sorry, now I'm confused. What good should the Play button alone do? It wouldn't even be clear what it would play (selected playlist, tab entry, track(s)? Then I'd definitely prefer the context menu. A quick way to listen to the selected tracks and move forward/backward from within gtkpod would certainly be convenient. JCS. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Gtkpod-devel mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |