[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: porting GNU Emacs to kde (?)

From: Giannis Georgalis
Subject: Re: porting GNU Emacs to kde (?)
Date: 19 Mar 2004 16:05:10 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Richard Stallman <address@hidden> writes:

Hello mr. RMS,

> Since we already have GTK support, there's no reason we could not
> have equivalent Qt support, if it someone wants to maintain it.
> However, GNOME is the main GNU desktop, and GNU packages are supposed
> to support each other.  It would not be right for Emacs to have more
> support for KDE than for GNOME.

A clean and organized approach to "transforming" Emacs in a
"component(TM)", should provide a similar codebase for both GNOME
and KDE. If the design is good, the GNOME/KDE specific code should be

Of-cource this is the way I see it. Could a Bonobo hacker confirm or
prove it false... ?

> Could someone investigate this?  It would be quite desirable to
> integrate Emacs with GNOME in this way.  If the same work could make
> this possible for GNOME and KDE, it would be pretty high priority--if
> it is feasible and acceptable at all.

I could investigate it. But provided that I suffer from severe time
constraints this season, my report will not be in depth (for now).

>     As I'm not able to estimate the difficulties/complexity of such an
>     approach (I'm not familiar with the emacs internals),
> Unfortunately, I know nothing about what these interfaces look like.
> You know only one half of the situation, and I know only the other
> half.  It isn't feasible for me to browse a web site--could you email me
> the text that describes the interface?

The KTextEditor "Interface" (actually it is a namespace with lots of
interfaces), is located here:

More specifically, KTextEditor::EditInterface
(which is the most important), is presented here (just to get an idea of what 
it looks

    *  EditInterface ()
    * virtual  ~EditInterface ()
    * unsigned int  editInterfaceNumber () const
    * virtual QString  text () const //the complete document as a single QString
    * virtual QString  text ( unsigned int startLine, unsigned int startCol, 
unsigned int endLine, unsigned int endCol ) const
    * virtual QString  textLine ( unsigned int line ) const // All the text 
from the requested line.
    * virtual unsigned int  numLines () const // The current number of lines in 
the document
    * virtual unsigned int  length () const //the number of characters in the 
    * virtual int  lineLength ( unsigned int line ) const //the number of 
characters in the line (-1 if no line "line")
    * virtual bool  setText ( const QString &text ) 
    * virtual bool  clear () // clears the document
    * virtual bool  insertText ( unsigned int line, unsigned int col, const 
QString &text )
    * virtual bool  removeText ( unsigned int startLine, unsigned int startCol, 
unsigned int endLine, unsigned int endCol )
    * virtual bool  insertLine ( unsigned int line, const QString &text )
    * virtual bool  removeLine ( unsigned int line )
    * virtual void  textChanged ()
    * virtual void  charactersInteractivelyInserted (int ,int ,const QString&) 
// not sure

Note that QString is a normal string class that can be
converted/constructed to/from a C string or a C++ std::string.

Also note that NOT all of the KTextEditor interfaces *should* be
implemented. For example the KTextEditor::ConfigInterface could be
ommited in favor of the emacs internal configuration system (I don't
know what it is called).

Please, tell me whether something is not clear or you need further
information on something.

Thank you,

 Object-oriented programming is an exceptionally bad 
idea which could only have originated in California.
    - Edsger Dijkstra (attributed)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]