Re: Выбор GUI

[Hleb Valoshka]

On 4/27/21, D. H.  wrote:

>> Создаём окно, добавляем менюшки, QOpenGLWidget. Запускаем, переводим
>> окно в полноэкранный режим - менюшки не отображаются. Баг известен со
>> времён 5.4, когда добавили QOpenGLWidget. Когда будет исправлен -
>> непонятно, обходной путь, растянуть окно на весь экран и убрать
>> границы, не всегда работает, у нас не работал. Продолжаем пользоваться
>> устаревшим QGLWidget. А он не умеет в GL ES, если Qt собран с
>> десктопным GL. Под Wayland-ом тоже с ним проблемы, сам не пробовал, но
>> пользователи сообщали. Под офтопиком почему-то FPS значительно ниже по
>> сравнению с native windows версией.
>
> Выложи куда код, я гляну как будет время. Можно не весь если закрытый
> код. С GL не работал, но попробую помочь чем могу.


https://github.com/CelestiaProject/Celestia (морда на Qt лежит в
src/celestia/qt, для сборки нужен cmake, все нужные пакеты описаны в
INSTALL.md)

Вот тут 
https://github.com/CelestiaProject/Celestia/commit/2f7adf19d047c9fa2e9700d91fd2bf08dec09dde
пытались переехать на QOpenGLWidget

-- 
Celestia real-time space simulator:
 * https://celestia.space
 * https://github.com/CelestiaProject

Forum:
 * https://celestia.space/forum/

Re: Выбор GUI

[D. H.]

On 2021-04-25 4:34 a.m., Hleb Valoshka wrote:
> Создаём окно, добавляем менюшки, QOpenGLWidget. Запускаем, переводим
> окно в полноэкранный режим - менюшки не отображаются. Баг известен со
> времён 5.4, когда добавили QOpenGLWidget. Когда будет исправлен -
> непонятно, обходной путь, растянуть окно на весь экран и убрать
> границы, не всегда работает, у нас не работал. Продолжаем пользоваться
> устаревшим QGLWidget. А он не умеет в GL ES, если Qt собран с
> десктопным GL. Под Wayland-ом тоже с ним проблемы, сам не пробовал, но
> пользователи сообщали. Под офтопиком почему-то FPS значительно ниже по
> сравнению с native windows версией.

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

Re: Выбор GUI

[Hleb Valoshka]

On 4/25/21, D. H.  wrote:

>> Qt мог бы быть наилучшим выбором, но ситуация с поддержкой LTS-ветки
>> удручает. Есть довольно критичные баги, которые не исправляются со
>> времён 4-й версии.
>
> Лучшим выбором он и остаётся. Баги эти на бумаге вероятнее всего с
> простым интерфейсам тебя и твоих пользователей не коснуться никогда.

Создаём окно, добавляем менюшки, QOpenGLWidget. Запускаем, переводим
окно в полноэкранный режим - менюшки не отображаются. Баг известен со
времён 5.4, когда добавили QOpenGLWidget. Когда будет исправлен -
непонятно, обходной путь, растянуть окно на весь экран и убрать
границы, не всегда работает, у нас не работал. Продолжаем пользоваться
устаревшим QGLWidget. А он не умеет в GL ES, если Qt собран с
десктопным GL. Под Wayland-ом тоже с ним проблемы, сам не пробовал, но
пользователи сообщали. Под офтопиком почему-то FPS значительно ниже по
сравнению с native windows версией.


-- 
Celestia real-time space simulator:
 * https://celestia.space
 * https://github.com/CelestiaProject

Forum:
 * https://celestia.space/forum/

Re: Выбор GUI

[Hleb Valoshka]

On 4/24/21, Konstantin Fadeyev  wrote:

> Может быть - https://www.enlightenment.org/about-efl

Так оно уже в списке:

>> Elementary. Непонятно пока насчёт высокого DPI, OpenGL и упаковки.
>> Есть опасность, что может быть ориентирован на пальцетыкальные
>> интерфейсы (в истории успеха холодильники и т.п.).



-- 
Celestia real-time space simulator:
 * https://celestia.space
 * https://github.com/CelestiaProject

Forum:
 * https://celestia.space/forum/

Re: Выбор GUI

[Konstantin Fadeyev]

Может быть - https://www.enlightenment.org/about-efl

сб, 24 апр. 2021 г. в 14:07, Hleb Valoshka <375...@gmail.com>:

> Привет!
>
> Кто-нибудь тут занимается разработкой десктопных програм с GUI? На чём
> имеет смысл начинать разработку довольно несложного интерфейса?
> Желательно библиотеки с поддержкой C++, кроссплатформенность
> необязательна, но обязательна возможность работы с OpenGL и поддержка
> высоких DPI.
>
> Qt мог бы быть наилучшим выбором, но ситуация с поддержкой LTS-ветки
> удручает. Есть довольно критичные баги, которые не исправляются со
> времён 4-й версии. Пытаются предоставить свою альтернативу
> существующим решениям, из-за чего в коде полно вещей типа
> QString::fromStdString qsting.toStdString(). Документация обещает
> проблемы с перерисовкой если не использовать существующие виджеты для
> OpenGL, а просто создать контекст используя область рисования. На
> альтернативные системы надо тащить кучу библиотек.
>
> Из Gtk скоро выкинут всё. Из 4-й версии выкинули даже тулбар. До Qt по
> количеству вижетов совершенно не дотягивает, да даже до WinAPI. Из-за
> ориентации на пальцетыкальные интерфейсы на десктопах выглядит ужасно.
> API не продумывается, постоянно что-то устаревает и заменяется чем-то
> новых. Последняя проблема актуальна в том числе и для gtkmm (обёртки
> на C++). Большой плюс - упаковка виджетов вместо расстановки по
> координатной сетке, но и последняя тоже поддерживается.
>
> wxWidgets. Обёртка над вышеперечисленными, а также есть вариант с
> Xlib, но в этом варианте мало виджетов. В стабильной версии нет
> поддержки  высоких DPI. Иструменты для визуального проектирования либо
> не поддерживают всех возможностей, либо не умеют в создание
> XML-описания, либо генерируют некорректный код. Если собран с Gtk 3,
> то выглядит так же паршиво. Опять же свои реализации вместо некоторых
> стандартных (wxString, например).
>
> Со следующими не работал вообще, бегло посмотрел сайт.
>
> Fox. Нет поддержки  высоких DPI. Свои реализации стандартных вещей. Не
> понял пока как реализована расстановка виджетов в окне: упаковываются
> как в Gtk  или по координатной сетке.
>
> fltk. Нет поддержки  высоких DPI в стабильной версии. Древний C++. Нет
> упаковки, размеры виджетов нужно задавать явно.
>
> Elementary. Непонятно пока насчёт высокого DPI, OpenGL и упаковки.
> Есть опасность, что может быть ориентирован на пальцетыкальные
> интерфейсы (в истории успеха холодильники и т.п.).
>
> Есть ли жизнь с десктопным GUI в 2021 году? Можно ли выбрать хоть
> что-то, что не сломается через два года?
>
> --
> Celestia real-time space simulator:
>  * https://celestia.space
>  * https://github.com/CelestiaProject
>
> Forum:
>  * https://celestia.space/forum/
>


-- 
Константин Фадеев

Выбор GUI

[Hleb Valoshka]

Привет!

Кто-нибудь тут занимается разработкой десктопных програм с GUI? На чём
имеет смысл начинать разработку довольно несложного интерфейса?
Желательно библиотеки с поддержкой C++, кроссплатформенность
необязательна, но обязательна возможность работы с OpenGL и поддержка
высоких DPI.

Qt мог бы быть наилучшим выбором, но ситуация с поддержкой LTS-ветки
удручает. Есть довольно критичные баги, которые не исправляются со
времён 4-й версии. Пытаются предоставить свою альтернативу
существующим решениям, из-за чего в коде полно вещей типа
QString::fromStdString qsting.toStdString(). Документация обещает
проблемы с перерисовкой если не использовать существующие виджеты для
OpenGL, а просто создать контекст используя область рисования. На
альтернативные системы надо тащить кучу библиотек.

Из Gtk скоро выкинут всё. Из 4-й версии выкинули даже тулбар. До Qt по
количеству вижетов совершенно не дотягивает, да даже до WinAPI. Из-за
ориентации на пальцетыкальные интерфейсы на десктопах выглядит ужасно.
API не продумывается, постоянно что-то устаревает и заменяется чем-то
новых. Последняя проблема актуальна в том числе и для gtkmm (обёртки
на C++). Большой плюс - упаковка виджетов вместо расстановки по
координатной сетке, но и последняя тоже поддерживается.

wxWidgets. Обёртка над вышеперечисленными, а также есть вариант с
Xlib, но в этом варианте мало виджетов. В стабильной версии нет
поддержки  высоких DPI. Иструменты для визуального проектирования либо
не поддерживают всех возможностей, либо не умеют в создание
XML-описания, либо генерируют некорректный код. Если собран с Gtk 3,
то выглядит так же паршиво. Опять же свои реализации вместо некоторых
стандартных (wxString, например).

Со следующими не работал вообще, бегло посмотрел сайт.

Fox. Нет поддержки  высоких DPI. Свои реализации стандартных вещей. Не
понял пока как реализована расстановка виджетов в окне: упаковываются
как в Gtk  или по координатной сетке.

fltk. Нет поддержки  высоких DPI в стабильной версии. Древний C++. Нет
упаковки, размеры виджетов нужно задавать явно.

Elementary. Непонятно пока насчёт высокого DPI, OpenGL и упаковки.
Есть опасность, что может быть ориентирован на пальцетыкальные
интерфейсы (в истории успеха холодильники и т.п.).

Есть ли жизнь с десктопным GUI в 2021 году? Можно ли выбрать хоть
что-то, что не сломается через два года?

-- 
Celestia real-time space simulator:
 * https://celestia.space
 * https://github.com/CelestiaProject

Forum:
 * https://celestia.space/forum/

Re: Диски, raid, ZFS & GUI

[Tim Sattarov]

On 2020-11-04 12:09 p.m., Tim Sattarov wrote:
> Приветствую, Debian сообщество
>
> решил обновить железо на домашней файлопомойке/медиасервере.
> Памяти там 32 гига, не ECC, обычной.
> достаточно слотов для дисков и сейчас стоят четыре стареньких WDшки, в LVM 
> mirror конфигурации.
>

Отвечаю сам себе:

решил попробовать ZFS: вылезла проблема переноса нынешних данных.

Было: LVM из 4 дисков
Стало: 5 дисков в ZFS , raidz

Места в сервере на оба набора не хватит...я надеялся что перенесу все данные со 
старого массива на
новый диск (места хватает). Создам raidz на оставшихся 4-х дисках и потом 
перенесу всё на raidz и
добавлю 5-й диск в пул.
Тут я ошибся... добавить диск в raidz пул никак нельзя.
Есть ли какие нибудь другие пути? на крайний случай придётся переносить по сети 
с другого сервера...

Спасибо

Диски, raid, ZFS & GUI

[Tim Sattarov]

Приветствую, Debian сообщество

решил обновить железо на домашней файлопомойке/медиасервере.
Памяти там 32 гига, не ECC, обычной.
достаточно слотов для дисков и сейчас стоят четыре стареньких WDшки, в LVM 
mirror конфигурации.

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

Вариантов развития несколько:

1) Восстановить всё как было, просто обновив диски на поновее и побольше и не 
париться
2) Сделать софтовый raid5 и ext4/xfs/btrfs поверху
3) Поднять ZFS pool и разрулить всё на его уровне

Исходя из прошлых обсуждений в этой рассылке - тут есть специалисты по ZFS и 
вообще домашним
системам хранения.  Что посоветуете?

И ещё вдобавок к вышеизложенному: есть ли красивая вебморда для статуса дисков, 
управление не так
важно, минимальное требование - дашбоард с температурой, емкостью и прочими 
состояниями.

Спасибо
Тимур

Re: GUI для openvpn

[Victor Wagner]

On Thu, 1 Sep 2016 12:08:17 +0900
"Munko O. Bazarzhapov"  wrote:

> Ключи все можно внутри *.conf файлов держать, NetworkManager вроде бы
> остальное может, хоть я его и не люблю еще со времен его создания

Ну написано же - нужен инструмент для network-manager-free системы.
Который делает все полезное, что делает в этой области network manager,
не делает ничего вредного, и  не содержит компилируемого кода.

Кстати, насколькор я понял, тут одно из двух - либо ключи внутри *.conf
файлов, либо network manager, поскольку network manager пытается
импортировать предоставленный снаружи конфиг openvpen/

Кстати того, кто придумал что конфигурации opoenvpn-сетей должны в
дебиане иметь расширение .conf убил бы. У всех .ovpn,  а здесь .conf.
Поэтому тупо скопировать один и тот же конфиг на windows, android и
debian не получается, приходится думать, как в данной системе он должен
правильно называться.

> 
В
-- 
   Victor Wagner 

Re: GUI для openvpn

[Victor Wagner]

On Wed, 31 Aug 2016 22:40:53 +0300
Sergey Yakimchuck  wrote:

> Добрый день.
> NetworkManager такое умеет

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

Re: GUI для openvpn

[Munko O. Bazarzhapov]

Ключи все можно внутри *.conf файлов держать, NetworkManager вроде бы
остальное может, хоть я его и не люблю еще со времен его создания

Интересно, а есть что то подобное или еще лучше с веб мордой для управления
серверной частью для генерации ключей, их блокировке, сортировке, в общем
управлении всей этой кашей, IP адреса и т.д.

В интернетах нагуглил, но оно было с просьбой купить
https://openvpn.net/index.php/access-server/docs/admin-guides/admin-guides/218-how-to-activate-your-license-in-openvpn-access-server.html


Munko O. Bazarzhapov
JabberID: v...@aginskoe.ru
mail: vec...@gmail.com

1 сентября 2016 г., 4:40 пользователь Sergey Yakimchuck <ya...@yakim.org.ua>
написал:

