Hi,
> on a first glance it looks possible to fulfill the required features
> below.
That is good news.
> A few questions though:
> >
> > - Accessibility support
>
> Which gtk/atk interfaces have to be implemented in particular?
Basically, when I say a11y support is needed in gtkmozedit, I am m
On 10/18/05, Kaushal Kumar <[EMAIL PROTECTED]> wrote:
> Hi,
Hi,
on a first glance it looks possible to fulfill the required features
below. A few questions though:
> Some of my thoughts on replacement of gtkhtml with gecko
> (gtkmozembed/gtkmozedit).
>
> The basic set of features which would be
All-
From a System Administrator perspective, I would be concerned about the following things:
- Performance of this change to remote DISPLAY Xservers (keystroke speed, scrolling speed).
- Performance on Xservers with no RENDER extension (still lots of those devices out here).
- Performan
Hi,
Some of my thoughts on replacement of gtkhtml with gecko
(gtkmozembed/gtkmozedit).
The basic set of features which would be needed in a gtkhtml replacement
are enumerated below:-
- Accessibility support
- RTL support
- Support for editing html objects like frames, iframes, etc.
- Support for
On Mon, 2005-10-17 at 09:37 +0200, Philip Van Hoof wrote:
Hi,
> I understand your concerns.
> I haven't yet spoken Harish about this attempt. As you probably know
> he's on (or was on) vacation so I'm guessing we'll discuss this soon?
>
I am back :-)
> Perhaps we should address this at a next E
On Mon, 2005-10-17 at 02:49 +0300, Tor Lillqvist wrote:
> On sö, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote:
> > There's however a few issues and things to add:
>
> One more point is that switching GtkMozEmbed will require an unknown
> amount of work on the Win32 platform. It might be (relat
On sö, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote:
> There's however a few issues and things to add:
One more point is that switching GtkMozEmbed will require an unknown
amount of work on the Win32 platform. It might be (relatively) trivial,
or it might be quite difficult. I really can't say
Using my latest patch it's assured that the EMsgComposer struct members
are no longer used outside the e-msg-composer.c file. Therefore it's
safe to re-implement everything in the file.
However. Not everything should be reimplemented. Some routines are not
dependent on the editor component:
