These forums are in read-only mode. Please see this news post for more information.

New forums can be found here


Go Back   WowAce Forums > Addon Chat > Frameworks
Frameworks Framework Discussion

Reply
 
Thread Tools
Old 10-20-2007   #11
Tekkub
Tanuki
 
Tekkub's Avatar
 
Join Date: Feb 2005
Posts: 5,091
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by Toadkiller
I need an answer to this issue please so I can know how to proceed.
You offered a blowjob, I'm still waiting for delivery.

Solutions for Ace3 are being discussed. 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.
Tekkub is offline   Reply With Quote
Old 10-20-2007   #12
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by tekkub
...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:
Originally Posted by tekkub
You offered a blowjob, I'm still waiting for delivery...
Sucker! I only asked who I would have to, not to actually...
Azethoth is offline   Reply With Quote
Old 10-20-2007   #13
Tekkub
Tanuki
 
Tekkub's Avatar
 
Join Date: Feb 2005
Posts: 5,091
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by Toadkiller
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.
I totally agree that dropdown suck, and I hope that providing a nice GUI from the start will help keep everyone from using them as a full-blow config UI. I still think they're super hander for simple 1-level toggle and execute lists though.

Console, however, is something we need to keep around. I was one voting for "fuck command line" from the start, but a number of users chimed in asking to keep it so they can automate addons in their macros. That's a very valid use case there, and I can certainly see times where they'd want to automate something involving an itemlink. Plus AceTab makes command line less blow, so there's that as well.

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. When you drop an item it sticks the itemlink in, spels get the spell name. Maybe it could have an optional flag to appear as a "bag slot" instead of a text field in GUI... but the bare minimum would be accepting a drag and displaying it as an item link. That wouldn't add a new type, and it'd make the edit type more useful overall (addons that take an item link in an edit already would need no changes to get support for drags in a GUI). This would of course be implemented in the GUI lib, not in the console lib.

Quote:
Originally Posted by Toadkiller
Sucker! I only asked who I would have to, not to actually...
So you intend to skip out on payment...
Tekkub is offline   Reply With Quote
Old 10-20-2007   #14
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by tekkub
...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:
Originally Posted by 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:
Originally Posted by tekkub
So you intend to skip out on payment...
Surely you do not expect payment without rendering any service...?
Azethoth is offline   Reply With Quote
Old 10-20-2007   #15
Tekkub
Tanuki
 
Tekkub's Avatar
 
Join Date: Feb 2005
Posts: 5,091
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by Toadkiller
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.
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.
Tekkub is offline   Reply With Quote
Old 10-20-2007   #16
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Who do I have to blow to get dragLink added to AceOptions?

Quote:
Originally Posted by tekkub
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.
Azethoth is offline   Reply With Quote
Old 10-21-2007   #17
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Who do I have to blow to get dragLink added to AceOptions?

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.
  • The data is specified here: http://www.wowwiki.com/API_GetCursorInfo. Basically type, info1, info2. type = "item", "spell", "macro", "money" or "merchant"
  • 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.

Notes:
  • 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)
Azethoth is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 06:08 AM.