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

A few questions about remove deprecated function calls

Expand Messages
  • Jjgod Jiang
    Hi, I would like to make some patches to eliminate deprecated function calls as many as possible, here are a few points: 1. replace all Font Manager APIs with
    Message 1 of 10 , Mar 10, 2007
    • 0 Attachment
      Hi,

      I would like to make some patches to eliminate deprecated function calls
      as many as possible, here are a few points:

      1. replace all Font Manager APIs with Apple Type Service APIs, it could
      be done quite safely.

      2. Completely eliminate the usage of FSSpec, use FSRef instead, since
      vim 7 only supports Mac OS X. According to File Manager Reference:

      A number of deprecated functions in the File Manager were inherited from
      earlier versions of Mac OS and have been carried along to
      facilitate porting
      legacy applications to Mac OS X. You should avoid using these deprecated
      functions. In particular, you should avoid any function or data
      structure that
      uses the FSSpec data type

      This change may require us to remove Code Warrior Editor support, do
      you guys think it's acceptable, or is this piece of code still maintaining
      by some one else?

      3. replace all QuickDraw APIs with Quartz/Core Graphics equivalence.
      This change may not be that easy, I think we need to create a new branch
      for this if we really going to do so.

      Any comments?

      - jjgod.
    • Nicolas Weber
      Hi, I m all for that. I also think the codewarrior support could be removed. You can also take a look at http://macvim.org/OSX/files/patches/ eventpatch.diff
      Message 2 of 10 , Mar 10, 2007
      • 0 Attachment
        Hi,

        I'm all for that. I also think the codewarrior support could be removed.

        You can also take a look at http://macvim.org/OSX/files/patches/
        eventpatch.diff (the 'next weeks' are longer than expected :-P).

        Bye,
        Nico
      • Panos Laganakos
        Anything that will make the Vim experience on Mac is welcome. Thanks for your work. ... -- Panos Laganakos
        Message 3 of 10 , Mar 10, 2007
        • 0 Attachment
          Anything that will make the Vim experience on Mac is welcome.

          Thanks for your work.

          On 3/10/07, Nicolas Weber <nicolasweber@...> wrote:
          > Hi,
          >
          > I'm all for that. I also think the codewarrior support could be removed.
          >
          > You can also take a look at http://macvim.org/OSX/files/patches/
          > eventpatch.diff (the 'next weeks' are longer than expected :-P).
          >
          > Bye,
          > Nico
          >


          --
          Panos Laganakos
        • Rainer Schmid
          Hi, ... A couple of months ago I tired to use gvim as the editor for Xcode and it somewhat worked -- opening files and jumping to a certain line (e.g. when
          Message 4 of 10 , Mar 19, 2007
          • 0 Attachment
            Hi,

            > [...]
            > This change may require us to remove Code Warrior Editor support, do
            > you guys think it's acceptable, or is this piece of code still maintaining
            > by some one else?

            A couple of months ago I tired to use gvim as the editor for Xcode and
            it somewhat worked -- opening files and jumping to a certain line
            (e.g. when clicking on an error a warning in Xcode) worked; however,
            checking for modified files (and some other stuff, as far as I recall)
            didn't work.

            I took a quick look at it, and I believe that the Code Warrior support
            is used for this functionality. And the reason that it didn't work for
            some cases was due to the wrong usage of FSSpec, as I recall.
            Unfortunately, I didn't get around to do a complete patch.

            But maybe it is worth keeping and fixing that code?

            I don't care about Code Warrior support, but it would be nice if gvim
            could be used as an editor for Xcode.

            Rainer
          • Benji Fisher
            ... I am not sure what earlier versions means. Please make sure that vim still compiles on OS X 10.2. I think we have officially dropped support for
            Message 5 of 10 , Mar 30, 2007
            • 0 Attachment
              On Sun, Mar 11, 2007 at 01:03:07AM +0800, Jjgod Jiang wrote:
              > Hi,
              >
              > I would like to make some patches to eliminate deprecated function calls
              > as many as possible, here are a few points:
              >
              > 1. replace all Font Manager APIs with Apple Type Service APIs, it could
              > be done quite safely.
              >
              > 2. Completely eliminate the usage of FSSpec, use FSRef instead, since
              > vim 7 only supports Mac OS X. According to File Manager Reference:
              >
              > A number of deprecated functions in the File Manager were inherited from
              > earlier versions of Mac OS and have been carried along to
              > facilitate porting
              > legacy applications to Mac OS X. You should avoid using these deprecated
              > functions. In particular, you should avoid any function or data
              > structure that
              > uses the FSSpec data type
              >
              > This change may require us to remove Code Warrior Editor support, do
              > you guys think it's acceptable, or is this piece of code still maintaining
              > by some one else?
              >
              > 3. replace all QuickDraw APIs with Quartz/Core Graphics equivalence.
              > This change may not be that easy, I think we need to create a new branch
              > for this if we really going to do so.
              >
              > Any comments?
              >
              > - jjgod.

              I am not sure what "earlier versions" means. Please make sure that
              vim still compiles on OS X 10.2. I think we have officially dropped
              support for versions earlier than that.

              If you can maintain patches, rather than a separate development
              branch, to experiment with Quartz/Core Graphics, I will continue to
              compile experimental versions so that they can be widely tested.

              HTH --Benji Fisher
            • Nicolas Weber
              ... earlier means pre-OS X. I think 10.2 is a reasonable target for Vim. Perhaps even 10.3 in a year or so. ... I think it s not completely unreasonable to
              Message 6 of 10 , Mar 30, 2007
              • 0 Attachment
                >>
                >> A number of deprecated functions in the File Manager were
                >> inherited from
                >> earlier versions of Mac OS and have been carried along to
                >> facilitate porting
                >> legacy applications to Mac OS X.

                > I am not sure what "earlier versions" means. Please make sure
                > that
                > vim still compiles on OS X 10.2. I think we have officially dropped
                > support for versions earlier than that.

                "earlier" means pre-OS X. I think 10.2 is a reasonable target for
                Vim. Perhaps even 10.3 in a year or so.

                > If you can maintain patches, rather than a separate development
                > branch, to experiment with Quartz/Core Graphics, I will continue to
                > compile experimental versions so that they can be widely tested.

                I think it's not completely unreasonable to set up a repository for
                gui_mac.c for larger patch sets...I have a local repo for that, but a
                shared repo would be helpful imho (perhaps a git repo...seems more
                appropriate).

                Bye,
                Nico
              • Jjgod Jiang
                Hi all, ... I just started to review and merge this patch. To summarize, I hope to do the following code cleanup/improvement: FSSpec - FSRef Control Manager
                Message 7 of 10 , Apr 4 10:46 AM
                • 0 Attachment
                  Hi all,

                  2007/3/11, Nicolas Weber <nicolasweber@...>:
                  > Hi,
                  >
                  > I'm all for that. I also think the codewarrior support could be removed.
                  >
                  > You can also take a look at http://macvim.org/OSX/files/patches/
                  > eventpatch.diff (the 'next weeks' are longer than expected :-P).

                  I just started to review and merge this patch.

                  To summarize, I hope to do the following code cleanup/improvement:

                  FSSpec -> FSRef
                  Control Manager -> Human Interface Toolbox
                  QuickDraw -> Quartz
                  ControlRef -> HIViewRef
                  Str255 -> CFString

                  (also listed in http://www.carbondev.com/site/?page=Carbon+Orientation)

                  But the last one may need multibyte to be compiled in so that
                  mac_enc_to_cfstring
                  can be used. For example, When removing deprecated Menu creation code
                  (NewMenu, SetMenuItemText), FEAT_MBYTE should be needed to do menu
                  name conversion. Do you guys think it's acceptable?

                  - jjgod
                • Nicolas Weber
                  Hi, ... I ve attached a document I wrote a few weeks ago that might be helpful. Probably it s not, though :-P What do you think about doing your changes in a
                  Message 8 of 10 , Apr 4 11:27 AM
                  • 0 Attachment
                    Hi,

                    > I just started to review and merge this patch.
                    >
                    > To summarize, I hope to do the following code cleanup/improvement:
                    >
                    > FSSpec -> FSRef
                    > Control Manager -> Human Interface Toolbox
                    > QuickDraw -> Quartz
                    > ControlRef -> HIViewRef
                    > Str255 -> CFString

                    I've attached a document I wrote a few weeks ago that might be
                    helpful. Probably it's not, though :-P

                    What do you think about doing your changes in a public repository?
                    (this repo needs only to contain a few files, mainly gui_mac.c and
                    some supporting stuff)

                    > But the last one may need multibyte to be compiled in so that
                    > mac_enc_to_cfstring
                    > can be used. For example, When removing deprecated Menu creation code
                    > (NewMenu, SetMenuItemText), FEAT_MBYTE should be needed to do menu
                    > name conversion. Do you guys think it's acceptable?

                    I have no problems with this, especially since this is only a
                    requirement for the gui version (which doesn't work correctly without
                    multibyte anyways). But in the end Bram has to decide this I guess.

                    Bye,
                    Nico
                  • Jjgod Jiang
                    ... It s very helpful, I think you should add this to the wiki :) My current approach is create an empty gui_mac.c and add to it piece by piece, and try to
                    Message 9 of 10 , Apr 4 7:33 PM
                    • 0 Attachment
                      2007/4/5, Nicolas Weber <nicolasweber@...>:
                      > Hi,
                      >
                      > I've attached a document I wrote a few weeks ago that might be
                      > helpful. Probably it's not, though :-P
                      >

                      It's very helpful, I think you should add this to the wiki :) My current
                      approach is create an empty gui_mac.c and add to it piece by
                      piece, and try to keep the code in a more organized and easier
                      to maintained way. After I finished one experiment and know which
                      code I could change/remove safely, I'll start to make patch on
                      the main repository.

                      Many APIs are interrelated, it makes changing the code directly
                      on main repository very difficult (to avoid broke things).

                      - jjgod
                    • Nicolas Weber
                      Hi, ... Yes, that was why I asked for markdown support. Panos is working on it, but it turns out to be more difficult than expected. I ll post it (and some
                      Message 10 of 10 , Apr 5 1:06 AM
                      • 0 Attachment
                        Hi,

                        > 2007/4/5, Nicolas Weber <nicolasweber@...>:
                        >> Hi,
                        >>
                        >> I've attached a document I wrote a few weeks ago that might be
                        >> helpful. Probably it's not, though :-P
                        >>
                        >
                        > It's very helpful, I think you should add this to the wiki :)

                        Yes, that was why I asked for markdown support. Panos is working on
                        it, but it turns out to be more difficult than expected. I'll post it
                        (and some other stuff, for example how the main loop hack in the
                        events patch works) when markdown support works.

                        > My current approach is create an empty gui_mac.c and add to it
                        > piece by
                        > piece, and try to keep the code in a more organized and easier
                        > to maintained way. After I finished one experiment and know which
                        > code I could change/remove safely, I'll start to make patch on
                        > the main repository.
                        >
                        > Many APIs are interrelated, it makes changing the code directly
                        > on main repository very difficult (to avoid broke things).

                        Perhaps you could post some notes about your progress to the wiki as
                        well (problems you hand and how you solved them; regressions you
                        noticed, ...) :-)

                        Bye,
                        Nico
                      Your message has been successfully submitted and would be delivered to recipients shortly.