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.