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

GTK+ 2 Vim + sign icons

Expand Messages
  • Daniel Elstner
    Hey, recently I discovered the GTK+ GUI doesn t support the sign icons feature. I think it s a shame if GTK+ Vim doesn t support something that s implemented
    Message 1 of 7 , Mar 2, 2003
      Hey,

      recently I discovered the GTK+ GUI doesn't support the sign icons
      feature. I think it's a shame if GTK+ Vim doesn't support something
      that's implemented even in the ugly Motif GUI. Thus I went ahead and
      added the feature:

      http://regexxer.sourceforge.net/vim/vim-gtk2-20030303.patch.gz

      Thanks to GdkPixbuf, all of the common image file types (png, jpg, bmp,
      xpm and possibly more) are supported automagically. As an additional
      bonus the screen won't get messed up if the sign icon is too large.
      Instead the image is scaled up/down as necessary if it doesn't fit
      (using a threshold to avoid excessive scaling).

      I'm looking forward to see this being used in a future IDE-integrated
      Vim component (hi Jason ;-).

      Have fun,
      --Daniel
    • Jason Hildebrand
      ... ... Cool - I wasn t even aware that vim had this feature, but I had actually thought that something like this would be useful/necessary for
      Message 2 of 7 , Mar 2, 2003
        On Sun, 2003-03-02 at 17:39, Daniel Elstner wrote:
        > recently I discovered the GTK+ GUI doesn't support the sign icons
        > feature. I think it's a shame if GTK+ Vim doesn't support something
        > that's implemented even in the ugly Motif GUI. Thus I went ahead and
        > added the feature:
        <snip>
        > I'm looking forward to see this being used in a future IDE-integrated
        > Vim component (hi Jason ;-).

        Cool - I wasn't even aware that vim had this feature, but I had actually
        thought that something like this would be useful/necessary for
        integrating with IDE's. It'll have to be hooked up some sort of
        bonobo/corba interface, so that the container app can control it easily.

        BTW, I _have_ made some progress on bonobo-izing vim. So far I can
        instantiate a vim control and place it in the window. The vim control
        starts without crashing (this is a great feature, not to be
        underestimated), and merges it's UI (menus, toolbars) into the window.
        I've also written a small container-app for testing purposes.

        I'd post a screenshot, but since you can't see the two processes
        involved it wouldn't really demonstrate what has been achieved -- it
        looks very similar to the GTK2 version. :)

        Right now I'm working on supporting more of the UI features (i.e.
        different toolbar icon sizes), making menu items (in)sensitive, etc.
        Then I'll implement the persist stream and persist file bonobo
        interfaces, which will allow the container to load/save the vim
        control's file.

        Soon I'll update my website and post the code, so that others can play
        with it, too, and fix all the remaining bugs for me. :)

        peace,
        Jason
      • Daniel Elstner
        ... I hope you re going to hook up the whole ex command line stuff as scripting interface anyway ;) ... Indeed. ... But I couldn t resist making a screenshot:
        Message 3 of 7 , Mar 3, 2003
          On Mon, 2003-03-03 at 02:30, Jason Hildebrand wrote:

          > Cool - I wasn't even aware that vim had this feature, but I had actually
          > thought that something like this would be useful/necessary for
          > integrating with IDE's. It'll have to be hooked up some sort of
          > bonobo/corba interface, so that the container app can control it easily.

          I hope you're going to hook up the whole ex command line stuff as
          scripting interface anyway ;)

          > BTW, I _have_ made some progress on bonobo-izing vim. So far I can
          > instantiate a vim control and place it in the window. The vim control
          > starts without crashing (this is a great feature, not to be
          > underestimated),

          Indeed.

          > and merges it's UI (menus, toolbars) into the window.
          > I've also written a small container-app for testing purposes.
          >
          > I'd post a screenshot, but since you can't see the two processes
          > involved it wouldn't really demonstrate what has been achieved -- it
          > looks very similar to the GTK2 version. :)

          But I couldn't resist making a screenshot:

          http://regexxer.sourceforge.net/vim/vim-abuse.png

          Disclaimer: Viewing this image may cause serious injury, or may make
          you lose your faith in god (or Vim, if atheist). You have been warned.

          > Right now I'm working on supporting more of the UI features (i.e.
          > different toolbar icon sizes), making menu items (in)sensitive, etc.
          > Then I'll implement the persist stream and persist file bonobo
          > interfaces, which will allow the container to load/save the vim
          > control's file.

          Rock. So I guess a simple Nautilus component is not too far off?

          > Soon I'll update my website and post the code, so that others can play
          > with it, too, and fix all the remaining bugs for me. :)

          Heh ;)

          Cheers,
          --Daniel
        • Bram Moolenaar
          ... I would actually like to include this in the GTK 1 version as well. Is this possible without using GTK 2 features? If this is possible, can you separate
          Message 4 of 7 , Mar 3, 2003
            Daniel Elstner wrote:

            > recently I discovered the GTK+ GUI doesn't support the sign icons
            > feature. I think it's a shame if GTK+ Vim doesn't support something
            > that's implemented even in the ugly Motif GUI. Thus I went ahead and
            > added the feature:
            >
            > http://regexxer.sourceforge.net/vim/vim-gtk2-20030303.patch.gz
            >
            > Thanks to GdkPixbuf, all of the common image file types (png, jpg, bmp,
            > xpm and possibly more) are supported automagically. As an additional
            > bonus the screen won't get messed up if the sign icon is too large.
            > Instead the image is scaled up/down as necessary if it doesn't fit
            > (using a threshold to avoid excessive scaling).

            I would actually like to include this in the GTK 1 version as well. Is
            this possible without using GTK 2 features? If this is possible, can
            you separate this change from the rest and e-mail it to me?

            > I'm looking forward to see this being used in a future IDE-integrated
            > Vim component (hi Jason ;-).

            I'm working on it. Will work with Motif as well.

            --
            A disclaimer for the disclaimer:
            "and before I get a huge amount of complaints , I have no control over the
            disclaimer at the end of this mail :-)" (Timothy Aldrich)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Daniel Elstner
            ... [...] ... It certainly is possible, but a) I d practically have to do it again from scratch b) the GTK+ 1 version would support only .xpm and no scaling I
            Message 5 of 7 , Mar 3, 2003
              On Mon, 2003-03-03 at 10:27, Bram Moolenaar wrote:
              > Daniel Elstner wrote:
              >
              > > recently I discovered the GTK+ GUI doesn't support the sign icons
              > > feature. I think it's a shame if GTK+ Vim doesn't support something
              > > that's implemented even in the ugly Motif GUI. Thus I went ahead and
              > > added the feature:

              [...]

              > I would actually like to include this in the GTK 1 version as well. Is
              > this possible without using GTK 2 features? If this is possible, can
              > you separate this change from the rest and e-mail it to me?

              It certainly is possible, but

              a) I'd practically have to do it again from scratch
              b) the GTK+ 1 version would support only .xpm and no scaling

              I agree that it's a sensible goal to make all GUIs suport roughly the
              same feature set. But from my point of view the GTK+ 2 GUI replaces the
              GTK+ 1.2 version.

              Well, that's what I think -- if you feel it's really necessary to have
              this in the old GUI too, I'll try to implement it.

              > > I'm looking forward to see this being used in a future IDE-integrated
              > > Vim component (hi Jason ;-).
              >
              > I'm working on it. Will work with Motif as well.

              Oh -- what exactly are you working on?

              Regards,
              --Daniel
            • Jason Hildebrand
              ... I think the most important thing will be to implement a bunch of generic interfaces (i.e. not vim-specific) which any editor can implement, so that the
              Message 6 of 7 , Mar 3, 2003
                On Mon, 2003-03-03 at 03:14, Daniel Elstner wrote:
                > On Mon, 2003-03-03 at 02:30, Jason Hildebrand wrote:
                >
                > > Cool - I wasn't even aware that vim had this feature, but I had actually
                > > thought that something like this would be useful/necessary for
                > > integrating with IDE's. It'll have to be hooked up some sort of
                > > bonobo/corba interface, so that the container app can control it easily.
                >
                > I hope you're going to hook up the whole ex command line stuff as
                > scripting interface anyway ;)

                I think the most important thing will be to implement a bunch of
                "generic" interfaces (i.e. not vim-specific) which any editor can
                implement, so that the application using an embedded editor doesn't have
                to care which one the user has chosen. Of course, we can always offer
                some additional vim-specific interfaces, too (i.e. ex command line).

                > > Right now I'm working on supporting more of the UI features (i.e.
                > > different toolbar icon sizes), making menu items (in)sensitive, etc.
                > > Then I'll implement the persist stream and persist file bonobo
                > > interfaces, which will allow the container to load/save the vim
                > > control's file.
                >
                > Rock. So I guess a simple Nautilus component is not too far off?

                I've never used a component for editing a file within Nautilus; I've
                only used them for viewing. I need to look into this a bit more to see
                how Nautilus does stuff. But if it's possible to edit a file right
                within Nautilus, we should be fairly close.

                My big itch is Evolution, though, and now that the Gnome2 version is
                shaping up, this is very doable.
                --
                Jason D. Hildebrand
                jason@...
              • Daniel Elstner
                ... Been there, done that :P --Daniel
                Message 7 of 7 , Mar 10, 2003
                  On Mon, 2003-03-10 at 22:52, Gordon Prieur wrote:
                  > Bram,
                  >
                  > If nobody does it in the next few months I'll add the sign support
                  > I'll need it for netbeans support on Linux. However, I won't be able
                  > to get to it for 2-3 months (at least) so somebody else is welcome
                  > to do it first :-)

                  Been there, done that :P

                  --Daniel
                Your message has been successfully submitted and would be delivered to recipients shortly.