Resize the Preference Window

Questions & Suggestions
1

Continuing the discussion from Why isn't Custom HTML Prompt resizable?:

I have been wondering the same thing about the preferences in particular the clipboards tab. I would like to expand them a bit bigger if possible.

3 Likes
2

Since the preferences window resizes itself as you change preference panes, it is difficult to accomodate resizing by the user as well.

3

Good to know thanks.

4

Sorry to bring this up again but since I am now in Keyboard Maestro 8 and it has been awhile any chance that we’ll ever be able to resize the clipboards preference pane? I’d love to see full names of clipboards and not have to scroll through so many variables when I have much more space to resize on my display. Perhaps it could be a fixed size and then let the user resize it if that is easier to accommodate?

2 Likes
5

There is no particular plans to do this currently.

6

Okay thanks, we’ll maybe you can sleep on it and at least know it has my vote.

1 Like
7

I vote for a user-expandable Preference window as well. It would be very handy to see ALL my variables without scrolling.

2 Likes
8

IMO, the real issue is that lists like Variables and Named clipboards are not really preferences, and therefore don't belong in the app Preferences.
What not show them in separate resizable windows, accessed from the "View" or "Window" menu? That should make it much easier to implement.

5 Likes
9

That makes great sense to me!!

10

I very much agree with this and have often wondered why it was in the preferences. It would be awesome if these were moved to the windows menu and were given their own key commands of
⌘+7 Clipboards
⌘+8 Variables

and resizable windows.

image
image853×173 12.4 KB

11

You know what... I like your idea.

But there are probably lots of consequences of making that change, for no benefit.

One problem that I have with both the status quo and your suggestion is that the editor isn't the authentic source of variable values. It is a secondary source, or possibly a tertiary source. The primary source is the Engine, which probably saves new values from time to time in the plist file, and the Editor (the current Preferences window) either gets its values from the plist file or from the Engine (I'm not sure which one.) So my suggestion is that variables are NOT displayed from an Editor-owned process, but from an Engine-owned process, which is accessible from the KM icon on the system tray.

12

Interesting, I am all in favor as long as I can resize, see edit and work with it easier than I can in the preference window. If somethine else makes more sense by all means. Do you ever work directly in the Engine? The editor seems to be the way to get things edited for the engine so I would love to understand what you are saying better.

I have right clicked on the on Keyboard Maestro Editor in the dock as well as the menu icon in the top and dont see that option but probably something I need to enable.

I did however find "Active Macros Groups" which is super handy since it is clickable to troubleshoot what groups I expect to see in each application so thanks for that :grinning:.

13

You did nothing wrong. I worded my sentence poorly. All I meant was that the Engine itself was accessible from the system menu icon, and that that's where I felt access to variables should be granted from.

Yes! I'm constantly using the debugger, which runs from within the Engine, not within the Editor. Indeed, you can even see some variables in the Engine through the debugger window if you press the button in the upper right corner of the window. Now that I think about that, maybe that's good enough.

14

Oh gotcha, I never really thought of that being part of the engine directly but when I do press quit I knew it qute the engine so that makes sense.

I have pressed the X but I am probably in the wrong place. I selected "Start Debugging" since that is all I see in in the menulet for debugging.

image

This makes sense, since you have to get the variable values from the Engine in AppleScript before you can use them.

( Engine Variable ) 
tell application "Keyboard Maestro Engine"
  -- Get the value of the KM variable "ToggleText"
  set searchText to getvariable "ToggleText"
end tell

tell application "Keyboard Maestro"
  set selectedMacrosList to get selectedMacros
  
  repeat with theMacro in selectedMacrosList
    set macroName to name of macro id theMacro
    
    if macroName ends with searchText then
      -- Remove the text if it is present
      set name of macro id theMacro to text 1 thru ((length of macroName) - (length of searchText)) of macroName
    else
      -- Add the text if it is not present
      set name of macro id theMacro to (macroName & searchText)
    end if
  end repeat
end tell
15

You are in the right place. I think you don't understand that it shows variables only for running macros. This is a limitation, but it's usually an acceptable limitation. It also limits the display of variables to ones which have been changed in your running macro. That limitation is usually acceptable too. It's very useful once you know how it works.

Or you could get them from the file that the Engine updates.

16

Oh yeah I agree. I was just thinking you were saying there was a way to see all of them in a resizeable window through the engine. That makes sense now.

That's cool, I have no idea how to do that. I guess in theory that would be slightly faster since the engine wouldn't have to be called and then do that itself.

17

I suspect an SSD is slower than RAM, but I'm certain that an HDD is slower than RAM.

18

You've just found your next project...

Custom HTML Prompts are resizeable. Using JavaScript, you can get and set variable values, trigger macros, run AppleScripts.

All ( :wink: ) you have to do is put those pieces together to make your own resizable variable editor.

19

I was kind of thinking that myself last night when you told me about that. Thank you :slightly_smiling_face: