Just one window for now, but having a class should allow a lot of logic from Init and the update functions to be moved out of Core.

Also: GUI.get_window_pos, maybe the save/load ExtState functions as well.

Issues:

• Button not consistently drawing its body
• Many elements still need updating to state and last
• Some elements not responding at all

Many scripts aren't really dockable without this, since a dock will never have the same dimensions as a hard-coded window.

May not be practical for something big like Theory Helper, in which case being able to define a minimal layout when docked might suffice.

Might need the JS extension?

i.e.

local myColors = {
  main: "red",
}

Maybe just make "Caption" a shared class that implements a Label?

I expect that US and JS windows will have their own graphics API. Scripters should be isolated from this, so the GUI should be able to load different drawing modules that provide wrappers for gfx.rect, gfx.drawstr, etc.

Bugs:

• Doubleclick - clicking the first letter of a word selects the first word of the line
• Doubleclick - clicking a space doesn't work properly
• Backspacing at the end of a line makes the scrollbar start extending too far to the right

To Do:

• :checkselection and :selectionvisible seem
  like they might have a lot of overlap
• Add current line highlight a la NP++
• Ctrl+Home/End
• Horizontal scrolling w/ mouse drag?
• Have the text, selection, and scrollbar drawn to a buffer
  • For redraw, just blit it with the caret blink drawn on top
  • Most methods would need to call a full redraw.
  • :draw() might be able to check and see if anything has changed
• Add "locked" property to TextEditor; make it read only, hide caret?
• Figure out word wrapping
  • See if iReaScript can help

GB may be a little easier to implement this time since elements are now created with prop objects rather than multiple arguments. At the same time, handling layers might be more difficult because they're now actual reference values.

Ideas:

• Separate tab for creating, editing, showing, and hiding layers
  • When exporting, including the show/hide state could be optional
