как запустить chromium развернутым на весь экран?
Собственно вопрос в заголовке. СПС.
Правой кнопкой мыши на заголовок окна — «использовать рамки и строку заголовка системы»
гугли ключи запуска
как запустить chromium развернутым на весь экран?
Правой кнопкой мыши на заголовок окна — «использовать рамки и строку заголовка системы»
вопрос не про это, вопрос про запуск в полно-экранном режиме
Re: как запустить chromium развернутым на весь экран?
Ну я же сказал ключи.
Какие все нынче ленивые, даже маны по ключам почитать не могут.
Делай так:
Какие все нынче ленивые, даже маны по ключам почитать не могут.
тих тих я же не тебе ответил, а rise. а по твоему совету пошел гуглить ключи, во что на гуглил ))) http://peter.sh/experiments/chromium-command-line-switches/
Я тебе дал ключ запуска в фулл скрине.
Вот правильный ключ —enable-kiosk-mode СПС за наводку
А чем мой неправильный?
Вот правильный ключ —enable-kiosk-mode СПС за наводку
Не вводи людей в заблуждение
—enable-kiosk-mode Enable Kiosk mode for ChromeOS
F11 после запуска.
Re: как запустить chromium развернутым на весь экран?
Попробовал у себя. Запуск происходит в той же геометрии, как перед закрытием.
Приходи, починю тебе руки. Версию сначала скажи.
18.0.1025.151 (DEV 130497 Linux)
Понятно. У меня 20.0.1107.0. Киоск начинает работать правильно только если пускать с ключём —kiosk и последующим нажатием F11.
Второй логичный вопрос будет про wm. Надо будет попробовать в openbox.
PS: я не топикстартер разумеется, просто стало интересно.
Я не пользуюсь, запустил 2 раза всего. 1 раз для теста перед постом второй раз после твоего поста.
В обоих случаях сразу фуллскрин из которого нельзя выйти F11 только альт-таб или альт-ф4
Источник
Firefox в полноэкранном режиме
Это возможно? Пробовал это руководство, только при старте системы — запускается браузер, но в полноэкранный режим не выходит. В режиме текущей сессии браузер худо-бедно ещё запускается этим скриптом в полноэкранном виде. Что может влиять на неисправный автостарт этого скрипта при заходе в систему?
Сделал такой вот скрипт в автозагрузке:
Иксы еще окно не отрисовали (или еще какая хрень не догрузилась), а ты его уже телипаешь на фулскрин. Задержку в несколько сек точно ставил, увеличивал? Возможно перед запуском фф тоже нужна.
Если твой WM не умеет (а какой у тебя WM?), то попробуй поставить devilspie. Напиши правило в
(я надеюсь, что в правиле не ошибся — писал вслепую)
какой WM ? В моем bspwm это можно местными средствами делать, при этом firefox все валидно подхватывает
Нет, всё бодро грузится, открывается бразер, но не разворачивается на полный экран. Задержку увеличивал до 9 секунд. Никакого эффекта. Т
Unity. Ubuntu 14.04.5.
А перед запуском фф задержку ставить пробовал?
Тогда, может, поставить Compiz Config Settings Manager? Там есть подобные настройки для каждого приложения в разделе Window Management -> Window Rules + Place Windows
Всем ещё раз спасибо за идеи!
Ну а как решил задачу в итоге?
В теле темы всегда пишу, чтобы люди долго не листали переписку).
В теле темы всегда пишу, чтобы люди долго не листали переписку).
Ну, если честно, то решение с xdotool странное. Для твоей задачи инструмент хоть и рабочий, но такое решение — кривой костыль. Какие-то паузы выжидать. Зачем? 11 секунд! В иксах есть механизмы присвоения окнам свойств в момент их появления. Окно еще не отобразилось, а WM уже будет знать, как его отображать. То есть это либо оконные менеджеры умеют сами, либо сторонние средства типа devilspie (а в случае Unity — CCSM).
К тому же, твое решение некорректное. Ты хоть понимаешь, куда посылается F11? Оно посылается не конкретно окну firefox, а окну, которое на момент срабатывания xdotool будет иметь input focus. Если кто-то перехватит фокус за твои 7 секунд (что-то вскочило на экране), то F11 firefox не получит.
Исправил код. Замечание верное. Фокус реально сбивался).
Задержка нужна, т.к. глючный Wi-Fi адаптер долго подсоединяется к сетке. Если он не соединится вовремя, браузер раскроется на весь экран со страницей ошибки. В итоге, время задержки было увеличено аж до 27 секунд (!). Это киоск, фэйлы с незагруженными страничками — крайне не желательны. А так, да, если коннект быстрый, смысла ставить такое долгое время нет.
У огнелиса есть расширения для режима киоска.
Создай отдельный профиль firefox —ProfileManager и установи туда расширения необходимые. Потом стартуй по firefox -P .
И запускать через N секунд после старта тоже некорректно. Скриптом проверяй поднялась ли сеть, а потом стартуй огнелис.
Исправил код. Замечание верное. Фокус реально сбивался).
Ты его странно исправил, это мягко говоря. 🙂 Твой код ничего не делает. То, что ты написал, не делает ничего. Надо хотя бы так (classname, class, name можно посмотреть в xprop, например):
Это киоск, фэйлы с незагруженными страничками — крайне не желательны
А для чего киоск вообще нужен? Пользователь имеет доступ к клавиатуре? Он может нажать F11 и вывести FF из полноэкранного режима? Может, тебе вообще оконный менеджер не нужен в принципе, если компьютер будет без доступа к клавиатуре и выполнять только одну задачу серфинга по интернету.
Пользователь имеет доступ к виртуальной клавиатуре, на которой отсутствуют функциональные клавиши и клавиша Ctrl. Сама система нужна для настройки некоторых устройств и сервисов.
C чего ты взял, что он ничего не делает? У меня он делает следующее: открыто для теста окно хрома, окно терминала, из которого выполняю этот скрипт. В итоге, открывается Firefox и разворачивает на полный экран, окна хрома и терминала остаются прежними. Всё работает.
Зачем это вообще на киоске?
Я когда-то делал для цати штук по районам, ничего кроме X не использовалось, никаких вм итп.
firefox —display=:0 -P /настроенный/профиль
Домашняя директория в чистом tmpfs с профилем воссоздается из тарбола перед каждым запуском фф, во избежание. По вкусу можно использовать tmpfs+overlay
Экранная клава, емнип, была в виде дополнения к фф.
Стартовало все мгновенно и ничего не ломалось.
Нет, не делает. Что эта строчка делает? Она в первой части просто запрашивает XID окон, которые подходят под критерий «-name ‘firefox’ и выводит их в stdout, а потом выполняет xdotool key «F11» , где снова достается окну, у которого фокус ввода. Если перед FF что-то перехватит фокус, то ему не достанется. Об этом я, кажется, выше сказал. Хочешь проверить? Пожалуйста. Открой FF, открой терминал перед FF. Терминал имеет фокус ввода. Теперь в терминале введи свою строчку.
Что ты получаешь? Первая часть просто выведет номер, вторая передаст терминалу, а Firefox так и станется в своем состоянии, ничего не получит. То есть то, что ты пытался исправить после моего замечания, не исправлено. А теперь попоробуй мою строчку из такого же состояния.
Аналогично. Надо было поставить на ЦЭВМ торгового автомата браузер, так как интерфейс у них был написан на HTML. Вкатил FF (тогда еще был xulrunner). Но надо было, чтобы в приложении была только область рендера и никаких там менюшек, кнопок, табов, строки статуса и пр. Написал тривиальный XUL, в котором осталась только область отображения нужного размера (тег
, вертикальный экран 1440×900). Все стартовало со стартовой странички в атрибуте «src». Никаких там WM, ничего, только голые Иксы.
Прошли те времена .
Когда я запускаю в скрипте, то всё выводится нормально. Если выполнить отдельно команду, то да, раскрывается терминал.
А теперь попоробуй мою строчку из такого же состояния.
Попробовал. На экране появился браузер Firefox. Раскрытия на весь экран не было.
Попробовал. На экране появился браузер Firefox. Раскрытия на весь экран не было.
Этого не может быть. Какую строчку ты попробовал? У меня все раскрывается после того, как FF выдвигается вперед.
Вот эту команду ввёл в терминале при раскрытом сзади Firefox’e:
А FF поднимается поверх терминала после выполнения этой строчки?
Да, фокус переключается на Firefox.
Не знаю. Должно работать. У меня работает из любого положения — пусть даже FF похоронен по десятью окнами. Он должен поднять окно FF, дождаться конца этой операции и только после этого переслать F11. Не знаю, в чем может быть дело у тебя. Попробуй добавить delay:
если команду написать так:
Я на федоре пробую. Не знаю, наверное, не имеет значения.
ТЫ делаешь то же самое, что и делал. xdotool передает F11 окну, которое имеет фокус, а не конкретному окну. Но у меня есть предположение, почему так происходит. Подчеркну, что это предположение. У меня FF еще старый, так как я хочу подзадержаться на GTK2. FF на GTK3 меня выбешивает, а у тебя наверняка все наоборот.
Ситуация такая. Когда в параметрах xdotool указывается конкретное окно, то он использует для передачи сообщения F11 клиентское сообщение SendEvent, а если окно не указывается (то, как ты сделал), то используется расширение XTEST, которое посылает кнопку тому, кто владеет фокусом. Есть одна фишка, что некоторые тулкиты или отдельные приложения могут фильтровать сообщения SendEvent и поэтому никак не реагировать. Этот момент много где описан и также в xdotool:
FF на GTK2 реагирует, а вот на GTK3 может не реагировать. Тогда выходя нет — поднимать окно и тут же второй командой через XTEST долбить F11.
А я же выше написал. Из xprop например.
Интересная инфа. Спасибо!
Ну, да. В общем, я тут проверил на Evince, который GTK3. Игнорирует он сообщения, отправленные ему напрямую. При этом если фокус имеет, то сообщения через XTEST нормально отрабатывает. Чудится мне, что это политика уже на уровне GTK3 сделана. Возможно, что из каких-то своих соображений безопасности. О таких соображениях, например, в xterm говорится:
То есть твой последний вариант с отдельным xdotool после поднятия окна наверх единственный рабочий вариант (поднятием окна заведует WM, а не приложение, поэтому оно-то срабатывает).
Источник
Запуск приложений развернутыми на весь экран
Раньше, когда у меня была система на базе Debian Squeeze, чтобы запускать нужные приложения развернутыми на полный экран, можно было просто отредактировать .config/openbox/rc.xml, например, так:
Кто вас научил лазить в /etc за пользовательскими настройками? Мало того, что это дурной тон, так у общесистемных конфигов ещё и приоритет ниже, чем у юзерских. Правьте $XDG_CONFIG_HOME/openbox/rc.xml, и будет вам счастье.
Научил гугл. Редактирование локального rc.xml ничего не дает (точнее, он уже был отредактирован, когда стоял Debian Squeeze, а после обновления до Wheezy эти настройки игнорируются).
Не может быть такого. В каком каталоге лежит конфиг?
А если другие настройки в этом файле менять? Хоткей, например, какой-нибудь переназначить?
Переназначение хоткеев работает. Проверил xml на xmlvalidation.com, ошибок не найдено. Его содержание.
Дык, ещё бы оно работало. Как он должен приложения-то к правилам матчить, по-вашему, если у вас полей, кроме имени, ни в одном из них нет?
А зачем ему знать что-то кроме имени? Кроме того, раньше-то ведь нормально работало.
А зачем ему знать что-то кроме имени?
А чему оно соответствует?
Кроме того, раньше-то ведь нормально работало.
Понятия не имею как, ведь эти имена явно в большинстве случаев не соответствуют значениям, которые выдаёт obxprop. Я всегда в правилах класс указывал.
Названию процесса. Насколько я себе это представляю, по процессу ищется окно, определяется его handler и меняются свойства.
ведь эти имена явно в большинстве случаев не соответствуют значениям, которые выдаёт obxprop.
В этой утилите все окна должны быть отображены? Она находит у меня только terminator.
Я всегда в правилах класс указывал.
Насколько я себе это представляю, по процессу ищется окно, определяется его handler и меняются свойства.
Как вы думаете, оконному менеджеру заняться больше нечем?
В этой утилите все окна должны быть отображены?
Нет, только то, по которому кликнете.
Значение переменной WM_CLASS из выхлопа того же obxprop.
Как вы думаете, оконному менеджеру заняться больше нечем?
Похоже, этим занимается obxprop.
Кликаю на iceweasel, получаю следующее (pastebin не работает).
Не вижу тут iceweasel. WM_CLASS(STRING) = «tint2», «Tint2»
Нет, он смотрит в атрибуты окна, так же, как и WM.
Вы по панели и кликаете, значит, а не по окну.
Вы по панели и кликаете, значит, а не по окну.
Чего-то я протупил 🙂
Короче говоря, проблема была в том, что в этом rc.xml названия этих классов, как правило, идут с большой буквы. Стоило мне поменять
Короче говоря, проблема была в том, что в этом rc.xml названия этих классов, как правило, идут с большой буквы.
Это не в rc.xml, а в свойствах иксовых окон, которые присваивают им сами приложения. А в конфиге они просто должны соответствовать.
Теперь мне интересно как оно раньше работало. 🙂
Видимо, раньше парсинг названий классов был нечувствителен к регистру, или же было больше вариантов. Например, для stardict дается
Видимо, раньше парсинг названий классов был нечувствителен к регистру, или же было больше вариантов.
Первое маловероятно, скорее, второе. Но тоже странное изменение.
Возможно, просто баг. Логичнее
А у многих приложений так поменялось поведение?
Пока что заметил у gnumeric, konqueror и icedove («Icedove»,«Mail»). Icedove, возможно, не считается, потому что в правилах до этого у меня стоял «thunderbird».
Кстати, terminator работает по-прежнему нормально.
Источник
