Вопрос к автору новости, как знатоку KDE и GNOME: а в KDE такое возможно, я имею ввиду не является ли ущербной технология KParts?

Хотя думаю там есть какой-нибудь маршалинг ... в CORBA.

Не что ж, первая ласточка :) Пока кривовато, судя по описанию, но... Я надеюсь, что в скором времени мы получим дейсвительно модульную архитектуру приложений по *NIX.

Надеюсь, что скоро я легко смогу взять mail компонент Evolution и вставить его в свою программу, не заморачиваясь написанием очередношо недо- MUA, коих и так слишком много...

2BaT: Это уже не первая ласточка, KDE давно в этом преуспел ;-)

Да уж, первая ласточка. Теперь даешь gnome-sh, gnome-cat, gnome-awk... Вместо того, чтобы сделать системно прозрачное интегрирование данных в файловую систему, началась компиляция устоявшегося софта с левыми либами.

   Вопрос  к  автору  новости,  как  знатоку  KDE  и GNOME: а в KDE такое
   возможно, я имею ввиду не является ли ущербной технология KParts?

   Хотя думаю там есть какой-нибудь маршалинг ... в CORBA.
Я плохо знаю внутренности KDE. Вроде поверх Corba KParts может бегать.
Как раз мне бы тоже хотелось задать след. вопросы людям, знающим внутренности
KDE:
1) используется ли IDL-подобный язык для описания програмного интерфейса
компонентов (в гноме - да)
2) Как легко можно писать компоненты на языках, отличных от С/С++? Для гнома -
тривиально ибо интерфейс описывается на IDL, и для каждого языка есть генераторы
врапперов.
3) Есть ли репозитарий компонентов - то есть DB, позволяющая по имени
интерфейса (например GtkHTMLEditor) активитировать компонент? В гноме - да.
   Да уж, первая ласточка. Теперь даешь gnome-sh, gnome-cat, gnome-awk...
   Вместо того, чтобы сделать системно прозрачное интегрирование данных в
   файловую  систему,  началась  компиляция  устоявшегося  софта с левыми
   либами.
Чушь какая-то. Никаких gnome-{cat,sh,awk} не будет.

Ты анонимус круто загнул. Сейчас интеграция в файлуху это либо Hurd
- для использования сейчас АБСОЛЮТНО не пригодный. И имеющий
проблемы дизайна в области своей микроядерности. Или
namesys fs , storage layer которого всем извесный reiser. Только
reiser fs все видели а libnamesys только у Ганса в секретном
CVS'е для коммерческих проектов :-) Вот так вот.


Грубо говоря МЫ ВСЕ ЗАЕБЕМСЯ делать то что ты предложил. Вот.

Не согласен. Создание файла в /proc - это как hello.c в lkhg. Так что надо лишь оттунеллить open, close, read, write и seek в юзерспейс. И сделать набор ф-ций для end-программера - чтобы можно было, допустим, предствлять кусок памяти как регулярный файл, а поток данных как пайп. И все. Технически это выглядит как в /proc/<pid> две директории - одна для управления, другая для клиентов. Программа, допустим, создает файл /proc/<pid>/trans-rule/data, а клиента (vim тот же) натравливает на /proc/<pid>/trans-data/data.

На все это надо 1 человек-месяц. До демонстрации работы. Если б мне по работе это надо было, я бы это сделал.

Вот вот "Если б мне по работе это надо было". Это мы все рассуждать
горазды.
Это ведь ПО РАБОТЕ никому не надо(исследователей ОС не в счет).
Так как вы предлагаете
несколько поменять концепцию программирования.
Работа же, состоит в зарабатывании бабок, а их зарабатывают
используя существующие концепции и интерфейсы.

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

Более того - надо еще долго и упорно разбиратся КАКОЙ ИМЕННО
должен быть этот интерфейс. А это действительно крупная проблема.
И в каком месте его должен использовать прикладной программист.

Просто если попробавать порешать с помощью этого интерфейса
типичные задачи - дофига всего вылезет.
А этого можно добится только годами труда либо за бабки
либо для удовольствия. То есть: Пишем модуль к ядру.
Пишим несколько прог - клиентов. Дописываем модуль. Еще пишем
клиентов , итд. Пока на этом интерфейса хуйня размером
с gnome крутится не будет , ничего про то какой должен быть
этот интерфейс сказать нельзя.

