[Suggestion] Access .inc files from right-click context menu?

[Cariboudjan]

Would be really useful if right-clicking on a skin gave immediate shortcuts to any .inc files used in that skin. Sometimes its really hard to figure out what .inc file is being used in the file, or where its located, especially if that .inc file name contains a variable.

Since variables inside includes cannot be dynamic, having the context menu items listed as they are used should be easy, shouldn't it?

Screenshot 2022-03-25 105156.png

Screenshot 2022-03-25 105656.png

[death.crafter]

Not really, no. This is not related to what the context menu is supposed to do, i.e. control the skin and have a few functionalities related to Rainmeter.

But if you want one for development you can make a plugin to capture the right click on any skin and show a custom menu. I mean it's not as easy as it sounds, but yeah, it should be an one time thing, and interesting one tbh.

[Cariboudjan]

I mean, the context menu is to help facilitate users to edit/manage the skin. Often variables like Color, Opacity, Position, Size, etc. are all located in .inc files. The "Edit skin" button alone isn't sufficient in this case. I think it is very relevant to what the context menu is supposed to do.

[Yincognito]

Would be really useful if right-clicking on a skin gave immediate shortcuts to any .inc files used in that skin. Sometimes its really hard to figure out what .inc file is being used in the file, or where its located, especially if that .inc file name contains a variable.

Since variables inside includes cannot be dynamic, having the context menu items listed as they are used should be easy, shouldn't it?


Screenshot 2022-03-25 105156.png

Screenshot 2022-03-25 105656.png

I wouldn't say no to such a feature, it looks useful and related to what the context menu does. Not sure if one wouldn't enter into a bit of clutter when it comes to @includes within @includes, but then, it can't be worse than how other submenus look like, say, for a skin suite with lots of subfolders.

[jsmorley]

I see absolutely no prospect that we would read and parse the entire .ini file looking for @Include... statements, then finding and reading and parsing each and every one of those, digging and digging for @Includes inside of @Includes inside of @Includes, to some undefined level, and then trash up the context menus with them.

If a skin author wants to expose one or more @Inlude files so they can be edited by an end-user, that can be done easily enough with custom context menus.

Code: Select all

