Loading ...
Sorry, an error occurred while loading the content.
 

Re: Document Icons

Expand Messages
  • Nico Weber
    Hi, ... 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.
    Message 1 of 20 , Nov 30, 2008
      Hi,

      > 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


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tobia Conforto
      ... 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
      Message 2 of 20 , Dec 1, 2008
        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.

        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:


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Andrew Long
        ... ... 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
        Message 3 of 20 , Dec 1, 2008
          On 1 Dec 2008, at 11:07, Tobia Conforto wrote:

          > 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


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tobia Conforto
          ... 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
          Message 4 of 20 , Dec 1, 2008
            Andrew Long wrote:
            >> 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
            >
            > 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

            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

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Nico Weber
            ... I agree XCode s 16x16 icons are nice. The main reason why I didn t try to go with 16x16 icons similar to them is that I couldn t come up with a way to
            Message 5 of 20 , Dec 1, 2008
              > > 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.

              I agree XCode's 16x16 icons are nice. The main reason why I didn't try
              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.

              It's not just the "Preview paradigm": Lots of other apps do this, too.
              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:

              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").

              Nico
              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... I like the newer 32x32 icons too...I find it easy to read the VIM written on them. ... I can t think of any way to deal with the 16x16 icons in a
              Message 6 of 20 , Dec 2, 2008
                2008/12/1 Nico Weber <nicolasweber@...>:
                >
                > 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

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Nico Weber
                ... Sounds good. Let s get the original, blurry version merged first. After that, I ll prepare a patch for the nice 32x32 version, and when that is merged,
                Message 7 of 20 , Dec 2, 2008
                  > 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?

                  Sounds good. Let's get the original, blurry version merged first.
                  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
                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • 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.
                  Message 8 of 20 , Dec 12, 2008
                    2008/12/2 Nico Weber <nicolasweber@...>:
                    >
                    >> 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?
                    >
                    > Sounds good. Let's get the original, blurry version merged first.
                    > 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,

                    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

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Nico Weber
                    ... Snap, Tiger doesn t support pyobjc. ... I don t think this is a good idea: Every time we change the generation script, the repo grows a few MB. And every
                    Message 9 of 20 , Dec 12, 2008
                      > I've been trying to get the icon making stuff to work on Tiger and it
                      > is not entirely unproblematic.

                      > 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?

                      Snap, Tiger doesn't support pyobjc.

                      > 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. 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
                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • björn
                      ... Yeah, I d like to avoid this too. ... If there is nothing that you can use instead of pyobjc then I guess this is an ok compromise (anybody using Tiger who
                      Message 10 of 20 , Dec 13, 2008
                        2008/12/13 Nico Weber <nicolasweber@...>:
                        >
                        >> 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

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Ben Schmidt
                        ... 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?
                        Message 11 of 20 , Dec 13, 2008
                          >> 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).

                          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.




                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Steven Michalske
                          ... 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
                          Message 12 of 20 , Dec 13, 2008
                            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.

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Nico Weber
                            ... The appended version uses the generic document icon on Tiger. Nico --~--~---------~--~----~------------~-------~--~----~ You received this message from the
                            Message 13 of 20 , Dec 14, 2008
                              >>> 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).
                              >
                              > 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


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Nico Weber
                              ... Since they are included with MacVim anyways, that doesn t seem necessary and means more work for you. Nico
                              Message 14 of 20 , Dec 14, 2008
                                >> 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.

                                Since they are included with MacVim anyways, that doesn't seem
                                necessary and means more work for you.

                                Nico

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • björn
                                ... 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
                                Message 15 of 20 , Dec 15, 2008
                                  2008/12/15 Nico Weber <nicolasweber@...>:
                                  >
                                  > 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

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Nico Weber
                                  ... 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
                                  Message 16 of 20 , Dec 15, 2008
                                    > 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.

                                    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

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • björn
                                    ... Duh! Of course...why didn t I think of that? Thanks, Björn --~--~---------~--~----~------------~-------~--~----~ You received this message from the
                                    Message 17 of 20 , Dec 15, 2008
                                      2008/12/16 Nico Weber <nicolasweber@...>:
                                      >
                                      >> 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.
                                      >
                                      > 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.

                                      Duh! Of course...why didn't I think of that?

                                      Thanks,
                                      Björn

                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_mac" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    Your message has been successfully submitted and would be delivered to recipients shortly.