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

Re: A few questions about remove deprecated function calls

Expand Messages
  • Panos Laganakos
    Anything that will make the Vim experience on Mac is welcome. Thanks for your work. ... -- Panos Laganakos
    Message 1 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 2 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 3 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 4 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 5 of 10 , Apr 4, 2007
            • 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 6 of 10 , Apr 4, 2007
              • 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 7 of 10 , Apr 4, 2007
                • 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 8 of 10 , Apr 5, 2007
                  • 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.