Почему в линуксе неюзабельный UI

>Чтобы эффективно работать на компьютере, математику не должно быть нужно владеть словарём/языком конкретной матбиблиотеки

На компютере «вообще» — да. А вот с «конкретной матбиблиотекой», вероятно, не получится. Старая шутка «Быстро, дёшево, качественно. Выбирайте любые 2 пункта.» вполне применима к «инструментам», только параметры другие. Т.е. у конкретной «библиотеки» может быть «понятный» интерфейс. Который либо спрячет кучу её возможностей, либо будет слишком сложным для «не владеющего языком» пользователя. Либо библиотека слишком «немощна».

Впрочем, это только опыт. Если вдруг кому-то удастся объединить все 3 в одной рюмке, буду рад.

>так должен быть работать Tcl/Tk по задумке автора

Мне показалось, он имел ввиду что-то типа javastudio, виденое мною лет 10 назад. Там вытаскивались кирпичи типа «бд»,«табличка»,«if»,«+», и т.п., соединялись трубами и потом всё это весело мигало. Простые объёкты были слишком трудны, сложные непонятны(много торчащих концов). Но работало.

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

Croquet надо KRoN73-у показать. Это такая штука для создания многопользовательских 3D миров.

>>Мне показалось, он имел ввиду что-то типа javastudio, виденое мною лет 10 назад. Там вытаскивались кирпичи типа «бд»,«табличка»,«if»,«+», и т.п., соединялись трубами и потом всё это весело мигало.

Да-да, что-то типа этого: http://www.javaworld.com/jw-01-1998/images/jslogic.gif

Вроде от неё отказались.

> Выходной тип «гуёвых» программ — двухмерное изображение предназначенное для глаз/мозгов. Т.о. их легко комбинировать только с глазами/мозгами.

тут неверно

выходов у гуевой проги м.б. 2 — 1. сам гуй 2. составляемая командная строка,

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

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

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

>Если вдруг кому-то удастся объединить все 3 в одной рюмке, буду рад.

Есть неидеальный, но работающий фреймворк BlackBox Component Builder http://www.oberoncore.ru/ в котором реализована компонентная модель составных документов - «все 3 в одной рюмке» :)

Да-да, что-то типа этого: http://www.javaworld.com/jw-01-1998/images/jslogic.gif

Например в odgl это могло бы выглядеть примерно так:

Comfortable +{r}
Returns +{r}
Risks +{r}
RememberInputs -{r}
    InvestmentLogic
        Distribute
            Conservative 
            Negate Conservative

odgl = ?

гугль и википедия молчат

а вы в консоли картинки не через cat смотрите случайно?

Извини, меня их аббревиатура всегда сбивает с толку. Там ничего интересного, это просто «язык» сериализации графов. Демонстрировалось, что в виме такую схему нарисовать не сложнее http://ogdl.sourceforge.net/.

Да, а ИИ противника можно реализовать элементарным плагином.

ActiveX вобще не нужен

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

Ололо! Чтобы мой броузер показывал разные форматы изображений, мне нужно его перекомпилять™ ради каждого формата, вместо того, чтобы подключить в систему еще одну библиотеку?!

>Ололо! Чтобы мой броузер показывал разные форматы изображений, мне нужно его перекомпилять™ ради каждого формата, вместо того, чтобы подключить в систему еще одну библиотеку?!

Перечитайте топик и проникнитесь пониманием невероятной, ужасающей глупости и неуместности своей реплики.
Nuff said.

> Перечитайте топик и проникнитесь пониманием невероятной, ужасающей глупости большинства его участников.

Очевидный фикс.

> ActiveX вобще не нужен

Enjoy your KPart/Bonobo

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

Проблема в «мешанине» скорее не в том, что нужен способ делать франкенштейна, а в возможности «на лету» менять содержимое логических компонент, без процедуры в 100500 импортов/экспортов. Ну вот к примеру - есть у нас редактор диаграмм, редактор рисунков, редактор формул, и редактор неведомой фигни. Результаты труда этих компонент мы экспортируем в Простой Растровый Формат (ЩИТО?) и вставляем в отчет на 100500 листов.У нас больше чем 100 таких компонент. И нам вдруг, ВНЕЗАПНО, надо половину из них поправить. Допустим даже все исходники этого барахла заботливо уложены в архив с этим документом (ОЛОЛО?). Нам надо найти в этой каше нужный компонент, обработать его, экспортировать, удалить старый и всунуть новый. Вот такая вот чепуха выходит. Впринципе, в стане *TeX так примерно и происходит.

Для упрощения всех этих процедур существует стандартизация, часть готовых стандартов можно найти на w3.org

Нужно начать с того, что такая функциональность была и ее решили выкинуть за сложность реализации, громоздкость. Потому что брали пример с ActiveX. В итоге получилось что оно еще никому и не надо.

Но конечно сществует возможность это реализовать. Если нужный код лежив библиотеке, то и коню понятно как им пользоваться. Вопрос звучит, а что если нужно совместное выполнение кода в двух процессах. Я так понял?

Два процесса можно связать любым из этих методов: сокеты (включая локальные), FIFO, Dbus, shared memory (читаем shmat), pipes и даже GConf. Последний хорошо подходит, если имеет место нечастое взаимодействие, которое не в виде потока информации, а больше в виде нечастой конфигурации и принимающая сторона может быть и не запущена. Вышеописанные методы полностью решают проблему взаимодействия двух процессов.

Остается еще одна задача, собственно GUI. Встаривание виджетов одного процесса в виджеты в другом процессе может быть реализовано с помощью GtkSocket+GtkPlug. В Qt для этого предназначет QtXEmbedClient+QtXEmbedClient, которые совместимы с вышеописанными Gtk виджетами. Так что встраиваемые обьекты не должны быть основаны на одном тулките. По крайней мере по идее.