williballenthin / ida-settings Goto Github PK

As nice as it is to have all settings easily stored, it is not too useful without a way to edit them.
In the present situation, every plugin writer needs to create some way of modifying the settings of his own plugin (much like I did with IPM.)

A far better solution will be a GUI to allow easy viewing and editing of all the settings.

Sadly, this means writing a GUI...

In the current state it is inconvenient to edit anything but numbers.

It would be great if the GUI will display different editing options for different data types. Raw text for strings, numeric input for numbers, a list-view of sorts for lists, a table for dicts...

Further improvements may include editors for "user-defined" types, such as colors.

On Windows, when trying to write to the system-settings using an unprivileged user, you get no error, but the value is not written.

The write attempt should probably raise some error, so that the user knows what happened.

via the original discussion by @tmr232:

Regarding the 1024 bytes limit. I find it a bit problematic. The first plugin I wanted to use ida-settings is my plugin-loader. The loader currently holds a list of paths for all the plugins it loads. Paths are naturally long, so the data is easily over 1024 bytes. Any solution that resolves that on the plugin side is bound to be messy.

Any thoughts on that? I am leaning towards letting a JSON dump spread over several nodes.

This will make installation a lot easier.

Just like with the other settings, I'd like to be able to manipulate the directory settings from outside IDA. This should be easily possible by implementing an API that looks like settings = IDASettings("my plugin", directory="path to directory with settings").

I'd be just as happy to be able to change IDB settings without opening IDA, but that would require parsing and editing of the IDB outside of IDA, and while that might be an interesting project, it is far out of scope here.

Trying to develop on the capa master branch, which now depends on ida-settings. This causes an exception:

C:\Program Files\IDA Pro 7.5\plugins\capa_plugin_ida.py: string argument without an encoding
  ...
  File "C:\Users\<user>\AppData\Local\Programs\Python\Python37\lib\site-packages\ida_settings-1.0.1-py3.7.egg\ida_settings\ida_settings.py", line 859, in <module>
    VALUE_1 = bytes("hello")
TypeError: string argument without an encoding

The line no longer exists in the master branch of ida-settings, suggesting the port to Python 3 fixed it.

Would it be worth publishing the latest version of ida-settings to PyPI, so this dependency can be correctly installed?

If the idaapi and idc imports will be optional, it will be possible to configure system- and user-settings outside IDA.

This could be useful when setting up on a new computer, or when updating settings that require restarting IDA (like my plugin loader plugin).

should blacklist the character '/' (which is used by QSettings subgroups), but everything else should be ok

When using ida-settings outside IDA, there are still some issues:

1. Using settings['some-key'] fails with an EnvironmentError. See here.
2. Accessing directory settings raises NameError: global name 'idc' is not defined instead of an environment error like the idb settings.

From my experience, simply importing the Qt modules into IDA can result in issues if they are installed as standard Python modules as well.

I have an ugly solution for that in Cute.

see: https://github.com/williballenthin/ida-settings/pull/9/files#diff-ed394b18efd10ea18953360b54e6b716R708

this won't quite work. this property is meant to be a 'class property', that is, a property available from the class object itself, and not a specific instance. the intent is allow you to be able to query for all plugin names, without knowing any of them (and therefore, being unable to instantiate any IDASettings).

my initial reaction was to be:

as a temporary fix, until more discussion, i'm going to move the config directory to a keyword parameter to directory_plugin_names(). this will allow you to specify the working directory.

however, this doesn't work, because these are properties, which don't accept arguments.

therefore, my thinking is to update these accessors to be methods, rather than properties, that would look like:

def get_system_plugin_names(self):
def get_user_plugin_names(self):
def get_directory_plugin_names(self, config_directory=None):
def get_idb_plugin_names(self):

any issues?