porting GNU Emacs to kde (?)

porting GNU Emacs to kde (?)

[Giannis Georgalis]

Hello !

I was thinking of trying to port GNU Emacs to the KDE[1] environment
in the near future. The main incentive for this decision, is my
desire to start using kdevelop[2] as my IDE (which is impossible
without Emacs ;-)). This is possible in KDE (and kdevelop in specific)
through the KPart[3] interface. This roughly means that Emacs should
become a shared object and export some functionality that implements a
well defined Editor interface. This way, Emacs can be used throughout
the KDE environment WHEREVER an editor is needed[4].

This is quite a complex task. And as I see it, it could be done in
two steps:
a) Make Emacs use the kde libraries as done with the gtk2 port.
b) "Organize" Emacs in a way that it can elegantly implement the
Editor interface mentioned above.

Note, that I'm familiar with the effort of Marco Correia (that also
send a mail to this list with a similar context), who begun (but
stopped eventually) to implement an Emacs KPart[3], using the
emacs-server interface.
Though Marco's approach (as he told me) is possible, IMHO it is
better to follow the former method because it can achieve far better
integration with the kde environment, while implementing all the
necessary "hooks" (and knowledge/code base) for a similar integration
with the GNOME environment (ORBit(?)), which I suspect, follows a
similar pattern.

As I'm not able to estimate the difficulties/complexity of such an
approach (I'm not familiar with the emacs internals), I firstly would
like to ask your opinion on the above matters and whether you think
this whole project would be useful from the "Emacs perspective".
Lastly, are there any other parameters, that would make this project
more difficult/impossible (eg. policy / ideological issues)?

Thank you,
Giannis

References:

[1] http://www.kde.org
[2] http://kdevelop.org
[3] http://en.wikipedia.org/wiki/KPart
[4] see also vimpart.

-- 
question = ( to ) ? be : ! be;
                -- Wm. Shakespeare

porting GNU Emacs to kde (?)

[Giannis Georgalis]

Hello !

I was thinking of trying to port GNU Emacs to the KDE[1] environment
in the near future. The main incentive for this decision, is my
desire to start using kdevelop[2] as my IDE (which is impossible
without Emacs ;-)). This is possible in KDE (and kdevelop in specific)
through the KPart[3] interface. This roughly means that Emacs should
become a shared object and export some functionality that implements a
well defined Editor interface. This way, Emacs can be used throughout
the KDE environment WHEREVER an editor is needed[4].

This is quite a complex task. And as I see it, it could be done in
two steps:
a) Make Emacs use the kde libraries as done with the gtk2 port.
b) "Organize" Emacs in a way that it can elegantly implement the
Editor interface mentioned above.

Note, that I'm familiar with the effort of Marco Correia (that also
send a mail to this list with a similar context), who begun (but
stopped eventually) to implement an Emacs KPart[3], using the
emacs-server interface.
Though Marco's approach (as he told me) is possible, IMHO it is
better to follow the former method because it can achieve far better
integration with the kde environment, while implementing all the
necessary "hooks" (and knowledge/code base) for a similar integration
with the GNOME environment (ORBit(?)), which I suspect, follows a
similar pattern.

As I'm not able to estimate the difficulties/complexity of such an
approach (I'm not familiar with the emacs internals), I firstly would
like to ask your opinion on the above matters and whether you think
this whole project would be useful from the "Emacs perspective".
Lastly, are there any other parameters, that would make this project
more difficult/impossible (eg. policy / ideological issues)?

Thank you,
Giannis

References:

[1] http://www.kde.org
[2] http://kdevelop.org
[3] http://en.wikipedia.org/wiki/KPart
[4] see also vimpart.

-- 
question = ( to ) ? be : ! be;
                -- Wm. Shakespeare

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

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.

    Though Marco's approach (as he told me) is possible, IMHO it is
    better to follow the former method because it can achieve far better
    integration with the kde environment, while implementing all the
    necessary "hooks" (and knowledge/code base) for a similar integration
    with the GNOME environment (ORBit(?)), which I suspect, follows a
    similar pattern.

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.

    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?

Re: porting GNU Emacs to kde (?)

[Masatake YAMATO]

> I was thinking of trying to port GNU Emacs to the KDE[1] environment
> in the near future. The main incentive for this decision, is my
> desire to start using kdevelop[2] as my IDE (which is impossible
> without Emacs ;-)). This is possible in KDE (and kdevelop in specific)
> through the KPart[3] interface. This roughly means that Emacs should
> become a shared object and export some functionality that implements a
> well defined Editor interface. This way, Emacs can be used throughout
> the KDE environment WHEREVER an editor is needed[4].

