Quoteth the blogger:
I wonder how much intersect with Nokia Maemo, but that would be their interest to team up to create a viable ecosystem of software. Maybe this time we could have AbiWord on PlamOS?
For my dayjob, I've been playing around with the software libraries referenced from the Jabber site, and have experienced nothing but frustration with them.
It seems that most of the libraries mentioned there suffer from one or more of the following defects:
So, if anyone has a favorite Jabber library that works ok with Google Talk and isn't written in say, Flash, I'd love to hear about it. I haven't tried all of the ones listed (I'm walking the list in my preferred language order), so maybe some client will work.
Update Thanks for everyone who gave me hints and suggestions. For those who care, I've settled on Smack. It's super-spiffy.
In a thoughtful email, I've been told that I didn't accurately address Davyd's concern in my last post, so let me excerpt the email and further clarify and qualify my statements.
In your reply to Davyd, you're basing your argument on a different use case than he. [snip] Its not about finding out the file-type. What Davyd talked about, and what I also regularly do, is the opposite: Finding files of a certain type. [snip] You are right in saying that simply putting the file-type as text into the icon might not be the optimal choice but so far, I at least am not aware of a better one.
So let's run with that.
Let's forget that you can probably do this based on the file's name easily enough. Let's put aside the fact that having this info embedded in a smallish image probably isn't ideal. Let's put aside the fact that representing text as an image is lousy for a variety of reasons and recommended against by the GNOME HIG (most likely for i18n purposes). Let's see what other tools Nautilus gives you to solve this problem.
If one wants to, one can organize the icons by their type. One can choose to display the file's type in its caption. One can also choose to use the list view, which includes the file's type in the view by default.
There are at least 3 other easy ways to view and use this information for that particular use-case. I contend that there are alternate (I'd contend, better) ways of viewing this information than having the information embedded inside the file's icon.
Christian has suggested that if you really want this behavior, it might be accomplishable via Nautilus emblems. Dave Camp's blog from yesteryear suggests that it might be possible.
As Christian mentions, breaking API/ABI isn't something to be done lightly, even if your module isn't constrained by GNOME's API/ABI policies. My argument doesn't concern itself with that, however, only with the apparent "loss of information and usability" that has been claimed.
Even if you think the puported usability arguments are thin, I think that I've shown that usability arguments for keeping them in are at least equally thin. In that case, please at least consider deferring to the HIG, which quite clearly says "no text in icons" and decide on a better way of achieving the semantics you're after.
I'm going to have to go ahead and disagree with Davyd here. Maybe you just picked bad examples that don't really illustrate your point. In both cases, you can easily find out what type of file or share they are via the Nautilus contextual menu. Heck, you even have extensions showing, so saying that you don't know if "FOO.JPG" is a JPEG image because "JPEG" is not in the file's icon is complete rubbish.
My mother doesn't care whether the share is a SSH one, but if you do, right click->properties. The contextual information should be accessible via the "context" menu. If it's not, I'd argue that the bug lies there. The information in the icon is ugly, gets in the way, and is probably redundant. These are exactly the kinds of thing you want a drill-down interface for, not bubble-up (IMHO, of course).
Sometimes I wonder whether people are percieving real problems, or if they are just acting out their past frustrations with Dobey...
I'm going to have to disagree with some of Raph's points about the auto* toolchain. While I can't say that I'm pleased with many of auto*'s decisions, I've yet to see a build system that attempted to fill auto*'s niche and fill it as well as auto* currently does.
Is auto* a perfect toolchain? No. Like you, I wish that we had a better alternative and feel that one is long past due. But in an imperfect world of having to support legacy linkers, compilers, and ancient platforms, auto* still fills a useful niche. Things are not as bad as you make them seem. You're just lamenting that the tools attempt to address a niche that you'd rather ignore entirely. That's fine for you. But writing off the tool entirely for those reasons is just sour grapes...
What follows aren't particularly well-formed thoughts, just ideas floating around that I need to jot down so that I don't forget them. These are original (in the sense that I'm not copying these from anywhere that I'm aware of), but I'm not sure if they're unique or even valid ideas. I'd like to investigate them more in the near future. I'm admittedly lacking in both IP and Constitutional law education and experience, so there are probably glaring holes and errors in my argument. Take what you read here with a grain of salt.
In case any of them are reading this syndicated somewhere, I'd just like to offer them a small piece of the solution and some advice, which they're free to do with as they will. Librsvg has implemented the drawing-side code for filters. No doubt, it could use some cleaning up and restructuring (and we'd love contributions back), but the code is there, is freely available, and just works. You'll still need to write all of the code for creating and manipulating the filters, but at least the rendering part is already done.
From what I understand from their emails, they're blocking filters on Cairo/Xara integration, which I don't quite understand. The filters all operate on pixel data, not SVG maths. As such, they're independant of Cairo, Libart, or whatever one wants to draw with. The small-but-important exception is that one needs to be able to turn a specified region of the source graphic into a pixel buffer in order to use it with these filter functions (which Inkscape probably almost already has, since it uses libart to draw), and the ability to blit pixel data back onto the source graphic (which Inkscape necessarily has, since it supports the <image> tag). In librsvg, this has always been a pretty small shim, regardless of whether we were using Cairo or libart.
Also, they claim that Cairo is "slow". From librsvg's experience, it's anything but, at least compared to what we were using. Link Inkscape, we once used libart_lgpl. Cairo's image surface has been between 1.5x and 10x faster than using libart. My best guesses as to why are because it uses ARGB rather than RGBA pixel ordering and that libpixman's gradient-generating code is pretty good. Sure, it might not be able to (currently) draw 10 gazillion polygons per second like Xara claims to do, but does Inkscape really need that level of performance? I'd also like to see the code/tests Xara used in their performance comparison.
Anyway, we abstracted out our rendering into a 6-method interface that's implementable via Cairo or libart in ~1100 lines of C code. It's proven indispensable. Once you've chosen a good enough rendering abstraction, swapping in Cairo, Xara, or $flavour-of-the-week under the hood shouldn't be a problem down the road.
If SVG filters are your most requested feature, and it really is more than "just a one person job", please consider stealing liberally from us. GNOME needs more pretty icons and widget themes.
So, Ruth and I were driving from her grandparents' place in upstate Pennsylvania to Boston tonight. It's a long drive (7 hours in ideal conditions), and it was rainy/foggy most of the way. After about 5 hours, Ruth gets tired and I took over driving. All's well for about 1.5 hours until I get ticketed: I was going 63mph in a 40mph zone. This 40mph zone was near an otherwise *vacant* toll booth area where the speed limit drops from 65mph to 50mph to 40mph and then to 30mph in a matter of 300 meters. I pulled my foot off the gas pedal and applied the brake, but apparently not fast enough for the state trooper's liking. Utter B.S...
Then we get home and open a week's worth of mail that's been waiting for us. The choice piece of mail is a letter from the I.R.S. where they tell Ruth that she owes about $3000 in back "self employment" taxes. Ruth is a graduate student who makes about $18k per year in taxable income (which she pays quarterly, like she's supposed to) from an extremely modest stipend. She is in no way "self employed", nor should the government feel that they're entitled to another 1/6th of her measly income ON TOP of the other taxes she'd already paid. What The FSCK...
Today's lesson learned: Government- can't live with 'em, can't run or hide from 'em either.
Why is ODF a leapfrog? While it doesn't appear to be so, it offers something MS Office is never going to be able to offer, full portability of documents regardless of program. I call that a killer feature.
I think that you're forgetting other "open" specs like RTF, which offer full portability of documents regardless of the program used to edit or render them. And you also forget that the other MS Office formats are pretty well-understood these days by a *lot* of other programs. To say that you don't have something close to full portability of your documents today is to live in igorance. To say that we don't have "simply documents" these days is to abound in ignorance.
ODT does have a few things that the MSFT formats don't have:
From a technical perspective, ODT, DOC/XLS, etc. are on fairly equal playing ground and enjoy broad application support. Why I have to claim otherwise in order to "be there socially", as you claim, I have no idea. Your excluding/ignoring/rejecting other people's well-founded technical opinions because they aren't they aren't your type of zealotry is an inexcusable offense.
I'm not claiming that ODT isn't technically good or morally good. It is both. I'd rather support it than MSFT's formats any day. But you're arguing all the wrong things for all the right reasons.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!