Ultra TC Editors

[Avada]

Странно, ещё другие пожелания не реализованы, а уже происходит попытка создать новый редактор.

А это совершенно параллельные вещи. И, как легко видеть, пока речь идёт только о предварительных намерениях.

Первое чего захотелось это правильного срабатывания перемещения пункта с удержанием ЛКМ, пока при отпускании он перепрыгивает на самую верхнюю позицию всего тулбара. Хотелось бы, чтобы в момент перемещения появлялся визуальный разделитель, указывающий место постановки передвигаемой кнопки.

Странно, у меня перетаскивается точно. А про разделитель согласен.

Следующий момент: при нажатии на каком-то пункте с невыпадающем меню, отличным от первого, ИМХО, было бы удобней работать с входящих только в это меню клавишами, а для выпадающие меню сделать аналогично тому, как это возможно сейчас, т.е. с фолдингом, это бы удовлетворяло логике.

Прошу прощения, не понял. Подробнее по этим пунктам, пожалуйста.

Далее: при закрытии изменённого и несохранённого тулбара, естественно, должно появляться окно (не)подтверждения сохранения.

Само собой. Но, как было сказано, пока это вообще не редактор.

Также хотелось бы наличия маркеров для внутренних команд ТС.

А cm_ или там em_ недостаточно? Может, цветом различать?

А Shortcut Key - это вообще прелесть.

А где ты увидел эту прелесть и почему её не вижу я?

[Flasher]

И, как легко видеть, пока речь идёт только о предварительных намерениях.

Не думаю, что что-то подобное можно состряпать за пять минут. Наверняка на это ушло времени не меньше, чем бы ушло, например, на тему c возвратом к виртуальным папкам после перезапуска ТС.

Странно, у меня перетаскивается точно.

На XP ещё не пробовал, проверю.

Подробнее по этим пунктам, пожалуйста.

Не знаю как тут по пунктам.
Открываем редактор. Сразу появляется список кнопок, принадлежащих в первому bar-у. Второй и последующий bar-ы распахиваются при нажатии плюсика. При этом элементы, не относящиеся к выбранному bar-у, также остаются в общем списке, что из первого, что из неактивных последующих, раскрывающихся. А нужно, чтобы отражались только элементы из выбранного bar-а (не в виде меню).

Но, как было сказано, пока это вообще не редактор.

А ещё было сказано, что нужно обсудить, что я, собственно, и делаю.

А cm_ или там em_ недостаточно? Может, цветом различать?

Так мы же команды можем видеть только в выбранной кнопке, а я пишу про общий список. Можно и цветом.

А где ты увидел эту прелесть и почему её не вижу я?

Левый нижний угол с текстовым полем.

[Avada]

Не думаю, что что-то подобное можно состряпать за пять минут. Наверняка на это ушло времени не меньше, чем бы ушло, например, на тему c возвратом к виртуальным папкам после перезапуска ТС.

За пять не за пять, но, насколько понимаю, достаточно быстро. Это же всего-то редактор пользовательских команд, быстренько приспособленный (в порядке эксперимента) для отображения в виде дерева BAR-файлов. Просто посмотреть, как это получится...
И, согласись, автору виднее, за что в данный момент хвататься и что в какую очередь делать. Поставленная задача его явно заинтересовала пока что просто принципиальной возможностью реализации. Оказалось — действительно можно. А впереди ещё много всего будет.

Открываем редактор. Сразу появляется список кнопок, принадлежащих в первому bar-у. Второй и последующий bar-ы распахиваются при нажатии плюсика. При этом элементы, не относящиеся к выбранному bar-у, также остаются в общем списке, что из первого, что из неактивных последующих, раскрывающихся. А нужно, чтобы отражались только элементы из выбранного bar-а (не в виде меню).

Дерева, а не меню. Теперь понял, но вообще-то это противоречит самой концепции отображения дочерних тулбаров как развёрнутых ветвей дерева. Мы же не можем попросту убрать верхний уровень дерева, оставив только нижележащий. Я не очень представляю, как это в нынешнем виде можно сделать иначе. Если бы идеология реализации стала совсем другой (BAR-файлы как категории в списке команд, скажем), то да, конечно. Но там, видимо, свои проблемы возникнут. Впрочем, новый редактор может быть, вероятно, сделан отдельной программой и по каким-то своим правилам...

Так мы же команды можем видеть только в выбранной кнопке, а я пишу про общий список.

И я про него же. В нём команды прекрасно видны на данный момент именно как cm_ или em_.

Левый нижний угол с текстовым полем.

