Comfortable way to code long actions?

[Active Colors]

Hi there. At first I would like to say that what I really love in Rainmeter is that the process of making(coding) skins is really simple and makes sense comparing to other difficult programming languages. Beautiful! But there is one thing that sometimes it makes harder to code and entangles me every time when I see them - big amount of bangs in one action.

rm4.png

This is the piece of code I was doing one year ago. Couple of hours before I have decided that it is time to fix the skin but I couldn't comprehend all my crap there . Basically because all bangs go one after another in one single line with a wordwrap which divides bangs so that every other bang starts in the end of one line and finishes on another line. Thus it is difficult to concentrate and follow it. What I'm currently doing is breaking up all bangs into each line, then remaking/recoding/fixing/doing all the stuff which requires to fix the skin and then accumulating all the lines with bangs into one line. But it is not so convenient as there are might be over 90 bangs to unify into one line. Sometimes I regulate windows' width of a notepad++ to see a better picture of the code (see the spoiler below) but it is not so good approach for this issue

So, does anybody have any ideas or suggestions regarding this occasion? I will really appreciate any help.

[jsmorley]

There really is no good way to make this much simpler. You could shorten things a little by having some shorter static [Variables] for longer things like #ROOTCONFIGPATH#Work Launcher.ini that you use repeatedly, but the very nature of a .ini file is that each Key=Value is on a single contiguous line. That is why we needed to create #CRLF# to support a literal linefeed in the value.

You could take advantage of the search / replace capabilities of Notepad++ to do something where you put each one on a separate line, which would make reading and copy / pasting over and over a lot easier, then when you are done just do an "extended" search for "\r\n" and replace that with nothing... That will remove the carriage return / line feeds and make it all one contiguous line that you can paste into the .ini. Makes it a little harder to iteratively test though.

test.gif

Oh, and "holy crap!"

[iNjUST]

Jsmorley's suggestion for line breaks is good. You could also probably take your existing actions chain and do Replace: ][ with: ]\r\n[ to convert it to "reading mode" and then do jsmorley's process above to switch it back to "action mode".

I'm not sure what your code does, but it seems like it changes a whole slew of options in some meters. One possible alternative--if it could apply to your specific situation--is to use @include options to switch between configurations...

So if you're switching between 2 (or more) configurations for your skin, create 2 (or more) different files that contain only the meters/measures that get changed in their respective different versions/configurations. If we name these files config1.inc and config2.inc, you could just set a Variable number=1 and write @include=#CURRENTPATH#config#number#.inc. Then when you want to change all of the options to number 2's version, just do [!WriteKeyValue number 2][!Refresh].

Again, your code is too complicated and out of context for me to have any idea how you intend it to work, so this might not apply.

[Active Colors]

I'm not sure what your code does, but it seems like it changes a whole slew of options in some meters.

Well, that piece of code is my first real experience with making settings panel which changes lots of settings in real and depending on different settings whole thingy should be able to work properly so I somehow came with "this". But never-mind, that was just an example from the past and now I know pretty well how to make all that stuff compact with little amount of bangs. Thanks for the tips anyways.

Really thank you guys! This method of breaking up and connecting back is really handy.








Though I can't simplify anything here. And there are forty meters like this :c

rm2.png

[FlyingHyrax]

