Roadmap for Visual Editor

Development Third-Party
1

Continuing the discussion from Any wheels that need to be redesigned?:

Basic Roadmap

  1. First, due to the fact that XML syntax highlighting is likely available for text editors, the XML Code Format needs to be developed first.

    • Unicode will also need to be supported to use variable names and comments of the programmer’s native speech. This needs to be ironed out in the other thread.

  2. Since this will be using native InterfaceKit anyway, there’s no disadvantage to writing translators to import other programming langjuages as a bonus feature.

  3. Refactor a common wrapper class from the Scintilla text editor class and our own code view gadget. (CodeView will inherit from BOutlineListVIew.) That way existing code editors like Koder can use our editor almost out of the box.)

    • This may involve using shortcuts based on regular text characters without modifiers so it is easy to enter code quickly. This will map into the intellisense-like features of the current Scintilla API.

  4. While writing a compiler frontend for the XML language edited by the editor seems more attractive to me, using a C++20 backend may be useful instead. I’d like to support modules instead of headers and object files as separate. Either way, this step can be concurrent to steps 2 and 3 (if a second programmer wishes to help out).

  5. ???

  6. Profit!

Other Considerations

  • The lack of a source-level debug format may require that the debug mode be interpreted instead of compiled at first.
  • Another option is to develop a karat position class so that the XML will correlate to the positions of the parameters in each command construct. Modern Clang derivatives and GCC already do this, it just may be tricky on a visual language. This would map directly into the “red squiggly underline” features of Scintilla so the API may need to support it anyway.
  • Getting decent icons for the language will need somebody with graphical skills. I’d round this out to a team size of 3 or more ideally but I doubt that will happen currently.
    1. Compiler developer for the XML language
    2. Somebody who knows how to use InterfaceKit properly and other Haiku APIs. (This may double duty as integration developer to work with IDEs and Koder APIs to use the class in.)
    3. Icon designer. (Light duty.)
2

Just a few more notes about a potential hack:
Inherit directly from Scintilla and override any inapplicable code (selecting only parts of a command for cut/paste operations is illegal) and use a color font for all the icons. Lexzilla should be easily appeased for this to work.

3

Why would you ever use xml for something like this?

The aukland layout editor is already available, go fix it up or something D:

4

I thought ALE was just a GUI builder. In fact, using ALE will simplify the rest of the job. I probably will fix and use it. That will reduce the man hours needed significantly!

1 Like
5

I started looking at ALE today and it will definitely need some work. The 64-bit compile has a cryptic linker error that doesn’t get queried until runtime (at least I think it’s a linker error) and the drag-and-drop interface on the 32-bit version seems to try too hard to be WYSIWYG.

1 Like
7

Nice!!! Do it.

8

Speaking of linker errors, the CMake build script is very obsolete and tries to link to $(CORELIBS) but the macro isn’t mentioned in the oldest CMake online manual I could find and it doesn’t expand to anything in Bash. Does anyone know what libraries are supposed to link to that macro expansion?