> Добрый день.
> NetworkManager такое умеет
>
> С уважением,
> Якимчук Сергей
>
>
> On 31.08.16 21:43, Victor Wagner wrote:
>
>> Коллеги!
>>
>> Вот тут захотелось мне gui-утилиту для управления openvpn. Чтобы сидела
>> в tray-е и позволяла включать-выключать соединения (клиентские) с
>> разными серверами, у каждого сервера, естественно свой CA, запрашивала
>> в некоторых случаях пассфразу к секретному ключу или красивым диалогом
>> просила вставить криптографический токен, показывала состояние
>> соединения, и, при необходимости сообщения из лога.
>>
>> В общем более-менее полно реализовывала протоко, описанный в
>>
>> /usr/share/doc/openvpn/management-notes.txt.gz при минимальной
>> инвазивности интерфейса.
>>
>> Возможность править конфиги через GUI скорее вредна, чем полезна.
>> И еще хотелось бы чтобы для использвания этого добра не нужно было бы
>> править полученные от администратора openvpn-сервера конфиги. То есть
>> всякие необходимые --management* ключики передавались бы запускаемым
>> openvpn-ам через init-скрипт, запускающий их при старте системы.
>> (естественно, все это для systemd-free и network-manager-free среды.
>> wicd это такой network-manager-lite).
>>
>> Интересно, кто-нибудь под linux писал?
>>
>> То есть, понятно, что если не найду, можно вспомнить Tcl/Tk и написать
>> самому. Но вдруг есть готовое, требующее минимальной обработки
>> напильником
>>
>>
>

Re: GUI для openvpn

[Sergey Yakimchuck]

Добрый день.
NetworkManager такое умеет

С уважением,
Якимчук Сергей

On 31.08.16 21:43, Victor Wagner wrote:

Коллеги!

Вот тут захотелось мне gui-утилиту для управления openvpn. Чтобы сидела
в tray-е и позволяла включать-выключать соединения (клиентские) с
разными серверами, у каждого сервера, естественно свой CA, запрашивала
в некоторых случаях пассфразу к секретному ключу или красивым диалогом
просила вставить криптографический токен, показывала состояние
соединения, и, при необходимости сообщения из лога.

В общем более-менее полно реализовывала протоко, описанный в

/usr/share/doc/openvpn/management-notes.txt.gz при минимальной
инвазивности интерфейса.

Возможность править конфиги через GUI скорее вредна, чем полезна.
И еще хотелось бы чтобы для использвания этого добра не нужно было бы
править полученные от администратора openvpn-сервера конфиги. То есть
всякие необходимые --management* ключики передавались бы запускаемым
openvpn-ам через init-скрипт, запускающий их при старте системы.
(естественно, все это для systemd-free и network-manager-free среды.
wicd это такой network-manager-lite).

Интересно, кто-нибудь под linux писал?

То есть, понятно, что если не найду, можно вспомнить Tcl/Tk и написать
самому. Но вдруг есть готовое, требующее минимальной обработки
напильником

GUI для openvpn

[Victor Wagner]

Коллеги!

Вот тут захотелось мне gui-утилиту для управления openvpn. Чтобы сидела
в tray-е и позволяла включать-выключать соединения (клиентские) с
разными серверами, у каждого сервера, естественно свой CA, запрашивала
в некоторых случаях пассфразу к секретному ключу или красивым диалогом
просила вставить криптографический токен, показывала состояние
соединения, и, при необходимости сообщения из лога.

В общем более-менее полно реализовывала протоко, описанный в 

/usr/share/doc/openvpn/management-notes.txt.gz при минимальной
инвазивности интерфейса.

Возможность править конфиги через GUI скорее вредна, чем полезна.
И еще хотелось бы чтобы для использвания этого добра не нужно было бы
править полученные от администратора openvpn-сервера конфиги. То есть
всякие необходимые --management* ключики передавались бы запускаемым
openvpn-ам через init-скрипт, запускающий их при старте системы.
(естественно, все это для systemd-free и network-manager-free среды.
wicd это такой network-manager-lite).

Интересно, кто-нибудь под linux писал?

То есть, понятно, что если не найду, можно вспомнить Tcl/Tk и написать
самому. Но вдруг есть готовое, требующее минимальной обработки
напильником

-- 
   Victor Wagner <vi...@wagner.pp.ru>

Отчего gksu не открывает gui программу от другого пользователя, а kdesudo открывает?

[DimAnt10]

Здравствуйте!

Никто не знает, почему gksu не отрывает gui программу от другого 
пользователя ("Не удалось открыть дисплей:"), а kdesudo открывает? Может 
донастроить чего надо?

Re: Отчего gksu не открывает gui программу от другого пользователя, а kdesudo открывает?

[Andrey Melnikoff]

DimAnt10 <diman...@mail.ru> wrote:
> Здравствуйте!

> Никто не знает, почему gksu не отрывает gui программу от другого 
> пользователя ("Не удалось открыть дисплей:"), а kdesudo открывает? Может 
> донастроить чего надо?
gksu похоже давно сломали везде с пеерездом на gnome3 и systemd. Попробуй gksudo

Re: Отчего gksu не открывает gui программу от другого пользователя, а kdesudo открывает?

[DimAnt10]

Выдает в числе прочего "Не удалось открыть дисплей:". gksudo точно так 
же реагирует, хоть там в gui и предусмотрен запуск от другого пользователя.


31.08.2015 10:53, Anatoly Pugachev пишет:
Если запустить gksu из xterm (или другого текстового терминала, 
konsole, gnome-terminal), показывает ли какие-нибудь ошибки?


2015-08-31 10:24 GMT+03:00 DimAnt10 <diman...@mail.ru 
<mailto:diman...@mail.ru>>:


Здравствуйте!

Никто не знает, почему gksu не отрывает gui программу от другого
пользователя ("Не удалось открыть дисплей:"), а kdesudo открывает?
Может донастроить чего надо?

Re: Отчего gksu не открывает gui программу от другого пользователя, а kdesudo открывает?

[Anatoly Pugachev]

Если запустить gksu из xterm (или другого текстового терминала, konsole,
gnome-terminal), показывает ли какие-нибудь ошибки?

2015-08-31 10:24 GMT+03:00 DimAnt10 <diman...@mail.ru>:

> Здравствуйте!
>
> Никто не знает, почему gksu не отрывает gui программу от другого
> пользователя ("Не удалось открыть дисплей:"), а kdesudo открывает? Может
> донастроить чего надо?
>
>

Re: Отчего gksu не открывает gui программу от другого пользователя, а kdesudo открывает?

[Илья]

Пробавали в  /etc/sudoers  добавить строку
Defaults env_keep=DISPLAY


On 08/31/2015 10:24 AM, DimAnt10 wrote:

Здравствуйте!

Никто не знает, почему gksu не отрывает gui программу от другого 
пользователя ("Не удалось открыть дисплей:"), а kdesudo открывает? 
Может донастроить чего надо?

xrandr roaming + GUI

[Alexander Gerasiov]

Коллеги, здравствуйте.

Сейчас очень у многих ноутбуки, которые переносятся с места на место, к
ним подключаются мониторы, прокторы и т.п.
При чем, возможны разные конфигурации: клонирование, два, три монитора 
расположенных по разному (справа, слева и т.д.). 

Получается этакий роаминг между разными физическими точками.

Для управления этим в иксах есть randr и консольный интерфейс xrandr. В 
разных DE есть конфигурялки, но они не умеют (я не видел) позволять 
задавать несколько predefined конфигураций и легко выбирать между ними.

А еще лучше автоопределять конфигурации по набору подключенных
мониторов. А еще, помимо разрешений, хочется управлять dpi и
хинтингом опять же автоматом, в зависимости от конфигурации. А еще
некоторые действия вообще можно делать автоматом, заметив изменение
конфигурации (отключение/подключение монитора).

По крайней мере я что-то подобное для себя делаю, но для решения такой
задачи на каждом новом ноутбуке вынужден писать набор скриптов над
xrandrco и потом допиливать их под новые сочетания мониторов. Как-то
это костыльно. Вчера вот пришел на лекцию, подключился к проектору, а
он какой-то не совсем адекватный (разрешения у него странные и xrandr
несколько переклинивает при попытке включить нужный режим). В итоге я
минуты три возился с командной строкой в мучительных попытках заставить
эту дуру взлететь - выглядело не солидно =)

Например, у меня сейчас три наиболее часто используемых конфигурации:
1.Ноут с фулл-хд
2.Ноут с фулл-хд и проектором в режиме экрана справа (на который идёт
окно презентации, а на ноуте основной рабочий стол)
3.Два монитора 4:3 как два экрана (один справа, другой слева), тот что
слева дублируется на экран ноутбука, при этом ноутбук переключается в
разрешение монитора (для того, чтобы сам ноутбук держать закрытым, но в
случае, если ноут уснет, а проснется без мониторов, основной рабочий
стол был доступен на экране ноутбука без проблем.)

Помимо этого иногда бывают какие-то другие конфигурации, типа
подключить телевизор и склонировать на него основной экран и т.п.


Внимание вопрос: всё действительно печально и нормальных инструментов
для решения задачи нету?

Просто мне это как-то надоело и я уже подумываю сам написать такую
штуку с нардами и гуриями.

-- 
Александр.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422112710.4caa4...@brick.gerasiov.net

Re: xrandr roaming + GUI

[Руслан Коротаев]

В сообщении от [Ср 2015-04-22 11:27 +0300]
Alexander Gerasiov g...@cs.msu.su пишет:
 Сейчас очень у многих ноутбуки, которые переносятся с места на место, к
 ним подключаются мониторы, прокторы и т.п.
 При чем, возможны разные конфигурации: клонирование, два, три монитора 
 расположенных по разному (справа, слева и т.д.). 
 
 Получается этакий роаминг между разными физическими точками.
 
 Для управления этим в иксах есть randr и консольный интерфейс xrandr. В 
 разных DE есть конфигурялки, но они не умеют (я не видел) позволять 
 задавать несколько predefined конфигураций и легко выбирать между ними.
 
 А еще лучше автоопределять конфигурации по набору подключенных
 мониторов. А еще, помимо разрешений, хочется управлять dpi и
 хинтингом опять же автоматом, в зависимости от конфигурации. А еще
 некоторые действия вообще можно делать автоматом, заметив изменение
 конфигурации (отключение/подключение монитора).

У меня тоже была такая проблема с подключением мониторов и проекторов.
Всё решилось переходом на тайловый оконный менеджер xmonad [1], он с
помощью xinerama может автоматически подключать и управлять тремя
мониторами, горячие клавиши для этого предусмотрены их функциональности
хватает для большинства случаев.

Отказываться от своего любимого DE/WM не обязательно, можно просто
добавить xmonad как еще одно окружение в логин-менеджере (типа slim [2])
и грузить его по мере необходимости.

[1] http://xmonad.org/
[2] https://wiki.archlinux.org/index.php/SLiM_(Русский)

-- 
http://google.com/+РусланКоротаев


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422105825.GA1523@debian

Re: xrandr roaming + GUI

[Alexander Gerasiov]

Hello Руслан,

On Wed, 22 Apr 2015 15:58:25 +0500
Руслан Коротаев korot...@ufamail.ru wrote:

 У меня тоже была такая проблема с подключением мониторов и проекторов.
 Всё решилось переходом на тайловый оконный менеджер xmonad [1], он с
 помощью xinerama может автоматически подключать и управлять тремя
 мониторами, горячие клавиши для этого предусмотрены их
 функциональности хватает для большинства случаев.
xinerama - не true, нужен randr, чтобы отдельные скрины и всё такое.
Сейчас много софта на это завязано, например
libreoffice-presenter-console

 Отказываться от своего любимого DE/WM не обязательно, можно просто
 добавить xmonad как еще одно окружение в логин-менеджере (типа slim
 [2]) и грузить его по мере необходимости.
То есть таки отказаться от любимого DE. =)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422143651.719c2...@brick.gerasiov.net

Re: xrandr roaming + GUI

[Alexander Gerasiov]

Hello Alexander,

On Wed, 22 Apr 2015 11:49:38 +0300
Alexander Gerasiov g...@cs.msu.su wrote:

 И всё это вместо того, чтобы открыть дроп-даун список режимов, выбрать
 один, второй, третий и чух-чух-чух, поезд отправляется.
btw, вообще для задачи открыть список экранов и выбрать конфигурацию
на сейчас неплохо подходит lxrandr, но в нем нет как раз функции
роаминга между набором любимых конфигураций.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422121049.26a67...@brick.gerasiov.net

Re: xrandr roaming + GUI

[Hleb Valoshka]

On 4/22/15, Alexander Gerasiov g...@cs.msu.su wrote:
...
 Внимание вопрос: всё действительно печально и нормальных инструментов
 для решения задачи нету?

Не уверен, что arandr умеет всё, что вам нужно. Но он умеет
генерировать нужную команду для xrandr, которую потом можно как-то
запускать. В репозитории есть.

Re: xrandr roaming + GUI

[Рустам Гимадиев]

Я использовал 
https://sites.google.com/site/akohlmey/random-hacks/xrandr-chooser-with-presets 
в качестве готового решения, но перестал (не так часто в итоге настройки 
менялись)
-- 
С уважением,
 Рустам Гимадиев


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3030131429691...@web4o.yandex.ru

Re: xrandr roaming + GUI

[Alexander Gerasiov]

Hello Рустам,

On Wed, 22 Apr 2015 11:33:19 +0300
Рустам Гимадиев gimadiev@yandex.ru wrote:

 Я использовал
 https://sites.google.com/site/akohlmey/random-hacks/xrandr-chooser-with-presets
 в качестве готового решения, но перестал (не так часто в итоге
 настройки менялись) 

Ну это пример как раз наколеночного скрипта, просто обернутый в
wish/tcl для примитивного гуя.
У меня то же самое, только на шелле (вызывается хоткеем: ACPI кнопка,
закрытие крышки ноута и т.п.), дополнительно управляет xft и
содержит немножко интеллекта для определения того, к каким выходам
сейчас вообще хоть что-то подключено.

Основная проблема, что там всё довольно-таки захардкожено, и, если
вдруг, у тебя новая конфигурация (подключился к проектору, а он первым
разрешением предлагает 640х480, на максимальном разрешении не работает,
а рабочее в списке xrandr где-то в середине), то чтобы заставить ее
работать, приходится несколько минут сидеть в консоли, перебирая
варианты. А там еще в процессе перебора иногда слетает положение
screen'ов относительно друг-друга и на проектор выводится половина
экрана презентация, а другая половина главный рабочий стол, приходится
опять лезть в выдачу xrandr, искать там смещения, пытаться их править...

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

