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

List:       vim-dev
Subject:    RE: [kvim-dev] Re: Vim's future ?
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-12 14:11:37
[Download RAW message or body]


> It's right that Vim doesn't have an event loop, like many GUI
> applications do.  But it blocks by calling a GUI function to get the
> next event, thus it's actually the GUI that blocks, not Vim code.

And this makes it completely unusable in a component world, because the
component host must be able to do plenty of things while the editor is
waiting for a character.

> > This problem is certainly not specific to Qt/KDE. All X11 graphical
toolkit
> > and windows graphical toolkit work with an event loop and gui events.
Gvim
> > is really slow and my guess is that this is one of the 
> reason for it.
> 
> For GTK, Motif and Athena a good solution has been found.  The lowlevel
> function used for this is XtAppProcessEvent().  This is the same
> function that the "normal" GUI event loop uses to wait for the next
> event to arrive.  Doesn't Qt provide a similar function? 

There is something like that but it is not possible to use it inside a
component, where we do not have control on the main gui event loop.

Once you told me on Gnome : "Gnome assumes too much on what it is allowed to
do". The same goes for vim.

> I would be very surprised if it doesn't.  Every GUI application must wait
for the
> next event to arrive somewhere.

It is deep inside Qt. I don't plan to patch Qt anytime soon to make it more
vim-friendly.

> 
> > > A GUI often has an event driven loop, with some way to remember the
> > > current state to decide what to do with an event.  Vim waits for a
> > > next character to be typed in various places.  The place where this
> > > is done inherently specifies the current state.
> > 
> > Indeed. How many such places exist ? Do you think it would be very
difficult
> > to change with a state machine ?
> 
> Yes.  It's like turning Vim inside out.

Bad news.


> > This would make any gui integration a lot
> > more cleaner. What this requires, from a theorical point is to split the
> > functions with blocking character wait into multiple functions, each
> > finishing when the processing of the current key is done. The function
would
> > set a specific state when returning. When the next key arrive, vim would
> > check the state, and call the next function according to this state. Is
that
> > a lot of work ?
> 
> Yes, because you might be deep down a series of function calls and you
> have to go all the way back to the top.  Then when the (key press) event
> has arrived, you need to go back all the way to the bottom again,
> restoring all the local variables that the functions used.  That's an
> awful lot of state information, most of which used to be local to
> functions and now would need to be made global.

I see. Do you have anything against C++ ? Using objects to handle this kind
of state would be make the process a lot easier.

> The resizing is the only problem that is difficult to cope with.  The
> GTK code also has this problem.  It's a conflict of the GUI trying to
> tell Vim what it's new size is and Vim telling the GUI what size it
> wants to be.  It's solvable, but it does require good thinking.

The way it should be done is vim tells the GUI: "I want x lines and y
columns" and sometimes, the gui tells vim "now, you have x2 lines and y2
columns because the user resized". Nothing more. Exact placement of the
scrollbar should be left to the gui.

> 
> > For a good example of the gui abstraction, you can take the search
dialog.
> > It is very good. The vim call only say "popup a search dialog with this
> > information". This is perfect for us because we can implement the search
> > dialog the way we want. We would like to have more abstraction like
that.
> 
> Again, please be specific.  I'm sure the interface between the non-GUI
> part of Vim, the generic GUI part and the system-specific GUI part can
> be improved. We need to do this step by step and making sure the code
> still works for all GUIs.

So if someone submit patches to improve that, you will accept them ?

> > > For example, not all GUIs have a font selector.
> > 
> > Offtopic, but Vim's fonts are causing big trouble to us, because the way
Qt
> > encodes a font name is different from the way vim encodes a font name.
> 
> Does Vim encode a font name?  The 'guifont' option is a plain string.
> For X11 the name
> is the usual dashed name, it's ugly.  For Qt it would be 
> possible to use
> whatever Qt uses.  What would be the problem?

Our initial goal was to be as compatible as possible with vim. So we havn't
look into this solution yet.

> What "do the gui stuff correctly" means very much depends on your point
> of view!  I'm sure that followers of GUI A say all the followers of GUI
> B are doing it wrong.  For Vim it's a very tough job to make as much of
> the GUI code common to all GUIs.  There is no way it's going to be
> "correct" for everybody.

Are you sure. How much experience do you have with GUI coding ? As you
noticed, Qt and Gtk had the same resizing problem. I can tell you that Gtk
and Qt have exactly the same architecture. The port was initially just a
rip-off of the Gtk version. Most X11 Gui toolkit I have seen basically work
the same way. And windows is not that different.

So contrary to what you state, I do think that improving the gui code
improves the GUI for _all_ vim gui.

> I don't see why.  The GUI only has to provide a rectangular pane to draw
> text in, the rest is done by the common Vim code.  The only tricky part
> is the placement of scrollbars, that is a bit unusual.