И кстати недавно, в очередной раз кто-то слабал
патч к 2.4.* Который делает fs в userspace.
То есть роутит не только open, close, read, write и seek
но и всяческие readdir.
Но таких патчей уже дофига сделали а результат :-(

пара ответов
- да, в kde это возможно, там очень грамотная компонентная модель

- перекинуть вызовы open, read, etc в userspace - раз плюнуть
(сам писал) в частности aufofs, coda прмерно так и сделаны, правда там кернел кое-что делает, прежде чем передать управление в userspace

также вспомните userfs (хотя ненужная в общем-то вещь)

Еще раз повторюсь - вызовы перекинуть просто. А речь идет об УНИВЕРСАЛЬНОМ и УДОБНОМ API

не знаю насколько язные и удобные API в OS/400, но люди которые "сильно подсели на IBM Solution", гворят что очень нехило все придумано. Если кто не знает, там понятия "файловая система" вообще нет (в смысле для прикладного программера), все представлено в виде базы данных. И нет различий данные в ОЗУ или на диске, и если на диске то гда имеено. Все расслоено и спрятано за всякого уровня API.

Опят-же, где-то пролетало, что Ганс считает такой подход самым правильным.

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

возвращаясь к топику новости - vim в качесве компонента это классно. Теперь еще нужно [x]emacs так-же "запихать в компонент". Так скзаать, дял полноты ;)

   пара ответов
   - да, в kde это возможно, там очень грамотная компонентная модель
Что "это"? Использорвать corba? Или все остальное тоже? Доступно ли оно
уже сейчас или просто "возможно"?
  А всякие хаки с /proc - никому не нужны. Нужна возможность не
передавать данные, а вызвыать ф-ии, framework нужен нормальный и
network transparent. Транспортный уровень (чем яв-ся хак с /proc) - это 1%
от того , что нужно для компонентной архитектуры.

конечно существует, и все ей давно пользуются
люди сначала думали над удобным фреймворком, а потом уже начали приложения клепать
почитай статьи по архитектуре на http://developer.kde.org/, там их десятки

в частности про kparts

   конечно существует, и все ей давно пользуются
   люди  сначала  думали  над  удобным  фреймворком,  а  потом уже начали
   приложения клепать
   почитай  статьи  по  архитектуре  на http://developer.kde.org/, там их
   десятки
   в частности про kparts
Ты яснее (однозначней) можешь говорить?
  Сейчас я честно прошерстил все файлы пакетов от KDE2.0.1, не нашел
ни одного файла похожего по синтаксису на IDL. Искал честно, смотря
все файлы кроме тех, что с расширениями .cpp .cc .h .am, в сырцах
kdebase kdelibs koffice kivio. Как я понял, KParts - базовый класс,
который совместно с архитектурой поддержки KParts в приложениях
позволяет об[екту-потомку KParts рисоваться в окне, добавлять свои меню и
тулбар исконс в приложение, котороы ты редактируешь (ну и печататься/
сохраняться/грузится). ВСЕ! Никакой низкоуровневой функциональности от него
не добиться (то есть прямо использовать его функции из любого языка,
например менять свойства диаграм, добавлять новые серии в kchart).
А в гноме каждый порядочный компонент дает юзать его функциональность
из любого языка посредством предоставления доступа к свойствам
и методам через Corba (и описанных на IDL). См. /usr/share/idl и
/etc/CORBA/servers. Соответственно можно подставить свою реализацию
интерфейса, и все приложения ничего не заметят, и все будет работать.
Что и продемонстрировано на примере vim+evo. C KDE это просто не возможно
так как ни одно из базовых приложений (koffice, kivio) не разделено на
независимые компоненты.
   Кошмар, я о KDE-шниках был более хорошего мнения. Теперь они в моих
глазах - просто никто.
   А ты, анонимус, гони поменьше и сам почаще читай developer.kde.org и сырцы.

ну да нету там idl
а почему всё дожно быть corba based?
может быть vi был написан как corba server?

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

судя по по матюкам ты сам ничего не читал

насчёт почаще читай не понял - знания зависят от частоты чтения? а может быть всё таки от количества прочитанного и восприятого?

есть Corba based но это KOM, а не KParts

   ну да нету там idl
   а почему всё дожно быть corba based?
Потому что корба-промышленный стандарт. Но это мелочи. Главное - все
делать в виде компонентов, экспортирующих свойства и методы для предоставления
ВСЕЙ функциональности компонента, с БД отображающей сервис->информация-для-активации
(из какой либы или из какого процесса), с описанием интерфейса (методов
и свойств) на мета-языке описания интерфейса. Это даст возможность
1) писать и юзать компоненты на любом языке программирования
2) подменять компоненты другими, с тем же интерфейсом.
   в  тех же статьях расказывается почему они вовремя отказались от корбы
   - корба для десктопа сущее проклятие, по их словам
   судя по по матюкам ты сам ничего не читал
 Читать отмазки, причем написанные несколько лет назад (когда техника была не
такая мощная) - дело неблагодарное. Да и при хорошем ORB вызовы методов
компонента, активированного на локальной машине, по стоимости эквивалентны
вызовом виртуальных методов в C++. В гноме именно такой ORB используется.
Так что тормозов не будет.
 А прикрутить xemacs должно быть тоже тривиально (небольшой модификацией связки
для vim).
2RM: а сейчас KOM есть в KDE2.2? Что-нить его использует?