Текстовое поле в левом нижнем углу — это поле "Подсказка". (Которое пока, как и "Значок", не работает.) Я уже начинаю задаваться вопросом, одну ли мы программу смотрим... Может быть, скрин покажешь?

[Flasher]

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

Не спорю. Что там по Todo отвечено?

Дерева, а не меню.

"в виде меню" - именно так написано в диалоге "Настройка панели инструментов".

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

Не вижу противоречий. Разница только в последовательности расположения bar-ов. Почему первому bar-у можно показывать только свои кнопки, а последующим нельзя? Идёт прямое нарушение логики.

Я не очень представляю, как это в нынешнем виде можно сделать иначе.

При нажатии на каждый из bar-ов все остальные элементы должны скрываться, я же объяснил.

BAR-файлы как категории в списке команд

Не понял. Каких категорий? Чьего списка?

Впрочем, новый редактор может быть, вероятно, сделан отдельной программой и по каким-то своим правилам.

Иначе без фишек не имело бы смысла городить тот же огород, но с другим интерфейсом. Так и должно быть.

И я про него же. В нём команды прекрасно видны на данный момент именно как cm_ или em_.

А, действительно. У меня просто большинство кнопок сделано по аналогии с польз. командами, сей момент из головы вылетел. Но цвет бы сразу в глаза бросался, как думаешь?

Может быть, скрин покажешь?

[Avada]

Не спорю. Что там по Todo отвечено?

А я ещё не спрашивал — пока не до этого было. Возможно, завтра.

"в виде меню" - именно так написано в диалоге "Настройка панели инструментов".

Это в Тотале. А я про то, как в редакторе.

Не вижу противоречий. Разница только в последовательности расположения bar-ов. Почему первому bar-у можно показывать только свои кнопки, а последующим нельзя? Идёт прямое нарушение логики.

Потому что первый BAR есть верхний уровень дерева, а все остальные — на более глубоких уровнях. Корень дерева без развёрнутых ветвей отобразить можно запросто. А развёрнутую ветвь дерева без его корневой части?

Не понял. Каких категорий? Чьего списка?

Который в диалоге "Выбор команды". Вот как там убрать остальное и показать только конкретный список, я понимаю. А в дереве — не очень.

Но цвет бы сразу в глаза бросался, как думаешь?

Думаю, да.

За скрин спасибо. Понял, в чём прикол: встроенный английский для этой штуки слегка отличается от файла English.lng. При использовании тех же самых строк. Если новый файл добавлен к прочим редакторам в каталог Ultra TС Editors, то аглийский берётся из языкового файла и получается обычное "Tooltip". (А по-русски там, естественно, получается "Подсказка".) А вот если из другого каталога запустить, то да, будет "Shortcut Key".

[Flasher]

Это в Тотале. А я про то, как в редакторе.

Дык ты'ж мои слова корректируешь. Я там в цитируемом слово "меню" употребил лишь в приведённом контексте.

Потому что первый BAR есть верхний уровень дерева, а все остальные — на более глубоких уровнях. Корень дерева без развёрнутых ветвей отобразить можно запросто. А развёрнутую ветвь дерева без его корневой части?

Я бы не стал называть это деревом, это понятие больше уместно для отображения структуры каталогов/файлов. А тут речь скорей может идти о ниспадающих списках элементов, как в случае с фолдингом или спойлером. И воспринимать первый bar как корень я бы не стал. Все, что происходит - это отображения списка из содержимого первого bar-a также, как могло бы происходить отображение содержимого последующих.
Ладно, вопрос не в понятиях, а желании сделать описанное, т.е. убрать элемент разворачивания для последующих bar-ов, оставив их только у тех, что в виде меню, ну и организовать скрытие. Первый bar, даже если кнопка с которым не входит в какое-либо из последующих bar-ов можно оставить сверху как обязательный элемент списка.

Если новый файл добавлен к прочим редакторам в каталог Ultra TС Editors, то аглийский берётся из языкового файла и получается обычное "Tooltip".

Не стал сам проверять, но догадался, что этим кончится. Хорошо, пусть так, значит будем считать, что это расположение файла в ином каталоге окажется для развития данного редактора не случайным. Автору обязательно стоит предложить то, о чём я писал, т.е. об автоматическом создании пользовательской команды, синтаксис которой полностью удовлетворяет кнопочному.

[Avada]

И воспринимать первый bar как корень я бы не стал.

Да я бы тоже не стал, но куда денешься? В пробном варианте это древесная структура в чистом виде. Со всеми своими специфическими элементами (включая корневой).