-- 
Александр.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422114938.5607b...@brick.gerasiov.net

Re: xrandr roaming + GUI

[Alexander Gerasiov]

Hello Hleb,

On Wed, 22 Apr 2015 12:11:49 +0300
Hleb Valoshka 375...@gmail.com wrote:

 On 4/22/15, Alexander Gerasiov g...@cs.msu.su wrote:
 ...
  Внимание вопрос: всё действительно печально и нормальных
  инструментов для решения задачи нету?
 
 Не уверен, что arandr умеет всё, что вам нужно. Но он умеет
 генерировать нужную команду для xrandr, которую потом можно как-то
 запускать. В репозитории есть.
Это надстройка для конфигурирования, а не роаминг-агент. То есть решает
примерно полторы задачи из трёх =)

Вообще на сайте у него есть несколько ссылок на альтернативы
http://christian.amsuess.com/tools/arandr/

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422123123.41eab...@brick.gerasiov.net

GUI

[Ivan Shmakov]

 Q  qh...@rambler.ru writes:
 On Friday 03 August 2012 17:35:36 Artem Chuprina wrote:

[Похоже, вновь завел поля^Wподписчиков в дремучий OT.]

  Как только интерфейс начнет показывать шпации, так он сразу станет
  не WYSIWYG.  Потому что на бумаге шпацию как объект, натурально, не
  видно.

  А в ветке, как и в исходном сообщении, речь о GUI, а не WYSIWYG.
  Который не обязан быть единственным видом GUI в программе.

Я прочитал [1] как «не стоит писать тексты тем, кому для этого
/необходим/ GUI.»  Не /полезен/, а именно /необходим./

[1] news:20120803080822.ga21...@wagner.pp.ru

  Как раз что набираете — видите.  Вы не видите, как это будет
  выглядеть.  Но обычно при наборе формулы важно, правильная она или
  нет, а как она будет выглядеть — пусть этим займется автоматика,
  Кнут эту задачу уже решил.

  Нет, я не вижу, я читаю.  Для опытного пользователя этого достаточно.
  Для новичка — нет.  Особенно если этот новичок занимается
  самообразованием.

Если новичек планирует дообразовываться до опытного пользователя
— все одно привыкать придется.

  Программисты довольно давно пользуются для этой цели отступами.  В
  коде.  Помогает.  Пользуются, надо сказать, много дольше, нежели
  существуют языки, которые этот самый отступ интерпретируют.

  У программистов выбора нет.  Либо программировать мышкой формочки и
  терпеть ограничения данного способа, либо пытаться с помощью текста
  хоть как-то описать решение задачи.  Графического вида программ типа
  математических формул, нотной записи, чертежей или принципиальных
  схем, у них просто нет.

Algorithm Builder [2], G (который в LabVIEW)…?

[2] http://algrom.net/

  Даже связи между компонентами программы приходится в голове держать.

Приходится.  И не только программистам.  И совершенно себе не
представляю, как этого можно было бы избежать.

  А как оно будет выглядеть — это даже emacs может показать на лету.
  При том, что набирать Вы будете исходник.

  При том, что набирать мне _придётся_ исходник.  Что-то позабыл, или
  просто, с конструкцией не встречался — и всё, в документацию.
  Которая тоже большей частью текстовая и справочного вида.

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

  И подозреваю, что видимая формула в емаксе — картинка.

Подтверждаю.

Строго говоря, любое изображение на современном дисплее —
картинка.  Причем растровая.

  Что-таки ограничивает возможности по представлению данных.

?

-- 
FSF associate member #7257  http://sf-day.org/


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86wr1goru2.fsf...@gray.siamics.net

Re: GUI

[Q]

On Friday 03 August 2012 20:36:37 Ivan Shmakov wrote:
   Я прочитал [1] как «не стоит писать тексты тем, кому для этого
   /необходим/ GUI.»  Не /полезен/, а именно /необходим./

А чем особенно отличаются эти люди, разве что кому полезен более опытные?


   Если новичек планирует дообразовываться до опытного пользователя
   — все одно привыкать придется.

Не придётся. Привыкнет автоматически. С опытом. А вот кривая обучения разная.


   Algorithm Builder [2], G (который в LabVIEW)…?

 [2] http://algrom.net/

А где графика-то? Текст на графе. Убрать текст, и всё станет непонятно. 


   Приходится.  И не только программистам.  И совершенно себе не
   представляю, как этого можно было бы избежать.

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


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

Я говорю хотя бы про греческие буквы и вещи типа разных видов интегралов. 


   Что-таки ограничивает возможности по представлению данных.

   ?

Скажем, редактировать картинку как формулу нельзя. Ткнуть в картинку для 
переходя в нужное место редактирования. Ну и т. д.

Re: GUI

[Иван Лох]

On Fri, Aug 03, 2012 at 09:15:05PM +0400, Q wrote:
 
 Скажем, редактировать картинку как формулу нельзя. Ткнуть в картинку для 
 переходя в нужное место редактирования. Ну и т. д.

Так можно. 

 

-- 
С коммунистическим приветом,
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120803171606.gi4...@nano.ioffe.rssi.ru

Re: GUI

[Q]

On Friday 03 August 2012 21:16:06 Иван Лох wrote:
 On Fri, Aug 03, 2012 at 09:15:05PM +0400, Q wrote:
  Скажем, редактировать картинку как формулу нельзя. Ткнуть в картинку для
  переходя в нужное место редактирования. Ну и т. д.

 Так можно.

Навигация по картинке?

 --
 С коммунистическим приветом,
 Иван Лох

Re: GUI

[Иван Лох]

On Fri, Aug 03, 2012 at 09:36:26PM +0400, Q wrote:
 On Friday 03 August 2012 21:16:06 Иван Лох wrote:
  On Fri, Aug 03, 2012 at 09:15:05PM +0400, Q wrote:
   Скажем, редактировать картинку как формулу нельзя. Ткнуть в картинку для
   переходя в нужное место редактирования. Ну и т. д.
 
  Так можно.
 
 Навигация по картинке?

Там есть специальные метки. Технология reverse search, называется.

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120803182529.gj4...@nano.ioffe.rssi.ru

Re: GUI

[Q]

On Friday 03 August 2012 22:25:29 Иван Лох wrote:


 Там есть специальные метки. Технология reverse search, называется.

 --
 Иван Лох


Спасибо за информацию.

Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)

[Michael Shigorin]

On Sun, May 20, 2012 at 09:57:14PM +0100, Mikhail Ramendik wrote:
 Лучше всего было бы сделать команду, которая отменяет все задания
 и снимает все паузы. И повесить её на пункт меню icewm.
 Есть ли такая команда?

Возможно, пригодится вот эта поделка, которую когда-то сделал:
http://fly.osdn.org.ua/~mike/packages/lprestart/

CUPS стоит проинструктировать, что ErrorPolicy есть abort-job.

-- 
  WBR, Michael Shigorin m...@altlinux.ru
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120525204020.gb31...@osdn.org.ua

Re: CLI vs. GUI

[Artem Chuprina]

Артём Н. - debian-russian@lists.debian.org  @ Tue, 22 May 2012 22:48:11 +0400:

  Так что писать на коленке презентацию, которая будет
  выведена плюс-минус так, как ты ее видишь, еще можно (и то
  не всегда нужно - видел я подобные поползновения печатать
  объявления в ворде...), а HTML - уже ни в коем разе.
 АН Как-раз для HTML, GUI необходим. Если, конечно, вы не
 АН рассчитываете на то, что все ваши пользователи используют
 АН lynx, links, w3m или подобное.

Доктор, это ничего, что у меня есть информативный сайт, все HTML
которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
- информативный. 
   АН Вообще-то, это частный случай, когда требуется преимущественно
   АН подсветка HTML и CSS. С чем VIM неплохо справляется.
  
  Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
  файле, отчего все еще проще.
 АН Правильный редактор не должен рассчитывать на то, что всё будет по
 АН уму, к тому же, иногда надо смешивать CSS и HTML.

Правильный _для меня_ - имеет право на это рассчитывать.  Более того,
ему рекомендуется так делать.  Типа если он не справляется с подсветкой,
значит, я фигню порю.  emacs вполне успешно справляется с задачей ловли
меня за руку.

Смешивать CSS и HTML иногда надо.  Но если это приходится делать до
такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
Что и наблюдается в случае HTML из-под винворда :-)

  Суть, собственно, в том, что vim и emacs - это TUI, а не GUI.  Хотя
  emacs даже умеет показывать картинки.  Лучше б не умел...
  
А если мне нужно интерактивное веб-приложение, то
там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
ручное редактирование.
   АН Хм... Haml - любопытно.
  
  Угу.  Технология создания веб-приложений сводится к тому, что дизайнер
  делает дизайн, HTML-верстальщик (это совершенно другой человек)
  превращает его в HTML, CSS и набор картинок, а программист превращает
  эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
  которые динамически заполняются данными.  Гуй для HTML при этом может
  использоваться в принципе только на втором этапе, но тем верстальщикам,
  кто пытается его там использовать, быстро отрывают руки.  Ну, или
  результат получается, мягко говоря, неюзабельным для пользователя.
 АН Хм. Что, вы хотите сказать, что во всех компаниях, которые
 АН занимаются созданием WEB-данных (документов или приложений и т.п.)
 АН и могут позволить себе иметь дизайнера, не имеющего представления о
 АН вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда
 АН работают без GUI?  Кстати, а дизайнер тоже обязательно, либо не
 АН использует компьютер, либо работает без GUI? :-) Или, всё-таки, на
 АН первом этапе тоже есть GUI, только совершенно отличный от GUI
 АН верстальщика?

К слову, в большинстве контор, занимающихся созданием веб-приложений,
своего дизайнера вообще нет.  Аутсорсят.  Дизайнер не работает с HTML,
поэтому ему гуй для (читаем внимательно!) HTML не нужен.

Верстальщик тоже работает с гуем - но не для создания HTML, а для
нарезки того, что сделал дизайнер, и для извлечения оттуда информации о
цветах :-)

 АН Кстати, а операторам на станциях например, GUI тоже не требуется?
 АН :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно
 АН пытаетесь доказать, что GUI - всегда плохо)?

Почему-то вы упорно вычитываете в моих словах то, что там не написано.

Как это выглядит, нужно смотреть в браузере и только в браузере.
Желательно не в одном.
   АН Как это выглядит и работает нужно проверять в браузере. Обязательно
   АН не в одном, как говорят. По крайней мере, в наиболее популярных
   АН (или в тех, на которых это будет работать, если это нечто
   АН специфическое). И, затем ещё вносить корректировки для конкретных
   АН экземпляров. :-|
  
  Тонкость в том, что если у тебя есть информация, то можно написать
  достаточно простой HTML для того, чтобы проверять его нужно было
  максимум в одном.  Тому, кому есть, что сказать, дизайнерские изыски
  обычно не шибко нужны.
 АН Просто выглядящий и преподносящий информацию в удобочитаемом виде
 АН или просто устроенный? :-)

Все три.  Первые два вообще очень тесно коррелируют - чем проще выглядит
HTML, тем информация в нем удобочитаемее.

Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
реальным видом документа.  А что этот гуй выдает в код, и какой ужас
потом в браузере...  Это - практика.
   АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор
   АН имеет представление о том, что существуют разные средства вывода
   АН (и, если уж быть точным, не обязательно визуальные).
  
  Наличие гуя провоцирует не иметь такого представления.
 АН Это, как наличие пистолета провоцирует с кем-то разобраться...
 АН Уменьшает порог вхождения.
 АН Но человек во вменяемом состоянии, вряд ли побежит разбираться с
 АН кем-то лишь потому, что у него в кармане оружие.

Аналогии лгут.

А JS длиннее одного

Re: CLI vs. GUI

[Иван Лох]

On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote:
 Смешивать CSS и HTML иногда надо.  Но если это приходится делать до
 такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
 Что и наблюдается в случае HTML из-под винворда :-)
   Это второй вопрос.  Но программа на JS, если она используется, должна
   быть в отдельном файле, а не включена в тот же HTML.
  АН Когда как...
 
 Ни одного контрпримера не попадалось.

Проблема в том, что Билл Гейц и Ко сумели творчески переработать  принцип:
Все есть файл в Нечто есть _один_ файл. Как следствие, появилось
поколение калек, для которых мысль о необходимости копирования _нескольких_
файлов для того чтобы разместить страницу, кажется странной.

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

Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции 
растра в SVG. Добились, кстати. А любимый, некоторыми, fb2?

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523100209.ga12...@nano.ioffe.rssi.ru

Re: CLI vs. GUI

[Артём Н.]

23.05.2012 14:02, Иван Лох пишет:
 On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote:
 Смешивать CSS и HTML иногда надо.  Но если это приходится делать до
 такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
 Что и наблюдается в случае HTML из-под винворда :-)
   Это второй вопрос.  Но программа на JS, если она используется, должна
   быть в отдельном файле, а не включена в тот же HTML.
  АН Когда как...

 Ни одного контрпримера не попадалось.
 
 Проблема в том, что Билл Гейц и Ко сумели творчески переработать  принцип:
 Все есть файл в Нечто есть _один_ файл. Как следствие, появилось
 поколение калек, для которых мысль о необходимости копирования _нескольких_
 файлов для того чтобы разместить страницу, кажется странной.
 
 Как следствие, какой-нибудь, опенофис вместо того чтобы создать каталог с
 читаемыми файлами создает архив, а, говорят, может и одну xml-простыню
 родить.
 
 Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции 
 растра в SVG. Добились, кстати. А любимый, некоторыми, fb2?
Ну, не всё так сурово. Я про более частный случай. Кстати, тесно связанный с 
MS. :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fbcf44e.8060...@yandex.ru

Re: CLI vs. GUI

[Артём Н.]

