[отказано] снять ограничение по отображению и перемещению элементов

[Gudvin]

Сейчас элементы скина можно перемещать только в границах контейнеров, что оправдано но не совсем удобно совсем не удобно!!!. например при замене текстуры в контейнере на текстуру меньшего размера границы контейнера уменьшается и часть элементов оказывается "за бортом" не доступна, скрыта, потерена..... Конечно элемент можно выбрать в дереве элементов и в рабочей области будет видна рамка вокруг него, но не передвинуть элемент мышкой, не вызвать меню кликнув по рамке нельзя, а двигать элемент клавишами управления по рабочей области по меньшей мере [Цензура] не удобно....
Такое ощущение что редактор "видит" все элементы в рабочей области, но отображает только те что не выходят за границы контейнеров, остальные же скрывает "маской" (интересно, а как на самом деле?).... так вот хотелось бы убрать эту "маску" и сделать возможным свободно перемещать элементы по рабочей области и осталять их там где душе угодно...

Как быть, если элемент оказался над другим контейнером? очень просто-автоматически перемещать его в этот контейнер! 

снятие ограничений позволит создавать добавлять элементы в любом месте рабочей области... и те элементы что лежат за границами контейнеров во избежание путаницы в дереве элементов смело его (элемент лежащий в рабочей области в не контейнера (группы)) выводить за список (группу)

P.S. это проблема уходит своими корнями в глубокое прошлое....... в этом году столкнулся с ней снова и... невыдержал... накипело.... честно сказать месяц кипело.... только щас смог сформулировать мысль и выложить сдесь в удобоваримом варианте.

P.P.S. мое мнение остается не изменным: нужно "наладить связь" между Палитрой компанентов - Рабочей областью и - Деревом Элементов....

Иными словами наладить нормальное создание добавление, скрытие и удаление элементов в редакторе!!!

Вроде все!!!

а нет не все.... это предложение касается только файла проэкта и редактора.... все что касается сборки обложки может остаться как есть (или менятся в том направлении в каком меняется, оно разработчику виднее (ее пока (сборку) не трогаю )

[Artem]

Сейчас элементы скина можно перемещать только в границах контейнеров, что оправдано но не совсем удобно совсем не удобно!!!. например при замене текстуры в контейнере на текстуру меньшего размера границы контейнера уменьшается и часть элементов оказывается "за бортом" не доступна, скрыта, потерена..... Конечно элемент можно выбрать в дереве элементов и в рабочей области будет видна рамка вокруг него, но не передвинуть элемент мышкой, не вызвать меню кликнув по рамке нельзя, а двигать элемент клавишами управления по рабочей области по меньшей мере [Цензура] не удобно....

Наверное для этого и была сделана функция сделать видимым, или я ошибаюсь?

Такое ощущение что редактор "видит" все элементы в рабочей области, но отображает только те что не выходят за границы контейнеров, остальные же скрывает "маской" (интересно, а как на самом деле?)....

Естественно видны на экране те, что ВИДНЫ, было бы крайне странным, если бы кнопка, которая вывались за пределы своего окна-предка (конейнера), рисовалась и вела себя как обычные видимые кнопки.

так вот хотелось бы убрать эту "маску" и сделать возможным свободно перемещать элементы по рабочей области и осталять их там где душе угодно...

Для дочерних контейнеров есть опция ClipChildren, она частично реализует то, что вы хотите. Делалась она по большей части для составных контейнеров.

P.S. это проблема уходит своими корнями в глубокое прошлое....... в этом году столкнулся с ней снова и... невыдержал... накипело.... честно сказать месяц кипело.... только щас смог сформулировать мысль и выложить сдесь в удобоваримом варианте.

1) Это не проблема
2) Корни ее растут из здравого смысла.

это предложение касается только файла проэкта и редактора.... все что касается сборки обложки может остаться как есть (или менятся в том направлении в каком меняется, оно разработчику виднее (ее пока (сборку) не трогаю )

Честно говоря не понял, что вы хотели сказать

[B1ood]

В этом случае ничего менять нельзя, ибо иначе в растягивающихся скинах все будет совершенно непонятно, как правльно работать тому или иному элементу.

[Gudvin]

Наверное для этого и была сделана функция сделать видимым, или я ошибаюсь?

не понимаю где вы откопали эту функцию я ее в 305м билде не нашел!!!

Естественно видны на экране те, что ВИДНЫ, было бы крайне странным, если бы кнопка, которая вывались за пределы своего окна-предка (конейнера), рисовалась и вела себя как обычные видимые кнопки.

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

Честно говоря не понял, что вы хотели сказать

я и сам себя порой не пойму

P.S. Артем просьба читать этот пост медленно и вдумчиво!

[Gudvin]

было бы крайне странным, если бы кнопка, которая вывались за пределы своего окна-предка....

да вы все таки правы - это странно но если она вывалилась за пределы окна предка как вы говорите, то кому она пренадлежит??? не логично ли ее приписать к рабочей облати, а рабочую область сделать активным элементом программы редактора??


P.S. Артем Вы меня извините, если сможете, но в этот раз я не намерен отступать!

[Artem]

не понимаю где вы откопали эту функцию я ее в 305м билде не нашел!!!

Это скорее баг

[Gudvin]

Это скорее баг

врядли это баг! В 285м билде функции"показать элемент" тоже нет.
да ее и не должно быть в ом виде в котором она была реализована во второй версии редактора... да тогда было оправдана такая реализация... но в новой версии все должно быть переписано по новой... и подогнано под API

[Gudvin]

У меня тут вопрос возник в тему... даже несколько и все они сводятся к 2м к 4м вопросам:

1)Как устроен редактор обложек?

2)Как он будет устроен?

3)Как происходит сборка обложек: какие элементы попадают в обложку из проэкта, а какие отсеиваются? или все происходит по старинке (как было во 2ой версии)?

4)Как будет происходить сборка обложки? (напишите алгоритм сборки)

P.S.если не хотите светить ответы на форуме пишите на Email.

[Artem]

врядли это баг! В 285м билде функции"показать элемент" тоже нет.
да ее и не должно быть в ом виде в котором она была реализована во второй версии редактора... да тогда было оправдана такая реализация... но в новой версии все должно быть переписано по новой... и подогнано под API

Под какой еще АПИ?

редактор устроен так же как и плеер. сборка происходит по старинке - невидимые элементы убиваются

[Gudvin]

Под какой еще АПИ?

Под готовящийся

[Artem]

Не совсем понимаю, как связан API с отрисовкой скинов? Плагины не могут, и не должны влиять на отрисовку скинов

[Gudvin]

Не совсем понимаю, как связан API с отрисовкой скинов? Плагины не могут, и не должны влиять на отрисовку скинов

Никак не связано, А как добавление элементов связано с API?
если ни как, то я тупо перемудрил
 Я предполагал, что создание добавление Элементов из палитры компанентов както связано с API, а следовательно и функция Показать элемент может быть привязана к API тоже. ведь реч шла о ней...

врядли это баг! В 285м билде функции"показать элемент" тоже нет.
да ее и не должно быть в ом виде в котором она была реализована во второй версии редактора... да тогда было оправдана такая реализация... но в новой версии все должно быть переписано по новой... и подогнано под API

но как оказалось, я ошибся...
И под этими словами:

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

нужно было понимать, что у вас все строго расплонировано... а у меня в голове начало рисоваться черти что... 

[Artem]

Попробую объяснить. Сейчас API предоставляется только плагинам, все стандартные компоненты программы работают напрямую с ядром (1.png). Соответственно, есть фиксированный набор элементов, которые вызывают функции из ядра, их нельзя удалить из скина (можно только спрятать).  Все остальные (почти все) клонируются от "фиксированных", они представляют лишь визуально самостоятельный элемент, внутри же вся обработка пересылается оригиналу, а уже оригинал взаимодействует с ядром.

Я же планирую переделать сам Plugins-API, и пересмотреть его место в программе (2.png). Таким образом, каждый элемент сможет работать напрямую с ядром, он не будет зависеть от других элементов, их статуса и расположения.
Более того, новый подход позволит реализовать поддержку скриптов - можно будет написать полностью свой обработчик.

Часть элементов, что лежат в палитре, частично переведены на новый API. Конечно, в палитру можно вывести и клонируемые элементы, но оно того не стоит - через несколько месяцев код для клонов все равно придется выкидывать.