[L2Ork-dev] preset_hub isues/questions
Ivica Ico Bukvic
ico.bukvic at gmail.com
Tue Aug 13 00:47:16 UTC 2013
On 08/12/2013 05:13 PM, András Murányi wrote:
> I'm attaching a test patch.
Many thanks for this! I identified and hopefully fixed the error with
the latest commit. Please see below for more info.
>
> I should also correct my previous statement in that having presets
> renumbered could potentially (likely) wreak havoc in respect to
> the rest of the patch as the preset model is number-dependent.
> Having said that, please convince me otherwise and I may consider
> implementing renumber feature, although it seems to me the coll
> solution should work just as well. Let me know.
>
>
> Well, coll is a swiss army knife that includes a machine gun and other
> handy tools :)
> I'd rather keep my presets in sync with something more basic like a
> list.When an item from a list is deleted, indexes naturally shift.
> (I guess there might be different use cases why someone wants to keep
> their presets in sync with something else; mine is keeping preset
> names, and to eventually feed them to a popup menu.)
> Then, if presets get cleared but never deleted, one will either have
> to reuse existing preset slots (complicated task when you want to keep
> the whole thing in sync with something) or indexes will reach the sky
> (which doesn't necessarily impose a practical problem but
> architecturally it's something dangerous) and you still cannot spare
> keeping track of those cleared slots.
> So, in order for preset_hub to be easily cooperate with list-based,
> list-behaving objects I suggest that beside the "clear" method there
> be a "delete" method which shifts the index numbers so they are always
> continuous.
>
> Thanks a Lot,
> András
OK, you convinced me (not that it was that hard to do so :-). So, the
updated git now has a new preset_hub and updated documentation,
including aforesaid bug fix, some other minor fixes in terms of missing
output from the preset_hub (e.g. when a store fails due to the fact that
preset numbers must be >= 0), and most importantly new "sort n" message
where n means the new starting number. All presets are therefore sorted
according to this starting value and go up from there by one. If n is
not given, sort defaults to 0.
HTH
Best wishes,
Ico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130812/e314bf60/attachment.html>
More information about the L2Ork-dev
mailing list