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.