Как называется состояние UI контейнера/окна?

sticky
relative

relative не подходит так как у меня контейнер/окно может быть внутри другого контейнера окна https://imgur.com/a/nQA7Dmw (красное окно вложено в то что под ним) и relative будет сбивать с толку.

sticky это для случая когда ui элемент прилипает к другому или краю экрана при приближении.

А тут есть окно 100 на 100 по размерам я в него сую кнопку в позиции 150 на 150 и окно увеличивается я до размера 150 на 150 позицию свою же оставляет прежнюю.

• convex
• outline

• enclosure

В X11-speech, IIRC это называется gravity, если я правильно понял постановку вопроса.

Хм, подумаю спасибо пока что рабочий вариант вот такой

    bool hover;
    bool active;
    bool enabled;
    bool movable;
    bool resizable;
    bool closable;
    bool minimizable;
    bool bar_active;
    bool bordered;
    bool screen_lock;

    bool pressed;
    bool minimized;
    bool pressed_movable;
    bool pressed_resizable;
    bool adaptive_size; // <= от эта шняга

Но вот хочется одним словом без подчёркивания прям не могу :D Потому что потом эту опцию буду из конфига для ui брать (когда его запилю) а в конфигах я ой как не люблю всё что то не дим словом… хотя может просто мне перебороть эту фобию хз :D Ща допилю эту адаптивность (а то она пока кривая и не работает для положений элементов меньше позиции контейнера) окончательный вариант видосиком выложу и снова вернусь сюда уже утверждать имя флага этого =)

Я сёдня выложу видосик (когда допилю как мне это видится) как оно работает в полной имплементации, вернусь покажу и будет более внятно и наглядно. Кастану =) Одна голова хорошо, а много лучше =)

Короче вот https://youtu.be/XuQSQHK4hwo . Элементы в контейнере всегда внутри него поэтому если размер элемента больше размера контейнера то контейнер меняет размер в любом случае. Это пока что просто захардкожено.

Но

1 - вариант если адаптивность включена то контейнер меняет свои размеры ещё и в отношении максимального положения элементов

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

Короче вот это поведение окна/контейнера надо назвать как то.

Может вместо всех этих bool лучше использовать один uint32_t?

enum class Flags : unit32_t
{
    hover = 1 << 0,
    active = 1 << 1,
    enabled = 1 << 2,
    movable = 1 << 3,
    resizable = 1 << 4,
    // ...
};
uint32_t entityFlags = 0;

Ну я привык к такому виду в так сказать внешнем API

ui_elem_get_as("button",ui_button)->active = false;

или

ui_button * btn = ui_elem_new("console_button",ui_button);
...
btn->active = config_get_bool(cfg,"console_button_active");
...

То есть всё явное, ну да конечно жирное ну, мне так удобнее.

А вот для внутренних вещей да надо кое что на флаги перевести, я всё время про них забываю и перманентно фигачу булы.

Ну я ещё имею склонность тупо флаги забывать основательно, обычно когда что-то забываю как что работает или где что прикрученно я смотрю в структуры это для меня как документация и там я привык видеть полную однозначность ну. Короче это скорее моя причуда короче =)

Можно так:

void setFlag(Flags flag);
void addFlag(Flags flag);
void clearFlag(Flags flag);

Или так (я предпочитаю этот вариант):

uint32_t getFlags() const;
void setFlags(uint32_t flags);

И, кстати, для чтения параметра использую такую запись:

template<typename T>
T getValue("name", const T& def) const;

Что позволяет указать дефольтное значение и тип. Кроме того, используется одно название метода для разных типов.

Почему в первом случае подсветки нет, а во втором подсветка кода есть? В обоих случаях использовал markdown с указанием c++.

Ну для нутрей надо как нибудь порефракторить, в рендере например, там вообще надо тотально уже начать мусор разгребать, оптимозировать и в целом рефракторить.

А ща дела насущные, тупа переменную назвать, флаг же тоже надо называть один хрен =) Окошко размер которого могут или не могут менять его внутренние элементы.

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

вот тут Как называется состояние UI контейнера/окна? (комментарий) подсветки вообще нету у меня

Да, надо подзапариться и сделать для конфигов указание дефолтного значения в случае если опции нет и диапазоны мож ещё добавить разрешённых значений для опции. Ну как бы у меня это есть, но обычно обёрткой через проверки что не всегда удобно. Хорошая мысля. А одна процедура для всех типов это будет не проблема у меня всё храниться в void * которые где то распиханы по массивам а где то в листах живут. И по имени приводятся к нужному типу так как имя привязано к типу.

вот тут Как называется состояние UI контейнера/окна? (комментарий) подсветки вообще нету у меня

О том и речь - тут подсветки и у меня нет, а в следующем комментарии подсветка есть.

диапазоны мож ещё добавить разрешённых значений для опции

Это уже задача виджета/контрола/класса/вотэвер определять диапазон. Конфиг лишь должен уметь прочитать значение указанного типа или отдать дефолтное, если его нет.

Ага, кажись понял. Я бы назвал наверное «stretchable», если одним словом.

Ну, хм, по идее вроде норм, это как resizable по смыслу только для другого, отложу пока рядышком и если потом от остальных фигулин по смыслу коллизий не будет внесу в структурку. Апсибо =)

А что насчет adaptive??? Именно! adaptive идеально

Дa! Но нет… adaptive очень общее понятие, что бы я сам не путался я сразу зарезервировал его на потом, в планах (когда я полностью функционал контейнеров допилю до сотояния что бы можно было на изи сделать к примеру такое гибкое ui как в блендере) я хочу сделать адаптивное поведение контейреров когда они в режиме окон для пользователя ну то есть экрана (реального или виртуального когда контейнер внутри контейнера) что бы автоматически подстраивать размер окна в зависимости от ситуации, например распахнуть если окно потащить вверх, свернуть в шапку и развернуть если провернуть колёсиком мышки, выровнять по левому/правому краю экрана если утащить его в бок с «усилием» , поделить размер окна на два если в край притащил ещё одно окно , выровнять окна по сетке если на экране их 2x2 3x3 4x4 и т.д. Изменить размеры одного окна и остальное выровняется само как окна в vim. Вот всю эту катавасию возможностей я и хочу назвать adaptive =)

В Qt есть такая тема, extending extandable shrinkable - этих слов пока никто в теме не написал

extending

мля, тоже ведь в тему, спасибо.

Я ща (час назад) короче такой сижу и смотрю на код и думаю, а нахер я заголовок контейнера когда он в режиме окна располагаю над контейнером мне ведь и проверять два раза надо находится где курсор и при отключении шапки этой размер меняется, запихал внутрь, а для элементов координаты x=0 y=0 сдвигаются оффсетом под шапку, без задней мысли нахерачил для всего и вся учёт оффсетов получил сломанный расчёт координат, вылет окна за пределы границ инвертирование размера элементов и вообще всё сломал нахер ахахахахах сук. (на эту херню я убил час а исправлять придётся завтра весь день ибо коммиты и история в vim для слабаков я ипал) Короче надо писать нормальный калькулятор размеров, а то боюсь когда я захочу то что выше написал сделать я тупа повешусь нахрен ахах. Ну эт я так, поржать =) К слову я тут ещё полез в gtk/nk/dwm и прочие смотреть как они там рулят позициями и прочим, а там везде аля

 if (layout->row.type == NK_LAYOUT_DYNAMIC_ROW) {
        float ratio = ratio_or_width;
        if ((ratio + layout->row.filled) > 1.0f) return;
        if (ratio > 0.0f)
            layout->row.item_width = NK_SATURATE(ratio);
        else layout->row.item_width = 1.0f - layout->row.filled;
    } else layout->row.item_width = ratio_or_width;

ifelsemode :D

Блин, а ведь вроде это всё можно абстрагировать вынести в отдельную библиотеку и путём пормёжки ей эвентов и позиций начальных делать расчёты без подобной лапши в 100500 состояний.

Я то себе напишу прооостенькое ибо программист я так себе, а вот кто-то более смышлёный думаю осилит библиотеку для гуя которая будет рулить всеми координатами, позициями, фичами и прочим и эту либу благополучно впихнут в себя все гуй фреймворки и не только. Графомнить закончил, доброй ночи :D