[плача тред] Задолбался с этим вашим windows way-ем.

Сложно сказать, насколько это жизненно. Может и взлетит.

печально вот что: мне такая утилита не особо нужна

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

Тебе придётся научить их встраиваться в исходное окно. Потому что переключение режимов иначе не взлетит.

Но дело даже не в том. Согласен, я в стартовом посте одним пунктом захватил 2 совершенно разных задачи. Разделим из:

1. Просмотрщик text-like данных, который я описал в предыдущем комментарии.

2. Утилита для показа одного файла в разных просмотрщиках с переключением между ними.

херню какую-то нагородил
нахера диалог копирования вне фм?
морда к find - те, кто разберётся с ним осилит и его использование в консольке, где он и должен быть
да и в миллионе фм есть свои поисковики, даже с grep-ом встроенным
ах да - тебе никто ничего не должен - пили сам
смотрю на тебя и думаю - что ты курил?

Проходи мимо, по четвергам не подаю.

Тебе придётся научить их встраиваться в исходное окно. Потому что переключение режимов иначе не взлетит.

xembed

да ты точно упоролся
пробуй выдохнуть опять

Вот что xembed? Ты думаешь, стоит только произнести xembed, и код напишется сам?

нет, я просто говорю, что это вполне реализуемо, при желании

Я в курсе.

Бугага! Написать графический аналог cp на bash — дело нескольких минут! А мужики-то не знают! Сходи покури сорцы coreutils.

Зачем там сорцы coreutils? Есть же всякие zenity и прочая фигня — find получает список файлов, потом в цикле проверяются на существование целевые файлы в цикле, если не существует — копируется, если существует, выводится диалог «заменить / переименовать / оставить / etc» — пока вывод find не кончится.

в полноценных ОС есть консоль, которая умеет делать то же самое, но лучше.

И следом еще сходи-ка читкани юниксвейца.

Ты не согласен, что команда stat лучше диалога properties? Между прочим, при желании, на каком-нибудь xdialog или его аналоге вполне можно вывести результат выполнения команды stat в виде иксового окошка

Так что твоя агрессия тут куда-то не туда идёт.

Если на все вопросы отвечать «зачем? это не нужно», то он и к консоли окажется «слабо применим». Давай попробуем:

«sed? зачем? есть vim!»

Зачем графический мусор, если уже есть консоль? Следует развивать консоль, а графику прикручивать можно и нужно только там, где она действительно нужна — это в графических редакторах, браузерах и видеоплеерах.

А mc не нужен, потому что уже есть консоль с coreutils и прочим, которая может делать то же самое, но удобней и проще.

А насчёт Vim я бы сказал наоборот — зачем vim если уже есть ed и sed?

Зачем там сорцы coreutils? Есть же всякие zenity и прочая фигня — find получает список файлов, потом в цикле проверяются на существование целевые файлы в цикле, если не существует — копируется, если существует, выводится диалог «заменить / переименовать / оставить / etc» — пока вывод find не кончится.

Я смотрю, ты специалист по строительству кривых домов с дырявой крышей.

Ты не согласен, что команда stat лучше диалога properties?

А ты не согласен, что микроскоп лучше молотка?

Между прочим, при желании, на каком-нибудь xdialog или его аналоге вполне можно вывести результат выполнения команды stat в виде иксового окошка

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

man сарказм

тёлочка поди попросила?

муж мамы, ок

мантру «эта ваша винда» бубнил с умным видом, лихо цыркая при этом зубом?

nie

2. Какое есть приложение для отображения диалога «Свойства файлов» а ля аналогичные диалоги из наутилус/тунар/pcmanfm? (Нет такого приложения)

А вам нужна ЕЩЕ ОДНА?? Имхо, не имеет особого смысла без DE.

3. Какая есть утилита, аналогичная диалогу копирования/перемещения файлов из двухпанельных ФМ. С умными вопросами типа «файл уже существует, заменить/пропустить/переименовать?»

Опять не понял, зачем плодить сущности, и почему нельзя использовать уже существующие? Не хочется иметь ради утилиты всё остальное DE? Умные вопросы в диалогах копирования уже давно есть, нужны еще более умные? Можно выпилить из mc всё ненужное, в конце концов, будет утилита, только вопрос: зачем?

4. Какая есть утилита — универсальный вьюер файлов. С переключением режимов текст/hex-дамп/html/картинко и т.п. С поддержкой кодировок. С поддержкой файлов произвольного размера. С поддержкой плагинов. (Нет такой утилиты.)

Вам юниксвей или утилиту?

5. Какая есть утилита графический фронт-энд для find? (Нет такой утилиты. catfish убог чуть более, чем совсем. Уже подумываю о том, чтобы запилить собственную на Ruby и назвать dogfish.)

ггг, xterm, не? ))

Вам юниксвей или утилиту?

Мне гибкость, простоту и возможности. То, чем славен юникс. Был.

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

Ответ такой — тем кто пользуется интегрированными графическими средами такая модульность не нужна, поскольку из консоли запустить chmod проще чем properties, таким образом в консоли они будут пользоваться именно консольными средствами, а в гуе они будут пользоваться файловым менеджером, в котором перечисленный функционал уже есть (konqueror тут рулит)

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

Или ты скажешь, что я не так понял тему опять?

Я думал над этим вопросом модульности и понял, что он есть, просто модули собираются в приложения не динамически в процессе исполнения, они собираются вместе на этапе разработки, таким образом ответ для тебя — это Qt Creator, с помощью которого ты можешь скомбинировать нужные тебе виджеты так как угодно тебе.

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

Мне гибкость, простоту и возможности. То, чем славен юникс. Был.

Юникс таким был, но его архитектура была малоприспособлена к сетям, просто мейнфрейм и куча терминалов к нему — а не большое количество машин с полноценными ОС на каждом.

После чего гибкость, простота и возможности юникса в основном остались — посмотри на те же OpenBSD, да и ту часть GNU/Linux, которая работает без иксов.

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

И собственно есть Plan9, PlanB, Inferno, Octopus. Кстати, Inferno работает поверх GNU/Linux, можешь попробовать.

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

Жесть. Засранность мозгов у пользователей достигла той степени, когда задачи типа «копирование файлов» и «поиск файлов» спокойно воспринимаются как «части программы». Позволь полюбопытствовать: какой именно программы? Программа должна решать одну задачу и решать её хорошо. Какую задачу решает ФМ? Да он решает пару десятков задач. И большую часть из них он решает плохо.

Почему cp, stat и find — это нормально, а то же самое в графике — это несамостоятельные «части»?

Ответ такой — тем кто пользуется интегрированными графическими средами такая модульность не нужна

В данном случае стоит воспринимать «не нужна» как типичный лоровский мем, потому что реальность прямо противоположна. Модульность нужна не только пользователю, но и, в первую очередь, тем, кто пишет указанный сфот. Потому что невозможно в одной гигантской программе угодить всем, всегда, и предусмотреть все use cases. Если какая-то часть конгломерата, называемого «файловый менеджер» не устраивает пользователя, она должна быть легко заменима. Заменима на уровне «поправил строчку в конфиге». А если разработчик решил улучшить какую-либо утилиту (читай: «часть программы», если на твоем языке), эта утилита должна встроиться в среду без лишнего геморроя. На уровне правки строчки в том же самом конфиге, ага.

Поэтому никаких:

таким образом ответ для тебя — это Qt Creator

быть не может. Это всё равно что, брать в руки компилятор каждый раз, когда мне надо сделать blabla | grep ... | awk ...

И «любители минимализма» тут ни при чем.

Всё, что я тут пишу, должно быть очевидно любому программисту, если он действительно программист, а не результат скрешивания школьника с самоучителем «PHP для чайников». Впрочем, я никого не обвиняю. Я просто пытаюсь понять, как десктоп линукса докатился до того, до чего он докатился.

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

Современные DE — это вообще полный бред. Монолитные куски говна, в которые местами засунуты палки поддержки немногих стандартов fd.o, чтобы оно хоть как-то могло взаимодействовать со внешним миром.

Какое счастье, что хотя бы спецификация NETWM успела родиться раньше, чем всё скатилось в говно.

Потому что невозможно в одной гигантской программе угодить всем, всегда, и предусмотреть все use cases. Если какая-то часть конгломерата, называемого «файловый менеджер» не устраивает пользователя, она должна быть легко заменима. Заменима на уровне «поправил строчку в конфиге». А если разработчик решил улучшить какую-либо утилиту (читай: «часть программы», если на твоем языке), эта утилита должна встроиться в среду без лишнего геморроя. На уровне правки строчки в том же самом конфиге, ага.

вспомнилась вот эта статья Витуса:

http://vitus.wagner.pp.ru/articles/true_unix_gui_2_0.html

особенно пункт про архитектуру

Невозможно взять и — хоп — написать омг-файловый-менеджер с нуля. На это придётся потратить просто дохера времени и ресурсов.

А если для этого достаточно кинуть на форму пару компонентов и связать их прослойками в пару строчек кода?

Это всё равно что, брать в руки компилятор каждый раз, когда мне надо сделать blabla | grep ... | awk ...

А ты и берёшь в руки... только не компилятор, а интерпретатор. Насколько я знаю, GUI-приложения пишутся и на всяких питонах и tcl/tk

Почему cp, stat и find — это нормально, а то же самое в графике — это несамостоятельные «части»?

Вероятно, дело в том, что если у человека достаточно мозгов для того что бы использовать связки из find, xargs, grep, etc, то ему не нужна возможность делать то же самое в GUI, а если недостаточно, то

Заменима на уровне «поправил строчку в конфиге»

Он всё равно не осилит заменить строчку в конфиге.

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

Витус крут, да.

А если для этого достаточно кинуть на форму пару компонентов и связать их прослойками в пару строчек кода?

Чего-чего? Кинуть на форму? Ба, да ты упорот.

А ты и берёшь в руки... только не компилятор, а интерпретатор. Насколько я знаю, GUI-приложения пишутся и на всяких питонах и tcl/tk

И что мне делать этим интерпретатором, пальмы околачивать? Утилиты для решения задач в GUI отсутствуют. Или ты мне предлагаешь сначала их всех написать?

Вероятно, дело в том, что если у человека достаточно мозгов для того что бы использовать связки из find, xargs, grep, etc, то ему не нужна возможность делать то же самое в GUI, а если недостаточно, то

Заменима на уровне «поправил строчку в конфиге»

Он всё равно не осилит заменить строчку в конфиге.

Гораздо более вероятно, что ты просто упорот. Бред про qt-креатора, формы, навязчивые состояния — всё сходится.

Собственно, а ты с какова раёна^[4^W вообще кто? Программист? Инженер? Ну так, чтобы оценить: ты просто не в теме или действительно упорот?

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

Вот я и говорю, как хорошо, что спецификации на управление окнами родились раньше, чем гуем линукса стали заниматься такие умные люди, как ты. Твои вопросы бьют не в бровь, а прямо в глаз. Ну вот скажи мне, где, кроме оконного менеджера и панели, встречается необходимость управлять окнами? Да к черту эту спецификацию, понапридумывали сложностей! Захардкодим прямо в тулкит. Тем более, вон и вейланд на подходе.

ты просто не в теме или действительно упорот?

Могу сказать, что GUI-приложений сложней калькулятора не писал, если тебе это чем-то поможет.

Однако же ты не ответил на прямо заданные вопросы — где например могут потребоваться эти самые свойства файла кроме файлового менеджера?

Плюс ещё один вопрос — если человек достаточно умён что бы пользоваться консольным find, нафига ему нужен GUI-фронтенд?

Утилиты для решения задач в GUI отсутствуют. Или ты мне предлагаешь сначала их всех написать?

Если они действительно отсутствуют и нужны (в чём я сомневаюсь, но ты, похоже, нет), то да, предлагаю написать.

Кинуть на форму? Ба, да ты упорот.

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

Кроме того я знаю что в Qt и GTK готовые виджеты есть практически для всего, например vte для эмуляторов терминала. Следовательно что бы написать файловый менеджер, нужно относительно немного усилий — накидать на форму элементов управления и компонентов, несколькими строчками кода описать их взаимодействие и всё.

И что, где я не прав?

читал-читал я тред и понял: то, что ты предлагаешь - это же офигенно круто! Поправь, если я не прав, но я это представляю себе примерно как конфиг awesome, только масштабнее и собираем так любую программу. Я это ХОТЕТ!

Однако же ты не ответил на прямо заданные вопросы — где например могут потребоваться эти самые свойства файла кроме файлового менеджера?

А где тебе может понадобится stat, кроме sh-а? Давай встроим stat прямо в sh? Прежде чем говорить, что я опять не ответил, подумай.

Плюс ещё один вопрос — если человек достаточно умён что бы пользоваться консольным find, нафига ему нужен GUI-фронтенд?

А ты достаточно умён, чтобы понимать, что умение пользоваться find не является показателем ума? Равно как и не являются показателем его отсутствия твои орфографические и пунктуационные ошибки, хотя какой-нибудь другой абстрактный «Xenius» мог бы и так подумать.

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

GUI-приложений сложней калькулятора не писал

Оно и видно.

Кроме того я знаю что в Qt и GTK готовые виджеты есть практически для всего, например vte для эмуляторов терминала. Следовательно что бы написать файловый менеджер, нужно относительно немного усилий — накидать на форму элементов управления и компонентов, несколькими строчками кода описать их взаимодействие и всё.

Давай ты откроишь исходники какого-нибудь ФМ... например, этого: http://git.bzatek.net/tuxcmd/tree . Или этого: http://git.xfce.org/xfce/thunar/tree/ . И затем расскажешь его разработчикам, что они всё делают неправильно. Достаточно было накидать элементов на форму в кутекреаторе!11 Окей?

И что, где я не прав?

Ты везде не прав. Читать лекцию о разработке ПО, уж извини, не буду.

дай попробую ответить.

где например могут потребоваться эти самые свойства файла кроме файлового менеджера?

Я хочу свойства из дельфина в thunar`е например. Суть, как я понимаю - делать программу как обзязку для нескольких простейших программ. А для этого из этих программ должны торчать входы и выходы, чтобы их можно было между собой связывать. И походу тут нужен интерпретатор, а не компилятор.

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

Такие штуки уже описывались, например:

[post UNIX?] [когда будет?] Универсальный интерфейс-конструктор — я

<лень искать ссылку> — geekless

http://vitus.wagner.pp.ru/articles/true_unix_gui.html — Витус Вагнер

Но это почему-то то ли никто так и не сделал, то ли почти никто не пользуется. Странно, да?

Собственно, раз ты откопал тот свой тред, процитирую себя оттуда:

> Универсальный интерфейс-конструктор. когда будет?

Никогда. Почитай ЛОР — все ссут кипятком при выходе очередного костыля и высирают кирпичи, когда предлагается что-нибудь действительно улучшить, сделать логичнее, устранить лишние сущности.

Интерфейс-конструктор будет не понятен ни быдлоюзерам, ни быдоадминам, ни быдлопрограммистам.

95%. Ибо.

не знаю, странно или нет.

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

С другой, «tue unix gui» - это ведь здравая мысль, уверен, что нравиться она должна не только спорящим здесь и Витусу Вагнеру, мог бы и заняться кто-нибудь из влиятельных в сообществе организаций.

Такие дела.

Давай встроим stat прямо в sh?

stat слишком редко нужен, а вот echo, seq (в форме echo {1..10} ), ls (в форме echo *) почему-то в bash таки встроили. Как думаешь, почему?
Ведь seq, `ls` и тд существуют и в виде отдельных приложений.

А ты достаточно умён, чтобы понимать, что умение пользоваться find не является показателем ума?

Просто пользоваться в формате find . -name '*...*' где всё кроме трёх точек заучено наизусть — не является. А вот умение его использовать полноценно, включая возможность связки через exec — всё-таки является.

твои орфографические и пунктуационные ошибки

И чего ты их сюда приплетаешь?

И вообще, ты сам говорил:

Интерфейс-конструктор будет не понятен ни быдлоюзерам, ни быдоадминам, ни быдлопрограммистам.

95%. Ибо.

А когда я тебе повторяю твой же аргумент, ты заявляешь, что я упорот. Где логика?

Но это почему-то то ли никто так и не сделал, то ли почти никто не пользуется. Странно, да?

Моя цитата оттуда в тему, ага.

А вот ты в данный момент чем занимаешься в этом треде? Еще тут даже никто и не предложил (ни я, ни кто либо другой), мол давайте что-то сделаем. А просто спросил: «почему существующие решения неоптимальны?» Как тут же прибежала туча «защитников» доказывать, что решения оптимальны, а ТС на самом деле придурок, не осилил mc/консоль/kde/пусть_валит_на_шиндошс/подставь_нужное. И ты в их числе, «защитников», да.

А начинается всё с малого. Неужели не очевидно то, что написал S-Mage: «Я хочу свойства из дельфина в thunar`е например»? Я ждал просветления с твоей стороны после намёка на NETWM, на вейланд, на stat в sh... но нет, ты меня всё так же спрашиваешь «зачем». Вот именно за этим. Вернее: в том числе и за этим. И за многим другим. В правильном «конструкторе» из этих кубиков можно сложить дом.

Ну так вот, я отвлёкся, о чем бишь я... Всё начинается с малого. Сегодня кто-то вынес диалог свойств файла в отдельный бинарник. Завтра кто-то написал обёртку для find. Послезавтра еще кто-то сказал «а давайте стандартизируем ключи запуска для ФМ» и притащил 3 патча под популярные ФМы. Если по дороге не идти, никуда не придёшь.

Так вот я хочу спросить:

Где все эти люди?

dogfish, говоришь? что за беда, создавай проект на github (или где-то еще), помогу чем смогу.

А когда я тебе повторяю твой же аргумент, ты заявляешь, что я упорот. Где логика?

Ты не повторяешь мой аргумент. Qt-креатор — это не «интерфейс-конструктор». Это не более чем вспомогательный инструмент рисовать морду к ПО (еще и применимый только в специфических случаях), и на саму программу результат его работы походит не больше, чем набросок дизайна в гимпе — на реальный сайт.

И ты в их числе, «защитников», да.

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

Кроме того, предложенные тобой пункты действительно ненужные, кроме 1 и 4, но 1 уже есть в лице xdg-mime, а 4 есть... в лице например firefox и konqueror — это как раз и есть универсальный вьюер. Правда в фирефоксе нет двоичного вида, но в конке 3.5 точно был.

Ты не повторяешь мой аргумент.

Повторяю:

Вероятно, дело в том, что если у человека достаточно мозгов для того что бы использовать связки из find, xargs, grep, etc, то ему не нужна возможность делать то же самое в GUI, а если недостаточно, то он всё равно не осилит заменить строчку в конфиге.

Это именно и есть аргумент на тему, что 95% не осилят, а тем кто осилит не нужны фронтенды для консольных команд.

Долго читал тред, и сначал не мог понять, почему unix-way в гуе применим, и в чём его польза вообще.
Затем вспомнил, зачем создавались структуры, классы, паттерны проектирования и т.д. Ведь получается, что приложение - более высокоуровневая сущность, чем класс тот же, и к нему применимы(и применяются) принципы инкапсуляции и наследования, но вот наследования я нигде на наблюдал.
Я так понял unix-way - вместо того, чтобы программировать, использовать уже готовое, более высокоуровневое, посредством заданных и общеизвестных интерфейсов.
И также я понял то, о чём говоришь ты, перейти с уровня программирования, на уровень собирания приложений
Также теперь понял твою тему насчёт ключей для запуска ФМ.
Поток сознания какой-то осводился. ^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W^W Откопаю ка твою тему насчёт ФМ, и покопаюсь в них.

а 4 есть... в лице например firefox и konqueror — это как раз и есть универсальный вьюер

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

сюда ее положи пажалста, мне тоже интересно.

это?

dogfish, говоришь? что за беда, создавай проект на github (или где-то еще), помогу чем смогу.

Черт знает, может и выложу. Запускать-останавливать find, собирать из него данные и писать в строке статуса «Идет поиск в каталоге таком-то» оно уже умеет, по крайней мере.

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

Наверное, ты про это:

Её главные требования — мгновенно открываться, просматривать файлы любой длины, корректно обрабатывать «неожиданные» для текстового потока символы («\0»), на лету переключать кодировки, уметь hex-режим, выделять-копировать текст. А, ну и еще: всё операции должны быть на хоткеях.

Konqueror 3.5 всё это умел, я точно помню.

Ты конечно можешь придраться к тому, что он умел не только это, а ещё дофига всего, но по-моему «лишний» функционал в не всегда вреден (в частности, уже упомянутые echo прямо в bash и {1..10} в нём же — особого вреда от их наличия я не вижу. В конце концов, unix way и прочие высокие слова — это не самоцель, а лишь принципы, которые по идее помогут достичь целей).

уже неплохо. выкладывай.

возьмете ни разу не умеющего ни руби, ни вообще что-либо серьезное студента на обучение? Для начала можно хотя бы книжки, которые надо прочитать?

https://github.com/geekless/dogfish

О_О

сам в шоке. ну ладно, я ерунду спорол, посоветуй чего-нибудь на почитать, я пока помогать не способен.

Ну лично я по сабжу кроме манов, справочников API и спецификаций ничего не читаю. А надо? :)

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

фиг знает, надо или нет, я по книжке только c++ учил(привет, универ, в котором дают дельфи). Ну хорошо, маны и API так маны и API. Надо начинать быть Ъ, большой уже.

Вообще-то тред про линукс.

Перечитал ещё раз. Похоже что да, но замаскировал успешно :) После первого прочтения я был уверен, что тебе по служебной необходимости приходится сидеть на винде и это «радости тред»