Кнопки "Развернуть окно" и "Вернуть к обычному размеру"

All that makes Kolibri beautiful outside while we are working inside
  • Поддерживаю создание кнопки "развернуть". Ещё один шаг к нормальному GUI.
    Помогу в переделке скинов.
    "Свернуть в заголовок" не нужна.
    Из хаоса в космос
  • SoUrcerer
    Как же мы теперь жить-то будем без рамки-заголовка, это ж фирменная GUIфича?
    Покушаешься на традиционный уклад и фундаментальные ценности, однако :D

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

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

    Проведем мысленный эксперимент. Допустим, мы создали программу, у которой есть две кнопки "Сделать зашибись". На первой кнопке нет поясняющей надписи (или, может быть, абстрактный узор). Вторая кнопка намного больше первой, но она не рисуется на экране, просто определяется как область, и делает то же самое, что и первая, если по ней дважды щелкнуть.
    Попасть проще по большой кнопке - но человек, который не будет знать, что там есть кнопка, не будет по ней щелкать. Двойной клик вдобавок сложнее, чем несложный (не 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 есть упоминание.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Вариант, который предложил сейчас art_zh, тоже выглядит очень интересно. У меня сейчас своих забот выше крыши, но вопрос, при всей его "малости", серьезный.
  • ОООО, раз уж зашел такой холивар, то приложу свою руку к этому!
    Предлагаю, помимо кнопки свернуть и развернуть, за одно увеличить секцию таблицы системных цветов. Конечно позиция:
    со своим собственным окном программа может делать все, что ей заблагорассудится.
    правильная, в ядро мусор пихать не стоит! Но в данном случае, если этого не сделать, то у каждой программы будет свой цвет прогрессбара, свой цвет эдитконтролов, скролов и плевать на дизайн, как скины не крути, а таким набором в таблице не выкрутиться.

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

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

    PPS: да каждый скин вырастет в размере байт на 40, но это не так существенно как мне кажется по сравнению со стандартизацией внешнего вида.
  • Akyltist
    При разработке нового стандарта, следует учесть наличие цветов для @PANEL. Мне пришлось в INI файл выносить, когда код переписывал - в системной палитре не было нужных цветов, а это заранее проигрышный подход.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:Akyltist
    При разработке нового стандарта, следует учесть наличие цветов для @PANEL. Мне пришлось в INI файл выносить, когда код переписывал - в системной палитре не было нужных цветов, а это заранее проигрышный подход.
    Обязательно учту, есть еще замечания что нужно учесть, не выпустить из виду, дабы ничего не упустить? Лучше на берегу все сделать, чем потом в море выяснять, что не стоило затыкать "ту щель в дне" пластилином.

    PS: отдам сегодня диплом на подшивку, если комитет ошибок не найдет и займусь спекой.
  • От системных кнопок вреда больше, чем пользы. У ядра приоритет в обработке событий, реализовать поведение отличное от запрограммированного в ядре невозможно.
  • Serge wrote:У ядра приоритет в обработке событий, реализовать поведение отличное от запрограммированного в ядре невозможно.
    Для подавляющего большинства программ это и не нужно.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 6 guests