К сожалению, это только моё предположение. Было ли подобное реализовано кем-то на практике — не знаю. Подозреваю, что многомониторность системе предоставляет драйвер видюхи, т.е. на уровне приложения добавить плюс один монитор невозможно, что затрудняет реализацию.
Ну, не только. Часто на одном десктопе могут быть открыты одни терминалы, но при этом в самих терминалах может быть что угодно. Например, в одном редактируешь скрипт, в другой его запускаешь.
Хотя, это как раз плохой пример. Если разобраться, выходит, что все толковые программы используют собственную организацию окон внутри главного окна — взять хоть vim/emacs, хоть виндовые дебаггеры (windbg, ollydbg), хоть вкладки в браузерах. Да тот же Фотошоп — его тулбары, списки слоёв и т.п. — казалось бы, кто мешал сделать их отдельными окнами и управлять ими наравне с остальными окнами Windows? Так нет же — создаётся одно родительское окно (своего рода «виртуальный десктоп»), включающее в себя кучу дочерних.
Собственно, многодесктопность — по сути, продолжение того же принципа, но уже применительно не к конкретной программе (фотошопу), а к организации работы с компьютером в целом.
Не только. Вообще, на мой взгляд, использование нескольких виртуальных десктопов, особенно большого их количества (6-8 шт.), свойственно людям, больше использующим в работе клавиатуру.
Возвращаясь к примеру с треем — даже если программа умеет сворачиваться в трей, вызвать её оттуда хоткеем становится проблемно (если она сама не поддерживает такой функции). А с дополнительным десктопом эта задача решается для любого произвольного окна: нажал один хоткей — отправил окно на другой десктоп («свернул в трей»), нажал другой — переключился на этот десктоп («развернул из трея»).
Если так рассуждать, то и сворачивания программы в трей не нужно (кто мешает держать лишнее окно на рабочем столе?), однако эта фича есть у многих программ под Windows.
В статье, к сожалению, не отражено главного — не указан принцип работы каждого из инструментов. В итоге сделать выбор, прочитав статью, затруднительно. Многие «менеджеры десктопов» Windows работают по схожему принципу — они скрывают все окна (чуть ли не через SW_HIDE), относящиеся не к текущему десктопу (при этом как таковых «десктопов» в системе нет, есть скорее наборы окон). В итоге новые окна и мессадж боксы любая программа открывает на первом десктопе, а не на текущем, плюс появляется ряд проблем, если программа сама использует сокрытие своих окон (например, когда прячется в трей).
Это также упомянуто в описании Desktops: «Unlike other virtual desktop utilities that implement their desktops by showing the windows that are active on a desktop and hiding the rest, Sysinternals Desktops uses a Windows desktop object for each desktop». Есть ещё интересный вариант с созданием виртуального монитора и расширением десктопа на него. Неплохо было бы дополнить статью подобной информацией.
Я лишь попытался объяснить, почему заметка вызвала негативную реакцию.
По определению из википедии назвать «сетью» можно любую чушь. Например, возьмём два компьютера, закрепим мышь одного над сидиромом другого. Теперь напишем программку, которая по изменению положения курсора мыши будет определять, был ли открыт сидиром на втором компьютере.
Система связи компьютеров есть? Есть. Физические являния для передачи информации используются? Используются. Но можно ли это назвать «сетью» и отправлять на хабр «способ связать компьютеры в сеть с помощью сидирома и мыши»? Я бы не стал.
Вы обещали «способ связать в сеть», а «сеть» — это как среда, так и протокол связи. Без протокола не будет сети. Говоря формально, протокол у вас есть, но ваш собственный, поверх XMPP. Инкапсулировать в него другой протокол уровня приложения (например, RDP) штатными средствами невозможно.
Статья называется «Способ связать разные компьютеры в одну сеть». «Сеть» предполагает использование стандартного протокола. Например, соединив компьютеры в VPN, можно слать айпи пакеты, инкапсулировав в них что угодно — хоть тот же XMPP, хоть RDP, хоть свой протокол.
У вас же связь между компьютерами наличествует, но стандартного протокола нет (вместо этого вы придумываете свой протокол, инкапсулированный внутрь сообщений XMPP). Следовательно, говорить про то, что вы таким образом «связываете компьютеры в одну сеть» нельзя, вы просто описываете способ как послать произвольное текстовое сообщение с одного компьютера на другой и обработать его скриптом на питоне. Что, впрочем, не даёт людям права грубить в комментариях…
Негодование комментатора можно понять. Статья называется «Способ связать разные компьютеры в одну сеть» (т.е. фактически обещается некая новая реализация VPN), а речь в ней идёт про то, как послать джаббер-сообщение из питона через библиотеку xmpppy.
Если бы статья называлась «Простейший пример отправки XMPP-сообщения» и размещалась бы в блоге Python — никто бы не назвал её «хернёй».
Хотя, это как раз плохой пример. Если разобраться, выходит, что все толковые программы используют собственную организацию окон внутри главного окна — взять хоть vim/emacs, хоть виндовые дебаггеры (windbg, ollydbg), хоть вкладки в браузерах. Да тот же Фотошоп — его тулбары, списки слоёв и т.п. — казалось бы, кто мешал сделать их отдельными окнами и управлять ими наравне с остальными окнами Windows? Так нет же — создаётся одно родительское окно (своего рода «виртуальный десктоп»), включающее в себя кучу дочерних.
Собственно, многодесктопность — по сути, продолжение того же принципа, но уже применительно не к конкретной программе (фотошопу), а к организации работы с компьютером в целом.
Возвращаясь к примеру с треем — даже если программа умеет сворачиваться в трей, вызвать её оттуда хоткеем становится проблемно (если она сама не поддерживает такой функции). А с дополнительным десктопом эта задача решается для любого произвольного окна: нажал один хоткей — отправил окно на другой десктоп («свернул в трей»), нажал другой — переключился на этот десктоп («развернул из трея»).
как-то так:
Section «Device»
Identifier «Screen0»
Driver «radeon»
Screen 0
EndSection
Section «Device»
Identifier «Screen1»
Driver «radeon»
Screen 1
EndSection
и после этого любимый windows manager настраиваешь на два экрана
как-то так:
Section «Device»
Identifier «Screen0»
Driver «radeon»
Screen 0
EndSection
Section «Device»
Identifier «Screen1»
Driver «radeon»
Screen 1
EndSection
и после этого любимый windows manager настраиваешь на два экрана
В статье, к сожалению, не отражено главного — не указан принцип работы каждого из инструментов. В итоге сделать выбор, прочитав статью, затруднительно. Многие «менеджеры десктопов» Windows работают по схожему принципу — они скрывают все окна (чуть ли не через SW_HIDE), относящиеся не к текущему десктопу (при этом как таковых «десктопов» в системе нет, есть скорее наборы окон). В итоге новые окна и мессадж боксы любая программа открывает на первом десктопе, а не на текущем, плюс появляется ряд проблем, если программа сама использует сокрытие своих окон (например, когда прячется в трей).
Это также упомянуто в описании Desktops: «Unlike other virtual desktop utilities that implement their desktops by showing the windows that are active on a desktop and hiding the rest, Sysinternals Desktops uses a Windows desktop object for each desktop». Есть ещё интересный вариант с созданием виртуального монитора и расширением десктопа на него. Неплохо было бы дополнить статью подобной информацией.
См. выше — «нужно настраивать роутер. Он запаролен, пароля нет, и никто не знает...»
А то! Промышленный объект.
По определению из википедии назвать «сетью» можно любую чушь. Например, возьмём два компьютера, закрепим мышь одного над сидиромом другого. Теперь напишем программку, которая по изменению положения курсора мыши будет определять, был ли открыт сидиром на втором компьютере.
Система связи компьютеров есть? Есть. Физические являния для передачи информации используются? Используются. Но можно ли это назвать «сетью» и отправлять на хабр «способ связать компьютеры в сеть с помощью сидирома и мыши»? Я бы не стал.
У вас же связь между компьютерами наличествует, но стандартного протокола нет (вместо этого вы придумываете свой протокол, инкапсулированный внутрь сообщений XMPP). Следовательно, говорить про то, что вы таким образом «связываете компьютеры в одну сеть» нельзя, вы просто описываете способ как послать произвольное текстовое сообщение с одного компьютера на другой и обработать его скриптом на питоне. Что, впрочем, не даёт людям права грубить в комментариях…
Если бы статья называлась «Простейший пример отправки XMPP-сообщения» и размещалась бы в блоге Python — никто бы не назвал её «хернёй».