From: James L. <jrl...@co...> - 2005-07-03 01:25:32
Attachments:
New Sort Tab Proposal.png
|
Jorg, After seeing how the sorting tabs are handled, I've got an idea for a new UI for them. Attached is a picture of a preliminary window I put together in Glade today. I think it could make things a lot easier because it consolidates all six different sort tab sets into one. What do you think? James |
From: Jorg S. <jor...@gm...> - 2005-07-03 14:20:07
|
Hi James, [prefs for special sort tab] retyping the smart sorttab fields everytime you start gtkpod should be tedious... As a user I want my last entries being remembered -- they are definitely a better default than anything we programmers can come up with. [new sort tab] Sorry, but my first reaction is that I don't like it... Selecting items from a combo box appears tedious for me. Don't worry too much about the special sort tabs, anyhow. I'd rather throw them out completely and replace them with the smart playlist interface anyway. Cheers, JCS. > --- Ursprüngliche Nachricht --- > Von: James Liggett <jrl...@co...> > An: Jorg Schuler <Jor...@we...> > Kopie: GtkPod Developer Mailing List <gtk...@li...> > Betreff: [Gtkpod-devel] Sort Tabs Idea > Datum: Sat, 02 Jul 2005 18:21:19 -0700 > > Jorg, > After seeing how the sorting tabs are handled, I've got an idea for a > new UI for them. Attached is a picture of a preliminary window I put > together in Glade today. I think it could make things a lot easier > because it consolidates all six different sort tab sets into one. What > do you think? > > James > -- What's the difference between eating sugar (e.g. candy bar) and eating carbon hydrates (let's say a loaf of bread)? Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl |
From: James L. <jrl...@co...> - 2005-07-03 19:28:56
|
Yeah, I agree. Smart playlists would be a better way to do this stuff. The reason I ask about saving the the information in prefs is because the way it's set up now, using the system that I'm designing would be difficult. I'll look into it some more and come up with something. Thanks, James Liggett On Sun, 2005-07-03 at 16:19 +0200, Jorg Schuler wrote: > Hi James, > > [prefs for special sort tab] > retyping the smart sorttab fields everytime you start gtkpod should be > tedious... As a user I want my last entries being remembered -- they are > definitely a better default than anything we programmers can come up with. > > [new sort tab] > Sorry, but my first reaction is that I don't like it... Selecting items from > a combo box appears tedious for me. > > Don't worry too much about the special sort tabs, anyhow. I'd rather throw > them out completely and replace them with the smart playlist interface > anyway. > > Cheers, > > > JCS. > > > > > --- Ursprüngliche Nachricht --- > > Von: James Liggett <jrl...@co...> > > An: Jorg Schuler <Jor...@we...> > > Kopie: GtkPod Developer Mailing List <gtk...@li...> > > Betreff: [Gtkpod-devel] Sort Tabs Idea > > Datum: Sat, 02 Jul 2005 18:21:19 -0700 > > > > Jorg, > > After seeing how the sorting tabs are handled, I've got an idea for a > > new UI for them. Attached is a picture of a preliminary window I put > > together in Glade today. I think it could make things a lot easier > > because it consolidates all six different sort tab sets into one. What > > do you think? > > > > James > > > |
From: Jorg S. <jor...@gm...> - 2005-07-04 07:29:12
|
Never cancel features just because they don't fit the current implementation... ;-) JCS. > --- Ursprüngliche Nachricht --- > Von: James Liggett <jrl...@co...> > An: Jorg Schuler <jor...@gm...> > Kopie: GtkPod Developer Mailing List <gtk...@li...> > Betreff: Re: [Gtkpod-devel] Re: [Gtkpod-devel] Sort Tabs Idea > Datum: Sun, 03 Jul 2005 12:24:47 -0700 > > Yeah, I agree. Smart playlists would be a better way to do this stuff. > The reason I ask about saving the the information in prefs is because > the way it's set up now, using the system that I'm designing would be > difficult. I'll look into it some more and come up with something. > > Thanks, > James Liggett -- What's the difference between eating sugar (e.g. candy bar) and eating carbon hydrates (let's say a loaf of bread)? Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl |
From: James L. <jrl...@co...> - 2005-11-23 06:37:19
|
On Mon, 2005-07-04 at 09:29 +0200, Jorg Schuler wrote: > Never cancel features just because they don't fit the current > implementation... > > ;-) Sorry I took so long to get back to you on this. I've been very busy with a lot of different things, so I haven't had time to play with this. You're right--canceling a feature due to implementation really isn't a good idea. In retrospect, I think redoing the whole format of the prefrences file was too extreme anyway. I figured that it's a better idea to work with numbered pref keys instead of just getting rid of them. My hiatus from this did allow me to come up with an idea to make numbered prefs work with the new prefs interface I've been working on. I thought that the prefs functions that I was working with (prefs_get_int_value, prefs_set_int_value, etc) might work if we had them deal with numbered keys (i.e. the special sort tab keys) internally. For example, take the current prototype of prefs_get_int: gboolean prefs_get_int_value (const gchar *key, gint *value); I had the idea to add another parameter to these functions, which for now i'm calling key_number. This parameter specifies the number suffix of a pref key (if there is one) The new prototype could look like this: gboolean prefs_get_int_value (const gchar *key, gint key_number, gint *value); And the function would take the key name specified by key and suffix it with the key number. For instance, if I wanted to mess with any numbered key, like col_visible4, I would do something like this: prefs_get_int_value("col_visible", 4, 1) and the function would take the base key name and the key number and turn it into "col_visible4" internally, so we wouldn't have to worry about that from the outset. And for non-numbered keys, like mountpoint, we could do something like: prefs_get_string("mountpoint", -1) Where we have a the key name, and any negative number for a key number, so that the function would know it's dealing with a non-numbered key. I'm in the middle of hashing out some test cases, but so far things look pretty good. What do you think? James |
From: Jorg S. <Jor...@gm...> - 2005-11-24 12:46:06
|
Hi James, good to see you back... > I think redoing the whole format of the prefrences file was too extreme > anyway. Well, if someone comes up with an extremely better way I would definitely be for it... > I figured that it's a better > idea to work with numbered pref keys instead of just getting rid of > them. My hiatus from this did allow me to come up with an idea to make > numbered prefs work with the new prefs interface I've been working on. I > thought that the prefs functions that I was working with > (prefs_get_int_value, prefs_set_int_value, etc) might work if we had > them deal with numbered keys (i.e. the special sort tab keys) > internally. For example, take the current prototype of prefs_get_int: > > gboolean prefs_get_int_value (const gchar *key, gint *value); > > I had the idea to add another parameter to these functions, which for > now i'm calling key_number. This parameter specifies the number suffix > of a pref key (if there is one) The new prototype could look like this: > > gboolean prefs_get_int_value (const gchar *key, gint key_number, gint > *value); I would make another set of functions for numbered prefs -- no need to give out a key_number for non-numbered prefs. gboolean prefs_get_int_value_index (const gchar *key, gint key_number, gint *value) would then simply be a front-end to the existing gboolean prefs_get_int_value (const gchar *key, gint *value). > prefs_get_string("mountpoint", -1) > > Where we have a the key name, and any negative number for a key number, > so that the function would know it's dealing with a non-numbered key. Awkward ;-) Non-numbered prefs are more frequent than numbered ones... We'd also need a function to wipe out an existing numbered prefs name-space. Cheers, JCS. |
From: James L. <jrl...@co...> - 2005-11-24 21:27:37
|
On Thu, 2005-11-24 at 21:11 +0900, Jorg Schuler wrote: > > I would make another set of functions for numbered prefs -- no need to give > out a key_number for non-numbered prefs. > > gboolean prefs_get_int_value_index (const gchar *key, gint key_number, gint > *value) > > would then simply be a front-end to the existing > > gboolean prefs_get_int_value (const gchar *key, gint *value). I did initially consider something like that, but I was a little reluctant to add yet another set of functions, but if you think it works better I'll go for it... > > > prefs_get_string("mountpoint", -1) > > > > Where we have a the key name, and any negative number for a key number, > > so that the function would know it's dealing with a non-numbered key. > > Awkward ;-) Maybe. It's just a rough idea. :) > > Non-numbered prefs are more frequent than numbered ones... > > We'd also need a function to wipe out an existing numbered prefs name-space. Why would we need that if we can make this system work with them as they are as opposed to getting rid of them like I first suggested? Sure, I'd love to get rid of numbered keys for simplicity, but I think that just be way too difficult for everyone right now. > > Cheers, > > > JCS. |
From: Jorg S. <Jor...@gm...> - 2005-11-25 19:33:14
|
> > I would make another set of functions for numbered prefs -- no need to give > > out a key_number for non-numbered prefs. > > > > gboolean prefs_get_int_value_index (const gchar *key, gint key_number, gint > > *value) > > > > would then simply be a front-end to the existing > > > > gboolean prefs_get_int_value (const gchar *key, gint *value). > I did initially consider something like that, but I was a little > reluctant to add yet another set of functions, but if you think it works > better I'll go for it... I think it's better for the programmer :-) > > We'd also need a function to wipe out an existing numbered prefs name-space. > Why would we need that if we can make this system work with them as they > are as opposed to getting rid of them like I first suggested? Sure, I'd > love to get rid of numbered keys for simplicity, but I think that just > be way too difficult for everyone right now. Maybe I did not express what I wanted to say. For the "Sort Ignore List" the number of items can vary. Assume you have 10 items at first. Then the user modifies the items and you end up with six. You'd then have to make a call void prefs_index_wipe (gchar *key, gint num); that wipes key<num> key<num+1> key<num+2>, i.e. all keys with indexes no longer in use. Cheers, JCS. |
From: James L. <jrl...@co...> - 2005-11-26 04:21:18
|
On Fri, 2005-11-25 at 20:41 +0900, Jorg Schuler wrote: > Maybe I did not express what I wanted to say. > > For the "Sort Ignore List" the number of items can vary. Assume you > have 10 items at first. Then the user modifies the items and you end up with > six. You'd then have to make a call > > void prefs_index_wipe (gchar *key, gint num); > > that wipes key<num> key<num+1> key<num+2>, i.e. all keys with indexes no > longer in use. Ok. I get it now. Thanks for clearing it up. When I get done cleaning up the interfaces I'll work on this function. The overhaul is almost ready. The only things I have to do now are finish implementing the second set of prefs functions (the ones for numbered prefs like what you suggested yesterday,) implement commmand-line parsing (which will probably be pretty close to what's already in CVS,) and envrionment variable handling and it should be ready for you pretty soon. :) James |
From: Jorg S. <Jor...@gm...> - 2005-11-26 05:09:23
|
On Fri, Nov 25, 2005 at 08:27:44PM -0800, James Liggett wrote: > Ok. I get it now. Thanks for clearing it up. When I get done cleaning up > the interfaces I'll work on this function. The overhaul is almost ready. > The only things I have to do now are finish implementing the second set > of prefs functions (the ones for numbered prefs like what you suggested > yesterday,) implement commmand-line parsing (which will probably be > pretty close to what's already in CVS,) and envrionment variable > handling and it should be ready for you pretty soon. :) I'd have one request: please make small steps, like 1) first do the new interface and us the patch 2) change a small number of prefs functions and send a patch. This will allow to detect any problems that still need sorting out 3) do the rest as far as reasonable. Cheers, JCS. |
From: James L. <jrl...@co...> - 2005-11-27 08:54:04
|
On Sat, 2005-11-26 at 14:08 +0900, Jorg Schuler wrote: > I'd have one request: please make small steps, like That was going to be the plan anyway. I was going to bring it up, but you beat me to it. ;-) > > 1) first do the new interface and us the patch > 2) change a small number of prefs functions and send a patch. This will > allow to detect any problems that still need sorting out > 3) do the rest as far as reasonable. Ok. Sounds good. The way I see it, it would be best to make a patch against CVS that tacks on my interface backend code to the end of prefs.c, leaving the old stuff intact so as prefs get changed over to the new system we can keep removing its old counterparts in prefs.c and prefs.h, and keep doing that in steps until all we have left is the new system. If things work out like I hope they will, I will be able to send patches within the next few weeks. James |
From: Jorg S. <Jor...@gm...> - 2005-11-27 13:46:47
|
On Sun, Nov 27, 2005 at 01:01:29AM -0800, James Liggett wrote: > On Sat, 2005-11-26 at 14:08 +0900, Jorg Schuler wrote: > > I'd have one request: please make small steps, like > That was going to be the plan anyway. I was going to bring it up, but > you beat me to it. ;-) > > > > 1) first do the new interface and us the patch > > 2) change a small number of prefs functions and send a patch. This will > > allow to detect any problems that still need sorting out > > 3) do the rest as far as reasonable. > > Ok. Sounds good. The way I see it, it would be best to make a patch > against CVS that tacks on my interface backend code to the end of > prefs.c, leaving the old stuff intact so as prefs get changed over to > the new system we can keep removing its old counterparts in prefs.c and > prefs.h, and keep doing that in steps until all we have left is the new > system. If things work out like I hope they will, I will be able to send > patches within the next few weeks. Sounds fine! JCS. |
From: James L. <jrl...@co...> - 2005-12-10 04:05:26
|
Hi Jorg, I'm just about ready to start sending the first of the patches, but I've run into some issues I think we should discuss (apolgies for the length): Firstly, I've run into a bit of a problem with temporary prefs for the advanced sort window. Currently this is handled with its own temporary prefs structure. I've planned to replace the temp prefs structures with a tree containing changed keys that will be copied back into the main hash table. While this approach works fine for the main prefs window, it doesn't quite work out for the advanced prefs window. I realized that this window would need a temp prefs tree of its own to keep track of changes that the user makes without interfering with changes made in the main prefs window. I've been spending quite some time figuring out a plan on how to address the problem. One thing I really don't want to end up doing here is adding a whole new set of functions just for the sort window, or any other prefs windows that might come about later on. But I think putting in it's own GTree would work. I think we should move the temp prefs tree objects (just the pointers to them--not the interface functions.) out of prefs.c and put them in prefs_window.h. Then, we could add another parameter to the temp prefs functions, something like: void temp_prefs_set_string_value(const GTree *prefs_tree, const gchar *key, const gchar *value); Where prefs_tree tells the function which tree the data is going into. That way, as new prefs windows get added as GtkPod's functionality expands, there'll be an easier way to handle it. The only reservation I have about this approach is that the pointers to the GTree's would have to be non-static, which means it would be legal for people to mess with the trees directly, which is a bad idea. OK, now for the second thing: the sort-ignore list. I've pretty much got this hashed out, but then something occurred to me. What if, for some reason, we had to add another list like this (that is, a list with a variable length) sometime in the future? I thought it might be a good idea to have the infrastructure for something like that in place now so we wouldn't have to deal with it later. What I think we should do in this case is add a simple GList that contains the keys of lists that need to be cleaned up. The temp prefs tree would contain the entire new list. A function would be used to flag lists that have been changed and need to be cleaned, and another function would call prefs_wipe_index to do the work, and then the temp prefs would be put into the hash table, new list items and all. Because the sort ignore list is the only list like this right now, this might seem a little like overkill, but I think we need to keep our eye on the future here. Let me know what you think. ;-) James |
From: Jorg S. <Jor...@gm...> - 2005-12-10 04:43:27
|
Hi James, thanks for your continued work on this! > plan on how to address the problem. One thing I really don't want to end > up doing here is adding a whole new set of functions just for the sort > window, or any other prefs windows that might come about later on. But I > think putting in it's own GTree would work. I think we should move the > temp prefs tree objects (just the pointers to them--not the interface > functions.) out of prefs.c and put them in prefs_window.h. Then, we > could add another parameter to the temp prefs functions, something like: > > void temp_prefs_set_string_value(const GTree *prefs_tree, const gchar > *key, const gchar *value); This interface looks fine -- what is the problem? You could make the GTree pointer static in prefs_window.c then nobody will play around with them. I'm not sure what the advantage of a GTree over a GHashTable is, but if you have some good reasons... I also think it would be a good time to redo the apply/cancel mechanism. Currently, if you press cancel, the original prefs structure is restored, even if you pressed apply before. I do no longer think this is how it should be (correct me if I'm wrong). Cancel should close the window and leave the prefs as they are without applying any changes done since the last apply. > OK, now for the second thing: the sort-ignore list. I've pretty much got > this hashed out, but then something occurred to me. What if, for some > reason, we had to add another list like this (that is, a list with a > variable length) sometime in the future? I thought it might be a good > idea to have the infrastructure for something like that in place now so > we wouldn't have to deal with it later. What I think we should do in > this case is add a simple GList that contains the keys of lists that > need to be cleaned up. The temp prefs tree would contain the entire new > list. A function would be used to flag lists that have been changed and > need to be cleaned, and another function would call prefs_wipe_index to > do the work, and then the temp prefs would be put into the hash table, > new list items and all. Because the sort ignore list is the only list > like this right now, this might seem a little like overkill, but I think > we need to keep our eye on the future here. Makes sense -- but too many functions for my taste. What about something like temp_prefs_apply (GTree *prefs_to_tree, GTree *prefs_from_tree, GList *lists); that does all the work at once (check if one of the lists was changed, if yes wipe the prefs_to_tree of these keys, and finally copy over all changes). prefs_to_tree would be NULL to apply to the original preferences. Cheers, JCS. |
From: James L. <jrl...@co...> - 2005-12-10 06:10:55
|
On Sat, 2005-12-10 at 13:42 +0900, Jorg Schuler wrote: > Hi James, > > thanks for your continued work on this! > > > plan on how to address the problem. One thing I really don't want to end > > up doing here is adding a whole new set of functions just for the sort > > window, or any other prefs windows that might come about later on. But I > > think putting in it's own GTree would work. I think we should move the > > temp prefs tree objects (just the pointers to them--not the interface > > functions.) out of prefs.c and put them in prefs_window.h. Then, we > > could add another parameter to the temp prefs functions, something like: > > > > void temp_prefs_set_string_value(const GTree *prefs_tree, const gchar > > *key, const gchar *value); > > This interface looks fine -- what is the problem? You could make the GTree > pointer static in prefs_window.c then nobody will play around with them. Maybe I didn't say it like I needed to. Under the one-tree system I have now, the tree object is static in prefs.c, and is only accessible via the interface functions there. If I carry out my plan, they'd be moved to prefs_window.c, where a lot of changes could potentially occur. The thing I'm most worried about is the potential for people to start screwing with the trees in the functions there. The thing is you'll just have to watch out for that kind of thing in patches against the new system. > > I'm not sure what the advantage of a GTree over a GHashTable is, but if you > have some good reasons... I don't think I ever explained why I use trees here. I chose trees for the temp prefs because they're linked structures, and require a lot less work to grow than does a hash table. It seemed to be the better choice here because we don't really have an idea of exactly how many prefs would need to be changed. A hash table, by contrast, requires a lot more work to grow, and a lot of times that doesn't make them so great for cases like this. > > I also think it would be a good time to redo the apply/cancel mechanism. > > Currently, if you press cancel, the original prefs structure is restored, > even if you pressed apply before. I do no longer think this is how it should > be (correct me if I'm wrong). Cancel should close the window and leave the > prefs as they are without applying any changes done since the last apply. Absolutely. That's one of the reasons that I needed to come up with the interface described earlier. Under my system, if cancel is pressed, the tree is destroyed, and the table doesn't get touched. > > > OK, now for the second thing: the sort-ignore list. I've pretty much got > > this hashed out, but then something occurred to me. What if, for some > > reason, we had to add another list like this (that is, a list with a > > variable length) sometime in the future? I thought it might be a good > > idea to have the infrastructure for something like that in place now so > > we wouldn't have to deal with it later. What I think we should do in > > this case is add a simple GList that contains the keys of lists that > > need to be cleaned up. The temp prefs tree would contain the entire new > > list. A function would be used to flag lists that have been changed and > > need to be cleaned, and another function would call prefs_wipe_index to > > do the work, and then the temp prefs would be put into the hash table, > > new list items and all. Because the sort ignore list is the only list > > like this right now, this might seem a little like overkill, but I think > > we need to keep our eye on the future here. > > Makes sense -- but too many functions for my taste. What about something > like > > temp_prefs_apply (GTree *prefs_to_tree, GTree *prefs_from_tree, GList *lists); I think that's pretty much where the final patch would have gone anyway. Keep in mind that what I'm describing is just a proposal--I haven't actually developed any of this yet, but it should be easy enough to do. I thought it would be better to bring you in on the idea before I started working on it. One of my main goals with the new system is to deconsolidate the prefs system into more modular functions. While this might seem like it makes things complex initially, in the end I think it'll make things easier, especially in terms of expansion. One of the major problems I notice with the current system is that many of the functions (like read_prefs) do way too many different things, like environment parsing and commandline parsing all in the same ball of wax, which makes extenstion difficult. But, it seems like for the most part we're on the same page, so I'll get to work. :) James |