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

Re: On 16x16 document icons

Expand Messages
  • björn
    ... That s fine with me. ... Unfortunately it doesn t. The function ATSFontActivateFromFileReference() is new to OS X 10.5. Maybe you can somehow not compile
    Message 1 of 20 , Feb 1, 2009
    • 0 Attachment
      2009/2/1 Nico Weber:
      >
      > People seemed to like this version and the colored version best. It's
      > not clear to me how to extend the 16x16 color to larger icon sizes, so
      > the green version will have to do for now.

      That's fine with me.

      >
      > As usual, I hope this doesn't break docicon generation on Tiger. It
      > shouldn't, but you never know.

      Unfortunately it doesn't. The function
      ATSFontActivateFromFileReference() is new to OS X 10.5. Maybe you can
      somehow not compile loadfont.c on 10.4? (Or use the old API, but
      that's kind of silly since the function won't be called anyway.)

      > In my eyes, this patch completes the docicon saga for now (perhaps
      > modulo a few code-cleanup patches), and I will take a look at
      > +balloon_eval next.

      Great!

      Thanks for the patch,
      Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Nico Weber
      ... I misunderstood Damien: he does not want Envy Code R Bold to be in our repository (but he might allow us to add a font he s currently working on, once he s
      Message 2 of 20 , Feb 1, 2009
      • 0 Attachment
        > Unfortunately it doesn't. The function
        > ATSFontActivateFromFileReference() is new to OS X 10.5. Maybe you can
        > somehow not compile loadfont.c on 10.4? (Or use the old API, but
        > that's kind of silly since the function won't be called anyway.)


        I misunderstood Damien: he does not want Envy Code R Bold to be in our
        repository (but he might allow us to add a font he's currently working
        on, once he's done – even more awesome!). In the meantime, the
        attached version of the patch simply assumes that Envy Code R Bold is
        installed (else, it falls back to the old docicons). This means the
        people building MacVim have to download it from http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
        before building.

        This conveniently makes the Tiger-compatibility of loadfont.c a moot
        point for now; I will revisit this once it becomes necessary.

        Nico


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Niklas Lindström
        ... Would it be ok to add something like: ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip if [[ ! -e EnvyCodeR.zip ]]; then curl
        Message 3 of 20 , Feb 1, 2009
        • 0 Attachment
          On Mon, Feb 2, 2009 at 5:14 AM, Nico Weber <nicolasweber@...> wrote:
          > I misunderstood Damien: he does not want Envy Code R Bold to be in our
          > repository (but he might allow us to add a font he's currently working
          > on, once he's done – even more awesome!). In the meantime, the
          > attached version of the patch simply assumes that Envy Code R Bold is
          > installed (else, it falls back to the old docicons). This means the
          > people building MacVim have to download it from http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
          > before building.

          Would it be ok to add something like:

          ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip
          if [[ ! -e 'EnvyCodeR.zip' ]]; then
          curl $ENVYCODE_URL -o EnvyCodeR.zip
          unzip EnvyCodeR.zip
          fi

          to the build process?

          (Thanks for the great work btw!)

          Best regards,
          Niklas

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Nico Weber
          ... That s a great idea. I asked, and it s ok. Hooray. The attached patch grabs the font file through curl and then loads the font from the ttf file. I tried
          Message 4 of 20 , Feb 2, 2009
          • 0 Attachment
            > Would it be ok to add something like:
            >
            > ENVYCODE_URL=http://download.damieng.com/fonts/original/EnvyCodeR-PR7.zip
            > if [[ ! -e 'EnvyCodeR.zip' ]]; then
            > curl $ENVYCODE_URL -o EnvyCodeR.zip
            > unzip EnvyCodeR.zip
            > fi
            >
            > to the build process?

            That's a great idea. I asked, and it's ok. Hooray.

            The attached patch grabs the font file through curl and then loads the
            font from the ttf file. I tried to fix the tiger build problems too; I
            hope that worked out.

            Nico


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Nico Weber
            ... This patch has now been merged. I pulled the latest version from the repo today on a machine that had both python 2.4 and 2.5 installed, and for some
            Message 5 of 20 , Feb 5, 2009
            • 0 Attachment
              > The attached patch grabs the font file through curl and then loads the
              > font from the ttf file. I tried to fix the tiger build problems too; I
              > hope that worked out.

              This patch has now been merged.

              I pulled the latest version from the repo today on a machine that had
              both python 2.4 and 2.5 installed, and for some reason the loadfont
              module was compiled with 2.4 but the script executed with 2.5, which
              resulted in a crash.

              The attached patch makes compilation of the loadfont module more
              portable. I first added a few additional parameters to the gcc
              invocation in the makefile, but that will probably cause other
              problems in the future. Instead, the patch now uses python's
              distutils, which is the recommended way to build C extensions for
              python. With this patch, the crash went away and the icons were
              generated correctly.

              Nico


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... Thanks Nico, I ve merged this patch. I did notice one _very_ minor thing: if you type make twice in a row, then the second (and any consequtive calls to)
              Message 6 of 20 , Feb 6, 2009
              • 0 Attachment
                2009/2/6 Nico Weber:
                >> The attached patch grabs the font file through curl and then loads the
                >> font from the ttf file. I tried to fix the tiger build problems too; I
                >> hope that worked out.
                >
                > This patch has now been merged.
                >
                > I pulled the latest version from the repo today on a machine that had
                > both python 2.4 and 2.5 installed, and for some reason the loadfont
                > module was compiled with 2.4 but the script executed with 2.5, which
                > resulted in a crash.
                >
                > The attached patch makes compilation of the loadfont module more
                > portable. I first added a few additional parameters to the gcc
                > invocation in the makefile, but that will probably cause other
                > problems in the future. Instead, the patch now uses python's
                > distutils, which is the recommended way to build C extensions for
                > python. With this patch, the crash went away and the icons were
                > generated correctly.

                Thanks Nico, I've merged this patch. I did notice one _very_ minor
                thing: if you type make twice in a row, then the second (and any
                consequtive calls to) "make" will unpack the font zip file again. Any
                idea why this is?

                Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Nico Weber
                ... No idea. (couple minutes pass) This is because `unzip` uses the file modification date from the zip file, see: $ ls -l Envy* -rw-r--r-- 1 thakis eng
                Message 7 of 20 , Feb 6, 2009
                • 0 Attachment
                  > Thanks Nico, I've merged this patch.  I did notice one _very_ minor
                  > thing: if you type make twice in a row, then the second (and any
                  > consequtive calls to) "make" will unpack the font zip file again.  Any
                  > idea why this is?

                  No idea. (couple minutes pass) This is because `unzip` uses the file
                  modification date from the zip file, see:

                  $ ls -l Envy*
                  -rw-r--r-- 1 thakis eng 83856 May 26 2008 Envy Code R Bold.ttf
                  -rw-r--r-- 1 thakis eng 172849 Feb 5 10:30 EnvyCodeR.zip

                  Hence, make thinks the zip file is newer than the ttf file and unpacks
                  it again. I can't find a flag that tells unzip to set the extraction
                  date on the files it creates, but the patch of this mail works around
                  the problem.

                  Nico

                  ps: Not a real patch; group's web interface doesn't support
                  attachments:

                  --- a/src/MacVim/icons/Makefile
                  +++ b/src/MacVim/icons/Makefile
                  @@ -11,6 +11,9 @@ loadfont.so: loadfont.c

                  Envy\ Code\ R\ Bold.ttf: EnvyCodeR.zip
                  unzip -jo EnvyCodeR.zip
                  + # unzip uses the file date from the zip file. Change the file
                  date to
                  + # "now", so that the zip is not unzipped in every `make` run.`
                  + touch Envy\ Code\ R\ Bold.ttf

                  ENVYCODE_URL=http://download.damieng.com/latest/EnvyCodeR
                  EnvyCodeR.zip:


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... Thanks, I have merged and pushed the patch. Björn --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_mac
                  Message 8 of 20 , Feb 6, 2009
                  • 0 Attachment
                    2009/2/6 Nico Weber:
                    >
                    >> Thanks Nico, I've merged this patch. I did notice one _very_ minor
                    >> thing: if you type make twice in a row, then the second (and any
                    >> consequtive calls to) "make" will unpack the font zip file again. Any
                    >> idea why this is?
                    >
                    > No idea. (couple minutes pass) This is because `unzip` uses the file
                    > modification date from the zip file, see:

                    Thanks, I have merged and pushed the patch.

                    Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Tobia Conforto
                    Sorry for the late reply I think the green, bold icons (Option 3. in the OP) look awesome. I d rather have all icons green, as a hint that the file will be
                    Message 9 of 20 , Feb 12, 2009
                    • 0 Attachment
                      Sorry for the late reply

                      I think the green, bold icons (Option 3. in the OP) look awesome. I'd
                      rather have all icons green, as a hint that the file will be opened
                      with MacVim.

                      A suggestion: I don't know if it's feasible with the API you're using,
                      but I would shift the text 0.5 pixels to the left (or maybe 0.333 or
                      0.667 pixels) I think it would make it more readable and better
                      centered, especially for 3 char extensions.

                      All in all, a very good job!

                      Tobia

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Nico Weber
                      Hi Tobia, ... this is now in snapshot 43 :-) ... I agree, but I couldn t get this to work with Cocoa. I tried passing fractional coordinates to -[NSString
                      Message 10 of 20 , Feb 22, 2009
                      • 0 Attachment
                        Hi Tobia,

                        > I think the green, bold icons (Option 3. in the OP) look awesome.  I'd  
                        > rather have all icons green, as a hint that the file will be opened  
                        > with MacVim.

                        this is now in snapshot 43 :-)

                        > A suggestion: I don't know if it's feasible with the API you're using,  
                        > but I would shift the text 0.5 pixels to the left (or maybe 0.333 or  
                        > 0.667 pixels)  I think it would make it more readable and better  
                        > centered, especially for 3 char extensions.

                        I agree, but I couldn't get this to work with Cocoa. I tried passing
                        fractional coordinates to -[NSString drawAtPoint:withAttributes:]
                        directly, and I also tried using a fractional translational
                        NSAffineTransform. It seems that Cocoa truncates the coordinate before
                        drawing the text.

                        Nico
                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Tobia Conforto
                        ... That s a shame. What about putting some fractional space before the text and shifting the coordinates to the left? Unicode has several space characters,
                        Message 11 of 20 , Feb 23, 2009
                        • 0 Attachment
                          Nico Weber wrote:
                          > I agree, but I couldn't get this to work with Cocoa. I tried passing
                          > fractional coordinates to -[NSString drawAtPoint:withAttributes:]
                          > directly, and I also tried using a fractional translational
                          > NSAffineTransform. It seems that Cocoa truncates the coordinate
                          > before drawing the text.

                          That's a shame. What about putting some fractional space before the
                          text and shifting the coordinates to the left? Unicode has several
                          space characters, some of which are quite tiny:

                          U+0020 space
                          U+2002 en space
                          U+2003 em space
                          U+2004 three-per-em space
                          U+2005 four-per-em space
                          U+2006 six-per-em space
                          U+2007 figure space
                          U+2008 punctuation space
                          U+2009 thin space
                          U+200A hair space

                          -Tobia

                          --~--~---------~--~----~------------~-------~--~----~
                          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.