• 0

    posted a message on Objective Tracker Replacement [planning]
    Right, so I'm in the process of rebooting an old project of mine, starting from scratch. Figured I'd share some of my plans regarding design philosophy, because doing so would present me with the opportunity of perspective. And such is always nice. Anyway, on to it, although if it ends up being somewhat incoherent, it could be due to sleep deprivation. I blame the weather.

    Righto. So I'm planning on making it modular, and making it possible to plug in to the addon. Before I detail this more, I should probably discuss the core a bit more.

    I'm planning on splitting the core addon three-ways. One part specializing in handling the widgets, one part specializing in config options, and one part for tying it all together.

    The widget part will deal with linking frames together, sorting them, recycling. All that fun stuff. I have that one mostly figured out. It will have widgets grouped into custom objects in a hierarchy following something akin to: tracker frame > module frame > object > objective. Only this part of the code will directly modify the widgets. The 'core core', config manager or plugins will only be allowed to do so via internal addon functions.

    As for the config part, there is not really much to say. AceConfig options table, where plugins will have some predefined config options, it will then be expanded to include a table of config options specific to that plugin. For the latter, plugins will be responsible for handling their own specific options table in terms of getter/setter functions, and as such also storing the actual config values.

    So, like I mentioned, the core would then be responsible for tying these things together. Essentially, a plugin would register with the core, passing along a name and an optional partial options table. The core will then create a module frame object for it, keep a local reference to it, and spit back an object with a metatable set to it that contain an __index entry for the relevant functions. It will not be given a reference to its gui widget, because we can't go around breaking abstraction.

    Some of the functions it would be given would deal with adding/removing objects/objectives, triggering resorting based on custom sort fields. I may also want to give plugins the ability to add stuff to the addon's LDB label.

    And to briefly retouch the gui widget thingies, all but objectives are likely to be uniform, with objectives being able to have different styles. What currently comes to mind being description-only, statusbar, and counter (left-hand description, right-hand counter.)

    Admittedly, there are a whole range of details omitted, but then again, this post is intended to deal with the more overarching stuff.

    Before I attempt to pass out again, some of the indented plugins are, well, the obvious: quests, achievements, dungeons - the stuff currently covered by the objectives tracker. Only pwettier, hopefully. And will probably expand to make a daily/weekly tracker as well, which will have some predefined sets, that will account for quests that may vary on a daily basis, as well as the option to add more under the provision the quest id is known.

    Right. Thoughts or requests for clarification are welcome.

    Edit: Is this in the proper subforum, though? It seems it's more an addon idea than lua discussion, anyway. Aah! Halp!
    Posted in: Addon Ideas
  • 0

    posted a message on LibPrism-1.0
    Quote from Aiue
    Although given the way I've ended up writing things now, I'm wondering if I should move GetAngleGradient() into just GetGradient() (or Gradient()), passing the desired gradient type to it. For the sake of cleanliness. I'd keep GetAngleGradient() for backwards compatibility, though, but point it to the new function, should it be implemented.

    The benefit of having one function to fetch any type of gradient would be that it would be cleaner to fetch based on conditionals such as user configuration.

    I did just that. Different gradients will be added later, though. In the meanwhile, I certainly wouldn't mind if someone tried breaking the lib for me.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Quote from Pelf
    The most odd stuff was with the multiplicative functions. If the multiplicative Saturate function basically does:

    v = v * (1 + m)

    Then, passing -0.3 ends up multiplying v by 0.7 which is ... not that it doesn't make sense, but it is interesting.

    ...right. *facepalms @ self*
    Obviously I did get involuntarily drunk without realizing it while writing that. I can do away with the silly if ... elseif ... else completely, because the end result will be the same regardless.

    Quote from Pelf
    So anyway, rambling ... but it's an interesting side effect of trying to make things nicer. I see you're considering this stuff, already.

    Well, I suppose it's a natural thing to consider. :p

    Although given the way I've ended up writing things now, I'm wondering if I should move GetAngleGradient() into just GetGradient() (or Gradient()), passing the desired gradient type to it. For the sake of cleanliness. I'd keep GetAngleGradient() for backwards compatibility, though, but point it to the new function, should it be implemented.

    The benefit of having one function to fetch any type of gradient would be that it would be cleaner to fetch based on conditionals such as user configuration.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Quote from Pelf
    What would be the behavior of passing negative values to a multiplicative Desaturate? What about to a multiplicative Saturate?


    function Prism:Saturate(r, g, b, m, operation)
    ...
       if operation == TYPE_MULTI then
          -- Have to take special care of negative values here.
          if m < -1 then m = 0 elseif m < 0 then m = 1-(math.abs(m)) else m = 1+m end
          s = s*m
    ...
    
    function Prism:Desaturate(r, g, b, m, operation)
       return self:Saturate(r, g, b, -m, operation)
    end

    Unless I've managed to get myself drunk without realizing it, that should mean that any negative value passed will decrease the value with the specified percentage, and decreasing anything by 100% or more, with the lowest allowed value being 0, would result in setting it to 0. Similarly, positive percentages have no defined maximum value, as for instance, 300% of .1 will not exceed the maximum saturation of 1.

    Since I do have:
       if s < 0 then s = 0 elseif s > 1 then s = 1 end

    before passing the return, I could as well just skip the if m < -1="" check="" i="" placed="" in="" the="" multiplicative="" conditional,="" though,="" i="">

    Also, right. That didn't actually answer the question. And I suppose it is something that may need some more thought. Then again, desaturating something by 100% does seem to imply completely desaturating it. So I suppose sticking with the above may well be a sensible approach.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Quote from Phanx
    Well, one could easily argue that RGB<->HSV conversions do nothing but perform arithmetic on values, so they don't warrant inclusion either. :p

    Pff, they do conditional arithmetic operations! :p

    Also, I'm not sure my saturate/desaturate (and possible lighten/darken) are spitting out proper values at the moment. I think there may be a problem with my conversion algorithms currently. So I'll be having a look at that, as well as finishing the work I've begun on allowing for multiplicative operations.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Quote from Pelf
    Also, would an additive Saturate with a negative value be the same as an additive Desaturate? Are those functions going to reject or math.abs negative values?

    Well, I hacked together a couple of functions for saturation and brightness, accepting modifier values within the [-1,1] range. So basically one could desaturate by passing a negative value to the saturate function, which is actually how I decided to write the counterpart functions Prism:Desaturate() and Prism:Darken().

    They do not yet accept a fifth argument, but I will probably make them do so soon, while taking the above post in consideration. The validation for a multiplicative modifier value will have to be a bit different, though, but just increasing the accepted range to >-1 and simply using 1+m as the factor should do the trick. Would need to tweak Desaturate and Darken, though.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Hum, still trying to figure out a good way of doing the whole saturate/desaturate and darken/lighten things in a way that warrants inclusion. The only thing those functions would really do would be to convert to hsv, perform arithmetic on one of the values, then convert it back.

    Granted, getting the angle gradient is not all that different in that regard, the main difference being it performs an operation on each of the values. With that in mind, including the above mentioned functions may well be equally warranted.

    I just have to figure out if the best way to go about it would be to accept a fixed value to modify by, a percentage, or both.

    Possibly something akin to:
    function Prism:Saturate(r, g, b, m, isPercent)
        local h,s,v = Prism:RGBtoHSV(r,g,b)
        if isPercent then s = s*(m+1)
        else s = s+m end
        if s < 0 then s = 0 elseif s > 1 then s = 1 end
        return Prism:HSVtoRGB(h,s,v)
    end
    


    With some sanity validation checks included.
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    Quote from Phanx
    A rather unfortunate name in light of recent NSA news, lol.

    Ugh, right. It seemed somehow fitting, though. >.

    Quote from Phanx

    (1) You need to use the package-as directive in your project's .pkgmeta file so that the packager names your folder properly to match your TOC file. Right now it's using the default from your project's URL slug, which is "libprism-1-0" which does not match the "LibPrism-1.0" used in your TOC file's name. This will prevent your lib from loading standalone, which is how most developers and some users will run it.

    Yeah, I noticed that and poked the "package as" setting. Gonna nudge it into the .pkgmeta as well before my next push.

    Quote from Phanx
    (2) Methods for "darken/lighten/saturate/desaturate the specified color by X%" could be useful. See https://github.com/minism/leaf/blob/master/color.lua for some color-related functions in Lua you can "be inspired by".

    Oooh. Yeah, ideas for more functionality is something I'm interested in. I suppose the main point should be to aim for useful (as you argued) functions. But I will look into that, and possibly other types of gradients as well.

    Quote from Phanx
    (3) Passing tables around seems sub-optimal, as it forces addon authors who wouldn't otherwise be using tables for their color values to either implement table recycling or waste the garbage collector's time with single-use tables. I'd suggest accepting individual RGB values instead. If you want to keep accepting tables (and strings? though I don't think I've ever seen an addon storing colors internally as strings) you can easily do that:

    Seems reasonable enough. And should someone ever find the need to call the function from a base-16 variable, converting is easy enough on their end.

    Thanks for the feedback. :)
    Posted in: Libraries
  • 0

    posted a message on LibPrism-1.0
    So I decided to stop being lazy and learn Lua, the WowAce framework and the WoW API. Started tinkering with an addon and realized "hey, this should be in a library!", yet I couldn't find any seemingly maintained libraries doing what I needed. The result is LibPrism-1.0.

    So, what does it do? Well, the intent is to have a library that will provide color manipulation tools. It doesn't do very much on that end yet, with only three functions, but I'm open to ideas and suggestions in that regard. I'm hopefully not too shy when it comes to collaboration, either. Give me a poke if you want in on trying to increase the usefulness of this project and such may or may not be arranged.

    Right, so I didn't really answer my own question in the previous paragraph, other than quite vaguely. To elaborate a bit, but just a little bit, on the three functions, there is one for calculating the angle gradient between two colors, then two for converting between hsv and rgb.

    Project page: http://www.wowace.com/addons/libprism-1-0/
    Documentation: http://www.wowace.com/addons/libprism-1-0/pages/api/ (Once I get the documenter working, anyway. Right now it's just a placeholder page, documentation is available on the main project page until then.)

    Edit; Sample:
    Posted in: Libraries
  • To post a comment, please or register a new account.