23.05.2012 10:10, Artem Chuprina пишет:
 Артём Н. - debian-russian@lists.debian.org  @ Tue, 22 May 2012 22:48:11 
 +0400:
 
   Так что писать на коленке презентацию, которая будет
   выведена плюс-минус так, как ты ее видишь, еще можно (и то
   не всегда нужно - видел я подобные поползновения печатать
   объявления в ворде...), а HTML - уже ни в коем разе.
  АН Как-раз для HTML, GUI необходим. Если, конечно, вы не
  АН рассчитываете на то, что все ваши пользователи используют
  АН lynx, links, w3m или подобное.
 
 Доктор, это ничего, что у меня есть информативный сайт, все HTML
 которого написаны вручную, старые в vim, новые в emacs?  Ключевое 
 слово
 - информативный. 
АН Вообще-то, это частный случай, когда требуется преимущественно
АН подсветка HTML и CSS. С чем VIM неплохо справляется.
   
   Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
   файле, отчего все еще проще.
  АН Правильный редактор не должен рассчитывать на то, что всё будет по
  АН уму, к тому же, иногда надо смешивать CSS и HTML.
 
 Правильный _для меня_ - имеет право на это рассчитывать.  Более того,
 ему рекомендуется так делать.  Типа если он не справляется с подсветкой,
 значит, я фигню порю.  emacs вполне успешно справляется с задачей ловли
 меня за руку.
А вы будете в своём правильном редакторе просматривать исключительно
правильный код? :-) Или что-то чужое иногда приходится читать? Да и неплохо бы
дать пользователю _выбирать_, что для него правильно...

 Смешивать CSS и HTML иногда надо.  Но если это приходится делать до
 такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
 Что и наблюдается в случае HTML из-под винворда :-)
Не обязательно (именно про подсветку в CSS, даже когда он в отдельном файле).
Синтаксическая подсветка позволит визуально выделить элементы (я не про помойку
CSS+HTML, а про выделение элементов в самом CSS). Меньше придётся напрягаться,
например, при визуальном поиске (в глаза сразу бросаются имена атрибутов,
например, в полотне параметров и своих классов).
Меньше усталость, комфортнее работать. Я не прав?

   Суть, собственно, в том, что vim и emacs - это TUI, а не GUI.  Хотя
   emacs даже умеет показывать картинки.  Лучше б не умел...
   
 А если мне нужно интерактивное веб-приложение, то
 там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
 ручное редактирование.
АН Хм... Haml - любопытно.
   
   Угу.  Технология создания веб-приложений сводится к тому, что дизайнер
   делает дизайн, HTML-верстальщик (это совершенно другой человек)
   превращает его в HTML, CSS и набор картинок, а программист превращает
   эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
   которые динамически заполняются данными.  Гуй для HTML при этом может
   использоваться в принципе только на втором этапе, но тем верстальщикам,
   кто пытается его там использовать, быстро отрывают руки.  Ну, или
   результат получается, мягко говоря, неюзабельным для пользователя.
  АН Хм. Что, вы хотите сказать, что во всех компаниях, которые
  АН занимаются созданием WEB-данных (документов или приложений и т.п.)
  АН и могут позволить себе иметь дизайнера, не имеющего представления о
  АН вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда
  АН работают без GUI?  Кстати, а дизайнер тоже обязательно, либо не
  АН использует компьютер, либо работает без GUI? :-) Или, всё-таки, на
  АН первом этапе тоже есть GUI, только совершенно отличный от GUI
  АН верстальщика?
 
 К слову, в большинстве контор, занимающихся созданием веб-приложений,
 своего дизайнера вообще нет.  Аутсорсят.  Дизайнер не работает с HTML,
 поэтому ему гуй для (читаем внимательно!) HTML не нужен.
 Верстальщик тоже работает с гуем - но не для создания HTML, а для
 нарезки того, что сделал дизайнер, и для извлечения оттуда информации о
 цветах :-)
Ну, я про это и говорю (читаем внимательно в предыдущем сообщении): раздельный
ГУЙ. Но дизайнер тоже работает с гуём...

  АН Кстати, а операторам на станциях например, GUI тоже не требуется?
  АН :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно
  АН пытаетесь доказать, что GUI - всегда плохо)?
 Почему-то вы упорно вычитываете в моих словах то, что там не написано.
Ну, потому что мне кажется, что вы упорно доказываете то, что я там вычитываю. 
:-)

 Как это выглядит, нужно смотреть в браузере и только в браузере.
 Желательно не в одном.
АН Как это выглядит и работает нужно проверять в браузере. Обязательно
АН не в одном, как говорят. По крайней мере, в наиболее популярных
АН (или в тех, на которых это будет работать, если это нечто
АН специфическое). И, затем ещё вносить корректировки для конкретных
АН экземпляров. :-|
   
   Тонкость в том, что если у тебя есть информация, то можно написать
   достаточно простой HTML для того, чтобы проверять его нужно было
   максимум в одном.  Тому, кому есть, что сказать, дизайнерские изыски
   обычно не

Re: CLI vs. GUI

[Иван Лох]

On Wed, May 23, 2012 at 06:43:38PM +0400, Артём Н. wrote:
 Главная страница может использовать общий стиль. Но у неё есть некоторые
 особенности. Зачем для неё выносить CSS в отдельный файл (читайте отдельный

Ну и ввести набор классов специально для особенностей главной страницы.

 запрос), если он больше нигде не дублируется?
 IE поддерживает условные комментарии (aka костыли), которые приходится 
 применять

Это уже треш какой-то

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523163650.gb12...@nano.ioffe.rssi.ru

Re: CLI vs. GUI

[Артём Н.]

20.05.2012 23:31, Artem Chuprina пишет:
 Артём Н. - debian-russian@lists.debian.org  @ Sun, 20 May 2012 21:56:09 
 +0400:
 
 Так что писать на коленке презентацию, которая будет выведена 
 плюс-минус
 так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
 подобные поползновения печатать объявления в ворде...), а HTML - уже 
 ни
 в коем разе.
АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
АН на то, что все ваши пользователи используют lynx, links, w3m или
АН подобное.
   
   Доктор, это ничего, что у меня есть информативный сайт, все HTML
   которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
   - информативный. 
  АН Вообще-то, это частный случай, когда требуется преимущественно
  АН подсветка HTML и CSS. С чем VIM неплохо справляется.
 
 Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
 файле, отчего все еще проще.
Правильный редактор не должен рассчитывать на то, что всё будет по уму, к тому
же, иногда надо смешивать CSS и HTML.

 Суть, собственно, в том, что vim и emacs - это TUI, а не GUI.  Хотя
 emacs даже умеет показывать картинки.  Лучше б не умел...
 
   А если мне нужно интерактивное веб-приложение, то
   там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
   ручное редактирование.
  АН Хм... Haml - любопытно.
 
 Угу.  Технология создания веб-приложений сводится к тому, что дизайнер
 делает дизайн, HTML-верстальщик (это совершенно другой человек)
 превращает его в HTML, CSS и набор картинок, а программист превращает
 эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
 которые динамически заполняются данными.  Гуй для HTML при этом может
 использоваться в принципе только на втором этапе, но тем верстальщикам,
 кто пытается его там использовать, быстро отрывают руки.  Ну, или
 результат получается, мягко говоря, неюзабельным для пользователя.
Хм. Что, вы хотите сказать, что во всех компаниях, которые занимаются созданием
WEB-данных (документов или приложений и т.п.) и могут позволить себе иметь
дизайнера, не имеющего представления о вёрстке и ей не занимающегося,
верстальщика и прочих, вторые всегда работают без GUI?
Кстати, а дизайнер тоже обязательно, либо не использует компьютер, либо работает
без GUI? :-)
Или, всё-таки, на первом этапе тоже есть GUI, только совершенно отличный от GUI
верстальщика?

Кстати, а операторам на станциях например, GUI тоже не требуется? :-)
Или, всё-таки, он иногда нужен (почему-то вы та упорно пытаетесь доказать, что
GUI - всегда плохо)?

   Как это выглядит, нужно смотреть в браузере и только в браузере.
   Желательно не в одном.
  АН Как это выглядит и работает нужно проверять в браузере. Обязательно
  АН не в одном, как говорят. По крайней мере, в наиболее популярных
  АН (или в тех, на которых это будет работать, если это нечто
  АН специфическое). И, затем ещё вносить корректировки для конкретных
  АН экземпляров. :-|
 
 Тонкость в том, что если у тебя есть информация, то можно написать
 достаточно простой HTML для того, чтобы проверять его нужно было
 максимум в одном.  Тому, кому есть, что сказать, дизайнерские изыски
 обычно не шибко нужны.
Просто выглядящий и преподносящий информацию в удобочитаемом виде или просто
устроенный? :-)

   Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
   реальным видом документа.  А что этот гуй выдает в код, и какой ужас
   потом в браузере...  Это - практика.
  АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор
  АН имеет представление о том, что существуют разные средства вывода
  АН (и, если уж быть точным, не обязательно визуальные).
 
 Наличие гуя провоцирует не иметь такого представления.
Это, как наличие пистолета провоцирует с кем-то разобраться...
Уменьшает порог вхождения.
Но человек во вменяемом состоянии, вряд ли побежит разбираться с кем-то лишь
потому, что у него в кармане оружие.

   А JS длиннее одного вызова функции в script в ручную написанном HTML -
   это признак того, что у автора слишком много свободного времени, и ему
   нечем это время занять, кроме как вычисткой потом глюков из результата.
  АН Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один
  АН внешний JS, который включает объект её реализующий? Про много
  АН свободного времени - это вы объясните авторам всяких там гуглов и
  АН ещё 100500 сервисов, которые этим JS буквально пронизаны (местами
  АН это даже удобно и, бывает, работает).
 Это второй вопрос.  Но программа на JS, если она используется, должна
 быть в отдельном файле, а не включена в тот же HTML.
Когда как...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fbbdf6b.8090...@yandex.ru

Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)

[Иван Лох]

On Mon, May 21, 2012 at 07:57:27AM +0400, Artem Chuprina wrote:
 Mikhail Ramendik - Debian-russian List  @ Sun, 20 May 2012 21:57:14 +0100:
 
  MR Лучше всего было бы сделать команду, которая отменяет все задания и
  MR снимает все паузы. И повесить её на пункт меню icewm.
 
  MR Есть ли такая команда?
 
 Есть.  Только у меня сейчас не стоит cups, и я не могу сказать, какая
 именно.  Подозреваю, что на самом деле это две команды - lp и cancel.

Я не очень понимаю, что такое паузы... Для принтера по-умолчанию 

cancel -a
cupsenable 
cupsaccept

 Ну, скрипт на три строки по вкусу.

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521054408.ga29...@nano.ioffe.rssi.ru

Re: CLI vs. GUI

[Artem Chuprina]

Maksym Tiurin - debian-russian@lists.debian.org  @ Mon, 21 May 2012 08:38:35 
+0300:

Меню организуют структуру команд и
позволяют быстро найти нужную (они не заменяют горячих клавиш), без
использования справки...
 
   MT Представил себе меню emacs со всеми командами.
   MT Ужаснулся. Быстро там найти явно ниче нельзя будет.
 
  Да ладно!  Я иногда включаю menu-bar-mode, когда не помню комбинацию
  клавиш для операции.  И успешно там нахожу.

 MT Все? В меняю всех никогда ИМХО не было. Например режимы для работы с
 MT Version Control Systems очень куцо в меню представлены.

Может быть.  Но это недостаток данного меню, а не возможностей меню
вообще.  У gnus очень развесистые меню, и в них при этом неплохо ищется.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obpi9hn7@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Artem Chuprina]

Артём Н. - debian-russian@lists.debian.org  @ Fri, 18 May 2012 12:07:00 +0400:

Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
понимать что с ним будет происходить при некоторых изменениях (например
при переформатировании на другую ширину) и быть уверенными что от этого
смысл не потеряется.
   АН И, всё-таки, GUI... :-)
  
  Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
  человеческой психики, ничего личного.
  
  Так что писать на коленке презентацию, которая будет выведена плюс-минус
  так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
  подобные поползновения печатать объявления в ворде...), а HTML - уже ни
  в коем разе.
 АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
 АН на то, что все ваши пользователи используют lynx, links, w3m или
 АН подобное.

Доктор, это ничего, что у меня есть информативный сайт, все HTML
которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
- информативный.  А если мне нужно интерактивное веб-приложение, то
там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
ручное редактирование.

 АН К тому же, для написания кода необходим нормальный интерфейс (ну, 
используя cat
 АН или echo, тоже возможно кое-что написать, но идея плохая (как крайний 
случай)).
 АН Если вы будете писать в notepad-like, это затянется.
 АН Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с
 АН автоматическим определением по контексту того, что подсвечивать (например, 
js в
 АН script и css должны подсвечиваться по-разному).
 АН Он не обязательно должен работать в графическом режиме,

Дело не в этом.  Дело в том, что он обязательно НЕ должен быть WYSIWYG.
Как это выглядит, нужно смотреть в браузере и только в браузере.
Желательно не в одном.

 АН но графический режим добавляет возможность предосмотра картинок,
 АН например. Поддержка мышки и dd добавляет возможность быстрой
 АН компоновки. Меню организуют структуру команд и позволяют быстро
 АН найти нужную (они не заменяют горячих клавиш), без использования
 АН справки...  В итоге, получается GUI (причём, никто не отменяет
 АН поддержку консольного режима).  По-моему, это очевидно.  И чем тут
 АН он мешает (при условии, что он спроектирован и реализован
 АН грамотно)?

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

А JS длиннее одного вызова функции в script в ручную написанном HTML -
это признак того, что у автора слишком много свободного времени, и ему
нечем это время занять, кроме как вычисткой потом глюков из результата.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762bqdb04@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Artem Chuprina]

Stanislav Vlasov - Артём Н.  @ Fri, 18 May 2012 14:20:53 +0600:

 SV Не совсем так. GUI здесь необходим, если вы разрабатываете _дизайн_ 
страницы.

Причем этот гуй называется, surprise, Adobe InDesign, и ничего общего с
HTML не имеет...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871umedaxv@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Artem Chuprina]

Maksym Tiurin - Артём Н.  @ Fri, 18 May 2012 23:05:30 +0300:

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

 MT Представил себе меню emacs со всеми командами.
 MT Ужаснулся. Быстро там найти явно ниче нельзя будет.

