I want to rephrase & clarify the requirement for the "link" type here:
I need an option type that supports dragging & dropping of existing objects in the Blizzard interface. Specifically for a gui it uses GetCursorInfo() to get information about the object being dragged anonymously and without regard for where it got dragged from. The only thing that matters is that something got dragged & is now being dropped. There is no hooking of functions etc. This drag & drop interface is a global cross OS standard. It needs support in ace options & by support I mean either as a base type of the standard or as a custom type using whatever extension mechanism is provided. Nothing less than this is acceptable.
In order of importance:
In the GUI I can drop items / macros / spells & whatever future object types Blizzard may support this way. I drop them onto an icon which shows me what I have done visually. Optionally there is a text description of the dragged object next to or below its icon.
In the tree view part there is a smaller icon next to the text when the "link" is not in the content pane only. I can also directly drag onto the tree view part if it is visible.
The tooltip displays the object dragged with a "Drag an object from your bags, inventory, spellbook, or macros here" explanation apended.
There is a way to filter to just the object types I want to receive & thus leave the others on the cursor.
In the Console there is a text format to specify things all at once or a set of sub entry strings to enter all the specified data separately.
In the drop down there is some scheme for entering the specified data.
consoleHidden & dropdownHidden fields suppress display in those UI's
Adding a text field to the gui can be done as an optional flavour of the "link". If so there is also a type dropDown. The dropDown gets set automatically to the right type when shift clicking something into the field.
The text field can be the macro text for a custom macro (type = "customMacro", macroText stored in info2). This is distinct from a regular Blizzard macro (type "macro" which has its macro id in info1)
As a special case when I am only looking for an object of type "item" or "spell" or "macro" or "customMacro", the icon & type dropdown can be suppressed & the text field accepts itemLink shift clicks or spell shift clicks (but not pet spells) or the macroID or the macroText / macro shift click respectively.
That is it.
There is no attempt whatsoever to somehow be backwards compatible with existing stuff or magically upgrade them with new functionality. That is because existing stuff does not provide the functionality required here. A text field that you can shift-click an item or spell into or Allah forbid actually type an itemId into is just not the same thing. It is a mere subset, a paltry shade of the desired functionality. As such an author currently using such an interface can choose to upgrade if they wish & the process would be quite easy.
There is no mention of magic wand technology because its implementation is intrusive, hacky, inelegant & requiring the hooking of all sorts of stuff & even then it will not work for new mods / interfaces because they will not be hooked. If Blizzard provides magic wand technology then fine, we will have an elegant api just like the current drag api & another type to implement or a different flavour of the gui component to implement.
The existence of this type does not preclude upgrading the text field type to accept drags. The text field, even upgraded is just not a substitute for "link" though.
"simply let the editbox accept a drag" clearly does not fulfil the intended feature.
The type formerly known as dragLink or objectLink is now simply known as "link". (tx ckknight for the suggestion)
My idea was to simply let the editbox accept a drag. Like I said some means of making the field appear as a "bag slot" instead may be possible, but simply making the editbox accept a drag would fulfil the intended feature here (drag and drop config). Making it show up as a bag slot instead of a text field is just appearance. Doing it like that we don't have to add a type, and we add functionality to existing fields that may be useful if the author hadn't explicitly written the option table to handle dragged items.
Yes & that is fine & adequate for people that only need an itemLink.
However, that would leave your control once more unsuitable for AutoBar use & make me still need to implement a proper gui object that accepts a cursor drop & handles objects other than an itemLink. To wit: macros, spells & actions.
I really do not care about existing fields. Existing fields are perfectly adequate as used right now. If the author wants to enhance their field they can change to using an objectLink & handle the special sub case of an item type with an itemLink. If they actually can handle the other types then bonus, they now have 1 control to do it with.
Which brings up a good point. An objectLink would need to be able to filter non acceptable types.
...dropdown suck [but] ... I still think they're super hander for simple 1-level toggle and execute lists though.
Could not agree more. Dropdowns should be a quick access mechanism for some really simple settings.
Quote from tekkub »
My solution is simple, make the "edit" type (whatever we're calling it, the kind that accept text, shows up as a text box in GUI) accept drags in the GUI...
Ok lets call it objectLink for now:
We are agreed that in dropdown you are typing your stuff in somehow.
Also agreed that in console mode you are either typing or shift clicking to get it in there or automating via macros which are happy to type it out.
For the gui part, having a text field is ok but of incomplete usefulness. It is necessary to have the icon to drag to as well. Either but not both can be disabled.
Now the purpose of an objectLink is not to simply wrangle an itemLink. An itemLink does not handle macros nor spells nor actions. The current returns are:
objectType, objectId, objectInfo which are what you get from GetCursorInfo()
An itemLink can be parsed into these components & for drops with objectType = "item", objectInfo is in fact an itemLink.
So a drop down would have to specify type & then take some text, and the same for console.
Macros are a bit tricky since you can have a built in macro (18 + 18 different ones) as well as a straight up chunk of macro text. As is GetCursorInfo only supports the built in type & its index is in objectId. To support other macros, objectInfo can contain the text for them.
Make no mistake, this is a compound type in the same way that color is a compound type. Just as color actually displays a color in the gui so an objectLink displays an icon in the gui. Similarly just as you wouldn't only give a user 4 text boxes instead of a color control, so you would not simply give the user ony a text box here. A mod author can choose to gimp their gui if they want to I guess but the base functionality should not be gimped.
Quote from tekkub »
So you intend to skip out on payment...
Surely you do not expect payment without rendering any service...?
...Drag-and-drop is a nice idea for GUI, but whatever we add needs to handle console and dropdown (*shudder*) as well. Hopefully we can find a solution that will work for you, and feel "natural" for everyone else.
Interresting. Well the odd man out here currently is drop down. Console can probably accept shift-click text input.
Dropdown cannot accept anything that does not leave the mouse hovering over it. Neither magic glowy cursor technology nor drag & drop technology will work unless the dropdown is forced to stay open until the user is done with it & dismisses it somehow (other than merely moving off of it). Well I guess glowy could remember who it is glowing for & so work but without any feedback to that effect...
Now that is not a bad idea because the most revolting thing for me in the current drop down is its insistence on closing up & forcing me to retraverse its hierarchy at the twitch of a mouse.
However I am getting a very uneasy feeling about this. "Whatever we add needs to handle console and dropdown as well". This is a recipe for lamest common denominator UI which is what we have right now. Just free yourself from such an insistence. It makes no sense. The very appeal of a gui is to easily be able to do complex things that would require a lot of typing in a console or hackarounds in a drop down.
Each 3 has their place in a UI, but insisting on equal capability is to insist on a UI that knows how to edit text & checkboxes & little else. There needs to be guiHidden, consoleHidden & dropDownHidden options ...
Quote from tekkub »
You offered a blowjob, I'm still waiting for delivery...
Sucker! I only asked who I would have to, not to actually...
I have patched AceConsole-2.0.lua to fix this issue on a temporary basis while waiting for a solution. This apparently is not good enough for some members of this community who insist on deleting the patch even though it could not possibly do any harm whatsoever.
I need an answer to this issue please so I can know how to proceed . Meanwhile I need for people to stop deleting my AceConsole-2.0.lua patch.
Actually, what I think would be useful is a "Select item glowy hand" option, where you toggle the selector on, and it glowyhands you and you click your required item. I had issues with the drag-drop dewdrop menu option in some fubar plugins cause the textbox where I'd need to drop the item disappeared. Going the other way, ie, making the selection possible seems like a useful method.
Glowy hand would be a usefull suplement but its not exactly easy to discover in the interface. While drag & drop is a standard part of any modern UI, even the Blizzard UI. Blizzard has also recently fixed their drag & drop ui to make senses & to operate without needing to hook anything. You simply check the cursor on drop & retrieve the object from it if you want to.
Quote from tekkub »
I didn't say no, I just expressed my lack of understanding. You're the one asking for something to be implemented, sell it! I, for one, don't see how drag and drop is more effective than shift-click, and I can hazard a guess that shift click would be simpler to implement.
Sell your shit, don't just get mad cause I don't see the need. Convince us that it's needed!
Well the drag & drop is already implemented, unless you are talking about implementing it in AceConsole. There I can definitely see opening the options out to a dragLink (bad name in that case) & shift clicking the link in as your value. Heck if shift-click also works as a shortcut to dragging thats a bonus feature & I will add that in. But it would seem to require a lot more work than just using Blizzards simple does the cursor have stuff on it? / ok so what is on it? interface. The other issue is, ok lets say you "shift click" a value into a text field then parse it. Well now what? It still needs to get dragged & dropped around to rearrange the list. This behaviour just works if you have a dragLink though.
As for selling it I am of 2 minds. On the one hand I need drag & drop since it is easy to explain to users & they have already done it b4 just by playing WoW. On the other hand, like I mentioned this is a lot more specific than say the color option. So seriously I am ok with it not bloating up the core set of options.
Who else could use a dragLink? Well an interface that lets you make custom PT3 sets or something like that. So for instance baggins or other bag sorting mods. Potentially any client mod of PT3 could use it if they let users customize their own sets. Looking to the future a UI like ItemRack could just be a bunch of dragLinks, assuming a layout of that kind could be made (which from the Ace3 discussion on Jirra seems possible if the panel layout is adopted & up to snuff).
So I think a dragLink has potential for some cool uses, the question is if it gets allowed in then what else gets in & where do you draw the line / deal with potentially a large number of new (gui) option elements. I am also surprised that the options are so resistant to change / extension. Perhapos that is because a gui view on them is a recent thing?
Regardless though, a choice needs to be made from the following:
1) Add dragLink for the things Console will look for so it can ignore it instead of crashing on it. Repeat this step for each new gui element added by anyone using Console.
2) Do nothing. Do not add it to the ignore list & force all users that use AceOptions to make specific options tables to coddle AceConsole which is apparently very picky when getting fed an options table. Or dont use AceOptions at all.
3) Modify its behaviour so it can be told not to complain about unkown objects or just plain does not complain. Perhaps this is runtime behaviour & during debug it complains.
4) Who cares about AceConsole-2.0 anyway. Leave the solution as an exercise for the student to get into AceConsole-3.0 or whatever the Rock counterpart is.
5) Do something completely different like a magical glowy hand that gets activated & then sucks in things you click on.
PS: I am not mad. Well not clinically diagnosed as such anyway ;-p
I don't understand the need for it honestly, the default UI works off shift-click for what it sounds like you're doing... actionbars and bag slots are the only things that accept drags (okey and hunter pet unitframes). I'd expect a config UI to work like the macro UI, shift click a spell or a bag item to insert it in the line you are editing. Does shift-click not work with waterfall text fields?
That sounds real lame. What I want & do not have working yet is in the tree part of the view to have a small icon of the item + its name & you can drag right onto it. Right now this only works on the icon part so you need to open each item individually to drag to it. Shift click to insert the name is a very poor substitute & unacceptably hacky imo. The only thing blizzard uses that for is chat & macros which are text based interfaces. Everything else is drag & drop or modifer - click. Bottom line: I am simply not interrested in lowest common denominator type interfaces.
Now it is ok to say no to this request though, I understand that it would be used by very few mods. But what I need from Ace Console is to not barf on the config I feed it. That part is unacceptable. It is fine to ignore & not display stuff it does not understand but to blow up is retarded. There needs to be a shut up & do your job setting which can be ignored for debug I guess. Or an api so I can feed it a list of stuff to ignore.
As I have posted elsewhere I sure hope that the Ace3 options will be extensible so people can register new types & have them handled even though they are too particular to make it into the "standard" set of option types.
In irc people were going on about how I should make a custom options list just for Console. This is highly stupid. Why should I double my options data just so I can have it show up at all in Console?
It is currently implemented in waterfall as an object that can receive a drag via the CursorHasItem etc. functions and accepts macros, spells, items, actions. I use it in AutoBar to allow users to specify items with a simple drag & drop without having to know or type in arcane itemIDs or some such nonsense.
It can be used for UI wherever someone needs to make a list of items / spells etc.