Re: new Desktop::Editor

[James Aylett <dj-gnome insigma com>]

On Tue, Sep 21, 1999 at 02:09:50AM +0200, Martijn van Beers wrote:

> I finally came up with a new Desktop::Editor interface that
> will hopefully comply with everybody's wishes.

[snip]

> #ifndef __DESKTOP_EDITOR_IDL__
> #define __DESKTOP_EDITOR_IDL__
> 
> module Desktop {
> 
> 	/* This interface is intended as an add-on to GNOME::Stream
> 	 */
> 	interface EditorStream : GNOME::Unknown {
> 		typedef long SearchOption;
> 		/* whether the search-string is a regexp */
> 		const SearchOption SEARCH_REGEX = 1;

Which breed of regexps is being mandated here?

> 		/* whether to ignore case while searching */
> 		const SearchOption SEARCH_ICASE = 2;
> 		/* whether to search backwards */
> 		const SearchOption SEARCH_REVERSE = 4;
> 		/**
> 		 * search:
> 		 * @regexp: the string or POSIX regexp to find
                                          -----
Ah. Okay, sorry :)

> 		 * @whence: scroll from where

"Search from where", I think :)

> 		 * @flags: Options modifying the search
> 		 *
> 		 * lets you search for a string in the stream. The read/write
> 		 * pointer for the Stream is set to the position of the
> 		 * found string.

Presumably the start of the first found string? Is it the start or end of
the found string while searching backwards?

>                  The search-string can optionally be a
> 		 * regular expression (Editors do not have to support this)

I think this is slightly the wrong way to do it, for reasons I can't quite
put my finger on. Possibly I'm misunderstanding - if the EditorStream's
read/write position doesn't reflect the editor's user write/read position,
then it's not really a problem. If it _does_, then changing it on a search
is not an side-effect I'd like to pay.

I guess what I'm asking is for is clarification about the separation between
the EditorStream and the UI editor.

> 		 * Returns TRUE if there was a match and FALSE if there wasn't
> 		 */
> 		 boolean search (in string       regexp,
> 		                 in SEEKFROM     whence,
> 		                 in SearchOption flags);
> 	}
> 	/* This interface should also implement the GNOME::PersistFile
> 	 * and GNOME::PersistStream interfaces
> 	 */
> 	interface Editor : GNOME::Unknown {
> 		/* whether the file is visible in any window */
> 		attribute boolean visible;
> 
> 		/**
> 		 * access_as_stream:
> 		 *
> 		 * Returns a GNOME::Stream/Desktop::EditorStream hybrid object
> 		 * through which you can * manipulate the contents of the editor.
> 		 */
> 		Object access_as_stream (void);
> 
> 		/**
> 		 * scroll_pos:
> 		 * @offset: how much to scroll
> 		 * @whence: scroll from where
> 		 *
> 		 * This method allows you change the position of the cursor

Erm ... the name is inaccurate, in my opinion. You're not scrolling
anything, necessarily; you're changing the position of the cursor (as
stated). Scrolling I associate with scrollbars and views onto canvas-like
objects ...

> 		 * in the editor window on a character basis.

What about binary editors (ghex et al)? Or aren't we supporting them here?
Phrasing it as "atomic unit" rather than "character" would more or less
clear that up, although it's not perfect - because you need to know how the
particular Editor instance you've got for this file is going to operate on
this file.

It might be that the best thing here is to avoid non-textual editing.

> 		 */
> 		void scroll_pos (in long     offset,
> 		                 in SEEKFROM whence) raises OutOfRange);

Is that the right number of brackets? (Warning: I don't actually speak IDL
that fluently :-)

> 		/**
> 		 * scroll_pos:
> 		 * @offset: how much to scroll
> 		 * @whence: scroll from where
> 		 *
> 		 * This method allows you change the position of the cursor
> 		 * in the editor window on a line basis.
> 		 */
> 		void scroll_line (in long     offset,
> 		                  in SEEKFROM whence) raises (OutOfRange);

Logical line or physical line? (Where I use logical line to typically
describe an entire hard line - ended by \n, \r or whatever dependent on the
file/editor, and physical line to describe a single horizontal line on the
editor display.) The latter makes more sense (since it allows you, with the
scroll_pos() method, to implement the equivalent of the cursor keys, from
the calling application).

In fact, unless the Editor interface contained a way of inserting text
'through' the user's view on the file (rather than via the EditorStream
interface), you don't need to be able to move around the logical lines. As I
understand it, though, the old Desktop::Editor did indeed allow this.

Please forgive me if I'm talking rubbish; I've only just got up :)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                           www.zap.uk.eu.org
  james@tartarus.org                                    www.footlights.org