Да ладно!  Я иногда включаю menu-bar-mode, когда не помню комбинацию
клавиш для операции.  И успешно там нахожу.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wr46bwbu@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Артём Н.]

20.05.2012 21:21, Artem Chuprina пишет:
 Артём Н. - debian-russian@lists.debian.org  @ Fri, 18 May 2012 12:07:00 
 +0400:
   Так что писать на коленке презентацию, которая будет выведена плюс-минус
   так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
   подобные поползновения печатать объявления в ворде...), а HTML - уже ни
   в коем разе.
  АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
  АН на то, что все ваши пользователи используют lynx, links, w3m или
  АН подобное.
 
 Доктор, это ничего, что у меня есть информативный сайт, все HTML
 которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
 - информативный. 
Вообще-то, это частный случай, когда требуется преимущественно подсветка HTML и
CSS. С чем VIM неплохо справляется.

 А если мне нужно интерактивное веб-приложение, то
 там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
 ручное редактирование.
Хм... Haml - любопытно.

 Как это выглядит, нужно смотреть в браузере и только в браузере.
 Желательно не в одном.
Как это выглядит и работает нужно проверять в браузере. Обязательно не в одном,
как говорят. По крайней мере, в наиболее популярных (или в тех, на которых это
будет работать, если это нечто специфическое). И, затем ещё вносить
корректировки для конкретных экземпляров. :-|

  АН но графический режим добавляет возможность предосмотра картинок,
  АН например. Поддержка мышки и dd добавляет возможность быстрой
  АН компоновки. Меню организуют структуру команд и позволяют быстро
  АН найти нужную (они не заменяют горячих клавиш), без использования
  АН справки...  В итоге, получается GUI (причём, никто не отменяет
  АН поддержку консольного режима).  По-моему, это очевидно.  И чем тут
  АН он мешает (при условии, что он спроектирован и реализован
  АН грамотно)?
 
 Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
 реальным видом документа.  А что этот гуй выдает в код, и какой ужас
 потом в браузере...  Это - практика.
o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор имеет
представление о том, что существуют разные средства вывода (и, если уж быть
точным, не обязательно визуальные).

  АН К тому же, для написания кода необходим нормальный интерфейс (ну,
используя cat
  АН или echo, тоже возможно кое-что написать, но идея плохая (как крайний
случай)).
  АН Если вы будете писать в notepad-like, это затянется.
  АН Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с
  АН автоматическим определением по контексту того, что подсвечивать
(например, js в
  АН script и css должны подсвечиваться по-разному).
  АН Он не обязательно должен работать в графическом режиме,

 Дело не в этом.  Дело в том, что он обязательно НЕ должен быть WYSIWYG.
Вот именно об этом я и говорю. WISYWYG плохо, потому что это WISYWYG (и ещё
десять надуманных причин).
Дело в том, что там он крайне желателен. Вопрос удобства.
Пример грамотно (несмотря на то, что они там напилили в последних версиях и ещё
множество лишних вещей) реализованного редактора - Dreamweaver.
WISYWYG нужен для примерного представления о том, как будет выглядеть документ.
Никто не отменяет ручной правки результата.
Но этак даже формочки во всяких Делфи возможно вручную делать. Но зачем?

 А JS длиннее одного вызова функции в script в ручную написанном HTML -
 это признак того, что у автора слишком много свободного времени, и ему
 нечем это время занять, кроме как вычисткой потом глюков из результата.
Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один внешний JS,
который включает объект её реализующий? Про много свободного времени - это вы
объясните авторам всяких там гуглов и ещё 100500 сервисов, которые этим JS
буквально пронизаны (местами это даже удобно и, бывает, работает).


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb93039.8070...@yandex.ru

Re: CLI vs. GUI

[Artem Chuprina]

Артём Н. - debian-russian@lists.debian.org  @ Sun, 20 May 2012 21:56:09 +0400:

Так что писать на коленке презентацию, которая будет выведена плюс-минус
так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
подобные поползновения печатать объявления в ворде...), а HTML - уже ни
в коем разе.
   АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
   АН на то, что все ваши пользователи используют lynx, links, w3m или
   АН подобное.
  
  Доктор, это ничего, что у меня есть информативный сайт, все HTML
  которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
  - информативный. 
 АН Вообще-то, это частный случай, когда требуется преимущественно
 АН подсветка HTML и CSS. С чем VIM неплохо справляется.

Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
файле, отчего все еще проще.

Суть, собственно, в том, что vim и emacs - это TUI, а не GUI.  Хотя
emacs даже умеет показывать картинки.  Лучше б не умел...

  А если мне нужно интерактивное веб-приложение, то
  там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
  ручное редактирование.
 АН Хм... Haml - любопытно.

Угу.  Технология создания веб-приложений сводится к тому, что дизайнер
делает дизайн, HTML-верстальщик (это совершенно другой человек)
превращает его в HTML, CSS и набор картинок, а программист превращает
эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
которые динамически заполняются данными.  Гуй для HTML при этом может
использоваться в принципе только на втором этапе, но тем верстальщикам,
кто пытается его там использовать, быстро отрывают руки.  Ну, или
результат получается, мягко говоря, неюзабельным для пользователя.

  Как это выглядит, нужно смотреть в браузере и только в браузере.
  Желательно не в одном.
 АН Как это выглядит и работает нужно проверять в браузере. Обязательно
 АН не в одном, как говорят. По крайней мере, в наиболее популярных
 АН (или в тех, на которых это будет работать, если это нечто
 АН специфическое). И, затем ещё вносить корректировки для конкретных
 АН экземпляров. :-|

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

   АН но графический режим добавляет возможность предосмотра картинок,
   АН например. Поддержка мышки и dd добавляет возможность быстрой
   АН компоновки. Меню организуют структуру команд и позволяют быстро
   АН найти нужную (они не заменяют горячих клавиш), без использования
   АН справки...  В итоге, получается GUI (причём, никто не отменяет
   АН поддержку консольного режима).  По-моему, это очевидно.  И чем тут
   АН он мешает (при условии, что он спроектирован и реализован
   АН грамотно)?
  
  Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
  реальным видом документа.  А что этот гуй выдает в код, и какой ужас
  потом в браузере...  Это - практика.
 АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор
 АН имеет представление о том, что существуют разные средства вывода
 АН (и, если уж быть точным, не обязательно визуальные).

Наличие гуя провоцирует не иметь такого представления.

 АН Но этак даже формочки во всяких Делфи возможно вручную делать. Но зачем?

В Delphi - можно, но тяжело и неудобно.  А в Tk - удобно...

  А JS длиннее одного вызова функции в script в ручную написанном HTML -
  это признак того, что у автора слишком много свободного времени, и ему
  нечем это время занять, кроме как вычисткой потом глюков из результата.
 АН Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один
 АН внешний JS, который включает объект её реализующий? Про много
 АН свободного времени - это вы объясните авторам всяких там гуглов и
 АН ещё 100500 сервисов, которые этим JS буквально пронизаны (местами
 АН это даже удобно и, бывает, работает).

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87396ubqew@wizzle.ran.pp.ru

Передёрнуть cups из командной строки? (Или же GUI для CUPS)

[Mikhail Ramendik]

Всем привет!

Squeeze, принтер HP PhotoSmart B110 на сетевом подключении (встроенный
wi-fi принтера), драйвер hpijs. Печатает нормально, но периодически
что-то глючит и принтер оказывается paused. Послче чего перестаёт
печатать, пока я не зайду на http://localhost:631 и не отменю эту
паузу (заодно сняв задания, клоторые были выданы юзером в попытке
что-то напечатать).

Я хотел бы дать юзеру возможность простым способом восстановить
работоспособностть принтера.

Лучше всего было бы сделать команду, которая отменяет все задания и
снимает все паузы. И повесить её на пункт меню icewm.

Есть ли такая команда?

Если нет - то есть ли GUI к CUPS, позволяющий снять паузу с меньшей
вознёй, чем http://localhost:631 ?

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)

[-=Devil_InSide=-]

варианты:
1. выпендриться сторонней утилитой:
если сделать через curl ?
пункт меню будет вызывать скприт, который будет автообщаться с веб-
интерфейсом.

2. прочитать документацию:
uri: http://www.cups.org/documentation.php/options.html

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

тут какие то гуи описаны:
uri: http://en.wikipedia.org/wiki/CUPS#User_interface_tools

,-[Mikhail Ramendik, 21 May 2012 00:57]:

 Всем привет!
 
 Squeeze, принтер HP PhotoSmart B110 на сетевом подключении (встроенный
 wi-fi принтера), драйвер hpijs. Печатает нормально, но периодически
 что-то глючит и принтер оказывается paused. Послче чего перестаёт
 печатать, пока я не зайду на http://localhost:631 и не отменю эту
 паузу (заодно сняв задания, клоторые были выданы юзером в попытке
 что-то напечатать).
 
 Я хотел бы дать юзеру возможность простым способом восстановить
 работоспособностть принтера.
 
 Лучше всего было бы сделать команду, которая отменяет все задания и
 снимает все паузы. И повесить её на пункт меню icewm.
 
 Есть ли такая команда?
 
 Если нет - то есть ли GUI к CUPS, позволяющий снять паузу с меньшей
 вознёй, чем http://localhost:631 ?
 

-- 
__
mpd status: [stopped]
**
*  jabber:  devil_ins...@jabber.ru   *
*   Registered linux user #450844*
**



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jpbn8d$aab$1...@dough.gmane.org

Re: Передёрнуть cups из командной строки? (Или же GUI для CUPS)

[Artem Chuprina]

Mikhail Ramendik - Debian-russian List  @ Sun, 20 May 2012 21:57:14 +0100:

 MR Лучше всего было бы сделать команду, которая отменяет все задания и
 MR снимает все паузы. И повесить её на пункт меню icewm.

 MR Есть ли такая команда?

Есть.  Только у меня сейчас не стоит cups, и я не могу сказать, какая
именно.  Подозреваю, что на самом деле это две команды - lp и cancel.

Ну, скрипт на три строки по вкусу.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txza9oew@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Maksym Tiurin]

Artem Chuprina writes:

 Maksym Tiurin - Артём Н.  @ Fri, 18 May 2012 23:05:30 +0300:

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

  MT Представил себе меню emacs со всеми командами.
  MT Ужаснулся. Быстро там найти явно ниче нельзя будет.

 Да ладно!  Я иногда включаю menu-bar-mode, когда не помню комбинацию
 клавиш для операции.  И успешно там нахожу.

Все? В меняю всех никогда ИМХО не было. Например режимы для работы с
Version Control Systems очень куцо в меню представлены.
-- 

With Best Regards, Maksym Tiurin
JID:mrko...@jabber.pibhe.com


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m31umert44@comp.bungarus.info

Re: CLI vs. GUI

[Артём Н.]

17.05.2012 15:09, Artem Chuprina пишет:
 Артём Н. - debian-russian@lists.debian.org  @ Thu, 17 May 2012 09:42:11 
 +0400:
 
   Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
   понимать что с ним будет происходить при некоторых изменениях (например
   при переформатировании на другую ширину) и быть уверенными что от этого
   смысл не потеряется.
  АН И, всё-таки, GUI... :-)
 
 Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
 человеческой психики, ничего личного.
 
 Так что писать на коленке презентацию, которая будет выведена плюс-минус
 так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
 подобные поползновения печатать объявления в ворде...), а HTML - уже ни
 в коем разе.
Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, что
все ваши пользователи используют lynx, links, w3m или подобное.
К тому же, для написания кода необходим нормальный интерфейс (ну, используя cat
или echo, тоже возможно кое-что написать, но идея плохая (как крайний случай)).
Если вы будете писать в notepad-like, это затянется.
Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с
автоматическим определением по контексту того, что подсвечивать (например, js в
script и css должны подсвечиваться по-разному).
Он не обязательно должен работать в графическом режиме, но графический режим
добавляет возможность предосмотра картинок, например. Поддержка мышки и dd
добавляет возможность быстрой компоновки. Меню организуют структуру команд и
позволяют быстро найти нужную (они не заменяют горячих клавиш), без
использования справки...
В итоге, получается GUI (причём, никто не отменяет поддержку консольного 
режима).
По-моему, это очевидно.
И чем тут он мешает (при условии, что он спроектирован и реализован грамотно)?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb60324.6010...@yandex.ru

Re: CLI vs. GUI

[Stanislav Vlasov]

18 мая 2012 г., 14:07 пользователь Артём Н. artio...@yandex.ru написал:
   Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
   понимать что с ним будет происходить при некоторых изменениях (например
   при переформатировании на другую ширину) и быть уверенными что от этого
   смысл не потеряется.
  АН И, всё-таки, GUI... :-)

 Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
 человеческой психики, ничего личного.

 Так что писать на коленке презентацию, которая будет выведена плюс-минус
 так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
 подобные поползновения печатать объявления в ворде...), а HTML - уже ни
 в коем разе.
 Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, что
 все ваши пользователи используют lynx, links, w3m или подобное.

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

-- 
Stanislav

Re: CLI vs. GUI

[Артём Н.]

17.05.2012 13:12, Иван Лох пишет:
 On Thu, May 17, 2012 at 09:42:11AM +0400, Артём Н. wrote:
 Хм... Наверное, пользователь документа - это тот, кто использует документ 
 (пусть
 даже это сайт, хотя тогда документ - не совсем верно).
 Тот, кто пишет - писатель или разработчик.
 
 браузеры которые слушаются пользователя лучше, чем дизайнера), а
 человек, который хочет донести до читателя смысл текста.
 Да, но читателю не нужно видеть разницу.
 Писатель предоставляет данные и способ их отображения 
 программе-обработчику.
 Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем
 детализации. Каждому - своё.
 
 Это вопрос о возможности модификации контента в широком смысле. Корпорация
 всегда стремиться затруднить активное использования продуктов своей
 жизнедеятельности. То есть свести все отношения к паре писатель-читатель.
