Deprecating mvim.app. WAS: What's the rationale behind not using a normal PATH?
björn
>
> mvim.app is a slight modification of gvim.app, and both of those were
> available long before the MacVim preference.
>
> So, for...most...intents and purposes, mvim.app is deprecated due to the
> *relatively* new MacVim preference. Additionally, if you read the blog
> post, the purpose off gvim.app and mvim.app had to do with File
> Associations. The launching in a login shell was just a bonus.
Ted,
I've asked this in the past, but would you consider adding all the
file associations/icons in mvim.app to MacVim's Info.plist so that you
can deprecate mvim.app once and for all? If you don't want to do it
-- do you mind if I simply copy everything over myself? Or is there
some other reason for keeping mvim.app alive?
Björn
Ted Pavlic
>> So, for...most...intents and purposes, mvim.app is deprecated due to the
>> *relatively* new MacVim preference. Additionally, if you read the blog
>> post, the purpose off gvim.app and mvim.app had to do with File
>> Associations. The launching in a login shell was just a bonus.
>
> I've asked this in the past, but would you consider adding all the
> file associations/icons in mvim.app to MacVim's Info.plist so that you
> can deprecate mvim.app once and for all? If you don't want to do it
> -- do you mind if I simply copy everything over myself? Or is there
> some other reason for keeping mvim.app alive?
I've been hesitant to do so because, IIRC, when I added all of those
associations, I just grabbed them from some other not-so-open-source
text editor on my system (e.g., TextMate or BBEdit... I don't remember)
and made a few modifications. I know this is poor form, but the "app"
was not meant to be exported initially... but then I saw posts from
people with the same problem, so I posted it with no claims about its
legitimacy.
So was is the copyright status of file associations buried within an
application bundle? If you think there's no problem, then I'm fine with
just moving them over. Otherwise... I guess someone (?) has to manually
add them in some sort of fresh manner. :(
Sorry for not responding about this a LONG time ago... it was always on
my ToDo list... but then my ToDo list turned more into a ToDo stack...
and... well... you know.
--Ted
--
Ted Pavlic <t...@tedpavlic.com>
Matt Tolton
to me if a list of file extensions could really be copyrighted.
Matt Tolton
Grr.
Ted Pavlic
> to me if a list of file extensions could really be copyrighted.
It still was a significant amount of work that someone else did that I
totally stole. It would have taken me a long time to:
a) Come up with that list
b) Convert it to the pref format that OS X needs
--
Ted Pavlic <t...@tedpavlic.com>
Ben Schmidt
>> to me if a list of file extensions could really be copyrighted.
>
> It still was a significant amount of work that someone else did that I
> totally stole. It would have taken me a long time to:
>
> a) Come up with that list
>
> b) Convert it to the pref format that OS X needs
IANAL. I'm also in Australia, and have no idea under what legal
jurisdiction MacVim falls, or the aforementioned not-so-free app, or
whether it really matters. But...I do know, or think I know, that
- The amount of work put into it is irrelevant.
- Nonetheless copyright may well subsist in the 'compilation' of those
associations, i.e. the selection and arrangement of them (so, yes the
'coming up with the list' part does make it copyright; not because it
was a lot of work, but because it was essentially creative work).
- Copyright wouldn't subsist in the individual associations themselves,
which is the kinda obvious thing: just because one person associates a
filetype to an app doesn't mean nobody else can do the same!
So, yeah, I believe basically you can come up with your own list which
incidentally will have similar associations to a lot of other people's
lists, but you can't just rip someone else's list unless it has a
compatible license.
Ben.
Matt Tolton
not-so-free app and ask for permission?
Nico Weber
>>> to me if a list of file extensions could really be copyrighted.
>>
>> It still was a significant amount of work that someone else did
>> that I
>> totally stole. It would have taken me a long time to:
>>
>> a) Come up with that list
>>
>> b) Convert it to the pref format that OS X needs
>
> IANAL. I'm also in Australia, and have no idea under what legal
> jurisdiction MacVim falls, or the aforementioned not-so-free app, or
> whether it really matters. But...I do know, or think I know, that
Why not play safe and do a clean-room reimplementation. Ted, can you
just post the list of file extensions here? Converting the list of
extensions into a patch to the plist file should be matter of 10
minutes with python and/or vim macros; I can do that.
Nico
Ben Schmidt
> just post the list of file extensions here? Converting the list of
> extensions into a patch to the plist file should be matter of 10
> minutes with python and/or vim macros; I can do that.
Wouldn't the logical thing be to base it on $VIMRUNTIME/filetype.vim?
Just grep for the autocommand patterns somehow, trim stuff you probably
wouldn't actually want associated, add a few obvious non-highlighted
extensions (like *.txt), and keep a copy of the file you used, so
periodically it can be compared to the current runtime files and
additions get picked up and incorporated.
Just my few cents.
Ben.
Ted Pavlic
> just post the list of file extensions here? Converting the list of
> extensions into a patch to the plist file should be matter of 10
> minutes with python and/or vim macros; I can do that.
*) Here's the bundle, uncompressed so you can peruse it on-line:
http://www.tedpavlic.com/examples/mvim/mvim.app
*) Here's the plist with the file extensions:
http://www.tedpavlic.com/examples/mvim/mvim.app/Contents/Info.plist
*) Here are all if the corresponding icons:
http://www.tedpavlic.com/examples/mvim/mvim.app/Contents/Resources/
Each icon has an (old?) Vim icon with text across the bottom telling you
what type of file it is. I *think* I modded those myself... but it's
been so long ago. :( Again, initially I never figured this app would
leave my /Applications folder...
**NOTE: The pList pattern is fairly regular, HOWEVER there are several
MIME types in there too, and plenty of entries have several extensions
associated with a single icon (txt.icns, for example).
Ted Pavlic
> associations, i.e. the selection and arrangement of them (so, yes the
> 'coming up with the list' part does make it copyright; not because it
> was a lot of work, but because it was essentially creative work).
That's what I meant --- I should have said that it would have taken a
lot of creative energy for me to come up with that list. If I was its
original author, I might be offended if someone else were to use it
without acknowledging that it wouldn't exist if it weren't for me.
I would be able to figure out which Info.plist that matches (BBEdit,
TextMate, etc.), but I've gotten rid of all of my other text editors now
that I use MacVim so exclusively... :(
Nico Weber
On 14.11.2008, at 05:53, Ted Pavlic wrote:
>> Why not play safe and do a clean-room reimplementation. Ted, can you
>> just post the list of file extensions here? Converting the list of
>> extensions into a patch to the plist file should be matter of 10
>> minutes with python and/or vim macros; I can do that.
>
> *) Here's the bundle, uncompressed so you can peruse it on-line:
>
> http://www.tedpavlic.com/examples/mvim/mvim.app
>
> *) Here's the plist with the file extensions:
>
> http://www.tedpavlic.com/examples/mvim/mvim.app/Contents/Info.plist
>
> *) Here are all if the corresponding icons:
>
> http://www.tedpavlic.com/examples/mvim/mvim.app/Contents/Resources/
As far as I understand (IANAL either), the point of of clean-room
implementations is that I don't look at those files. Someone looks at
them and then says "Wouldn't it be great if MacVim worked with
filetypes .foo, .bar, and .baz?" and then someone else who hasn't seen
those files does the change.
See http://en.wikipedia.org/wiki/Clean_room_design .
Ben: Supporting _all_ filetypes from $VIMRUNTIME excessive to me.
Nico
Ted Pavlic
Don't forget about MIME types
Ted Pavlic
> implementations is that I don't look at those files. Someone looks at
Okay... So I think I need to give you a specification. How about this?
-----
Type: ADA source
Extensions: adb, ads
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/ada.icns
-----
-----
Type: AppleScript source
Extensions: applescript
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/applescript.icns
-----
-----
Type: ActionScript source
Extensions: as
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/as.icns
-----
-----
Type: ASP document
Extensions: asp, asa
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/asp.icns
-----
-----
Type: ASP.NET document
Extensions: aspx, ascx, asmx, ashx
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/asp.icns
-----
-----
Type: BibTeX bibliography
Extensions: bib
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/bib.icns
-----
-----
Type: C source
Extensions: c
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/c.icns
-----
-----
Type: C++ source
Extensions: cc, cp, cpp, cxx, c++
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/pp.icns
-----
-----
Type: C# source
Extensions: cs
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/cs.icns
-----
-----
Type: Context Free Design Grammar
Extensions: cfdg
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/csfg.icns
-----
-----
Type: Comma separated values
Extensions: csv
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/csv.icns
-----
-----
Type: Tab separated values
Extensions: tsv
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/tsv.icns
-----
-----
Type: CGI script
Extensions: cgi, fcgi
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/cgi.icns
-----
-----
Type: Configuration file
Extensions: cfg, conf, config, htaccess
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/cfg.icns
-----
-----
Type: Cascading style sheet
Extensions: css
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/css.icns
-----
-----
Type: Differences file
Extensions: diff
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/diff.icns
-----
-----
Type: Document Type Definition
Extensions: dtd
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/dtd.icns
-----
-----
Type: Dylan source
Extensions: dylan
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/dylan.icns
-----
-----
Type: Erlang source
Extensions: erl, hrl
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/erl.icns
-----
-----
Type: F-Script source
Extensions: fscript
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/fscript.icns
-----
-----
Type: Fortran source
Extensions: f, for, fpp, f77, f90, f95
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/f.icns
-----
-----
Type: Header
Extensions: h, pch
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/h.icns
-----
-----
Type: C++ header
Extensions: hh, hpp, hxx, h++
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/hh.icns
-----
-----
Type: GTD document
Extensions: gtd, gtdlog
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/gtd.icns
-----
-----
Type: Haskell source
Extensions: hs, lhs
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/hs.icns
-----
-----
Type: HTML document
Extensions: htm, pht, sht, xht, phtm, shtm, xhtm, html, phtml, shtml, xhtml
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/html.icns
-----
-----
Type: Include file
Extensions: inc
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/inc.icns
-----
-----
Type: iCalendar schedule
Extensions: ics
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/ics.icns
-----
-----
Type: MS Windows initialization file
Extensions: ini
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/ini.icns
-----
-----
Type: Io source
Extensions: io
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/io.icns
-----
-----
Type: Java source
Extensions: java
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/java.icns
-----
-----
Type: BeanShell script
Extensions: bsh
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/bsh.icns
-----
-----
Type: Java properties file
Extensions: properties
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/properties.icns
-----
-----
Type: JavaScript source
Extensions: js, htc
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/js.icns
-----
-----
Type: Java Server Page
Extensions: jsp
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/jsp.icns
-----
-----
Type: LISP source
Extensions: lisp, cl, l, lsp, mud, el
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/lisp.icns
-----
-----
Type: Log file
Extensions: log
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/log.icns
-----
-----
Type: Mediawiki document
Extensions: wiki, wikipedia, mediawiki
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/wiki.icns
-----
-----
Type: Objective-C source
Extensions: m
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/m.icns
-----
-----
Type: Objective-C++ source
Extensions: mm
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/mm.icns
-----
-----
Type: Patch file
Extensions: patch
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/patch.icns
-----
-----
Type: Perl source
Extensions: pl, pod, perl
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/perl.icns
-----
-----
Type: Perl module
Extensions: pm
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/perl.icns
-----
-----
Type: PHP source
Extensions: php, php3, php4, php5
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/php.icns
-----
-----
Type: PostScript source
Extensions: ps, eps
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/ps.icns
-----
-----
Type: Property list
Extensions: dict, plist, scriptSuite, scriptTerminology
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/plist.icns
-----
-----
Type: Python source
Extensions: py, rpy, cpy, python
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/py.icns
-----
-----
Type: Ruby source
Extensions: rb, rbx, rjs, rxml
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/rb.icns
-----
-----
Type: Scheme source
Extensions: scm, sch
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/sch.icns
-----
-----
Type: Shell script
Extensions: sh, ss, bashrc, bash_profile, bash_login, profile, bash_logout
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/bash.icns
-----
-----
Type: SQL source
Extensions: sql
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/sql.icns
-----
-----
Type: Tcl source
Extensions: tcl
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/tcl.icns
-----
-----
Type: TeX document
Extensions: tex, sty, cls, ltx, ins, dtx
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/tex.icns
-----
-----
Type: Plain text document
Extensions: text, txt, utf8
MIME Types: text/plain
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/txt.icns
-----
-----
Type: XML document
Extensions: xml, rss, tld, pt, cpt, dtml
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/xml.icns
-----
-----
Type: XSL stylesheet
Extensions: xsl, xslt
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/xsl.icns
-----
-----
Type: Electronic business card
Extensions: vcf, vcard
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/vcf.icns
-----
-----
Type: Visual Basic source
Extensions: vb
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/vb.icns
-----
-----
Type: YAML document
Extensions: yaml, yml
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/yaml.icns
-----
-----
Type: VIM Script
Extensions: vim
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/vim.icns
-----
-----
Type: Document
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/document.icns
-----
IIRC, the icns files were ones I generated by modifying something I
stole from MacVim (or gvim?).
Nico Weber
On 14.11.2008, at 11:21, Ted Pavlic wrote:
> Okay... So I think I need to give you a specification. How about this?
That looks great. I've written a small python script that converts
this to plist format; both script and output are attached.
The plist assumes that the icons are in mvim's Resource bundle and
named doc-bm-<current-name>, perhaps you (Ted) can rename them, zip
them up, and send them here?
Nico
björn
> On 14.11.2008, at 11:21, Ted Pavlic wrote:
>
>> Okay... So I think I need to give you a specification. How about this?
>
> That looks great. I've written a small python script that converts
> this to plist format; both script and output are attached.
I'd be very grateful for a patch against MacVim's Info.plist (and the
xcodeproj file in case there a new icons, of course) once everything
is sorted out.
Thanks,
Björn
Ted Pavlic
> this to plist format; both script and output are attached.
Note that there are a couple of entries that do not have the format
listed in the Python script. For example:
-----
Type: Plain text document
Extensions: text, txt, utf8
MIME Types: text/plain
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/txt.icns
-----
I think that entry confused your script. There is another entry:
-----
Type: Document
Icon file at: http://www.tedpavlic.com/examples/mvim/icns/document.icns
-----
which might be important. To handle this last entry, I think you can set:
CFBundleTypeOSTypes to (string)****
and
CFBundleTyepRole to (string)Editor
and
LSItemContenTypes to (string)public.data
> The plist assumes that the icons are in mvim's Resource bundle and
> named doc-bm-<current-name>, perhaps you (Ted) can rename them, zip
> them up, and send them here?
Rather than polluting the list, I've put the archive here:
http://www.tedpavlic.com/examples/mvim/doc-bm-icns/doc-bm-mvim-icns.zip
NOTE: There are several of files that already exist in the current
MacVim resource bundle (for example, doc-bm-java.icns). Also, the
convention used in my icons use a lighter color. Someday (?) they should
probably be converted to the current convention.
How's that?
Nico Weber
> listed in the Python script. For example:
>
> -----
> Type: Plain text document
> Extensions: text, txt, utf8
> MIME Types: text/plain
> Icon file at: http://www.tedpavlic.com/examples/mvim/icns/txt.icns
> -----
Thanks for catching this. As it turns out, this is already in the
current Info.plist, however.
> -----
> Type: Document
> Icon file at: http://www.tedpavlic.com/examples/mvim/icns/
> document.icns
> -----
This is also already in the current Info.plist.
Attached is a patch to Info.plist that merges the Info.plist currently
used and the data sent by Ted. When I had to choose, I generally kept
what was in the Info.plist. I tried to not move around to much stuff
to keep the diff clean.
I didn't add UTIs for Quicklook for the new filetypes, most of the
file types are known by OS X anyways.
What does
<key>LSIsAppleDefaultForType</key>
<false/>
do? It's used by quite a few entries in Info.plist, but I couldn't
find what this is supposed to do (hence, I didn't add it to the new
entries).
I believe there is no danger in merging this now, even when the new
icons are not there yet. We can add Ted's icons (perhaps we can add
symlinks to a generic icon for some of the less popular file type
icons, to not bloat the app size too much), but I'd like to try to
find (or write) a small program that can generate document icons from
an app icon and a string list. Then the document icons could use the
new MacVim icon (and could easily be updated if the MacVim icons
should be updated again).
Nico
Ted Pavlic
> <key>LSIsAppleDefaultForType</key>
> <false/>
> do? It's used by quite a few entries in Info.plist, but I couldn't
> find what this is supposed to do (hence, I didn't add it to the new
> entries).
I Googled and found this link:
http://www.cocoabuilder.com/archive/message/cocoa/2006/6/14/165625
In particular:
=====
You can see that for pdf files, it is true, but for ai (Illustrator
files) it is false. Basically this is a way for Launch Services to
'know' which application should be considered the default default app
for a given type without having to hard-code that info into the
system. AFAIK it is only ever set on Apple's own Apps and should
probably be considered private.
=====
> icons, to not bloat the app size too much), but I'd like to try to
> find (or write) a small program that can generate document icons from
> an app icon and a string list. Then the document icons could use the
I know *nothing* about what *.icns files are internally, but:
a) If they can be converted from PostScript, then the names on the icons
should be text strings within the PostScript. That would be easy to hack.
b) If they can be converted to/from PDF, you could pull them into LaTeX
and then have LaTeX plop an overlay text right on top of them.
So both of those options could be easily automated.
dacresni
putting ALL of them in the app, they really aren't that big because
they're either pdf or png.
Nico Weber
TextEdit and Preview), and icns store pixel data. A 128x128 icns (used
by TextEdit) weighs in at 48 kb (which means 10 of them are half a
megabyte), a 512x512 icns weighs in at about 164kb (Preview document
icons).
Nico
Ted Pavlic
For example, can we use a PDF? If so, it would be easy to automate the
generation (and squeeze down the file size).
--Ted
Ted Pavlic <t...@tedpavlic.com>
David P. Henderson
On 20 Nov 2008, at 16:59, Ted Pavlic wrote:
> Can we use something other than an icns file?
Not certain, but I'd guess not given that icns is the system
expectation. But the icns format does have certain advantages in that
it contains several versions of the icon varying in bit depth and
size and alpha channel masks to allow for transparency.
> For example, can we use a PDF? If so, it would be easy to automate the
> generation (and squeeze down the file size).
There is a command line tool for converting tiffs 2 icns called
tiff2icns.
> Nico Weber wrote:
>>
>> On Nov 20, 2:17 pm, dacresni <vivacar...@gmail.com> wrote:
>>> I seriously suggest just altering the text layer of the icon and
>>> putting ALL of them in the app, they really aren't that big because
>>> they're either pdf or png.
>>
>> Actually, they are usually icns (at least for the apps I just
>> checked:
>> TextEdit and Preview), and icns store pixel data. A 128x128 icns
>> (used
>> by TextEdit) weighs in at 48 kb (which means 10 of them are half a
>> megabyte), a 512x512 icns weighs in at about 164kb (Preview document
>> icons).
Nico, have you used icns browser to examine those icon files. You'll
find that they contain more than just a 512^2 icon or smaller.
Dave
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult." -- C. A. R.
"Tony" Hoare
Nico Weber
> find that they contain more than just a 512^2 icon or smaller.
Yes, I'm aware of that. Preview also displays the several sizes. I'm
currently cooking up a program to create document icons.
Nico
Nico Weber
The script is attached. I tested it with Preview's app icon and
compared it to the document icons bundled with Preview.app. It's close.
To use this, drop the script into the directory containing
vim_gloss.icns and execute it in Terminal. It will create a file
called out.png. It's probably best to use a vim icon that doesn't have
any shadow for this script (Bjorn, do you have a version of the icon
without shadow?). I'm open for all kinds of comments. If there are
none, I'll use this to create icons for all filetypes supported by vim
tomorrow.
Nico
Ted Pavlic
>
> Not certain, but I'd guess not given that icns is the system
> expectation. But the icns format does have certain advantages in that
> it contains several versions of the icon varying in bit depth and
> size and alpha channel masks to allow for transparency.
Wouldn't a vector-based PDF have many of the same advantages built in?
Speaking of that, some icons are smarter than others (e.g., icons that
show PDF thumbnails). There's no way to dynamically create icons (or
simply text overlays) within the Finder, is there? (or would that be
horrible?)
>> For example, can we use a PDF? If so, it would be easy to automate the
>> generation (and squeeze down the file size).
>
> There is a command line tool for converting tiffs 2 icns called
> tiff2icns.
latex -> eps -> tiff -> icns would then be a possible path.
David P. Henderson
On 21 Nov 2008, at 05:11, Ted Pavlic wrote:
> Wouldn't a vector-based PDF have many of the same advantages built in?
>
Quite possibly, I'm just not certain that the OS will display such a
beast correctly.
> Speaking of that, some icons are smarter than others (e.g., icons that
> show PDF thumbnails). There's no way to dynamically create icons (or
> simply text overlays) within the Finder, is there? (or would that be
> horrible?)
AFAIK Finder doesn't handle this. What you want is icon services.
Dave
--
"Criticizing evolutionary theory because Darwin was limited is like
claiming computers don't work because Chuck Babbage didn't foresee
Duke Nukem 3." -- Patrick Coskren
björn
I don't have any other version of the icon at the moment, but I could
get one. However, I strongly prefer file type icons that have the
paper with one corner folded -- is there any way we could take a
generic one of those and use your script to add the file extension on
top? (I really dislike the current file type icons in MacVim.)
As for the increased app bundle size: how do other text editors handle
file type icons? Do they only use small-ish sized icons? Or do they
simply not care about the bloat?
Björn
Nico Weber
> get one. However, I strongly prefer file type icons that have the
> paper with one corner folded -- is there any way we could take a
> generic one of those and use your script to add the file extension on
> top?
you give an example of a file type icon that looks like you want? (app
name, or screenshot, or …) My script uses the system's generic
document icon as background, which is what all document icons in
apple's apps use too (and what MacVim currently uses as well). I don't
understand what you're asking for :-)
> As for the increased app bundle size: how do other text editors handle
> file type icons? Do they only use small-ish sized icons? Or do they
> simply not care about the bloat?
of the app icon, too). Smultron has just one generic document icon,
it's 512x512. TextEdit (does that count as text editor?) uses 128x128.
XCode uses 128x128 icons for most formats (cpp, c, source code files
in general, pretty ugly ones) and 512x512 for some other files
(xcodeproj, some filetypes that I believe are iphone-related).
Nico
björn
>
>> I don't have any other version of the icon at the moment, but I could
>> get one. However, I strongly prefer file type icons that have the
>> paper with one corner folded -- is there any way we could take a
>> generic one of those and use your script to add the file extension on
>> top?
>
> The current ones have the top right corner folded, haven't they? Can
> you give an example of a file type icon that looks like you want? (app
> name, or screenshot, or …) My script uses the system's generic
> document icon as background, which is what all document icons in
> apple's apps use too (and what MacVim currently uses as well). I don't
> understand what you're asking for :-)
Oh, I misunderstood you: I thought you were saying that you'd make
icons using the app's icon and a the file extension on top _without_
the document in the background. What you're doing sounds fine.
What I was asking for was a document with the file extension on top
but without the app icon layered in between the document and the
extension. The app icon in between is what I think looks ugly -- e.g.
the Xcode icons don't have an Xcode picture on the icon for .h files
for example. Of course, adding the MacVim icon on the document icon
makes it obvious which program will open when you double-click that
file so maybe it isn't such a bad idea to include it.
Am I still making no sense? :)
>> As for the increased app bundle size: how do other text editors handle
>> file type icons? Do they only use small-ish sized icons? Or do they
>> simply not care about the bloat?
>
> TextMate is pre-Leopard and hence has only 128x128 icons (that's true
> of the app icon, too). Smultron has just one generic document icon,
> it's 512x512. TextEdit (does that count as text editor?) uses 128x128.
> XCode uses 128x128 icons for most formats (cpp, c, source code files
> in general, pretty ugly ones) and 512x512 for some other files
> (xcodeproj, some filetypes that I believe are iphone-related).
Ok. Well, I think it is nice to use specialized icons for the most
common formats (c/cpp/obj-c, java, javascript, html, xml, python,
perl, ruby, vim, ..., etc.) and a generic one for everything else but
we should probably avoid having one icon for every file extension
there is. I have no idea which are the "most common" formats though.
;-)
Björn
Nico Weber
> but without the app icon layered in between the document and the
> extension. The app icon in between is what I think looks ugly -- e.g.
> the Xcode icons don't have an Xcode picture on the icon for .h files
> for example. Of course, adding the MacVim icon on the document icon
> makes it obvious which program will open when you double-click that
> file so maybe it isn't such a bad idea to include it.
The HIG says "document icons should make it obvious which application
they are associated with.: http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIcons/chapter_15_section_4.html#/
/apple_ref/doc/uid/20000967-TPXREF124 :
I did a quick survey what other apps do:
find /Applications -name '*.icns' -exec ln -s {} \;
After going through this temporary folder, these apps use the "sheet
of paper with app icon" document icon scheme:
Acorn
Cha-Ching
CSSEdit
Cyberduck (only page with icon, no text)
Firefox
Aquamacs (only page with icon, no text)
Camino
Gimp
Inkscape
These don't:
XCode *
* only for some document icons, though
That's an overwhelming vote for including the MacVim icon in the
document icons.
>>> As for the increased app bundle size: how do other text editors
>>> handle
>>> file type icons? Do they only use small-ish sized icons? Or do
>>> they
>>> simply not care about the bloat?
>>
>> TextMate is pre-Leopard and hence has only 128x128 icons (that's true
>> of the app icon, too). Smultron has just one generic document icon,
>> it's 512x512. TextEdit (does that count as text editor?) uses
>> 128x128.
>> XCode uses 128x128 icons for most formats (cpp, c, source code files
>> in general, pretty ugly ones) and 512x512 for some other files
>> (xcodeproj, some filetypes that I believe are iphone-related).
>
> Ok. Well, I think it is nice to use specialized icons for the most
> common formats (c/cpp/obj-c, java, javascript, html, xml, python,
> perl, ruby, vim, ..., etc.) and a generic one for everything else but
> we should probably avoid having one icon for every file extension
> there is. I have no idea which are the "most common" formats though.
> ;-)
Here are some numbers (getting those was more complicated than
expected, the process gave birth to http://amnoid.de/icns/
makeicns.html :-P).
Currently (with the Info.plist patch I sent a few days ago), there are
56 document icons (of which perhaps 5 are obscure enough to warrant
removal).
Icon Composer creates icns files that have 512, 256, 128, 32, and 16
variants. An icns file containing all those versions is about 120kB.
Having those icons for all 56 document types needs about 6.5MB just
for document icons – in my eyes that's a bit much (does anyone but
Bjorn and me care about MacVim.app size?)
The HIG says ( http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIcons/chapter_15_section_8.html
) that there should at least be 512 and 128 variants, with 32 and 16
variants recommended (but since we autogenerate those sizes anyway,
they won't be much better than what OS X would generated from the 128
variant. Then again, the small sizes probably don't need a lot of
space). So we can get rid of the 256x256 version without any argument.
Which effect do which icon sizes have on file sizes? Here are some
measurements:
Icns with 512, 128, 32, 16 (no 256): about 96kB.
Icns with 256, 128, 32, 16 (no 512): about 60kB.
Icns with only 512, 128: about 92kB
Icns with only 128, 32, 16: about 36kB
Even with the last setting, that's still over 2MB of document icons,
so we do need a generic icon.
So, here's a proposed icon distribution:
* Hi-Res (512, 128, 32, 16): For the generic document icon and for the
document icon for vim files. (2 icons)
* Low-Res (128, 32, 16) for: txt, tex, h, c, m, mm, c++, java, html,
xml, javascript, perl, python, php, ruby, css, haskell, ps, erlang,
lisp, scheme, yaml, plist (23 icons)
* Generic icon: fortran, sh, diff, flash, asp, bib, c#, csv, tsv, cgi,
dtd, dylan, fscript, ini, io, prop, log, wiki, sql, tcl, vcard,
vbasic, ics, jsp, log, xsl (26 filetypes)
* Think about removing those filetypes: gtd, bsh, cfdg, cfg, inc
(merge with "h"?) (5 icons)
Yay, that at least sums up to 56 filetypes.
This distribution would require about 120kB * 2 + 23 * 36kB = 1MB for
icons. Is that ok or still too much? Would someone want to move some
filetype into a different group?
Nico
ps: icns uses compression (jpeg2000 for the larger icon variants, and
I think some sort of RLE for the smaller variants), so filesize
depends a bit on how an icon looks. But since all document icons look
similar, I guess the sizes in this mail are a good approximation. I
used the icon visible on the page linked above as reference.
Ben Schmidt
> for document icons – in my eyes that's a bit much (does anyone but
> Bjorn and me care about MacVim.app size?)
I also think keeping the bundle size down is a good idea. I don't think
a few MB hurt, though, say 2-3 MB. I'd say 5 MB or over is probably
getting a bit excessive, though. I have absolutely no basis for those
numbers, they're just kinda how I feel about it.
At any rate, I think bundle size is a good reason to have a generic
icon. But after the bundle size has been considered in the choice to
have a generic icon, which icons to make generic should be dictated by
usage patterns and not be size-driven.
> So, here's a proposed icon distribution:
>
> * Hi-Res (512, 128, 32, 16): For the generic document icon and for the
> document icon for vim files. (2 icons)
>
> * Low-Res (128, 32, 16) for: txt, tex, h, c, m, mm, c++, java, html,
> xml, javascript, perl, python, php, ruby, css, haskell, ps, erlang,
> lisp, scheme, yaml, plist (23 icons)
>
> * Generic icon: fortran, sh, diff, flash, asp, bib, c#, csv, tsv, cgi,
> dtd, dylan, fscript, ini, io, prop, log, wiki, sql, tcl, vcard,
> vbasic, ics, jsp, log, xsl (26 filetypes)
I guess it makes sense for predominantly Microsoft/Windows filetypes to
have generic icons, and 'support' filetypes like xsl, but I would've
thought things like sql, tcl, diff/patch, log, sh, fortran, jsp
warranted real icons. I question whether ps is really a filetype that
deserves one as they are pretty rarely edited as text files. I would've
though plist is borderline, too; the proper editor is surely more
appropriate for those than a text editor?
Cheers,
Ben.
björn
>
>
> I did a quick survey what other apps do:
>
> That's an overwhelming vote for including the MacVim icon in the
> document icons.
Ok, you have convinced me.
> Here are some numbers (getting those was more complicated than
> expected, the process gave birth to http://amnoid.de/icns/
> makeicns.html :-P).
Nice! It seems almost strange that there isn't such an app already.
> So, here's a proposed icon distribution:
>
> * Hi-Res (512, 128, 32, 16): For the generic document icon and for the
> document icon for vim files. (2 icons)
>
> * Low-Res (128, 32, 16) for: txt, tex, h, c, m, mm, c++, java, html,
> xml, javascript, perl, python, php, ruby, css, haskell, ps, erlang,
> lisp, scheme, yaml, plist (23 icons)
Personally, I would like to add diff and patch with one shared icon to
this list (and maybe sh as well, but with its own icon of course).
I think it is ok if 'mm' uses the same icon as 'm', but maybe this is a
bit confusing?
I removed plist on purpose a while back because it should associate with
the Property List Editor app (these files may be binary), so please make
sure it is not in the patched Info.plist.
As Ben also pointed out: do we need an entry for 'ps'? I would think
you'd be more likely to open such files with Preview. (Or does it
mean something other than PostScript?)
> * Generic icon: fortran, sh, diff, flash, asp, bib, c#, csv, tsv, cgi,
> dtd, dylan, fscript, ini, io, prop, log, wiki, sql, tcl, vcard,
> vbasic, ics, jsp, log, xsl (26 filetypes)
I don't know of any reason why we can't add as many filetype
associations as we'd want (with the generic icon) so I'd say anything
goes in this list as long as its not a format that may be binary (like
plist) or that is usually not opened with a text editor (like ps).
> * Think about removing those filetypes: gtd, bsh, cfdg, cfg, inc
> (merge with "h"?) (5 icons)
The only time I've used 'inc' was in connection with assembly
language...where is it supposed to be used? I don't know any of the
others (cfg I guess is some generic config format but I don't know
what or who uses it).
> This distribution would require about 120kB * 2 + 23 * 36kB = 1MB for
> icons. Is that ok or still too much? Would someone want to move some
> filetype into a different group?
Around 1 MB is fine by me.
Thanks for taking the time to sort these things out Nico!
Björn
Ben Schmidt
>> What I was asking for was a document with the file extension on top
>> but without the app icon layered in between the document and the
>> extension. The app icon in between is what I think looks ugly -- e.g.
>> the Xcode icons don't have an Xcode picture on the icon for .h files
>> for example. Of course, adding the MacVim icon on the document icon
>> makes it obvious which program will open when you double-click that
>> file so maybe it isn't such a bad idea to include it.
I like having it there. In fact, I will rarely double click a file
unless it has an icon which clearly indicates to me which app is going
to open it.
Perhaps it would look less ugly if it were faded, i.e. placed there with
transparency so it looks more pale and stands out less? The focus of the
icon can become the extension badge, not the MacVim icon then perhaps.
Ben.
Nico Weber
here's (hopefully) the final patch for this.
>> So, here's a proposed icon distribution:
>>
>> * Hi-Res (512, 128, 32, 16): For the generic document icon and for
>> the
>> document icon for vim files. (2 icons)
>>
>> * Low-Res (128, 32, 16) for: txt, tex, h, c, m, mm, c++, java, html,
>> xml, javascript, perl, python, php, ruby, css, haskell, ps, erlang,
>> lisp, scheme, yaml, plist (23 icons)
>
> Personally, I would like to add diff and patch with one shared icon to
> this list (and maybe sh as well, but with its own icon of course).
As you and Ben suggested, I added diff/patch (shared icon), sql, tcl,
log, sh, fortran, and jsp to the "own icon" list and removed ps and
plist.
> I think it is ok if 'mm' uses the same icon as 'm', but maybe this
> is a
> bit confusing?
I kept mm for now.
> I removed plist on purpose a while back because it should associate
> with
> the Property List Editor app (these files may be binary), so please
> make
> sure it is not in the patched Info.plist.
Done. I have this in my _vimrc for this case:
command PLXml %!plutil -convert xml1 -o - %
But since MacVim doesn't do this automatically, I agree plists do not
belong into the Info.plist.
> The only time I've used 'inc' was in connection with assembly
> language...where is it supposed to be used?
It's used in C++ for template definition files (they need to be
included in .h files but contain implementation code), but it's also
used in pascal, so I kept this separate.
>
The attachment includes both a patch to Info.plist and a python script
that generates all document icons from an application icon. Moving
filetypes from "has own 128 icon" to "has generic icon" or "has own
512 icon" is an easy change with this script. Since all document icons
are > 1.3 MB in total, I think it's better to instead add the python
script to the repo and then create the document icons and move them
into the app in a build stage.
The python script expects to be in a directory with a file called "vim-
noshadow-512.png" and with the makeicns binary ( http://amnoid.de/icns/makeicns.html
– perhaps add the source of this to a subdirectory and build that in
a build stage too?). Invoke it with
python make_icons.py
and it will create lots of doc-bm-*.icns files, overwriting existing
ones. It's easy to add or remove document icons from the script, to
change the text on the document icons, and to change the
"group" (large, big, symlink) of document icons.
Nico
björn
>
> The attachment includes both a patch to Info.plist and a python script
> that generates all document icons from an application icon. Moving
> filetypes from "has own 128 icon" to "has generic icon" or "has own
> 512 icon" is an easy change with this script. Since all document icons
> are > 1.3 MB in total, I think it's better to instead add the python
> script to the repo and then create the document icons and move them
> into the app in a build stage.
>
> The python script expects to be in a directory with a file called "vim-
> noshadow-512.png" and with the makeicns binary ( http://amnoid.de/icns/makeicns.html
> – perhaps add the source of this to a subdirectory and build that in
> a build stage too?). Invoke it with
>
> python make_icons.py
>
> and it will create lots of doc-bm-*.icns files, overwriting existing
> ones. It's easy to add or remove document icons from the script, to
> change the text on the document icons, and to change the
> "group" (large, big, symlink) of document icons.
Thanks Nico. I will look into adding the script+source for the
makeicns program to the repo and then add a custom build phase to the
Xcode project. Hopefully I'll get a chance this weekend.
Björn
Steven Michalske
When i make icons....
choose size version.... Larger icons can have more information,
smaller icons need more distinctive look.
Inkscape -> SVG
scripts to edit SVG properties like text....
export to raster....
mkdir PNGS
for SIZE in 16 32 64 128 256 512
if [ -e FILENAME_$SIZE ]; then
inkscape -C --export-png=PNGS/$FILENAME_$SIZE -w $SIZE -h $SIZE $
(FILENAME)_$SIZE
fi
IconComposer -> icns
most of this is manual with some simple bash scripts to sort folders
to simplify drag and drop
Thanks for pointing out the tiff2icns, how does the alpha channel work?
Steve
Nico Weber
On 24.11.2008, at 16:56, Steven Michalske wrote:
> mkdir PNGS
> for SIZE in 16 32 64 128 256 512
> if [ -e FILENAME_$SIZE ]; then
> inkscape -C --export-png=PNGS/$FILENAME_$SIZE -w $SIZE -h $SIZE $
> (FILENAME)_$SIZE
> fi
>
> IconComposer -> icns
>
> most of this is manual with some simple bash scripts to sort folders
> to simplify drag and drop
>
> Thanks for pointing out the tiff2icns, how does the alpha channel
> work?
tiff2icns does not handle 512x512 icons, and using it is a bit
complicated: You have to put all tiff icons into one file (with
`tiffutil -cat`). Because of that, I have written makeicns ( http://amnoid.de/icns/makeicns.html
), which you can use to convert all your pngs to icns files like this:
makeicns -512 FILENAME_512 -256 FILENAME_256 -128 FILENAME_128
-32 FILENAME_32 -16 FILENAME_16 -out shinyicon.icns
Both makeicns and tiff2icns use the alpha channel of the source images.
HTH,
Nico
Steven Michalske
Steve