Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

[Strategize] Editors #204

Open
ferndot opened this issue Nov 7, 2014 · 6 comments
Open

[Strategize] Editors #204

ferndot opened this issue Nov 7, 2014 · 6 comments

Comments

@ferndot
Copy link
Member

ferndot commented Nov 7, 2014

As we support more and more formats, we may need to use different editors for different file types. For instance, WebODF for XML files, Midas for HTML files, and a plain-text editor for TXT.

This issue is for brainstorming the methods that we could use to accomplish this objective.

@ferndot
Copy link
Member Author

ferndot commented Nov 7, 2014

One idea that I had was to create a module (using the system from #194) for each editor. The app could select and load the desired editor based on the file mimetype.

@twiss
Copy link
Collaborator

twiss commented Nov 7, 2014

I think the idea you mentioned in #201:

What do you think about moving the formatting toolbar into the editor? This would reduce a lot of the cross-frame communication, and allow for different features for different file types.

makes a ton of sense. Although that's still tricky, because if you want to keep the hide-keyboard button you'd have to replicate it in every editor, which is also bad.

@jackd1
Copy link
Member

jackd1 commented Nov 7, 2014

We could maybe have a template editor, containing necessary modules for all editors for things like communication with the main document. Then we could just inject other modules depending on the document being edited.

@twiss
Copy link
Collaborator

twiss commented Nov 26, 2014

I think the idea you mentioned in #201:

What do you think about moving the formatting toolbar into the editor? (...)

makes a ton of sense.

OTOH, the main benefit of having support for many file types in one app (as opposed to many apps) is a unified UI. In other words, if we add WebODF (#189) we might want to redo its toolbar to be the same as the one we have. That's probably easier if we keep the toolbar out of the editors.

This would reduce a lot of the cross-frame communication, and allow for different features for different file types.

We could hide some buttons based on file type.

Although that's still tricky, because if you want to keep the hide-keyboard button you'd have to replicate it in every editor, which is also bad.

@twiss
Copy link
Collaborator

twiss commented Nov 26, 2014

In the same vein, it might make sense to pick a single editor (be it designMode or WebODF or ...) and convert everything to and from that, to make sure every file type behaves exactly the same.

@ferndot
Copy link
Member Author

ferndot commented Nov 27, 2014

That's probably easier if we keep the toolbar out of the editors.

These are the pros/cons that I can discern for each approach (feel free to add some):

  • Toolbar inside of editor
    • Pro: Encapsulation of features
    • Pro: Simple editor layout modification
    • Con: Separate maintenance of each toolbar UI
  • Toolbar outside of editor
    • Pro: Unified UI
    • Con: Difficult feature differentiation
    • Con: Difficult editor layout modifications

In the same vein, it might make sense to pick a single editor (be it designMode or WebODF or ...) and convert everything to and from that, to make sure every file type behaves exactly the same.

@twiss that is what we are doing now, and it poses some challenges (even conversion from plain text to HTML had some errors). Still, it would be simpler...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants