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

Re: MacVim plugin patch

Expand Messages
  • björn
    ... Hmmm...somehow it seems unnecessary to wrap Cocoa functionality in the mediator object , but you ll have to decide when and where it is suitable. In this
    Message 1 of 34 , Apr 1 12:36 PM
    • 0 Attachment
      On 01/04/2008, Matt Tolton <matt@...> wrote:
      >
      > > > > - Possibility of having plug-ins in floating panels? Plug-ins in drawers?
      > > >
      > > > I think that these are the best way to present plugins. I think that
      > > > plugins should be allowed to create floating panels as well as new
      > > > windows (I'm not sure we actually have to do anything special to allow
      > > > this) and to add drawers to vim windows.
      > >
      > > No, you wouldn't have to do anything special at all. A plug-in could
      > > create any number of windows/panels and it can access all visible
      > > windows via NSApp.
      >
      >
      > I was thinking that the object we handed the plugin would have some
      > kind of addDrawer method. Are you saying we should just give the
      > plugin a reference to the window and let them add a drawer on their
      > own? Or should we help facilitate this somehow?

      Hmmm...somehow it seems unnecessary to wrap Cocoa functionality in the
      "mediator object", but you'll have to decide when and where it is
      suitable. In this case, maybe you'll want an addDrawer method on your
      mediator object since several plug-ins may want to add drawers and
      you'll want to react in some way when this happens. Of course, you
      could also leave it up to the plug-in to check that no drawer is
      already visible before it tries to add one...I'm not sure which is
      best. (I think I would make the interface of the mediator as simple
      as possible to begin with and revise later on.)

      However, to minimize dependency on "core MacVim" I don't think a
      plug-in should ever be allowed to call any method on an object whose
      name begins with MM. Such things should be handled by the mediator.


      > > > > - Plug-in persistence: automatically save/load plug-in layout? Save plug-in
      > > > > layout in "workspace" files?
      > > >
      > > > Hmm...it doesn't seem like this is really necessary... do you have a
      > > > use case in mind for this?
      > >
      > > Well, if you load a plug-in and then quit MacVim should that plug-in
      > > automatically load when you restart? E.g. a plug-in that lives in a
      > > drawer...should it open that drawer when you restart or do you have to
      > > go through the process of loading that plug-in manually each time you
      > > restart MacVim?
      > >
      > > What if you want a "drawer plug-in" loaded for one window and no others?
      >
      >
      > Ok I see what you're saying. I don't think that this is necessary.
      > If a plugin wants to save some state, I think it should do it on its
      > own.

      Ok. (Maybe something to think more about once we have some actual plug-ins.)


      > > > - Every time we create a new instance of MMVimController, we
      > > > instantiate an object of the bundle's principal class. When we
      > > > initialize this object, we give it some object that it can interact
      > > > with (that is specific to that MMVimController) which will allow it to
      > > > do things such as add a drawer to the vim window, send input to vim,
      > > > subscribe to notifications for that particular vim instance (like when
      > > > a new tab is selected).
      > >
      > > It seems to me that some plug-ins might only want their principal
      > > class to be instantiated once...I have no concrete example, but it
      > > seems natural to have a separation between plug-ins that are
      > > instantiated once and those that are instantiated each time a new Vim
      > > process connects.
      >
      >
      > I was basically thinking the informal principal class protocol would
      > include something like this:
      >
      > + (BOOL) initializePluginWithController:(MMPluginController*)controller;
      > + (void) terminatePlugin;
      > - (id) initWithInstanceController:(MMPluginInstanceController*)controller;
      >
      > If a plugin is "application scoped", then it just will not implement
      > the initWithInstanceController selector and we won't instantiate one
      > for each instance. The plugin can then do all of its initialization
      > stuff in the initializePluginWithController method.
      >
      > Does this seem ok?

      Yes, that makes sense. Reading that I got confused by your choice of
      names; is MMPluginController the "mediator object" (in my
      terminology)? If so I think it should be called something with
      "mediator" or something similar in it since a controller usually is
      something else. (The book "Design Patterns" by Gamma et al. may have
      a better term than "mediator" for it.)


      > > Notifications should be easy enough using Cocoa's notification system.
      > >
      >
      >
      > What notifications do you think are necessary? All that I can think
      > of are things like "tab changed" and "tab closed" notifications.
      > However, this may not be necessary...see below.

      Again, this requires no code on your behalf I think. If a plug-in
      wants to become an observer it simply has to use the
      NSNotificationCenter class, which should be considered public even to
      plug-ins.


      > > > Some questions I have:
      > > > - How do you think we should handle plugins adding menu items? Right
      > > > now it seems like all of the menus are controlled entirely by vim. Do
      > > > we want to add a single menu that plugins are allowed to add menu
      > > > items to? Do we want to allow them to create entire menus of their
      > > > own?
      > >
      > > This is simply not possible at the moment. One of the first thing I
      > > will work on when I get my new Mac is to clean up the menu system. My
      > > intentions are to allow menu items to be added from within MacVim
      > > without involving Vim, thus plug-ins could add menu items easily. A
      > > separate plug-in menu may not be too bad either. Either way, you can
      > > hack something together temporarily, or you can wait for me to fix
      > > this (which won't happen for another month).
      >
      >
      > Yeah...I was looking at the code that handles this. It shouldn't be
      > -too- bad to tweak it a little bit to allow for a plugin menu.

      Go for it. Try not to waste too much time on it though, since the
      menu code will be scrapped.


      > > > - Do we want to provide a way to communicate with a specific plugin
      > > > from within vim?
      > >
      > > No. Vim should not be aware of any MacVim plug-in stuff.
      >
      >
      > The scenario that I was thinking about was a plugin that would like to
      > be notified of certain vim events. It could set up an autocmd in that
      > vim instance to send a message to itself when something occurred (like
      > a tab was closed, or changed, or a new buffer was created, etc)

      Maybe it would be a better idea to investigate how hard it would be to
      put hooks inside the Vim code which forwards Vim events to MacVim and
      then you can use notifications inside MacVim to enable plug-ins to
      listen to these (or simply pass the events to the plug-ins). This
      requires a bit of extra glue-code, but I've been forced to do similar
      things already so it's not too bad (and it might come in handy for
      "core MacVim" as well).

      I still maintain that Vim should remain completely ignorant of plug-in
      stuff, otherwise you'll break the tenet that MacVim (and Vim) should
      not depend on plug-in code in any way.


      /Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Stefan Eletzhofer
      Hi, ... Ok, fine with me. ... Sure. I meant that we should provide some sort of very basic example plugin, which cocoa-dumb people like me can use as template
      Message 34 of 34 , Apr 3 2:41 AM
      • 0 Attachment
        Hi,


        Am 02.04.2008 um 19:58 schrieb "Matt Tolton" <matt@...>:

        >
        >>
        >> Once I'm home again I'll sit down and think and code that -- if
        >> there's a git repo I can clone from. And some example plugin, perhaps
        >> one which just does an alert box (hint hint).
        >
        > I'll put this up in a git repo at some point. As of now I am just
        > working in a local branch. If you want I can send out a patch that
        > you can apply against the main repo.
        >

        Ok, fine with me.

        > As for a plugin which shows an alert box...I don't think we need to
        > provide this functionality (showing alert boxes) as you can just
        > directly use an NSAlert can't you?
        >

        Sure. I meant that we should provide some sort of very basic example
        plugin, which cocoa-dumb people like me can use as template :)

        Stefan

        > Matt
        >
        > >

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