Comments 41
А почему у Вас на левой кнопке логотип Убунту? :)
Интеренсно, а реально ли сделать аналог для linux. Или все прочно завязано на WinAPI? Но и в таком случае, вероятно, есть варианты решения… Нужно разобраться.
Думается, что реально. В данном случае всё завязано на WinAPI, собственно как что угодно другое, скрытое фреймворком Qt. Где-то проскакивали предложения воплотить подобную возможность в декораторе окон KDE, но пока лишь предложения.
Поддерживаю, только опять же, в силу несовместимости менеджеров окон решение не будет переносимо, или придется для каждого писать свое…
UFO just landed and posted this here
Ну сделайте нам бэкенты для других систем и DE, будет более кроссплатформенный класс. =)
Там проблема даже не в завязке на winAPI, всё-таки в хедере нет ни одного апишного метода, все зашиты в реализацию. Просто сам подход плохо переносимый. Особенно из за того, что напрямую в заголовке приходится рисовать.
Там за рамку вокруг окна отвечает менеджер окон. Приспособиться ко всем различным менеджерам окон вряд ли возможно, тем более что некоторые эту рамку вообще не рисуют. Остаётся лишь убирать рамку вообще и рисовать её, включая название окна и кнопки, самому, но тогда результат не будет соответствовать стилю других, обычных окон.
Не «стремится», а «стремиться». Не «недописан», а «не дописан».
А как это будет выглядеть в XP?
Увы, как надо работает только в Windows Vista и Windows 7, да и то со включённой «Aero». В ХP все контроллы из заголовка сместятся вниз, заголовок окна будет совершенно обычным. Чтобы добиться такого эффекта в XP, надо вручную рисовать заголовок, границы окна, кнопки… Это хлопотно.
Никак. То есть кнопки просто будут на уровень ниже, а оформление окна будет абсолютно стандартным.
На скрине gui-версия программы, выводящей собственный код?
по правде говоря я не совсем понимаю для чего делать такое, ведь Qt был разработан для того чтобы программы на нем везде работали одинаково, а тут придется для каждой ОС рисовать свое оформление.
Не одинаково, а максимально приближено к поведению родных для среды прог. Тут уж приходится идти на жертвы, благо класс крошечный и практически ни к чему не обязывающий. В дальнейшем постараюсь его допилить до состояния: кастанул его на окошко и забыл. Правда для табов таки придется лезть в метод addWidget — это самая плохо переносимая часть класса.
Зашел прочитать кроссплатформенную реализацию, разочаровался
А как вы её себе представляете? Вариант рисовать рамку не годится. В X11 окошки рисуются сервером, к ним из кутей просто не добраться. На Макоси может и получится, но у меня нет её, поэтому не могу запилить для неё бэкенд. А уж заниматься велосипедизмом и писать свой декоратор окон увольте.
Не представляю, поэтому зашел почитать.
Браво! Полезная штука! Действительно жаль, что такое под Линукс не увижу, хотя есть вариант скрыть стандартное оформление, тогда придется перемещение окна, писать самому и вообще оформление системное для приложения потеряется:
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
setAttribute(Qt::WA_TranslucentBackground);
setWindowFlags(Qt::FramelessWindowHint);
// ...
}
А если над рамкой окна вывесить свой тулбар и таскать его, отслеживая перемещения окна?
Нет, идея рисовать что-то в заголовке для Linux вообще малоподходящая. Во-первых, может быть включён композитный режим и, к примеру, желейные окна — такой метод будет выглядеть жутко. Во-вторых, абсолютное положение окна — это всего лишь рекомендация серверу, которую он может игнорировать. Есть тайловые менеджеры, которые не делают одно окно поверх другого. В-третьих, заголовка может вообще не быть — как в тайловых менеджерах, так и в обычных (floating).
В тяжёлых случаях тулбар можно переносить или отключать в опциях. Всё же большинство* менеджеров заголовок окна используют.
* По количеству пользователей
* По количеству пользователей
Вообще, ждем Wayland'а и уж там добиваемся, что бы была штатная фича на уровне протокола для этого дела. Это конечно когда они примутся за протокол для декораций окошек. Но наличие плюх типа DBusMenu воодушевляет. Например кдешники через него хотят во всех прогах сделать QMenuBar переносимым в кнопку в заголовке.
Ну, про большинство — да, соглашусь, но встаёт вопрос декораций: kwin3, kwin4, metacity, mutter, compiz-fusion, icewm, etc. В общем, нет единого протокола. Да и нарушение идеологии, в общем-то. К тому же надо динамически реагировать (у меня, к примеру в KDE4 на Win+Del висит убрать/показать декорации).
UFO just landed and posted this here
А он этого и не делает. Заголовок отдельно, содержимое отдельно. И Chrome этого не делает, есть режим «без заголовка» и «с заголовком».
UFO just landed and posted this here
Мы про Linux говорим? Какая оранжевая кнопка? Вот картинка с сайта, как оно в GNOME выглядит, у меня KDE, просто заголовок окна другой.
Чую меня сейчас прирежут, но никто не подкинет примера реализации на Delphi?
Главная болезнь всех манипуляций с заголовком решена или не подвержен, он продолжает слушаться оконного менеджера? Например горячие зоны при разворачивания на весь экран, привязке к стороне и так далее. А то как посмотришь на некоторые реализации, которые в наглую игнорируют стандартное поведение.
Окошко можно растягивать за границы, таскать за заголовок, разворачивать и восстанавливать двойным тыком по заголовку, работает Aero Snap (или как там называется разворот окна при подведении к границе экрана), — всё работает как и прежде.
Практически адекватно работает. В некоторых случаях кнопки не пропускают мышиные события сквозь себя.
Кстати, а почему отказались от своего заголовка окна, как в старой версии?
Меня это интересует с сугубо практической точки зрения — я по воле судьбы пишу такой вот свой кроссплатформенный «Window Decorator», хочу узнать немного про подводные камни.
Меня это интересует с сугубо практической точки зрения — я по воле судьбы пишу такой вот свой кроссплатформенный «Window Decorator», хочу узнать немного про подводные камни.
Sign up to leave a comment.
Рисуем виджеты в заголовке окна