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

Re: Cocoa gvim?

Expand Messages
  • Stephen Riehm
    Hi Marvin, ... ouch ouch ouch - it itches - ouch! ;-) That would indeed be a pretty amazing leap forward if it were to work. You re only talking about doing
    Message 1 of 4 , Dec 28, 2006
    • 0 Attachment
      Hi Marvin,

      > For now I've given up, but since I live inside of vim for several
      > hours each day, I imagine that the itch will prove too tempting and
      > eventually I'll have to scratch it. If I do, I figure that rather
      > than debug QuickDraw, the best approach will be to rip everything
      > out and start from scratch with Cocoa.
      >
      > Has anybody gone down this path already? Any drawbacks, besides
      > the standard problems of rewrite bugginess and backwards
      > compatibility? I'm not an experienced Mac developer, but this
      > sounds like a fun project and a good way to learn.

      ouch ouch ouch - it itches - ouch! ;-)
      That would indeed be a pretty amazing leap forward if it were to
      work. You're only talking about doing the GUI though right - not the
      whole back end too I hope!

      I too am a Cocoa-newbie and sadly never seem to have the time to
      scratch my own itches, but I reckon it could be fun to give it a go.

      A couple of things that occur to me:
      NSTextView is almost a kind of emacs editor already - without you
      writing any code at all.
      Things like Visual Highlighting could be interesting if a
      proportional font is selected (would have to filter the available
      fonts maybe)
      You could easily set up a delegate to catch all keystrokes and
      handle the different states
      Not sure how I would go about doing the status bar and ex line at
      the bottom of the visual port
      Character addressing may be fun - since you don't do that in cocoa
      (you give it a block of text and it does all the wrapping and
      formatting)
      What other special gui features would be needed?
      I've never built a cocoa program without using the Interface Builder
      and XCode - not sure about hand-coding everything from scratch -
      apple seems to hide a fair bit of magic from us mere mortals :-(

      Now if I could just live without having to work to pay bills for a
      while... :-}

      Steve
    • Marvin Humphrey
      ... Right. Basically, after familiarizing myself with large pieces of gui_mac.c and the ATSUI API, I started to figure that it might be more efficient to just
      Message 2 of 4 , Dec 28, 2006
      • 0 Attachment
        On Dec 28, 2006, at 3:40 PM, Stephen Riehm wrote:

        > You're only talking about doing the GUI though right - not the
        > whole back end too I hope!

        Right. Basically, after familiarizing myself with large pieces of
        gui_mac.c and the ATSUI API, I started to figure that it might be
        more efficient to just rip out everything QuickDraw and start from
        scratch. I started to find ATSUI nuggets like kATSUQDBoldfaceTag and
        wondered why the QuickDraw function TextFace was being used instead.
        Legacy, I assume, but perhaps TextFace and ATSUDrawText don't play
        nice together. So, as I was gaining confidence that I could pull
        this off, my thought was, why not invest in learning Cocoa instead?

        > NSTextView is almost a kind of emacs editor already - without you
        > writing any code at all.
        > Things like Visual Highlighting could be interesting if a
        > proportional font is selected (would have to filter the available
        > fonts maybe)
        > You could easily set up a delegate to catch all keystrokes and
        > handle the different states
        > Not sure how I would go about doing the status bar and ex line at
        > the bottom of the visual port
        > Character addressing may be fun - since you don't do that in cocoa
        > (you give it a block of text and it does all the wrapping and
        > formatting)
        > What other special gui features would be needed?

        I'm coming at this from a position of almost complete naivete
        regarding Cocoa, so that won't mean a lot to me until I do some
        tutorials. What I do have is a strong understanding of how the final
        product should work, significant experience in graphic design and
        typography, and a persistent itch. Experience tells me that the best
        way to learn new technologies is to start with that kind of a clear
        vision and work work work until it's realized.

        > I've never built a cocoa program without using the Interface
        > Builder and XCode - not sure about hand-coding everything from
        > scratch - apple seems to hide a fair bit of magic from us mere
        > mortals :-(

        Well, then maybe Cocoa isn't the best route after all. The idea is
        to purge all QuickDraw libraries, breaking the app, then rebuild it
        bit by bit using the latest, greatest API from Apple. Buzz has it
        that "new apps should be in Cocoa", and that because Cocoa is higher
        level than Carbon, Cocoa code tends to be less buggy and require less
        maintenance. But we're not contemplating a new app, just glomming a
        new gui onto the front of an existing app. There may be some pieces
        of Vim which are impossible to implement using Cocoa.

        I dunno. Maybe try Cocoa and see if a brick wall shows up?

        Marvin Humphrey
        Rectangular Research
        http://www.rectangular.com/
      • Timothy Knox
        Somewhere on Shadow Earth, at Thu, Dec 28, 2006 at 04:54:03PM -0800, Marvin Humphrey wrote: ... Hard to say. The buzz is that all new apps should be
        Message 3 of 4 , Dec 28, 2006
        • 0 Attachment
          Somewhere on Shadow Earth, at Thu, Dec 28, 2006 at 04:54:03PM -0800, Marvin Humphrey wrote:
          <snip>
          > Well, then maybe Cocoa isn't the best route after all. The idea is
          > to purge all QuickDraw libraries, breaking the app, then rebuild it
          > bit by bit using the latest, greatest API from Apple. Buzz has it
          > that "new apps should be in Cocoa", and that because Cocoa is higher
          > level than Carbon, Cocoa code tends to be less buggy and require less
          > maintenance. But we're not contemplating a new app, just glomming a
          > new gui onto the front of an existing app. There may be some pieces
          > of Vim which are impossible to implement using Cocoa.

          Hard to say. The buzz is that "all new apps should be Cocoa", but one, this
          isn't a new app; and two, Cocoa is all Objective-C based, so you would
          complicate the startup/shutdown processing, because you need to be sure all your
          Objective-C objects are properly constructed/destroyed. It will also complicate
          maintenance, as now maintainers must know both C and Objective-C.

          My thought would be to look at using modern Carbon, particularly, as you noted,
          ATSUI, which is the modern text-rendering engine. You might find this a helpful
          place to start:

          http://developer.apple.com/referencelibrary/TextFonts/idxCarbon-date.html

          Also:

          http://lists.apple.com/mailman/listinfo/carbon-dev

          --
          I have always wished that my computer would be as easy to use as my telephone.
          My wish has come true. I no longer know how to use my telephone.
          -- Bjarne Stroustrup, creator of the C++ programming language
        Your message has been successfully submitted and would be delivered to recipients shortly.