nkb03 / hextant Goto Github PK

Current behavior:

• sometimes the completion popup pops up after the corresponding editor has been left by the user
• selecting a completion causes an exception, when the corresponding expander has since been expanded
  Intended behavior:
• completion popups should not show when the corresponding node has been left
• it should be checked whether the expander is expanded before trying to expand it with a completion

How do I build and run the project?

Hextant should be able to automatically find plugins in the classpath.
An application has dependencies on required plugins.
Additional plugins can be added by the user by putting them into the classpath.

It should be visible for the user when some expander is not expanded.

The core should handle all exceptions occurring in pluggable parts.

• commands
• inspections
• Expander.expand
• ListEditor.createEditor
• TokenEditor.compile
• plugin initialization
• etc.

• Users can manually save with Ctrl + S, which saves all currently selected files
• When an editor loses focus it is automatically saved
• Maybe highlight editors which were modified (based on a change of result)

• ValidatedTokenEditor instead of FilteredTokenEditor
• ExpanderControl instead of FXExpanderView
• TokenEditorControl instead of FXTokenEditorView and merge abstract class

• plugins can register configurable properties
• settings file edits a map of properties to values
• this map is passed as a bundle to all the editors (including the settings file)

Hextant design is currently pretty dark and ugly ):
To make it better follow these steps:

1. Fork, clone and build the repository as described in the README
2. Run one of the examples as described in the README
3. Get a good idea on how you want Hextant to look
4. Modify the stylesheet under hextant-core\src\main\resources\hextant\core\style.css
5. Rerun Hextant and decide whether you are satisfied with it
6. Repeat steps 4 and 5 until you are happy with the design
7. Create a pull request maybe including some pictures of the new look

If any questions or errors occur during your work contact me ([email protected]).

• make the API less fragmented
• display matched parts of completions

• should be handled in EditorControl
• first, commands for the view are considered then commands for the target

• Highlight matched parts
• When command with parameters is expanded the argument editors need focus

• Default shortcuts for undo, redo, etc.
• Default command line?
• Possible solution: Many sub-classes of HextantApplication for different purposes

• As the CompileResult API may be used without Hextant it should probably be put in its own module
• Because it is then independent of editors it should probably be renamed to Result
• There could be an extension module that combines the CompileResult with the Reactive-API
• Is this overkill?

Currently moving forward is working seamlessly on list editors but moving back is sometimes not possible.

• Possibly coroutines could help

• Command lines should not only act on editors but also on their views

• not only the editors but also the current configuration of the views must be saved
• to possibilities for the implementation
  1. Views get additional config Bundle, which is written to files when saved
  2. Properties of views can be marked with some annotation (maybe @ViewConfig) and all properties with this annotation are written to files when saved

• user should be able to add/remove plugins
• plugins are added as .jar-files to a certain directory which is recursively included in the classpath
• to activate the changes, the application has to be restarted
• detection of name, author, and description require this information to be in the MANIFEST.MF
• descriptions are probably specified as references to resources in the manifest and
  displayed in a WebView
• open question: should plugins be managed in SettingsEditor or in a separate PluginsEditor
  • Display of description must be possible
  • When plugins property is removed from settings all info is lost

-> Probably we need a separate editor

Files and directory can be copied and pasted since #13, but it would be more intuitive to move project items with a drag and drop gesture.

• The user should be able to select multiple project items and then drop them into another location
• If dropped on a directory the items should be moved inside the directory
• If dropped on a file the items should become siblings of this file
• The items should be moved and not copied, that is they should be removed from the source location
• No items that are part of the same tree path can be dragged simultaneously
• This issue is probably connected to #14

When the user presses ESC the focused dialog should be closed and the parent scene must be focused.

• Only one Bundle interface that also handles reactive properties
• Use Any as default permissions
• ReactiveProperty class for reactive properties
• Get rid of HextantPlatform

For example:

• rename <project> <new_name>: renames a project
• delete <project>: deletes a project from the disk
• quit: quits the launcher

• Command selection
• Navigation inside problems and fixes
• Traversal with arrow keys
• Selection of multiple editors
• etc.

Currently, copy/paste is only supported on expanders.
There are scenarios, where no expanders are involved but the user still wants copy/paste functionality available. For example in the project explorer the user may want to paste a project item, but he might not have an expander available. Therefore the following changes are proposed:

• Make copy/paste mostly independent of expanders
• A copy action from the user just moves the selected editor(s) to the clipboard.
• Editor gets a new method paste(editor: Editor<*>), which can be overridden by implementing classes
• Implementations have to check, whether they support pasting the supplied editor (i.e. instance of tests)
• There are default implementations in TokenEditor, CompoundEditor and ListEditor
• Expander implements this method by testing whether the pasted editor is an expander or is of the class of the editor type of the given expander and replace their content by the supplied one
• When the user types Ctrl + V on an editor view, the clipboard is looked up, and the paste method of the target editor is invoked
• ListEditor gets a method paste(index: Int), which looks up the clipboard, copies it and then puts the new editor into the specified index
• ListEditorControl gets two new shortcuts for pasting before/after the selected item (Ctrl + V and Ctrl + Shift + V)
• The copyForImpl()/supportsCopy() are removed and implemented as extensions, that create a new instance of the editor with the specified context and then call paste

Completions should be able to communicate with TokenEditors and Expanders in a non-textual way.