How do you maximise ? IIRC, you ask for the size of the desktop than deduce
the maximum size of the application and pass a resize to the gui code. But
KDE has a maximise function that does more than that. This is another
example of X11 code that should not go into main vim gui code but only
inside X11 code that doesn't know how to maximise a window. Maximisation
should take into account the size of the window decoration, of the panel,
and stuff like that.

>  But every GUI should provide a way to specify the scrollbar position and
length
> (especially since they are all packed together in the toplevel frame).

You specify a scrollbar size, but what if the current theme require a wider
scrollbar ? What if vim is the only KDE appliation to have a 10 pixel
scrollbar when all other KDE appliation have a 20 pixel wide scrollbar ?
Then kvim is no more a true KDE application, it just has a KDE skin. You
don't really care about the distinction but I do. I don't want kvim to be
second-class citizen of KDE.

> Can you show figures about the GUI code performing badly? 

No figures sorry. But there is a big difference between running vim in a
konsole and running kvim. KVim is really slow to display typed text. Need to
check that again.

> > If having gvim is equivalent to have vim in a console, there is not
> > much interest in gvim.
> 
> Can you show me statistics???

Should I count all the mails  of people who told me they have been waiting
for a long time for such a vim component ? For one guy that wrote us, how
many do agree with him and do not write to us ?
 
> > - overspecification of the gui
> 
> No idea what you mean by this.

don't do things pixel-wise in vim. Just tell us, "scrollbar is on the left"
and "draw string at line/col x,y". Allow us to maximise properly. Things
like that.

> > - lack of access to a pure vim engine.
> 
> Eh, isn't this what we have been using all along?

No we are using vim's application, which is quite different from a vim
engine. Using vim the appliations creates numerous problems that could be
avoided if vim-the-engine could be made separated from vim-the-application. 


> I must admit I mostly prefer a
> tiled window layout over overlapped windows,

It is not about overlapped window, there is no window at all. The comonent
becomes part of the application just like its buttons or its text fields.

> > Since most functions in the C file to have a comment before the function
> > specifying what the function does, would it be possible to at least
include
> > this comment in the .pro file ? You could use the syntax of
javadoc/doxygen,
> > marking comments that are documentation with /** ... */ instead of just
/*
> > ... */.
> 
> I don't see the advantage in this.  When browsing through the source
> code (I always forget how it really works :-) I never get into the
> proto/*.pro files.  I only use "[I" to see the arguments used.  Using
> CTRL-] to jump to a function is mostly sufficient to find out how it
> works.  Sometimes I look for another place where a function is used and
> use this as an example (the surrounding code is often useful as well).
> Use ":grep" for that.

If it doesn't change anything for you and brings us benefit and is a minimal
change, why do you refuse it. The fact that this is not a problem _to you_
doesn't make the need void.

> > And if for you, the source code is clear, for me it is obscure. I have
spent
> > a lot of time trying to understand it.
> 
> There is never enough documentation and comments to find the function
> you are looking for. 

I am talking about an inexpensive modification of existing documentation.
And yet for you it is too much! Your attitude is not very friendly to the
people that want to contribute to vim. 

After a few month of reading through vim source, I have given up. I was
disgusted of always having to go through 2000 lines files to find the
function I was looking for. Yes, i was not using cscope. So vim source is
"use cscope or die ?". I took the second option and kvim development
stopped.

You have no idea how many people have been disgusted to work on vim because
of the way the source code is layed out. But there are more than you think.
On the three people working on kvim, we are three disgusted. This thing is
making valid contributors go coding somewhere else. Too bad.

You should think more about this. Don't you welcome contributions ? Then
welcome additions that do not create problems for you and change the life of
others.

Want any suggestions ? Instead of putting all the gui files inside the main
directory and call them gui_XXX, create a directory ui/ and subdirectories
gtk/, athena/, X11/ and soon kde/ . Put the code specific to each gui in its
own directory. Put the gui generic code (ui.c, gui.h) inside the ui
directory.

This is not very obstrusive. Yet it would make things clear. It took me a
while to figure out that gui_x11 was not needed for me. This is wasted time
that I would have prefereed to spend on kvim. But I expect you to tell me "I
don't see why I should do that, I have no problem with the way the current
code is layed out". Too bad for me and the other contributors.

> Try reading the GTK library source code.  Look ma, no comments! :-(

I did that once or twice and had no problems. The big difference is that
there are API, header files, small files with a relevant names and
intelligent function naming. When you have all that, documenting code is not
that much necessary.

> I would think the Vim code is reasonably understandable, the size is
> what makes it difficult to understand.

I don't agree with the first statement but with the second. When something
gets too big, a solution is to split it, to have manageable size. You are
free not to do it of course.

	Philipppe
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
[prev in list] [next in list] [prev in thread] [next in thread]