Daniel Naber wrote in some time
ago to
inform us of a new XML plugin forKate. "The plugin gives hints about what's allowed at a certain position in
an XML file, according to the file's DTD. It will list possible
elements, attributes, attribute values or entities, depending on the
cursor position. You can also close an open element with a keyboard
shortcut. DocBook is also supported, so hopefully people will use Kate +
XML plugin to write KDE documentation." This should be useful to the
tons of us working withstructured data in XML. I gave KXMLEditor a whirl the other day but although it looks nice, it basically ignored my DTD. I hear Richard Moore also has XMElegance in the making. Yup.

In other unreleased software news, Mosfet wrote
in to point us to his PixiePlusscreenshot previews.
It's slated to have tons of new stuff and candy.

Type in the path for the packages e.g the supplementary directory on the ftp where the KDE2.2.2 packages is. And then you just need to choose the ones you want installed. You should upgrade all of the packages!

well, as he is writing KDE software he is a part of the KDE "team". he just isn't storing his work in KDE's central CVS server or coding in direct coordination with the core developers. and that's fine, as it works much better for everyone involved that way.

there is nothing to prevent you from downloading his apps and using them, or your distribution from including them with their binary packages. if they are popular enough (which they seem to be) and there aren't any legal issues surrounding them (which there doesn't seem to be), i would be quite surprised if at least some distributions didn't create and ship binaries for Mosfet's works.

The blonde girl, Gwen, is my ex-fiance. She lives on a farm outside St. Louis with lots of animals including a Donkey she took in because it was going to be put to sleep. Your the sicko for making a weird connotation about that...

My standard goth apparel. Your lucky I didn't use the pics I have of me running around the goth clubs in a vynil and metal studded G string... ;-) Plus, it's fun having the people on slashdot try to guess my gender >:)

Now, if we can get back to the *software*... I'm pretty excited about the new Pixie. If you liked the old one this new one is much more usable (the thumbnail browser really rocks), and has a lot of new neat stuff.

Thanks for all your work. My question is:
what is there about Pixie that is more
than that found in other KDE image-managers
like gwenview or showimg? I have not used
the latest Pixie (since it is not released
yet!) but judging from your
descriptions and screenshots, all the
stuff seems "standard" for an image-viewer
these days. To use a non-KDE application
as an example, the wonderful gqview
(http://gqview.sourceforge.net ) has had
all the features that you list for pixie
for the better part of a year, including the
heads-up when we try to overwrite an already
existing image.

In summary, what features have you planned
for pixie that will make it a better
image viewer than showimg, gwenview or
gqview?

There's a ton of stuff. Read the Pixie main page, but it has an extremely fast demand-loaded thumbnail manager (the fastest that I could find), tons of effects, batch editing, and lots of image management features. Heck, the old version had a pretty impressive feature list compared to things like ShowImg...

Hmm, I should mention this isn't a slight to ShowImg or any of the other applications... it has some interesting features and competition is always good :) For example, while I always thought Pixie was powerful and had lots of good stuff, many people hated it's interface and prefer things like in ShowImg and GwenView. This caused me to totally rewrite the GUI. So, while I think Pixie is nice and has lots of things users will like, the same could be said about the other people's application's, too... Users will just have to try them out and see what they like, which is a pretty good deal for the users, anyways >:)

How does the new Pixie compare to gqview? I found gqview to be amazingly fast with generating and displaying thumbnails, as well as maintaining usability while it's generating thumbnails (which I find handy).

Very good! For reasonable directory sizes (a couple hundred images) it's 1 second or less. It takes 4 1/2 seconds, (4,582ms to be exact), to complete loading a directory of 5,000 image thumbnails. If you got more than that you need to start downloading less Pam Anderson pictures ;-) Most of that time is spent getting and sorting directory information, not loading thumbnails itself.

My system is an AMD450/128M RAM, and the images are on an IDE ReiserFS drive. I'm very happy with it's performance :)

Generating thumbnails is still expensive, but I've improved the smoothscaling operation (it no longer uses Qt's QImage::smoothScale method in some cases). I've looked at this at the majority of time (around 2/3rds) is spent in the file I/O procedures for the various image formats, not in the application's code itself. This applies to libjpeg, libgif, and libpng. Since virtually all applications use these libraries (both GTK and Qt), thumbnail generation will probably end up around the same speed for most image viewers. Konq is an exception because it uses IOSlaves, but even that is pretty intelligent about sharing the image data between the slave and the browser in order to be quick. Konq's main problem is the way it manages updating it's iconview.