How about d-bus[1]?
I think it would be gnome<->kde neutral way.
Once emacs side d-bus interface is completed, you can do what
you want in elisp. I guess drag-and-drop support code added to
emacs recently is good place to start.

[1] http://dbus.freedesktop.org/

Masatake YAMATO

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

    How about d-bus[1]?
    I think it would be gnome<->kde neutral way.

Can someone explain to me what d-bus does,
or else send me a few pages from http://dbus.freedesktop.org/
which would tell me?

Re: porting GNU Emacs to kde (?)

[Masatake YAMATO]

>     How about d-bus[1]?
>     I think it would be gnome<->kde neutral way.
> 
> Can someone explain to me what d-bus does,
> or else send me a few pages from http://dbus.freedesktop.org/
> which would tell me?

Copy and paste'ed from http://dbus.freedesktop.org/

    D-BUS is a message bus system, a simple way for applications to talk
    to one another.

    D-BUS supplies both a system daemon (for events such as "new hardware
    device added" or "printer queue changed") and a per-user-login-session
    daemon (for general IPC needs among user applications). Also, the
    message bus is built on top of a general one-to-one message passing
    framework, which can be used by any two apps to communicate directly
    (without going through the message bus daemon).

    The D-BUS API isn't finished yet, and the design is by no means set in
    stone. One of our main goals is for lots of projects to use it, so if
    you wouldn't use it, by all means mail us and say why - design,
    licensing, indentation style, we would rather know than not know.

    D-BUS has no required dependencies, but includes GLib and Qt APIs to
    the D-BUS system, if you want to build those.

    Trying out D-BUS in sample applications is encouraged - we want to get
    it widely used and tested. It should be working pretty well these
    days, and when it isn't bug reports are very welcome.

    Get on D-BUS today!

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

I don't follow how D-BUS relates to the issue of supporting Qt.

Re: porting GNU Emacs to kde (?)

[Masatake YAMATO]

> I don't follow how D-BUS relates to the issue of supporting Qt.

I'll try to explain. I'm not an expert. If what I write is wrong, 
please correct me.

You wrote in another mail about this issue:
> 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.
>
>     Though Marco's approach (as he told me) is possible, IMHO it is
>     better to follow the former method because it can achieve far better
>     integration with the kde environment, while implementing all the
>     necessary "hooks" (and knowledge/code base) for a similar integration
>     with the GNOME environment (ORBit(?)), which I suspect, follows a
>     similar pattern.
>
> 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.

With D-BUS, Emacs can support both GNOME and KDE in minimal effort.

Currently ORBit/Bonobo(?) is used in Gnome; and KPart(?) is used in KDE
as high level IPC mechanisms. In other hand D-BUS is desktop neutral 
high level IPC mechanism. 

Supporting ORBit/Bonobo in Emacs stands for integrating Emacs with
GNOME.  Supporting KPart in Emacs stands for integrating Emacs with
KDE. For each desktop, one high level IPC mechanism must be supported
in Emacs(and at least one voluntee is needed). In other hand, supporting
D-BUS in Emacs stands for integrating Emacs with both GNOME and KDE at
once.

Masatake YAMATO

Re: porting GNU Emacs to kde (?)

[Danilo Segan]

Hi,

Masatake YAMATO <jet@gyve.org> writes:

>> 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.
>
> With D-BUS, Emacs can support both GNOME and KDE in minimal effort.
>
> Currently ORBit/Bonobo(?) is used in Gnome; and KPart(?) is used in KDE
> as high level IPC mechanisms. In other hand D-BUS is desktop neutral 
> high level IPC mechanism. 

Actually, D-BUS is *simple* IPC mechanism.  It was not designed to
replace CORBA in the Gnome platform.  Also, CORBA is not used only
for IPC in Gnome, so D-BUS is a non-contender there.  D-BUS was
designed to provide simple IPC mechanism where CORBA is overkill
(i.e. harder than necessary).

D-BUS doesn't provide anything on par with component mechanism
provided by Bonobo (or, I guess, DCOP/KParts).  Both Bonobo and
KParts are implemented over their respective IPCs, so it doesn't make
too much sense to reimplement it all.

> Supporting ORBit/Bonobo in Emacs stands for integrating Emacs with
> GNOME.  Supporting KPart in Emacs stands for integrating Emacs with
> KDE. For each desktop, one high level IPC mechanism must be supported
> in Emacs(and at least one voluntee is needed). In other hand, supporting
> D-BUS in Emacs stands for integrating Emacs with both GNOME and KDE at
> once.

Yeah, if D-BUS was ever able to handle that (without significant work
of reimplementing everything, which would be silly).  I don't see
myself how could it be related.  It was never designed to be able to
replace things like Bonobo and KParts.

Cheers,
Danilo

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

Richard Stallman <rms@gnu.org> 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
"minimal".

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:
http://developer.kde.org/documentation/library/3.0-api/classref/interfaces/KTextEditor.html

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

    *  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 document
    * 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,
Giannis

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

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

Danilo Segan <dsegan@gmx.net> writes:

> Yeah, if D-BUS was ever able to handle that (without significant work
> of reimplementing everything, which would be silly).  I don't see
> myself how could it be related.  It was never designed to be able to
> replace things like Bonobo and KParts.

Exactly. Besides doesn't Emacs already have Its own IPC mechanism ?

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

Re: porting GNU Emacs to kde (?)

[David Kastrup]

Giannis Georgalis <jgeorgal@uoc.gr> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > 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 "minimal".

Yes.  Personally, I don't understand RMS' "it would not be right for
Emacs to have more support for KDE than for GNOME" mostly as an
admonition that one should not proceed hastily towards a KDE solution
and later find that one made design decisions that complicate
integrating Emacs into GNOME.  But that would certainly hold to a
certain degree also the other way round.  I don't think that one
should require any KDE coder interested in that project to work slower
or worse than her GNOME counterpart.  The situation would be
embarrassing, yes, but that would not be the fault of KDE.

My project preview-latex has had a renderer utility dvipng written
specifically for it (after I fantasized how nice that would be to
have), starting over a year ago, and only now have I been able to
properly integrate it.  In the meantime, this utility has been used
for quite a few other projects, including competing ones.  The
situation was embarrassing, but keeping stuff under lock in order to
save the embarrasment would have benefited nobody.

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

Does anybody know whether any of the hardcore GNOME hackers have Emacs
exposure or could be interested for taking a look?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

    With D-BUS, Emacs can support both GNOME and KDE in minimal effort.

    Currently ORBit/Bonobo(?) is used in Gnome; and KPart(?) is used in KDE
    as high level IPC mechanisms. In other hand D-BUS is desktop neutral 
    high level IPC mechanism. 

Support for GTK required many changes in the Emacs display code.
I presume support for Qt would also require many such changes.
That is where the work is.

I don't know if Emacs works with Bonobo.  I am not sure whether that
is important.  What features would we get by making Emacs work with
Bonobo?

Re: porting GNU Emacs to kde (?)

[Danilo Segan]

David Kastrup <dak@gnu.org> writes:

> Does anybody know whether any of the hardcore GNOME hackers have Emacs
> exposure or could be interested for taking a look?

I believe many of the (hard)core GNOME hackers *use* Emacs for their 
work.  I don't know how many of them (if at all) are actually
interested in working on this.  Perhaps asking them directly (using
gnome-list@gnome.org, I believe) would be the best option?

Gnome also comes with gtksourceview widget which is used by stuff like
gedit (a [not so] simple text-editor provided by Gnome).  If someone
would take a closer look at it, it would probably be nice if they
could create an Emacs-widget which would be mostly (source-code)
compatible with it.

Emacs Bonobo component, OTOH, would allow Emacs to be embedded even
in programs like Mozilla (look for mozilla-bonobo project), and many
other Bonobo-aware 'containers' (Nautilus comes to mind).  Those are
the advantages of having Bonobo components.

Cheers,
Danilo

Re: porting GNU Emacs to kde (?)

[mr mike]

> Gnome also comes with gtksourceview widget which is used by stuff like
> gedit (a [not so] simple text-editor provided by Gnome).  If someone
> would take a closer look at it, it would probably be nice if they
> could create an Emacs-widget which would be mostly (source-code)
> compatible with it.
> 
> Emacs Bonobo component, OTOH, would allow Emacs to be embedded even
> in programs like Mozilla (look for mozilla-bonobo project), and many
> other Bonobo-aware 'containers' (Nautilus comes to mind).  Those are
> the advantages of having Bonobo components.
> 
> Cheers,
> Danilo
> 

If emacs had a way to start it unmapped like xemacs, this probably would
not be hard at all.  if emacs was not already up, we could fork it in
the background and then use gnuserv to send it a create-frame call with
a GtkSocket id to draw to.

there was a gnomacs project a couple of years ago that showed something
like this.  the only problem is that it required an already running
emacs to create the frame.

i've looked into the source of gnomacs some on and off and i've also
looked a the gtk emacs port some to see how hard it would be.  actually
embedding the frame does not look hard at all.

native d-bus support for evaluating lisp commands would make
communicating with the running emacs process much easier.

mike

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

David Kastrup <dak@gnu.org> writes:

Hello David,

> Yes.  Personally, I don't understand RMS' "it would not be right for
> Emacs to have more support for KDE than for GNOME" mostly as an
> admonition that one should not proceed hastily towards a KDE solution
> and later find that one made design decisions that complicate
> integrating Emacs into GNOME.  But that would certainly hold to a
> certain degree also the other way round.  I don't think that one
> should require any KDE coder interested in that project to work slower
> or worse than her GNOME counterpart.  The situation would be
> embarrassing, yes, but that would not be the fault of KDE.

I fully understand the claim that a KDE port that precedes the GNOME
effort may impose certain difficulties to the later. RMS was right to
point that out. Apart from the "embarrassing" factor, Emacs would be
filled with nasty hacks in order to be able to support both designs
and that's not good.

I personally would be very interested in working to that direction
(making Emacs a Component(TM)) (time permitting of-course). I'm not
in any way affiliated with KDE nor GNOME, so what I had in mind was a
combined effort with the same code-base that would make both the KDE
and the GNOME port easier for the following reasons:

1) No duplication of efforts.
2) A more elegant design that will support both GNOME and KDE without
imposing maintainability problems to the Emacs code base.
3) I'm not at all familiar with the Emacs internals, so I was hopping
that a possible cooperation with the GNOME hackers (the ones that
ported Emacs to gtk2), would make the process easier (;-)).

Thank you,
Giannis

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

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

    Yes.  Personally, I don't understand RMS' "it would not be right for
    Emacs to have more support for KDE than for GNOME" mostly as an
    admonition that one should not proceed hastily towards a KDE solution
    and later find that one made design decisions that complicate
    integrating Emacs into GNOME.

This interpretation is not correct.  What I said is that a GNU package
should support GNOME at least as well as it supports any non-GNU
desktop.  The maintainers should not leave it to chance, or to the
actions of others, to control whether this is true.  They should make
sure this is always true.

GNU packages such as GNU Emacs and GNOME are part of a larger project,
the GNU Project.  They should help each other out and support each
other.  If Emacs included support for KDE in ways that it did not
support GNOME, that would be disloyal.  We will not do that.

To maintain a GNU package as if it existed in isolation, as if the
only goal were to make that package good and popular, is to work
towards the wrong goal.  The goal is to make the GNU system good and
popular.  Maintainers should not forget to work together on this.

Re: porting GNU Emacs to kde (?)

[Richard Stallman]

    Gnome also comes with gtksourceview widget which is used by stuff like
    gedit (a [not so] simple text-editor provided by Gnome).  If someone
    would take a closer look at it, it would probably be nice if they
    could create an Emacs-widget which would be mostly (source-code)
    compatible with it.

It would be a very useful thing to modify Emacs so that it can be used
by GNOME programs that want an editor.  If you can find someone who
would like to do this, I will appreciate it.

Re: porting GNU Emacs to kde (?)

[Lars Brinkhoff]

Richard Stallman <rms@gnu.org> writes:
> It would be a very useful thing to modify Emacs so that it can be used
> by GNOME programs that want an editor.

Better yet: every editable text field could be an Emacs buffer.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

Richard Stallman <rms@gnu.org> writes:

> a GNU package should support GNOME at least as well as it supports
> any non-GNU desktop.  The maintainers should not leave it to chance,
> or to the actions of others, to control whether this is true.  They
> should make sure this is always true.
> 
> GNU packages such as GNU Emacs and GNOME are part of a larger project,
> the GNU Project.  They should help each other out and support each
> other.  If Emacs included support for KDE in ways that it did not
> support GNOME, that would be disloyal.  We will not do that.
> 
> To maintain a GNU package as if it existed in isolation, as if the
> only goal were to make that package good and popular, is to work
> towards the wrong goal.  The goal is to make the GNU system good and
> popular.  Maintainers should not forget to work together on this.

As this thread has stalled for a while, I would like to repeat once
more, that if it is decided that an effort to component-ize Emacs
should be started, it should certainly take into consideration GNOME,
KDE and GNUstep. RMS' point is valid and essential for the
interoperability throughout the GNU system, so it goes without saying
(Is it a valid english expression ?)  that it should be respected.

