I'm using this now, but I'd like it better if it had these features:

• some way to open a folder from the command line ("open -a Xee ." doesn't work).
• some way to advance to the next image one-handed on a laptop keyboard, possibly with , and . (obvious joke goes here).

what

Xee? What's Xee?

secret project lolz

http://4-ch.net/tech/kareha.pl/1117579382/33 <-- This secret project, in fact.

> some way to open a folder from the command line ("open -a Xee ." doesn't work).

I am enough of a Mac newbie to not know how to make that work. Tell me, and I'll fix it.

> some way to advance to the next image one-handed on a laptop keyboard, possibly with , and . (obvious joke goes here).

Ah, noted.

Oh well, since MrVacBob spilled the beans anyway, and since I do need some testing, I'll upload an alpha version, if anybody wants to check it out.

http://wakaba.c3.cx/releases/mac/Xee_alpha_1.zip

Lots of functionality missing (you'll see placeholders in the menus and stuff), and the status bar is a mess, but it image viewing and browsing should work. Report bugs and such.

Interesting. I like the speed!

Some of them you're probably aware of, but here goes:

• The program tries to open PDFs and BMP images, but displays just a blank black box for both.
• When opening an image too big for my screen, and I'm not telling it to shrink images to fit, it opens it up in full size, but there are no scroll bars. Is this intentional?
• I just happened to have a Wakaba vericode image on my desktop, and when Xee opens it, the transparent background is noisy. Other transparent GIFs seem to be okay. Haven't tried an animated GIF yet...
• When more images are added to the folder Xee is currently browsing, Xee doesn't seem to become aware of them. Maybe the program could do a re-scan of the folder whenever it is brought to the background from the foreground?
• Trying to open another viewer while one viewer is open = hang. But I tried it a couple of other times and couldn't reproduce it...
• "Error loading image" on the attached image.
• The "fit to screen" isn't as pretty as Apple's. Also, will you be making a "full screen" mode that does away with the menu bar and status bar?

Not a bad little hack for a Mac n00b. Good work. :) Any significance to the name "Xee?"

> re-scan of the folder

Rescanning is a baaaaad idea.

OSX has dnotify-like functionality. I think it's called kqueue.

> I am enough of a Mac newbie to not know how to make that work. Tell me, and I'll fix it.

I checked, and 'open -a Xee <an image>' works properly, so I assume it would be a matter of noticing that the thing you've been given is a directory. I don't know the specific file API you're using, since there's at least three, so I couldn't answer that question specifically.

> When opening an image too big for my screen, and I'm not telling it to shrink images to fit, it opens it up in full size, but there are no scroll bars. Is this intentional?

This confused me the first time I got to a manga page that was entirely white at the top, but I don't want a scroll bar wasting space in the window. Perhaps a "current height/total height" percentage at the bottom?

> The "fit to screen" isn't as pretty as Apple's.

It uses OpenGL (presumably bilinear) scaling, and Preview first displays a scale with no interpolation and then goes back with Lanczos or something. It would be hard to duplicate this without using software scaling.

> The program tries to open PDFs and BMP images, but displays just a blank black box for both.

Known bug - I just ripped off the file types from Preview and what NSImage says it can handle, but I no longer use NSImage for loading so it's outdated. Will be fixed later.

> When opening an image too big for my screen, and I'm not telling it to shrink images to fit, it opens it up in full size, but there are no scroll bars. Is this intentional?

This matches the behaviour of ACDSee. It's admittedly confusing to people not used to ACDSee, but for me it's natural, and I've been pretty much designing for myself with this one. It also reduces the clutter around the image.

> I just happened to have a Wakaba vericode image on my desktop, and when Xee opens it, the transparent background is noisy. Other transparent GIFs seem to be okay. Haven't tried an animated GIF yet...

I should probably be clearing the buffer before drawing the Quicktime-loaded image into it, or something. Will look into it.

> When more images are added to the folder Xee is currently browsing, Xee doesn't seem to become aware of them. Maybe the program could do a re-scan of the folder whenever it is brought to the background from the foreground?

This also matches the behaviour of ACDSee, but in this case it may not be a good idea. I'll probably look into ways of fixing that later.

> Trying to open another viewer while one viewer is open = hang. But I tried it a couple of other times and couldn't reproduce it...

There might be some issues with multiple windows open... I haven't been able to track it down, and it seems fairly random. If you could reproduce it, I'd be happy.

> "Error loading image" on the attached image.

Will look into it.

> The "fit to screen" isn't as pretty as Apple's. Also, will you be making a "full screen" mode that does away with the menu bar and status bar?

As MrVacBob says, it's OpenGL doing the resampling. It might look prettier if I enabled mip-mapping, but it would also use a bit more graphics memory. I'll probably add an option for this whenever I get around to making a preference GUI. Full screen mode is something I'll probably do sooner or later.

> Any significance to the name "Xee?"

"ACDSee for OS X", probably. Also, it's cute.

> I checked, and 'open -a Xee <an image>' works properly, so I assume it would be a matter of noticing that the thing you've been given is a directory. I don't know the specific file API you're using, since there's at least three, so I couldn't answer that question specifically.

I am just specifying which file types I support in the plist, and then getting events to the NSApplication. I guess that if I can tell the OS I can open directories, and added some code to properly do that, it'd work?

> This confused me the first time I got to a manga page that was entirely white at the top, but I don't want a scroll bar wasting space in the window. Perhaps a "current height/total height" percentage at the bottom?

I need to design some sort of prettier status bar. Maybe there is some sort of iconic representation for this I could think up...

The image in >>7 loads fine for me, it seems. Maybe your Quicktime installation is wonky or something? Can you load it in Quicktime itself? Can you load it if you copy it somewhere else?

>>12: Weird. I made a copy of the image to my desktop, and was able to open the copy. So I moved the original to my desktop, and was able to open the original. So then I moved the original back to /Users/Albright/Sites/oaf/_el/css/img/logo.gif, and "error loading image" again. I don't think the pathname length has anything to do with it, because I have a shadow.gif in the same directory that loads fine...

>This matches the behaviour of ACDSee. It's admittedly confusing to people not used to ACDSee, but for me it's natural, and I've been pretty much designing for myself with this one. It also reduces the clutter around the image.

Yeah, I figured out that you can scroll around using the arrow keys, which works as nice as the scroll bars. That'll be confusing to n00bs though.

Regarding the status bar, maybe you could reduce clutter even more by having it be a transparent overlay over the image; maybe barely visible at first, but it gets more opaque when you mouse over it or something.

Also,

>some way to advance to the next image one-handed on a laptop keyboard, possibly with , and . (obvious joke goes here).

I noticed that the scroll wheel changes through images (though it's a bit too fast). I use SideTrack to emulate a scroll wheel on my trackpad. It's a nifty hunk of code; you might wanna give it a try. It's so nice even a tightwad like me went ahead and paid the registration fee ($15).
http://www.macupdate.com/info.php/id/12800

> Yeah, I figured out that you can scroll around using the arrow keys, which works as nice as the scroll bars. That'll be confusing to n00bs though.

You can use the mouse to drag the image around too. I should probably change the cursor to indicate that.

> Regarding the status bar, maybe you could reduce clutter even more by having it be a transparent overlay over the image; maybe barely visible at first, but it gets more opaque when you mouse over it or something.

No, I don't think an image viewer should overlay anything on the image by default, and I want to be able to read it all the time. Since the resize hande in the lower left corner is already at risk for overlaying the image, the status bar is good for avoiding that, too.

Tried to make it work on a very big image I have - no joy. Image is linked - it is about 36k pixels wide and I wouldn't recommend opening it in Safari.

Sorting bug: I have a set of images (1-1.jpg 1-2.jpg .. 1-10.jpg 1-11.jpg 1-12.jpg) and they're displayed 1,10,11,12,2.

>>15

The whole image has to fit into memory at least twice when loading, due to it having to be converted to OpenGL textures... I might manage to squeeze down the memory requirements a bit, but I suspect it'll never be able to properly load really huge images. That's also bigger than 32k pixels wide - can Quicktime itself open it?

>>16

Mac OS X seems a bit schizophrenic about how to sort files - the file list you get back from NSFileManager is sort differently than the Finder list. I'll probably work around it at some point - do you know if there are any functions to do sorting the same way as the Finder?

At least for JPEG a near-arbitrary size is possible, if you write your own decoder. You need only decode enough 8x8 blocks to fill ~1.5 times the size of the screen, and upload that to the card. Today's processors should be fast enough to decode additional blocks on demand as the user scrolls around.

It's an ugly hack, but considering the prevalence of JPEGs, it might be worth doing.

Actually, libjpeg works by decompressing scanlines, so you can easily do on-demand in the y-axis. Regrettably, it can't do it for x.

Combine that with one GL texture per scanline, and it's better than nothing.

Subdividing textures too much would play hell with resizing the image. Also, the lines have to be subdivided further, either (on more modern cards) if the image is wider than the max texture size, or (on older cards) to make sure all textures used are of power-of-two size. Adding dynamic loading on top of that is a bit more than I feel like doing at the moment. Besides, you'll run into trouble as soon as you zoom out.

Sounds like you're having fun. o/

What's the deal with OSX's 2D API's? Are they really that bad?

They're not designed for this (which is a polite way of saying they're slow, especially Cocoa). I think there are fast ways involving the C Quartz 2D APIs or QuickDraw, but one is complex and the other is complex and obsolete.

http://wakaba.c3.cx/releases/mac/Xee_alpha_2.zip

Some things mentioned in this thread are fixed, many aren't. I mostly concentrated on doing a lot of re-writing of the image loading code. It now supports loading sub-images in formats that support this (Photoshop layers, JPEG thumbnails) and GIF animations. This is more in spite of than thanks to the Quicktime APIs.

Use 1 and 2 to flip through sub-images or frames. If anyone has a better suggestion for keys to use for this, do tell.

What's the point of displaying "24 bits RGB" for a JPEG? They aren't.

That's what Quicktime says they are, so that's what I'm stuck with. Quicktime also seems to think 32, 64 and 128 colour GIFs are 256 colours. I've been considering making my own code to extract more correct image properties.

For practical purposes, though, JPEGs are 24 bit RGB. Unless they're 8 bit grayscale.

http://wakaba.c3.cx/releases/mac/Xee_alpha_3.zip

Just getting this out before going to sleep. Even more work on the image loading code - background loading can now be interrupted properly when skipping through images, so things should be a bit more responsive.

Also supports deleting files now - press delete or backspace to move files to the trashcan. Moving and copying files will come later.

The thought just occurred to me that since Xee uses QuickTime, it'll never be ported to other unixen. Nooooo!

Ever consider using FFmpeg (although that is one hell of a dependency...)?

I don't really use Quicktime to load anything but bitmap images, so something like ImageMagick would be a better fit. However, I am not using it right now because it would mean the difference between a 60kb executable and a 12 megabyte one. It is, I think, well-designed enough that porting it to use a different image loading library should be fairly easy.

The idea of porting it to OpenStep has occured to me more than once, but I don't know how much functionality that has.

...probably not enough. I'm using some of the wonderful recent Apple functionality like Cocoa bindings (tying interface elements directly to preference values, without glue code - so lovely). Well, you could add the glue code, but I dunno if it's worth it anymore then.

And does OpenStep handle NIB files? I have no idea.

...and I guess I should be saying "GNUStep" and not "OpenStep":

The OSX APIs are completely beyond my realm of experience, so I have no idea. However, this fellow seems to have pulled it off: http://lynkeos.sourceforge.net/

This is particularly relevant with regard to Cocoa<->OPENSTEP<->GNUstep conversions: http://mediawiki.gnustep.org/index.php/Writing_portable_code

And, ah, do something about the cookie code already, will ya? I'm getting testy about this.

Thank-you, thank-you, I'll be here all night.

> press delete or backspace to move files to the trashcan

Some image viewers use backspace to browse backwards in a directory. (i.e. the opposite of pressing space)

Ah, yes. But Mac uses backspace for deletion instead of delete, for some unfathomable reason. I'd just as well use only delete, but the Mac people might disagree with me there. Well, at least there's a protective confirmation dialog before deleting.

The Mac doesn't have a backspace key. It has a Delete key in the place where the Backspace key is on Wintel keyboards. It has the same functionality on both systems. The key that Wintel boards call the "Delete" key is called the "Forward Delete" key on the Mac. Again, same functionality. Just understand that it rubs Mac users the wrong way to say that the Mac is "wrong" because it has a "delete" key instead of a "backspace" key or some shit.

Anyway, I would suggest using Command-Delete to move a file to the trash. It's the same command as the Finder, and the chording will reduce accidental trashings. Either way, a confirmation dialog shouldn't be necessary when it's just moving files to the trash (as opposed to immediately deleting).

Well, the Mac is certainly in a minority with the "Delete" and "Forward delete" thing. Every other platform I've used has "Backspace" and "Delete", and that's definitely not just limited to Wintel machines.

Also, I really dislike chording the delete key. Chords are for making keys do something other than they usually do, and the delete key should delete without having to sprain any fingers.

...maybe I'll do both: Pressing option-delete will delete the picture immediately, pressing delete will ask.

http://wakaba.c3.cx/releases/mac/Xee_alpha_4.zip

Another done-for-the-night release. This one has more fixes for bugs in the loading and threading code (goddamn but I hate multi-threading), some improvements to the deletion (>>37, and also it doesn't say "...and so on" any longer), fixed file ordering, and support for opening directories. Also, you can use space to skip to the next image now.

Okay, I gave the program another try. Opening directories doesn't seem to be working in the Open dialog box. Dragging a directory to the Dock's icon worked, though.

Neither is a dialog box appearing when I press (the Mac's) Delete. The program doesn't do anything... Command-Delete works though. Space works.

Also, I forgot to mention in my last post... Be careful implementing any function to the Mac's Forward Delete key. Laptops don't have it.

Still a big fan of this program's speed. Keep it up!

Okay, I just used Xee to browse through some pictures I took with my digicam today and delete the ones that didn't turn out well, but it brought to light what would be another nice feature... image rotation, for viewing the "vertical" pics I took. It doesn't have to "save" the rotation; just remember it while I have that directory open. Can do?

> Opening directories doesn't seem to be working in the Open dialog box.

Is this even possible to do? I have no idea.

> Neither is a dialog box appearing when I press (the Mac's) Delete.

Weird. I programmed it to respond to both backspace and delete on this standard USB keyboard I'm using...

> image rotation

That's planned. I'm meaning to add lossless JPEG rotation for just that purpose, so you can safely rotate an image without it getting recompressed.

>Is this even possible to do? I have no idea.

Yes. Fire up Bits on Wheels or the official BitTorrent client (if you've got either) and try to make a torrent from a directory of files. The dialog box will let you select a directory. Also, if your Mac came with GraphicConverter (Minis and iMacs might not have it), try its File: Browse Folder... dialog box.

Also: If someone (Hello, MrVacBob!) could tell me why when I try to do an "open -a Xee file.jpg", the Xee icons appears briefly (even if it's already running) and then disappears again, I would be most grateful.

Does it work for anyone else?

http://wakaba.c3.cx/releases/mac/Xee_alpha_5.zip

This is the Albright Release. I fixed the bug mentioned about with deletion not working right, and I added lossless JPEG transforms using exiftran. This means the program nearly quadrupled in size, but oh well.

The JPEG menu has options for transforming JPEG files in various ways. The images need to be a multiple of 8 pixels (Or was that 16? I forget.) wide and high for this to work well, but it should be lossless in either case. If your camera writes EXIF orientation tags to its images, you can just press Command-A to automatically rotate the image according to how the camera thinks it should be oriented.

Oh, and it's also possible to open directories in the open dialog now.

Also, a request: Xee is in dire need of icons. It needs a program icon, and icons for the different file types it supports (it would be nice if these were subtly colour-coded, too). Personally, I am completely lost when it comes to Mac icon design, and I haven't been able to find anyone to rope into doing this for me yet.

Any takers?

Here's what I get when I try to open images from the command line...

Twelve:~/Desktop/103CANON Albright$ open -a Xee IMG_0367.JPG 
2005-08-06 13:23:42.821 open[1410] Couldn't open file: /Users/Albright/Desktop/103CANON/IMG_0367.JPG

Delete key works, rotation works, opening directories work. Auto rotation didn't work, but I don't think my camera writes orientation EXIF data. Xee approaches perfection a little more every day. Thanks!

>and icons for the different file types it supports (it would be nice if these were subtly colour-coded, too)

It's cool if you want to do this, but please make it possible to view pix in Xee without the file becoming "Xee's file." Applications that claim files as their own without my permission just because I open (but do not save) files with them piss me off to no end; Graphic Converter and Windows Media Player do this, and it's very annoying.

...and now that I test it again, open -a Xee works perfectly. What the hell?

Also, yes, Xee won't claim files as its own without being told to. I might add some option for it to claim the filetypes it supports, but that's about it.

Since nobody else is reporting it, I'll instead rant about a new bug: If you install Xee, and do an "open Folder/", you won't get a Finder window, you'll get a Xee window.

Why, you ask? Because I declared that Xee can open folders by using the UTI public.folder. The finder declares a folder file type too, *but doesn't use the public.folder UTI, but instead an incorrect OSType of fold!*

This after Apple making a big point about how great UTIs are for identifying files. The Finder doesn't use UTIs at all! So if I claim to be able to open it, this breaks the open command!

Which all means that the next version of Xee won't let you drop folders on its icon, because I have to claim public.folder to do that. Which I can't.

Opening folders with the open command, or from the open dialog, will still work, though.

http://wakaba.c3.cx/releases/mac/Xee_alpha_6.zip

All right, the "bug" in >>49 is "fixed". I also added an "Open in Editor" option to throw images into Photoshop your favourite legally-obtained image manipulation program.

All right, after an epic struggle against Apple's APIs, documentation and laziness (mine, not theirs), I have finally managed to finish another version of Xee:

http://wakaba.c3.cx/releases/mac/Xee_alpha_7.zip

The main new thing is the ability to move and copy files from inside Xee, with an interface I tried to optimize for quickly categorizing a lot of images, such as for imageboard downloads. I am not sure how successful this was, but I would be happy for any kind of feedback I can get on this.

There might be some other minor changes too, it's been a while and I've forgotten. This was originally meant to be beta 1, since I've now almost implemented all the basic functionality I wanted, and I was meaning to only polish the interface and fix bugs from now on, but it's becoming increasingly clear to me that I don't really want to use QuickTime for loading images, so I'd really like to find a good image loading library to replace it with. I wonder how small I can get ImageMagick if I don't use any of the image processing functions.

, and . are broken. So is the Delete key (but not Command-Delete).

Using the scroll wheel in the "Move file to..." panel still changes the picture instead of scrolling through the list (when the window is small enough that it becomes a scrollable list. Also, the "Choose a directory..." isn't logical interface design in my opinion. Maybe you could add a button with a folder and a plus sign instead... but it shouldn't be in the list.

> I don't really want to use QuickTime for loading images

Hooray!

> , and . are broken. So is the Delete key (but not Command-Delete).

This is probably when the list is selected. Since menus can't have printable characters as shortcuts (even if you can set them up like that), I have to read those keys manually, and currently the main view does that, so if it's unselected, it won't work. I'll need to work around this one way or the other.

> Using the scroll wheel in the "Move file to..." panel still changes the picture instead of scrolling through the list

A side effect of the fact that I had to do some ugly hacking to make the scroll wheel work when the mouse pointer is outside the window. This is counter-intuitive, but on the other hand it's useful when going through files and moving them. I am unsure of what to do about it.

> Also, the "Choose a directory..." isn't logical interface design in my opinion.

Granted. This time, though, it's to make it easier to run the program from the keyboard. How about putting some sort of spacer between it and the rest of the list? No matter how I think about it, just putting in a button seems a bit clumsy too, except if it was at the bottom of the list, but there it would be sort of hard to see...

>This time, though, it's to make it easier to run the program from the keyboard.

I don't see why a task which will be as uncommon as adding a folder to that list must be keyboard-accessable. If you're against a button, though, then how about maybe a line of text telling us to drag-and-drop folders from the Finder to add them to the list (just tried it and saw it works... cool).

How does moving files work using the keyboard, anyway? Only way I've found to do it is double-clicking on the folder (which itself is also a bit illogical, as it's not opening anything as a double-click usually does... perhaps a single-click (as a "choice") would work better).

(Sorry for the slow reply... I just recently tried the program again. It's not somethin I need to use every day, but when I do, it's quite handy.)

By the way, and maybe we're getting into feature bloat here... but could you maybe add a feature to rename images from within the application? That way I could easily label my digicam pictures "Curling on Canadian TV.jpeg" instead of "IMG_0258.JPG." Ditto with images from Wakachan.

> How does moving files work using the keyboard, anyway?

Err, you're SUPPOSED to be able to move files by using the arrow keys to select the destination and then pressing return, but I seem to have forgotten to actually implement this. The idea is that you can just use arrow up, arrow down, page up, page down, and return to flip through images and move them around.

> but could you maybe add a feature to rename images from within the application?

Yeah, I've been thinking the same thing.

A new version, now with source code for those who are into that kind of thing:

http://wakaba.c3.cx/releases/mac/Xee_alpha_8.zip
http://wakaba.c3.cx/releases/mac/Xee_alpha_8_src.zip

Mainly a lot of re-working of the internals. The loading code now uses significantly less memory, especially when loading and showing JPEGs. The GIF anim code has also been completely re-written and no longer uses Quicktime. This means a dramatic decrease in memory usage, and better playing of animated GIFs (it appears Quicktime doesn't implement all the correct deviations from the spec that are needed to correctly show all files out there). There is now also proper support for transparent images of various kinds.

No fixes for the various keyboard issues mentioned earlier, though. That's still to come. Now would also be a good point to remind me about other bugs and features I've forgotten about!

A quick bugfix release:

http://wakaba.c3.cx/releases/mac/Xee_alpha_9.zip
http://wakaba.c3.cx/releases/mac/Xee_alpha_9_src.zip

Fixes some bugs introduced in the previous version (Automatic Zoom being broken, files getting added to the destination list instead of directories), and also fixes numerous keyboard problems, and the scroll wheel issue mentioned earlier.

The keyboard and Automatic Zoom work, but I notice that one comic shows every new page scrolled to the bottom.

>>60

Oops, forgot that I turned the coordinate system upside-down. Will be fixed.

Release release &c &c

http://wakaba.c3.cx/releases/mac/Xee_alpha_10.zip
http://wakaba.c3.cx/releases/mac/Xee_alpha_10_src.zip

New: Now tries to use both Quicktime and NSImage for loading, meaning more image formats are supported. Broken JPEGs are now also handled by NSImage, which is better at reading them than Quicktime. It is also now possible to rename files from inside Xee, and the destination list has a pop-up menu with a couple of useful options.

AGED.

I would love to help with >>46, but sadly I'm not THAT good at OSX icon design. I'll try and see what I can do sometime this week. Document icons are quite simple to create to fit with HIG (Human Interface Guidelines) once you have an application icon. :P

My idea was a globe of light. It could be any color for when it's in the dock or as a normal icon. In the document icons, the globe could be a different color for each filetype.

Also, Xee is my primary image viewer on my computer. I haven't touched Preview for a month now. That must mean something. :P

Apple is already using the coloured-orb image for their various Core APIs, though. Something based on an eye is one idea that comes to mind, though...

Ah yes, I forgot about the whole Core APIs ordeal. I'll see what I can do.

Finally I have implemented all the functionality I had planned for the version version (and a lot more besides):

http://wakaba.c3.cx/releases/mac/Xee_beta_1.zip
http://wakaba.c3.cx/releases/mac/Xee_beta_1_src.zip

I've been struggling with this one for so long now I've forgotten what I've implemented. It should include:

• Image saving
• Copy to clipboard and Show clipboard
• Find-as-you-type and colors in the destination list
• Stuff I forgot
• Bugfixes and new bugs

From now on, I'm trying to focus on bugfixing and polishing for a real 1.0 version. I still need to clean up the status bar a lot, and I need icons, and I was thinking I'd like a Japanese version. Now, what I'd like is for people to actually go through and test the various features that are in there and tell me if they break, and if I am missing something very basic. I'm putting of major new functionality until after 1.0, though.

And here's another beta version. It features only "bugfixes". Truth to be told, I got kind of carried away and did a lot more than fix bugs. I added custom loading code for PNGs (QuickTime's PNG loader has some annoying bugs), PCXs (I guess I could claim it's a bug that it couldn't load all my old PCX files...) and good old Amiga IFF-ILBM files (I have no excuse for that one, I just got carried away).

http://wakaba.c3.cx/releases/mac/Xee_beta_2.zip
http://wakaba.c3.cx/releases/mac/Xee_beta_2_src.zip

For any old Amiga geeks who happen to be hanging around, I implemented a very fully-featured IFF-ILBM reader. It supports all the wacky screen modes (EHB, HAM, HAM8), non-square pixels (640x200 and 320x400 modes and such), and even colour cycling (press 3 to activate it!). I hacked at it until it could load and the Deluxe Paint example images I was able to find (from DPaints 1, 4 and 4.5), except those that were broken out of the box (two of them were). You can find those images at http://wakaba.c3.cx/stuff/dpaint.zip if you want to marvel at the moving colours!

Also, thanks to the #abime.net people for helping me track down those images!

> even colour cycling

hahaha christ

Just found this... excellent work, goodbye Preview.

A way to recursively open every image in a folder would be nice. An option in preferences to turn this on and off and with a recursive depth setting would be wonderful.

I've been considering that one, but it has some problems. For one, it shouldn't lock up the entire program if you happen to open the root directory. The scanning depth helps with that, but doesn't quite eliminate the problem.

Well, either way, it'll wait until after I get 1.0 done.

So... when are we getting sneak peeks of them icons? ;)

BEHOLD: The Icon!

Thanks to the talented and twisted James "Kibo" Perry (http://www.kibo.com/), there is now an icon for Xee! This isn't quite the final version, I think, but it's close.

It's SQL quality!

I was meaning to make the next release the final release candidate, but since it's taking some time to get everything into shape, and I'm going away for a couple of days, I figured I might as well release a half-done version to get some comments on how it looks so far. The main new thing is the status bar. The icons it uses currently don't quite fit, but consider them placeholders until I work out something better. Now, do your duty and complain!

http://wakaba.c3.cx/releases/mac/Xee_beta_3.zip
http://wakaba.c3.cx/releases/mac/Xee_beta_3_src.zip

>>74
Don't you mean James "Kibo" Parry?

Also, please kill me for getting Kibo's last name wrong. orz

What makes me not use Xee is that it hasn't got support for viewing comics directly from zip files. Footagehead does this. Footagehead can even view zip files within zip files. Is that too hard to implent if using zlib?

alt.religion.kibology????

>>77

It's non-trivial to implement. FFview has a library to make it easier, but I haven't looked into it. The biggest problem is getting the external image loading libraries to load the files properly.

Personally, I've long since gotten into the habit of just unpacking all archives. Reading files out of a zip will always be slower anyway, and more cumbersome if you want to use the files for something other than just reading.

>>78

He's Fred, Jim.

>>79

You personally know kibo? Neat. He's the old-school internet famous.

Well, I know him well enough to get him to draw me an icon, at least. I used to be a somewhat active poster on ARK, which sooner or later leaves you with a Kibo number of 1.

Anyone who read Waha's entry on Wikipedia knows that he is a famous Kibologist like Mr VacBob.

A post from an alternate universe!

>>82

We're all on big cabal (TINC).

There is a cabal we just hide ourselťœĬģĄÕP¿_¶ÂñºlNO CARRIER

What's this cabal thing? Is it like "nurupo"?

I'm getting this crash frequently:

Date/Time: 2005-10-09 12:24:11.016 -0400
OS Version: 10.4.2 (Build 8C46)
Report Version: 3

Command: Xee
Path: /Users/astrange/Xee.app/Contents/MacOS/Xee
Parent: WindowServer [77]

Version: ??? (1.0 beta 3)

PID: 11442
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x058a2000

Thread 0 Crashed:
0 <<00000000>> 0xffff88a4 __memcpy + 260 (cpu_capabilities.h:189)
1 com.apple.ATIRage128GLDriver 0x03771c2c gldGetTextureLevel + 1776
2 com.apple.ATIRage128GLDriver 0x03711384 gldDestroyPipelineProgram + 2172
3 com.apple.ATIRage128GLDriver 0x0376abc8 gldUpdateDispatch + 104
4 GLEngine 0x035f9be8 glBegin_Exec + 408
5 cx.c3.xee 0x0000c33c -[XeeBitmapTile drawWithTarget:bounds:] + 356 (crt.c:355)
6 cx.c3.xee 0x0000bad8 -[XeeBitmapImage draw:size:bounds:] + 532 (crt.c:355)
7 cx.c3.xee 0x00003e18 -[XeeView drawRect:] + 1572 (crt.c:355)
8 com.apple.AppKit 0x925069b0 -[NSView _drawRect:clip:] + 2128
9 com.apple.AppKit 0x92505f80 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 404
10 com.apple.AppKit 0x92508c98 _recursiveDisplayInRect2 + 84
11 com.apple.CoreFoundation 0x9f005b84 CFArrayApplyFunction + 416
12 com.apple.AppKit 0x92506094 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 680
13 com.apple.AppKit 0x92508c98 _recursiveDisplayInRect2 + 84
14 com.apple.CoreFoundation 0x9f005b84 CFArrayApplyFunction + 416
15 com.apple.AppKit 0x92506094 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 680
16 com.apple.AppKit 0x92505558 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 196
17 com.apple.AppKit 0x9252617c -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 192
18 com.apple.AppKit 0x924ff1cc -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 384
19 com.apple.AppKit 0x924f44d0 -[NSView displayIfNeeded] + 248
20 com.apple.AppKit 0x925b5934 -[NSThemeFrame handleSetFrameCommonRedisplay] + 256
21 com.apple.AppKit 0x925020f8 -[NSWindow _setFrameCommon:display:stashSize:] + 708
22 com.apple.AppKit 0x92501e20 -[NSWindow setFrame:display:] + 40
23 cx.c3.xee 0x0000540c -[XeeController setViewSize:] + 980 (crt.c:355)
24 cx.c3.xee 0x00004f88 -[XeeController setImage:] + 692 (crt.c:355)
25 cx.c3.xee 0x00012f80 -[XeeDirectoryController displayImage:next:] + 212 (crt.c:355)
26 com.apple.AppKit 0x92561d2c -[NSApplication sendAction:to:from:] + 108
27 cx.c3.xee 0x000158ac -[XeeDirectoryWindow keyDown:] + 232 (crt.c:355)
28 com.apple.AppKit 0x9258eff8 forwardMethod + 92
29 com.apple.AppKit 0x9258eff8 forwardMethod + 92
30 cx.c3.xee 0x00004008 -[XeeView keyDown:] + 204 (crt.c:355)
31 com.apple.AppKit 0x9251d0d8 -[NSWindow sendEvent:] + 6424
32 com.apple.AppKit 0x924c5bfc -[NSApplication sendEvent:] + 4172
33 cx.c3.xee 0x00006e78 -[XeeApplication sendEvent:] + 424 (crt.c:355)
34 com.apple.AppKit 0x924bd090 -[NSApplication run] + 508
35 com.apple.AppKit 0x925ad8bc NSApplicationMain + 452
36 cx.c3.xee 0x00002d84 _start + 344 (crt.c:272)
37 cx.c3.xee 0x00002c28 start + 60

>>86

There is no cabal. Please move on, and remember, we never spoke. You never saw me, and I never saw you. Please, the non-existance of a non-group should not intrest you, even if they are not not intrested in you. This newsgroup does not exist, this newssever has no address, and even if it did, it would not exist to point to.

Have a nice day.

>>88
kinda like luelinks am i rite

>>87

A crash inside the GL driver? Aaaugh!

>>89 Only this cabal actually doesn't exist.

>>90

Yeah. I haven't tried RGB mode yet, but I'll give you the images when I get home so you can fiddle with tiling or something.

If you were holding your breath while waiting to find out how this would turn out, rest assured that the crash was fixed. The bug is apparently in Apple's Rage128 driver, but a quick workaround seems to have calmed it down. Xee will use a bit more memory on Rage128 thanks to it, though.

>>86
GA!

Thank you for this, it is wonderful.
I wish i could remap the forward and next buttons though.

>>95

I don't think I feel like spending all the effort that would be required for that, but if you really want to do that, install the developer tools (so that you have Interface Builder.app), and then do a "Show Package Contents" on Xee, go to Contents/English.lproj/, and click on MainMenu.nib. That should launch Interface Builder, and you can edit all the menus to your heart's content.

Well, after some waiting, I've now decided that Xee is good enough for a real 1.0 release.

http://wakaba.c3.cx/releases/mac/Xee1.0.zip

1.0 features some more bugfixes, a full set of icons by James "Kibo" Parry, and a Japanese translation by Hinata. Many thanks to them, and also to MrVacBob for being an invaluable help for me while trying to get a grip on Objective-C and Mac OS X programming.

There is now a separate thread for general support questions for Xee, which is also linked from inside the program itself:

http://wakaba.c3.cx/sup/kareha.pl/1132091963/

Source code is available, for those who want to hack or help out:

http://wakaba.c3.cx/releases/mac/Xee1.0_src.zip

http://www.apple.com/downloads/macosx/imaging_3d/xee.html

Ahahahahah, goddamn you, Apple!

Circlesoft?

Old name. Apple insists that you are part of a company if you make software.