Hehe, I just noticed that's something that ShowImg can do that Pixie can't. Pixie always had a sorting option, "Ascending by size/Same sizes first", that I used to find duplicates - but it didn't actually compare images. It just stuck all the images that were the same size on top. This is a useful feature tho, so I'll add it now. It can be done rather efficently since you don't have to compare every image to every other image. You just have to compare images that are the same size. This is what I'm adding now.

The only problem with this is it will only give you exact matches. But this would mostly be used to compare images downloaded from various websites, which may have scaled the image size differently, placed different web site logos on the image, used different optimization or file format, etc... So you may have the same photo, but it is actually a different size and has different image data. In order to compensate for this you'd have to compare the percentage of red, green, or blue in each image, (or HSV - it really doesn't matter), and have an allowable range of difference for it to match. This is why I never implemented exact duplicate finding before: it's not that useful for me.

This sounds like you'd be stuck comparing each image to every other image again, since you couldn't just compare ones with the same filesize, but that's not true. I occured to me awhile ago that thumbnails are PNG files, and I can encode additional data in the PNG comment field for the thumbnail, (without changing the original comment of course!). So you can encode CRC values for each color channel when generating the thumbnails and then just compare that - not the entire image! This would allow for the "fuzziness" I mentioned above while still relatively fast. Comparing every image to every other one is not acceptable, of course.

Cool... I'm not exactly sure how gqview does comparison, but I believe it's the same as what findimagedupes does. I believe it first generates CRCs or hashes or something (I don't really know anything about that kind of stuff, just buzzwords ;) ), stores them in a database, and then compares the different CRCs to each other, instead of comparing the files themselves. It works pretty well, and can find similar-but-not-exact matches.

If it allows for fuzziness then it's storing CRC values or something similiar somewhere. I really like the idea of sticking it in the thumbnail, tho. It's less efficent than keeping the data in a flatfile, (you have to open each one to load it's comment field), but then you don't have the additional overhead of maintaining a seperate index of items. Since this isn't an operation your likely to do often, I like that approach better, but I may change my mind. I'll take a look and see what it does.

Hi Mosfet! I love your software, but I hang around at goth- and fetish-clubs every weekend and I don't think your look is very gothic.. It's more what we call the "chock-rock" or "freak" look. At least on that only picture I've seen of you... :)
BTW, I'd love to see those vinyl G-string pictures! :D
(and no, I'm not gay)

I think so to, but it's a bug in PHP-Nuke (has been for a long time). And it's easy to fix. I did so when I played around with PHP-Nuke localy.

Somewhere there is a counter that counts hits, it test if the browser is a Netscape (or Mozilla) browser before it checks if it's a Konqueror. The Konqueror agentstring contians the words "Mozilla/5.0 (compatible; ...)" so PHP-Nuke thinks it's a Mozilla browser, instead they should move the test if it's Konqueror to before the tist if it's Mozilla... That anoying bug has been there for a long time. In KDE 2.1 you could manualy change the useragent string to whatever you'd like. I changed it to Konqueror/2.1, and it worked wonderful, but that's not possible anymore...

It is bad for PHP Nuke and many other stats pages.
It would be better that "Mozilla" would not be wrote in the default Konqueror Agentstring. If there is a bug, it is not in PHP-Nuke and others programs, it is in Konqueror. And it is a very bad thing because Konqueror looks like a very few used browser :-(

That's not entirely accurate. Konqueror is listed as Mozilla Compatible because otherwise a good number of sites would choke on it. I've seen many a badly designed site that assumed that if you're not using IE or Netscape, then you must be uncapable of using Flash, Javascript, or sometimes even frames!

The bug is in PHP-Nuke's agent string parsing because Konqi lists itself as being Mozilla _compatible_, which is not the same thing as being Mozilla.

It's true, this bug isn't Konqueror's fault, because even Internet Explorer for Windows identifies itself as Mozilla. 'Mozilla' appears always as the first word in the UA string (even in the latest IE version), because in the old days when the only JavaScript-compatible browser and market leader was Netscape, webmasters did a check on the browser UA to allow only Netscape users, so IE began identifying itself as Mozilla, which was originally Netscape UA string (Mozilla was the browser code upon which Netscape was built, even nowadays). So browser sniffing isn't good coding practice, never was; but now, when we got standards, browser check isn't necessary anymore; in javascript we should use object detection instead and in server side detection, only UA storage for use in stats. I do only browser checking for a personal site but I don't deny contents. Just change the site interface where the browser does support advanced features.

I found this scp/ssh kio slave very usefull and stable. It doesn't use sftp, but uses a combination of ssh and scp. Fun thing is that it also uses the keys you have loaded in ssh-agent AND it uses your ~/.ssh/config. So browsing your home directory from work at home is as simple as fish://yourbox/ (no password if you have keys and config set up right.