Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#61: 2007-08-19 01:29:56 ЛС | профиль | цитата
nesco писал(а):
А я вот тоже в толк не возьму

Помочь больше ничем не могу
Повторять 20-й раз одно и то же для писателей - мне уже в печенках сидит.
карма: 9

0
Разработчик
Ответов: 26163
Рейтинг: 2127
#62: 2007-08-19 02:18:51 ЛС | профиль | цитата
Galkov, а ты ничего аргументированного и толкового не привел, чтобы вот такое самому писать
Galkov писал(а):
Повторять 20-й раз одно и то же для писателей - мне уже в печенках сидит.
А вот Dilma написал аргументрованно
Dilma писал(а):
oldTV, не предлагал переходить на некий новый уровень представления контейнеров в коде. Даже более того - в последнем варианте и с точки зрения интерфейса остается все по прежнему. Им было предложено всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в них для того, чтобы иметь возможность сразу перетащить элемент на уровень ниже или выше
И вот этого в конце было достаточно, чтобы понять, что это все не реализуемо
Dilma писал(а):
Как я уже сказал подобная операция содержит достаточно много неоднозначностей и кроме того её нельзя реализовать в рамках текущей внутренней модели
А в том случае, который ты описал, с копиями контейнеров, можно было просто запретить действия по перетаскиванию элементов между уровнями (запрещены же у нас визуальные контролы внутри мультиков).

карма: 22

0
Ответов: 9906
Рейтинг: 351
#63: 2007-08-19 08:58:18 ЛС | профиль | цитата
nesco писал(а):
И вот этого в конце было достаточно, чтобы понять, что это все не реализуемо

Реализуемо - все. Но не все одновременно. И вопрос (которого я якобы не понимаю) состоит в том, что уйдя на на одно направление "коврового покрытия", второе направление (возможности неограниченной структуризации) мягко говоря - отложится. А грубо говоря - никогда не будет реализован.
И второе мне уже не безразлично.

nesco писал(а):
А в том случае, который ты описал

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

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

Это так - к сведению...
карма: 9

0
Разработчик
Ответов: 26163
Рейтинг: 2127
#64: 2007-08-19 10:19:31 ЛС | профиль | цитата
Galkov писал(а):
второе направление (взможности неограниченной структуризации) мягко говоря - отложится. А грубо говоря - никогда не будет реализован

Вот, наконец-то, я понял к чему ты клонил. Тебе тяжелова-то сразу понять, особенно твою конечную масль. Нас подводит то, что мы не заглядываем далеко вперед, а пытаемся решить каждодневыные мелкие задачи, не вдаваясь и не прослеживая конечного результата, откуда можно попасть в тупик.
карма: 22

0
Администрация
Ответов: 15295
Рейтинг: 1519
#65: 2007-08-19 13:15:53 ЛС | профиль | цитата
Я всеравно не ощутил описываемой проблемы. Содержимое контейнера когда-то предпологалось выводить в отдельной вьюшке при клике на него. Т.е. имеем абсолютно тоже развертывание с разницей лишь в позиции отображения.

А вот пример:
Add(ViewSHA,6751565,35,560)
{
Width=191
Height=135
}
BEGIN_SDK
Add(Img_Point,9120885,42,28)
{
link(onDraw,3421712:doDraw,[])
}
Add(Img_Line,3674241,42,77)
{
link(onDraw,3848316:doDraw,[])
}
Add(Img_Rectangle,3421712,84,28)
{
}
Add(Img_Rectangle,3848316,84,77)
{
}
Add(Img_Ellipse,6862288,126,28)
{
}
END_SDK

ну и чем это вообще отличается от того, что предлагает OldTV Только тем, что подвойному клику осуществляется вход внутрь, а не переход в режим редактирования.
карма: 27
0
Ответов: 9906
Рейтинг: 351
#66: 2007-08-19 14:04:45 ЛС | профиль | цитата
Вот это: code_1841.txt , отличается от его предложения на 180 градусов.
Его предложение (без конкретизации разворачивания, типа: "а это уже дело конструкторей") категорически предполагает одиночное использование мультика.
В ином контексте "перенос границы покрывала" - просто бессмысленнен.

