[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: Vim's future ?
From:       "vipin aravind" <vipin.aravind () wipro ! com>
Date:       2002-11-06 8:19:32
[Download RAW message or body]

Hello,
It will be great if you guys can move it in terms of C++ abstraction(
Objects,inheritance and so on).

We can have a OsDefaults virtual class from which all the os dependent
Classes derive.Now the main module would call something like
CreateOsdefaults(...), this would create the os dependent derived object.
In case of windows OsWindowsDefaults. Now we have win16 and win32 so the 
leaf object would be OsWindows16defaults and OsWindows32defaults.

As an example lets take the case of printing module.
Now  this object should internally create the necessary derived objects.
E.g:-
     PrintingModule,VimDiffModule,etc

Now the os independent module should call:-
   Osdefaults->GetPrintingModule(...)  and it would get the pointer to the 
PrintingModule.
We can have the PrintingModule virtual, so the derived classes could be
PrintingPSModule, PrintingWinModule(which will be virtual) and from which
PrintingWin16Module and PrintingWin32Module would derive.


The benefit is that all the #ifdefs will go away with this architecture.
vipin

-----Original Message-----
From: Philippe FREMY [mailto:P.FREMY@OBERTHURCS.com] 
Sent: Tuesday, November 05, 2002 10:06 PM
Cc: VIM Team; kvim-dev@freenux.org
Subject: RE: Vim's future ?



Bram wrote:

> Philippe Fremy wrote:
> 
> > Bram said:
> > 
> > > If you use one vim with multiple toplevel windows, most people 
> > > still want different menus, options, private registers, etc.
> > 
> > Are you sure ? These "most people" don't include at least all the 
> > people
who
> > have talked to us (as the kvim development team). Since we have 
> > started
kvim
> > and the vim KDE component, we have had a lot of feedback for
enthusiastic vi
> > and KDE users. I can tell you that _all_ of these people would like 
> > to
have
> > a good vim component. Vim as the application doesn't matter much to
them.
> > KDE is getting more and more popular and we will have more and more
people
> > like this.
> 
> Note that using Vim as a component inside a KDE application is quite 
> different from using Vim as the main application, with multiple 
> toplevelwindows.  There is only a slight overlap here.
> 
> When using Vim as a component, you probably don't want a
> second menu bar inside the Vim part of your framework. 

Well, components are allowed to add menu entries and toolbar entries to their host \
application. So it is possible but we haven't done it.

> I don't know exactly how it would work, but I imagine that when Vim is
active it takes over the
> single menu bar at the top.

When a component is active, the host menu bar is merged with the component menu bar. \
You add an entry <merge/> in the XML file defining the menubar of the host for this \
to happen.

> When activating one of the other windows the Vim-specific menus 
> disappear
again. 
> This is difficult to integrate with the existing Vim menus though.

Yes, it does not integrate with vim's current menu. But the feature itself is very \
easy to provide. This is why I would like to see the vim menu code separated from the \
vim engine. Having exactly the same kvim as gvim is not very interesting. KVim \
becomes interesting if it can integrate more with KDE, using KDE's menu structure and \
such. It would be incompatible with gvim but those who want pure gvim can still have \
it. This is only a personal opinion. The current kvim is 100% compatible with gvim \
and (as a matter of fact) does not integrate that much with KDE.

> > A requirement from the component editor of KDE is to be able to work
with
> > abstracted document of views. This is causing headaches because vim 
> > has
no
> > concept of document or views. Vim has only a concept of vim.
> > 
> > Separating vim into a few components would allow more customisation 
> > of
vim.
> > The current vim would still exist, but we could also have a stripped
down
> > version suitable for many more usage.
> 
> Before jumping to conclusions, specify the problem properly and make a 
> list of alternatives.
> 
> Vim does have views (each window is one), but this might not be the 
> same as what KDE calls a view.  This requires properly specifying how 
> the Vim things map to KDE things.  It's easy to confuse terms.

For KDE, a view is something that inherits from QWidget and is responsible to display \
the content of the file it was given as argument. We have one such QWidget, which is \
our vim component, the vim application embedded into a QWidget. We can not have more \
than one such thing.

> There should be several alternatives, one of them is making a wrapper 
> around Vim to provide the KDE functionality.

This is exactly what we have been doing and the result is not satifying. The code is \
full of complicated hacks, vim takes one or two seconds to start, it features plenty \
of things we have no use for and it misses some stuff. I think there is still a race \
condition, with the consequence that on slow computers, the full vim window pops up \
separately from our application :-(

I agree that vim-the-application has different requirements from vim-the-component, \
which makes using one for the other complicated. This is why I am proposing to \
separate vim-the-application into vim-the-engine and vim-the-application-gui. We \
would only use a very simple vim component.

The question of buffer-local or global settings is valid for vim-the-application. For \
vim the component, this is not as much important. Almost all settings would be global \
and that would be perfectely fine. I can tell you that the user of an integrated \
application prefers a light vim component with less feature than a slower-to-start \
full-blown vim component.

> Redesigning Vim to separate it into components is very likely the
alternative with the
> largest amount of work.

This is the one with the largest amount of work upfront. However, the consequences \
would not only benefit vim-the-component. Vim code would be make simpler, easier to \
maintain, easier to understand. So this means less work afterward. Vim would also \
benefit from the fame of KDE (plus other IDE when the component gets integrated) and \
get new coders that way. 

> Probably too much for anyone to accomplish.

I think you would have answered exactly that if when you have started vim, I had told \
you that you were developing an editor with 7 gui, a script engine, a dynamic menu \
system, a very powerful syntax highlighting engine, many syntax files, a html like \
help system and many translations.

Yes the task is big but so is the benefit.

Basically, you are reluctant but you did not say no. If enough people here find the \
motivation to do the architectural changes, will you accept their patches ? One very \
first step would be to create a directory to hold the various GUI. 

The architectural change doesn't have to be "we break everything at once and hope to \
make it work again". This is the best way to fail. We must do that in an incremental \
manner. At the beginning, it is only separating files into relevant directories. Then \
ensure that each directory contains only files related to its components. Then \
changing slightly the internal engine so that API for components can be made \
apparent. Then use these API (this is where you create bugs). Then lot of testing. \
Then we release vim the component, v1.0 :-)

Note that the component, being available for KDE, probably for Gnome too and for \
other IDE, would get a lot of attentions, user and testing.

	Philippe
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more \
information, connect to http://www.F-Secure.com/


["InterScan_Disclaimer.txt" (text/plain)]

**************************Disclaimer**************************************************    
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

****************************************************************************************





[prev in list] [next in list] [prev in thread] [next in thread]