Document Icons
björn
I had two problems getting the script to work (mostly my fault, but anyway):
1. If the vim-noshadow-512.png file is missing the following is logged
Traceback (most recent call last):
File "make_icons.py", line 159, in <module>
main()
File "make_icons.py", line 148, in main
createIcon(TMPFILE, NSString.stringWithString_(text))
File "make_icons.py", line 108, in createIcon
icon.drawInRect_fromRect_operation_fraction_(
AttributeError: 'NoneType' object has no attribute
'drawInRect_fromRect_operation_fraction_'
...it would probably be nicer with a "File missing" warning. It took
me a while to figure out what the problem was (despite you having
stated this clearly in your post...yes, I can be a bit slow). ;-)
2. The "LucidaSans-Demi" does not exist on my system. Again, if the
font is missing you get an unhelpful message:
2008-11-30 16:03:35.751 Python[615:613] *** -[NSNull
screenFontWithRenderingMode:]: unrecognized selector sent to instance
0xa0018020
Traceback (most recent call last):
File "make_icons.py", line 159, in <module>
main()
File "make_icons.py", line 148, in main
createIcon(TMPFILE, NSString.stringWithString_(text))
File "make_icons.py", line 111, in createIcon
text.drawInRect_withAttributes_( ((0.5, 23.5), (511, 120)), attribs)
ValueError: NSInvalidArgumentException - *** -[NSNull
screenFontWithRenderingMode:]: unrecognized selector sent to instance
0xa0018020
I tried using "LucidaGrande" instead (the only Lucida variant on my
system) and then everything works. Is there a big difference between
these two fonts?
When I saw this line
BACKGROUND = '/System/Library/CoreServices/CoreTypes.bundle/' + \
'Contents/Resources/GenericDocumentIcon.icns' # might require leopard?
I started up Tiger -- that icon does exist on Tiger as well...so no
problems there.
Anyway, all in all my concern is that there may be more problems
lurking and I worry that adding the icon making a separate build step
would cause problems when trying to build MacVim. We should be able
to iron out these problems but before I add this to the repo I think
we need to ensure that it will build on a "clean" Tiger/Leopard
install. It might be sufficient for me to just make a patch and send
it out asking people to try it out before I merge.
Finally, I really think we need to do something about the smaller
sized icons: they are completely illegible. I have attached the icon
for ".h" files to illustrate this point. This is the simplest icon
but even it is impossible to make out what it is supposed to be (even
at 32x32). I'm not sure exactly what to do about this, but one
suggestion is to make the file extension text cover the entire
document at 32x32 and lower. The MacVim icon could perhaps be toned
down or, in the case of 16x16, completely removed?
The problem with smaller icons is particularly important since they
are often the icons you see in Finder (at least if you use list/column
view in Finder) and since they are also displayed as proxy icons.
Björn
Nico Weber
On 30.11.2008, at 07:17, björn wrote:
> 2. The "LucidaSans-Demi" does not exist on my system. Again, if the
> font is missing you get an unhelpful message:
Bummer. The attached version uses Lucida Grande, which is a system
font. Its font metrics are a bit different, hence I had to change some
rects, but it looks very similar to Lucida Grande now (modulo the
digit glyphs, but we don't use those). It also adds some more helpful
error messages.
> When I saw this line
>
> BACKGROUND = '/System/Library/CoreServices/CoreTypes.bundle/' + \
> 'Contents/Resources/GenericDocumentIcon.icns' # might require
> leopard?
>
> I started up Tiger -- that icon does exist on Tiger as well...so no
> problems there.
But on Tiger it's probably not a 512x512 icon.
> Finally, I really think we need to do something about the smaller
> sized icons: they are completely illegible. I have attached the icon
> for ".h" files to illustrate this point. This is the simplest icon
> but even it is impossible to make out what it is supposed to be (even
> at 32x32). I'm not sure exactly what to do about this, but one
> suggestion is to make the file extension text cover the entire
> document at 32x32 and lower. The MacVim icon could perhaps be toned
> down or, in the case of 16x16, completely removed?
I'm doing some experiments with re-rendering the text for each icon
size instead of using the downsampled 512 variant, this yields
readable text at 32x32 (haven't tried with 16x16 yet). But let's get
the current version merged first.
Nico
Nico Weber
> font. Its font metrics are a bit different, hence I had to change some
> rects, but it looks very similar to Lucida Grande now (modulo the
> digit glyphs, but we don't use those). It also adds some more helpful
> error messages.
This attached version even works if doc-bm-generic.icns does not exist
when the script is started :-P
Nico Weber
> Finally, I really think we need to do something about the smaller
> sized icons: they are completely illegible.
I modified my script to re-render the text at sizes 128, 32 and 16.
The text on the 32x32 variants is pretty legible, the 16x16 text not
so much. Preview's icons don't have legible extensions at 16x16
either, though. I tried omitting the "text" on the 16x16 variant and
instead make the vim icon a bit bigger, but that didn't look much
better.
I've attached both an icns that contains rescaled versions of the 512
variants for 128, 32, and 16, as well as an icns that contains re-
rendered 512, 128, 32, and 16 variants (double-click the images to
open them in Preview and look at the different variants there). I'm
pretty happy with the re-rendered icns.
Comments?
Nico
Tobia Conforto
> Finally, I really think we need to do something about the smaller
> sized icons: they are completely illegible.
I believe this is an important point.
If you look at XCode's documen icons at 16x16 (screenshot below, to
the left) you will see that you can tell at a glance whether the file
is .C source code, .H header, or anything else of import. The large
(relatively to the icon size) and colored text, "C" or "H", helps a lot.
Larger icons can still use the Preview paradigm (blank paper + app
icon + type text below) but IMHO the smaller icons should follow what
XCode does.
If we want people to be able to tell the files that are associated
with Vim from those associated with XCode, we can come up with a
different graphical hint, such as a colored border--this is just the
first idea that came to my mind:
Andrew Long
> björn wrote:
>> Finally, I really think we need to do something about the smaller
>> sized icons: they are completely illegible.
>
> I believe this is an important point.
>
<snip/>
> If we want people to be able to tell the files that are associated
> with Vim from those associated with XCode, we can come up with a
> different graphical hint, such as a colored border--this is just the
> first idea that came to my mind:
>
I'm not szo sure that it's important. What's important to me is that the
file is a C source file, or a BASH script, or a SQL script. I can make a
choice about which application to open them with, once I know what the
file type IS
Regards, Andy
--
Andrew Long
andrew dot long at mac dot com
Tobia Conforto
>> If we want people to be able to tell the files that are associated
>> with Vim from those associated with XCode, we can come up with a
>> different graphical hint, such as a colored border
>
> the file is a C source file, or a BASH script, or a SQL script. I
> can make a choice about which application to open them with, once I
> know what the file type IS
Absolutely.
Maybe it wasn't clear from my post, butI agree that the file type
comes first.
XCode-like colors (C is blue, H is red...) help with that.
Tobia
Nico Weber
> > sized icons: they are completely illegible.
>
> I believe this is an important point.
>
> If you look at XCode's documen icons at 16x16 (screenshot below, to
> the left) you will see that you can tell at a glance whether the file
> is .C source code, .H header, or anything else of import. The large
> (relatively to the icon size) and colored text, "C" or "H", helps a lot.
to go with 16x16 icons similar to them is that I couldn't come up with
a way to handle longer extensions (e.g. "html").
> Larger icons can still use the Preview paradigm (blank paper + app
> icon + type text below) but IMHO the smaller icons should follow what
> XCode does.
Examples include Safari, CSSEdit, Instruments, Pages, Keynote,
QuickTime Player, iCal, Coda, etc. Some of those programs leave the
extension text out in the 16x16 variant and include only the icon
(Instruments, CSSEdit).
I think the 32x32 variant is still legible, so we're only talking
about 16x16 here.
XCode's approach works fine with 1-char extensions (h, c), ok with 2-
char extensions (mm, rb, ...), not-so-great with three chars (e.g.
expfile.icns in the XCode bundle), not-at-all with 4-char extensions
(nasmfile.icns).
> If we want people to be able to tell the files that are associated
> with Vim from those associated with XCode, we can come up with a
> different graphical hint, such as a colored border--this is just the
> first idea that came to my mind:
very low contrast). But: It's different from all other apps, and I
need a good suggestion how to handle document types with a long
extension that don't have an obvious shorter version ("Python" can
become "Py" without problems, but what about, say, "html", "xhtml",
"dylan", "fscript", "applescript").
Nico
björn
>
> I think the 32x32 variant is still legible, so we're only talking
> about 16x16 here.
I like the newer 32x32 icons too...I find it easy to read the "VIM"
written on them.
> XCode's approach works fine with 1-char extensions (h, c), ok with 2-
> char extensions (mm, rb, ...), not-so-great with three chars (e.g.
> expfile.icns in the XCode bundle), not-at-all with 4-char extensions
> (nasmfile.icns).
>
>> If we want people to be able to tell the files that are associated
>> with Vim from those associated with XCode, we can come up with a
>> different graphical hint, such as a colored border--this is just the
>> first idea that came to my mind:
>
> Perhaps we could also put the green square behind the letters (with a
> very low contrast). But: It's different from all other apps, and I
> need a good suggestion how to handle document types with a long
> extension that don't have an obvious shorter version ("Python" can
> become "Py" without problems, but what about, say, "html", "xhtml",
> "dylan", "fscript", "applescript").
I can't think of any way to deal with the 16x16 icons in a consistent
way so I suggest we simply put the green diamond (without the "V") on
the 16x16 icon and leave out the extension. (Even the "V" is hard to
distinguish at 16x16 which is why I think we should leave it out.)
The one-letter (and maybe two-letter) extensions could have icons
similar to the XCode ones, but as for the rest I think there is not
much we can do. Maybe we can experiment with this more later on?
Björn
Nico Weber
> similar to the XCode ones, but as for the rest I think there is not
> much we can do. Maybe we can experiment with this more later on?
After that, I'll prepare a patch for the "nice 32x32" version, and
when that is merged, I'll see if I have come up with nice 16x16 until
then.
Nico
björn
Nico,
I've been trying to get the icon making stuff to work on Tiger and it
is not entirely unproblematic.
Problems with gettng 'makeicns' to compile:
1. makeicns.m won't compile because of:
i) use of Obj-C 2.0 iterators in getBitmapImageRepOfSize() (only one spot)
ii) kIconServices512PixelDataARGB is not defined (can be found in
IconFamily.m)
2. can't link makeicns because Intel versions of libraries not present
on PPC machines (ok if "-arch i386 is removed from the Makefile)
I did get the program to compile&link after fixing those two things
(that was the easy part).
Problems with make_icons.py:
1. I get this: "ImportError: No Module named Foundation". It seems
that the Foundation module is 10.5 only...is there any way to work
around this?
I'm not very familiary with Python so I couldn't get this step to work at all.
There is also a problem with 512 icons: the generic document icon does
not come in 512x512 on Tiger (only 128x128 as you suspected) and I
don't think the "IconFamily.m" module handles 512 icons on Tiger
either (see line 390).
It would be great if you could work around these issues on Tiger (by
only making 128 icons unless compiled on Leopard). If you can't then
I guess we'll have to add the .icns files to the repo. (?)
Björn
Nico Weber
> is not entirely unproblematic.
>
> 1. I get this: "ImportError: No Module named Foundation". It seems
> that the Foundation module is 10.5 only...is there any way to work
> around this?
> It would be great if you could work around these issues on Tiger (by
> only making 128 icons unless compiled on Leopard). If you can't then
> I guess we'll have to add the .icns files to the repo. (?)
script, the repo grows a few MB. And every contributor has a local
copy of the repo. What if I simply change the script to create
symlinks to the MacVim icon when it runs on Tiger? Then people
building on Tiger will have somewhat useless document icons, but that
sounds like the lesser of two evil.
Nico
björn
>
>> It would be great if you could work around these issues on Tiger (by
>> only making 128 icons unless compiled on Leopard). If you can't then
>> I guess we'll have to add the .icns files to the repo. (?)
>
> I don't think this is a good idea: Every time we change the generation
> script, the repo grows a few MB. And every contributor has a local
> copy of the repo.
Yeah, I'd like to avoid this too.
>What if I simply change the script to create
> symlinks to the MacVim icon when it runs on Tiger? Then people
> building on Tiger will have somewhat useless document icons, but that
> sounds like the lesser of two evil.
If there is nothing that you can use instead of pyobjc then I guess
this is an ok compromise (anybody using Tiger who has an objection to
this, please speak up). I can also put an archive with all the
document icons on the project web page so that anybody on Tiger can
download them manually if they so wish.
The most important thing is that MacVim will build on Tiger without any hiccups.
Björn
Ben Schmidt
>> symlinks to the MacVim icon when it runs on Tiger? Then people
>> building on Tiger will have somewhat useless document icons, but that
>> sounds like the lesser of two evil.
>
> If there is nothing that you can use instead of pyobjc then I guess
> this is an ok compromise (anybody using Tiger who has an objection to
> this, please speak up).
Could we keep one generic MacVim document icon in the repo and link to
that, just so they look like documents, not applications? Or is that
what you meant?
Even if there is something that can be used instead of PyObjC, then this
seems like a good step to take until/unless someone has time and
inclination to implement in something else.
> I can also put an archive with all the
> document icons on the project web page so that anybody on Tiger can
> download them manually if they so wish.
Sounds good.
Ben.
Steven Michalske
On Dec 13, 2008, at 3:28 AM, björn wrote:
>>>
>>> It would be great if you could work around these issues on Tiger (by
>>> only making 128 icons unless compiled on Leopard). If you can't
>>> then
>>> I guess we'll have to add the .icns files to the repo. (?)
>>
>> I don't think this is a good idea: Every time we change the
>> generation
>> script, the repo grows a few MB. And every contributor has a local
>> copy of the repo.
>
> Yeah, I'd like to avoid this too.
use a git subproject?
then it could link to the latest copy and would not require a growing
repo.
use a download?
compiled resources don't always need to be in a source control
repository.
Nico Weber
>>> symlinks to the MacVim icon when it runs on Tiger? Then people
>>> building on Tiger will have somewhat useless document icons, but
>>> that
>>> sounds like the lesser of two evil.
>>
>> If there is nothing that you can use instead of pyobjc then I guess
>> this is an ok compromise (anybody using Tiger who has an objection to
>> this, please speak up).
>
> Could we keep one generic MacVim document icon in the repo and link to
> that, just so they look like documents, not applications? Or is that
> what you meant?
>
> Even if there is something that can be used instead of PyObjC, then
> this
> seems like a good step to take until/unless someone has time and
> inclination to implement in something else.
The appended version uses the generic document icon on Tiger.
Nico
Nico Weber
>> document icons on the project web page so that anybody on Tiger can
>> download them manually if they so wish.
Since they are included with MacVim anyways, that doesn't seem
necessary and means more work for you.
Nico
björn
>
> The appended version uses the generic document icon on Tiger.
Thanks, I can confirm that it works. It is a bit of a shame that
building on Tiger gives you a blank (i.e. without the Vim diamond on
top) generic document icon though...
The remaining problem is to get makeicns to build with the rest of the
project. It is not possible to simply call the makefile because
linking fails if you pass "-arch i386" on PPC/Tiger. The best
solution would be to build natively under the Debug/Release
configurations and build universal (if possible) under the Universal
configuration. Does anybody have any ideas of how to do this? (I
don't much enjoy figuring these sort of things out myself I'm afraid.)
Björn
Nico Weber
> project. It is not possible to simply call the makefile because
> linking fails if you pass "-arch i386" on PPC/Tiger.
What about simply leaving away the -arch flags in the Makefile?
makeicns is only used during build-time, so it's ok if it's built only
for the architecture of the mac running the build.
Nico