И это вопрос просто концепции, не более: если у нас модель лоскутного одеяла - никаких вопросов, все правильно.
Если мы работаем в объектной модели (или "матрешковой", если так понятнее) - полная ерунда.

Мне представляется, что проблема в другом: вроде бы и логично разрешать ПРАВКУ мультика, даже имеющего линки, а с другой стороны - правка мультика с линками, это совсем другая история, чем одиночного.
Наступить на эту гранату ЛЕГКО.
Перетаскивание, поддержанное средой, это не просто пользователь наступил на гранату, а даже это мы ему помогли в этом (подтолкнули в этом направлении).
Вместо того чтобы как-то серьезно обратить внимание (не знаю как) пользователя на то, чего он правит, для случая наличия линков.


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

И какой смысл поддерживать это, что бы пользователь дольше смог продержаться на ошибочной технике
карма: 9

0
файлы: 1code_1841.txt [1.8KB] [446]
Администрация
Ответов: 15295
Рейтинг: 1519
#67: 2007-08-19 15:56:18 ЛС | профиль | цитата
Этот пример весьма оригинально выглядит в менеджере проекта...
карма: 27
0
Ответов: 9906
Рейтинг: 351
#68: 2007-08-19 16:04:50 ЛС | профиль | цитата
Пока не видел
карма: 9

0
Ответов: 689
Рейтинг: 20
#69: 2007-08-19 21:18:57 ЛС | профиль | цитата
Galkov, не делайте поспешных выводов, прошу Вас:
Его предложение (без конкретизации разворачивания, типа: "а это уже дело конструкторей") категорически предполагает одиночное использование мультика.
В ином контексте "перенос границы покрывала" - просто бессмысленнен.

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


Вот полностью понятая моя мысль.
Что касается "конкретизации разворачивания" предложений несколько (лишь бы было заявлено о возможности реализации):
  • при поднесении курсора к мультиэлементу (панель, мультик и ets) в центре элемента появляется + (как сейчас появляется линия при протягивании связи к хабу например). При нажатии на него елемент разворачивается.
  • разворот осуществляется по двойному щелчку;
  • разворот осуществляется по нажатию на стрелочку на панели элементов (так как сейчас осуществляется вход внутрь) - хотя это и не очень удобно;
  • разворот осуществляется по нажатию на клавиши - Ctrl+стрелка вправо (к примеру).
  • карма: 0

    0
    Ответов: 9906
    Рейтинг: 351
    #70: 2007-08-19 22:53:11 ЛС | профиль | цитата
    oldTV писал(а):
    не делайте поспешных выводов, прошу Вас

    Не надо меня просить не спешить - я про все это уже не меньше ГОДА знаю. И уже даже способен предсказать реакцию, да почти на все.

    Dilma писал(а):
    всего лишь развертывание контейнеров на рабочем поле без непосредственного входа в них

    Ну спасибо, разъяснили

    Вот только значительно раньше было интерфейсное предложение (даже не придуманное, а подсмотренное), ушедшее как-то так "в никуда"

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

    Да при отладке: почему тогда не делать вхождение в мультик в новом связанном окне...
  • карма: 9

    0
    Разработчик
    Ответов: 26163
    Рейтинг: 2127
    #71: 2007-08-19 22:57:33 ЛС | профиль | цитата
    Помню, давно это обсуждали -- многооконный режим работы, так ни к чему и не пришли
    карма: 22

    0
    Ответов: 3655
    Рейтинг: 69
    #72: 2007-08-19 23:06:50 ЛС | профиль | цитата
    nesco писал(а):
    Помню, давно это обсуждали -- многооконный режим работы, так ни к чему и не пришли

    Дык HiAsm изначально был многооконный но потом утерял такую возможность.
    карма: 0

    0
    Ответов: 9906
    Рейтинг: 351
    #73: 2007-08-19 23:10:12 ЛС | профиль | цитата
    Ась
    карма: 9

    0
    Администрация
    Ответов: 15295
    Рейтинг: 1519
    #74: 2007-08-19 23:17:27 ЛС | профиль | цитата
    Чего чего
    карма: 27
    0
    Ответов: 3655
    Рейтинг: 69
    #75: 2007-08-19 23:21:52 ЛС | профиль | цитата
    Ну как среда то была из отдельных окон.(как в делфи)
    карма: 0

    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)