[Rainmeter]
Update=1000
AccurateText=1
SkinWidth=170
SkinHeight=342
BackGroundMode=2
SolidColor=255,0,0,0
MouseScrollDownAction=[!Refresh #CURRENTCONFIG#]
RightMouseUpAction=[!SkinCustomMenu]
ContextTitle=#ContextLocationString#
ContextAction=[https://www.google.com/maps/search/#Latitude#,#Longitude#]
ContextTitle2=[@CurrentObservationDate]
ContextAction2=[]
ContextTitle3=#ObservedAt# [@CurrentObservationTime] [@LocationTimeZoneAbbreviation]
ContextAction3=[]
ContextTitle4=----
ContextAction4=[]
ContextTitle5=#ChooseLocation#
ContextAction5=[!ActivateConfig "#CURRENTCONFIG#\WeatherComCodes" "WeatherComCodes.ini"]
ContextTitle6=----
ContextAction6=[]
ContextTitle7=#EditWeatherVariables#
ContextAction7=["#@#\WeatherComJSONVariables.inc"]
ContextTitle8=#EditTranslationVariables#
ContextAction8=["#@#\WeatherComJSONLanguage.inc"]
ContextTitle9=#EditGeneralVariables#
ContextAction9=["#@#\GeneralVariables.inc"]
ContextTitle10=----
ContextAction10=[]
ContextTitle11=#Open@ResourcesFolder#
ContextAction11=["#@#"]
ContextTitle12=----
ContextAction12=[]
ContextTitle13=#MoreActions#
ContextAction13=[!SkinMenu]

Code: Select all

[Variables]
@Include1=#@#GeneralVariables.inc
@Include2=#@#WeatherComJSONVariables.inc
@Include3=#@#WeatherComJSONMeasures3Day.inc
@Include4=#@#WeatherComJSONLanguage.inc
@Include5=#@#WeatherComJSONAlerts.inc

1.png

[Yincognito]

I see absolutely no prospect that we would read and parse the entire .ini file looking for @Include... statements, then finding and reading and parsing each and every one of those, digging and digging for @Inlcudes inside of @Includes inside of @Includes, to some undefined level, and then trash up the context menus with them.

If a skin author wants to expose one or more @Inlude files so they can be edited by an end-user, that can be done easily enough with custom context menus.

I get what you mean with finding and reading and parsing and digging and whatnot, although I don't share the negativity, LOL. The suggestion was for cases when skin authors don't expose those to the end-user though (or, for the unlikely cases where there isn't any more room in the custom context menu for such an exposure).

I mean, the context menu is to help facilitate users to edit/manage the skin. Often variables like Color, Opacity, Position, Size, etc. are all located in .inc files. The "Edit skin" button alone isn't sufficient in this case. I think it is very relevant to what the context menu is supposed to do.

Another (half) solution to this could be to recursively parse those include files from Lua:

Code: Select all

function Initialize()
  includes, iform = {}, '^@[Ii][Nn][Cc][Ll][Uu][Dd][Ee].+=(.-)$'
end

function Update()
  return IncludeFiles(SKIN:ReplaceVariables('#CURRENTPATH##CURRENTFILE#'))
end

function GetFileIncludes(rawpath)
  local path = SKIN:ReplaceVariables(rawpath)
  local count, file = 0, io.open(path, 'r')
  if not file
    then print('Unable to load file ' .. path)
    else for line in file:lines() do if line:match(iform) then includes[#includes + 1] = SKIN:ReplaceVariables(line:match(iform)); count = count + 1; GetFileIncludes(includes[#includes]) end end; file:close()
  end
  print('Found ' .. count .. ' include lines in file ' .. path)
  return true
end

function IncludeFiles(rawpath)
  includes = {}; GetFileIncludes(rawpath)
  for i = 1, math.min(#includes, 25) do
    SKIN:Bang('!SetOption', 'Rainmeter', 'ContextTitle' .. (i == 1 and '' or i), (includes[i]:gsub('^.+\\(.-)$', '%1')))
    SKIN:Bang('!SetOption', 'Rainmeter', 'ContextAction' .. (i == 1 and '' or i), '["' .. includes[i] .. '"]')
  end
  return 'Include Count: ' .. #includes .. '\r\n' .. table.concat(includes, '\r\n')
end

by adding a simple negatively updated script measure in the desired code:

Code: Select all

[Variables]
@Include0=#@#Include0.inc
g=7

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1

---Meters---

[MeterTest]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Include Files: [Script]"
UpdateDivider=-1
DynamicVariables=1

TestIncludes_1.0.0.rmskin

GetIncludesLua.jpg

It's a half solution because Lua can't properly read UTF-16 LE files (for example, all the include test files used above were encoded as ANSI in Notepad++). An alternative would be to recursively parse the local files using WebParser, a perfectly possible task via self updating and sequentially accessing files to simulate the Lua's FOR loop, though it might require some CodePage kung-fu in order to switch between ANSI and UTF-16 LE as needed. Using one of these two alternatives, assuming the encoding part is reasonably solved, would allow you to get the includes custom menu for any skin, whether or not the author exposed the files already or not, just by (temporarily) inserting the said code in the skin.

P.S. Death.crafter said recently that he doesn't know how to access the Rainmeter section from Lua. Not sure what he referred to, but if it's about writing to the custom context menu, this is how.
P.S.S. By the way, there's a small inconsistency in the manual at the bottom of the !SetOption Guide where it says that one cannot use the bang to change "any" option from the Rainmeter section. The fact that this is possible for the custom context menu (which is mentioned in other places) is omitted.

[Cariboudjan]

I'd prefer to see this on all skins as a default feature. Let's be honest. Even if this is possible to do as an add-in, the fact that it's not a default feature means that 99% of skins will not have this capability and 99% of casual users who do not understand how to find a .inc file are going to have difficulty editing basic parameters like opacity and color.

I'm not suggesting this as something that benefits people that are already rainmeter veterans. Of course you can create your own custom context menus with links to the .inc files - But the vast majority of authors will not implement this.

Ultimately everyone would benefit from such a feature if it were just included in the standard menu.

[Yincognito]

I'm not suggesting this as something that benefits people that are already rainmeter veterans.

Do you think Rainmeter 'veterans' like to look into dozens of files to find out exactly what .inc is holding the problematic variable or measure when helping out? Don't worry, it will benefit these veterans as well. But then, suggestions are not as attractive as those little bugs - something I noticed a long time ago.

[Cariboudjan]