У вас есть проблемы напоминаний в MLO-Android? Ответьте: Да/Нет.

Инверсия зависимости

Какие новые функции Вы хотели бы увидеть в MLO для ПК?
Автор темы

Кирилл Е
Команда бета тестеров
Сообщения: 299
Зарегистрирован: мар 2017
Есть ответ: 12
Благодарил (а): 75 раз
Поблагодарили: 95 раз

Инверсия зависимости

Сообщение Кирилл Е » 12 фев 2018, 23:13

Хотелось бы видеть в МЛО инверсию зависимости.
Если задача завершена - зависимая задача становится неактивна.
Это значительно упростило бы схемы где нужно использовать "выключатель".

Аватара пользователя
Краевой
Команда бета тестеров
Сообщения: 802
Зарегистрирован: янв 2012
Есть ответ: 22
Откуда: Киев
Благодарил (а): 21 раз
Поблагодарили: 129 раз
Контактная информация:

Инверсия зависимости

Сообщение Краевой » 13 фев 2018, 21:13

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

Автор темы

Кирилл Е
Команда бета тестеров
Сообщения: 299
Зарегистрирован: мар 2017
Есть ответ: 12
Благодарил (а): 75 раз
Поблагодарили: 95 раз

Инверсия зависимости

Сообщение Кирилл Е » 19 фев 2018, 03:16

Может функция редко применима, потому что её сложно реализовать? Сужу только по себе. Если она реально у других не востребована, я обойдусь костылями, но видеть хотелось бы.

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

Nikolay D
Сообщения: 115
Зарегистрирован: мар 2013
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Инверсия зависимости

Сообщение Nikolay D » 20 фев 2018, 16:49

Не очень понял целесообразность постановки задачи про инверсию зависимости.
Если зависимая задача станет неактивной после выполнения обеспечивающей задачи, то зачем зависимая вообще нужна? Так только невидимый мусор может накапливаться.

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

Автор темы

Кирилл Е
Команда бета тестеров
Сообщения: 299
Зарегистрирован: мар 2017
Есть ответ: 12
Благодарил (а): 75 раз
Поблагодарили: 95 раз

Инверсия зависимости

Сообщение Кирилл Е » 22 фев 2018, 04:59

Типовая схема звучит так: "когда я делаю А, то не могу Б." Применяю к нестандартным задачам, по большей части чтобы скрыть стандартные ситуации, когда контексты и фокус не справляются.

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

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

Пример "когда проект..., то другие проекты..." Когда получили хороший заказ, то перестаю дёргать мастера по второстепенным ролям. итд

На практике функция легко реализуется в момент прояснения задачи. Просто думаешь какие дела она заблокирует и добавляешь к этим делам в "блок". Сложность технически настроить.

Чтобы ветка не висела нужно подумать на сколько времени блокирующая задача выведет блокируемую из строя, или какое событие должно снять блок. Как вариант можно добавить опцию как в зависимости, "вернуть через...часов". Мне хватает повторов, или запуска архивации во время обзора.

Автозачёркивание даст немного другой эффект, если я правильно Вас понял.. Функция хоть и опасная, но тоже интересная. Реализую её с помощью локальной ссылки.

Nikolay D
Сообщения: 115
Зарегистрирован: мар 2013
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Инверсия зависимости

Сообщение Nikolay D » 22 фев 2018, 17:05

Не очень понятное у Вас разъяснение. На 100% я его так и не понял. Буду отвечать на то, что понял.

Стандартная зависимость: задача Б заблокирована до выполнения задачи А.

Вы предлагаете в начальном посте 13 фев 2018, 03:13 - задача Б становится неактивной, когда выполнена (уже выполнена) задача А.

Во-первых, смотрите мой предыдущий пост 20 фев 2018, 20:49. Во-вторых, не понятно как этот механизм поможет Вам реализовать механизмы, предлагаемые в посте 22 февр 2018, 08:59.

Стандартная реализованная зависимость имеет простейшее условие - выполнена-невыполнена задача А.

Вы предлагаете в посте 22 февр 2018, 08:59 ввести, как я понял, новый тип условий - блокировка, когда задача А выполняется. Это совсем не тоже самое, что в посте 13 фев 2018, 03:13. Чего вы на самом деле хотите?

Отступление. Задача имеет, как минимум, 2 параметра действия - активна-неактивна и (занимает ваше настоящее время)-(не занимает ваше настоящее время). [Простаивает-выполняется это другое - может быть другой исполнитель и ваше время свободно.]
Второй вид параметра в MLO дееспособным образом пока не реализован (старт-стоп), а активная задача, как впрочем и неактивная, могут как занимать ваше настоящее (сию минуту) время, так и не занимать.

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

Автор темы

Кирилл Е
Команда бета тестеров
Сообщения: 299
Зарегистрирован: мар 2017
Есть ответ: 12
Благодарил (а): 75 раз
Поблагодарили: 95 раз

Инверсия зависимости

Сообщение Кирилл Е » 23 фев 2018, 23:11

Не очень понятное у Вас разъяснение.

Это не мой конёк) Плохо определяю заранее что вызовет вопросы, а что запутает, у меня то в голове всё очевидно :D

Во-первых, смотрите мой предыдущий пост 20 фев 2018, 20:49

