bug-gnupod
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnupod] Suggested re-design of gnupod_search.pl


From: H. Langos
Subject: [Bug-gnupod] Suggested re-design of gnupod_search.pl
Date: Thu, 28 Aug 2008 12:56:15 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hi gnupod users,

Adrian has allowed me to make some changes and (hopefully) improvements
to gnupod. The changes are in cvs and a 0.99.8 should be released soon.
It will probably become 1.0 as soon as the most obvious bugs are fixed :-)

For the next version after 1.0 I've already implemented some features and 
I'd like to do some serious rewriting of existing tools.

I've taken a look at gnupod_search.pl and eventhough it is small and nicely
written I'd suggest a modular rewrite that better separates the different 
tasks that it has come to do.

gnupod_search will only do the search and show the results.
gnupod_modify will modify tags.
gnupod_remove will delete songs from your ipod.

To keep it compatible I'd leave the existing command line switches for 
gnupod_search as they are, but to give full access to all song attributes
as stored in the XML structure I'd add "search" "show" "sort" options
that take full attribute names.


So you could call

gnupod_search --search artist="Pink Floyd",album="The Wall" --sort 
cdnum,songnum --show songnum,title

to get the track numbers and titles of that 2 CD album sorted by CD and track 
number.


To improve user experience gnupod_search needs to be more aware of 
what type of data it handles. It already knows how much space an
attribute needs for the output (thats why the "id" column is much
smaller than the "artist" column), and it knows what to write into 
the column header. But it also needs to know if an attribute 
is numeric or a string or a date. This will make it much easier to 
refine searches.

"--search" will understand some modifiers for people not familiar with
regular expressions and some extentions that can't be done with 
regular expressions at all.

So --search artist=="Pink" would find just "Pink" and not "Pink Floyd", 
and --search year=<2005 would find songs made before 2005, 
and --search addtime=<2008-07-15 would find songs added to my ipod before July 
15th,
and --search addtime=>"yesterday" would find songs added in the last 24h,
and --search releasedate=<"last week" will find podcast entries that are older 
than a week.

Sounds fun doesn't it? 

"--sort" will understand modifiers like "+" and "-" so that 
"--sort -title" will reverse the sorting by song title.


gnupod_remove will work exactly as the new gnupod_search will but 
will delete the songs it finds.


gnupod_modify will take the same new options as gnupod_search but will
also have a "--set" option that works pretty much the same way as the 
"--search" option does. 
So --set artist="Foo Fighters",year=2002 will do what you expect it to do.


So, what do you guys think? 

Any suggestions? 

Things I have overlooked?

Things that you miss in gnupod_search?

Is the equals sign in "--search year=<2005" suggesting to strongly that 
the year 2005 is included? 

Should "=" be replaced by ":" ?

Should "=" be treated like "==" and "=~" be the modifier for regex match?

Or how about having one character only? 
  artist=Pink  exact string match
  artist~Pink  regex match
  artist>Pink  alphabetically larger
  artist<Pink  alphabetically smaller

Or would that be too dangerous with all the wannebe smart shells out there 
that would easily interpret it as redirection of stdin/stdou? (Remember I want 
to make gnupod more pleasant to the less experienced user.)

Should "gnupod_search" be left alone and "gnupod_find" be the name of the new
modular search tool? 

Should gnupod_remove and gnupod_modify be interactive by default and have a 
"--force" switch for non-interactive mode?

Tell me what you think! I make no promises whatsoever that in the end I will 
not simply decide what I think is best, but hey .. if you run linux you are 
used to benign despotism ;-)

cheers
-henrik





reply via email to

[Prev in Thread] Current Thread [Next in Thread]