вот напреимер статейка, демонстрируящая идеологию (так же вкратце там есть "отмазки", почему kde не использует corba) http://klotski.berlios.de/kde/kpart-techno/kpart-techno.html

цитата:

KPart is based on Shared Libraries. This makes the component appears directly as a C++ object. There is no need to wrap its features with an IDL language, everything is accessible without extra effort.

нотя подозреваю товарищу hvv это всё равно не понравится :)

Я первый анонимус - последний пост про /proc

2hvv - не надо выдумывать никакой новой концепции. Она уже выдумана 30 лет назад. Просто не следует усложнять, по-моему.

В конце концов, если нужна переносимость - сделать как nfs-сервер.

Вот именно, C++-only solution. За такое надо мочить в сортире.

to hvv:
> Да и при хорошем ORB вызовы методов компонента, активированного на > локальной машине, по стоимости эквивалентны вызовом виртуальных
> методов в C++. В гноме именно такой ORB используется. Так
> что тормозов не будет.

ну как бы понятно слету что такая стоимость может получится только при том, что в микрософте называтеся inproc activation 8). корба такого на моей памяти никогда делать не могла, можно поглядеть но не думаю, чтобы научилась - не гонишь ли ты, мил человек?

   ну как бы понятно слету что такая стоимость может получится только при
   том, что в микрософте называтеся inproc activation 8). корба такого на
   моей  памяти  никогда  делать  не  могла, можно поглядеть но не думаю,
   чтобы научилась - не гонишь ли ты, мил человек?
Я точно это не гарантирую - как-то прочитал где-то это давно.. Ссылок
показать не могу. Если интересно, можно сходить на developer.gnome.org
и там в статьях что-то должно быть. Но что Orbit - очень быстрый ORB
это факт.
 А, вот нашел ссылку:
http://developer.gnome.org/doc/whitepapers/ORBit/about-orbit.html
Искать 'in-process' в той страничке. Правда про эквивалентность по
стоимости вызову виртуального метода там вроде нет.
 Но по-любому, gnome с версии 1.0 очень активно использует Корбу, например
вся панель и апплеты используют Корбу.
   KPart  is  based on Shared Libraries. This makes the component appears
   directly  as  a C++ object. There is no need to wrap its features with
   an IDL language, everything is accessible without extra effort.

   нотя подозреваю товарищу hvv это всё равно не понравится :)
Да, не нравится по причинам описанным выше.

> KPart is based on Shared Libraries.
> This makes the component appears directly as a C++ object.

Хм, т.е. на чем либо другом делать нельзя? Глупо, имхо.
COM/DCOM - бинарный стандарт, компоненты можно делать не только на C/C++, как и обращаться к ним.

А что там с лицензией на использование COM/DCOM?

> а сейчас KOM есть в KDE2.2? Что-нить его использует?
А по вашему эта завязка на корбу поможет умирающему GNOM'у?
Да и из каких языков позвольте вы собираетесь использовать этот бесполезный стафф? Скрипты? Может Паскаль в конце концов? :)
Я вообще ни понимаю как можно строить современные GUI приложения на основе такого отстоя как gtk...

   А что там с лицензией на использование COM/DCOM?
