My favorites | Sign in
Project Home Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 26: Icons don't fit with OS X. (Patch included)
5 people starred this issue and may be notified of changes. Back to list
Status:  Started
Owner:  ----

Sign in to add a comment
Reported by, Nov 1, 2007
The icons don't quite fit with the graphic style of OS X. I've replaced
them with freely available / redistributable and GPL2'd alternatives, which
hopefully lends a more cohesive appearance to the application.

I think MacVim should reexamine what it places in the toolbar, and consider
breaking parity with the Linux/Windows variants. OS X tends to use its
toolbars to deal *only* with a given window's document, not to interact
with the application itself.

For instance, Smultron is the only other application I have installed with
an "Open" button in the toolbar.

The preservation of division between application and document is crucial
for a truly Mac-like experience.
41.8 KB   View   Download
41.6 KB   View   Download
109 KB   View   Download
Nov 2, 2007
Project Member #1
Thanks!  I agree that those icons are nicer (and it is great that you updated the credits too) so I've merged your 
patch.  You are also right about the toolbar needing to change...if you have suggestions then please start a 
thread on the vim_mac mailing list so that we can discuss it further.  I would very much like some new ideas on 
what the toolbar should contain.

Status: Started
Labels: -Type-Defect Type-Enhancement
Dec 6, 2007
Well, those new icons are nice, but two of them are completely wrong: "Eject" symbol is used for "Open", 
standard mac "Burn" symbol for "make". I don't understand this decision and find it very confusing at best.

Apr 9, 2008
I agree with above:

1. Open should simply go away from the toolbar. No Mac program has it, that's why there is no well-known icon 
for it and Dan had to misuse the eject symbol. Cmd-O is second-nature to any Mac user anyway, not to mention 
dragging files to MacVim's icon on the dock, etc.

2. The burn icon has nothing to do with make. Something like Xcode's "hammer" icon would be much more easily 

3. The new load/save session icons aren't exactly fitting either: they mean "extract archive" and "add to archive" 
respectively. But I can't think of a suitable replacement right now.

Good work overall
Apr 9, 2008
As I'm responsible for the initial iconset change, I thought I'd drop a quick
response and braindump.

1. I agree with a handful of the icons being a poor fit at best, and an incorrect
metaphor at worst. As I'm not an artist, I was constrained by what was available
under Free licenses.

2. I have seen a few Mac applications with "Open" buttons on their toolbars. They
consistently use an Aqua-style folder with an arrow coming up and out of it (google
for Office 2008 screenshots for an example). Of course, such applications don't feel
quite right either (take another look at Office 2008).

Honestly, the toolbar should be rethought. Apple's applications generally use
toolbars for three things: Acting on the window's document, changing the window's
view of its document, and toggling drawers/palettes. To that end, the only current
button I can really see belonging on the toolbar is "Make."

Bluntly: Reusing the Windows/Unix toolbar doesn't cut it. Aquamacs is doing the same
thing and has a similarly weird toolbar.

So what should we do?

Looking at a few popular editors:
 - Coda's toolbar is only used for switching views within a project.
 - TextMate doesn't have a toolbar.
 - SubEthaEdit's toolbar is only used for multiuser editing features (highlighting,
toggling drawers).
 - XCode doesn't have a toolbar, though the editor can be embedded a project window
which has a toolbar for building and running the entire project.

So do we need it at all? A nice Maclike toolbar does help reinforce the idea that
MacVim is actually an application unto itself and not just a 256-color terminal
running vim. The trick is ensuring that such a toolbar is actually useful.

I should be done with the bulk of my schoolwork by the end of April, at which point
I'll be able to get to work on this side of things.
Apr 12, 2008
Well, personaly I agree that most of the icons in the toolbar don't have to be there at all (at least for me). If 
the toolbar was as easily editable as in other Cocoa apps, I would throw them out. 

My ideal toolbar: 
1. User editable as in other Cocoa apps. Options of all current buttons (mostly for compatibility with other 
2. Buttons for 
  - settings of text, that are not even in menu (Show Invisible, Text encoding, Line endings) and 
  - settings that would be visible this way (chosen syntax and colour scheme, tags list)
3.  Show/hide a drawer that would contain the Taglist plugin (that would have to be bundled in MacVim).

(TextWrangler has many of these options, "tags list" idea is from TeXShop.) 
I am not really asking for all of this, just giving you something to look at and think about.
Apr 18, 2008
Don't forget that almost all Mac apps allow the toolbar size and icon/text usage to be adjusted. MacVim 
currently does not allow this.
Aug 13, 2008
Project Member #7
Comment 6 is actually false (and has been ever since the toolbar was implemented in MacVim): take a look at ":h 
'tb'" and ":h 'tbis'".  (Not that this makes much difference, the toolbar is still useless and ugly as it stands.)
Sep 12, 2008
Though I prefer the robustness of macvim, I much prefer the more classic application vim icon from vim-cocoa: 

I think it fits in better with OS X icons, while still looking much fresher than the 32x32 gvim icon included on 
most linux variants.
Nov 15, 2010
Project Member #10
It turns out to be very difficult to support the standard "right-click to customize toolbar" at the same time as supporting Vim's toolbar handling (via :menu commands) which is the reason why things are they way they are (and why they are not likely to change).  In all honesty, the toolbar has very limited use at it stands and I suggest you just hide it so you can fit another line of text!  (Add "set go-=T" to your .gvimrc file.)

The square problem probably has something to do with the fact that the background color has changed slightly since the toolbar framework was written (when OS X 10.4 was current).  If you fix the + sign icon and send me a new one I'll merge it.

Nov 15, 2010
I've added a new entry for the square problem:  Issue 301 

The utility of the tab bar seems to be another issue, and perhaps one we should take up with the mailing list.

Aside from Office, I hardly see any Mac applications placing file opening / saving / printing options in the toolbar, much less undo/redo, cut/copy/paste, or help.

Which leaves us with session saving / loading, running vim scripts, and calling :make in the default toolbar...

Where do we go from there? I think it makes sense, in the case of the toolbar, to diverge a little further from upstream gVim in the interest of creating a more useful, Mac-like editor.
Nov 15, 2010
Project Member #12
At the moment the only reason why I haven't made the toolbar disabled by default is because it is enabled on all other platforms.

The items on the toolbar are mostly dubious like you say.  Even the session and :make icons seem mostly pointless to have in such a prominent spot as the toolbar.

I have thought a bit on what would be useful on the toolbar and have come up mostly blank.  One idea I have been toying with is some sort of "universal search box" which will search in buffer / vimgrep / whatever based on context, or perhaps a pull-down menu.  My reasoning was that a search box is pretty much universal in OS X apps and discovering the "right" search tool in Vim often takes some time (based on my personal experience).

I can't think of anything else that would be useful on the toolbar at the moment.
Sign in to add a comment

Powered by Google Project Hosting