Clicked 2.0

[Snakybo]

This issue contains ideas I have for future development of Clicked, nothing in here is set in stone and may change at any time, it's simply a collection of ramblings and ideas I currently have or may have.

The TL;DR of this, is that these changes aim to make Clicked a more comprehensive visual macro-builder, with more functionality and more extensibility.

Philosophy

Clicked 2.0 is an almost full rewrite of all systems, the high-level goals are as follows:

• Reduce memory usage

Currently, Clicked uses a lot of memory. This isn't really bad, as it's generally peanuts in the grand scheme of things, but it'd be nice if this can be significantly reduced.

• Simplify database

The database structure is currently quite complex, and due to how options are serialized, it contains a lot of practically useless data. For example, default values for options are not omitted, so there's a lot of data which could just be inferred from the defaults table.

This had a purpose initially — I don't want to override a setting for a user if the default value changes, but in practice that has rarely if ever happened. It should be safe to simply omit values that are the default, and thus significantly reduce the size of the saved variables, too.

• Allow for more control over macros

Currently, bindings use some smart logic to determine the position of a binding within a macro. This is nice and convenient because it makes it easy to use, but there are instances where you want more control over how the macro is built.

• Modernize interface

Whilst the interface was rewritten not that long ago, unfortunately AceGUI uses old templates and styles. There are three paths here:

1. Remove AceGUI completely, and write a custom UI library
2. Create a full replacement set of AceGUI widgets and containers that use the new templates
3. Live with how AceGUI looks and keep it as-is

• Simplify code

The game has some more things built-in, such as data compression and decompression, thus we can get rid of the libraries used for this.

• Reduce translation layers

It's currently a bit complex, going from bindings to commands to attributes to actually setting attributes on frames. A simpler translation layer would be nice and should be possible with the rest of the proposed changes.

If we can:

1. Determine which bindings are active
2. Convert the bindings into attribute sets
3. Apply all attributes

• Make it easier to extend binding types

Currently, it's not hard per-say to add new binding types, but it requires code in a lot of places, ideally this is all simplified into a single place, like modules that can be added. That will make it easier to add, for example, the following:

1. /summonpet
2. /dismisspet
3. /dismount
4. /equipset
5. /leavevehicle
6. /castrandom
7. /castsequence
8. /startattack
9. /stopattack
10. /stopcasting
11. /userandom
12. /focus

Note that a some of these are currently built-in using check boxes on bindings. This would expand upon that feature, and allow the user to customize these further

• [TBD] further expanding functionality

An idea is to further expand functionality of Clicked, straying a bit from the strict slash-command wrapper it is now. Think of:

1. Summoning random favorite mounts — this is unfortunately, not available through a slash command, but is a feature you'd probably want to keybind if using the feature

Technical changes

Settings

Currently, settings are stored within a profile, those should really be stored globally. It's somewhat stupid that these reset every time you create a new profile.

Bindings

Bindings are currently gigantic data objects that contain a bunch of load conditions and a bunch of targets, in Clicked 2.0 this will be a much simpler and extendible data structure.

Bindings will be split up and cease to exist across a multitude of different object types. This is a rough outline of how it will be structured:

--- @class Key
--- @field key string
--- @field type ActionType
--- @field sets ActionSet[]

--- @class ActionSet
--- @field type string -- cast,use,etc.
--- @field actions Action[]

--- @class Action
--- @field load LoadConditionSet
--- @field flags UnitFlags
--- @field target string

--- @class CastAction : Action
--- @field name string
--- @field id? integer

--- @class UseAction : Action
--- @field name string
--- @field id? integer

--- @class CancelAuraAction : Action
--- @field name string
--- @field id? integer

--- @class MacroAction : Action
--- @field name string
--- @field icon string
--- @field text string

This separates the current interface into three distinct layers, at the top there's a key assignment, next, a new term "ActionSet", this is simply a container for a single line within a macro, so an action set can be for /use, and another action set can be for /cast, executed in the order they appear in the table.

And lastly, there are actions, these are the "do" part of a binding and refer to the thing a binding actually does, when it does it, and when it should be active to begin with. This is now separated out into multiple smaller objects, each specifically for the action set of their relevant type. So a cast action set will contain CastActions, a use action set will contain UseActions, etc.

A macro action set is a bit special however, as that can only contain a single entry.

Validation

Unfortunately, macros have a hard length limit of 255, this was a problem before, but powerusers of this new version may make it much easier to reach that. We need to be able to check for final macro lengths in real-time, and show a warning in the UI as needed.

Key objects

It's possible to create multiple key-level entries for the same key, this requires two things:

• Identifying key-level objects using something other than the keybind, likely a uid like it exists currently.
• Configuring a merge priority, where a higher value comes first in the final macro.

--- @class Key
--- @field uid integer
--- @field priority integer

User interface

The user interface will keep a familiar feel, but function quite differently, a rough outline is as follows:

┌─────────────────────────────────────────────── Clicked ───────────────────────────────────────────────┐
│ ┌──────────────────────┐
│ │ Search...            │
│ ├──────────────────────┤
│ │ E                    │
│ │ ├ Use an item     [1]│
│ │ │ └ Use My Trinket   │
│ │ │   @player          │
│ │ └ Cast a spell    [2]│
│ │   ├ Cast Holy Shock  │
│ │   │ @mouseover       │
│ │   ├ Cast Holy Shock  │
│ │   └ @player          │
│ │                      │
│ │                      │
│ └──────────────────────┘
│

The binding list contains a visualization of the three data types above — the top-level key, an action set, and actions.

Keep basic functionality simple

Whilst the above UI is much more powerful, it's also much more complex, which might turn people away. By default, it should be able to function as it does now, where you can simply click a button to create a "cast a spell" configuration.

Another idea is some interactive creation wizard that goes along the lines of:

1. What key do you want to press?
   • E
2. When you press E you want to do?
   • Cast Holy Shock
3. On whom?
   1. My mouseover target
   2. My target

If that wizard is intelligent enough to automatically merge on a Key that already exists, it would be extremely easy to create any new item without having to interact with any form of advanced configuration.

[Gateswong]

Thank you for the awesome addon and great works! Here is a wish list during my usage of this addon that may help, or inspire:

Search through context. (Macro, bound spell etc)

I heavily use Clicked and bind almost all spells. The list is long and hard to navigate to what I need to find. The search sometimes not helping if I'm using macro and a different title, espically it's in a different language.

Taking an example of Celestial Alignment. I have a macro with different title. I cannot search this through the spell name. In this case I'll need to manually scroll and find the button I'm looking for.

Add an option to by default set spell bind to current class and spec.

When I'm adding a new spell binding, or directly drag from spell book, set these by default.

Drag and drop spell from book

If the binding list is full, the drag and drop from spell book becomes harder. Also, if you start a drag from spell book, and release the left mouse button, then you will not be able to drop it into the addon.

One possible solution is adding a quick drop "fake action button" on ui to accept the drop operation.

Support KeyUI

The "Show on keyboard" is an awesome feature. However it doesn't display the bindings from the other addons and system. KeyUI is an universal keybinding visualization addon, and it supports bindings from some addons. The binding in clicked is displayed as technical code on KeyUI. It would be great to add support on it as well.