Не очень понял целесообразность постановки задачи про инверсию зависимости.

Цель: запланировать блокировку того(Б), чем я не буду заниматься по причине...(А).
Средства: ломать голову как это устроить, собирать из этого механизмы-шаблоны для разных условий, учиться быстро их встраивать в нужных условиях.
Так же средства: механизмы занимают место, иногда требуют дополнительных(формальных) задач, папок, подмеханизмов.
Сообразность цели средствам определяется для каждого случая индивидуально. Основной критерий: если шаблон при планировании добавляется в систему за несколько минут и гарантированно решает в будущем какой-то вопрос - ему быть.

Вы предлагаете в посте 22 февр 2018, 08:59 ввести, как я понял, новый тип условий - блокировка, когда задача А выполняется. Это совсем не тоже самое, что в посте 13 фев 2018, 03:13. Чего вы на самом деле хотите?

Не хватает именно этого:
задача Б становится неактивной, когда выполнена (уже выполнена) задача А

От разработчиков я прошу функцию в чистом виде...
Во-вторых, не понятно как этот механизм поможет Вам реализовать механизмы, предлагаемые в посте 22 февр 2018, 08:59.

...Чистая функция имеет преимущества над схемами её заменяющими. Что сэкономит затрачиваемые средства.
Предлагаемые механизмы можно уже сейчас настроить, успешно тестирую их для некоторой повторяющейся рутины, с помощью "километровых костылей".

Вот один из шаблонов, и реальный пример его тестирования(если выполнять проект с санками, то тренировки отпадут), воссоздал без дат, чтобы пример кликался.
пример.ml
(51.06 КБ) 122 скачивания

шаблон.ml
(46.18 КБ) 98 скачиваний

Вместо "тренировок" можно поставить хоть всю сферу жизни РАБОТА и ДОМ или же отдельные их части, а вместо "горки" заблокировать задачей "посадка на рейс в отпуск", разблокировать задачей "посадка на рейс домой"(или просто отработав и заархивировав проект отпуск)

Если зависимая задача станет неактивной после выполнения обеспечивающей задачи, то зачем зависимая вообще нужна?

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

Если "блокировка" прячет мусор навсегда - мусор удаляется при следующем обзоре активных проектов(если Вы такой глубокий обзор не проводите, можно подумать над другим решением)
Если "блокировка" временная или решаемая - мусор уже не мусор, а задача в ожидании.

Старт-стоп мне не очень нужен.

Еще пару скопившихся заметок по теме.
Как я представляю себе поведение функции?
Та же зависимость, но с одним отличием:
-когда "А" завершена - "Б" не активна;
-когда "А" не завершена - она не блокирует "Б".

Остальное должно быть как в стандартной зависимости:
-одна "А" может блокировать сразу несколько задач "Б", "Б1", "Б2"...;
-у одной "Б" может быть одновременно несколько блокирующих задач, "А", "А1", "А2"....;
-есть возможность выбора условия блокировки "Б" (когда выполнены "все А" или "любая из А").

Опционально, но для меня необязательно:
-В стандартной зависимости есть функция "отложить", когда обеспечивающая задача выполнена зависимая задача всё ещё неактивна, но по прошествии времени активируется. Для блокировки мне видится логичным поменять "отложить" на "вернуть". Если "вернуть" имеет значение отличное от нулевого, например 1 день, то после выполнения блокирующего "А", задача "Б" становится неактивна, а через сутки блокировка проходит.
-Дополнительно нужно обдумать как будет себя вести "Б", если у неё есть блокирующая "А" и зависимость "В". Мне видится логичным активировать "Б", если блокирующая "А" не завершена, а зависимость "В" завершена.
Так же следует продумать как будут взаимодействовать функции "вернуть" и "отложить" в одной блокируемо-зависимой задаче.


Оформление
Сделать другую иконку для визуального различия.
Придумать подходящее название функции, написать про него другую српавку.
Остальное вроде под кальку.


Долго писал сообщение... если что-то упустил или не понятно, отвечу наверное уже после отпуска.

Nikolay D
Сообщения: 115
Зарегистрирован: мар 2013
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Инверсия зависимости

Сообщение Nikolay D » 27 фев 2018, 20:21

Если ввести зависимость "Задача Б становится неактивной после выполнения задачи А", то после выполнения задачи А задача Б больше никогда не сможет быть активной и зависнет навсегда.

Автор темы

Кирилл Е
Команда бета тестеров
Сообщения: 299
Зарегистрирован: мар 2017
Есть ответ: 12
Благодарил (а): 75 раз
Поблагодарили: 95 раз

Инверсия зависимости

Сообщение Кирилл Е » 28 фев 2018, 08:50

Ну да, поведение функции вполне естественно. Если в действительности задача "А" - безвозвратно блокирует "Б", то и в планировщике это должно повторяться. Это логично. "Б" зависнет без возможности завершиться. Всё что зависит от "Б" так же зависнет и это будет отражать реальный ход дел. "А" не решает проблему для "Б", а создаёт.

Если в действительности "А" - временная помеха, отображаем это в планировщике в свойствах "А".

Если в действительности "А" - решаемая помеха, отображаем это в планировщике в виде дополнительной задачи-решения.


Вернуться в «Предложения по улучшению»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя