Board.KolibriOS.org

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

Даже если совместимость со старыми скинами не будет сохранена, катастрофы не произойдет. Если кнопка (как я надеюсь) будет добавлена, а вам нравился какой-то скин, но вы не захотите переделать его под "трехкнопочный" интерфейс - обращайтесь ко мне, я выделю 5 минут времени, чтобы это исправить.

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

Насчет четвертой кнопки "свернуть в заголовок" не уверен, потому что не сталкивался с ситуациями, когда от неё была какая-нибудь польза. Если знаете такие ситуации - поделитесь

Поддерживаю создание кнопки "развернуть". Ещё один шаг к нормальному GUI.
Помогу в переделке скинов.
"Свернуть в заголовок" не нужна.

SoUrcerer
Как же мы теперь жить-то будем без рамки-заголовка, это ж фирменная GUIфича?
Покушаешься на традиционный уклад и фундаментальные ценности, однако

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

Если кому надо на весь экран - пожалуйста, фреймбуфер к вашим услугам. Ну а дорисовать дополнительную иконку разворота на собственной рамке - с этим и ёжик справится.

Не соглашусь. Моя аргументация такая:
Я постоянно работаю на весь экран с текстовыми редакторами, файловыми менежерами и браузерами - и мне совсем не улыбается работать в четверть экрана лишь потому, что "приложение знает свой оптимальный размер". ОС многозадачная - а я нет. Тебе, как работающему со встроенными решениями, нет большой разницы, что и как рисуется. Мне, как человеку, который работает в Колибри с прикладным ПО, разница есть.
Само наличие возможности развернуть окно на весь экран радует, но не сильно. Большинство конечных пользователей об этой возможности не знает, потому что даблклик по заголовку - не есть очевидное действие. А вот нажатие на кнопку разворота - очевидное действие.
Да, кнопку разворота может рисовать само приложение - но при этом её положение будет не между "свернуть в панель" и "закрыть окно", что есть плохо - у людей есть привычки, и если их использование обладает положительными чертами, то эти привычки стоит поддерживать.

Проведем мысленный эксперимент. Допустим, мы создали программу, у которой есть две кнопки "Сделать зашибись". На первой кнопке нет поясняющей надписи (или, может быть, абстрактный узор). Вторая кнопка намного больше первой, но она не рисуется на экране, просто определяется как область, и делает то же самое, что и первая, если по ней дважды щелкнуть.
Попасть проще по большой кнопке - но человек, который не будет знать, что там есть кнопка, не будет по ней щелкать. Двойной клик вдобавок сложнее, чем несложный (не pixel-perfect, я имею в виду) прицел+одинарный клик.
И самое главное. Не смотря на то, что кнопка "сделать зашибись" может не быть подписана ясным образом, любопытство многих людей заставит эту кнопку нажать, оценить "зашибись" и начать кнопкой пользоваться. Невидимая кнопка будет оставаться неизвестной.

art_zh wrote:А если серьезно - кнопка разворота до сих пор никому нафиг была не нужна, потому что каждое приложение изначально знало свой оптимальный размер (оно же само себя рисует - попиксельно!).

Также, как и браузер, ага. Если её небыло это совсем не означает, что никому она не была нужна.

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

И вовсе не обязательно для этого менять GUI.

Ты предлагаешь сделать так, чтобы все "современные" программы
1) не использовали окно со скином
2) рисовали скин сами
3) обрабатывали нажатие на кнопку разворота на весь экран сами
М? В ядре уже есть код для распахивания окон; в ядре уже есть код, который определяет, допускает ли окно распахивание. Все, что от кода требуется - зарезервировать еще одну системную кнопку и отрисовывать её. Это добавит такой удобный функционал во все программы, без переписывания. Без переписывания KFAR, Tinypad, HTMLv, Eolite, HEED, Kiv, ZSea, Shell, и так далее.
Это путь наименьшего сопротивления. Проще только оставить всё, как есть - разве нет?

имхо все, что можно сделать без помощи ядра - надо делать без помощи ядра.

сколько у тебя программ, требующих такой переделки?
- если одна-две,- не лезь в GUI.
- если 10-20,- тем более не лезь в GUI.
Там костылей и так столько, что уже малой кровью ничего не выправить.

Лучше собери типовой код в DLL, и полный вперед.

Собственно что мешает сохранить старый формат и ввести дополнительно новый? Надо просто сесть и подумать, как это лучше сделать. Говорю как человек приложивший руку к появлению разделения на "активное" и " не активное" окно в скине. В M32 окна как были без визуальных отличий, так и остались. Упаковку в SKN придумал уже mike.dld и проделал большую работу, но начинал это дело я. Вроде в history.txt есть упоминание.

Вариант, который предложил сейчас art_zh, тоже выглядит очень интересно. У меня сейчас своих забот выше крыши, но вопрос, при всей его "малости", серьезный.

ОООО, раз уж зашел такой холивар, то приложу свою руку к этому!
Предлагаю, помимо кнопки свернуть и развернуть, за одно увеличить секцию таблицы системных цветов. Конечно позиция:

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

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

Со своей стороны, предлагаю поссильную помощь, в ближайшую неделю могу подготовить адекватное рабочее предложение (Request for Comments, RFC) в котором распишу все за и против, про документирую каждую запись из таблицы системных цветов и на сколько ее следует увеличить (а это не много) и зачем. А также сколько слотов зарезервировать. Отрисую все в наглядном виде и представлю в виде PDF. А там можем и продолжить дискуссию и подкорректировать.

PS: могу помочь в дальнейшем с переделкой скинов.

PPS: да каждый скин вырастет в размере байт на 40, но это не так существенно как мне кажется по сравнению со стандартизацией внешнего вида.

Akyltist
При разработке нового стандарта, следует учесть наличие цветов для @PANEL. Мне пришлось в INI файл выносить, когда код переписывал - в системной палитре не было нужных цветов, а это заранее проигрышный подход.

Mario_r4 wrote:Akyltist
При разработке нового стандарта, следует учесть наличие цветов для @PANEL. Мне пришлось в INI файл выносить, когда код переписывал - в системной палитре не было нужных цветов, а это заранее проигрышный подход.

Обязательно учту, есть еще замечания что нужно учесть, не выпустить из виду, дабы ничего не упустить? Лучше на берегу все сделать, чем потом в море выяснять, что не стоило затыкать "ту щель в дне" пластилином.

PS: отдам сегодня диплом на подшивку, если комитет ошибок не найдет и займусь спекой.

От системных кнопок вреда больше, чем пользы. У ядра приоритет в обработке событий, реализовать поведение отличное от запрограммированного в ядре невозможно.

Serge wrote:У ядра приоритет в обработке событий, реализовать поведение отличное от запрограммированного в ядре невозможно.

Для подавляющего большинства программ это и не нужно.