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 09-18-2007   #1
Elsia
Legendary Member
 
Join Date: Dec 2005
Posts: 2,144
Default Options and config abstraction (Rock, Ace3)

This is really sort of a conceptual question about how libraries plan to handle options and their configuration by the user.

Rock has removed AceOptions and I see that in the Ace3 wiki there is mentioning of AceConsole being split into an AceConsole and an AceConfig part that seems to be comparable to Rock's config part.

Now to give some background: I write small addons for personal use (well I give them away but guess noone uses them anyway ) and I have been using Ace2 primarily to give easy option configuration and seemless integration with other addons on the configuration side. (it actually turns out that the fact that AceOptions is gone from Rock is the main difficulty to port my addons to Rock.)

Generally what I like about the Ace2 situation is that in some sense one just defines the the options data structure and one gets slash command and gui integration (Niagara if present) automatically. Other options, like FuBar buttons and dropdown menus can be easily added.

While it may not be perfect it seems to follow a basic "type of data to be configured" vs "representation for that type of data via a cli/gui/..." abstraction and multiple representations can easily be grabbed.

I really liked that and think it's a clean principle. I actually like a commandline interface, not because I want people to use it a lot, but because it provides complementary functionality to other more gui type interfacing via quick changing of often used specific setting (think "/myaddon lock") and the ability to macro script and link to buttons (hence giving a link to Blizzards button gui without extra code).

Rock Wiki states:
Quote:
Removal of AceOptions support from the Console library.

* It is a major hassle to have multiple implementations for options, as they can sometimes conflict or one can be out of date. There are also issues for some addons only supporting one implementation and some supporting another, causing duplication of code as well as end-user inconsistency.
* Using the console for large configuration is unwieldy. "The poor man's gui".
* Small slash commands are great.
o Sometimes you want to have slash commands, but in such an event, the slash command should be simple enough so that it can be manually coded, therefore input capabilities are still in LibRockConsole-1.0, just simplified from the Ace2 version.
* There is an official gui-based options system called LibRockConfig-1.0
Well in some sense I hope to see options and their representation separated and at least retain the option to provide commandline options as a possible representation. Also I'd like to see this separation because it allows multiple GUI ways to represent the same option set (dropdown, waterfall, some people suggested itemrack-like tab based etc).

Some of the Rock principles noted above are GUI design decisions. It would be good to abstract this for people who have a different GUI design philosophy and hence more flexibility there. Certainly I don't want to write slash command code for all of my addons, and use a separate code (via a library) to create the same option->user mapping via a GUI.

Is it yet specified how Ace3 is going to handle this? Is there an intend to keep a commandline oriented library that implements an interface to an option data structure? How do you feel about option data abstraction and their GUI representation for flexibility?
Elsia is offline   Reply With Quote
Old 09-18-2007   #2
Nickenyfiken
Hero Member
 
Join Date: Aug 2008
Posts: 798
Default Re: Options and config abstraction (Rock, Ace3)

You should find this interesting.
Nickenyfiken is offline   Reply With Quote
Old 09-18-2007   #3
Elsia
Legendary Member
 
Join Date: Dec 2005
Posts: 2,144
Default Re: Options and config abstraction (Rock, Ace3)

Yes, I do. Thanks for the lead
Elsia is offline   Reply With Quote
Old 09-19-2007   #4
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Options and config abstraction (Rock, Ace3)

You know what, I am going to 2nd that motion. I too would like to see a framework independant:
1) DB library. This would have a common format that any mod whatsoever can use. It has absolutely no GUI or CLI or anything. Just persistence & defaults. Ideally it would also support some kind of inheritance down its hierarchy so I could as an example have
MyModDB
BarsDB
ButtonsDB
So a particular option set on MyModDB would be global to all, but overideable down the line. So for instance button size could be set on the mod level & thus all buttons are same size unless a particlar bar or button has it set as well. A call for button size to a particular button would ask the bar for the size if the button doesnt have it etc.
2) GUI Library. Given the DB library & a layout description (like aceoptions table), provide a GUI for manipulating it.
3) CLI Library. Same thing but with a CLI for manipulating it.

Now CLI can & should probably only have 1 implementation.
We know GUI already has many but I would like to vote for perhaps a fatGUI & a thinGUI. thin would handle only simple data types which suffices for a lot of mods. fat would be kitchen sink & handle mods with complex needs.

Alternatively there could be a plugin scheme to a thin GUI that makes it extensible. For example the type dispatcher & object factory could be changed to be table driven. A "plugin" then simply adds a new type to the various tables, provides any parameter parsing needed beyond the basic ones provided, its factory method etc.
Azethoth is offline   Reply With Quote
Old 09-20-2007   #5
Industrial
Amazing Member
 
Join Date: Sep 2005
Posts: 1,517
Default Re: Options and config abstraction (Rock, Ace3)

You are basically describing a framework, toadkiller, and this isn't universal because of the same reasons multiple frameworks exist; Different goals, ideas and assumptions as to how it should work.

These elements are tied up and need each other in order to work, that's why they can't be standalone libraries.
Industrial is offline   Reply With Quote
Old 09-20-2007   #6
Elsia
Legendary Member
 
Join Date: Dec 2005
Posts: 2,144
Default Re: Options and config abstraction (Rock, Ace3)

It only needs a standard for how to structure the options, how each framework chooses to implement them is arbitrary as long as folks can agree to a standard for the data structure. The recent addition of AceOptions based addons to RockConfig shows that this kind of interoperability is quite possible.

But I hear a lot recently that things are categorically impossible and I think I don't really understand the real reasons for all this, not that I think it helps to understand them.

For practical purposes I do see stuff that I like just plain happen so I'm not too worried really
Elsia is offline   Reply With Quote
Old 09-20-2007   #7
ckknight
Hero Member
 
Join Date: Apr 2006
Posts: 666
Default Re: Options and config abstraction (Rock, Ace3)

I've been pondering, as one like myself would ponder, about exporting the data-retrieval functions of LibRockConfig-1.0 and then having third-party libraries use these same functions to create their own configuration menus. This could be used for a dropdown system (a la Dewdrop) or a slash command system (a la AceConsole) or whatever. The major advantage to doing this is that it would eliminate the issue that Waterfall/AceConsole/Dewdrop had before where each had to write their own data retrieval functions and none would be consistent. The only problem that remains (that I honestly don't know how to solve) is that then things wouldn't necessarily be consistent from the user's point of view.
ckknight is offline   Reply With Quote
Old 09-21-2007   #8
halgrimm2
Member
 
Join Date: Sep 2008
Posts: 32
Default Re: Options and config abstraction (Rock, Ace3)

Quote:
Originally Posted by ckknight
I've been pondering, as one like myself would ponder, about exporting the data-retrieval functions of LibRockConfig-1.0 and then having third-party libraries use these same functions to create their own configuration menus. This could be used for a dropdown system (a la Dewdrop) or a slash command system (a la AceConsole) or whatever. The major advantage to doing this is that it would eliminate the issue that Waterfall/AceConsole/Dewdrop had before where each had to write their own data retrieval functions and none would be consistent. The only problem that remains (that I honestly don't know how to solve) is that then things wouldn't necessarily be consistent from the user's point of view.
To be honest, as long as the library code that handled all this was consistent and complete i don't think it would matter if the manner in which things were displayed was inconsistent. Most users would not mix and match the different display systems, they would just use the one they prefer and ignore the rest. The problem only arises if they have to use multiple display systems to be able to handle everything because certain things are only available in each one.
halgrimm2 is offline   Reply With Quote
Old 09-21-2007   #9
Azethoth
Amazing Member
 
Join Date: Jan 2006
Posts: 1,627
Default Re: Options and config abstraction (Rock, Ace3)

Quote:
Originally Posted by Industrial
You are basically describing a framework, toadkiller, and this isn't universal because of the same reasons multiple frameworks exist; Different goals, ideas and assumptions as to how it should work.

These elements are tied up and need each other in order to work, that's why they can't be standalone libraries.
That is true for the CLI & GUI, but the base lib just provides data and persistence for the data. For some mods that is sufficient & all they need. Mods that need preferences add either or both the CLI or GUI. I like ckknight's suggestion of having a common way of accesing things so another lib that traverses the options table & handles updates & refreshes etc. makes sense. This lib can maintain its own browsing state so the CLI & GUI open to the same spot when invoked (which fixes a pet peeve of mine which is the boring redrilling down to where I was & am most likely wanting to be).

Also note that while I suggest a single CLI & GUI, obviously a variety of ones can be built. However that would make extensions dificult. So perhaps a reference GUI is a better way to think about it. Compatible GUI's thus need to also be compatible with the extension mechanism.

So yes, it is a 1-3 library "framework", but I think it can be done to be capital F Framework agnostic. Also absolutely any mod at all could use it or just 1 or 2 parts of it. Now it is true that to do the CLI or GUI part you could & probably would use some specific framework but from a user & author's point of view the point is that your data get's saved & users can mess with the data they need to mess with & the author wrote very little code to do that. Also, unlike Ace b4 it it can become a standard across all mods willing to use LibStub. Additionally if it is extensible then the core can remain simple & unclutered & individual mods can add all the bloated goodness they need themselves.

Quote:
Originally Posted by ckknight
...The only problem that remains (that I honestly don't know how to solve) is that then things wouldn't necessarily be consistent from the user's point of view.
I don't get why that would happen? Do you mean that a particular data type may not show up in some version if it cannot edit it as Halgrimm mentions? Or that the CLI & GUI should present different views on the data?

Certainly for where AutoBar is going not all things are going to be possible in the CLI, or certainly not in a nice human usable way, although perhaps in ways acceptable for scripting purposes. As long as the GUI can handle everything required it should all work out fine...
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 12:13 PM.