I have been wanting to blog about this for ages. So in November last year I decided that my old trusty Athlon XP that has served me for years was really due for replacement. It was still fast enough to run vim and Firefox and such, but the machine became annoying as soon as I switched to Gmail last Summer. The machine could just not keep up with me typing e-mail in the browser. For a very long time I have been wanting to buy a Mac Pro (or Powermac G5 before), in the end I chose for a different solution.
So I ended up buying components for a Intel Core 2 Quad, 4G RAM and RAID1 on pretty fast SATA2 disks. I bought the cheapest PCI-e video card available to drive my dual Iiyama displays. After assembling the machine myself, I loaded it with the 64-bit version of Ubuntu. Figuring out the partitions (software RAID and LVM) took a while (apparently I needed another install DVD image for this) but after that the installation process was fantastic. Completely flawless, everything worked out of the box.
The end result: my own self-built “Mac”. Everything works in Ubuntu, also suspend (what I would buy a desktop Mac for). The configuration I have right now would be impossible to get from Apple for 500 euros, and works as flawless as the Macs I have. Plus, it runs Linux which I still prefer over Mac OS X for programming tasks.
Really, really glad that I ended up getting this as my new desktop machine. I am pretty sure that my next desktop machine (which I will get in 4 years or so :) will again be a Linux machine and not a Mac. Though for laptops I still prefer Macs, sorry ;)
Oh yea, what I did learn was that I could also just have upgraded the browser to Firefox 3 on the old Athlon. Oh well, it is still amazing to watch a Quad core compile GTK+.
Even though you do really have a point that the current GtkTreeModel interface is way too complex, I am getting very, very tired about the way you are trying to get this across. We have discussed your ideas in person some time ago already and I am very well aware of the direction in which you want to head.
You are comparing GtkTreeModel and DataTable in .NET and saying that GtkTreeModel is not generic like IList is. That is a correct observation, because GtkTreeModel was not at all designed to be a generic model. Note it was named GtkTreeModel, not GModel, GtkGenericModel or whatever. It was designed to be a model for GtkTreeView and nothing else. And yes, it is being misused.
So why was GtkTreeView not designed like that? Well, you give the answer to that yourself in your earlier blog entry: we did not have a collection framework.
Doing it right, like .NET does, requires a collection framework. You are talking about IList and IList is a part of .NET’s collection framework. I am not at all opposed to walk this route and introduce proper models in GTK+ and GtkTreeView can then also use these. But it is not at all fair to keep comparing .NET’s generic data binding with the current non-generic GtkTreeModel.
For some reason you feel obliged to mention that the .NET implementation will only access data of visible entries. You know that for GtkTreeView the same holds if you are using fixed height mode. And you also know that I have been working on patches that will remove the validation process that has to iterate over the entire model in advance, making it possible to work with very large models without using fixed height mode. In fact, this will deprecate fixed height mode.
It is easy to pick on work people have been maintaining in their spare time, but it does not provide a form of motivation nor encouragement.
This year’s lowlands festival started on Friday. For the last six editions I have been there, but we are missing out on this one. Also because it was sold out incredibly early, I think they broke a record with that. More importantly, we are not going because the line-up totally sucks this year. In a news article today they reviewed the Friday evening and mentioned there was dance, rock and even metal. Like having metal is special, I mean the previous incarnations of lowlands always had a very large share of punk, metal and alternative bands. Unfortunately, that has really been on the decline over the last few years. This also attracted a different kind of people and the real authentic “lowlands feel” that I felt during the first time I went really started to evaporate in the last few years.
Too bad really. We’re opting for proper concerts instead these days (and living in Amsterdam is very helpful for that :). We will be seeing Korpiklaani at Pagan Fest in September and hopefully we might even catch Enserifum when they hit the Netherlands. Seems like Anti-Flag will be playing the Melkweg in November.
Oh yeah, the studies are done now and I should be receiving my BSc and MSc certificates on Friday (both in Computer Science, surprise). So I have been getting back into GTK+ in my spare time now wooooo. Should definitely be playing more guitar and bass guitar as well.
Apparently blogging about stuff helps, one day after blogging and complaining about my missing Internet connection my DSL modem was delivered. Rejoice.
Once all of GNOME has migrated to git this week, I should try to find time to check out the new repositories and rebuild everything. I hope I can finally get my branches in order and then slowly get back to hacking yaaaay.
Okay, I am actually getting hacking done (okay okay it is more like reviewing) and I just committed the fix for #316087 “Resizing columns is chaotic” to gtk+ trunk (finally!). Should be in the next 2.13 releases. This patch does modify the internals of tree view column size allocation, so if people could give the latest gtk+ from trunk a test drive that would be really appreciated :) By the way, you can find the slides from yesterday's GTK+ state of the Union here. The plans from the release team for GNOME3 sound cool, exciting times ahead :)
My talk “GTK+ State of the Union” at GUADEC has been moved from Friday morning to Thursday 14:30 (the cancelled keynote slot). This was noted in the schedule on the GUADEC website before, but unfortunately this schedule was reverted to the original version as also found on the badges this morning. But the move of the talk is still on :) Minutes from the GTK+ developer's meeting we had yesterday will follow soon, hopefully early next week. Ah yeah, and during GUADEC I am hacking on Bug 316087, or better known as “column resizing with expand=TRUE columns is entirely fucked up”. Seems we are very close to getting this fixed now. I will probably also hang out at the parties during the upcoming days, so see you all there ;)
I've been meaning to blog again for a long while, and I finally managed to sit down and do it. The last few months have been very, very busy. I got inspired in some way and started studying three times as hard, which is a good thing since I finally manage to get a lot of things done there. This week I finished two more master courses, for both of which we did some interesting stuff. For the first one I have been looking at very low-level cache optimizations (esp. strip lining/loop blocking) with somebody else; learnt a great deal of new stuff and gained experience. The other course was about grid computing; for the presentation and project part I have been focussing on data storage in grids. I've been looking at iRODS, which is an open source system for building data grids. It is a very interesting and promising project, but not yet ready for production deployments. I should probably put my report on this online at some point. Furthermore, my thesis is finally almost done. In the coming weeks I will be working on finishing another course which I had to leave behind for a while at the end of last year. At least the end is coming in sight, I hope to have my BSc and MSc degrees before mid next-year. Being very busy with studying is nice and all, but it means I had zero time left for spare time (GTK+) hacking. I hope this will change in the coming weeks and get my “getting things done” attitude from University work also applied to GTK+ hacking ;) I am going to look into:
- Getting the column resizing with > 1 expand=TRUE columns patch updated, fixed and committed in trunk. (finally)
- Design and implement a proper API for doing DnD (with multiple rows) in GtkTreeView. This should include making it possible to DnD between tree views and apps. (finally)
- Look into improving the rubber banding behavior as Christian Neumair talked about in his blog. As is stated in the related tree view bugzilla bug about this, probably need to move over the cell_process_action() refactorings from my experimental branch to trunk and then this might be much easier to fix. Moving that refactoring over means writing a good automated layouting test.
- Look into properly fixing the editing mess. We need a better means to distinguish between committed/cancelled editings.
- Actually write about the plans for a simple tree view wrapper that I've discussed with Johan and Emmanuele during the hack fest.
- Continue hacking on my experimental tree view branch. More on this later.
I thought I had more for this list, but this will keep me busy for a good while anyway ;)
In his last post, Murray writes that GtkTreeView calls gtk_tree_model_iter_next() for every row. This is indeed true, for the simple reason that the internal state keeping of GtkTreeView needs an exact internal representation of what is being displayed. This representation is in the form of an RB-Tree, wherein there is a node for each visible row. The definition of visible that we use here includes all nodes that are outside the current scroll area that is being shown. Visible distinguishes collapsed and expanded nodes from each other. Each node in this RB-Tree contains the properties of that row, such as its height, is it a parent or not, is it selected, etc, etc. In order to build this tree, we need to iterate over all nodes in the model, hence that iter_next() is being called for all these nodes. Even for a million rows this is not a problem, building the RB-Tree is quite a fast operation. This has all been discussed at length recently at gtk-devel-list: see here. The main performance problems have always been the measuring of all rows, which is something you can avoid by using fixed-height-mode. A lot of people have heard about me working on some experimental tree view improvements, this is also true. In my experimental branch fixed-height-mode has been removed, since the need for validating all rows has been removed. It can handle 4 million rows just fine. So, do we really have to put the entire model in the internal representation? This is actually an unanswered question. It of course greatly simplifies the implementation of GtkTreeView, but nobody says that it would not be possible to modify GtkTreeView in such a way that this is not required anymore. I haven't looked at this in depth myself yet, maybe at some point in the future when I have time and finished studies and and and … (I spent a lot of time on University stuff these days, it has been years since I have been so much motivated to work on finishing studies). While Philip and Jürg's ideas on iterator types and GtkTreeModel improvements are certainly interesting, it is not a (complete) solution for this particular problem. It will especially easify the implementation of data sources/tree models and their testability. The solution for large data sources is really in the view part and not (so much) the model part. Time for more Minix hacking now …
In some of the feedback we've received so far we feel that some of the points on the slides have been misunderstood. All people that haven't been in Berlin of course miss a part of the story, since the bullet points don't tell it in full. We've just done some more touches to our paper describing our vision on the GTK+ and you can read it here. As you can imagine, the paper is much more elaborate than the slides. If there are more questions/suggestions after reading the paper, be sure to let us know!
People here figured that today is GTK+'s 2.0.0 6th anniversary, woo! We go to celebrate this later tonight. Today most of the talks have been about introspection. I spent some time talking with ebassi and jdahlin where they showed me the “simple tree view wrappers” that exist for perl and python. Both seem to be similar and very nice. Hope to look into creating something like this in C soon (maybe this week still?) to make the simple uses for GtkTreeView much less time consuming to program. My hacking project seems to be progressing nicely. pixbuf-demo is running fine already with all graphics properly loaded via CoreGraphics. It loads photoshop files nicely as well. Next steps are getting it to do progressive loading and support animations and then a first version should be ready to hopefully commit in trunk. After that I will look into getting saving support done :)