Ладно, вопрос не в понятиях, а желании сделать описанное, т.е. убрать элемент разворачивания для последующих bar-ов, оставив их только у тех, что в виде меню, ну и организовать скрытие. Первый bar, даже если кнопка с которым не входит в какое-либо из последующих bar-ов можно оставить сверху как обязательный элемент списка.

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

Автору обязательно стоит предложить то, о чём я писал, т.е. об автоматическом создании пользовательской команды, синтаксис которой полностью удовлетворяет кнопочному.

То есть ты считаешь полезной идеологию "Каждой кнопке по em_-команде?" Но такие вещи если и делать, то уж всяко не автоматически. (Да и не надо это в массовом порядке — у меня, например, и так куча кнопок создаётся уже на пользовательских командах.) И полностью удовлетворить не получится, поскольку em_-команда, естественно, не учитывает, например, опцию "в виде меню". Кроме того, клавиши назначаются команде, а не кнопке (для которой они отображаются просто как часть подсказки). Поэтому мне нынешнее "Shortcut Key" не очень понятно в плане будущей функциональности, даже когда это будет не вместо подсказки, а отдельно.
В общем, идею надо отшлифовать, а то у автора будут недоумения.

[Flasher]

Да я бы тоже не стал, но куда денешься? В пробном варианте это древесная структура в чистом виде. Со всеми своими специфическими элементами (включая корневой).

Даже сам факт быстрого перемещения любой кнопки с другим bar-ом на место той, что с первым баром, говорит сам за себя. С каталогами ты такого фокуса со сменой "корня" не сделаешь.

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

Я же написал "убрать элемент разворачивания", а не возможность просматривать их. См. их будем как первый бар при двойном клике ЛКМ, при этом все остальные элементы(кнопки) исчезнут, и уже текущий bar будет восприниматься как корень.
Для чего нужно? Да банально - это облегчит скорость навигации.

То есть ты считаешь полезной идеологию "Каждой кнопке по em_-команде?" Но такие вещи если и делать, то уж всяко не автоматически.

Объясняю: автоматически - это создание с уже вписанными в поля кнопки значениями после клика по некой кнопке с появлением промежуточного диалога, о котором я писал выше. Пусть будет называться "полуавтомат", не вопрос.

И полностью удовлетворить не получится, поскольку em_-команда, естественно, не учитывает, например, опцию "в виде меню".

Эта опция появляется лишь в кнопках с bar-ами и легко игнорируется программно, или даже просто не учитывается. Для автора это не проблема.

[Avada]

Даже сам факт быстрого перемещения любой кнопки с другим bar-ом на место той, что с первым баром, говорит сам за себя. С каталогами ты такого фокуса со сменой "корня" не сделаешь.

В программе я никакого "перемещения на место" в упор не вижу. Грубо говоря, у меня главная панель, а на ней две первые кнопки ведут, соответственно, на вторую и третью панель. При открытии программы первые два элемента — это свёрнутые списки (или ветви дерева, или подменю — в данный момент неважно). Далее идёт содержимое главной панели. Я открываю, допустим, третью панель. Вся структура осталась на своих местах — закрытое "подменю" второй панели, открытое только что — третьей, и ранее открытое — первой. В том же порядке.

Я же написал "убрать элемент разворачивания", а не возможность просматривать их. См. их будем как первый бар при двойном клике ЛКМ, при этом все остальные элементы(кнопки) исчезнут, и уже текущий bar будет восприниматься как корень.

Как ты откроешь для просмотра такое "подменю" (будем условно пользоваться этим термином) мышкой без элемента его разворачивания, если самопроизвольно (просто при наведении мышки) оно не разворачивается, а даблклик сейчас интерпретируется как открытие в панели TC каталога с указанной программой и никак не интерпретируется для cm/em команд TC? Клавиатурные способы пока не обсуждаю.

Объясняю: автоматически - это создание с уже вписанными в поля кнопки значениями после клика по некой кнопке с появлением промежуточного диалога, о котором я писал выше. Пусть будет называться "полуавтомат", не вопрос.

Уточняю ещё раз: речь идёт о создании кнопки для ещё не существующей em_-команды с созданием этой команды и назначением её клавиш по ходу дела? Я правильно понял?

Эта опция появляется лишь в кнопках с bar-ами и легко игнорируется программно, или даже просто не учитывается. Для автора это не проблема.

Несомненно.

[Flasher]

В программе я никакого "перемещения на место" в упор не вижу.

Вообще да, я поспешил с примером. Ни в программе, ни в диалоге "Настройка панели инструментов" передвижение условный корень не поменяет. А кстати было бы удобно. Тут мешает программная привязка к default.bar.