Possible fix

• add parameter completion: Any? to method expand(text: String) and compile(text: String)
• by default null is supplied
• the corresponding views may call the public method complete(completion: Completion<*>) that delegates to expand and compile
• subclasses of Expander and TokenEditor can take the completion-argument into consideration when overriding expand or compile
• ExpanderConfigs could have a typesafe interceptor registerInterceptor<reified T: Any>(factory: (T) -> E)

See #45

• if no constructor(Context, Result) is available, use constructor(Context) and setResult
• autogenerate setResult in generated editors

Problem 1: Too many threads needed with the current solution
Problem 2: Sometimes it doesn't even work

Some editors always produce a valid result. It should, therefore, be possible to implement editors whose result property is of type T and not of type Validated<T>. There are two possible solutions:

Easy solution

Create function defaultResult(): Validated<R> in Expander that can be overridden by subclasses to achieve that the result is always Valid. Plugins can then call force() on results when they know that the result is always Valid.

Pro

• This could be implemented quite easily and the API-changes would be backward-compatible.

Contra

• not the cleanest solution
• the fact that an editor always produces a valid result is not captured in the type definitions
• this leads to many unnecessary force() calls.

Complete solution

Change the type of result to R instead of Validated<R>. Editors that may have an invalid result can just pass Validated<R> as the type parameter.
There are however some problems with this solution.

1. There is currently no way to reflectively create editors for a generic type. This means we can not create an editor for result type ´Validated<T>.
   • use KType instead of KClass for registering editor factories
   • there is the typeOf function that can be used to get the KType instead of the KClass from a reified generic
   • should this also be done for EditorView factories?
2. How do the CommandLine, the SettingsEditor and the argumentPrompt know if the result of an editor is valid?
   • Add property isValid: ReactiveBoolean to interface Editor
   • Create editors by asking for an editor of type P and then for an editor of type Validated<P>
3. A ListEditor doesn't know if its child results can be invalid.
   • Create abstract function accumulateResults that is implemented by subclasses ValidatedListEditor and SimpleListEditor
4. The SyntaxErrorInspection only works for Editors with validated results
   • Use KType instead of KClass for registering inspections and commands

Pro

• clean
• this would solve fundamental problems such as generic reflective registration
• everything is visible in the types

Contra

• quite tedious to implement
• many major backward-incompatible changes to the API

On top of the current Kotlin DSL based shortcut API, there should be string based DSL for shortcuts, which should support the following features:

• a shortcut extension function for String, which parses a shortcut description string
  • "A".shortcut => shortcut(KeyCode.A)
    *"Ctrl+A".shortcut => shortcut(KeyCode.A) { control(DOWN) }
  • "Ctrl?+A".shortcut => shortcut(KeyCode.A) { control(MAYBE) }
• ShortcutRegistrar.on should also be able to take a shortcut description string as parameter.
  • For example: on("Ctrl+B") { doSomething() }
• Whitespace should be supported between different tokens

• Pasting should be supported directly
• INSERT and REMOVE instead of PLUS and MINUS
• INSERT with control inserts before selected editor

• probably history view is to be removed
• instead, you could view the history with a key combination
• also "go back in history" and "go forward in history" should be supported
• command line should be an editor, so that you can wrap commands inside one another which enables commands like repeat
• the overall GUI should be more 'responsive'

• hover should focus item
• popups should be hidden on escape and when losing focus
• choose better colors
• compute common width

Until now, the @Compound annotation from the hextant-codegen module only works on data classes, implicitly using the primary constructor.
In principle, there would be nothing preventing it from being used on general top-level functions.
The behavior on data classes should stay the same meanwhile.

When executing commands, it is typically expected that undoing will undo the whole command. This is currently not the case. Instead the user has to undo all the steps done by the command. To solve this, the methods UndoManager.startCompoundEdit() and UndoManager.finishCompoundEdit() are needed. Every Edits recorded between those two method calls are merged into a single CompoundEdit which is registered after calling finishCompoundEdit().

• function Editor.createSnapshot(): Any creates a new snapshot
• snapshots save the entire state of the editor
• they can be used for copy/paste, undo/redo and serialization/deserialization
• there can be default snapshots for core editor classes like TokenEditor, Expander and CompoundEditor

• Editor A has an error
• Editor B has a warning
• A is a (possibly indirect) parent of B
• What should happen: the complete view of A should be marked in red
• What currently happens: The view of B inside of A is marked in yellow

At the moment the plugin server has to be available when creating or opening projects.
This should not be required.

• Ability to disable/enable commands and inspections (involves restructuring inspection API)
• Ability to configure highlighting of problems

• We don't need the launcher things inside the core-binary
• The plugin system-related things should mostly not be exposed to plugin developers

Information that should be included:

General overview

• what is Hextant?
• some links
  • Youtube Video on Hask
  • Wiki

Getting started

• building
• running
• testing

How to write plugins

• build script
• making editors
  • Editors and EditorViews
  • contexts
  • Expander, ConfigurableExpander, ListEditor, TokenEditor, CompoundEditor, ProjectEditors
  • code generation annotations
  • completion
  • undo managers
• plugin initializer
  • commands
  • inspections
  • stylesheets
  • configurable and persistent properties
  • how to add new features to the plugin initializer
• JavaFX related things
• plugin.json (maybe make a schema file)
• the aspect/feature/implementation-system