Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 mainly referring to the following: - The atk relation must be established between all the widgets (toolbar, menubar, any other widget) so that gnopernicus, speech reader, etc. can use them. - The main text editing widget should have an atk interface. i.e. so the typed typed is continuously readable by speech reader. For further information, you might want to get in touch with Nagappan ( [EMAIL PROTECTED] ), who works in a11y based LDTP project. A mailing list useful for this type of development is: http://mail.freestandards.org/mailman/listinfo/accessibility-atspi I believe few IBM and Sun guys are already working in mozilla a11y project so they could give some valuable inputs too, in making gtkmozedit a11y enabled. A peek into epiphany browser, which is a11y enabled, and is based on gtkmozembed, might be helpful too. I have not described the a11y requirements for rendering part of gtkhtml, since we are focusing on editing for now. > > > - RTL support > > - Support for editing html objects like frames, iframes, etc. > > - Support for emacs keybindings. > > That's probably tedious. Maybe some kind of standalone > filter/translator could be created so this peace of could would be > reusable with other widgets (by attaching it, conceptually similar to > a GtkEntryCompletion) Actually, gtkhtml does all the above locally and does not use any plugins, or standalone utils, so I am not sure of some alternative. > > > - Support for preview and print. > > - Support for html embedded objects. > > - Support for cut/copy-paste, drag-n-drop. > > - Support for images and animations. > > What kind of animations? animated gif?, flash? Mainly gif animation is needed. Flash isn't supported by gtkhtml. > > > - Support for undo-redo. > > - Support for IM. > > - Text justification > > - Find/Replace > > - Dictionary interface > > - Link handling > > - Sub-parts of evolution like calender, tasks, addressbook interact with > > gtkhtml for their stream display. > Please feel free to mail me or catch me on irc (nick: ksh) for any other inputs I could provide. Thanks, Kaushal ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 needed in a gtkhtml replacement > are enumerated below:- > > - Accessibility support Which gtk/atk interfaces have to be implemented in particular? > - RTL support > - Support for editing html objects like frames, iframes, etc. > - Support for emacs keybindings. That's probably tedious. Maybe some kind of standalone filter/translator could be created so this peace of could would be reusable with other widgets (by attaching it, conceptually similar to a GtkEntryCompletion) > - Support for preview and print. > - Support for html embedded objects. > - Support for cut/copy-paste, drag-n-drop. > - Support for images and animations. What kind of animations? animated gif?, flash? > - Support for undo-redo. > - Support for IM. > - Text justification > - Find/Replace > - Dictionary interface > - Link handling > - Sub-parts of evolution like calender, tasks, addressbook interact with > gtkhtml for their stream display. Best regards, Rob gtkmozedit maintainer ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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). - Performance without XShm, shared memory because it's no longer on the system console/video card. - Endian issues from Intel-->RISC, and the opposite as well when using remote DISPLAY. (there are some sections in the Beagle Best UI that don't display correctly on RISC devices). My suggestion if appropriate would be to build a small composer window only, and let people test it on various hardware and network configurations. I can test all of the above items here for you. I would say that composing email is kind of an important thing in an email package and we all know that sometimes things come up when tested with diverse hardware. Dave On Tue, 2005-10-18 at 16:22 +0530, Kaushal Kumar wrote: 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 emacs keybindings. - Support for preview and print. - Support for html embedded objects. - Support for cut/copy-paste, drag-n-drop. - Support for images and animations. - Support for undo-redo. - Support for IM. - Text justification - Find/Replace - Dictionary interface - Link handling - Sub-parts of evolution like calender, tasks, addressbook interact with gtkhtml for their stream display. Some of the above, as I understand, can be implemented via the command manager of the gecko editor, whereas, others might need little more work, which is not a problem. What is more important is implementing all the requirements finally, and for now, determining if gecko editor provides a platform for achieving it, or not. As pointed out on irc yesterday, gtkhtml is buggy. But then, which module is not? That may not be a reason good enough for it's replacement, unless we have met a dead end and the open bugs are not fixable [1]. However, if mozilla technology promises a better user experience at face value, then it is worth the migration. GtkHTML does not support CSS, DOM as yet. This could be because it was designed to be a lightweight mail editor/renderer, in the first place. However, if mails use CSS more now, it would be useful to add it. To do this, we could either simply add it's support; or, we could try using gtkmozembed for rendering (on similar lines of epiphany). The editing part could still be left to gtkhtml (or maybe a scaled down version of gtkhtml). I would like to re-affirm that I too favor switching to gtkmoz*, if we could create a plan/design, to fill-up for the existing gtkhtml features, along with that of adding new ones. Since I have not much expertise in mozilla-related stuff, someone else could do this analysis and I could help by reviewing it. Philip's initial investigation on the replacement plan is a very good start (thanks for the wiki page on the same). I admire and appreciate Rob's gtkmozedit work. I would be glad to pitch-in all help possible, from my side. Cheers, Kaushal [1]: I would appreciate if someone could send me a list of those gtkhtml bugs which he/she considers to be critical that it hampers their work. -- Kaushal Kumar <[EMAIL PROTECTED]> On Sun, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote: > 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: > > - All the methods that are related to headers > - The "mailto:" parser and handlers > - Attachment handling > - GObject creation and boilerplate code > > Other parts are dependent on the editor component or visa versa. Parts > like: > > - Message body handling (full replacement) > - Inline image handling (partial replacement) > - PGP handling (partial replacement) > - MIME handling (full replacement) > - Signature handling (partial replacement) > > It's untrue that there's no more maintenance for the HTML editor > component if we'd switch to GtkMozEdit. However, there's a developer > (Robert Staudinger) doing it at this moment. And it's far less code > to maintain (since most of the code is GtkMozEmbed and, of course, > Gecko). There's however a few issues and things to add: > > - You can only start using the GtkMozEdit (and GtkMozEmbed) > widget after realizing it is completed. This does take a > certain amount of time (mainly the firs time) and is difficult > to detect in the code (it's a signal). Some parts of evolution > perform methods on the newly created EMs
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 emacs keybindings. - Support for preview and print. - Support for html embedded objects. - Support for cut/copy-paste, drag-n-drop. - Support for images and animations. - Support for undo-redo. - Support for IM. - Text justification - Find/Replace - Dictionary interface - Link handling - Sub-parts of evolution like calender, tasks, addressbook interact with gtkhtml for their stream display. Some of the above, as I understand, can be implemented via the command manager of the gecko editor, whereas, others might need little more work, which is not a problem. What is more important is implementing all the requirements finally, and for now, determining if gecko editor provides a platform for achieving it, or not. As pointed out on irc yesterday, gtkhtml is buggy. But then, which module is not? That may not be a reason good enough for it's replacement, unless we have met a dead end and the open bugs are not fixable [1]. However, if mozilla technology promises a better user experience at face value, then it is worth the migration. GtkHTML does not support CSS, DOM as yet. This could be because it was designed to be a lightweight mail editor/renderer, in the first place. However, if mails use CSS more now, it would be useful to add it. To do this, we could either simply add it's support; or, we could try using gtkmozembed for rendering (on similar lines of epiphany). The editing part could still be left to gtkhtml (or maybe a scaled down version of gtkhtml). I would like to re-affirm that I too favor switching to gtkmoz*, if we could create a plan/design, to fill-up for the existing gtkhtml features, along with that of adding new ones. Since I have not much expertise in mozilla-related stuff, someone else could do this analysis and I could help by reviewing it. Philip's initial investigation on the replacement plan is a very good start (thanks for the wiki page on the same). I admire and appreciate Rob's gtkmozedit work. I would be glad to pitch-in all help possible, from my side. Cheers, Kaushal [1]: I would appreciate if someone could send me a list of those gtkhtml bugs which he/she considers to be critical that it hampers their work. -- Kaushal Kumar <[EMAIL PROTECTED]> On Sun, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote: > 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: > > - All the methods that are related to headers > - The "mailto:"; parser and handlers > - Attachment handling > - GObject creation and boilerplate code > > Other parts are dependent on the editor component or visa versa. Parts > like: > > - Message body handling (full replacement) > - Inline image handling (partial replacement) > - PGP handling (partial replacement) > - MIME handling (full replacement) > - Signature handling (partial replacement) > > It's untrue that there's no more maintenance for the HTML editor > component if we'd switch to GtkMozEdit. However, there's a developer > (Robert Staudinger) doing it at this moment. And it's far less code > to maintain (since most of the code is GtkMozEmbed and, of course, > Gecko). There's however a few issues and things to add: > > - You can only start using the GtkMozEdit (and GtkMozEmbed) > widget after realizing it is completed. This does take a > certain amount of time (mainly the firs time) and is difficult > to detect in the code (it's a signal). Some parts of evolution > perform methods on the newly created EMsgComposer instance > right after it got created. This would be to early (since the > GtkMozEmbed widget needs to be realized first). > > This problem is deeply embedded in GtkMozEmbed (perhaps even > deeper, in Gecko). So it's not something that can be easily > fixed in GtkMozEdit. > > - GtkMozEdit doesn't yet support the exact same amount of > "commands" as the GtkHTML component does. A lot of the > "commands" need to be reimplemented. > > - GtkMozEdit, however, does support DOM. Which will become > very useful (using DOM you can access the HTML nodes > individually and stuff like that). > > Unlike GtkHTML, the GtkMozEdit doesn't have "Bold", "Italic" etcetera > buttons. So a new widget should probably be created that adds this to > GtkMozEdit (this is trivial). > > GtkMozEdit by default uses the default theme of Mozilla (for
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 Evolution meeting? > Yes. Let us thrash it out this Wednesday (1000 UTC) I will try to ensure all stakeholders (ksh, mailer guys ..) make it to the meeting. > because I'm not yet sure whether or not the Gecko HTML engine is > desirable in Evolution. Well, let us be open and evaluate it nevertheless. We would know, after the analysis :-) > What I've done so far is the Prove Of Concept :-P > Yes. There are many gaps that still need to be fixed. (http://go-evolution.org/Thoughts_and_ideas_to_replace_gtkhtml_with_gtkmozembed#Difficulties) > Important for Harish to know is that replacing GtHTML with Gecko > wouldn't be a one-person task. The entire team of Evolution developers > will most likely one way or another touch or feel the differences. As I had hinted to you earlier, Kaushal (the current gtkhtml maintainer) would be your most valuable ally for both evaluating the replacement as well as working on it. I am biased of course, to the option of making it a bonobo component (reimplement Editor.idl) in that it would be the least disruptive to the rest of the code. Configure time selection would make me happier - so we could do the 'field-tests' with the safety net of falling back to gtkhtml editor during the development releases. But then lets see the show of hands on how many of us can throw in the commitment to see it through.[1] > Like > you, Tor, who would have to port this to Win32. > > So it's good to discuss this :P > Tor/ srag , mostly. Cheers, Harish [1] Kaushal, Philip has already provided his analysis including what he sees as trouble spots in the task. Can you post your views too - so the rest of the team is prepared for the meeting. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 (relatively) trivial, > or it might be quite difficult. I really can't say yet. How likely is it > that the switch will happen? Would it be feasible to keep support for > both gtkhtml and gtkmozembed in the code, and have them selectable at > configure time? Hey Tor, 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? Perhaps we should address this at a next Evolution meeting? The GtkMozEdit looks as portable as GtkMozEmbed. Since GtkMozEdit does not add any extra (strange) dependencies and it's code looks not abnormal nor strange (It's a standard GObject/Gtk+ widget that inherits from GtkMozEmbed). It does link with libstdc++ but so does GtkMozEmbed. So if GtkMozEmbed is portable to Win32, GtkMozEdit is also portable. My plan is to move as much functionality that is now present in the GtkHTML (editor) component back into EMsgComposer and to create as few direct links to the editor component as possible. And by that making the editor component replaceable. But I haven't yet started this work because I'm not yet sure whether or not the Gecko HTML engine is desirable in Evolution. What I've done so far is the Prove Of Concept :-P Important for Harish to know is that replacing GtHTML with Gecko wouldn't be a one-person task. The entire team of Evolution developers will most likely one way or another touch or feel the differences. Like you, Tor, who would have to port this to Win32. So it's good to discuss this :P -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
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 yet. How likely is it that the switch will happen? Would it be feasible to keep support for both gtkhtml and gtkmozembed in the code, and have them selectable at configure time? --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
