nesco писал(а):
А я вот тоже в толк не возьму Помочь больше ничем не могу
Повторять 20-й раз одно и то же для писателей - мне уже в печенках сидит.
Ответов: 9906
Рейтинг: 351
|
|||
nesco писал(а): А я вот тоже в толк не возьму Помочь больше ничем не могу Повторять 20-й раз одно и то же для писателей - мне уже в печенках сидит. |
|||
карма: 9 |
|
Разработчик
Ответов: 26163
Рейтинг: 2127
|
|||
Galkov, а ты ничего аргументированного и толкового не привел, чтобы вот такое самому писать
Galkov писал(а): Повторять 20-й раз одно и то же для писателей - мне уже в печенках сидит.
Dilma писал(а): oldTV, не предлагал переходить на некий новый уровень представления контейнеров в коде. Даже более того - в последнем варианте и с точки зрения интерфейса остается все по прежнему. Им было предложено всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в них для того, чтобы иметь возможность сразу перетащить элемент на уровень ниже или вышеDilma писал(а): Как я уже сказал подобная операция содержит достаточно много неоднозначностей и кроме того её нельзя реализовать в рамках текущей внутренней модели |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
nesco писал(а): И вот этого в конце было достаточно, чтобы понять, что это все не реализуемоРеализуемо - все. Но не все одновременно. И вопрос (которого я якобы не понимаю) состоит в том, что уйдя на на одно направление "коврового покрытия", второе направление (возможности неограниченной структуризации) мягко говоря - отложится. А грубо говоря - никогда не будет реализован. И второе мне уже не безразлично. nesco писал(а): А в том случае, который ты описалЯ описал не какой-то уникальный случай, а случай проектирования элементов на HiAsm. И это не просто случай перетаскивания, а редактирования мультика вообще. Точно так же, как случай редактирования кода элемента. Если вы считаете это просто некой непонятной фичей - это Ваши проблемы. А вот только с понятия элемент, и его множественного использования - и начинался HiAsm. Это так - к сведению... |
|||
карма: 9 |
|
Разработчик
Ответов: 26163
Рейтинг: 2127
|
|||
Galkov писал(а): второе направление (взможности неограниченной структуризации) мягко говоря - отложится. А грубо говоря - никогда не будет реализованВот, наконец-то, я понял к чему ты клонил. Тебе тяжелова-то сразу понять, особенно твою конечную масль. Нас подводит то, что мы не заглядываем далеко вперед, а пытаемся решить каждодневыные мелкие задачи, не вдаваясь и не прослеживая конечного результата, откуда можно попасть в тупик. |
|||
карма: 22 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Я всеравно не ощутил описываемой проблемы. Содержимое контейнера когда-то предпологалось выводить в отдельной вьюшке при клике на него. Т.е. имеем абсолютно тоже развертывание с разницей лишь в позиции отображения.
А вот пример:
ну и чем это вообще отличается от того, что предлагает OldTV Только тем, что подвойному клику осуществляется вход внутрь, а не переход в режим редактирования. |
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Вот это: code_1841.txt , отличается от его предложения на 180 градусов.
Его предложение (без конкретизации разворачивания, типа: "а это уже дело конструкторей") категорически предполагает одиночное использование мультика. В ином контексте "перенос границы покрывала" - просто бессмысленнен. И это вопрос просто концепции, не более: если у нас модель лоскутного одеяла - никаких вопросов, все правильно. Если мы работаем в объектной модели (или "матрешковой", если так понятнее) - полная ерунда. Мне представляется, что проблема в другом: вроде бы и логично разрешать ПРАВКУ мультика, даже имеющего линки, а с другой стороны - правка мультика с линками, это совсем другая история, чем одиночного. Наступить на эту гранату ЛЕГКО. Перетаскивание, поддержанное средой, это не просто пользователь наступил на гранату, а даже это мы ему помогли в этом (подтолкнули в этом направлении). Вместо того чтобы как-то серьезно обратить внимание (не знаю как) пользователя на то, чего он правит, для случая наличия линков. Вообще-то, перетащить из чего-то в куда-то, и рассуждения о трудозатратах этого процесса сразу говорят о технологии: упаковка производится из соображений дизайна и географического положения. А вовсе не из логики работы. Dilma, вот только не говори мне, что это тебе не понятно было с самого начала Совершенно прозрачная вещь. И какой смысл поддерживать это, что бы пользователь дольше смог продержаться на ошибочной технике |
|||
карма: 9 |
| ||
файлы: 1 | code_1841.txt [1.8KB] [446] |
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Этот пример весьма оригинально выглядит в менеджере проекта...
|
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Пока не видел
|
|||
карма: 9 |
|
Ответов: 689
Рейтинг: 20
|
|||
Galkov, не делайте поспешных выводов, прошу Вас:
Его предложение (без конкретизации разворачивания, типа: "а это уже дело конструкторей") категорически предполагает одиночное использование мультика.
В ином контексте "перенос границы покрывала" - просто бессмысленнен. Категорически оно это не предполагает. Оно предполагает вот что: oldTV, не предлагал переходить на некий новый уровень представления контейнеров в коде. Даже более того - в последнем варианте и с точки зрения интерфейса остается все по прежнему. Им было предложено всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в них для того, чтобы иметь возможность сразу перетащить элемент на уровень ниже или выше
Вот полностью понятая моя мысль. Что касается "конкретизации разворачивания" предложений несколько (лишь бы было заявлено о возможности реализации): |
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
oldTV писал(а): не делайте поспешных выводов, прошу ВасНе надо меня просить не спешить - я про все это уже не меньше ГОДА знаю. И уже даже способен предсказать реакцию, да почти на все. Dilma писал(а): всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в нихНу спасибо, разъяснили Вот только значительно раньше было интерфейсное предложение (даже не придуманное, а подсмотренное), ушедшее как-то так "в никуда" Всего лишь хотелось: После этого конечно возникнет вопрос о "сквозной продсветке" линков (в связанном окне запросто может оказаться внутренность мультика, или наоборот - наружность, да и связанных окон больше двух может быть) Да при отладке: почему тогда не делать вхождение в мультик в новом связанном окне... |
|||
карма: 9 |
|
Разработчик
Ответов: 26163
Рейтинг: 2127
|
|||
Помню, давно это обсуждали -- многооконный режим работы, так ни к чему и не пришли
|
|||
карма: 22 |
|
Ответов: 3655
Рейтинг: 69
|
|||
nesco писал(а): Помню, давно это обсуждали -- многооконный режим работы, так ни к чему и не пришли Дык HiAsm изначально был многооконный но потом утерял такую возможность. |
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ась
|
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Чего чего
|
|||
карма: 27 |
|
Ответов: 3655
Рейтинг: 69
|
|||
Ну как среда то была из отдельных окон.(как в делфи)
|
|||
карма: 0 |
|