Having clarified the goals for such an effort, I would like to know
if anyone is interested in working towards that direction. Is the
team that ported Emacs to GTK interested in this ? (Jan DjAdrv ?).

Thank you,
Giannis

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

Re: porting GNU Emacs to kde (?)

[Jan D.]

> Having clarified the goals for such an effort, I would like to know
> if anyone is interested in working towards that direction. Is the
> team that ported Emacs to GTK interested in this ? (Jan DjAdrv ?).

My motivation for doing the GTK port in the first place was to make
Emacs a component that GNOME applications could use.  I don't like the
current GNOME editors that exists.  Ditto for KDE by the way.  But I 
still
have other things on my TODO list that I would like to fix first, (some
are GTK related, some not).  I do not know anything about GNUStep or
KParts, but will of course help as much as I can and have time for.

I suspect however, that KParts rely heavily on KDE and Qt libraries, the
same as GNOME components relies on GTK and GNOME libraries.
It will be hard work to make Emacs a general component without linking
in those libraries.  This should be investigated first.

	Jan D.

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

Hello Jan,

"Jan D." <jan.h.d@swipnet.se> writes:

> My motivation for doing the GTK port in the first place was to make
> Emacs a component that GNOME applications could use.  I don't like the
> current GNOME editors that exists.  Ditto for KDE by the way.  But I
> still

Yes. ALL other editors suck ;-).

> have other things on my TODO list that I would like to fix first, (some
> are GTK related, some not).  I do not know anything about GNUStep or
> KParts, but will of course help as much as I can and have time for.

