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

Re: A few questions about remove deprecated function calls

Expand Messages
  • 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 1 of 10 , Apr 4, 2007
      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 2 of 10 , Apr 4, 2007
        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 3 of 10 , Apr 4, 2007
          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 4 of 10 , Apr 5, 2007
            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.