From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Giannis Georgalis Newsgroups: gmane.emacs.devel Subject: Re: porting GNU Emacs to kde (?) Date: 19 Mar 2004 16:05:10 +0200 Organization: University of Crete Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <873c852aqx.fsf@hciat-16.ics.forth.gr> References: <878yi9r9go.fsf@isis.myth> Reply-To: jgeorgal@uoc.gr NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079706317 21345 80.91.224.253 (19 Mar 2004 14:25:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Mar 2004 14:25:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 19 15:25:12 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4Kvw-0003bO-00 for ; Fri, 19 Mar 2004 15:25:12 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4Kvw-0005B2-00 for ; Fri, 19 Mar 2004 15:25:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4Kvg-0007Dq-NT for emacs-devel@quimby.gnus.org; Fri, 19 Mar 2004 09:24:56 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4KsX-0006GT-6I for emacs-devel@gnu.org; Fri, 19 Mar 2004 09:21:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4Kl2-0004Ti-QO for emacs-devel@gnu.org; Fri, 19 Mar 2004 09:14:28 -0500 Original-Received: from [139.91.157.50] (helo=mailhost.ics.forth.gr) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4KXp-0002Pa-4g; Fri, 19 Mar 2004 09:00:17 -0500 Original-Received: from hciat-16.ics.forth.gr (localhost [127.0.0.1]) by mailhost.ics.forth.gr (8.12.10/ICS-FORTH/V10-Server-1.0) with ESMTP id i2JE09tR005405; Fri, 19 Mar 2004 16:00:09 +0200 (EET) Original-Received: from localhost ([127.0.0.1] helo=hciat-16.ics.forth.gr) by hciat-16.ics.forth.gr with esmtp (Exim 3.36 #1 (Debian)) id 1B4KcY-0004dL-00; Fri, 19 Mar 2004 16:05:10 +0200 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20609 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20609 Richard Stallman 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)