Page MenuHomePhabricator

Text Features
Updated 1,160 Days AgoPublic

Text Features

Case Study1

Spellchecker

Let’s you know when words are misspelled by highlighting the misspelled text/auto correcting the misspelled text as and when its typed or providing a set of corrected word options to choose from and also allows to check the whole document for misspelled words.
This feature mostly depends on editable widget (like elm_entry) and can be applied to some extent to non-editable widget (elm_label) as well (only highlight) but to correct words we will need a UI element to show list of corrected words)
Requirement:

  • The input typed in to editable widget, events (like focus out, mouse down, long press, cursor changed) needs to be monitored continuously based on which misspelled words will be highlighted.
  • Spellcheck has to happen asynchronously so that main loop does not get blocked, for which request/callback mechanism is needed.
  • Underlying spellcheck library can be any library and spellchecking can also be a daemon service or a service accessible via only internet hence Module approach is needed.
  • As spellcheck can be done for any language and also considering all language dictionaries might not be available on system, spellcheck will require input from app regarding languages that need spellcheck support so that so many dictionaries if available can be initialized and queried.

Case Study2

Undo/Redo

  • Undo: (ctrl+z): It erases the last change done to the document reverting it to an older state.
  • Redo: (shift+ctrl+z (or) ctrl+y): The redo command reverses the undo.

Requirement:

  • The number of undo/redo supported by a platform has to be a configurable option (via elm_config).
  • Whenever a word is entered in entry or whenever any text is deleted from entry, states to be created and stored in to stack. (need continuous monitoring of text input and cursor change )
  • When undo/redo happens accordingly update the undo/redo pointer access the corresponding data from stack and update entry.
  • The amount of text that needs to be stored in stack can be customized by application.

Designs

Design1

Create the feature as an Interface and let entry inherit from the interface.

Undo/Redo

D3561 - ref code

Pros:

  • Completely bindable.
  • Usage by applications is comparatively simpler and straight forward.
  • The interface can be inherited and implemented by any other widget as well.

Cons:

  • New API additions in Elm_Entry (enabled_set, stack_size_set, (add_to_stack, changed_cb_set)-for custom implementation by application))
    • @raster - REALLY? New APIs are only needed in legacy API. In eo API this implements the api's and you need APIs in a separate undo/redo handler object/helper anyway - so APIs go somewhere regardless. This makes it sound like its *EXTRA* work)
  • Checks needed in functions like entry changed, cursor changed.
    • @raster - What? Separate undo/redo object/helper doesn't also have to listen to these events? As such checks are not needed. Just need to listen to events on self.
  • Callbacks to be implemented in the entry widget to update contents according to contents of undo_redo stack.
    • @raster - you need some kind of glue regardless how you do it - separate object you bind or as an interface, so why is this a con vs. a separate object listener/handler or helper?
    • @shilpasingh - Its about keeping basic editable widget with standard set of editable features and adding other extra text features which are dependent on entry as external entities/objects which glue themselves to the widget. As entry provides required infrastructure needed to implement these features. The discussion is, these kind of features will only increase and these features are mostly kind of helpers to applications, so instead of apps implementing this, we provide apps with all the support needed.
    • @shilpasingh - Looking from maintenance point of view, these features actually depend on entry and entry do not depend on these. Your points listed here are all valid, code has to go somewhere so why not make them as interface and let other widgets inherit from them. we did that but then not much was left in interface, everything went in to entry itself, majorly because these features listen to events of entry and accordingly act and entry do not actually have any dependency on them hence the confusion

Spellchecker

Pros:

  • Completely bindable.
  • Usage by applications is comparatively simpler and straight forward.
  • The interface can be inherited and implemented by any other widget as well like elm_label.

Cons:

  • New API additions in Elm_Spellchecker (enabled_set, recheck_all)
    • @raster - Same comment as above for redo/undo
  • Checks needed in functions like entry changed, cursor changed, focus_out, mouse_down, long_press, double_click).
    • @raster - Same comment as above for redo/undo
  • Cursors maintenance, creation, underlining, updating context menu all this logic has to be moved to elm_entry, only feeding input to module, getting the response will be part of INTERFACE so as to keep the code generic.
    • @raster - How does this code not have to go somewhere anyway - eg in an external object or helper. It has to go somewhere... it's not magically free

Design 2

Undo/redo as a helper

Undo/Redo

D2297 - ref code

Pros:

  • No changes in elm_entry widget, functionalities implemented by connecting to entry’s callbacks.
    • @raster - How is this a pro? the code has to go somewhere. "In helper or spellchecker object. Does it matter if its in entry or not?

Cons:

  • Not bindable
  • Usage by applications comparatively complex as applications have to create helper, connect to callbacks.

Design 3

Spellchecker as a separate Eo object.

Spellchecker

D2575 - Ref code

Pros:

  • Completely bindable.
  • Not a regular feature hence made it attachable to the editable object, No changes in entry widget.
    • @raster - Again - how is this a pro? code has to go somewhere - inside entry or outside in another object. It doesn't save code or changes.
  • As independently implemented, further similar features like look up, synonym, translation, transliteration kind of features also can be independently implemented by using existing infra of elm_entry without any modification of the same.
    • @raster - This can also be done as an interface. The interface just calls the public methods of elm entry on itself ... if you inherit an entry and don't override these methods it all nicely continues to work too, so this isn't a special pro.

Cons:

  • Usage is a bit different not like other usual objects, one of a kind.

@shilpasingh - I referred other frameworks also like gtk for design approaches of such features and I found that even in gtk framework, spell(gtkspell), undo/redo(gtkundo) are external objects

Last Author
shilpasingh
Last Edited
Jan 19 2016, 2:00 AM
Projects
None
Subscribers
katpagavalli, ksinha, shilpasingh and 7 others