[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