AkelPad

Добрый день.
На данный момент в программе используются ini файлы в кач-ве настроечных (помимо варианта хранения в реестре, кстати список последних файлов также неплохо отвязать от реестра), причем субъективно в довольно сомнительном "винигрете", т.е. в директории "Plugs" помимо бинарей лежат ini-шники, основной файл настроек лежит рядом с исполняемым файлом. Субъективно опять же, смысла в этой каше не вижу, как человек сам пишущий программы, почти уверен, что так получилось потому, что так получилось (рекурсия в общем).
В общем предлагаю сделать профили настроек, что это такое и как выглядит думаю известно, и (это важно) переключение между активными профилями в программе и запуск активного профиля по ключу в ком. строке: i.e. (подсмотрено в Hippo Edit) при запуске с параметром пути к файлу активен режим (т.е. профиль) "просмотра" (ридонли, все панельки скрыты, etc), при открытии файла из программы (либо просто открытии программы) вид "a'la IDE", т.е панели эксплорера, фолдинга, клипборда, инкрементального поиска, etc. Думаю можно найти еще массу возможных вариантов применения данной фичи и вполне вписывается в концепцию AkelPad.
Спасибо за внимание.

На мыслю натолкнула идея отсюда.
Было бы здорово иметь такой "переключатель" в самой программе - плагин, к примеру "Менеджер конфигураций" или "Профилей". Ведь у меня почему так прога выглядит? Потому что ставлю её ещё другим своим пользователям, которым "программерские" штуки не нужно видеть, потому и стараюсь их спрятать для них подальше (чтобы в глаза не сильно бросалось), но и не слишком далеко от себя
Для начала бы хотелось конечно унифицировать Toolbar-плагин по интерфейсу и функциональности с ContextMenu, т.е.:
• настройки всех тулбаров в одном Toolbar.ini;
• в окне настроек тулбары задавать как и меню: • вверху Combobox с выбором меню;
• внизу галки местоположения.
А потом бы плаг, в котором как в Sessions-плагине переключать конфигурации.
В каждой конфигурации хотелось бы запоминать настройки как минимум: Toolbar-плагина (отображение определённых тулбаров и их положение), ContextMenu-плагина (отображение определённых меню и их положение). Возможно, Hotkeys-плагина.
Ну и настройки плага (ini-файл) хранить в дирректории пользователя (AppData), чтобы у каждого пользователя компа можно было установить свою конфигурацию.

На счет "ini_где-нибудь_ещё" можно попросить Instructorа сделать возможность редиректа ini: т.е., ini в папке программы может содержать единственную строкуИли, даже, если эта строка первая, то остальные строки игнорируются. Комментим такую первую строку - получаем портабельное приложение, ставим это юзверю, раскомменчиваем только одну первую строку - инишник создаётся где сказано.

Serge Yolkin
Это было бы здорово!
Но, по моему, какие-то левые пути прописывать нет необходимости. Нужно только 2: в директории программы и в директории пользователя (AppData), т.е. можно было бы (и это было бы лучше) сделать в настройках.

Instructor
Просим!!!

VladSh
Боюсь, до настроек юзверёк дотянется быстро, а потом будет здесь ныть, что у него "не сохраняется". ИМХО, лучше уж в инишнике, а для сетупа сделать такой инишник по умолчанию (из одной строчки).

Фикус в том, что в понятие "профиля", по-хорошему, могут входить настройки всех имеющихся плагинов, а также настройки самого Акеля (как минимум расцветки, плюс набор автозапускаемых плагинов). Поэтому если делать per-user профили, это решается довольно просто (набор настроек в AppData), а вот если собственные, в рамках одного юзера (возможность переключения "кодинг"/"печать"/"минимал"/...) - то это нужно заводить отдельную папку profiles, и в ней уже подпапки с настройками каждого профиля. Не столь великая задача, но всё-таки требует усложнения процессов чтения настроек. А также введения специальных функций для получения текущего пути к настройкам.

Если уж редиректить, то, ясен пень, все настройки. Иначе в тех же Program Files что-то не сохранится. А свои профили проще реализовать несколькими сборками AP. С редиректом, или без. У меня установленный в систему (замена блокнота) - минимальный, а для кодинга - портабельный, но ассоциирован с файлами через внутренние ассоциации портабельного же TC. Из винды имеем почти тот же блокнот, а из тотала - вполне себе разукрашенный Акел.

Fr0sT
Одно не мешает другому. AppData - для хранения настроек, которые могут часто изменяться.

Я предложил, чтобы была возможность быстрой установки выбранного профиля настроек. Для этого нужны и AppData, где у каждого пользователя будет храниться указание на профиль, и, возможно, сами ini проги плагинов (в зависимости от того, где установлено сохранение, в папке с программой или в AppData).

Serge Yolkin
Не сохраняется оно и сейчас, и люди ноют. Тогда будет тоже самое, но + возможность быстро поменять место хранения настроек.
Вон, у тотала даже при установке сразу спрашивает, где хранить настройки, с возможностью самостоятельного выбора директории.

> А свои профили проще реализовать несколькими сборками AP
Идея как раз в том, чтобы от этого уйти.
Тотал установлен не у всех и не везде. Да и связку "запуск из винды - обычный, а из тотала - программерский" не считаю нормальной. Я, к примеру, работаю и из тотала, и из проводника, и мне надо чтобы была открыта одна копия программы с одним и тем же интерфейсом и возможностями.

Про Тотал я чисто для примера написал, можно обойтись и одним проводником: по Enter/doubleClick открывать простой блокнот, а "программерский" - через контекстное меню (это не рекомендация, это, опять же, "например").
Теперь, чтобы за разногласиями не потерялось предложение: кто за то, чтобы в ini (первой строкой) можно было бы указать новый путь для хранения ВСЕХ настроек?
И ещё одно предложение: ключ комстроки для запуска без плагинов - как простой блокнот.

Serge Yolkin wrote:Теперь, чтобы за разногласиями не потерялось предложение: кто за то, чтобы в ini (первой строкой) можно было бы указать новый путь для хранения ВСЕХ настроек?

Я за то, чтобы настройка была, а где она будет не так важно.

Но, опять же, это не совсем то, что имеется ввиду. Путь хранения настроек - лишь необходимый минимум для реализации сабжа.

Serge Yolkin wrote:кто за

Мне лично в данный момент не нужно, но мысль хорошая, и, на мой взгляд, обогатит Акел. Возможность иметь сколько угодно профилей с разными настройками и наборами плагинов, но в то же время без дублирования бинарников, как это происходит при отдельных сборках, - это круто.

И ещё одно предложение: ключ комстроки для запуска без плагинов - как простой блокнот.

Проблема в том, что есть несколько плагов, без которых ну совсем не комфортно

Fr0sT wrote:Проблема в том, что есть несколько плагов, без которых ну совсем не комфортно

Идея плага, что в сабже это и призвана решать, ведь правда?)

VladSh
я к тому, что "Акель без плагов" - это, конечно, далеко не "Миранда без плагов", но всё равно мало кому потребуется (кмк).

Напомните пожалуйста, сейчас есть параметр, запрещающий АР лезть в реестр и пользоваться локальным файлом настроек (при наличии как минимум пустого файла настроек рядом с исполняемым файлом)?

Deft wrote: запрещающий АР лезть в реестр и пользоваться локальным файлом настроек

Ну, есть настройка, позволяющая хранить настройки программы в реестре ИЛИ в файле... третьего не дано.