С первым - согласен. Поскольку, монополизация идеи или другой интеллектуальной
собственности, вероятно, позволяет увеличить прибыль от её использования.
Со вторым - нет. Мне, например, не интересно исправлять ошибки в каком-нибудь
networkmanager (он недавно сглючил) или модифицировать его. Мне достаточно быть
читателем. В плане документов... Если это технический текст или код, возможно
вам потребуется его дополнять. Но это частный случай, который редко встречается.
Мало того, для этого требуется определённая квалификация (ну нет простых в
использовании инструментов для создания программ, даже если это RAD), а главное
- технические знания и понимание не только того, что сделал автор, но и как он
это сделал.
Прибавьте к этому частоту таких модификаций, сложность их сопровождения,
сложность...
Не каждому это нужно.

 Но, точно также, как и в opensource вне копирайтерских корпораций вопрос 
 использования,
 и трансформации контента стоит везде. И там где используется CC-SA вопрос о 
 виде
 пробелов и возможности их дальнейшего использования более чем актуален. 
 Вообще, потеря
 эмфазы, например, в цитатах, может исказить сегодня их смысл. Поэтому доступ 
 к исходным
 кодам произведения вполне важен. Этот процесс во многих областях идет. В 
 науке,
 например, где 90% фальсификаций скрыто за тремя кнопками, пресловутого, 
 ориджина -- тоже. 
Вопрос о доступе к исходным кодам - тема отдельного холивара.
Я лишь говорю о том, что для каждой задачи - свой инструмент.
А отвергать GUI, потому что он GUI, как-то странно...

 То же самое и GUI. sendmail, emacs, awesome, какой-нибудь, предоставляют 
 каждому
 широкую возможность модификации продукта прямо через конфигурационные файлы. 
 Любые GUI разом лишат их 90% функциональности. 
Ага, особенно учитывая известную простоту настройки sendmail, красоту и
понятность её конфига (по благодарным отзывам пользователей), думаю многие не
против настроить её через GUI. :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb6085a.5010...@yandex.ru

Re: CLI vs. GUI

[Artem Chuprina]

Иван Лох - debian-russian@lists.debian.org  @ Thu, 17 May 2012 19:17:12 +0400:

  Так что писать на коленке презентацию, которая будет выведена плюс-минус
  так, как ты ее видишь, еще можно (и то не всегда нужно - видел я

 ИЛ А потом потребуется постер или, например, буклет...

Так это я буду делать acroread'ом уже из PDF'ов.  А если потребуется
серьезный постер, то все равно переделывать.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjeyd45o@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Артём Н.]

18.05.2012 12:20, Stanislav Vlasov пишет:
 18 мая 2012 г., 14:07 пользователь Артём Н. artio...@yandex.ru написал:
   Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
   понимать что с ним будет происходить при некоторых изменениях (например
   при переформатировании на другую ширину) и быть уверенными что от этого
   смысл не потеряется.
  АН И, всё-таки, GUI... :-)

 Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
 человеческой психики, ничего личного.

 Так что писать на коленке презентацию, которая будет выведена плюс-минус
 так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
 подобные поползновения печатать объявления в ворде...), а HTML - уже ни
 в коем разе.
 Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, 
 что
 все ваши пользователи используют lynx, links, w3m или подобное.
 
 Не совсем так. GUI здесь необходим, если вы разрабатываете _дизайн_ страницы.
 Если же требуется написать её содержимое - здесь нужен редактор,
 который умеет разметку.
 Или даже достаточно отконвертировать документ откуда-то еще, дополнив
 элементами, созданными дизайнером для приведения внешнего вида к
 нужным кондициям.
Да, согласен, в этом случае GUI не всегда нужен, но страница может включать
иллюстрации, а специфичный GUI (например, специально для этого созданный),
позволит более просто содержимое подготовить (например, для Wiki не помешал бы
такой, поскольку копаться в справке по wiki специфичным тегам и разметки (ну или
искать примеры в коде), ради небольшого изменения (пример - добавление сноски),
вряд ли у кого вызовет серьёзный энтузиазм).


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb609d0.60...@yandex.ru

Re: CLI vs. GUI

[Maksym Tiurin]

Артём Н. writes:

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

Представил себе меню emacs со всеми командами.
Ужаснулся. Быстро там найти явно ниче нельзя будет.
-- 

With Best Regards, Maksym Tiurin
JID:mrko...@jabber.pibhe.com


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m3fwaxs19x@comp.bungarus.info

Re: CLI vs. GUI

[Иван Лох]

On Thu, May 17, 2012 at 09:42:11AM +0400, Артём Н. wrote:
 Хм... Наверное, пользователь документа - это тот, кто использует документ 
 (пусть
 даже это сайт, хотя тогда документ - не совсем верно).
 Тот, кто пишет - писатель или разработчик.

  браузеры которые слушаются пользователя лучше, чем дизайнера), а
  человек, который хочет донести до читателя смысл текста.
 Да, но читателю не нужно видеть разницу.
 Писатель предоставляет данные и способ их отображения программе-обработчику.
 Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем
 детализации. Каждому - своё.

Это вопрос о возможности модификации контента в широком смысле. Корпорация
всегда стремиться затруднить активное использования продуктов своей
жизнедеятельности. То есть свести все отношения к паре писатель-читатель.

Но, точно также, как и в opensource вне копирайтерских корпораций вопрос 
использования,
и трансформации контента стоит везде. И там где используется CC-SA вопрос о виде
пробелов и возможности их дальнейшего использования более чем актуален. Вообще, 
потеря
эмфазы, например, в цитатах, может исказить сегодня их смысл. Поэтому доступ к 
исходным
кодам произведения вполне важен. Этот процесс во многих областях идет. В науке,
например, где 90% фальсификаций скрыто за тремя кнопками, пресловутого, 
ориджина -- тоже. 

То же самое и GUI. sendmail, emacs, awesome, какой-нибудь, предоставляют каждому
широкую возможность модификации продукта прямо через конфигурационные файлы. 
Любые GUI разом лишат их 90% функциональности. 


-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120517091220.ga10...@nano.ioffe.rssi.ru

Re: CLI vs. GUI

[Artem Chuprina]

Артём Н. - debian-russian@lists.debian.org  @ Thu, 17 May 2012 09:42:11 +0400:

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

Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
человеческой психики, ничего личного.

Так что писать на коленке презентацию, которая будет выведена плюс-минус
так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
подобные поползновения печатать объявления в ворде...), а HTML - уже ни
в коем разе.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871umjdpym@wizzle.ran.pp.ru

Re: CLI vs. GUI

[Иван Лох]

On Thu, May 17, 2012 at 03:09:05PM +0400, Artem Chuprina wrote:
 
 Так что писать на коленке презентацию, которая будет выведена плюс-минус
 так, как ты ее видишь, еще можно (и то не всегда нужно - видел я

А потом потребуется постер или, например, буклет...

 подобные поползновения печатать объявления в ворде...), а HTML - уже ни
 в коем разе.

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120517151712.ga13...@nano.ioffe.rssi.ru

Re: CLI vs. GUI

[Артём Н.]

15.05.2012 11:12, Victor Wagner пишет:
 On 2012.05.15 at 10:58:27 +0400, Артём Н. wrote:
 
 Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) —
 нагляднее WYSIWYG.
 Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет
 определённые особенности в некоторых условиях, при отображении. Пользователю
 нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки
 
 Кого вы тут считаете пользователем? Читателя готового сформатированного
 текста на айпаде? Или все-таки человека, который документ ПИШЕТ?
Хм... Наверное, пользователь документа - это тот, кто использует документ (пусть
даже это сайт, хотя тогда документ - не совсем верно).
Тот, кто пишет - писатель или разработчик.

 Тому, кто документ пишет, принципиально видеть разницу между неразрывным
 пробелом и обычным, особенно если это не веб-дизайнер, гордящийся тем,
 что запретил пользователям увеличивать шрифт (не зная о том, что есть
 браузеры которые слушаются пользователя лучше, чем дизайнера), а
 человек, который хочет донести до читателя смысл текста.
Да, но читателю не нужно видеть разницу.
Писатель предоставляет данные и способ их отображения программе-обработчику.
Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем
детализации. Каждому - своё.

 Поэтому все опытные пользователи WYSIWYG текстовых процессоров, которых
 я знаю, всегда включают режим отображения невидимых символов в
 LibreOffice/Microsoft Office или окно разметки в WordPerfect.
 
 Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
 понимать что с ним будет происходить при некоторых изменениях (например
 при переформатировании на другую ширину) и быть уверенными что от этого
 смысл не потеряется.
И, всё-таки, GUI... :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb48fb3.4020...@yandex.ru

Re: CLI vs. GUI

[Konstantin Fadeyev]

GUI хорош для одних вещей, CLI для других.
В сущности скрипты которые мы пишем позволяют нам АВТОМАТИЗИРОВАТЬ
некоторые задачи. В этом их суть, их эго если хотите. Если брать чисто
командную строку, суть так или иначе сводится к скриптам и алиасам.
Долбить постоянно строку из 300 символов вряд ли кто хочет.
А вот создание текстовых документов с некоторой графикой и средней
степенью сложности форматирования, текстовые GUI процессоры, весьма и
весьма хороши. И опять же, да, не отображаемые символы наше всё.

-- 
Константин Фадеев

CLI vs. GUI

[Ivan Shmakov]

 Артём Н artio...@yandex.ru writes:
 14.05.2012 18:50, Ivan Shmakov пишет:

  Не всегда.  Прописать длинное правило дольше, менее наглядно,
  сложнее (больше всего надо помнить и вспоминать), чем использовать
  GUI, а вероятность допустить ошибку выше.

  Хм.  Есть большая разница между « », « » и « ».  Наглядно?

  А если так: « », «nbsp;» и «ensp;»?

  Причём тут интерфейс?

Это не к «интерфейсам», но к «наглядности.»

Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) —
нагляднее WYSIWYG.

  Гуй нужен для создания визуального представления для человека.
  Больше ни для чего.

  Ага.  Вот этот ГУЙ, как-раз только эту задачу и выполняет.  Это и
  нравится.  Кстати, CLI тоже нужен только для взаимодействия с
  человеком.

  Здесь речь не столько о GUI vs. CLI, сколько о «меню» vs. «язык
  программирования.»

  Основная проблема «типовых» GUI — невозможность «записать»
  последовательность команд, отданных пользователем, для последующего
  повторного использования.  В тех же случаях, когда такая возможность
  предоставляется (через определение «макрокоманд»), записанную
  последовательность нередко нельзя /параметризовать/.

  В случае с GUI, о котором речь, эти проблемы не стоят. :-)

Почему?

  Напротив, при использовании языков, производных от POSIX Shell, все
  эти возможности, как правило, в наличии.

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

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

Как показывает практика, в подавляющем большинстве случаев,
«проблемы advanced users разработчиков не волнуют», поэтому
«возможность» добавить язык к GUI-приложению остается лишь
возможностью.

  Впрочем, с учетом появления Ubuntu HUD, не исключено, что CLI
  обретет «вторую жизнь» в рамках ныне существующей
  «GUI-инфраструктуры.»

  o.O Фигасе.  Посмотрел что такое.  Ну стоит у меня ubiquity в
  iceweasel (в репозитории увидел и решил посмотреть, что такое).  Я
  даже помню, как он вызывается, но не пользуюсь.  Есть подозрение, что
  ихний HUD постигнет та же учесть, что и десяток (или сотню?) подобных
  велосипедов.

Возможно.  Но, на мой взгляд, запомнить название команды^W
пункта меню куда проще, чем название /и/ положение оного.

--cut: http://tourlib.net/books_others/gates_doroga_04.htm --
Но графический пользовательский интерфейс недостаточно прост для
будущих систем.  Мы столько всего размещаем на экране, что начинаем
путаться в программах или функциях, применяемых от случая к случаю.
Все эти возможности хороши для людей знающих, а к среднему
пользователю машина должна быть дружелюбнее, иначе ему с ней очень
неуютно.  […]
--cut: http://tourlib.net/books_others/gates_doroga_04.htm --

[…]

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/868vgurmq3.fsf...@gray.siamics.net

Re: CLI vs. GUI

[Артём Н.]

15.05.2012 10:18, Ivan Shmakov пишет:
 Артём Н artio...@yandex.ru writes:
 14.05.2012 18:50, Ivan Shmakov пишет:
 
   Не всегда.  Прописать длинное правило дольше, менее наглядно,
   сложнее (больше всего надо помнить и вспоминать), чем использовать
   GUI, а вероятность допустить ошибку выше.
 
   Хм.  Есть большая разница между « », « » и « ».  Наглядно?
 
   А если так: « », «nbsp;» и «ensp;»?
 
   Причём тут интерфейс?
 
   Это не к «интерфейсам», но к «наглядности.»
 
   Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) —
   нагляднее WYSIWYG.
Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет
определённые особенности в некоторых условиях, при отображении. Пользователю
нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки
(предназначенном для визуального отображения), пробел рисуется. В правильно
спроектированном интерфейсе (пусть даже это web-сайт), пробел останется
пробелом, безо всяких неоднозначностей.

 
   Гуй нужен для создания визуального представления для человека.
   Больше ни для чего.
 
   Ага.  Вот этот ГУЙ, как-раз только эту задачу и выполняет.  Это и
   нравится.  Кстати, CLI тоже нужен только для взаимодействия с
   человеком.
 
   Здесь речь не столько о GUI vs. CLI, сколько о «меню» vs. «язык
   программирования.»
 
   Основная проблема «типовых» GUI — невозможность «записать»
   последовательность команд, отданных пользователем, для последующего
   повторного использования.  В тех же случаях, когда такая возможность
   предоставляется (через определение «макрокоманд»), записанную
   последовательность нередко нельзя /параметризовать/.
 
   В случае с GUI, о котором речь, эти проблемы не стоят. :-)
 
   Почему?
Потому что там не нужно повторять последовательность команд, настройки
сохраняются, а дописать своё возможно в пролог или эпилог скрипта.

 
   Напротив, при использовании языков, производных от POSIX Shell, все
   эти возможности, как правило, в наличии.
 
   Это проблемы конкретного интерфейса.  Нужен язык - достаточно
   встроить движок в интерфейс.
 
   Конечно.  Но если мы создаем команднострочное приложение, то
   язык мы получаем «бесплатно», в то время как при создании
   приложения с графическим интерфейсом язык требует отдельного
   внимания.
Как и сам интерфейс.

   Как показывает практика, в подавляющем большинстве случаев,
   «проблемы advanced users разработчиков не волнуют», поэтому
   «возможность» добавить язык к GUI-приложению остается лишь
   возможностью.
Возможно иметь GUI и CLI одновременно. Хотя бы поддержку опций. Иногда GUI
удобнее. Я ж не говорю о том, что нужно ставить вопрос GUI vs CLI. :-\
Тут дело в том требуется ли такое в интерфейсе, а не в advanced users.

   o.O Фигасе.  Посмотрел что такое.  Ну стоит у меня ubiquity в
   iceweasel (в репозитории увидел и решил посмотреть, что такое).  Я
   даже помню, как он вызывается, но не пользуюсь.  Есть подозрение, что
   ихний HUD постигнет та же учесть, что и десяток (или сотню?) подобных
   велосипедов.
 
   Возможно.  Но, на мой взгляд, запомнить название команды^W
   пункта меню куда проще, чем название /и/ положение оного.
Ну да...
artiom@dana:~/Desktop$ l
Display all 201 possibilities? (y or n)


 --cut: http://tourlib.net/books_others/gates_doroga_04.htm --
O_O


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fb1fe93.2020...@yandex.ru

Re: CLI vs. GUI

[Victor Wagner]

On 2012.05.15 at 10:58:27 +0400, Артём Н. wrote:

  Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) —
  нагляднее WYSIWYG.
 Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет
 определённые особенности в некоторых условиях, при отображении. Пользователю
 нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки

Кого вы тут считаете пользователем? Читателя готового сформатированного
текста на айпаде? Или все-таки человека, который документ ПИШЕТ?

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

Поэтому все опытные пользователи WYSIWYG текстовых процессоров, которых
я знаю, всегда включают режим отображения невидимых символов в
LibreOffice/Microsoft Office или окно разметки в WordPerfect.

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515071220.ga5...@wagner.pp.ru

Re: The Linux Security Circus: On GUI isolation

[Alexander Aksarin]

On 13:31 Thu 23 Jun , Stanislav Maslovski wrote:
 По дефолту может (как и в той же винде, впрочем). Не cможет, если
 sensitive app позовет XGrabKeyboard().
 
 В меню xterm (Сtrl+LeftButton) есть пукт Secure keyboard.
Запускаю 2 xterm`а рядом, в первом 
$ xinput test 10
во втором включаю secure keyboard, ввожу что нибудь и вижу сканкоды в первом.
Так что похоже не работает.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110624124009.GB19345@debhm

Re: The Linux Security Circus: On GUI isolation

[Stanislav Maslovski]

On Птн, 2011-06-24 at 18:40 +0600, Alexander Aksarin wrote:
 On 13:31 Thu 23 Jun , Stanislav Maslovski wrote:
  По дефолту может (как и в той же винде, впрочем). Не cможет, если
  sensitive app позовет XGrabKeyboard().
  
  В меню xterm (Сtrl+LeftButton) есть пукт Secure keyboard.
 Запускаю 2 xterm`а рядом, в первом 
 $ xinput test 10
 во втором включаю secure keyboard, ввожу что нибудь и вижу сканкоды в первом.
 Так что похоже не работает.

Мм, да, против этого лома, похоже, нет приема: xinput перехватывает ввод
прямо с драйвера, а XGrabKeyboard() влияет только на получение более
высокоуровневых событий ввода.

Жаловаться можно, например, сюда:
https://bugs.freedesktop.org/show_bug.cgi?id=38517

-- 
Stanislav

Re: The Linux Security Circus: On GUI isolation

[Andrey Rahmatullin]

On Fri, Jun 24, 2011 at 02:08:28PM +0100, Stanislav Maslovski wrote:
   По дефолту может (как и в той же винде, впрочем). Не cможет, если
   sensitive app позовет XGrabKeyboard().
   
   В меню xterm (Сtrl+LeftButton) есть пукт Secure keyboard.
  Запускаю 2 xterm`а рядом, в первом 
  $ xinput test 10
  во втором включаю secure keyboard, ввожу что нибудь и вижу сканкоды в 
  первом.
  Так что похоже не работает.
 
 Мм, да, против этого лома, похоже, нет приема: xinput перехватывает ввод
 прямо с драйвера, а XGrabKeyboard() влияет только на получение более
 высокоуровневых событий ввода.
 
 Жаловаться можно, например, сюда:
 https://bugs.freedesktop.org/show_bug.cgi?id=38517
У рута есть ещё evtest.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

The Linux Security Circus: On GUI isolation

[Alexander Aksarin]

Здравствуйте. Прочитал интересную статью про безопасноть X-сервера. 
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
Проверил, у меня работает, как описано. Это получается что любая прога в
рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
огромной дырой в безопасности?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110623083917.GA14863@debhm

Re: The Linux Security Circus: On GUI isolation

[Artem Chuprina]

 Здравствуйте. Прочитал интересную статью про безопасноть X-сервера. 
 http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
 Проверил, у меня работает, как описано. Это получается что любая прога в
 рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
 огромной дырой в безопасности?

Да.  Если ты запускаешь что попало в своем X-сервере, то лучше просто знать,
что кто угодно может что угодно, чем не знать.  Поскольку для работы им все
равно нужно мочь.  Не с клавиатуры, так из selection, но нужно.

-- 
Танк - это не фаллический символ. Он просто _едет_...
(С)энта


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjr0sxll.wl%...@ran.pp.ru

Re: The Linux Security Circus: On GUI isolation

[Stanislav Maslovski]

On Thu, Jun 23, 2011 at 02:39:17PM +0600, Alexander Aksarin wrote:
 Здравствуйте. Прочитал интересную статью про безопасноть X-сервера. 
 http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
 Проверил, у меня работает, как описано. Это получается что любая прога в
 рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
 огромной дырой в безопасности?

По дефолту может (как и в той же винде, впрочем). Не cможет, если
sensitive app позовет XGrabKeyboard().

В меню xterm (Сtrl+LeftButton) есть пукт Secure keyboard.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110623093150.GA30581@kaiba.homelan

Re: The Linux Security Circus: On GUI isolation

[Igor Chumak]

23.06.2011 12:31, Artem Chuprina пишет:

Здравствуйте. Прочитал интересную статью про безопасноть X-сервера.
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
Проверил, у меня работает, как описано. Это получается что любая прога в
рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
огромной дырой в безопасности?

Да.  Если ты запускаешь что попало в своем X-сервере, то лучше просто знать,
что кто угодно может что угодно, чем не знать.  Поскольку для работы им все
равно нужно мочь.  Не с клавиатуры, так из selection, но нужно.


Очень удобно, что клавиатурный сниффер уже включен в дистрибутив ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e030b11.2070...@gmail.com

Re: The Linux Security Circus: On GUI isolation

[duk]

 http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
 Проверил, у меня работает, как описано. Это получается что любая прога в
 рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
 огромной дырой в безопасности?


Не желаю офтопить, но такой вопрос, на гуя мне выделять Х другим пользователям?

Серьёзно, для каких целей я поставлю Х-сервер на линию и дам кому-то
доступ?  По вашему мнению, есть какие-то приложения, что нуждаются в Х
сервировке?  Если есть, то можно ли запретить пользование Х консолем в
таком случае?  И будет ли это примитивным решением вышеуказанной
проблемы безопасности?

Re: The Linux Security Circus: On GUI isolation

[Igor Chumak]

23.06.2011 13:52, duk пишет:

http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
Проверил, у меня работает, как описано. Это получается что любая прога в
рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется это
огромной дырой в безопасности?


Не желаю офтопить, но такой вопрос, на гуя мне выделять Х другим пользователям?

Серьёзно, для каких целей я поставлю Х-сервер на линию и дам кому-то
доступ?

Это уж вам виднее ;) Странная постановка вопроса. У всех задачи разные

   По вашему мнению, есть какие-то приложения, что нуждаются в Х
сервировке?

chromium-browser например

Если есть, то можно ли запретить пользование Х консолем в
таком случае?  И будет ли это примитивным решением вышеуказанной
проблемы безопасности?
Пользуясь этой фичей, администратор системы может спокойно тырить 
пользовательские пароли. Не все же серфят lynx'ом из xterm'а ;)



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e032414.1050...@gmail.com

Re: The Linux Security Circus: On GUI isolation

[Artem Chuprina]

  http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
  Проверил, у меня работает, как описано. Это получается что любая прога в
  рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется 
  это
  огромной дырой в безопасности?
 
  Не желаю офтопить, но такой вопрос, на гуя мне выделять Х другим 
  пользователям?
 
  Серьёзно, для каких целей я поставлю Х-сервер на линию и дам кому-то
  доступ?
 Это уж вам виднее ;) Странная постановка вопроса. У всех задачи разные
 По вашему мнению, есть какие-то приложения, что нуждаются в Х
  сервировке?
 chromium-browser например
  Если есть, то можно ли запретить пользование Х консолем в
  таком случае?  И будет ли это примитивным решением вышеуказанной
  проблемы безопасности?
 Пользуясь этой фичей, администратор системы может спокойно тырить 
 пользовательские пароли. Не все же серфят lynx'ом из xterm'а ;)

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

-- 
на вопрос как дела? отвечать 304 Not Modified
 -- http://bash.org.ru/quote/20466


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc1osne5.wl%...@ran.pp.ru

Re: The Linux Security Circus: On GUI isolation

[Murat D. Kadirov]

On 23.06.2011 19:11, Artem Chuprina wrote:
 http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
 Проверил, у меня работает, как описано. Это получается что любая прога в
 рамках запущенного X-сервера может слушать что я ввожу. Только мне кажется 
 это
 огромной дырой в безопасности?

 Не желаю офтопить, но такой вопрос, на гуя мне выделять Х другим 
 пользователям?

 Серьёзно, для каких целей я поставлю Х-сервер на линию и дам кому-то
 доступ?
 Это уж вам виднее ;) Странная постановка вопроса. У всех задачи разные
По вашему мнению, есть какие-то приложения, что нуждаются в Х
 сервировке?
 chromium-browser например
 Если есть, то можно ли запретить пользование Х консолем в
 таком случае?  И будет ли это примитивным решением вышеуказанной
 проблемы безопасности?
 Пользуясь этой фичей, администратор системы может спокойно тырить 
 пользовательские пароли. Не все же серфят lynx'ом из xterm'а ;)
 
 Администратор может тырить пользовательские пароли и пользуясь массой других
 фич.  Начиная с возможности спокойно читать память любого процесса.
 

Наверное, всё-таки, заканчивая этим )


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e0341ed.9040...@gmail.com

Debian GUI administration tools?

[Oleksandr Gavenko]

Нужно посоветовать человеку для VPS (для PHP хостинга и сопутствующее)
графические тулзовины для администрирования.

Например вмеcто того что бы править proftpd.conf он заполняет менюшки.
Суть в экономии времени и избавиться от необходимости изучать docs.

Доступ по ssh, можно X Server + Xming.

Нашел такое:

  $ apt-cache search admin


  $ sudo apt-get install kdeadmin
  $ sudo apt-get install gnome-system-tools

В принципе вроде то что нужно, но по мне слишком bloated.

Any suggestion welcome.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ilntk5$dfl$1...@dough.gmane.org

Re: Debian GUI administration tools?

[Kirill Spitsin]

On Tue, Mar 15, 2011 at 04:38:14PM +0200, Oleksandr Gavenko wrote:
 Нужно посоветовать человеку для VPS (для PHP хостинга и сопутствующее)
 графические тулзовины для администрирования.

Может подойти Webmin (http://www.webmin.com/).

-- 
Kirill Spitsin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110315145818.gb64...@0x746e.org.ua

Re: Debian GUI administration tools?

[Oleksandr Gavenko]

On 15.03.2011 16:58, Kirill Spitsin wrote:

On Tue, Mar 15, 2011 at 04:38:14PM +0200, Oleksandr Gavenko wrote:

Нужно посоветовать человеку для VPS (для PHP хостинга и сопутствующее)
графические тулзовины для администрирования.


Может подойти Webmin (http://www.webmin.com/).


http://en.wikipedia.org/wiki/Control_panel_(Web_hosting) тоже думалось
Боялся спрашивать - что слишком глупо...

А почему в репозитории Debian нету Webmin, вроде лицензия BSD?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ilo0cs$e0$1...@dough.gmane.org

Re: Debian GUI administration tools?

[Andrey Rahmatullin]

On Tue, Mar 15, 2011 at 05:25:34PM +0200, Oleksandr Gavenko wrote:
 А почему в репозитории Debian нету Webmin, вроде лицензия BSD?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

hiddenman victor`: общаясь с майнтейнерами alt-а ты еще не раз почуствуешь
себя ничтожеством. я уже привык. это даже полезно, как штаммы
вируса гриппа, которые укрепляют иммунитет :)


signature.asc
Description: Digital signature

Re: Debian GUI administration tools?

[Munko O. Bazarzhapov]

А можете вкратце перевести почему удалили, у меня с английским очень туго


LLC Master-Byte
Munko O. Bazarzhapov
JabberID: v...@aginskoe.ru
ICQ:169245258
mail: vec...@gmail.com