This might be a bit overkill, but if I were dealing with actions that long I might try applying Lua. You can create a script file with functions for each of your really long actions, and keep different bang sequences in tables. Then you can concatenate or iterate over the tables to execute with SKIN:Bang(). Though, I suppose that this approach probably would introduce some additional overhead, depending somewhat on the implementation of the Bang() function (which I haven't checked). But if these are configurations actions which are rarely executed, that probably wouldn't matter too much anyway.

[Active Colors]

This might be a bit overkill, but if I were dealing with actions that long I might try applying Lua. You can create a script file with functions for each of your really long actions, and keep different bang sequences in tables. Then you can concatenate or iterate over the tables to execute with SKIN:Bang(). Though, I suppose that this approach probably would introduce some additional overhead, depending somewhat on the implementation of the Bang() function (which I haven't checked). But if these are configurations actions which are rarely executed, that probably wouldn't matter too much anyway.

Well, if it is possible and not time-consuming for you - I would definitely try that :)If you have spare time of course.

[FlyingHyrax]

Here's a simple skeleton implementation of what I had in my head (untested)

Code: Select all

--[[
Each subtable is just a list of strings, where each string is a valid bang.
This way, an individual action (group of bangs) can be referenced as ACTION.name,
and you can mix and match actions together by doing things like:

  function doOneAndTwo()
      runBangs(ACTIONS.action1)
      runBangs(ACTIONS.action2)
  end

]]
local ACTIONS = {
    action1 = {
        '!HideMeter Block16',
        '!CommandMeasure Transition "MoveToY(\'Block1\', (5+75))"',
        '!SetWallpaper "#WALLPAPERPREV3#"',
        '!EnableMeasure Unhide3',
        '!Redraw'
    },
    action2 = {
        -- more stuff
    },
    action3 = {
        -- some things
    }
}

--[[
Assumes that the values in a table are strings that can be run as bangs,
and executes each individually.  This function supports having strings in 
the table that contain multiple bangs (like "[!one][!two]") since each 
entry in the table is executed separately.
]]
function runBangs(tableOfBangs)
    for _, v in tableOfBangs do
        SKIN:Bang(v)
    end
end

--[[
Given a table of containing *individual bangs*, joins them 
together into one action where each is surrounded by [].  Things 
will break if any of the strings in the table already contain 
multiple bangs using the "[!someBang][!otherBang]" syntax
]]
local function concatenateBangs(tableOfBangs)
    return '[' .. table.concat(tableOfBangs, '][') .. ']'
end

--[[
Alternatively, joins all the bangs together into a string and
executes them at once.  (Fewer calls to SKIN:Bang, but you still have to 
iterate over the whole table to join them all together.) 
]]
function runBangsAlt(tableOfBangs)
    SKIN:Bang(concatenateBangs(tableOfBangs))
end

--[[
In the skin, you can then use:

    '!CommandMeasure "ThisScript" "runBangs(ACTIONS.action1)"'

...or create "alias functions" like this one to make things shorter
(helpful if you wanted to have once function call execute
more than one group of bangs) and you could say:
    
    '!CommandMeasure "ThisScript" "doAction1and2()"'
]]
function doAction1and2()
    runBangs(ACTIONS.action1)
    runBangs(ACTIONS.action2)
end

So in the ACTIONS table you can add subtables for groups of bangs, then just call one of the two 'runBangs' functions using !CommandMeasure and pass the subtable as an argument (see the comments in the script for a couple of examples). Note that this might require you do some quote escaping in strings. But, this lets you keep your bangs organized into groups that you can reuse and mix together. The other advantage is that you can write functions that return a table of bangs - so in cases where the bangs are very repetitive or mathematical you can generate them programmatically. Again, this introduces some performance overhead because you're having the script rewrite lists of bangs at runtime instead of hardcoding them, but it might make your life easier.

This is a pretty general solution and not very efficient, especially in your case where you seem to be making very heavy use of the Lua Transitions script - so you'd be sending a Bang to the configuration script, which sends bangs back to the skin, which sends bangs to another script, which then does the transitions. It might be worth editing the transitions script (since we don't have require()...) to add your own functions, to interface with the transitions script more directly. You can just add any number of functions like this at the bottom of Transitions.lua:

Code: Select all

function moveThings()
    MoveToY('Block1', (5+75))
    MoveToY('Block2', (5+75+105))
    MoveToY('Block3', (SKIN:GetVariable('WORKAREAHEIGHT') / 2 - 32 + ))
    -- move more meters here...
end

Then call it with !CommandMeasure "Transitions" "moveThings()"

[Active Colors]

Thanks for all those explanations. I will play around with it for the next couple of days or so to make it work in the skin.