Здравствуйте, remark, Вы писали:

R> Cyberax уже успеет слабать пару десятков классов
Я даже не сомневаюсь, что кто-то, пока продумывается архитектура, способен "сбацать" пару десятков классов. Не сомневаюсь я и в том, что пока разрабатывается архитектура дома или моста, иной "удачливый" строитель способен "сбацать" дом или мост. Только вот кто в этом доме будет жить и кто этим мостом будет пользоваться?

Вопрос не в том, чтобы "сбацать". Вопрос в том, чтобы все это грамотно сопровождать.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

R>> Cyberax уже успеет слабать пару десятков классов
КЛ>Я даже не сомневаюсь, что кто-то, пока продумывается архитектура, способен "сбацать" пару десятков классов. Не сомневаюсь я и в том, что пока разрабатывается архитектура дома или моста, иной "удачливый" строитель способен "сбацать" дом или мост. Только вот кто в этом доме будет жить и кто этим мостом будет пользоваться?

КЛ>Вопрос не в том, чтобы "сбацать". Вопрос в том, чтобы все это грамотно сопровождать.


Не всегда.

А что по поводу последнего вопроса: где и как размещать всё остальное, кроме рисования, что связано с фигурами?

Насчет автофигур в WordXP — согласен, что там можно обойтись несколькими общими классами (а может даже и одним; по-моему так и сделано: Shape. Только тогда не ясно, как же дело обстоит с маркерами, которые можно мышкой двигать, — у них же разная функциональность). Конструктивно, беру на заметку.

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

И все-таки очень хотелось бы увидеть какой-нибудь небольшой пример на 3-й вариант, описанный Вами. Не реализацию, а интерфейс.

Здравствуйте, remark, Вы писали:

R>А что по поводу последнего вопроса: где и как размещать всё остальное, кроме рисования, что связано с фигурами?

Вы перечислили 7 вещей (ответы и вопросы по ходу):

1) Название.

Ответ: Как свойство фигуры. Содержится внутри файла.

2) Картинка.

Ответ: Либо как заливка (в расширенном виде фигура содержит не цвет, а имя заливки, которая описывается в файле точно так же, как фигура) или как картинка (ссылка на картинку присутствует в файле с описанием фигуры).

3) Способ размещения пользователем.

Вопрос: Что это такое? Нужны конкретные примеры.

4) Способ отмены рисования фигуры.

Ответ: Просто не создаем фигуру и все. Или я не понял вопроса.

5) Список свойств.

Вопрос: Какие свойства необходимы? Желательно, перечислите свойства для группы из не менее 5 фигур.

6) Радиус окружности.

Вопрос: Зачем он нужен?

7) Количество точек для полигона.

Ответ: Если имеется в виду аппроксимация кривых ломаными при выводе на устройство, то можно поступить двояко:

а) Параметр задается для устройства. В этом случае он задается не просто в виде количества точек, а в виде dpi.
б) Либо он задается для фигуры и является свойством фигуры.

Здравствуйте, Cyberax, Вы писали:
C>А на простой вопрос не можете ответить? Каким образом мне осмысленно
C>представить _окружность_ и как сделать ее радиус доступным для
C>редактирования?

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

Кроме того, пользователь всё равно вводит "начальные значения" для фигуры, которые каким-то способом потом конвертяться в кривые. Способ конверсии можно описать в виде формул в файле, а "начальные паоаметры" хранить с фигурой. Тогда при их редактировании фигуру можно просто перегенерить

Опять же, есть вопрос по семантике. Как менять радиус трансформированной окружности? Что вообще значит такая операция?

С уважением.

Здравствуйте, Erop, Вы писали:

E>Опять же, есть вопрос по семантике. Как менять радиус трансформированной окружности? Что вообще значит такая операция?

Если окружность — отдельный объект, то радиус можно менять увеличением/уменьшением размеров прямоугольника элемента. Заодно эта окружность становится эллипсом, если высота не равна ширине.

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

Erop wrote:
> Я не Кирилл, но могу задать встречный вопрос: "А как редактировать
> радиус окружности в иерархии с классом на фигуру?"
> Типа к каждой фигуре приписать ещё по вьюшке, которая позволяет как-то
> мышкой или ещё как менять радиус?
> Может можно тоже как-то через какие-то хот-точки и формулы привязки этих
> точек к точкам пути задать?
У меня есть специальный интерфейс ITrackerProvider — он позволяет
задавать custom'ный набор трекеров (в виде набора координат блоков).

За рисование трекеров и манипуляции с ними отвечает редактор, а не
фигура. Когда какой-то трекер перемещается — объект получает об этом
сигнал и может соответственно пересчитать свои части.

Ну и по умолчанию (если не реализован ITrackerProvider) объекты имеют
четыре трекера по углам, центральную точку и обработчик события
масштабирующий объект.

> Кроме того, пользователь всё равно вводит "начальные значения" для
> фигуры, которые каким-то способом потом конвертяться в кривые. Способ
> конверсии можно описать в виде формул в файле, а "начальные паоаметры"
> хранить с фигурой. Тогда при их редактировании фигуру можно просто
> перегенерить
Все красиво на бумаге... Декларативное описание получится достаточно
сложным для непростых фигур (см. Visio).

> Опять же, есть вопрос по семантике. Как менять радиус трансформированной
> окружности? Что вообще значит такая операция?
Следует различать трансформации _фигуры_ и ее отображения.
Масштабирование, вращение, перекос — это просто изменения способа
отображения фигуры и не влияют на геометрию фигуры.

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

Обобщённо:

  // Общие классы
template <class T> class IClonable abstract
{
public:
  virtual T * Clone() = 0;
}

template <class T> class Array : virtual public IClonable<Array<T>>
{
  T ** hItems;
};

  // Параметры фигуры
class Parameter abstract : virtual public IClonable<Parameter>
{
  Text * hParamName;
};
class Real : public Parameter {};
class Text : public Parameter {};
class Point : public Parameter {};
// ...

  // на данном этапе один класс "типа фигуры" с неск. экземплярами (типами)
class FigureType sealed
{
  Text typeName;
  Array<Parameter> params;
  Array<CreateTool> createTools; // see 3ds max script: Create Tools; Tool Create;
  
  Figure * CreateFigure()
  {
    return new Figure(this);
  }
};

  // тоже самое, но не для "типа", а для "фигуры"
class Figure sealed
{
  FigureType * hType;
  Array<Parameter> * hParams;
public:
  Figure(FigureType * ht) : hType(ht), hParams(ht->params.Clone()) { }
};

  // Документ
class Document
{
  Array<Figure> figures;
  Array<View> views;

  bool Serialize(/* ... */);
};

  // Вид
class View
{
  Renderer * hRenderer;
  Document * hDoc;

  bool Draw()
  {
    return hRenderer->Render(this, hDoc);
  }
};

  // Движок (редактора или чего-то-там)
class Engine
{
  //Array<FigureType> figureTypes;
  Map<Text, FigureType> figureTypes;
  Array<Document> docs;
  Renderer * hDefaultRenderer;
private:
  Engine();
public:
  static Engine & GetSingle() // синглтон
  {
    static Engine instance;
    return instance;
  }
};

  // графические рисовальщики (дивайсы):
class Renderer abstract
{
  virtual public bool Render(View *, Document *) = 0;
};

class GDIRenderer : public Renderer {};
class OGLRenderer : public Renderer {};
// ...

По идее ни фигура ни документ не должны ничего знать об графическом дивайсе.
Вроде так...

Здравствуйте, michus, Вы писали:

M>Если окружность — отдельный объект, то радиус можно менять увеличением/уменьшением размеров прямоугольника элемента. Заодно эта окружность становится эллипсом, если высота не равна ширине.

В предложенной мною модели все так и происходит. Радиусы эллипса (окружности) изменяются заданием высоты и ширины. И для этого совсем не надо заводить для окружности отдельный класс.

Здравствуйте, Cyberax, Вы писали:

Если можно пару вопросов к Вам не по Вашему спору с Кириллом Лебедевым а по организации вашего редактора

C>У меня есть специальный интерфейс ITrackerProvider — он позволяет
C>задавать custom'ный набор трекеров (в виде набора координат блоков).

C>За рисование трекеров и манипуляции с ними отвечает редактор, а не
C>фигура. Когда какой-то трекер перемещается — объект получает об этом
C>сигнал и может соответственно пересчитать свои части.

1.Колличество и координаты трекеров все таки наверное определяет фигура?

...

C>Следует различать трансформации _фигуры_ и ее отображения.
C>Масштабирование, вращение, перекос — это просто изменения способа
C>отображения фигуры и не влияют на геометрию фигуры.

2.То есть координаты самих графических объектов не изменяются а пересчитываеются при каждом отображении?

3.Вы реально применяете объекты как экземпляры классов или как то иначе храните данные объектов?
Не сильно ли грузиться память при наличии скажем хотябы 10000 объектов?

Любопытство не праздное — я сам занимаюсь разработкой подобного редактора. Обмен опытом как никак

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, Дядюшка Че, Вы писали:
LM><skipped>
LM>Bridge?

А может Visitor?

Здравствуйте, Белая Крыса, Вы писали:

БК>Здравствуйте, LuciferMoscow, Вы писали:

LM>>Здравствуйте, Дядюшка Че, Вы писали:
LM>><skipped>
LM>>Bridge?
БК>А может Visitor?
Визитор тут уже обсуждался. Он явно для другого предназначен.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

R>>А что по поводу последнего вопроса: где и как размещать всё остальное, кроме рисования, что связано с фигурами?

КЛ>Вы перечислили 7 вещей (ответы и вопросы по ходу):

КЛ>1) Название.

КЛ>Ответ: Как свойство фигуры. Содержится внутри файла.

Согласен


КЛ>2) Картинка.

КЛ>Ответ: Либо как заливка (в расширенном виде фигура содержит не цвет, а имя заливки, которая описывается в файле точно так же, как фигура) или как картинка (ссылка на картинку присутствует в файле с описанием фигуры).

Согласен


КЛ>3) Способ размещения пользователем.

КЛ>Вопрос: Что это такое? Нужны конкретные примеры.

Когда пользователь рисует линию, то он может:
1. указать мышкой один конец линии и другой
2. если нажат shift, указать мышкой один конец линии и другой. при этом линия должна рисоваться под 45 градусов
3. если нажат ctrl, указать мышкой середину линии и конец линии

Когда пользователь рисует окружность, то он может:
1. указать центр и точку на контуре
2. если нажат shift, указать 3 точки на контуре
3. если нажат ctrl, указать центр и точку на контуре, при этом радиус должен быть дискрутный, т.е. округляться

Когда пользователь рисует полигон, то он может:
1. указывать тогки полигона, потом нажать правую-кнопку и контрур замыкается

Т.е. с каждой фигурой сопоставляются некоторые "удобные" способы рисования, как следствие присущие именно этой фигуре.

Я пока слабо представляю как это просто вынести во внешний файл. Без кода для каждой фигуры.



КЛ>4) Способ отмены рисования фигуры.

КЛ>Ответ: Просто не создаем фигуру и все. Или я не понял вопроса.

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


КЛ>5) Список свойств.

КЛ>Вопрос: Какие свойства необходимы? Желательно, перечислите свойства для группы из не менее 5 фигур.

Ну допустим тебе в ТЗ добавляют требование, что для фигур надо выводить некорую статистику: для полигона количество точек, для круга точку центра и радиус, для ешё чего-то ещё что-то.
При этом требования меняются: вначале говорят, что для окружности надо выводить, что она состоит из 3 точек (т.к. задаётся по 3 точкам), потом, что из 2 (центр+точка на контуре), потом, что для неё вообще не надо выводить, из скольких точек она состоит.



КЛ>6) Радиус окружности.

КЛ>Вопрос: Зачем он нужен?

Вполне законно, если пользователь нарисовал окружность радиусом 10, а потом захотел изменить радиус на 15, чтобы он мог просто поменять одно число с 10 на 15.



КЛ>7) Количество точек для полигона.

КЛ>Ответ: Если имеется в виду аппроксимация кривых ломаными при выводе на устройство, то можно поступить двояко:

КЛ>а) Параметр задается для устройства. В этом случае он задается не просто в виде количества точек, а в виде dpi.
КЛ>б) Либо он задается для фигуры и является свойством фигуры.


Или, например, если взять редактор UML, то там с каждой "фигурой" надо сопоставлять набор свойств+диалог для их редактирования


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

По-моему, вы тут в пример приводили post-script: если программа для его вывода/интерпретации может быть действительно простой и обходиться 3 типами примитивов, то это не значит, что программа для его вёрстки должна быть такой же простой и исеть тулбар с 3 инструментами.

Здравствуйте, Cyberax, Вы писали:
C>А на простой вопрос не можете ответить? Каким образом мне осмысленно
C>представить _окружность_ и как сделать ее радиус доступным для
C>редактирования?
В принципе, эту задачу вполге можно реализовать. Правда пример Кирилла с постскриптом некорректен — постскрип — это read only формат, он не годится для "осмысленного" редактирования высокого уровня . Как это можно решить — предоставить набор базовых фигур (не обязательно самых базовых, как в примере Кирилла), из которых можно быстро и удобноо составить остальные и скриптовый API, который позволит добавлять новые фигуры и описывать их свойства (контрольные точки, параметры и т.д).

Пример описания такой фигуры из головы, с использованием синтаксиса скриптового языкка lua:

shape{
  name="rectangle with text",
  
  -- Control points
  controls { 
    text_position = control { 
                             -- Might be also initialized externally inside shape.on_init
                             on_init = function() 
                                               self.x = shape.width/2
                                               self.y = shape.height/2
                                       end 
                            },
  },

  -- Graphical elements
  elements {
    lines = group{ line{}, line{}, line{}, line{} },
    text  = text{},
  },

  -- Modifiable properties
  properties {
     text = string_param{ on_change = function(new_text) self.elements.text.set_text( new_text ) end }
  },

  -- Behaviour
  on_init = function()
     resize(100,100)
  end,

  on_resize = function()
     self.elements.text.x = self.controls.text_position.x
     self.elements.text.y = self.controls.text_position.y
     self.elements.lines[0].x = 0
     self.elements.lines[0].y = 0
     self.elements.lines[1].x = shape.width
     self.elements.lines[1].y = 0
     -- etc
  end
}

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