Updating the toolbar
björn
I have been thinking about the toolbar a bit lately and would like
some feedback on my ideas. Somebody brought up the issue of the
"toolbar customization dialog" so I started thinking about how it
could be implemented. Unfortunately I cannot come up with any way of
reconciling the "Vim way" and the "Cocoa way" of dealing with the
toolbar. The cleanest solution would be to have two toolbar
mechanisms: the Vim toolbar, and the Cocoa toolbar.
1. The Vim toolbar: Well, that's what you have right now.
- Each window has its own toolbar
- Any number of items can be added to a toolbar by calling ":menu
ToolBar.Item ...".
- Each toolbar item is represented by an icon and can be automatically
enabled/disabled depending on which mode Vim is in
(normal/insert/...). An example: the cut & copy items are only
enabled in visual mode.
- The toolbar stated is not persistent...you have to modify .gvimrc to
keep the toolbar settings (very confusing when you press the "pill
button" and expect the toolbar to stay hidden when you restart
MacVim).
2. The Cocoa toolbar: My suggestion for the new and improved toolbar.
- Every window shares a toolbar (this is how Cocoa toolbars work, try
opening two Safari windows and modifying the toolbar in one
window...the toolbar in both windows changes).
- There is a predefined set of allowed toolbar items which are
displayed in the "toolbar customization" dialog (you cannot add any
more without recompiling).
- A toolbar item can be an image (like in Vim) or represented by a
custom view (which allows for fancy things like a search box, drop
down menu buttons, etc.)
- The state of the toolbar is autosaved
Basically, with the "Cocoa way" we can make the toolbar behave like it
should in a Mac app but that also means that the toolbar no longer
behaves like in other Vim ports (duh!). Is this bad? I don't think
so:
- By default we could enable the Cocoa toolbar, but if the user issues
a ":menu ToolBar.Item ..." command then it is replaced by a Vim
toolbar (toolbars in other windows are not affected).
- Who'd want to modify the toolbar from Vim anyway? Well, I don't
want to be the judge of that, but obviously plugins may want to modify
the toolbar. The downside here is that a user might be a bit confused
when a ":menu ToolBar.Item ..." command replaces all current toolbar
items with only one item. I don't see this as much of a problem
though...it would be documented.
I propose that I implement the above Cocoa toolbar...of course I must
also then choose what items should be allowed on there (like I said,
this cannot really be changed in runtime). Initially I would simply
add some items that made sense and then we could discuss the
introduction of more items and what should be the default (Nico had
some suggestions in a previous thread that I would use as a
guideline).
I am a bit of a sucker for the "Safari look" (sans the brushed metal
style) so I was thinking of making the toolbar items look similar to
the Safari items (there is a special button style that can be used to
do this). Another alternative is the "Mail look", or "pill style"
buttons but I don't really like them much.
Anyway, such matters can also be discussed more later...the main issue
here is whether we should introduce a "Cocoa style" toolbar or if we
should stick with the "Vim style" toolbar. Place your votes.
/Björn
travis
toolbar off and don't have to look at it.
Mark
It would make MacVim even more beautiful. I might even not hide the
toolbar then.
I'm not sure about the Safari style. Those buttons feel more like 'one-
off actions': Go back, Stop loading, Refresh. Whereas Vim would need
buttons that for instance shows a file selector. I'm not sure, a
Safari style button feels wrong.
Mark.
Nico Weber
> a ":menu ToolBar.Item ..." command then it is replaced by a Vim
> toolbar (toolbars in other windows are not affected).
If this is done, I think it's ok to go with a Cocoa toolbar.
Another idea would be to put toolbar buttons from plugins into a
floating pane (the only plugin I know that does is http://metamagix.org/vim/vimoutliner.html
). That way you could use plugins that come with toolbar buttons and
still have a nice toolbar. Do we need some explicit "give me back
vim's default behaviour" option in this case (i.e. one that loads
vim's default toolbar buttons and that makes `:menu Toolbar.xxx`
modify the real toolbar)? I'd tend to say no.
> I propose that I implement the above Cocoa toolbar...of course I must
> also then choose what items should be allowed on there (like I said,
> this cannot really be changed in runtime). Initially I would simply
> add some items that made sense and then we could discuss the
> introduction of more items and what should be the default (Nico had
> some suggestions in a previous thread that I would use as a
> guideline).
Since this would give us the Cocoa default "Configure Toolbar" dialog
(cmd-opt-click the pill button in mail to see what I mean), we could
also add a few more items that are not displayed by default (say,
buttons to control folding for example). The tooltips for those
buttons could display the vim command this button calls (e.g. "Closes
a fold.\nVim key: zc" or similar). That would make vim more
discoverable.
> I am a bit of a sucker for the "Safari look" (sans the brushed metal
> style) so I was thinking of making the toolbar items look similar to
> the Safari items (there is a special button style that can be used to
> do this). Another alternative is the "Mail look", or "pill style"
> buttons but I don't really like them much.
FWIW, I like the first look at this page most: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIcons/chapter_15_section_9.html#/
/apple_ref/doc/uid/20000967-TPXREF102 . It probably depends a bit on
what we want to put on the toolbar. Safari and pill style need less
space, but also give you less vertical room to communicate a buttons
effect. This should probably be decided by the icon artist (that we
don't have :-P).
> Anyway, such matters can also be discussed more later...the main issue
> here is whether we should introduce a "Cocoa style" toolbar or if we
> should stick with the "Vim style" toolbar. Place your votes.
+ 1 for Cocoa toolbar.
Nico
travis
http://www.vim.org/scripts/script.php?script_id=453 However they don't
work as Cocoa has trouble with the format of the icons.
On Mar 4, 5:52 am, Nico Weber <nicolaswe...@gmx.de> wrote:
> > - By default we could enable the Cocoa toolbar, but if the user issues
> > a ":menu ToolBar.Item ..." command then it is replaced by a Vim
> > toolbar (toolbars in other windows are not affected).
>
> If this is done, I think it's ok to go with a Cocoa toolbar.
>
> Another idea would be to put toolbar buttons from plugins into a
> still have a nice toolbar. Do we need some explicit "give me back
> vim's default behaviour" option in this case (i.e. one that loads
> vim's default toolbar buttons and that makes `:menu Toolbar.xxx`
> modify the real toolbar)? I'd tend to say no.
>
> > I propose that I implement the above Cocoa toolbar...of course I must
> > also then choose what items should be allowed on there (like I said,
> > this cannot really be changed in runtime). Initially I would simply
> > add some items that made sense and then we could discuss the
> > introduction of more items and what should be the default (Nico had
> > some suggestions in a previous thread that I would use as a
> > guideline).
>
> Since this would give us the Cocoa default "Configure Toolbar" dialog
> (cmd-opt-click the pill button in mail to see what I mean), we could
> also add a few more items that are not displayed by default (say,
> buttons to control folding for example). The tooltips for those
> buttons could display the vim command this button calls (e.g. "Closes
> a fold.\nVim key: zc" or similar). That would make vim more
> discoverable.
>
> > I am a bit of a sucker for the "Safari look" (sans the brushed metal
> > style) so I was thinking of making the toolbar items look similar to
> > the Safari items (there is a special button style that can be used to
> > do this). Another alternative is the "Mail look", or "pill style"
> > buttons but I don't really like them much.
>
Ben Schmidt
> Hi all,
>
> I have been thinking about the toolbar a bit lately and would like
> some feedback on my ideas. Somebody brought up the issue of the
> "toolbar customization dialog" so I started thinking about how it
> could be implemented. Unfortunately I cannot come up with any way of
> reconciling the "Vim way" and the "Cocoa way" of dealing with the
> toolbar. The cleanest solution would be to have two toolbar
> mechanisms: the Vim toolbar, and the Cocoa toolbar.
I'd vote for sticking with the Vim toolbar. I really think the essential aspects
of Vim need to be the same cross platform. I.e. the priority should be to be
Vim-like before being Mac-like. Extending Vim in platform-specific ways is one
thing; replacing features is quite another, and MacVim could too easily turn into
something that isn't really Vim any more. If we're not careful, we'll be making
MacVim modeless because it's more Mac-like! Aaargh!
If you really feel the interface to the toolbar needs revamping, I would suggest
writing a vimscript or making some changes to the Vim core that will work on all
platforms to create a way to do this (a toolbar editor, if you will). And then if
desired, make a nicer platform-specific GUI for it. It would probably be more
work, but it would be heaps better than replacing a Vim feature that a good number
of people and scripts would rely on. Of course, it would need to be coordinated
with Bram, too.
At the very least, if you implement the Cocoa toolbar, it should be off by
default, IMHO.
Another example is the :options command; a nice GUI for that would be nice, but it
would have to be integrated with the existing :options command so that changes to
Vim options get into the GUI thing whenever the Vim core changes, etc..
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Ben Schmidt
> The HTML script puts in toolbar buttons as well:
> http://www.vim.org/scripts/script.php?script_id=453 However they don't
> work as Cocoa has trouble with the format of the icons.
I think getting this to work should be higher priority than fiddling with a Cocoa
toolbar, too, personally. All Vim plugins should really work wherever Vim can
work, particularly if they are vimscript-only (i.e. not python, perl, etc.).
Nico Weber
>> http://www.vim.org/scripts/script.php?script_id=453 However they
>> don't
>> work as Cocoa has trouble with the format of the icons.
>
> I think getting this to work should be higher priority than fiddling
> with a Cocoa
> toolbar, too, personally. All Vim plugins should really work
> wherever Vim can
> work, particularly if they are vimscript-only (i.e. not python,
> perl, etc.).
Well, adding a Cocoa toolbar can be seen as "getting this to work". If
the current toolbar was replaced with a Cocoa toolbar and a floating
window for `:menu Toolbar...` icons was added, all these plugins would
put their icons there. These plugins ship with 16x16 pixel icons as
far as I know, which don't fit into a mac toolbar anyway.
Additionally, the current MacVim toolbar already doesn't display all
of the vim toolbar icons, simply because not all icons fit on it.
And the Cocoa toolbar would, it its default state, of course be very
similar to the normal vim toolbar, with a few changes (no open/save
icons as this is not usually done on the mac; find/find next/find prev
would become a search field that is synced to '/' (that's how search
dialogs look on the mac); etc).
Nico :-)
Bram Moolenaar
Ben Schmidt wrote:
Making MacVim look and feel more Mac-like is fine, of course. But for
someone who has been using Vim on other platforms it must be simple to
move to MacVim. There should be no negative surprises, only oh's and
ah's.
So keep this goal in mind: The .vimrc one has been using on Unix should
work with MacVim. Including additional toolbar items one has defined.
One could discuss about the MS-Windows .vimrc, but since Mac is more
Unix-like it's better to take Unix as a reference. Should be sufficient
for a portability check.
I'm not talking about things that are clearly platform dependent, such
as the image format (I suppose the Mac doesn't handle .xpm files).
[I still have to try out a recent MacVim version...]
--
From "know your smileys":
:-D Big smile
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Jakub Piotr Cłapa
> So keep this goal in mind: The .vimrc one has been using on Unix should
> work with MacVim. Including additional toolbar items one has defined.
>
> One could discuss about the MS-Windows .vimrc, but since Mac is more
> Unix-like it's better to take Unix as a reference. Should be sufficient
> for a portability check.
So the right thing would be to add a Cocoa toolbar but only enable it
for new users (add an almost empty .vimrc for them). Those who already
have their own .gvimrc should get the Unix behaviour unless they add set
toolbar=cocoa or something like this to their .gvimrc (but they will
have to do it by hand).
But the problem with toolbar modifying plugins remains...
--
regards,
Jakub Piotr Cłapa
Nico Weber
>> should
>> work with MacVim. Including additional toolbar items one has
>> defined.
>>
>> One could discuss about the MS-Windows .vimrc, but since Mac is more
>> Unix-like it's better to take Unix as a reference. Should be
>> sufficient
>> for a portability check.
>
> So the right thing would be to add a Cocoa toolbar but only enable it
> for new users (add an almost empty .vimrc for them). Those who already
> have their own .gvimrc should get the Unix behaviour unless they add
> set
> toolbar=cocoa or something like this to their .gvimrc (but they will
> have to do it by hand).
What's wrong with putting user-defined toolbar items into a floating
window and using the Cocoa toolbar as "real" toolbar by default?
Nico
björn
I don't really like the idea of another window floating around. Does
anybody else like this idea?
I also do not understand the objections have against the Cocoa toolbar
since it will _not_ break the usual Vim patterns. If somebody wants
to modify the toolbar from Vim they can. I can only assume that
people do not want ":menu ToolBar..." commands to _replace_ the Cocoa
toolbar; they want such commands to _add_ to the Cocoa toolbar. Am I
right? If that is the case, then maybe I can think of some way of
rectifying that.
It just seems to me that plugins which add to the toolbar are just
extremely likely to overcrowd it so that the overflow menu pops up and
hence it would be better if they simply got access to the entire
toolbar. Am I mistaken here?
If the complaint is about the toolbar looking different by default in
MacVim as compared with other platforms, then I am at a loss for
words. The default toolbar is just not very useful:
- it doesn't fit the default window size
- it contains masses of items nobody ever uses (least of all a newbie)
- it contains lots of items which do not belong on the toolbar in an OS X app
- I could go on ...
So, those of you who do not like the idea of a Cocoa toolbar...can you
please address the above points so that I may understand your
objections to it better? (And so that I may perhaps come up with a
way around those issues.)
Thanks,
Björn
Jakub Piotr Cłapa
> What's wrong with putting user-defined toolbar items into a floating
> window and using the Cocoa toolbar as "real" toolbar by default?
Looks good to me. :)
Nico Weber
>> window and using the Cocoa toolbar as "real" toolbar by default?
>
> I don't really like the idea of another window floating around. Does
> anybody else like this idea?
> It just seems to me that plugins which add to the toolbar are just
> extremely likely to overcrowd it so that the overflow menu pops up and
> hence it would be better if they simply got access to the entire
> toolbar. Am I mistaken here?
The icons that ship with the plugins are in the wrong pixel size (and
they have the "wrong" look too) for the default toolbar. Putting them
in their own window (which would be the vim toolbar, i.e. it'd
correspond to vim's `set guioptions-=T` option, thus we could autosave
the real toolbar state, as the pill would not have to deal with
guioptions) fixes this. And if you don't like the floating window (why
"another"? It's the first), you can hide it.
Of course, only one of the toolbar panels would be visible at a time
(there has to be one for each vim instance I suppose).
/me likes :-P
Nico
Ben Schmidt
> anybody else like this idea?
I don't like the extra window idea, either.
I liked the suggestion that it be enabled for new users by means of a minimal
..vimrc, but Unix behaviour for folks who have their own .vimrc already. Not hugely
sure how you'd implement that to make it work, but I like the suggestion, and
think it worthy of further thought. Though actually, I think I have a better idea
if it is feasible...see below.
> I also do not understand the objections have against the Cocoa toolbar
> since it will _not_ break the usual Vim patterns.
It sounded to me like it would.
> If somebody wants
> to modify the toolbar from Vim they can. I can only assume that
> people do not want ":menu ToolBar..." commands to _replace_ the Cocoa
> toolbar; they want such commands to _add_ to the Cocoa toolbar.
I use the toolbar rarely, but I would expect and want the functionality to be able
to remove toolbar icons as well as add them via vimscript, and for different Vim
instances to have different toolbars. Vim can do this on any other platform and it
would definitely be a negative surprise if it didn't work in MacVim. I also think
it is just darn confusing if the Cocoa toolbar could be sometimes on and sometimes
off depending what files you've sourced.
> Am I
> right? If that is the case, then maybe I can think of some way of
> rectifying that.
>
> It just seems to me that plugins which add to the toolbar are just
> extremely likely to overcrowd it so that the overflow menu pops up and
> hence it would be better if they simply got access to the entire
> toolbar. Am I mistaken here?
I think with the ability to remove icons in Vimscript, the adding is a lesser
problem, which is why I think that's important. I don't think having separate
toolbars is a good idea, whether they are in separate windows, in the same window,
or even having to choose between one and the other.
> If the complaint is about the toolbar looking different by default in
> MacVim as compared with other platforms, then I am at a loss for
> words.
Definitely not. A more Mac-like look is definitely plus.
I also think some more Cocoa-like widgets would be a great idea, e.g. a search
type-in box, with a nice little popup menu that can make it do the / command, or
the :find command, the :grep command, etc.. But I think it would be better to
integrate this somehow with the Vim toolbar rather than build something new to
replace the Vim toolbar.
> So, those of you who do not like the idea of a Cocoa toolbar...can you
> please address the above points so that I may understand your
> objections to it better? (And so that I may perhaps come up with a
> way around those issues.)
Would doing it something like this be feasible?:
- give the toolbar a Cocoa-like look in terms of background textures, default
icons, etc. Make it understand more icon formats, too, if possible.
- for more fancy Cocoa widgets, define commands beginning with :mac, e.g.
:macsearch. If executed as an Ex command, they can fall back to some other
command, e.g. :/, but if found in the toolbar, MacVim can display a fancy widget
for it. Either that or use the 'menu item name' of the toolbar buttons to trigger
display of fancier widgets. Though I kinda like the :mac... idea, because you
could then easily get widget functionality by using the command as an Ex command
if you wanted it. Might be nicer sometimes than clicking in a widget, but makes
use of the current 'mode' of the widget (e.g. / vs. :find vs. :grep).
- For that matter, it would be really cool if the :menu command were extended to
allow a flag that means a textbox should be displayed in the toolbar and arbitrary
commands built from it, like how nargs and <args> are used with :command. Then you
could create all kinds of toolbar icons in Vimscript that do fancy things when you
type in them and hit enter.
- Put these fancy widgets on the toolbar by default in place of equivalent Vim
toolbar icons that are there by default on other platforms.
- For the 'Customise toolbar' command, instead of saving the results in Mac user
defaults, store them in a file in ~/.vim/plugin/, say mactoolbar.vim, i.e.
maintain a very simple machine-readable/writable vimscript at
~/.vim/plugin/mactoolbar.vim that simply adds/removes toolbar buttons using :menu
and :unmenu. If MacVim finds this file has been tampered with (i.e. it is no
longer machine readable!) it could display a dialog and refuse to allow you to
'Customise Toolbar'. When you 'Customise Toolbar' any icons added by other pieces
of Vimscript (e.g. other plugins) would be ignored, so you would only be
customising the bare defaults (i.e. what is in ~/.vim/plugin. Changes wouldn't
propagate to other instances as they would just be made on initialisation of Vim,
but I think that's fair, and even perhaps sometimes desirable, actually.
This way, at the most fundamental level, all toolbar changes are made by
Vimscript, so this is very Vim-like and ensures all the necessary support is there
for plugins, etc.. You get the Cocoa look all the time, no matter what you do to
the toolbar. And you get the 'Customise toolbar' functionality for drag and drop
toolbar editing.
Ben Schmidt
> they have the "wrong" look too) for the default toolbar.
My priorities:
1. Editing my files.
2. Having tools, including toolbar buttons, to facilitate this.
3. How these tools work.
4. How these tools look.
5. How hard it is for the programmer to implement.
> Putting them
> in their own window (which would be the vim toolbar, i.e. it'd
> correspond to vim's `set guioptions-=T` option, thus we could autosave
> the real toolbar state, as the pill would not have to deal with
> guioptions) fixes this.
I'm afraid the 'own window' idea really repulses me. Having to move a floating
window around all the time when I want to move my other windows around just sounds
really clumsy/annoying to me. If it could be 'docked' in the Vim window to which
it belongs, it wouldn't hurt. I.e. I think this would bung up priority 2-3,
probably for the sake of priority 5. Not being able to use autosave might be a bit
annoying for implementation, but may be better for the user (see my other email
for an idea of how these problems can be overcome).
> And if you don't like the floating window (why
> "another"? It's the first), you can hide it.
But the whole point was that you *wanted* the toolbar. Saying that if you don't
like the form it is in, you should hide it, is unhelpul.
> Of course, only one of the toolbar panels would be visible at a time
> (there has to be one for each vim instance I suppose).
Of course. But it's even more intuitive if these jiggers are part of the windows
they are linked with!
Nico Weber
> I use the toolbar rarely, …
So you're arguing just for the sake of arguing? ;-)
> I also think it is just darn confusing if the Cocoa toolbar could be
> sometimes on and sometimes
> off depending what files you've sourced.
That's not a problem with the float. If there are no plugin toolbar
items, it's invisible, else it's visible. The normal toolbar always
looks the same.
> Would doing it something like this be feasible?:
>
> - give the toolbar a Cocoa-like look in terms of background
> textures, default
> icons, etc. Make it understand more icon formats, too, if possible.
It's not about the formats, but about the size. Win32 and Unix
toolbars are 20x20, Mac is 32x32.
> - for more fancy Cocoa widgets, define commands beginning with :mac,
> e.g.
> :macsearch. If executed as an Ex command, they can fall back to some
> other
>
> *snip*
>
> but I think that's fair, and even perhaps sometimes desirable,
> actually.
That sounds like a lot of work for not much effect. I wouldn't want to
write this.
Well, in the end it's up to Bjorn (or whoever else writes it). I feel
my suggestion is easy to understand for the user and comparably easy
to implement. Here are mock-ups of the two approaches:
Putting plugin toolbar items into the real toolbar:
http://amnoid.de/tmp/vimbar.png
(note that this looks a bit worse than it would look in practice; the
grey background color could be made transparent. But the icons would
still be that blurry).
Using a floating palette:
http://amnoid.de/tmp/floatbar.png
Again, this could look a bit nicer if the icon backgrounds were made
transparent and you could see the familiar tool window background color.
> My priorities:
>
> 1. Editing my files.
Works, yay :-)
> 2. Having tools, including toolbar buttons, to facilitate this.
> 3. How these tools work.
> 4. How these tools look.
> 5. How hard it is for the programmer to implement.
Implementability might not be your top priority, but it is important
to the people who do the implementation ;-) Besides, a floating window
fulfills 2-4 nicely.
Well, I won't push this idea further if no-one likes it. Judging by
the number of authors in this thread, most people don't seem to care
about this anyways ;-)
Nico
Matt Tolton
do like Nico's idea best.
björn
that I am failing to communicate all the relevant details properly.
On 07/03/2008, Ben Schmidt <mail_ben...@yahoo.com.au> wrote:
>
> > I also do not understand the objections have against the Cocoa toolbar
> > since it will _not_ break the usual Vim patterns.
>
> It sounded to me like it would.
>
>
> > If somebody wants
> > to modify the toolbar from Vim they can. I can only assume that
> > people do not want ":menu ToolBar..." commands to _replace_ the Cocoa
> > toolbar; they want such commands to _add_ to the Cocoa toolbar.
>
>
> I use the toolbar rarely, but I would expect and want the functionality to be able
> to remove toolbar icons as well as add them via vimscript, and for different Vim
> instances to have different toolbars. Vim can do this on any other platform and it
> would definitely be a negative surprise if it didn't work in MacVim. I also think
> it is just darn confusing if the Cocoa toolbar could be sometimes on and sometimes
> off depending what files you've sourced.
The big point of my suggestion is that you are still able to interact
with the toolbar just the same as on other platforms. The only
difference is that from Vim's point of view the toolbar is empty by
default (from the user perspective the "Cocoa toolbar" is visible by
default). Thus, if you want to customize the toolbar from Vim, then
you'll have to add all the items you want in your .gvimrc. Also, each
window can have its own toolbar.
> > It just seems to me that plugins which add to the toolbar are just
> > extremely likely to overcrowd it so that the overflow menu pops up and
> > hence it would be better if they simply got access to the entire
> > toolbar. Am I mistaken here?
>
> I think with the ability to remove icons in Vimscript, the adding is a lesser
> problem, which is why I think that's important. I don't think having separate
> toolbars is a good idea, whether they are in separate windows, in the same window,
> or even having to choose between one and the other.
There is always only one toolbar but you can customize it it in two
mutually exclusive ways:
1. With Vim script
2. Using the standard Cocoa "Customize toolbar..." sheet
That is, the user chooses in which way to interact with the toolbar.
Experienced Vim users (and plugin writers) will choose option 1,
everybody else will most likely go for option 2 (if you never tried
it, open the "Customize toolbar..." in the View menu of Safari to see
how easy it is to use).
It would be best if I could reconcile these two options, but I don't
think it is possible because Cocoa does not provide any notification
when the toolbar changes. Well, you can get notifications when
toolbar items are added/removed, but not when they are moved around
(try opening the "Customize toolbar..." item in the View menu in
Safari and drag the toolbar icons on the toolbar around to see what I
mean by "moving toolbar items").
The difficulty here is that both Vim and Cocoa expects to be in charge
of the toolbar.
> > If the complaint is about the toolbar looking different by default in
> > MacVim as compared with other platforms, then I am at a loss for
> > words.
>
>
> Definitely not. A more Mac-like look is definitely plus.
Phew! I was getting worried there for a while! :-)
> I also think some more Cocoa-like widgets would be a great idea, e.g. a search
> type-in box, with a nice little popup menu that can make it do the / command, or
> the :find command, the :grep command, etc.. But I think it would be better to
> integrate this somehow with the Vim toolbar rather than build something new to
> replace the Vim toolbar.
It would be possible to take the toolbar quite far using only Vim
script, but we will never get the "Customize toolbar..." sheet this
way. That is the only problem, I think.
> > So, those of you who do not like the idea of a Cocoa toolbar...can you
> > please address the above points so that I may understand your
> > objections to it better? (And so that I may perhaps come up with a
> > way around those issues.)
>
>
> Would doing it something like this be feasible?:
>
> - give the toolbar a Cocoa-like look in terms of background textures, default
> icons, etc. Make it understand more icon formats, too, if possible.
If somebody were to draw the icons, yes. I think it understands
enough formats (see docs for NSImage), the problem is that it only
looks inside the app bundle at the moment. I have to make it look for
images inside ~/.vim (and what other places?).
> - for more fancy Cocoa widgets, define commands beginning with :mac, e.g.
> :macsearch. If executed as an Ex command, they can fall back to some other
> command, e.g. :/, but if found in the toolbar, MacVim can display a fancy widget
> for it. Either that or use the 'menu item name' of the toolbar buttons to trigger
> display of fancier widgets. Though I kinda like the :mac... idea, because you
> could then easily get widget functionality by using the command as an Ex command
> if you wanted it. Might be nicer sometimes than clicking in a widget, but makes
> use of the current 'mode' of the widget (e.g. / vs. :find vs. :grep).
This is something I have thought of too...I think it could make way
for some interesting toolbar items.
> - For that matter, it would be really cool if the :menu command were extended to
> allow a flag that means a textbox should be displayed in the toolbar and arbitrary
> commands built from it, like how nargs and <args> are used with :command. Then you
> could create all kinds of toolbar icons in Vimscript that do fancy things when you
> type in them and hit enter.
Nice idea. It would also be nice with "live updating" so that the
command is executed as you type (like your typical "search box").
> - Put these fancy widgets on the toolbar by default in place of equivalent Vim
> toolbar icons that are there by default on other platforms.
> - For the 'Customise toolbar' command, instead of saving the results in Mac user
> defaults, store them in a file in ~/.vim/plugin/, say mactoolbar.vim, i.e.
> maintain a very simple machine-readable/writable vimscript at
> ~/.vim/plugin/mactoolbar.vim that simply adds/removes toolbar buttons using :menu
> and :unmenu. If MacVim finds this file has been tampered with (i.e. it is no
> longer machine readable!) it could display a dialog and refuse to allow you to
> 'Customise Toolbar'. When you 'Customise Toolbar' any icons added by other pieces
> of Vimscript (e.g. other plugins) would be ignored, so you would only be
> customising the bare defaults (i.e. what is in ~/.vim/plugin. Changes wouldn't
> propagate to other instances as they would just be made on initialisation of Vim,
> but I think that's fair, and even perhaps sometimes desirable, actually.
The biggest problem isn't how the toolbar data is stored, but the fact
that Cocoa doesn't provide notifications of when the toolbar is
modified like I said above. All your ideas require Vim to be in
charge (I strive to make this an invariant in MacVim, but it is not
always possible) and this does not work with the toolbar.
> This way, at the most fundamental level, all toolbar changes are made by
> Vimscript, so this is very Vim-like and ensures all the necessary support is there
> for plugins, etc.. You get the Cocoa look all the time, no matter what you do to
> the toolbar. And you get the 'Customise toolbar' functionality for drag and drop
> toolbar editing.
I would like to implement things the way you suggest, but I cannot.
We could do mostly everything with by changing the Vim toolbar around
a bit (as in I have to write some code for it), but we will not get
Cocoa's "Customize toolbar..." sheet.
Maybe the prudent thing would be to just live with it and improve the
toolbar on the Vim side as much as we can (it would not require too
much alteration inside Vim). However, my suggestion would not require
too much coding effort on my side and it does not cripple MacVim's
toolbar as compared with how it works on other platforms. Really, the
only thing that changes is that the default toolbar will look
different on MacVim and it gives newbies an easier way to modify the
toolbar to their needs.
Actually (please let me take some time to contradict myself), it may
present some problems for plugin authors in that they cannot simply
add items to the toolbar. However, they cannot rely on the toolbar
looking the same for all users since each user may modify their
toolbar via .gvimrc. So in essence, this is nothing new.
If anybody still thinks my idea in some way breaks Vim's normal usage
patterns please tell me and maybe I can convince you otherwise (or you
try to convince me of your view).
/Björn
björn
> my suggestion is easy to understand for the user and comparably easy
> to implement. Here are mock-ups of the two approaches:
>
> Putting plugin toolbar items into the real toolbar:
>
> http://amnoid.de/tmp/vimbar.png
>
> (note that this looks a bit worse than it would look in practice; the
> grey background color could be made transparent. But the icons would
> still be that blurry).
>
> Using a floating palette:
>
> http://amnoid.de/tmp/floatbar.png
>
> Again, this could look a bit nicer if the icon backgrounds were made
> transparent and you could see the familiar tool window background color.
That was by far the best argument you could have made, I think. When
I said I didn't like your idea in the other post I ... meant it. :-P
Sorry, had to type that. Ok, yes, so having a floating toolbar is
slightly annoying, but it does neatly take care of the problem.
> > My priorities:
> >
> > 1. Editing my files.
>
> Works, yay :-)
And there was much rejoicing.
>
> > 2. Having tools, including toolbar buttons, to facilitate this.
> > 3. How these tools work.
> > 4. How these tools look.
> > 5. How hard it is for the programmer to implement.
>
> Implementability might not be your top priority, but it is important
> to the people who do the implementation ;-) Besides, a floating window
> fulfills 2-4 nicely.
>
> Well, I won't push this idea further if no-one likes it. Judging by
> the number of authors in this thread, most people don't seem to care
> about this anyways ;-)
At the moment I think this is a viable solution. In particular if
coupled with an option to send ":menu ToolBar..." commands to the
actual toolbar instead of to a floating window (so that anybody who
wants to can customize the toolbar fully from script).
/Björn
Brian McKee
> If anybody still thinks my idea in some way breaks Vim's normal usage
> patterns please tell me and maybe I can convince you otherwise (or you try
> to convince me of your view).
Well, I'm not sure I understood the conversation to this point, but are you
saying if you make a Cocoa toolbar, and I hit the pill button to customize it,
then my Vim plugins that alter the menu bar quit working or disappear?
I think the existing body of software that uses the toolbar is more important
than not as yet written software that might use Mac-like toolbar features....
Brian
björn
>
> On Fri, Mar 7, 2008 at 12:40 PM, björn <bjorn.w...@gmail.com> wrote:
> > If anybody still thinks my idea in some way breaks Vim's normal usage
> > patterns please tell me and maybe I can convince you otherwise (or you try
> > to convince me of your view).
>
>
> Well, I'm not sure I understood the conversation to this point, but are you
> saying if you make a Cocoa toolbar, and I hit the pill button to customize it,
> then my Vim plugins that alter the menu bar quit working or disappear?
After all that ranting I realized that something like this is a
problem. If a plugin adds toolbar items then the customization sheet
is simply disabled (for the window the item was added only), so the
answer to your question is "no".
Oh, that sounds bad. And I guess would be extremely confusing.
Anyway, the minute you (or a plugin) starts adding toolbar items from
Vim the customization dialog is disabled. That is the biggest
shortcoming of this approach (...that I can think of now).
Maybe I need to think a little bit more about this. It could be that
we simply will have to leave the customization sheet out...which would
be unfortunate. :-(
> I think the existing body of software that uses the toolbar is more important
> than not as yet written software that might use Mac-like toolbar features....
Indeed, if current plugins stopped working then I would not see it as
a viable solution.
/Björn
Ben Schmidt
Centring the icons in a larger cell may look better than scaling them. Though, I
personally prefer the scaling even with blurriness. But then, I'm visually impaired...
>> Using a floating palette:
>>
>> http://amnoid.de/tmp/floatbar.png
>>
>> Again, this could look a bit nicer if the icon backgrounds were made
>> transparent and you could see the familiar tool window background color.
>
> That was by far the best argument you could have made, I think. When
> I said I didn't like your idea in the other post I ... meant it. :-P
> Sorry, had to type that. Ok, yes, so having a floating toolbar is
> slightly annoying, but it does neatly take care of the problem.
How about this idea that might be a good compromise between the two?
Have an item in the Cocoa toolbar that can't be removed that is the Vim toolbar?
(Or perhaps, if it is removed, make it appear as a floating window.) After all,
the Vim toolbar is smaller, so could easily fit in the Cocoa toolbar. It would be
empty by default.
I still kinda cringe at the idea of not being able to remove icons with Vimscript.
But...I could always remove all the Cocoa toolbar items except the Vim toolbar, or
perhaps one or two fancy widgets that I like, and restore the Vim defaults (pleaes
make this easy to do, however the toolbar ends up being implemented!) and then I'd
have pretty full control.
See, I imagine one usage pattern would be to have a standard set of buttons most
of the time, but when editing a certain type of file, a stack of these disappear
and get replaced with file-specific ones.
> And there was much rejoicing.
>
>> > 2. Having tools, including toolbar buttons, to facilitate this.
>> > 3. How these tools work.
>> > 4. How these tools look.
>> > 5. How hard it is for the programmer to implement.
>>
>> Implementability might not be your top priority, but it is important
>> to the people who do the implementation ;-) Besides, a floating window
>> fulfills 2-4 nicely.
I don't think it fulfils 3 nicely. Having a floating window to move around and
coordinate with other items on my screen doesn't count as 'working well' in my book.
Putting implementability at priority 5 doesn't make it unimportant. I could have
left it out altogether! I just wanted to provide an end-user perspective, partly
because I think software that is written focused on end users tends to be a lot
nicer to use than software that is written focused on ease of implementation. I
think that's one of the reasons the Mac is where it is today, as well--because a
lot of care has been taken to write good user interfaces, i.e. focusing on the
user, the platform is just nicer to use than many alternatives.
> At the moment I think this is a viable solution. In particular if
> coupled with an option to send ":menu ToolBar..." commands to the
> actual toolbar instead of to a floating window (so that anybody who
> wants to can customize the toolbar fully from script).
O! I didn't see that suggestion before I wrote the rest of my reply somehow...
If the toolbar can be customised fully from script, both adding items and deleting
existing ones, I am satisfied.
Ben Schmidt
>
> So you're arguing just for the sake of arguing? ;-)
Yes and no...
I use the toolbar rarely, because I use gvim rarely, because of a few other
shortcomings that look like they may well be addressed in time, but which aren't yet.
When I start to use gvim more, I expect to use the toolbar more. But I would
expect to use it not so much for the standard commands that I am used to typing as
Ex commands already, but for more fancy things, and/or with heavy customisations
for different file types, etc.. So that's why I push so much for making the
toolbar customisable from Vimscript.
>> I also think it is just darn confusing if the Cocoa toolbar could be
>> sometimes on and sometimes
>> off depending what files you've sourced.
>
> That's not a problem with the float. If there are no plugin toolbar
> items, it's invisible, else it's visible. The normal toolbar always
> looks the same.
True, it isn't a problem with the float. I still don't like the idea of having a
toolbar which must always stay the same--very un-Vim-like having something that
can't be customised!
>> Would doing it something like this be feasible?:
>>
>> - give the toolbar a Cocoa-like look in terms of background
>> textures, default
>> icons, etc. Make it understand more icon formats, too, if possible.
>
> It's not about the formats, but about the size. Win32 and Unix
> toolbars are 20x20, Mac is 32x32.
I thought in an earlier post a format issue was raised--xpm icons or something
that work on pretty much every other platform but Mac (and possibly Windows...).
That's what I was referring to.
> That sounds like a lot of work for not much effect. I wouldn't want to
> write this.
Mmm. Perhaps the 'Customise Toolbar' should simply be a way to set the initial set
of icons, and Vimscript can then be used to further alter it (i.e. add or remove
icons at will). That would be easier than maintaining a Vimscript file. I still
personally would prefer the customisations to end up in Vimscript, but hey, the
important thing for me is to have the toolbar Vimscript customisable. If the
initial toolbar is changeable and saved in Cocoa defaults, but still could be
affected by Vimscript, that'd be cool, too, from my perspective.
Ben Schmidt
> with the toolbar just the same as on other platforms. The only
> difference is that from Vim's point of view the toolbar is empty by
> default (from the user perspective the "Cocoa toolbar" is visible by
> default). Thus, if you want to customize the toolbar from Vim, then
> you'll have to add all the items you want in your .gvimrc.
The problem with this approach as I see it is that to truly be able to interact
just the same as other platforms, you not only need to add all the items you want
in your .gvimrc (or filetype-specific plugin), but also get rid of all (or some)
of the Cocoa icons, and there isn't a Vim-compatible way to do this in your
suggestion, from what I can tell.
> Also, each
> window can have its own toolbar.
Cool. I wasn't sure whether you were advocating the 'all windows have the same
toolbar' approach when you mentioned that other Mac apps have that behaviour.
> It would be best if I could reconcile these two options, but I don't
> think it is possible because Cocoa does not provide any notification
> when the toolbar changes.
Darn! That's the detail that starts to make it all get tricky! If the Cocoa app
doesn't have a way to find when the toolbar changes, or to query its current
arrangement, or something, then you can't really reconcile the approaches without
writing a good deal of toolbar code. It might be worth it, but probably more as a
long-term goal/later upgrade.
>> I also think some more Cocoa-like widgets would be a great idea, e.g. a search
>> type-in box, with a nice little popup menu that can make it do the / command, or
>> the :find command, the :grep command, etc.. But I think it would be better to
>> integrate this somehow with the Vim toolbar rather than build something new to
>> replace the Vim toolbar.
>
> It would be possible to take the toolbar quite far using only Vim
> script, but we will never get the "Customize toolbar..." sheet this
> way. That is the only problem, I think.
I would view the 'Customise toolbar' as a minor loss, personally. It is definitely
nice, but is the icing on the cake, not the cake itself.
>> - for more fancy Cocoa widgets, define commands beginning with :mac, e.g.
>> :macsearch. If executed as an Ex command, they can fall back to some other
>> command, e.g. :/, but if found in the toolbar, MacVim can display a fancy widget
>> for it. Either that or use the 'menu item name' of the toolbar buttons to trigger
>> display of fancier widgets. Though I kinda like the :mac... idea, because you
>> could then easily get widget functionality by using the command as an Ex command
>> if you wanted it. Might be nicer sometimes than clicking in a widget, but makes
>> use of the current 'mode' of the widget (e.g. / vs. :find vs. :grep).
>
> This is something I have thought of too...I think it could make way
> for some interesting toolbar items.
Yeah. Lots of possibilities.
>> - For that matter, it would be really cool if the :menu command were extended to
>> allow a flag that means a textbox should be displayed in the toolbar and arbitrary
>> commands built from it, like how nargs and <args> are used with :command. Then you
>> could create all kinds of toolbar icons in Vimscript that do fancy things when you
>> type in them and hit enter.
>
> Nice idea. It would also be nice with "live updating" so that the
> command is executed as you type (like your typical "search box").
Yeah, that would be cool, too.
> Maybe the prudent thing would be to just live with it and improve the
> toolbar on the Vim side as much as we can (it would not require too
> much alteration inside Vim).
Mmm. I think that would be my preference. Some of the most exciting prospects
above, IMHO, can't be done in the Cocoa toolbar, because they require that
arbitrary Ex commands be associated with toolbar buttons.
> However, my suggestion would not require
> too much coding effort on my side and it does not cripple MacVim's
> toolbar as compared with how it works on other platforms. Really, the
> only thing that changes is that the default toolbar will look
> different on MacVim and it gives newbies an easier way to modify the
> toolbar to their needs.
>
> Actually (please let me take some time to contradict myself), it may
> present some problems for plugin authors in that they cannot simply
> add items to the toolbar. However, they cannot rely on the toolbar
> looking the same for all users since each user may modify their
> toolbar via .gvimrc. So in essence, this is nothing new.
Perhaps this is a road forward that would work:
- For starters, make the Vim toolbar a single item in the Cocoa toolbar,
defaulting to empty, and provide a command to clobber the Cocoa toolbar if
desired. Then you get both types of customisations that can happen 'in parallel'
as it were, at least almost.
- Work on extending the Vim toolbar to include fancier widgets and stuff,
associated with Ex commands. The default Vim toolbar then just contains one or two
fancy widgets by default (perhaps just the search one), so the toolbar is still
mostly customisable by 'Customise toolbar' but also has fancy stuff, but that
fancy stuff is properly integrated with Vim.
- Work on an alternative to 'Customise toolbar' that is just as friendly, but that
works with the Vim toolbar instead of the Cocoa toolbar.
- Move everything to the Vim toolbar which now has all the benefits of the Cocoa
toolbar.
It could happen over many months, but I think would have the most beneficial
endpoint, and a good compromise in the meantime.
Jakub Piotr Cłapa
I like it! I might even start to use the toolbar if it would be one
shared window for all editors. That's how Adobe CS works and the screen
space savings are big.
PS. A vertical one would also be nice.