Это поделки MS, посему с лицензией все ОК. Или это про Orbit вопрос?
   Да  и  из  каких  языков  позвольте  вы  собираетесь использовать этот
   бесполезный стафф? Скрипты? Может Паскаль в конце концов? :)
Да, перловые скрипты.
   Я  вообще  ни  понимаю как можно строить современные GUI приложения на
   основе такого отстоя как gtk...
На флейм у меня нет времени, но кратко отвечу: а как же можно строить
системы на ОС с ядрами unix (ядрами, писанными на С)? Поясняю - есть врапперы для gtk для
тучи языков (включая С++) которые позволяют это делать очень комфортно.
Так думает в частности Redhat и Sun (gnome - DE по-дефолту в solaris9).

> A chto tam s licensiey na COM/DCOM?

------------
DCOM currently ships with Windows NT╝ 4.0 and will be available for Windows╝ 95 before the end of 1996. DCOM for the Apple╝ Macintosh╝ will be available from Microsoft in early 1997. In addition, DCOM implementations on all major UNIX platforms, including a reference implementation in source code form, will become available in early 1997. COM and DCOM are no longer proprietary to Microsoft, but are managed by the independent ActiveX≥ Consortium.
------------
It is quote from this location:

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechno...

-----------
Off: Sorry for english, troubles with codepages...

>Я вообще ни понимаю как можно строить современные GUI приложения на основе такого отстоя как gtk...

Не мог бы ты пояснить буквально в двух словах в чем состоит отстойность GTK. Мне действительно интересно, я сейчас пытаюсь с ним разбираться, имея опыт программирования интерфейсов на Turbo Vision под DOS, на MFC, VCL, ATL, VB, Win32 API под Windows. И, знаешь, какого-то особого впечатления кривизны GTK на меня не произвел, а если его сравнивать с Win32 API (тот же уровень, судя по всему), то gtk однозначно более концептуально стройный, что-ли. А насчет "строить современные GUI приложения на основе такого отстоя как gtk", можно задать встречный вопрос: как можно строить современные GUI приложения на основе такого отстоя как xlib? ;)

А я вот не понимаю, как можно писать хоть GUI, хоть что ещё, на таком ублюдочном язычке, как C++...

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

> Да, перловые скрипты.
Х-мм...я ничего не имею против perl(и даже активно его осваиваю), но
мне всегда казалось что его предназначение это обработка строк и использование в качестве CGI-scripts. В крайнем случае всегда под рукой есть Tcl/Tk.

>На флейм у меня нет времени, но кратко отвечу: а как же можно строить
>системы на ОС с ядрами unix (ядрами, писанными на С)?

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

>Поясняю - есть врапперы для gtk для
>тучи языков (включая С++) которые позволяют это делать очень >комфортно.

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

>..имея опыт программирования интерфейсов на Turbo Vision под DOS, на >MFC, VCL, ATL, VB, Win32 API под Windows.
Хоть вы и свалили все это в кучу но наверное должны понимать что использование C связано с недостаточной надежностью и выразительной способностью для отображенияв программе обьектов реального мира, коими несомненно являются понятия "окно", "кнопка" и т.д
Не буду спорить, может gtk и "однозначно более концептуально стройный"
чем win32API, однако если вы хотите создать хороший GUI API(а это возможно только с OO технологиями) то gtk становится просто еще одним лишним уровнем в схеме GUI_API->Gtk->Xlib->Drivers->Video.

предыдущая мессага от меня
>А я вот не понимаю, как можно писать хоть GUI, хоть что ещё, на таком >ублюдочном язычке, как C++...
В чем то согласен - в этом смысле мне больше по душе Java :)

>Хоть вы и свалили все это в кучу но наверное должны понимать что использование C связано с недостаточной надежностью и выразительной способностью для отображенияв программе обьектов реального мира, коими несомненно являются понятия "окно", "кнопка" и т.д

"Уже много говорилось об объектном подходе: некоторые говорили по существу, другие болтали о моделировании объектов реального мира" (c) Элджер (цитата не дословная) :)
Свет на объектном подходе клином не сошелся, это раз. Во вторых, если рассматривать такие концепции ОО, как наследование, инкапсуляция и полиморфизм, то все это в GTK есть, но не на уровне языка, а на уровне так сказать "паттернов проектирования". Что кстати позволяет обеспечить более другие и в чем-то даже лучшие инкапсуляцию и полиморфизм, чем в java или C++.

