So, I recently saw some more updates on the Gnome Live wiki regarding the evolution of a ‘Semantic Desktop’. I have some bad news people: Its not going to happen. Now before everyone spends 20 minutes explaining all the ways it could, let me clarify my point. It’s a largely unattainable goal, which if it ever were to complete, would be a horrible user experience. I think somewhere between RDF, FoaF, and ObjectRank we lost sight of the original goal of a Semantic Desktop. We wanted to organize, present and store data in a fashion more congruent with the human mind. The general effort behind the Semantic Web and Desktop movements was to reduce the ‘multiplier effect’ of communication. (Take for example one e-mail sent to a mailing list, the file and data is now duplicated a hundred times over, and each receiver must filer or classify the e-mail with relationship to themselves). On the scale that communication takes place over the web, this effort is still crucial, but in the desktop world, where we operate on a billionth of the scale, that problem is not nearly as pervasive. No doubt the advances made in understanding and structuring the mass hysteria of the web will benefit desktop users, but I think forcing that structure onto the desktop is not only impossible, but counter-productive.
In my opinion the options are clearly laid out before us:
1) Move the desktop into the structured realm of a million and one tags/categories/color filters/labels/folders
- Or -
2) Get rid of it all. And just know what the user wants. (Ok, not really all of it, but instead of adding more hierarchies, we add more in-place understanding)
I know, its a bold statement, but somewhere between my tags, stars, labels, folders and emblems I realized that all these efforts we were making towards ease of use and understanding are just obfuscating things even further. These elaborate systems that require users to squeeze into sub-par standards like iCal exacerbate the problem even more, and ignore the efficiency of simple systems, like a pad of paper. (Yes, props to Tomboy). The problem is, many times a blunt-simple interface requires significantly more work on the programmers side (to actually understand the data entered) than a more traditional tabs-and-forms approach. I think we are demanding too much from users, how many people actually keep their address book completely updated? Or tag all their photos, or keep every document in the right folder? Even those who are vigilant eventually fall behind, and that’s because users already know what the material they are filling is, but still have to spend time explaining to the computer which items are related and where they belong. Especially for users with large sets of desktop data (Few thousand docs,e-mails,photos, and songs) the time can add up. Instead of asking users to commit even more time for data integrity and organization with more tagging systems.
The way I see it, we can count on 2 skills from a Desktop user.
1) Searching ( ThankYou Google!! Most people are quite comfortable with search phrasing!) or more accurately, knowing what they are looking for
2) To use their computer even when they aren’t looking for something (ie content generation, surfing the web, chat etc.)
These are the common denominators that we should be reaching for. We shouldn’t be trying to make the user classify their relationship with each person in their address book, we should just always be there, identifying the relationship based upon their level of interaction. And on a higher level than traditional approaches have taken us. After working on the Beagle Project for some time, the incredible weight of maintaining the backends to communicate with each mail client, each rss reader and each chat client almost seems to drown out the gain from having the data in a central and unified place. I mean, each time it was just someone talking to someone else right? Why have we taken simple actions and tried to codify them, when the complexities of human behavior are so great any Psychologist would tell you its a guessing game anyways. I think we should start with the disorganized mess that is someones workday at a computer and ask for nothing else. Reverse the system, take all of our analytical energies and structure, and use it for ourselves, in the backend, and just have the users use computers.
The best example of this is the phenomenon of tagging. Basically associating like objects via keyword-phrases. The problem is tags restrict themselves, lets say I have created a blog post about web browsers, while the tags ‘html, web, mozilla, ie’ may indeed be the most accurate 4 words from my point of view, they in no way approach the whole set of meanings and connotations carried by all their synonyms, let alone the entire post. In the realm of multimedia, tags are more useful, as images and videos are harder to extract contextual value from, but there is a better way….
Lets be smart! Instead of trying to stem the tide of data to make it more manageable, we ride the wave! Data is very rarely stagnate on a machine, people send photos to friends, edit each others papers, and share music all the time, there is a wealth of information in the chat I have with a friend while he listens to the new song I sent him, we just need to grab it!
I have specifics and even a little bit of code for my next post, but until then, I want feedback, do people agree? I mean, yeah, a million and one more ways for me to catalog and store my data, but when I’m actually looking for something the tags never seem to help much. While tags and folders do help with the clutter problem, I want to propose the idea that we move completely beyond presenting the hierarchy to the user, and start determining how (from the most basic of usage data) we could better present/organize information. Is the ubiquitous search box the only UI system that fits? What about something like Dasher meets lowfat, powered by an incredible datastore, but for files?
So, I think most of the open source world has agreed that the DRCS model fits our working style better than the traditional model pushed by SVN and CVS etc. And in this DRCS world we have rallied around 3 main tools: Bzr, hg, and git. And in an even greater display of complacency we have given those 3 tools quick and general classifications that became obsolete almost a year ago. Bzr is user friendly but slow and technologically inferior, hg is the champion of the middle but with slow development and a lackluster community, git is wicked fast and ‘The Right Way’TM but a pain to use.
Really? Come on guys, those molds were cast almost a year and a half ago, isn’t it time we looked at things again? Git has an entirely new interface, hg has a slew of plugins/extensions, and bzr has a completely new repo format, and network protocol, resulting in a massive speedup. Now I’m not claiming to be some unbiased source, and comparing 3 incredibly robust tools is not my job, but given the amount of support that Git receives from its very vocal supporters makes me feel a need to give props to my favorite DRCS system: Bazaar.
That’s right, Bazaar (or bzr) is awesome. Sure, git is awesome too, and so is mercurial, but I have found myself loving bzr. I’m not going to attack other DRCS tools, I just want to extol the awesomeness that is bzr.
1) Bzr is Python-Tastic! - As a python hacker, being able to utilize a robust API and plugin system is a cool plus, this also generates lots of powerful and complete plugins, which leads me to the next point.
2) Bzr has a ton of plugins! - Plugins like bzr-avahi (allows the discovery of branches on a local network, great for sprints/hackfests), bzr-svn (makes working with upstream repositories easy as pie!), quilt and gtk tools.
3) Bzr works on Windows - Yeah, I’m not a huge fan of accommodating Windows users, but it makes collaboration easier, I don’t have to make my roommate boot into Ubuntu to lend a hand with some CSS bugs.
4) Bzr is easy to share - The ability to push branches to some central repo is a big component of distributed development. While patches work in some cases, most of the time, having access to a branch makes the whole system work better. Both Git and Hg require a bit of work to set up a new repo and push a branch, bzr supports a ton of protocols and can create the target directory/repo with one command. Sharing is easy!
5) Bzr is fast - Maybe others are faster, maybe it could be a million times faster, I dunno. What I do know is the only thing I seem to wait on is my net connection… I realize that many people need more than that. So here you go. http://bazaar-vcs.org/Benchmarks
6) Bzr is small - In my development model (a shared repo with branches inside of it) bzr is compact and aware of disk space, without repositories it might be huge, I dunno.
7) Bzr is clear about whats happening - I can follow what Bzr is trying to do with my code. A branch is a new directory, and I can always see my code. Not only is this comforting/reassuring, but I often utilize IDE’s like Wing, Eclipse, or Monodevelop when working on code, and while they can handle other systems, directories for branches translates to every editor and works well.
Bzr is reliable - A massive suite of unit-tests and a commitment to their excellence offers some comfort that I won’t be left holding half of my code in one hand and an ugly binary blob in the other.
9) Most of all, its a feeling. Its hard to explain, but I don’t notice bzr. Its just there, and I just have my code. I rarely take notice of it, and don’t focus on it. I spend 99% of my time coding and every 30 min I enter a terminal for a few seconds to do all my DRCS stuff. Maybe its why people who use Bzr aren’t very vocal about it. Its not a revolution in revision control, and I don’t do a million cool things in it. I just write code, and bzr is there, doing whatever it does.
If your in the greater Salt Lake area and love python swing by the meeting this evening! We’re doing a python editor head-to-head, should be fun!
So I noticed that one of the accepted proposals for the Mono project is to create a LINQ provider for SQLite. Major props to this (its something I totally want to see!) and I’m glad to see that LINQ in Mono is going to be its own beast, I love it when the FOSS community just takes a technology and runs with it! Anyways, I wanted to try and get in touch with the mentor/student of this project and share my experience (as the author of the current LINQ to SQLite component ). But contact info seemed hard to come by, so I thought I would post what I had learned.
First, people really want this, and there are several half-complete implementations floating around, including mine (read only, no commit/update/delete support) and this one.
Second, support for just queries is quite easy. Support for complete CRUD, tedious but not to difficult (lots of examples already exist). Support for the generation/mapping/reflection of a database to real Linq objects, this is the tricky part (specifically the UI elements when unable to just piggyback the Visual Studio work).
Anyways, all the luck in the world to this GSOC project, I would really like to see a working implementation come from this!
So, if you live in the greater Salt Lake City area, there’s a pretty cool low key (and free!) conference coming up, the Utah Code Camp. I’ll be doing a little talk on getting data out of HTML with Python (utilizing lxml and twill). If your interested, you can register here.
So if your like me, you’ve been suffering through some painful sound problems in Ubuntu Hardy, apparently its a known kernel issue, so just sit tight. However, if your like me (or 90% of nerds) then you need some sort of music to code. A little digging revealed that I did not in fact have any of the alsa kernel modules installed for my current kernel. apt-get left me high and dry (also without an nvidia driver yet, but that’s an easy fix).
The simple remedy is to just build the alsa modules yourself, a pretty painless task. The problem is, if you want to have any hope of keeping your install halfway clean, then you need to get those files tracked by dpkg so we avoid conflicts when the modules are fixed. There’s a simple solution:
sudo apt-get install module-assistant
sudo m-a update
sudo m-a prepare
sudo m-a a-i alsa
This utilizes the handy module-assistant package to automatically build alsa for you. 
Reboot and enjoy!
So I just returned from my massive onslaught of travel that started with PyCon, took me from one US coast to the other, a Carribean island, and then back home to Washington D.C. I’m on Spring Break for the rest of the week, and hope to get some good blog posts in reguarding the awesomness that was PyCon 2008!
So the more I work with Django the more I long for a solid development environment to work in. I use Wingware for much of my python development, with its rockin debugger and code completion, its more than I could ask for. Until the curse of the Java class. This quarter I’m taking a Java projects course, most of the class uses Eclipse but a few use Netbeans. My problem is, I got spoiled so fast by the incredible templates support, content suggestions, quick fixes and always dead on code completion. Going back to Wing feels like a halfway-there IDE. I know that pythons interpreted nature makes source completion much more difficult, now I would argue that with an interpreter, you could actually step through the code to some extent. However, I respect that dynamic objects are never gonna be easy to support. My beef is with the lack of support for super-popular frameworks (this goes for everybody!) Ruby on Rails has literally dozens of solid IDEs and a few that are just spectacular (see Aptana, or Netbeans). Why can’t I get even basic highlighting support for my Django templates? Why can’t I get any completion options on Models except my own?
Its just frustrating, Django is still a pleasure to develop in, even with just Gedit and a terminal, but is it really out of the question to consider providing a big pretty environment for those of us that like that?
I did dig up this and this. I guess its a step in the right direction, but its almost embarrassing next to the Rails environments.
So I just finalized my registration for PyCon and booked my flight! I can’t even begin to express my excitement! If anyone else plans on attending, I made a wiki page for you to add your name to!
See you there!
So I attempted to migrate my blog from Wordpress to Movable Type Open Source. I’ll go into specifics later, but suffice to say that it was a miserable failure. Problems with planets, constant admin interface crashes, extremely spamable, and most of all, just unusable.
As a result of my reversion back to Wordpress, I have lost a few posts, I will try to migrate them back, but its possible I’ll just do a major ‘things that we have missed’ post in a bit. Anyway, more updates coming soon.
I've been working on and off on a writeup concerning the use of Beagle to build an intelligent 'rank' for desktop entities. Or, in short, a Ranking system (not unlike Page Rank or the like) to organize desktop search results by far more than just keyword/date. I know the writing sucks, and its not 100% complete yet. In addition, I don't have much in terms of code to share (yet). To summarize (for those lazybones out there) I'm thinking of utilizing fairly universal and constant relationships (Creator, Creation Date, Modification Date(s), Parent/Source, and maybe others) to recurse deep into desktop relationships. By adding relevancy to the root hit for every child it has (logarithmically decreased by recurse iteration) we can have far more accurate desktop search results when querying a simple keyword/phrase. In addition, the children of a hit could often be considered hits themselves, if found in enough 'root' hits. Its a loose and patchy idea, and miles from a realistic implementation, however, thanks to the awesomeness of Lucene, comparing 2 in-index documents for textual relevancy (based on Term Frequency) is not impossible. (I have not considered the performance elements of these comparisons yet, they may be too slow to be realistic without serious optimization) Anyways, I'm working on it in Google Docs, so you can check out the full document here. I'll post once I've finished my research/planning etc. Please, share your thoughts! This is in the 'major brainfart' stage, so its open to whatever from anyone, I want to hear ideas! Technorati Tags: beagle, desktop search, lucene, search rank, gnome, mono
Powered by ScribeFire.
Beagle support in Ubuntu has been less than stellar up until this point (across all releases), and unfortunately, the best that we can really hope for in the immediate future is acceptable. This is mostly because only a few of Beagle's developers are running Ubuntu, and accurately reproducing common errors is difficult. To top this all off, the defacto Ubuntu contact at this point is me, and I haven't had the available time to really track down some of the more difficult bugs.
However, this problem reached an all time low when the beagle source package stopped building in Gutsy. This spurred us into action (our urgency increasing as we realized how close Gutsy was to shipping) and as a result there exist updated Ubuntu Gutsy packages (based upon the new 0.2.18 bugfix release of Beagle) available for testing. Thanks to Launchpads new super-awesome Personal Package Archive system, you only need to add the following sources, or download from the corresponding link. (NOTE! the versioning of these debs will not force an update if they are accepted into main, you will need to reinstall should they be accepted at their current version number!)
deb http://ppa.launchpad.net/kkubasik/ubuntu gutsy maindeb-src http://ppa.launchpad.net/kkubasik/ubuntu gutsy main
Please report bugs with these packages either to Beagle in launchpad or the dashboard-hackers mailing list. The more feedback we get in the next few days the better the chance that Ubuntu Gutsy will ship a solid Beagle.
Ok, I replaced our original autocomplete system with something a little more reserved, and based on a Gtk.Entry. Stealing heavily from a little-known F-Spot widget, I concocted a simple tagbar. Tab cycles through the completions and Enter selects. To give a rough idea of whats going on I made a quick screencast.
Let me know what you all think, if this is what we want to base our work on, then I'll clear out the almost 500 lines of commented code from our past revisions. If we need to try something new, we can do that to.
Ok, I replaced our original autocomplete system with something a little more reserved, and based on a Gtk.Entry. Stealing heavily from a little-known F-Spot widget, I concocted a simple tagbar. Tab cycles through the completions and Enter selects. To give a rough idea of whats going on I made a quick screencast.
Let me know what you all think, if this is what we want to base our work on, then I’ll clear out the almost 500 lines of commented code from our past revisions. If we need to try something new, we can do that to.
Well be hacking it up tonight at 6:00PM MST at the Novell Open Source Technology Center. The rough TODO for the night seems to be Tags, Tasks and maybe even a backend to query Beagle. ;) Anyways, if your in the greater Salt Lake City area, come on down! If your a little further away but want to join in anyways, join in on #tomboy! See you tonight!
Ok, so some of you may have noticed I've been a little quiet lately, over this time of non-blogging I built up a dozen great ideas for entries, and collected the photos to flesh them out. However, I am far to lazy, so you all get this little summary post instead. Let me apologize upfront, these were all taken with a cruddy phone. I'll have another post with my technical musings later this week.
- Who knew Utah was so cool! After attending the Ubuntu-Utah group meeting, I was floored at how active the area was! Not only was the user group active, social and plenty fun, but I quickly learned about the Utah Open Source Foundation, which is (for lack of something more elegant) just plain awesome, the guys that run it could not be doing a better job. It was at a Multi-Distro Release Party (graciously hosted by Novell at their Open Source Technologies Center) that I caught this amusing moment, after Ubuntu is Linux for Human Beings, there aren't age limits ;)
- Some (hopefully legal) shots of the Novell Provo campus, its quite nice:
- Another fun tidbit about Salt Lake City, they have not only the best burrito joint on earth, but random neon orange flags at street crossings...
So, I've heard a lot of hype about the upcoming 1.2.6 release of Mono being faster, leaner, and more stable then ever before (due largely to Novell's acquisition of a QA team dedicated to Mono). Beagle has always gotten flack over memory use, and as a result, we are relentless in our hunt for abused memory. And while it is wonderfully satisfying to reduce memory usage, its really hard to beat dropping megabytes of resident memory for free :). I'm running Ubuntu Gutsy and its 1.2.4 release of Mono, but in my quest for some real numbers to back up all this talk I built the current SVN trunk of Mono. Even my most optimistic expectations put our potential benefit around maybe 2 or 3 MB resident less than beagle running under Mono 1.2.4. On my test setup, Beagle 0.3pre consumed (after my recent Opera backend fix) around 110 MB of VM and 36 MB of RSS (averaged over a 2 hour run). After building and installing Mono 1.2.6, the same 2 hour run was averaging 72 MB of VM and 27 MB of RSS! Its still far from perfect, but free memory reduction is just plain cool :). Some observations about the general pattern of allocation and collection under 1.2.6, it 'idles' much lower than 1.2.4. While some actions always push the memory usage up, 1.2.6 *appeared* to return to its lower memory point much faster, and more regularly. Anyways, I just wanted to say, props to everyone on the Mono team for rocking my socks. So, I've heard a lot of hype about the upcoming 1.2.6 release of Mono being faster, leaner, and more stable then ever before (due largely to Novell's acquisition of a QA team dedicated to Mono). Beagle has always gotten flack over memory use, and as a result, we are relentless in our hunt for abused memory. And while it is wonderfully satisfying to reduce memory usage, its really hard to beat dropping megabytes of resident memory for free :). I'm running Ubuntu Gutsy and its 1.2.4 release of Mono, but in my quest for some real numbers to back up all this talk I built the current SVN trunk of Mono. Even my most optimistic expectations put our potential benefit around maybe 2 or 3 MB resident less than beagle running under Mono 1.2.4. On my test setup, Beagle 0.3pre consumed (after my recent Opera backend fix) around 110 MB of VM and 36 MB of RSS (averaged over a 2 hour run). After building and installing Mono 1.2.6, the same 2 hour run was averaging 72 MB of VM and 27 MB of RSS! Its still far from perfect, but free memory reduction is just plain cool :). Some observations about the general pattern of allocation and collection under 1.2.6, it 'idles' much lower than 1.2.4. While some actions always push the memory usage up, 1.2.6 *appeared* to return to its lower memory point much faster, and more regularly. Anyways, I just wanted to say, props to everyone on the Mono team for rocking my socks.
Google Docs has revolutionized the office suite, namely the word processor. Collaboration is easy, smooth, integrated, and automatic, whats more all your documents are accessible from anywhere, and all the common features I need are present. While I don't really use spreadsheets very often, my few simple instances of using Google Doc's for spreadsheets were easy enough. Needless to say, when I heard that a Presentation component was to be added I was excited. Now, I'm a far cry from a Powerpoint Guru, I've used it maybe 2 times, but with an upcoming presentation and the Ubuntu Utah user group, I figured I should probably slap a few slides together. Since I want to have a sane contingency for the exploding laptop, forgotten laptop, or limited presentation machine, I figured this would be a great chance to stretch my presenting legs and give it a try. Too bad I'm not that lucky, I was unable to save _any_ changes, just create a new presentation, modify it as much as I wanted, but any close would lose all my work... lovely (this is in Firefox 2.0, 3.0 trunk, IE7, and Opera 8.24). I'm willing to give Google a few hours and then try again (its possible its some small downtime, its still beta after all ;) ). Another gripe (as I read the Help to try and find similar reports of such bugs) is that there is a very limited selection of templates, while I might be able to upload new templates authored in PowerPoint or OpenOffice, couldn't they at least let me change the color schemes? (If I can and I'm just missing how to do it, please share!) I'll post an update soon, and let you all know if I had any luck saving anything.... Update: This is fixed, and now its kinda cool! I'm going to try it this Saturday at the Ubuntu Utah users group and see how it goes.
So its not a big surprise that an oft-requested feature for Beagle is the ability to index a users Gmail messages (like Google Desktop Search). Today we (the Beagle developers) started to investigate just how this is done. While POP3 (and now IMAP) are available, downloading all of a users mail, indexing it, and then caching the text so we can display it. Now, my initial investigation into GDS for Linux revealed that it was calling home via POP3s and downloading lots of data. I have assumed that it was simply iterating over all messages (via POP3), downloading them, indexing them, and caching the compressed content somewhere in Google's custom indexes. Now, I had originally planned on this post being an open plea to any and everyone at Google asking them to open up the Gmail access API, but seeing as its just the plain old ugly POP3 (maybe a cool extension), were stuck biting the bullet and implementing a remote mail access layer. Anyways, given how incredible Google has been in a million other situations, I thought I would throw out 2 wildly out-of-this-world questions, I wouldn't expect to get a response, but before I spend the time figuring it all out, I felt like I should at least ask.
- Are there some special POP Extensions available in Gmail? Is there some helper web api? Or does GDS really just have a POP3 crawler?
- Is your compression/text storage library open source? (or documented in some research paper at all?) Beagle has always struggled with how to best handle storing copies of a documents text so that it might be made available in interfaces. While we do have a new hybrid text cache (text over 4k on the filesystem, under in a sqlite db, all compressed) we were still no where near as small as the GDS indexes. A cursory examination reveals that the GDS indexes are some form of b-tree on disk, but how are you compressing all that text so small? Is there some substitution/reconstruction algorithm? (It seems like that would be wildly expensive, but who knows).
Ok, so I was stamping out a recent (quite simple) assignment for a class. The assignment required the separation of each place value in an integer. Since the information came into the program as a string, I stamped out a simple solution using some easy loops and handy methods available in the String class (of the .Net 2.0 class libraries). However, a quick skim over the rubric included 5% for correctly using div and mod to parse out the integer values. I immediately flipped back into my program, then froze for a second..
then another...
then 2 more...
I was completely blanking. I know its a simple task, its just I have become so accustomed to the incredible abundance and availability of a dozen methods for every little task that I blanked for a good minute, just stonewalled. I knew I had written this code before, everyone has done it at least once in some 'Intro to Programming Theory' class, and the concept was easy enough, but it just wouldn't come. Cursing the professor for such a trivial demand, I went and got a cup of coffee.
Upon returning I realized how stupid and petty I was being. While I do often rely on cool class libraries and the methods they provide, I really just have to stop being so self-righteous and realize how likely it was that much of the class would be completely stuck on such a task. We spend so much time today learning about existing technologies and API's that we forget the core of programming: Problem Solving.
I quickly slapped together the following C# method:
static int[] toIntArray(string input)
{
int i = 0;
int digit;
List<int> ints = new List<int>();
for (int numdigits = input.Length; numdigits > 0; numdigits--)
{digit = Convert.ToInt32(input) / (int)Math.Pow(10.0, (double)(numdigits - 1));
digit = digit % 10;
ints.Add(digit);
i++;
}
return ints.ToArray();
}
In retrospect, its quite simple, I just hope that this was my 'moment of realization' and I don't get so inundated again as to the point where I can't do the simple stuff on my own anymore.
Ok, so as many of you may have noticed in my last post I've taken a real interest in C# 3.0 and its new nifty features. Now, I'm mostly just excited for the simple collection manipulations, but the whole Linq to SQL thing is nagging in the back of my mind. Now while complete CRUD will no doubt take some serious code, simple query support is not that difficult to implement. After following mattwar's blog series on a generic DB provider for Linq, I decided that I wanted that awesome glory against a lean and mean sqlite db. So, about an hour or so of messing and meddling I have a few samples working. (The attached zip) Its a Visual Studio 2008 Beta 2 project (I'll be writing autotools magic for mono later this week) so sorry for that, the code can still be imported into Monodevelop, just the solution/project files won't work. Anyways, I have tested a smattering of JOIN's and all sorts of simple selects without issue. However, the elements of sqlite that behave differently tend to do so silently and without complaint, making it harder to be certain that everything is working. However, I'm planning on fleshing out a set of test queries, however, for now I could really just use the help with testing/checking the SQL (as I'm no sqlite Guru). Known Issues
- DataType sloppyness - I hope to handle this better (storing a DateTime string in TEXT would extract to DateTime successfully) right now you need to pretty much just use strings or numeric values.
- Inefficient Queries - Not being a Sql master, I can't say that much of whats generated is the best way to do things, please, if you know then share!
- OrderBy issues - Its just hard as heck to get working, it seems to work fine sometimes, but no promises.
linqtosqlite.zipad
I'm looking at db_linq, which is a full (bi-directional, change tracking, general awesome crazyness) solution, this is really just a way to query sqlite db. I might try to add a sqlite provider to db_linq at some point, its just that their system is very different from my implementation, so there wouldn't be too much shared code. :(
Ok, so I'm sure most MS .Net dev's have already seen these posts far too many times, for the Mono users out there, I have a little treat. While Moonlight and WPF get tons of hype, I think the biggest and most exciting change coming soon to a C# compiler near you is support for lambda expressions, anonymous types, and extension methods.
Now on the whole this doesn't sound all that exciting, I mean, before a few months ago, I had never really used lambda expressions to accomplish much beyond pass that unit in an intro to CS class. Individually, there's nothing to jump for joy about, but when used in conjunction, we can produce startlingly clean and readable code.
To demonstrate this I've whipped up two examples that I was fiddling with as I read a million tutorials. They aren't fancy XML or Database providers, just some simple (and quite common in my experience) text parsing tasks that have disproportionately complex code. We will use some of the new C# 3.0 features to make far cleaner and more readable code.
The first example is an exclusion string, or a set of characters that are not allowed in another.
var illegalchars = "abcdefg";
string testString1 = "Kevin";
string testString2 = "hijkmlppp";
The 'old' way of checking both strings for one of the illegal chars:
foreach (char c in illegalchars) {
if (testString1.Contains(c) || testString2.Contains(c))
Console.WriteLine("illegal char!");
}
Using awesome new stuff:
if (testString1.Intersect(illegalchars).Any()
|| testString2.Intersect(illegalchars).Any())Console.WriteLine("Linq found it too");
Our next example is 'exploding' or splitting a series of values out of a string (CSV and PSV are common examples of this) into an array:
string pipeDelined = "Kevin | McCool | Kubasik";
An old solution might have been (I know we could optimize this, or clean it up, just making a point ;) ):
List<string> names = new List<string>();
foreach (string s in pipeDelined.Split('|')) {
var ts = s.Trim();if (ts == "") continue;names.Add(ts);
}
var allNames = names.ToArray();
Using our cool new C# 3.0 tools, we can change this to the super-sexy:
var allLinqNames = pipeDelined.Split('|')
.Select(s => s.Trim()).Where(s => s != "").ToArray();
While a hardened child of OOP (via C# and Java) might baulk at the new syntax, I think that it can quickly start to grow on a developer. Moreover, it has the distinct advantage of being unambiguous, and makes reading someone else's dense code much more fluid.
I really can't wait for C# 3.0, and not for those flashy API's, just the simple syntactical sugar that is already making me lazier by the minute.
It happens.. even running on so little sleep, I still find myself waking. Fortunately, this time I awoke with an awesome realization. I've been pounding my brain against the wall for a week now on how to further refine/increase the accuracy of my original relation-based ranking system. My initial results had been less than stellar when unleashed upon the desktop as a whole. In controlled situations (where my defined relationships weight's were proportionate and scaled) the results were excellent, but I was hoping this 'lowest common denominator' of sorts would be the answer. I was mistaken. After being more or less tossed back to square one, I was less than optimistic to say the least. However, at 2:30 this morning all that seems irrelevant, as I believe I have determined the key to blazingly accurate desktop search results (specifically over large search sets, to the order of shared drives with thousands of documents, images, e-mails and other media files without any real semantic system to start). In my original design I made the mistake of utilizing fixed-proportion weights for my relationships. A similar mistake as seen in many ObjectRank based systems. PDF Alert! By fixed proportion, I mean that an astronomical amount of time has gone into determining how important an 'author' relationship is when compared to a 'creation date' relationship. I (like many before me) was using a weight x termsimilarityindex type system for each relationship. As a result I was spending tons of time and effort trying to strike the proper balance, and in most cases when I got one situation to work, I completely destroyed another. I think my < sarcasm > brilliant </sarcasm > revelation is becoming obvious, but bear with me. We cannot pretend that authorship means the same thing to all users, a simple example is the large number of users who still operate relatively isolated desktops, where they are the only author for most of the content. if someone email's them a document, it will have a hard time weighing up. However, creation date/modification date would probably serve as a solid indicator of relationship, as one person can really only work on one thing at a time. I wish I had something better to show than just this (I'm mostly writing this down so I don't forget it in the morning :) ) but I've determined that we need a deeper dimension of weight on relationship weighting (when scoring). While one possibility is to just add another variable to our existing weight-determination system, I am leaning towards something more broad. What if the programmer only had to specify a relationship, and through a combination of its occurrence, how closely it paralleled term-based similarity, and how often that relationship type was used to rank a selected result (would require gui integration, but for this proof of concept thats ok in my head) to build an individualized weight for each relationship. All of a sudden, the massive programmer burden of a relational ranking system is removed! (it takes a lot of specific code to handle each relationship and its weights/different characteristics properly) While there would be a massive front-end cost to tweaking and tuning the system which determines those individual relationship weights, it would be time well spent, as new data types/sources are added, there is no additional work beyond declaring/mapping the relevant relationships. Once the sun has actually risen, I'll try to start the process of actually codifying what I'm trying to say. If I've actually made enough sense that anyone understands what I'm getting at and has any thoughts/comments/criticisms, please share!
It looks like the monster might finally start to lay itself to rest. After almost 2 years, one of the most basic feature requests for Banshee looks like it will finally be fulfilled. I'm talking about playlist syncing to iPods. While there have been a plethora of patches in varying states of readiness always floating around, it just never got into trunk. I am very pleased to have checked in a working (and building at the moment) patch which enables the management of iPod playlists though banshee. I know that the patch has been in better shape, there were a dozen different times that a commit might have made sense, but in the end, ipod-sharp is a moving target, and trying to hit it and Banshee with stable API's at the same time (without a freeze ;) ) has proven to be quite difficult (no hard feelings to the Banshee dev's they keep new features coming, and fast). Anyways, there are a few known bugs with this patch, most of which (in my super-limited testing) stem from ipod-sharp being in the middle of an API shift, and trunk isn't working. Anyways, I wanted to make a list of Features and Bugs, namely so the 2 don't get confused, since a big part of this patch was trying to determine exactly what 'expected behavior' was, theres a lot of room to grow. Known Bugs
- Major Performance Issues - This just needed to eventually go in, and maybe the new ipod-sharp api will have a better solution, but I started working on this, everything (meaning the entire music library) must be iterated over to find a corresponding track. Some preliminary work was done to get more content sorted/hashed, but theres still a lot of work to do here.
- Double Tracks on IPod - Depending on your version of ipod-sharp, and what random steps you take to get things building against your version, there is a common issue where a Playlist Dragged from the Library onto an iPod will result in duplicates of every song in the playlist on the iPod. This should be easy enough to track down if someone just has the time and patience.
- New ipod-sharp API - As there will eventually be a new ipod-sharp API, someone needs to migrate the current logic to the new API, should be mostly the same except for the device detection logic.
- A Playlist from the Library to the iPod with the same name will result in the iPod version being overwritten.
- Dragging a track from the library to a iPod playlist will result in that track being copied to the iPod again
- Click and Drag support for playlist's on iPod, its recommended that you drag songs from the iPod's library
- Rename of iPod playlists
- Does not synchronize all library playlists to iPod automatically, only those which are placed onto the iPod
Note: I've tested this with the latest iPod Firmware, if you run the Hash tool as you normally would, it should work fine.
Today I checked in a few fun changes to Beagle today focused on the idea of emphasizing relationships between entities. It doesn't sound like a whole lot of fun, but its kinda nifty. New Query Context Options
- Find Documents by same author.
- Find E-mails from same contact.
- Find Pages from same site.
Beagle's powerful and simple query language makes stuff like this really easy, its just a matter of knowing what properties warrant special treatment like this. I'm open to ideas, what
A successful (so far) Wordpress upgrade. Version 2.3 seems cool enough, If you spot a problem, please let me know! Edit: It appears that I may have spoken too soon... Some fickle behavior from plugins that used to like categories, but I guess that was to be expected. =/
Alright! Some cool news! The Mono Hackfest at the Novell OSTC in Provo, Utah was a success ( I would say, people showed up and we talked about features 
) And while I took several photos in the hope that I might have another photo-riffic blog post, but alas, my flash wasn’t on, and they are all pretty much worthless. That aside, it was pretty cool to root around more of the Novell OSTC campus.
As a by-product of the ‘Hack’ing portion of the hackfest, I am happy to report the enabling of tagging in Tomboy, while we are still working out the specifics of the tagging interface, a super-experimental version of our newest iteration (based somewhat strongly on the Blogger.com tagging interface which we all agreed was somewhat well designed). While this is mostly implemented, there are a few issues (mostly based on my lack of Gtk knowledge/experience) with some of the autocomplete logic. I basically created a new Gtk Window which is composed of a ListView and hovers over the entry area (actually a GtkTextView, as a GtkEntry wouldn’t handle text markup). There are 2 real problems at the moment.
- I need to handle keyboard input intelligently enough to allow selection of an autocomplete option, I just need someone more familiar with how keypress events are handled to take a look at my code and figure out what widgets I should listen to the keypress events on etc.
- I need to get the autocomplete popup widget to show in the right place (should be easy enough to get, again I just need someone a little more familiar with the Gtk API so I don’t spend another hour looking for the window positioning information.) and the widget needs to close when a note is closed. (Right now the autocomplete box hangs around, should again just be subscribing to a window destroy event, but my previous attempts have resulted in some messes.)
Anyways, if anyone has the time to offer a hand/check any of this out, just drop by #tomboy (I’ll be in and out due to exams, but I’ll do my best to answer any questions) or feel free to just fix it right off the bat Here’s a quick and dirty screenshot of the problem as it exists (you can see the autocomplete dropdown isn’t quite right).
In addition to traditional tags, we have added a new little tidbit for Addin Developers, the concept of System Tags. In short, any tag added to a Tomboy note with the system: prefix will not be displayed. While this seems a little stupid at first glance, this allows us to easily implement things like Tasks, and allow Addins to associate their own data with tags while not implementing their own data store, and still maintaining backwards compatibility. For example if I wanted to implement ‘Contacts’ in Tomboy (NOT A FEATURE THAT SHOULD BE IMPLEMENTED IMHO) I could simply add the following tags to store all the information I needed for my Addin:
- system:Contact
- system:FirstName:Kevin
- system:LastName:Kubasik
- system:EMail:KevinAtKubasikDotNet
And so on, anything with the ’system:’ prefix will be hidden from the user, but still stored with each note.
Well be hacking it up tonight at 6:00PM MST at the Novell Open Source Technology Center. The rough TODO for the night seems to be Tags, Tasks and maybe even a backend to query Beagle. ;) Anyways, if your in the greater Salt Lake City area, come on down! If your a little further away but want to join in anyways, join in on #tomboy!
See you tonight!
Ok, so some of you may have noticed I’ve been a little quiet lately, over this time of non-blogging I built up a dozen great ideas for entries, and collected the photos to flesh them out. However, I am far to lazy, so you all get this little summary post instead. Let me apologize upfront, these were all taken with a cruddy phone. I’ll have another post with my technical musings later this week.
- Who knew Utah was so cool! After attending the Ubuntu-Utah group meeting, I was floored at how active the area was! Not only was the user group active, social and plenty fun, but I quickly learned about the Utah Open Source Foundation, which is (for lack of something more elegant) just plain awesome, the guys that run it could not be doing a better job. It was at a Multi-Distro Release Party (graciously hosted by Novell at their Open Source Technologies Center) that I caught this amusing moment, after Ubuntu is Linux for Human Beings, there aren’t age limits
- Some (hopefully legal) shots of the Novell Provo campus, its quite nice:
- Another fun tidbit about Salt Lake City, they have not only the best burrito joint on earth, but random neon orange flags at street crossings…
So, I’ve heard a lot of hype about the upcoming 1.2.6 release of Mono being faster, leaner, and more stable then ever before (due largely to Novell’s acquisition of a QA team dedicated to Mono). Beagle has always gotten flack over memory use, and as a result, we are relentless in our hunt for abused memory. And while it is wonderfully satisfying to reduce memory usage, its really hard to beat dropping megabytes of resident memory for free :). I’m running Ubuntu Gutsy and its 1.2.4 release of Mono, but in my quest for some real numbers to back up all this talk I built the current SVN trunk of Mono.
Even my most optimistic expectations put our potential benefit around maybe 2 or 3 MB resident less than beagle running under Mono 1.2.4. On my test setup, Beagle 0.3pre consumed (after my recent Opera backend fix) around 110 MB of VM and 36 MB of RSS (averaged over a 2 hour run).After building and installing Mono 1.2.6, the same 2 hour run was averaging 72 MB of VM and 27 MB of RSS! Its still far from perfect, but free memory reduction is just plain cool :).
Some observations about the general pattern of allocation and collection under 1.2.6, it ‘idles’ much lower than 1.2.4. While some actions always push the memory usage up, 1.2.6 *appeared* to return to its lower memory point much faster, and more regularly.
Anyways, I just wanted to say, props to everyone on the Mono team for rocking my socks.
Google Docs has revolutionized the office suite, namely the word processor. Collaboration is easy, smooth, integrated, and automatic, whats more all your documents are accessible from anywhere, and all the common features I need are present. While I don’t really use spreadsheets very often, my few simple instances of using Google Doc’s for spreadsheets were easy enough. Needless to say, when I heard that a Presentation component was to be added I was excited.
Now, I’m a far cry from a Powerpoint Guru, I’ve used it maybe 2 times, but with an upcoming presentation and the Ubuntu Utah user group, I figured I should probably slap a few slides together. Since I want to have a sane contingency for the exploding laptop, forgotten laptop, or limited presentation machine, I figured this would be a great chance to stretch my presenting legs and give it a try. Too bad I’m not that lucky, I was unable to save _any_ changes, just create a new presentation, modify it as much as I wanted, but any close would lose all my work… lovely (this is in Firefox 2.0, 3.0 trunk, IE7, and Opera 8.24). I’m willing to give Google a few hours and then try again (its possible its some small downtime, its still beta after all ).
Another gripe (as I read the Help to try and find similar reports of such bugs) is that there is a very limited selection of templates, while I might be able to upload new templates authored in PowerPoint or OpenOffice, couldn’t they at least let me change the color schemes? (If I can and I’m just missing how to do it, please share!)
I’ll post an update soon, and let you all know if I had any luck saving anything….
Update: This is fixed, and now its kinda cool! I’m going to try it this Saturday at the Ubuntu Utah users group and see how it goes.
So its not a big surprise that an oft-requested feature for Beagle is the ability to index a users Gmail messages (like Google Desktop Search). Today we (the Beagle developers) started to investigate just how this is done. While POP3 (and now IMAP) are available, downloading all of a users mail, indexing it, and then caching the text so we can display it. Now, my initial investigation into GDS for Linux revealed that it was calling home via POP3s and downloading lots of data. I have assumed that it was simply iterating over all messages (via POP3), downloading them, indexing them, and caching the compressed content somewhere in Google’s custom indexes.
Now, I had originally planned on this post being an open plea to any and everyone at Google asking them to open up the Gmail access API, but seeing as its just the plain old ugly POP3 (maybe a cool extension), were stuck biting the bullet and implementing a remote mail access layer.
Anyways, given how incredible Google has been in a million other situations, I thought I would throw out 2 wildly out-of-this-world questions, I wouldn’t expect to get a response, but before I spend the time figuring it all out, I felt like I should at least ask.
- Are there some special POP Extensions available in Gmail? Is there some helper web api? Or does GDS really just have a POP3 crawler?
- Is your compression/text storage library open source? (or documented in some research paper at all?) Beagle has always struggled with how to best handle storing copies of a documents text so that it might be made available in interfaces. While we do have a new hybrid text cache (text over 4k on the filesystem, under in a sqlite db, all compressed) we were still no where near as small as the GDS indexes. A cursory examination reveals that the GDS indexes are some form of b-tree on disk, but how are you compressing all that text so small? Is there some substitution/reconstruction algorithm? (It seems like that would be wildly expensive, but who knows).
Anyways, its a long shot, and its pretty far out there, but for the sake of not passing up answers that I can’t seem to find elsewhere on the net, I have asked.
Ok, so I was stamping out a recent (quite simple) assignment for a class. The assignment required the separation of each place value in an integer. Since the information came into the program as a string, I stamped out a simple solution using some easy loops and handy methods available in the String class (of the .Net 2.0 class libraries). However, a quick skim over the rubric included 5% for correctly using div and mod to parse out the integer values. I immediately flipped back into my program, then froze for a second..
then another…
then 2 more…
I was completely blanking. I know its a simple task, its just I have become so accustomed to the incredible abundance and availability of a dozen methods for every little task that I blanked for a good minute, just stonewalled. I knew I had written this code before, everyone has done it at least once in some ‘Intro to Programming Theory’ class, and the concept was easy enough, but it just wouldn’t come. Cursing the professor for such a trivial demand, I went and got a cup of coffee.
Upon returning I realized how stupid and petty I was being. While I do often rely on cool class libraries and the methods they provide, I really just have to stop being so self-righteous and realize how likely it was that much of the class would be completely stuck on such a task. We spend so much time today learning about existing technologies and API’s that we forget the core of programming: Problem Solving.
I quickly slapped together the following C# method:
static int[] toIntArray(string input)
{
int i = 0;
int digit;
List<int> ints = new List<int>();
for (int numdigits = input.Length; numdigits > 0; numdigits–)
{digit = Convert.ToInt32(input) / (int)Math.Pow(10.0, (double)(numdigits - 1));
digit = digit % 10;
ints.Add(digit);
i++;
}
return ints.ToArray();
}
In retrospect, its quite simple, I just hope that this was my ‘moment of realization’ and I don’t get so inundated again as to the point where I can’t do the simple stuff on my own anymore.
Ok, so as many of you may have noticed in my last post I’ve taken a real interest in C# 3.0 and its new nifty features. Now, I’m mostly just excited for the simple collection manipulations, but the whole Linq to SQL thing is nagging in the back of my mind. Now while complete CRUD will no doubt take some serious code, simple query support is not that difficult to implement. After following mattwar’s blog series on a generic DB provider for Linq, I decided that I wanted that awesome glory against a lean and mean sqlite db.
So, about an hour or so of messing and meddling I have a few samples working. (The attached zip) Its a Visual Studio 2008 Beta 2 project (I’ll be writing autotools magic for mono later this week) so sorry for that, the code can still be imported into Monodevelop, just the solution/project files won’t work. Anyways, I have tested a smattering of JOIN’s and all sorts of simple selects without issue. However, the elements of sqlite that behave differently tend to do so silently and without complaint, making it harder to be certain that everything is working. However, I’m planning on fleshing out a set of test queries, however, for now I could really just use the help with testing/checking the SQL (as I’m no sqlite Guru).
Known Issues
- DataType sloppyness - I hope to handle this better (storing a DateTime string in TEXT would extract to DateTime successfully) right now you need to pretty much just use strings or numeric values.
- Inefficient Queries - Not being a Sql master, I can’t say that much of whats generated is the best way to do things, please, if you know then share!
- OrderBy issues - Its just hard as heck to get working, it seems to work fine sometimes, but no promises.
Anyways, play around, have fun, and note that you need the Sqlite provider for ADO.Net (duh).
I’m looking at db_linq, which is a full (bi-directional, change tracking, general awesome crazyness) solution, this is really just a way to query sqlite db. I might try to add a sqlite provider to db_linq at some point, its just that their system is very different from my implementation, so there wouldn’t be too much shared code. 
Ok, so I’m sure most MS .Net dev’s have already seen these posts far too many times, for the Mono users out there, I have a little treat. While Moonlight and WPF get tons of hype, I think the biggest and most exciting change coming soon to a C# compiler near you is support for lambda expressions, anonymous types, and extension methods.
Now on the whole this doesn’t sound all that exciting, I mean, before a few months ago, I had never really used lambda expressions to accomplish much beyond pass that unit in an intro to CS class. Individually, there’s nothing to jump for joy about, but when used in conjunction, we can produce startlingly clean and readable code.
To demonstrate this I’ve whipped up two examples that I was fiddling with as I read a million tutorials. They aren’t fancy XML or Database providers, just some simple (and quite common in my experience) text parsing tasks that have disproportionately complex code. We will use some of the new C# 3.0 features to make far cleaner and more readable code.
The first example is an exclusion string, or a set of characters that are not allowed in another.
var illegalchars = "abcdefg";
string testString1 = "Kevin";
string testString2 = "hijkmlppp";
The ‘old’ way of checking both strings for one of the illegal chars:
foreach (char c in illegalchars) {
if (testString1.Contains(c) || testString2.Contains(c))
Console.WriteLine("illegal char!");
}
Using awesome new stuff:
if (testString1.Intersect(illegalchars).Any()
|| testString2.Intersect(illegalchars).Any())Console.WriteLine("Linq found it too");
Our next example is ‘exploding’ or splitting a series of values out of a string (CSV and PSV are common examples of this) into an array:
string pipeDelined = "Kevin | McCool | Kubasik";
An old solution might have been (I know we could optimize this, or clean it up, just making a point ):
List<string> names = new List<string>();
foreach (string s in pipeDelined.Split(‘|’)) {
var ts = s.Trim();if (ts == "") continue;names.Add(ts);
}
var allNames = names.ToArray();
Using our cool new C# 3.0 tools, we can change this to the super-sexy:
var allLinqNames = pipeDelined.Split(‘|’)
.Select(s => s.Trim()).Where(s => s != "").ToArray();
While a hardened child of OOP (via C# and Java) might baulk at the new syntax, I think that it can quickly start to grow on a developer. Moreover, it has the distinct advantage of being unambiguous, and makes reading someone else’s dense code much more fluid.
I really can’t wait for C# 3.0, and not for those flashy API’s, just the simple syntactical sugar that is already making me lazier by the minute.
It happens.. even running on so little sleep, I still find myself waking.
Fortunately, this time I awoke with an awesome realization. I’ve been pounding my brain against the wall for a week now on how to further refine/increase the accuracy of my original relation-based ranking system. My initial results had been less than stellar when unleashed upon the desktop as a whole. In controlled situations (where my defined relationships weight’s were proportionate and scaled) the results were excellent, but I was hoping this ‘lowest common denominator’ of sorts would be the answer. I was mistaken. After being more or less tossed back to square one, I was less than optimistic to say the least.
However, at 2:30 this morning all that seems irrelevant, as I believe I have determined the key to blazingly accurate desktop search results (specifically over large search sets, to the order of shared drives with thousands of documents, images, e-mails and other media files without any real semantic system to start). In my original design I made the mistake of utilizing fixed-proportion weights for my relationships. A similar mistake as seen in many ObjectRank based systems. PDF Alert! By fixed proportion, I mean that an astronomical amount of time has gone into determining how important an ‘author’ relationship is when compared to a ‘creation date’ relationship. I (like many before me) was using a weight x termsimilarityindex type system for each relationship. As a result I was spending tons of time and effort trying to strike the proper balance, and in most cases when I got one situation to work, I completely destroyed another.
I think my < sarcasm > brilliant </sarcasm > revelation is becoming obvious, but bear with me.
We cannot pretend that authorship means the same thing to all users, a simple example is the large number of users who still operate relatively isolated desktops, where they are the only author for most of the content. if someone email’s them a document, it will have a hard time weighing up. However, creation date/modification date would probably serve as a solid indicator of relationship, as one person can really only work on one thing at a time.
I wish I had something better to show than just this (I’m mostly writing this down so I don’t forget it in the morning ) but I’ve determined that we need a deeper dimension of weight on relationship weighting (when scoring). While one possibility is to just add another variable to our existing weight-determination system, I am leaning towards something more broad. What if the programmer only had to specify a relationship, and through a combination of its occurrence, how closely it paralleled term-based similarity, and how often that relationship type was used to rank a selected result (would require gui integration, but for this proof of concept thats ok in my head) to build an individualized weight for each relationship.
All of a sudden, the massive programmer burden of a relational ranking system is removed! (it takes a lot of specific code to handle each relationship and its weights/different characteristics properly) While there would be a massive front-end cost to tweaking and tuning the system which determines those individual relationship weights, it would be time well spent, as new data types/sources are added, there is no additional work beyond declaring/mapping the relevant relationships.
Once the sun has actually risen, I’ll try to start the process of actually codifying what I’m trying to say. If I’ve actually made enough sense that anyone understands what I’m getting at and has any thoughts/comments/criticisms, please share!
It looks like the monster might finally start to lay itself to rest. After almost 2 years, one of the most basic feature requests for Banshee looks like it will finally be fulfilled. I’m talking about playlist syncing to iPods. While there have been a plethora of patches in varying states of readiness always floating around, it just never got into trunk. I am very pleased to have checked in a working (and building at the moment) patch which enables the management of iPod playlists though banshee.
I know that the patch has been in better shape, there were a dozen different times that a commit might have made sense, but in the end, ipod-sharp is a moving target, and trying to hit it and Banshee with stable API’s at the same time (without a freeze ) has proven to be quite difficult (no hard feelings to the Banshee dev’s they keep new features coming, and fast). Anyways, there are a few known bugs with this patch, most of which (in my super-limited testing) stem from ipod-sharp being in the middle of an API shift, and trunk isn’t working.
Anyways, I wanted to make a list of Features and Bugs, namely so the 2 don’t get confused, since a big part of this patch was trying to determine exactly what ‘expected behavior’ was, theres a lot of room to grow.
Known Bugs
- Major Performance Issues - This just needed to eventually go in, and maybe the new ipod-sharp api will have a better solution, but I started working on this, everything (meaning the entire music library) must be iterated over to find a corresponding track. Some preliminary work was done to get more content sorted/hashed, but theres still a lot of work to do here.
- Double Tracks on IPod - Depending on your version of ipod-sharp, and what random steps you take to get things building against your version, there is a common issue where a Playlist Dragged from the Library onto an iPod will result in duplicates of every song in the playlist on the iPod. This should be easy enough to track down if someone just has the time and patience.
- New ipod-sharp API - As there will eventually be a new ipod-sharp API, someone needs to migrate the current logic to the new API, should be mostly the same except for the device detection logic.
Behavior Issues/Features
- A Playlist from the Library to the iPod with the same name will result in the iPod version being overwritten.
- Dragging a track from the library to a iPod playlist will result in that track being copied to the iPod again
- Click and Drag support for playlist’s on iPod, its recommended that you drag songs from the iPod’s library
- Rename of iPod playlists
- Does not synchronize all library playlists to iPod automatically, only those which are placed onto the iPod
I think thats most of it, once iPod support in Banshee has leveled out a little bit, I plan on adding support for On-The-Go playlists and Smart Playlists. Anyways, I know that its far from a perfect commit, but after porting this patch through so many API changes, design shifts, and general bitrot, I really just wanted to get it out of Bugzilla.
The obligatory screenshot:
Note: I’ve tested this with the latest iPod Firmware, if you run the Hash tool as you normally would, it should work fine.