• Element properties tab would have a dropdown with all available layers, a la assigning menus in Radial
• Import/export could use a serialized format for everything:

  local guiStructure = {
    windows: {
      {
        name: "Window Title",
        layers: {
          name: "Layer 1",
          z: 2,
          elements: {
            {
              name: "my_btn",
              type: "Button",
              x: 96,
              ...
            }
            ...
          }
        ...
      }
    ...
  }
  

  As long as everything can be referred to by name, there shouldn't be any reference issues.
• Export windows, layers, and elements individually without the GUI setup code
• Export to clipboard and/or a text editor
• Display the number of buffers that have been used; turn red when running low

Old To-Do list 1:

Complete rebuild

• Use keyed tables instead of strings
• Better module separation
  Only export elm properties that aren't the default (add "mandatory" flag to property classes for z,x,y)
  Project settings window - adjustchildelms needs to check for runtime before it can use elms_list - at startup, look through all elms for matching z instead
  Global settings window
• Visible grid
• Snap to grid
• Add lib_path as a user preference
  Edit/add font/color presets
• Use new window system idea
  Ctrl+drag element to copy it?
  Import from script
• Only works with scripts aren't dynamically generating elms, unless they use generated ref points
• Maybe won't work with tabs?
• Looks for meta tags to determine where to overwrite stuff
• Writes back to the original file
  Add ref coords/widths as an elm for scripts to refer to
• Exports as local ref1 = {....
  Add basic Help message for WIP release
  Allow Tabs to have a space in between?
  Add a shortcut/rclick to revert individual properties to their default, or reset the whole elm
• Generate elements' creation strings from their properties list
• Generate new elms menu from Elements
  Add Color property type
• Menubox w/ color strs?
• Color picker frame. gfx.showmenu pops up preset names?
  Slider issues:
• Allow gradient
• Fill color: "red, green"
• Rewrite so fill color uses col_a, add a box for col_b?
  Add checks for elements being placed outside the work area.
• Needs Coord_X?
  Elements tab:
  Menuboxes to filter by type and Z
  Edit/revert default params, copy from sel. elm
  Ctrl+Arrow to move elms or increment focused value (by grid, etc)
  Add window properties
• Make project area separate from the actual window size - create a dummy frame element?
• Make this a tab instead?
• Make sure to update export functions
  Export options:
• Put elms all together with extra_props together after, per z
  Create elms snapped to grid
  Dragging elms + w/ snapping
  Arrow keys to adjust cur elm by grid?
  Figure out something for z values
• Reserve a few in the front and back
• Offset user values as with Y coord

IDEA

• Limit the user to 10(?) zs at a time, which can be stored/exported as a set.
• Adjust user Tabs to save/load sets from file instead of affecting zs.
• Exporting project takes all of the sets and (somehow?) assigns a proper set of zs and z_sets.

Basic Features:

Textbox pad should only adjust the caption. Add "cap_align" param for left, top, right, bottom?
Menubox displays !s and #s in values
Props aren't updated on recreate w/ dir change (w vs h)
Menubox allows scrolling to # values
Add checks to all properties to revert to last value on error
Add ref + function to allow adjusting the sidebar on window resize
Add global redraw flag to Core.lua

• [0] was supposed to do that....
  Refactor/reorganize the test script
  Convert Y coords to adjust for menu bar
• New type Coord_Y?
  Add Label class
  Add Shadow property (type Boolean)
  Add file export
• Needs to create a GUI.title etc section

Old To-Do list 2:

Tasks Pre-Rebuild

• Rewrite GB Test to use keyed tables
  • Format Property For Export (should be able to create and export legal elements)
  • Recreate/duplicate elements
  • At this point everything should work as before

Rebuild

[ ] Tasks A (GB WIP)

This should all be doable with GUI v2.9, just have to change the reqs and Ctrl+H some GUI function/var names to port it to v3.

• Basic window structure
  • Sidebar, adjustsidebar
  • Menu w/ contents and dummy functions
• Basic elements
  • Right-click to create
  • Shift-click to select
  • Alt-click to delete
• Properties
  • Generate
  • Edit
  • Validate
• Project settings using existing GetUserInputs code
• System for project z versus GB z
  • Use an offset as for coord_y?
  • Reserve 1-10 for GB stuff, 110 for background and grid
  • Clamp all values to that range, specify it in Help
• Show edges of defined project area on frm_bg
• Basic export
  • Reqs
  • GUI.name, etc.
  • Elements + params
  • Init + Main
• Add basic Help window

[ ] Script Compiler overhaul

This should also be doable with GUI v2.9 and similarly easy to port

• Remove stray debug messages
• Replace Checklist with a Listbox
• Parse scripts recursively

[ ] Publish v3

• Update v2
• Create a stable release for the library as-is, pending bugs, so we can... (Pending update to wiki converter)
  • Bundle updated, path-aware versions of SC and the GB WIP
• How to publish? Github release, or can ReaPack access i.e. a 2.9 branch? Check with cfillion.
  • Can ReaPack packages require other packages?
  • Can ReaPack packages install an ExtState value, or run a script on install?
• Restructure the repo so the library is in its own folder, GB has a folder, SC can have a folder, etc.
  • README.MD should be the only file at root?
  • Library/Classes
  • Library/Settings? Presets, constants, etc?
  • Library/Modules
  • Library/Windows
  • Library/Examples
  • Library/Templates
• Split Core into Modules/Table.lua, Modules/Graphics.lua, etc
• Update Core to use more consistent (snake_case) function/variable naming
• Update all classes and examples to use the new structure and naming
• Update GB and SC to use the new structure, naming, and relative paths instead of F:/...
• Let v3 SC check for v2 scripts versus v3 scripts and paste modules accordingly
• Refactor classes to remove any calculations from :new if possible so recreating is easier?
• Add a check in Reqs for ext state - "Lokasenna_GUI Folder" - maybe include an "install" script to detect and set it?
• Update version to 3.0.0, start actually incrementing it periodically
  • VERSION.MD in each project's subfolder instead of in Core.lua?
• Create GUI Builder branch
• Push!
• Basic documentation
• Create project, migrate this list, etc?

[ ] Tasks B (GB)

• Advanced element behavior
  • Ctrl-drag to clone
  • Shift-drag to move
• Let Color properties use the Color Picker class
• Let Font properties use a Menubox
• Replace GetUserInputs with real Project window
  • Basic window
  • Title, size, position
• Basic Preferences window
  • Grid size
  • Show grid (also in menu)
  • Snapping (also in menu)
• Show boundaries of specified project dimensions
• Update Help with ^

[ ] Tasks C (GB)

• Write a helper for updating the script window's title
  • Write a helper-helper for GUI:reopen(title, x, y, etc)
    • Should update GUI.cur_w etc
• Project - Font presets
  • Boxes and validation light from Radial
  • Sample text
  • Should the font picker be a releasable window of its own?
  • Make sure only the user elements use custom fonts. How?
• Write Color Picker class from Radial code
  • Look at Airon's Color Swatch for any neat ideas to adapt
  • Document for Wiki
  • Push to repo
  • Make sure only the user elements use custom colors. How?
• Project - Color presets
• Idea: Have all of the GB elements use an internal clone of the color/font presets
• Update Help with ^

[ ] Tasks D (GB)

• Font preset import/export
• Color preset import/export
• Allow project to be a window
  • Checkbox and basic properties in Project Settings
  • Add (window) to title display
  • Show window frame in project area
• Window export
  • Comment specifying that this is a window, blank spot for parent script
  • Class requirements + error MB
  • Project title + size as window params
  • Skeletal return_func function with easy comments to Ctrl+F
• Update Help with ^

[ ] Tasks E (GB)

• Project settings - Allow resizing, allow docking
• Script export - code for blocking resizing and docking
• Window export - code for blocking resizing and docking
• Prefs - How to indent tables in export scripts
• Update Help with ^

[ ] Tasks F (GB)

• Prefs - Default project settings
• Prefs - Include blank ReaPack header when exporting a script
• Update Help with ^

Element functionality

• Create GUI elements
  • A Right-clicking the project area provides access to the element list + duplicate function(?)
  • B Ctrl-dragging an element clones it
• Edit GUI elements
  • A Shift-clicking an element selects it and shows a list of editable properties (Properties tab)
  • A Alt-clicking an element deletes it
• Arrange GUI elements
  • B Shift-dragging an element moves it

Property functionality

• Generate a list of editable properties
  • A Properties are subclasses of Textbox and Checklist with their own methods to validate entries
  • B Color pickers use the color picker frame (need new class)
  • B Fonts use font presets (Menubox?)

Project functionality

• Project settings window
  • A Project title/dims using existing GetUserInputs
  • B Replace ^ with Project window
  • B Project title
  • B Project size
  • D Project is a script or a window?
  • E Allow resizing
  • E Allow docking
  • Font presets
    • C Copy lights from Radial Menu for font validation
    • D Import/export
  • Color presets
    • B Use the new color picker class
    • D Import/export
• Global settings
  • B Grid size, snapping
  • F Default project settings/templates
  • F Default colors/fonts
  • F Include ReaPack header when exporting scripts?

Save/load functionality

• Export as GUI script
  • Exports:
    • F Blank Reapack header
    • A Reqs
    • A GUI.name, .w, etc
    • A Elements and params
    • E Allow docking/resize code
    • A Init + Main
• If a window, commented reference to the parent scriptExport as Window
  • Exports:
    • D If a window, commented reference to the parent script
    • D Class requirements + error message
    • D Project title + size as window params
    • E "Allow docking/resize" code
    • D Skeletal return_func code with easy comments to Ctrl+F
• Import from script
  • Parses a script for all GUI.elms, GUI.name/w/etc code and extracts elements
• Save/load project
  • Is this going to end up being any different than export/import?
  • Maybe just serialize all of the elms and project settings to a .txt as per Radial Menu?

Module structure

GUI Builder                             GUI Builder.lua

    Element functions                   func_Elements.lua
                                        data_Elements.lua


    Menus                               func_Menus.lua
        File
            New                         func_New.lua
            Open project                func_SaveLoad.lua
            Save project                func_SaveLoad.lua
            Import from script          func_Import.lua
            Export to script            func_Export.lua
            Exit
        View
            Show grid                   func_View.lua
            Snap to grid                func_View.lua
        Settings
            Project Settings            wnd_Project.lua
            Preferences                 wnd_Prefs.lua

    Tabs
        Properties                      tab_Properties.lua

        Layers                          tab_Layers.lua

In order to minimize coupling, and to enforce use of user-defined theming later, modules should expose as little of their functionality as possible.

For logic modules, this might mean anything that isn't a "top-level" function. For classes, this means anything that we don't specifically want scripts to mess with such as color and font settings.

Some elements may still need to expose their coloring and fonts, such as if a scripter wanted to have some sort of logo, but that should be an exception to the rule specifically provided by elements like Frame.

Can largely be pulled straight out of Radial.

Anything that repositions elements (the "flow" idea, etc) would need to be aware and update original positions as well where appropriate.

This one might be a bit difficult, both for the number of things that rely on the GUI state and not creating performance issues.

Ideas:

• Have GUI require Buffer, wrap getBuffer and releaseBuffer, then expose them to elements (still requires Element dependency on GUI)

• Move the app state into a separate module that Buffer can access without creating a circular dependency

• Label:fade
• Status window for "Go!" button

Using the existing text measurement functionality (which could probably use an overhaul), Textbox should be able to do this. TextEditor might be able to as well, since we aren't currently worried about word wrapping.

This might require hiding a lot of the coloring functions from script devs, or at least limiting their choices.

• Basic config script

• Pull settings from ExtState

• Write settings to ExtState

• Extract colors and fonts to a default theme file

• Add colors to Configuration

• Add fonts to Configuration

• Popup menu for selecting colors from the existing list?

• Font validation lights.

  • Is there any practical way to get a list of installed fonts?

Configurable parameters

doubleclickTime = 0.30
caretBlinkRate = 16
shadowSize = 1
tooltipTime = 0.7

colors = {
  windowBg
  tabBg
  elmBg
  elmFrame
  elmFill
  elmOutline
  txt
  shadow
  faded
}

fonts = {
  sans
  mono
}

dev = {
  gridMajor = 128,
  gridMinor = 16
}

The GUI will need to be restructured so that an arbitrary number of windows can exist and be opened/closed/paused independently of each other.

As a first step, a new GUI-level Window class will be necessary. A Window:

• Contains multiple Layers
• When prompted by the GUI, runs the layers' Update and Redraw loops
• Retains its state when closed or paused, so that f.e. a modal dialog can close the parent window, open the dialog, and then restore the parent window when the modal is closed. This might mess up docked scripts, so an alternative Window element might still be necessary.

• Maybe just allow Layers to have an origin and/or placement functions specified
  • Not sure how to do this. The Composite class ends up running into the same problems, so it can be sorted out there prior to working on this.

Maybe not necessary if we're planning to take color options away from scripters.

"Can only contain numbers", "must be a valid email address", etc, etc.