>
> Does anyone know of any attempts at making gvim (for MS Windows)
> look more modern? (Using a standard gui border for split windows, a
> gui-window for completion lists, a standard gui status bar, etc)
>
> If something like this doesn't already exist, would anyone be
> interested in me tying to code it? (Possibly even helping me out?)
> It would probably have to be maintained as a set of patches against
> the official vim releases.
As the author of Cream, I'm very interested in gVim having a few more
OS-standard widgets. Tony has already written an excellent post
summarizing the arguments against. I'll take a shot at a few arguments
for.
1. With just a few widgets, gVim *could* be customized to look and
behave like many other editors designed within the current OS
Desktop paradigm. Having similar appearance to other text editors
at least keeps Vim from appearing inferior or antiquated to the
uninitiated.
2. Outrageous amounts of effort have gone into developing GUI
interfaces over the decades. They have stuck because they work on
many levels. You would be hard-pressed to sell machines these days
without a graphic input device (mouse or finger), GUI windows,
widgets, proportional fonts, etc. Even gVim has conceded to
toolbars, a statusline, scroll bars, tabs, dialog boxes,
highlighting and colored syntax, spelling indications, etc. Visual
conventions have developed because they make interfaces easier.
3. There are broader types of text editor usage that these
developments would assist beyond traditional Vim usage. Not all of
us simply use a text editor for 12 hours of coding. Some of us also
write content, display complex file states, or use applications to
minimally format or process information, etc. In those cases,
proportional fonts are more easily read, GUI statusbars could be
interactive, and dialog selection lists, radio buttons, etc. are
more flexible for displaying data and obtaining user input.
4. Non-refocusing find/replace dialogs are crazy. :)
Arguments against modern interface conventions make sense only in
situations of demonstrated need: terminals, editing over slow
connections, ancient hardware, etc. These are not the requirements for
99.9% of computer users. But Vi/Vim has always served those
capacities, it doesn't make sense that it suddenly abandon these
services. So I think there are some obvious requirements for improved
GUI features:
1. Not at the expense of existing features. (This in itself is no
hurdle, Vim has a terrific set of compile-time features.)
2. Multiple platform implementation. Windows-only doesn't cut it. Many
Vim users need similar features across at least Windows and
Linux/Gnome/GTK. (There are lots of single-OS editors out there
already.)
3. Self-motivated developer(s). Given the current expectations of the
community, there won't be much support for advanced GUI features.
There won't be much opposition if they meet the above requirements,
but implementation will require ownership and attention to detail
to ensure they work well and bug-free.
4. Tiny scopes. I would recommend implementing each GUI feature
independently of the others. A special library for everything is
too hard to write, control and patch. Use conventions like
+gui_statusbar, +gui_dialog_-widgets, and +font_prop. By
implementing features in small steps, they can be developed and
tested more quickly.
Obviously, I don't speak for the Vim community or its author. I'm just
an interested party who has been around for a few years. I've seen
these interests come and go, and would like to see some developments
exactly in line with what you've suggested.
--
Steve Hall [ digitect dancingpaper com ]
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment