[убиться тапком] в файловый диалог gtk наконец-то добавили просмотр размера файлов

Ты их разоблачил.

бедные разработчики Гнома

как же они живут, обделенные рюшечками и блестками, так необходимыми каждому программеру

> Только не говори о плазмоидах, я прошу. Ты меня добьёшь %)

Плазмоиды --- кривая концепция. Умри :о)

>> Ну вот что за бред ты несёшь? Ругать кеды --- пожалуйста, но не путём выбирания первого попавшегося факта и извращением его до тошнотворности.
> Да я вот как раз сторонник HIG и минимализма в интерфейсе - то есть по мне все диалоги должны предоставлять только необходимый и достаточный функционал.

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

> Такое ощущение, что разработчики Гнома чем-то обделены. Вроде крутые программеры.

Крутые программисты не тянут отовсюду заведомо проигрышные концепции и не ходят по одним и тем же граблям неограниченное количество раз.

Ну хорошо, просмотр размера файлов добавили. А остальное? Переключение на эскизы или компактный список?

Qt-шный диалог остается самым удобным диалогом открытия файлов.

>Ты их разоблачил.

Ждём признаний =))

>как же они живут, обделенные рюшечками и блестками, так необходимыми каждому программеру

А они здесь причём? Я говорил о пользователях, ибо они пользуют. Да-да, разрабы тоже пользуют, но их меньше, и не факт что своё представление об удобстве они ставят выше представления об удобстве для _пользователя_. Сумбурно немного, но мысль ясна, думаю :)

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

В общем да, в консоли же имя файла передается параметром, а не выбирается в ncurses-диалоге. Но это будет слишком сильно выделяться из мейнстрима, эргономика будет отвратной, к тому же успешной модели интеграции гуёвых приложений типа редактирования файлов прямо в векторном гипертекстовом имаксе я не видел. Ранее таким отяготился MS, и получилось дефективное угробище COM.

>> Только не говори о плазмоидах, я прошу. Ты меня добьёшь %) >Плазмоиды --- кривая концепция. Умри :о)

А я думал ты их проблемой, прямо гвоздём в заднице, называл...

И да, ты меня сразил. Насм^W надолго.

>> Такое ощущение, что разработчики Гнома чем-то обделены. Вроде крутые программеры. >Крутые программисты не тянут отовсюду заведомо проигрышные концепции и не ходят по одним и тем же граблям неограниченное количество раз.

Нужен geek. Нужен кто-то, заявляющий об убогости С++.

> Плазмоиды --- кривая концепция

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

>Только не говори о плазмоидах, я прошу. Ты меня добьёшь %)

А что в утверждении "Весь не-trusted код должен быть в другом адресном пространстве и вызываться через rpc, без исключений даже ради перформанса" тебя добивает?

> Нужен geek. Нужен кто-то, заявляющий об убогости С++.

У нас в теме уже есть absurd, он лучше шарит в убогости C++.

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

Ранее такую концепцию изобрела Майкрософт (ActiveX Controls). Все программы которые имеют такие ActiveX Controls представляют собой рак, медленно убивающий винду.

> Нужен geek.

geek ненужен. (ц)

любите вы концепцию абстрактного Пользователя Неразумного

кому он нужен-то? ещё не хватало на него ориентироваться

> Ранее такую концепцию изобрела Майкрософт (ActiveX Controls). Все программы которые имеют такие ActiveX Controls представляют собой рак, медленно убивающий винду.

При чём тут activex?

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

Вопрос: В кедай есть возможность открыть файл из архива в ЛЮБОЙ проге?

>У нас в теме уже есть absurd, он лучше шарит в убогости C++.

Меня это настойобило, честно. Все что я думаю о С++ я уже сказал ранее. Один постинг в треде, напоминающий tailgunner'у о том что не стоит увлекаться статической типизацией, т.к она мешает декомпозиции программы на независимые модули я могу написать, но на долгий срач у мнея настроения нет.

> Да я вот как раз сторонник HIG и минимализма в интерфейсе...

А дальше можно не читать. HIGозавры нынче толще любого тролля.

>но тем временем ты не против апплетов, которые можно класть на гномовую панель?

Если на каждый апплет по процессу и чтобы они общались через rpc, то не против.

учитивая количество макросов и мусорного кода при программировании интерфейсов на gtk стремления разработчиков гнома выглядят вполне естественными

>Вопрос: В кедай есть возможность открыть файл из архива в ЛЮБОЙ проге?

любители заrar'енной порнушки негодуют?

> Поскольку "мегастабильный" KDE3 был по факту глючен как Daggerfall 1.0,

Ой, ну не надо так толсто. Баги в KDE3 и много, но к благодати баггера только KDE4.0 прикоснулся.

>учитивая количество макросов и мусорного кода при программировании интерфейсов на gtk стремления разработчиков гнома выглядят вполне естественными

Попробуй помедитировать над макросами ATL в твоей любимой Винде.

>> но тем временем ты не против апплетов, которые можно класть на гномовую панель?
> Если на каждый апплет по процессу и чтобы они общались через rpc, то не против.

А теперь подключаем логику. И клизмоиды и гномьи апплеты в подавляющем большнстве - разделяемые библиотеки, которые работают в адресном пространстве процесса, который рисует к примеру панельку с этими апплетами. Так что по логике ты против и клизмоидов, и гномьих апплетов, так? Тогда какие претензии конкретно к KDE? Это одна сторона вопроса.

Вторая сторона: какое отношение имеют детали реализации к самой идее плазмоидов?

>> Плазмоиды --- кривая концепция

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

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

Насчёт виджетов, которые можно впихнуть куда угодно: давно есть средства, позволяющие впихнуть окно одной программы в нужное место окна другой программы. При разных адресных пространствах. Именно так и работают древние fvwmbuttons или заембедденый в окно mplayer.

> А теперь подключаем логику. И клизмоиды и гномьи апплеты в подавляющем большнстве - разделяемые библиотеки, которые работают в адресном пространстве процесса, который рисует к примеру панельку с этими апплетами. Так что по логике ты против и клизмоидов, и гномьих апплетов, так? Тогда какие претензии конкретно к KDE? Это одна сторона вопроса.

Это проблема и гнома. Между кедами и гномом много общего. Например, то, что они говно :)

> Вторая сторона: какое отношение имеют детали реализации к самой идее плазмоидов?

Без этих деталей ничего в клизмоидах нового и уникального нет.

> Вопрос: В кедай есть возможность открыть файл из архива в ЛЮБОЙ проге?

Кеды магическим образом запрещают использовать archivemount, rarfs или avfs?

Значит по существу возражений нет и ты признаешь ущербность gtk? "Как долго я тебя лечил!" =)

> Вопрос: В кедай есть возможность открыть файл из архива в ЛЮБОЙ проге?

Только что для теста запаковал flac в tar.gz и открыл оттуда в mplayer'е. Так что да, можно. Но судя по всему fuse для этого пока не используется.

> давно есть средства, позволяющие впихнуть окно одной программы в нужное место окна другой программы.

Не посоветуешь толковый мануал о том, как это можно сделать? Лучше именно мануал, а не пример программы.

>Значит по существу возражений нет и ты признаешь ущербность gtk? "Как долго я тебя лечил!" =)

ATL между прочим написана на "кошерном" С++. Только switch к таблицей вида метка->обработчик кошерным, типово-безопасным плюсатым темплейтом почему-то нельзя. Вот незадача.

>> давно есть средства, позволяющие впихнуть окно одной программы в нужное место окна другой программы.
> Не посоветуешь толковый мануал о том, как это можно сделать? Лучше именно мануал, а не пример программы.

Честно говоря, мануалов не видел.
Если использовать Tk, то на одной стороне делаешь frame с опцией -container true, а на другой -- toplevel с -use ${id-шник фрейма на другой стороне}. Вроде всё.

Пример (хоть ты его и не просил :) ):
server:
% package require Tk
% pack [ frame .f -container true ]
% winfo id .f
0x3c0010a

client:
% package require Tk
% wm withdraw .
% toplevel .t -use 0x3c0010a
% pack [ button .t.b -text test ]

>Не посоветуешь толковый мануал о том, как это можно сделать? Лучше именно мануал, а не пример программы.

http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html

http://library.gnome.org/devel/gtk/unstable/GtkSocket.html

http://library.gnome.org/devel/gtk/unstable/GtkPlug.html

> Концепция чужого кода в своём адресном пространстве крива. Потому что так сложнее выделять сбойные места. А с общим адресным пространством надёжность программы ниже, чем надёжность самого её ненадёжного компонента.

Это я согласен. Только вот среди GUI-программ лично я ещё не видел чтобы подобное было реализовано не через жопу.

> заембедденый в окно mplayer

От всех попыток заэмбеддить куда-либо mplayer тянет поблевать. А после просмотра исходников меня наизнанку выворачивает моментально.

Какое мне вообще дело до ATL? Сам возись с ним, если заняться больше нечем.

>> Концепция чужого кода в своём адресном пространстве крива. Потому что так сложнее выделять сбойные места. А с общим адресным пространством надёжность программы ниже, чем надёжность самого её ненадёжного компонента.
> Это я согласен. Только вот среди GUI-программ лично я ещё не видел чтобы подобное было реализовано не через жопу.

А много ты видел вообще gui-программ, реализованных не через жопу? :)

>> заембедденый в окно mplayer
> От всех попыток заэмбеддить куда-либо mplayer тянет поблевать. А после просмотра исходников меня наизнанку выворачивает моментально.

Сильный аргумент в технической дискуссии.

> А много ты видел вообще gui-программ, реализованных не через жопу? :)

=)

> Сильный аргумент в технической дискуссии.

Да, это уже были просто эмоции. Тема то всё-таки в talks, а не в development 8).

> Если использовать Tk, то на одной стороне делаешь frame с опцией -container true, а на другой -- toplevel с -use ${id-шник фрейма на другой стороне}. Вроде всё.

Работает, кстати, не только tk-tk, но и с другими тулкитами.
Например, я встроил тот самый mplayer с порнушкой с помощью опции -wid.

А вот gvim-gtk присоединить не получилось. Видимо, этот gtkplug всё же несовместимый велосипед.

>Какое мне вообще дело до ATL? Сам возись с ним, если заняться больше нечем.

Важен сам принцип, что С++ не представляет никаких годных средств для минимизации boilerplate-кусков, так характерных для гуевого кода.

>Важен сам принцип, что С++ не представляет никаких годных средств для минимизации boilerplate-кусков, так характерных для гуевого кода.

не знаю что это такое, но gtk гораздо хуже

> Важен сам принцип, что С++ не представляет никаких годных средств для минимизации boilerplate-кусков, так характерных для гуевого кода.

А кто их предоставляет? Проблема построения gui является убийственной для подавляющего большинства языков. Даже в божественном лиспе своей gui-библиотеки нет.

>>Важен сам принцип, что С++ не представляет никаких годных средств для минимизации boilerplate-кусков, так характерных для гуевого кода.

>не знаю что это такое, но gtk гораздо хуже

Это кем надо быть чтобы ниасилить тупой как пробка C API.

>> не знаю что это такое, но gtk гораздо хуже
> Это кем надо быть чтобы ниасилить тупой как пробка C API.

Лентяем?

К слову, за одну только несовместимость gtk/glib event loop со стандартным юниксовым select/poll надо оторвать буйну головушку авторам и засунуть её туда, откуда у них растут руки.

> Можно вопрос: какую смысловую нагрузку имеет размер файла? С появлением UTF-8 она даже о количестве символов в текстовом файле сказать ничего не может.

Такой вариант например:

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

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

> мне нужно проверить изменения на сайте. Изменения заключались изменении максимального размера загружаемого файла. У меня есть каталог с тестовыми файлами. Что бы долго не возиться, было бы очень удобно видеть размер файла и желательно сортировать по размеру.

Ты ещё не весь палец высосал? :) В таких случаях просто делается либо скрипт для загрузки по HTTP, либо уж на худой конец файлы именуются типа 10kbfile, 100mbfile, 300mbfile.

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

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

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

>>кстати, вот мы все спорим какой файловый диалог круче - кутешный или гткшный и совсем забыли об оном в тикле ;) Он там вообще есть? Превьюшки показывает? А адресная строка есть?

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

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

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

Попытку ухода от темы это не оправдявает.