There's no need to hurry. It should be a long term project. You don't
have to know anything about GNUstep or KParts (see bellow).

> I suspect however, that KParts rely heavily on KDE and Qt libraries, the
> same as GNOME components relies on GTK and GNOME libraries.
> It will be hard work to make Emacs a general component without linking
> in those libraries.  This should be investigated first.

I'm not saying we shouldn't link Emacs with KDE/Qt or
GNOME/Bonobo/ORBit libraries. What I'm saying is that we should study
the KTextEditor Interfaces, the GNOME Text Editor CORBA interfaces and
the GNUstep's text editor interfaces and finally come up with
independent interfaces that would be a superset of the above three
and implement them. Then, each specific implementation
(GNOME/KDE/GNUstep) will just implement some text editor lightweight
interfaces that will only delegate their functionality to the general
interface that should be common.

As for the port of the GUI components of Emacs, a general, toolkit
independent, interface that will be implemented seperately by
GNOME/KDE/GNUstep, should make the porting job easier. I suspect you
have done something like this through your efforts to port Emacs to
GTK, didn't you ?

Please, tell me if I'm missing / oversimplifying / misunderstood
something.

Thank you,
Giannis

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

Re: porting GNU Emacs to kde (?)

[Jan D.]

>
> As for the port of the GUI components of Emacs, a general, toolkit
> independent, interface that will be implemented seperately by
> GNOME/KDE/GNUstep, should make the porting job easier. I suspect you
> have done something like this through your efforts to port Emacs to
> GTK, didn't you ?

No.  It was descided that the effort was not worth it.  If you look at
the code you will see that the W32, Mac, Xt, GTK and X ports of
Emacs are separate with different ifdefs.  Some common code does
exist, but there is no general toolkit independent interface.

Which is probably a good thing for GTK.  GTK is very unfriendly when
it comes to integrate into existing applications, so making first
a toolkit independent interface and then a GTK adaption to that 
interface
would surely increased the amount of code by a factor of 3 or 4.

	Jan D.

Re: porting GNU Emacs to kde (?)

[Giannis Georgalis]

Hi Jan,

"Jan D." <jan.h.d@swipnet.se> writes:

> No.  It was descided that the effort was not worth it.  If you look at
> the code you will see that the W32, Mac, Xt, GTK and X ports of
> Emacs are separate with different ifdefs.  Some common code does
> exist, but there is no general toolkit independent interface.
> 
> Which is probably a good thing for GTK.  GTK is very unfriendly when
> it comes to integrate into existing applications, so making first
> a toolkit independent interface and then a GTK adaption to that
> interface
> would surely increased the amount of code by a factor of 3 or 4.

Ok, that's fine. (although it should be a nightmare maintainance-wise
&& too many ifdefs are evil).

Is there any documentation or other resources describing the Emacs
GUI API (or the source is my friend ? ;-)).

Now, provided that you have not commented on the general "text editor
interface api", should I assume that you agree with this approach ?
If you do, I can begin (during the easter holiday probably)
designing a first draft of the api... (I would appreciate a link to
the text editor GNOME CORBA interfaces).

Thank you,
Giannis

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

Re: porting GNU Emacs to kde (?)

[Jan D.]

>
> Is there any documentation or other resources describing the Emacs
> GUI API (or the source is my friend ? ;-)).

There isn't any GUI API as such that I know of, just an implementation
so the source is where to look.

>
> Now, provided that you have not commented on the general "text editor
> interface api", should I assume that you agree with this approach ?
> If you do, I can begin (during the easter holiday probably)
> designing a first draft of the api... (I would appreciate a link to
> the text editor GNOME CORBA interfaces).

The first thing to do IMHO is getting embedding to work, i.e. put an 
Emacs
window inside Konquerer and/or Nautilus.  I don't think there is a lot
of interface to implement that.  After that one could take a look at
other KDE/GNOME editors and see what they provide.  I do not have
any GNOME links, so you will have too look around on the GNOME web site.

	Jan D.