I’m Not Dead Yet; Also, Ideas Wanted
I missed my Photo Friday post last week. The week before was a rushed job, and, honestly, wasn’t up to my standard of This is Pretty Interesting. I assure you, I had good reasons for sucking.
Now, I usually avoid meta posts about this blog, but I’ve been attempting at establishing more online presence, and missing a single post, even if just a photo, was too much of a personal let down to simply brush away. Let me assure you that Photo Fridays will continue to be a regular feature, and I’ll try my best to stop being lame.
That said, the primary purpose of this post is not to make excuses, but to solicit some ideas.
One thing I would like to do regularly here is to write technical articles on topics within the GNU/Linux and open source software domain. Having been involved in X.org at a capacity beyond being an average user for some time, the amount of misconceptions and misunderstandings surrounding some of the open source platforms have been both surprising and frustrating. As much as I have tried and mostly succeeded in remedying individual cases, there’s definitely more that can be done in terms user education.
Item number one on the list of article ideas is a three-part series on video playback, specifically rendering. Item number two may be an (simple) exposition of the state of graphics in Linux: where things have been, where things are going, and why certain things are so difficult. Three and beyond: I haven’t a clue.
This is where you come in—what would you like to know better?
Post a comment, dent me, tweet me, or even suggest ideas in meat space. I can’t and won’t guarantee that I will be sufficiently knowledgeable in most topics suggested or care enough to find out more about them, but I believe most of you are aware of my ability to ramble on about obscure technical trivia, and how much I seem to enjoy it.
It’s win-win, really. You have a chance to learn about something without first having to do all the legwork (assuming you trust my competencies) and I get to explore more interesting things.
Give me your best shot.
Tags: meta
August 4th, 2009 at 17:11
This isn’t really on the video/hardware side, but anyway. Two related X issues.
1. Internationalization. I haven’t found an input layer that continues to work for more than a couple months before something breaks. Whenever the system stops behaving, it usually means a lot of work fixing things, most often involving a new input layer system or a new backend dictionary system or both, figuring out how to configure the new chain of daemons, testing it with multiple apps… and each round of this testing tends to involve crashing apps and/or resetting X. I’ve read/heard a lot of “just install $this and it all works automatically!”, but for me it never has.
Even when it does work, it doesn’t work with every app — the app has to support the input layer in some way. Windows has some emulation option (IIRC) which gets around this issue. Most (X) apps that don’t work with the input layer will accept pasted-in international characters, which seems to imply X could do some sort of emulation as well… but AFAICT, never does. (Instead I get to do “manual emulation” — go to some app that’s working, type stuff up, cut it, paste it into the app which isn’t working.)
There are some more severe support issues here and there as well. I’ve seen tcsh both crash when tab completing a filename, or fail to match all files when given a wildcard (*). This may be connected to the larger issue of failing to handle unexpected characters for the given character set… or just poor support for non-ascii characters. Another common problem is that apps can’t survive a restart of the input daemon. The most common response is to crash (next time you type something or when it gets focus).
I’m sure the last two issues are related — input support has to be built into the app, and it’s at some deep enough level to crash it. Presumably the paste mechanism is more robust, and definitely higher level — you’re not dealing with keystrokes, you’re dealing with the final text. Perhaps input layers should work more like that.
2. Fonts. Why is font management so horrible? It seems to be at least a two part problem, and sometimes more. There’s the backend system, these days often fontconfig. There’s the application, which often has it’s own font configuration issues. And sometimes there’s a desktop (KDE/Gnome) specific layer, and/or a toolkit (e.g. GTK) layer. If you’re having a font display issue, tracking down the problem can be a big time sink.
Some problems I’ve had include unwanted antialiasing (often due to some system wide setting), refusal to use the font I specify (even though it exists), trouble figuring out how to even specify a particular font (maybe I know the XLFD or path, but not whatever homebrew qualification system $app is using), and horrible font substitution issues (e.g. one font for kana and another one or two for Kanji, with different size or style glyphs — again when a single font is available).
To reiterate, this is (at least) a two part problem — sometimes it’s the backend system, but more often it’s the front end app that’s at fault. But the fact that so many apps roll their own font selection/configuration systems seems to indicate a deeper problem — no unified high-level font system.