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

List:       vim-dev
Subject:    RE: [vimdev] Re: Vim's future ?
From:       "Michael Geddes" <mgeddes () au ! mediacommand ! com>
Date:       2002-11-07 1:01:12
[Download RAW message or body]

Bram,

It's not Qt (I'm assuming) in itself that is the problem - it's making
vim into an embedded control.  The same problems would become apparent
if we were to make vim an ActiveX control under win32 (I'm not talking
about using at as an .exe COM server here).

So, it's not making it a stand-alone GUI that is the problem - it's
embedding it in another GUI's event loop that is the problem - and this
is effectively what an ActiveX control does - and from what has been
said, also the same for a Qt plugin (which makes sense).

I know you are putting down most of the sweeping statements about how
redesigning it to make vim  better encapsulated with more defined
separation between the different conceptual modules, but in my
experience this is Always a good thing to do - if only for
maintainability, and the ability to more easily conceptualise an
individual area of the code - without having to understand the way the
rest of the code interacts / backdoors &c the particular area of code.

The way that vim has been designed to work with different architectures
is great - but even there, there are still #ifdefs in the middle of
UI-independent code targeted at specific archtiectures, rather than
features.

I'm not totally unsympathetic to your views on how the code should be
organised - but coding methods have developed a long way, and they add
exciting new dimensions to the possibilities for User-interfaces - and
all/most of us on this list would like to see vim amongst the
possibilities.. without taking away its usefulness as a
command-line/terminal editor.

//.



-----Original Message-----
From: Bram Moolenaar [mailto:Bram@moolenaar.net]=20
Sent: Thursday, 7 November 2002 10:09 AM
To: Philippe FREMY
Cc: VimDev; kvim-dev@freenux.org
Subject: RE: [vimdev] Re: Vim's future ?



Philippe Fremy wrote:

> I still think this is not right long term solution. This blocking call

> to vim cripples every gui.

No, that is not true.  All GUIs made so far work just fine.  Perhaps Qt
is so different that it does have a problem, but it would require an Qt
expert to say that before we can draw this conclusion.

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