16 марта 2011 г. 0:36 пользователь Andrey Rahmatullin w...@wrar.name написал:
 On Tue, Mar 15, 2011 at 05:25:34PM +0200, Oleksandr Gavenko wrote:
 А почему в репозитории Debian нету Webmin, вроде лицензия BSD?
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897

 --
 WBR, wRAR
 Powered by the ALT Linux fortune(6):

 hiddenman victor`: общаясь с майнтейнерами alt-а ты еще не раз почуствуешь
            себя ничтожеством. я уже привык. это даже полезно, как штаммы
            вируса гриппа, которые укрепляют иммунитет :)

Re: Debian GUI administration tools?

[Andrey Rahmatullin]

On Wed, Mar 16, 2011 at 03:44:42AM +0900, Munko O. Bazarzhapov wrote:
 А можете вкратце перевести почему удалили, у меня с английским очень туго
Майнтейнер прекратил майнтейнить пакет.

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

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


signature.asc
Description: Digital signature

Re: Debian GUI administration tools?

[Alexey Boyko]

Tue, 15 Mar 2011 16:38:14 +0200 було написано Oleksandr Gavenko  
gave...@bifit.com.ua:



Нужно посоветовать человеку для VPS (для PHP хостинга и сопутствующее)
графические тулзовины для администрирования.

Например вмеcто того что бы править proftpd.conf он заполняет менюшки.
Суть в экономии времени и избавиться от необходимости изучать docs.


тоже посоветую webmin, но не советую пользоваться им наобум. он не  
полностью исключает
необходимость читать доки. И первое время советую посматривать в конфиги,  
чего он там накорячил.


в виде пакета доступен тут:

deb http://download.webmin.com/download/repository sarge contrib

Написан на перле, по умолчанию висит на https://localhost:1

--
xmpp:ale...@boyko.km.ua

Re: как писать GUI?

[Ed]

Alexander Danilov wrote:

Ну посмотрите же наконец widget demo:

wish8.5 /usr/share/tcltk/tk8.5/demos/widget


спасибо, хорошая вещь


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1f6b7c.9030...@yandex.ru

Re: как писать GUI?

[Ed]

Artem Chuprina wrote:

 E - хорошая ли идея использовать tk из других языков?

Да.
  


я правильно понял, что tk написан на tcl и фактически без tcl tk не 
существует?


у меня сейчас складывается приложение написанное на lua+C, два 
скриптовых языка в одном приложении - это наверное перебор ;)



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1f6fb9.4020...@yandex.ru

Re: как писать GUI?

[Artem Chuprina]

Ed - debian-russian@lists.debian.org  @ Mon, 21 Jun 2010 17:57:13 +0400:

   E - хорошая ли идея использовать tk из других языков?
 
  Да.

 E я правильно понял, что tk написан на tcl и фактически без tcl tk не
 E существует?

Нет, неправильно.  Интерфейс из C тоже есть.  Но из tcl удобнее.

-- 
kernel bug (англ.) - ядрёна вошь


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/83686...@wizzle.ran.pp.ru

Re: как писать GUI?

[Artem Chuprina]

Alexey Boyko - debian-russian@lists.debian.org  @ Sun, 20 Jun 2010 19:13:13 
+0300:

Ну уж не страшнее, чем гном или KDE.  Особенно - если настроить.
 
   AB А можно скриншот с настроеным tkabber ? (ну или другой tk-программой)
 
  В аттаче.

 AB страшненько. а можно его переключить на стиль clam ?

А я почем знаю?  Мне нужен именно такой, а кто такой clam, я не в
курсе, и что характерно, не хочу...

-- 
Презерватив - это защита от копирования дурака.
 -- (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/17606...@wizzle.ran.pp.ru

Re: как писать GUI?

[Victor Wagner]

On 2010.06.21 at 17:57:13 +0400, Ed wrote:

 Artem Chuprina wrote:
  E - хорошая ли идея использовать tk из других языков?

 Да.
   

 я правильно понял, что tk написан на tcl и фактически без tcl tk не  
 существует?

Неправильно. Tk написан на C. Существует Perl Tk и Scheme-Tk, где Tcl
заменен соответственно на Perl и Scheme. Питоновцы пошли по пути
наименьшего сопротивления и прилинковали интерпретатор Tcl к
интерпретатору Python. Поэтому у них не просто  Tk, а Tkinter - Tk
interpreter. Это дает возможность гораздо с большей легкостью
использовать разнообразные расширения Tk,  сделанные для Tcl/Tk.

 у меня сейчас складывается приложение написанное на lua+C, два  
 скриптовых языка в одном приложении - это наверное перебор ;)

Ну как мы видим на примере Python - не все так считают.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100621164431.ga23...@wagner.pp.ru

Re: как писать GUI?

[Victor Wagner]

On 2010.06.21 at 17:57:13 +0400, Ed wrote:

 Artem Chuprina wrote:
  E - хорошая ли идея использовать tk из других языков?

 Да.
   

 я правильно понял, что tk написан на tcl и фактически без tcl tk не  
 существует?

 у меня сейчас складывается приложение написанное на lua+C, два  
 скриптовых языка в одном приложении - это наверное перебор ;)

http://www.tecgraf.puc-rio.br/~celes/tklua/


 -- 
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/4c1f6fb9.4020...@yandex.ru



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100621164536.gb23...@wagner.pp.ru

Re: как писать GUI?

[Ed]

Victor Wagner wrote:
у меня сейчас складывается приложение написанное на lua+C, два  
скриптовых языка в одном приложении - это наверное перебор ;)



http://www.tecgraf.puc-rio.br/~celes/tklua/
  

видел.

увы, оно не очень живое. ссылка на ftp не работает, да и Last update: 
November 1998 напрягает - совместимость с тех пор несколько раз ломали.


у меня сейчас складывается приложение написанное на lua+C, два  
скриптовых языка в одном приложении - это наверное перебор ;)



Ну как мы видим на примере Python - не все так считают.
  

ну рядом с питоном тикль пушинка.
а lua компактней сегодняшнего tcl.

ps: впрочем на самом деле для меня не так критичен lua, просто я сразу 
на текущую задачку примеряю предлагаемые варианты.

хочется понять - как именно удобнее писать GUI под иксы.
проблема ещё наверное в том, что у всех понятия об удобстве разные ;)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1fa428.4040...@yandex.ru

Re: как писать GUI?

[Alexey Boyko]

Sat, 19 Jun 2010 17:29:43 +0300 було написано Artem Chuprina  
r...@ran.pp.ru:



  Ну уж не страшнее, чем гном или KDE.  Особенно - если настроить.

 AB А можно скриншот с настроеным tkabber ? (ну или другой  
tk-программой)


В аттаче.


страшненько. а можно его переключить на стиль clam ?

--
За використання революційного клієнта електронної пошти Opera:  
http://www.opera.com/mail/

Re: как писать GUI?

[Alexander Galanin]

On Fri, 18 Jun 2010 23:33:20 +0600
Andrey Rahmatullin w...@altlinux.org wrote:

 On Fri, Jun 18, 2010 at 08:47:24PM +0400, Alexander Galanin wrote:
 Нижеприведённые строки помогают от них избавиться:
  
  aptitude install tk8.5
  update-alternatives --set wish /usr/bin/wish8.5
 Это правит только шрифты. Это конечно отличное и своевременное достижение
 для 2007 года, но внешний вид виджетов лучше не становится.

Наблюдаю уход от темы разговора к обсуждению субъективных вопросов
восприятия и привычек. Скажу только что у большинства плевавшихся от
внешнего вида _по_умолчанию_ претензии пропадали при использовании tk8.5.

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

Не видел ещё ни одного движка с темами, который удовлетворил бы меня
уровнем настраиваемости. Тот же tile нельзя настраивать через XRDB (нет
соответствующей темы).

-- 
Alexander Galanin


pgp5zIzbWOXmY.pgp
Description: PGP signature

Re: как писать GUI?

[Alexander Galanin]

On Fri, 18 Jun 2010 23:56:35 +0400
Ed sp...@yandex.ru wrote:

  - я не сталкивался с tcl, стоит ли он того, чтобы его учить (и на нём 
 писать)?

Да.

  - хорошая ли идея использовать tk из других языков?

Не знаю, не доводилось. Но с питоном используют нередко.

  - какую литературу порекомендуете для ознакомления?

Brent B. Welch, Practical Programming in Tcl  Tk
http://tkdocs.com/

-- 
Alexander Galanin


pgpDvYpySdHyU.pgp
Description: PGP signature

Re: как писать GUI?

[Alexander Galanin]

On Fri, 18 Jun 2010 21:33:55 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

 По aptitude install tkabber все еще ставится нечто страшное, с кривыми
 дефолтными русскими шрифтами...  

Потому что умолчательна версия Tk в дебиане --- 8.4. А там как раз
сломали отрисовку шрифтов (в 8.3 работало, в 8.5 тоже работает).

-- 
Alexander Galanin


pgpsw9matZzbS.pgp
Description: PGP signature

Re: как писать GUI?

[Andrey Rahmatullin]

On Sat, Jun 19, 2010 at 10:15:51AM +0400, Alexander Galanin wrote:
   - хорошая ли идея использовать tk из других языков?
 Не знаю, не доводилось. Но с питоном используют нередко.
Там, собсна, биндинги в stdlib.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Ваши желания не означают необходимости их реализации так, как Вам
это представляется.
-- zerg in devel@


signature.asc
Description: Digital signature

Re: как писать GUI?

[Dmitry Nezhevenko]

On Sat, Jun 19, 2010 at 10:23:03AM +0400, Alexander Galanin wrote:
 On Fri, 18 Jun 2010 21:33:55 +0300
 Dmitry Nezhevenko d...@inhex.net wrote:
 
  По aptitude install tkabber все еще ставится нечто страшное, с кривыми
  дефолтными русскими шрифтами...  
 
 Потому что умолчательна версия Tk в дебиане --- 8.4. А там как раз
 сломали отрисовку шрифтов (в 8.3 работало, в 8.5 тоже работает).
 

Оно по жизни так? В etch тоже убого выглядело =)
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: как писать GUI?

[yuri . nefedov]

On Sat, 19 Jun 2010, Alexander Galanin wrote:


On Fri, 18 Jun 2010 23:33:20 +0600
Andrey Rahmatullin w...@altlinux.org wrote:


On Fri, Jun 18, 2010 at 08:47:24PM +0400, Alexander Galanin wrote:

Нижеприведённые строки помогают от них избавиться:

aptitude install tk8.5
update-alternatives --set wish /usr/bin/wish8.5

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


Наблюдаю уход от темы разговора к обсуждению субъективных вопросов
восприятия и привычек. Скажу только что у большинства плевавшихся от
внешнего вида _по_умолчанию_ претензии пропадали при использовании tk8.5.



  Всё же не стоит сводить все проблемы к субъективному восприятию.
  То что называют корявостью, вырви глаз и т.д. сводится к
  вполне прозаичным вещам: плохо проработанному размещению виджетов
  друг относительно друга, неравномерности в интервалах между ними,
  плохо предсказуемому поведению этих пробелов при изменении размеров.
  Вообще говоря, это не проблемы Tk, это проблемы горе дизайнеров
  которые пишут на нём. Имеются граммотно написанные приложения
  замечательно выглядящие даже в 8.4. Скажем tkdiff.
  Никаких претензий.

  Мне кажется, что ситуация здесь похожа на сравнение *TeX и
  *office. Документ написанный в *TeX обычно более качественный,
  чем в *office. Просто потому, что Knuth засунул внутрь TeX
  огромное колличество типографских знаний, правил и т.п.
  Сделать типографскую ошибку в *TeX гораздо труднее.
  В *office же человек с плохим вкусом быстренько добивается
  нужных _ему_ результатов.

  То же самое в Tk. Нет никаких механизмов предотвратить
  грубые дизайнерские просчеты. Не сказать, что в других
  пакетах с этим намного лучше, но всё же, на мой взгляд,
  в этом отношении Tk худший. Motif, опять же IMHO, лучший,
  но там свои тараканы.


Не то, что во всякой новомодной гадости.

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


Не видел ещё ни одного движка с темами, который удовлетворил бы меня
уровнем настраиваемости. Тот же tile нельзя настраивать через XRDB (нет
соответствующей темы).



  Введение тем в Tk только выявляет эти недостатки.
  Достаточно взглянуть на скриншоты TTk/Tile:
  http://wiki.tcl.tk/11075

  Расстояние между радио, чек и комбо гуляет как хочет.
  Комбо и энтри сливаются. separator сливается с меню,
  а меню с статус...
  Причём в разных темах эффект то появляется, то исчезает.

  А всякие округлости, цвета и т.д. - это вторично.

 Ю.

Re: как писать GUI?

[Serhiy Storchaka]

Ed wrote:
 Пожалуй и всё пока. Повторюсь, главное - простота и удобство.

Если потребности скромны -- Xdialog/zenity/kdialog. Если посложнее --
посмотреть kommander. Ещё серьёзнее -- Tcl/Tk, придётся нырнуть с головой,
но потом станет просто. Если очень захотеть, то и от вырвиглаза избавиться
можно (я видел результат не хуже Gtk). Для совсем сложного и нетривиального
GUI придётся использовать Qt/Gtk.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hvi4tb$vo...@dough.gmane.org

Re: как писать GUI?

[Artem Chuprina]

Andrey Rahmatullin - debian-russian@lists.debian.org  @ Fri, 18 Jun 2010 
22:35:21 +0600:

  http://tcl.tk
 AR Вот только выглядит вырвиглазно.

Ну уж не страшнее, чем гном или KDE.  Особенно - если настроить.

-- 
Молодой, дикорастущий организм...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/62271...@wizzle.ran.pp.ru

Re: как писать GUI?

[Artem Chuprina]

Ed - debian-russian@lists.debian.org  @ Fri, 18 Jun 2010 23:56:35 +0400:

  ак-то не приходилось в последние годы писать GUI-приложений, а вот скоро
  похоже потребуется.
  Ничего особо сложного: кнопки, поля ввода, гриды и прочий примитив.
 
  http://tcl.tk

 E да, такой вариант мне приходил в голову.

 E вопросы:
 E - я не сталкивался с tcl, стоит ли он того, чтобы его учить (и на нём 
писать)?

Да.

 E - хорошая ли идея использовать tk из других языков?

Да.

 E - какую литературу порекомендуете для ознакомления?

Вэлша уже посоветовали.

-- 
Пифагоровы штаны Лобачевскому смешны
 -- lj user=osd


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/96191...@wizzle.ran.pp.ru

Re: как писать GUI?

[Alexander Galanin]

On Sat, 19 Jun 2010 11:45:28 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

 On Sat, Jun 19, 2010 at 10:23:03AM +0400, Alexander Galanin wrote:
  Потому что умолчательна версия Tk в дебиане --- 8.4. А там как раз
  сломали отрисовку шрифтов (в 8.3 работало, в 8.5 тоже работает).
 
 Оно по жизни так? В etch тоже убого выглядело =)

Потому что в etch tkabber зависел от уже упомянутой tk8.4.
packages.debian.org в свою очередь напоминает, что tk8.5 в etch вообще не
было.

-- 
Alexander Galanin


pgpRzPOOfOhaD.pgp
Description: PGP signature