Изменение парадигмы колонок

[edw]

Источник цитаты Сделать поля(колонки) не фиксированными, а конфигурируемыми...

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

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

Источник цитаты Пользовательское построение формул тоже уже реализовано в построителе фильтров...

После этого поста разговор перешёл в другую плоскость.

Если не касаться пока скриптового языка. И если признать, что необходимый минимум типов полей в MLO есть. Можно ли ваше предложение переформулировать так:

Для управления списками задач пользователю сейчас доступны Автоформатирование, виды создаваемые с помощью Фильтров, Счётчики и Области. Предлагается объединить функциональность Автоформатирования, Фильтров, Счётчиков и Областей в единый блок управления интерфейсом. Расширить его, добавив "базовые операции (+,-,*,/,\,^) и немного простых функций...".
Блок управления интерфейсом вынести в "xml-конфигурацию, которая может быть экспортирована/импортирована в виде файла". В этом же блоке предусмотреть возможность отключения (опциональных) полей задачи.
Предусмотреть возможность обращения к блоку управления интерфейсом из табличного вида через конфигурируемые колонки.

Наверное ваша постановка задачи технически более правильная. Но я пытаюсь понять, что в результате получит (продвинутый) пользователь.

[romka11]

Источник цитаты Но, в отличии от вас, меня интересовали конфигурируемые параметры в Свойствах задачи, а не табличный вид.

Отличия нет. Табличный вид является лишь представлением для подмножества свойств атомарной задачи. Слово "колонки" я использовал, чтобы упростить понимание для рядового пользователя, поскольку для него "задача" – это не объект класса TTask / не запись в базе данных, а строка в табличном виде. Меня интересует как раз оптимизация набора свойств атомарной задачи: возможность убрать/скрыть ненужные конкретному пользователю (=>упрощение интерфейса) и добавить недостающие конкретному пользователю (== добавление свойств различных типов, в том числе и вычислимых).

Источник цитаты После этого поста разговор перешёл в другую плоскость.

Остальные сообщения как раз касались идей в рамках смены парадигмы о реализации деталей и свойств различных типов:
• Ссылка на базе поля "заметка с маркдауном";
• Вычислимое на базе построителя формул фильтра;
• Файловый на базе механизма синхронизации иконок;
за исключением разговора о CLI, где я отвечал на вопрос:

Источник цитаты Есть ли какие-то технологии для Windows, которые позволяют настраивать MLO-скрипты во внешних приложениях?

Поэтому разговор плоскости первого поста не покидал.



Итак, если суть разговора осталась нераскрытой, мое предложение можно переформулировать так:

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

О динамическом отображении панели "Свойства", конфигурациях в виде XML, наборе типов пользовательских свойств, возможной реализации свойств типа Ссылка/Вычислимое/Файл/Действие – см. тему форума Изменение парадигмы колонок