Custom Context Browser Sections Patch

[Bradley Pesicka]

Thanks for reminding me. I have already changed the problem with tabs.  
I just needed to change a setting in kwrite.  It won't happen again.

Seb Ruiz wrote:

> ** Hardcoding sql / use of querybuilder **
> In the Amarok core, we use a QueryBuilder to create the required 
> query  for database lookups. This is used to ensure correctness of 
> code (to  an extent), ease of use, and, more imporantly to create 
> statements  relevant to the database used.  Most of your code _will 
> not_ work with  postgresql.  there is no way to avoid this until we 
> provide a Plugin  Api, hopefully for Amarok 2.0, when the databases 
> will be refactored  as well to a better OO design.
>
> Speaking of databases, the reason most of your stuff is buggy is  
> because you are missing semicolons at the end of the sql statements.

Sorry, I have only been using the sqlite database, so I have not been 
trying to make it compatible. But that is the problem, of course.

As to why I am using SQL in the scripts: I cannot access the album and 
statistics information from a script without using SQL.  Dcop only 
exposes the information for the currently playing track.

I just tried to write a QueryBuilder in ruby, but it was a big mess.  It 
probably is not a good idea to have a QueryBuilder in 
C++,ruby,python,etc. so a better solution is needed.

> Also, cover issue is solved if you do md5( album - artist ), not md5(  
> albumartst ).

Thanks, but this does not quite fix the problem.  The problem, as I see 
it, is that Amarok never creates the smaller version of the cover art, 
which is currently done in CollectionDB::findAmazonImage.  There is not 
a way to call this function from a script.

> ** Functionality **
> This is an excellent way to provide extensions to our users, but only  
> those who require or feel like playing with it. At the same time, we  
> shouldn't provide the need for this functionality unless the user  
> requests it. ie - keep the compiled code unless a script is used.

I should probably keep the internal section functions, but run them thru 
the custom context browser functions, so they function just like every 
other script.  However, I would need to find a good way to turn off the 
internal sections.  The scripts are basically just a general purpose 
script that reacts to the trackChange notification and calls dcop amarok 
contextbrowser addCustomSection and show up under a different section in 
the script manager.

> We also lose the javascript functionality, but i suppose this is just  
> code which you have not added - again, this would mean every script  
> would need to use custom headers and javascript methods. Yuck!

If you are talking about not being able to collapse the sections, I 
could not think of a good way to collapse a single section, have only 
that section disappear and have 3 columns at the same time.  It would 
have to re-render the html code.  And also, the javascript function for 
collapsing sections is still there, just not used by the sections.

> ** Load Times **
> This is the crux of my problems with your patch.  Having selected 
> only  the three "standard" scripts (current, fave tracks and other 
> albums),  it took 6 seconds to render the context browser.  Including 
> the  last.fm tags, wiki and suggestions, add another 10 seconds.

Any suggestions to speed it up would be greatly appreciated.  Currently 
it goes like this:
(the track changes)->(script notification)->(script 
processing)->(dcop)->(render)
After the script notification, everything is duplicated for each 
script.  I just cannot think of anything that can be done to speed this 
up except putting everything in the Amarok binary to remove script 
notification thru dcop steps, but that defeats the purpose of this patch.

I already use caching in some of the scripts to speed up accesses to web 
servers, but that also has problems.

Personally, I don't mind the time it takes.  I have been using this, in 
various stages of development, for about a week and it never crossed my 
mind that the load times could be a problem, but this is why I wanted 
comments on this patch though.

I think overall, though, we need to keep in mind that this is HIGHLY 
EXPERIMENTAL.

Thank you for your comments. I will see what I can do to incorporate 
your suggestions.