>однако если вы хотите создать хороший GUI API(а это возможно только с OO технологиями)

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

>то gtk становится просто еще одним лишним уровнем в схеме GUI_API->Gtk->Xlib->Drivers->Video.

Однако он не лишен смысла в схеме:
GUI_API_0 \
GUI_API_1--> Gtk->Xlib->Drivers->Video
GUI_API_N /

И как "пиши на чём хочешь" совмещается с "kparts - C++ only"? Никак не совмещается. Вывод KDE - ублюдство для стукнутых по голове фанатов C++, которые даже помыслить о том, что бывают ещё и другие языки, просто не в состоянии, в силу острой интеллектуальной недостаточности и врождённого дебилизма.

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

Я про "если вы хотите создать хороший GUI API(а это возможно только с OO технологиями)". За такое расстреливать надо.

В качестве примера ублюдочности отквоченного утверждения: где в Tk это сраное OO? Нет его там, и не должно быть. Не место сволочной ООПщине в гуйне.

мда...тут бы инквизицию бы возродить (*мечтательно так*)

   Я   уверен,   что   не   много   желающих  найдется  использовать  эти
   врапперы(если  я не прав - ссылки плизз). Ну а что касается самого gtk
"Типа не модно, посему юзать не буду" - да?
   то  я  согласен  своими друзьями, профессиональными дизайнерами, что у
   него совершенно жуткий внешний вид и отвратный usability.
Тогда пускай зайдут на gtk.themes.org или к окулисту.
Насчет usability - RTFM и список проблем в студию.

2hvv

>Тогда пускай зайдут на gtk.themes.org или к окулисту.
>Насчет usability - RTFM и список проблем в студию.
usability:
1.Есть ли на gtk.themes.org хоть одна тема, где бы отсутствовала
"бордюрка" между ползунком и непосредственно самим содержимым
окна. Лично _мне_ это неудобно. Я искал - не нашел.
2.В основном приложения GNOME/GTK используют MDI (тот же Gimp). Ну
неудобно _мне_. Почему не SDI?
(cравни с Krayon http://www.koffice.org/krayon/screenshots.phtml.)

>Да, перловые скрипты.
Чтобы делать очередные "поделки"?
Есть хоть одно серьезное GUI-приложение, написанное на Perl?
Я такого не знаю. А для "поделок" мне хватает
Kaptain http://www.hszk.bme.hu/~tz124/kaptain/

   1.Есть ли на gtk.themes.org хоть одна тема, где бы отсутствовала
   "бордюрка" между ползунком и непосредственно самим содержимым
   окна. Лично _мне_ это неудобно. Я искал - не нашел.
Незнаю. Даже точно не понял о чем речь. Сделай шот и подчеркни "бордюрку".
Хотя я скорее всего скажу "не знаю" про твой шот - надо смотреть сырцы, а
у меня времени нет на это. Сам смотри если такой придирчивый.
   2.В основном приложения GNOME/GTK используют MDI (тот же Gimp). Ну
   неудобно _мне_. Почему не SDI?
   (cравни с Krayon http://www.koffice.org/krayon/screenshots.phtml.)
1 Ты путаешь SDI и MDI. MDI (как ворд в винде) не использует ни одна
gtk прога. Если тебе не нравится какая-то прога (подход гимпа - тулбар один
на все окна) - проси авторов проги - виджетсет тут не причем.
   Чтобы делать очередные "поделки"?
Если у тебя на перле выходят только "поделки" - то это твои проблемы.
Маленькие програмки на нем писать очень удобно. И не очень маленькие.
   Есть хоть одно серьезное GUI-приложение, написанное на Perl?
В debian-russian их недавно перечисляли. Сам названия не помню.
Что помню - все *drake проги (для конфигурирования всего и вся в Mandrake -
типа keyboarddrake) писаны на перле (хотя я с ними не работал, о качестве
не в курсе).

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

   я  вижу уважаемый hvv что вы любите оставлять последнее слово за собой
   но по каким то причинам используете в дискусии не факты и обоснованные
   утверждения, а нелепые поговорки и прочую ерунду...:|
Ты вообще русский понимаешь? Если тебе кажется что да, процитируй
не факты, а поговорки и прочую ерунду в моих высказываниях. Или скажи
что тебе в моих словах не было понятно.

2hvv

http://debian.boom.ru/snapshot3.png

>Сам смотри если такой придирчивый.
Мы ведь говорим о usability? Так что я попридираюсь)

>1 Ты путаешь SDI и MDI. MDI (как ворд в винде) не использует ни
>одна gtk прога. Если тебе не нравится какая-то прога
>(подход гимпа - тулбар один на все окна) - проси авторов проги -
>виджетсет тут не причем.
Ворд в винде уже не использует MDI. Для каждого документа он
открывает отдельное окно. Ну да дело не в этом.
Вот что я подразумеваю под SDI:
http://developer.kde.org/documentation/standards/kde/style/basics/windows.html

>Если у тебя на перле выходят только "поделки" - то это твои
>проблемы. Маленькие програмки на нем писать очень удобно. И не
>очень маленькие.
Я ничего не имею против Perl. Просто в большинстве своем программки,
использующие gtk-perl не представляют особой ценности.

>Что помню - все *drake проги (для конфигурирования всего и вся в
>Mandrake - типа keyboarddrake) писаны на перле (хотя я с ними не
>работал, о качестве не в курсе).
Не знал. Но я с ними тоже не работал.

   http://debian.boom.ru/snapshot3.png
Понятно. Это кажется DEFAULT_SCROLLBAR_SPACING (=3) в gtk/gtkscrolledwindow.c
Попробуй поменять. Но scrollbars всегда "вдавлены" в gtk, так что установка
в 0 сделает внешний вид немного несуразным IMHO.
   Ворд в винде уже не использует MDI. Для каждого документа он
   открывает отдельное окно. Ну да дело не в этом.
Сорри спутал - в Excel MDI (слава Богу, давно с ними не работал).
   Вот что я подразумеваю под SDI:
   http://developer.kde.org/documentation/standards/kde/style/basics/win-
   dows.html
Понятно. Ну гимп наверно с фотошопа идеи брал - вот таким и стал. Не
факт что  все бы был удобнее pure SDI.
   >Если у тебя на перле выходят только "поделки" - то это твои
   >проблемы. Маленькие програмки на нем писать очень удобно. И не
   >очень маленькие.
   Я ничего не имею против Perl. Просто в большинстве своем программки,
   использующие gtk-perl не представляют особой ценности.
Я не встречал ни одной программы на gtk-perlкроме своих. Так что мне сказать
нечего.

>Что помню - все *drake проги (для конфигурирования всего и вся в
>Mandrake - типа keyboarddrake) писаны на перле (хотя я с ними не
>работал, о качестве не в курсе).
ну конечно не все, а примерно половина:
rpm -qal | grep -e "bin.*drak" | file -f -
да и потом если и пользоватся такими тулзовинами то лучше уж linuxconf где по кране мере все централизовано.

>Понятно. Это кажется DEFAULT_SCROLLBAR_SPACING (=3) в
>gtk/gtkscrolledwindow.c Попробуй поменять. Но scrollbars всегда
>"вдавлены" в gtk, так что установка в 0 сделает внешний вид немного
>несуразным IMHO.
Сенкс, попробую как-нибудь.

>Я не встречал ни одной программы на gtk-perlкроме своих. Так что
>мне сказать нечего.
Если не ошибаюсь, Вислобоков этим интересовался раньше.

   Если не ошибаюсь, Вислобоков этим интересовался раньше.
Да, он писал програмки - но больше в целях изучения GtkPerl. Сейчас
они больше не разрабатываются, и к тому же много незавершенных, как я понимаю.
PS: Krayon - поделка. Никакой возможности локализации диалогов, примитивный
внутр. язык для операций. К сожалению. Идея хорошая, но наверно лучше все-таки
описать диалоги gui-builderом и цеплять описание диалогов из перла или питона.

А кто такой Вислобоков и чем он прославился? Интересно даже...

Виктор Вислобоков задумал написать десктоп на перле (вернее, реализовать ф-ии, нужные юзеру от десктопа - редактор, ФМ, Run dialog, Завершение Работы) на GtkPerl. Но как я понимаю этот проект заброшен (написано было около 150 кб). УРЛ непомню - где-то на permonline.ru AFAIR.