Posts
| « | November 2024 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| « | November 2024 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
As I talked about earlier, I have a patch for showing inplace tooltips on a gtk+ treeview. Furthermore as it's nearing time to update it, I wanted to record the steps necessary to do so and to apply it.
Most of what I know about quilt I learned from this quilt howto hosted on alioth. So I'm by no means an expert; rather I know just enough to be dangerous. So here are the steps a Debian user can use to update and refresh my inplace tooltips patch.
First: set up quilt. Here's my modified /etc/quilt/quiltrc but feel free to put the equivalent in your own ~/.quiltrc instead. The first line is critical; the others just simplify the patches.
QUILT_PATCHES=debian/patches QUILT_DIFF_ARGS="--no-timestamps --no-index" QUILT_REFRESH_ARGS="--no-timestamps --no-index"
Second: get the build dependencies and source.
% sudo apt-get build-dep libgtk2.0-0 Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. % apt-get source libgtk2.0-0 Reading package lists... Done Building dependency tree Reading state information... Done Need to get 23.6MB of source archives. Get:1 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (dsc) [1565B] Get:2 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (tar) [23.5MB] Get:3 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (diff) [89.4kB] Fetched 23.6MB in 54s (430kB/s) dpkg-source: extracting gtk+2.0 in gtk+2.0-2.12.7 dpkg-source: unpacking gtk+2.0_2.12.7.orig.tar.gz dpkg-source: applying ./gtk+2.0_2.12.7-1.diff.gz
Third: apply the patch.
% cd gtk+2.0-2.12.7 % quilt import ../gtk+2.0-2.12.5/debian/patches/mu-inplace-tips.patch Importing patch ../gtk+2.0-2.12.5/debian/patches/mu-inplace-tips.patch (stored as mu-inplace-tips.patch)
Fourth: update debian/changelog. You'll want to fix the conflict, revert the changes, or update the number.
% quilt push mu-inplace-tips.patch % quilt edit debian/changelog [...] % quilt refresh Refreshed patch mu-inplace-tips.patch
Fifth: build the packages. This takes a while.
% dpkg-buildpackage -us -uc [...]
If anything breaks you'll probably have to run quilt pop mu-inplace-tips.patch, edit the patch to resolve the build failure, run quilt refresh, and try the build again.
Sixth: install the package, and optionally put it on hold. Note that you need only the libgtk2.0-0 package if you haven't bumped up the version in the changelog; you don't really need the others if you have, but they have tightly coupled version dependencies that complain if you don't use them.
% cd .. % sudo dpkg -i libgtk2.0-0_2.12.7-1+0mu_i386.deb libgtk2.0-dev_2.12.7-1+0mu_i386.deb gtk2-engines-pixbuf_2.12.7-1+0mu_i386.deb [...] % echo libgtk2.0-0_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections % echo libgtk2.0-dev_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections % echo gtk2-engines-pixbuf_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections
Finally restart any gtk+ programs you want to use your freshly updated gtk+ library.
) (0 Trackbacks)
debian
freesoftware
gtk+
quilt
A long time ago I started work to port my rudimentary treeview hack from its TreeViewHints python implementation in Quod Libet to a much more solid inplace-tooltips implementation in gtk+ itself. Inplace-tooltips are the little tips that appear as you move your cursor over items that aren't fully visible, and often appear immediately instead of after a hover delay.
For whatever reasons the patch has neither been nurtured and accepted nor denied, and has languished for most of the 19 months since I first filed the feature request. I personally suspect things varying from confusion over the term tooltips
being in the name to malevolent negligence, but claiming either of those doesn't help the situation anyway.
Eight months ago I found a much better approach to it, which wrangled out some superficial bugs for free, and updated the patch. Finally over the past two weeks, I found that Debian's gtk+ package had changed its build procedure, and this time was able to figure out how to integrate my patch. Wow, what a difference it makes to use it full time. In under two weeks I'd found and filled some important gaps in my initial implementations, including fixing the tip's position when a tree is scrolled horizontally.
But building my own Debian packages comes at a price. Not only does it take significant time to build the packages, there are three options each with disadvantages.
By applying just the code patch I get all the behavior changes I want...so long as I don't run a package update. If I run a package update, the original libgtk2.0-0 package takes precedence over my package, and offers to reinstall.
When Ubuntu makes packages, they apply a suffix to ensure that Debian's packages of the same version do not override theirs, but a newer Debian package can (so long as all dependencies are satisfied). This prevents the official package from overwriting my patched packages. However doing this causes the policy of my package to move past the testing archive and into the limbo which pulls in packages from unstable. It also requires I install some auxiliary packages due to tight version dependencies in the core gtk+ related packages.
An epoch is a special version indication that would let me continue to call my package by the same version the rest of gtk+ does, but tell the package management system it's newer than the official package. Assuming Debian never needs to bump their epoch, this would insulate me from the testing–>unstable bump, as my packages would always be even newer than the ones in unstable. However because of that it would be much harder to track when it was time to upgrade my own packages.
Currently I gave up on the first, and am still trying the second. I've run into one major hitch: aptitude doesn't work how I want it to. In particular I'm running with my suffixed package version 2.12.5-2+0mu, and unstable now has 2.12.7-1:
% apt-cache policy libgtk2.0-0
libgtk2.0-0:
Installed: 2.12.5-2+0mu
Candidate: 2.12.7-1
Version table:
2.12.7-1 0
601 http://http.us.debian.org unstable/main Packages
*** 2.12.5-2+0mu 0
100 /var/lib/dpkg/status
2.12.5-2 0
900 http://http.us.debian.org testing/main PackagesBecause I'm beyond testing (which I have as my default), apt and aptitude want to attempt to keep me at unstable (my fallback) because it appears that's where I was before the update. I'm not ready to make this leap; I want to make it when 2.12.7 reaches testing. So I employ the next trick in the book: hold.
Hold is supposed to tell aptitude to ignore this package during normal upgrades until I explicitly tell it to install a newer version. But it just doesn't work. If you visit aptitude's bug page and search for hold
it becomes obvious that there have been lots of problems with hold, and most of them are still unresolved. Most of them have to do with synchronizing aptitude's list of holds with dselect (and apt's) list. But if that were all, I could work around it. Instead aptitude doesn't even follow its own holds:
% dpkg --get-selections | egrep 'gtk2-engines-pixbuf|libgtk2.0-0|libgtk2.0-dev' gtk2-engines-pixbuf hold libgtk2.0-0 hold libgtk2.0-dev hold % sudo aptitude unhold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev [...] % sudo aptitude hold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev [...] % sudo aptitude safe-upgrade [...] The following packages will be upgraded: gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev 3 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded. Need to get 6061kB of archives. After unpacking 12.3kB will be used. Do you want to continue? [Y/n/?] n Abort.
Now that I've seen this sloppy behavior among others, and seen just how many long standing bugs there are against aptitude, I think it's time to go back to dselect, apt-get, and deborphan. Too bad; aptitude seemed like a good idea at the time.
So many things I forego writing about to fill up your feed, but here's one that I just have to. A while ago I worked on a program I was calling tansei. The eventual goal was to be a personal planet-style feed aggregator in an application instead of a browser window. But I got tired of it after some of the simplest bits of it fought me for too long. And as usual when I write software, I distracted myself with less important parts of it first - in this case trying to render all sorts of crappy html the way I wanted it.
So finally a few months ago Joe tells me liferea has a compact view which does exactly what I want...at least when it manages to pull the entries separately. And that means I no longer have to write the rest of the program, so I'm happy. Mostly. I don't actually like liferea all that much. The interface is somehow clunky in ways I can't put my finger on. The one I can is where it fails to act like another application which doing something weird - if, like pan's error window, liferea would put a close window button next to the mark-items-read button, I'd stop accidentally refreshing everything.
Then yesterday I hear that Google (they don't need the miniscule PageRank boost I can offer on a link) has released an upgrade to their feed reader service. The interface is pretty slick. It lets me delete the 2000 odd feeds I had accidentally imported into the old interface in under 10 tries (the previous interface would have required me to delete each one; the new one just kept failing in the middle of each delete all). It's about as nice as the way I read my mail. And then I find the important part: if I put subscriptions in folders, then I can select to read an entire folder. It then interleaves the posts by date. Yay! Planet behavior! This is on top of all the other odd benefits, such as practically infinite history for as long as anyone has subscribed to the same feed.
Today I try to load it. I can't seem to get past the loading animation. Since it's just an animated GIF I have no way to tell if it's making progress. I'm sad. I try another browser. No go. I'm sure they'll fix it later. Mmm, proprietary serviceware indeed.
Continuing along the theme of trivial problems that go unfixed for a long time, with an occasional personal favorite, here's some problems with PyGTK.
Where I treated Mozilla Firefox as a user application, I treat PyGTK mostly as the development library/toolkit that it is. For quite a while GTK+ and GNOME were the poster children of the Free Software Movement. They handle some things really well, but there are still a lot of gaps. Here's some of the gaps I particularly want to see filled.
Real tooltips can only be single paragraphs of text. No images, no formatting, no nothing. At two and a half, and five years respectively, these strike me as a perfect example of the if we put this off until we do such-and-such (a hard thing), then this will be really easy degenerate case
mentality. Since GTK+ is much more concerned about backwards compatibility than Mozilla Firefox seems to be, I can give them some kudos for avoiding ill-considered changes. However the status quo is not good enough, and any tooltip reimplementations to acquire the different capabilities ruin the point of having a widget in the first place.
There is no builtin way to set tooltips on a per-column, per-row, or per-cell basis (three and a half years old). This ties into the above five-year-old bug, potentially as another easy degenerate case. Well, I'm still waiting.
Dragging is hard enough, but dragging multiple items is really hard. By default you need to start a drag on the same button-press that selects or unselects a row. I can't find a bugzilla bug on this one, but Quod Libet uses class MultiDragTreeView which implements this in a saner fashion.
There is no builtin way to show the contents of an ellipsized or otherwise truncated text cell. I also can't find a bugzilla bug on this one, but Quod Libet uses class TreeViewHints which does most of what I need. The idea is when you're hovering over an ellipsized cell in a TreeView, a tooltip-like window will show up exactly in place to show you the parts you can't see. Windows MFC has this built in, and that one even works if the contents are hidden due to scroll. TreeViewHints only handles a small subset of ellipsized cases, so I'd rather see something real implemented in C.
There's no right way to set a right-click menu on a column header. Apparently there are some hacks in C, but they are not available from PyGTK. This makes it practically impossible for us to do the user-friendly configuration of Quod Libet's column headers that we've wanted to for over a year.
Free software has a major weakness. It's not one that other people can worsen or exploit, other than by working harder themselves. So this weakness doesn't spell the end of Free software. But it consistently acts as a limiting factor in the greatness of Free software. To be fair plenty of commercial software suffers from the same problem, if for different reasons, so it's not even a weakness specific to Free software. But it's a weakness I want to see addressed and mitigated.
The weakness I refer to is in small but important features: they constantly slip through the cracks. What makes it infuriating is the number of wonderful, obviously-difficult, and often polished features that are written in the same timespan. Sure it's not a straight tradeoff, so lamenting if we had time for this, certainly we had time for that
doesn't help—different contributors are interested in writing different things. Official maintainers are interested in accepting different things. But the result is the same: something simple remains hard or impossible for years, and things you could do in the previous version cannot always be done in the next version.
It's not hard to find examples. I don't pick any given example to make fun of the project which lacks the feature; I do it to highlight a change which I would love to see make my life that much better. That said the more I use something, the more gaps I'm likely to notice—in that sense perhaps it's a compliment if I list a lot of gaps! Regardless it's probably best to treat this as my personal rant list. More examples coming later.
What makes the first two Mozilla gaps so annoying is that they've both been present in previous versions of the product. Now that's progress!
Back in the bowels of time the first well-known web browser could view just about anything as if it were served with content-type text/plain. This was a great thing, although its importance didn't crop up until much much later. Recently web servers have started sending source code under other content types like text/x-csrc or text/x-py. Since it became reborn as Mozilla, rather than always supporting an in-browser fallback, unknown content types are only supported by external applications. This means when I go to view plain ascii text files on certain web servers I have to load up a text editor. Insanity!
And I'm far from the only one to think so. This was reported on bugzilla five years ago.
Firefox before version 1.5 offered a "Manage folder" option in the right click menu of each bookmark toolbar folder. In 1.5 they removed this, apparently because some people thought others might find the expand option confusing, and because some functionality didn't work right in the subfolder-only view. The result? I and others can no longer easily access and edit bookmarks in a single folder. I have way too many bookmarks to view the whole set; managing a single folder was very important to me.
When a site offers an RSS feed, you get a nice icon letting you know this. Click on the icon to subscribe (create a live bookmark). However neither in this dialog nor on a right click can you find out what the URL is for that live feed. The only way to do that is to view the original source, or to create the bookmark and view its properties. This makes it much harder to verify that you're setting up your RSS rel links correctly on a page, or to directly visit the feed in your browser. I couldn't find a bug in buzilla about this limitation.