Я открываю, допустим, третью панель. Вся структура осталась на своих местах — закрытое "подменю" второй панели, открытое только что — третьей, и ранее открытое — первой. В том же порядке.

Не понял, для чего ты описываешь нынешнее поведение? Оно и так очевидно.

Как ты откроешь для просмотра такое "подменю" (будем условно пользоваться этим термином) мышкой без элемента его разворачивания, если самопроизвольно (просто при наведении мышки) оно не разворачивается, а даблклик сейчас интерпретируется как открытие в панели TC каталога с указанной программой и никак не интерпретируется для cm/em команд TC?

На данный момент дефолтный bar не отображает элемент развёртывания списка кнопок. Точно также должно быть и для остальных bar-ов. Сам по себе элемент развёртывания - это всего лишь программная функция, которую можно заменить вызовом списка по двойному клику. А переход на нужный файл в соотв. папке в панели ТС я бы переложил на пункт в контекстном меню.

Уточняю ещё раз: речь идёт о создании кнопки для ещё не существующей em_-команды с созданием этой команды и назначением её клавиш по ходу дела? Я правильно понял?

Предложу такое решение: нижней строкой в интерфейсе редактора: галка "Создать пользовательскую команду", при отметке которой активируются нижеследующие элементы: флаги, взятые из Hotkeys Editor после радиокнопки "Клавиша:", и текстовое поле "Имя команды".
Помимо того, что это здорово сократит время на лишние манипуляции, да ещё можно было бы добавить маркеры для кнопок, с которыми связано создание пользовательских команд из редактора.
Добавлю: при сохранении настроек тулбара из редактора создание команд не должно затрагиваться, за этот момент будет отвечать только зелёная галка аля "Применить".

[Avada]

Не понял, для чего ты описываешь нынешнее поведение? Оно и так очевидно.

Чтобы проиллюстрировать то, что ты подтвердил:

передвижение условный корень не поменяет

В общем, разобрались. Сделать бы общий корень для всех панелей — но это вроде как противоречит концепции главной панели и дочерних панелей...

Насчёт элементов развёртывания — честно говоря, не очень понял, чем тебе не угодили эти плюсики. Меня они вполне устраивают. Индикацию различия обычной дочерней панели от "менюподобной" можно сделать не только наличием/отсутствием этого элемента.

Предложу такое решение: нижней строкой в интерфейсе редактора: галка "Создать пользовательскую команду", при отметке которой активируются нижеследующие элементы: флаги, взятые из Hotkeys Editor после радиокнопки "Клавиша:", и текстовое поле "Имя команды".

А, вот оно как... А на Extended Commands Editor и Hotkeys Editor переключаться не лучше? В рамках предлагавшейся ранее межпрограммной коммуникации. Хорошо ли втыкать в один редактор рудиментарные функции других редакторов? Я не отрицаю идею, а просто предлагаю обдумать такой вот нюанс.

[Flasher]

Насчёт элементов развёртывания — честно говоря, не очень понял, чем тебе не угодили эти плюсики. Меня они вполне устраивают.

Во-первых, чтобы развернуть, нужно подводить курсор к этому плюсику, что не очень удобно. Во-вторых, я писал о сокрытии списка элементов из других bar-ов, не принадлежащих к текущему, а это важно.

Индикацию различия обычной дочерней панели от "менюподобной" можно сделать не только наличием/отсутствием этого элемента.

Про индикацию я, заметь, не писал. Это уже косвенная функция.

А на Extended Commands Editor и Hotkeys Editor переключаться не лучше? В рамках предлагавшейся ранее межпрограммной коммуникации. Хорошо ли втыкать в один редактор рудиментарные функции других редакторов? Я не отрицаю идею, а просто предлагаю обдумать такой вот нюанс.

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

[Flasher]

Avada
Автор ознакомлен с соображениями?

[Avada]

Flasher
Автор пытался в них разобраться с помощью автоперевода. С переменным успехом. Надо будет давать дополнительные пояснения. Но у меня последние два дня просто не было ни на какую переписку времени — сначала из-за дальнейшего продвижения истории версий TC (перевода новых строк и редактирования совместно с соавтором предыдущих), потом из-за большой загруженности на работе.
Последняя поступившая информация — что успешно налажена функция сохранения в новом редакторе. Буду уточнять и просить пробную версию. Но не раньше, чем завтра.

[Flasher]

Avada
Ок, тогда добавлю впридачу по поводу:

ни возможности быстрого перекидывания кнопок через буфер

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