LINUX.ORG.RU

для antialias в gtk2 и gnome2 : (тем кто еще не понял)
export GDK_USE_XFT=1
и все.

anonymous
()

кстати тем кто использует LD_PRELOAD с gdkxft.so
это будет конфликтовать с gnome2 (описано в requirements)

anonymous
()
Ответ на: комментарий от anonymous

2vitus: >1) чем тебя не устраивает интерфейс Виндовс и как интерфейс (т.е. расположение кнопок и меню) влияет на кол-во багов. Желательно дать развернутый ответ и по возможности без лозунгов.

Концепцией "любой файл есть документ, и для любого документа есть ровно одна программа, умеющая с ним работать", пришедшей из ранних MacOS. Там она, правда, хотя бы прямо сделана. А уже в windows - криво - завязка на расширения файлов для определения типа содержимого.

В Gnome и KDE - еще кривее.

>2) Какие *конкретно* механизмы взаимодействия (я правильно поимаю что речь идет о IPC?), Мигел не приветствует?

google is your friend. А лично я не приветствую для взаимодействия между компонентами десктопа любые механизмы кроме ICCCM. Почему - я неоднократно объяснял в RU.LINUX. Так что google найдет.

> 3) Это самый замечательный пункт, т.к. GTK изначально создавалась как свободный ответ комерческому QT. Т.е. вы признаете, что свободные прогграммисты не смогли создать библиотеку хотя бы такого же уровня как комерческая QT?

Не знаете Вы истории, молодой человек.

Gtk это The Gimp toolkit. Создавался он исключительно с целью обслужить потребности разработчиков Gimp, которые прекрасно понимали, что многое из того, что необходимо для нормальной десктопной среды и что изначально существовало в графических тулкитак под X window, для их целей - лишнее. Хотя бы потому, что в 1996 году 100мбит сети еще были редкостью, поэтому вариант запуска растрового редактора на удаленном X-сервере можно было не рассматривать.

Естественно, я сравниваю Gtk не с Qt, который по моему такая же бяка, только хуже, поскольку еще и завязан

а) на объектную модель C++, которая совершенно не идеальна для разработки интерфейсов. Объектная модель Objective C или Smalltalk для этой цели куда больше подходит.

б) на препроцессор moc.

Сравнивать Gtk имеет смысл с Motif/Lesstif, Xview, Tk, GNUStep. И он это сравнение проигрывает по всем параметрам без исключения.,

>Из вашиъ пунктов один вывод - GPL - набор багов.

нет, вывод совершенно другой. Вывод - GNOME не лушче KDE, а мир OpenSource софта вообще, и софта под *nix в частности куда шире, чем Вы можете себе представить.

vitus
()
Ответ на: Ошибки дизайна от DonkeyHot

>для vitus >1. Интерфейс должен быть как у виндов

>Они(подозреваю что вообще никто) не знают какой должен быть интерфейс. >Известно 2: удобный(относительно, командная строка) и красивый("как у >виндов"). Первый реализовать нет смысла - он уже почти юзабелен.

Ну, мне во всяком случае, кажется очевидным, каким интерфейс НЕ должен быть.

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

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

Он НЕ должен мешать воспринимать любые обрабатываемые объекты в естественном для них виде. Вот здесь командная строка малость отстала от жизни - она не предоставляет естественных способов работы со структурированным текстом и графикой, не говоря уж об аудио и видео.

>>2. Традиционные средства межпроцессной коммуникации Unix и X window sucks

>Они не ушли от них(а как собс-но?). Они спрятали их вызовы - нормальная практика.

Именно ушли. Они пошли в сторону CORBA. Чем автоматически создали кучу проблем, поскольку системы аутентикации и авторизации у CORBA и у X-Window строго перпердикулярны друг другу.

И не надо мне тут о том, что CORBA внутри пользутеся socket(2). Я веду речь име нно о высокоуровневых, т.е. видимых пользователю концепциях взаимоедействия.

>>3. В качестве графического тулкита будем использовать Gtk.

>А какая разница. Рассматривай GTK как wrapper над X window. Который всегда можно переделать/исправить.

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

враппер это вообще говоря синоним слова интерфейс. Только интерфейс между двумя компонентами софта, а не между человеком и софтом. В этом качестве GTK не удовлетворяет первому из вышеприведенных критериев. Он обрезает нафиг заметную долю функциональности X Window. А именно, все, что связано с per-display конфигурацией.

vitus
()
Ответ на: комментарий от anonymous

>1. у гнома не более виндовый интерфейс чем в КДЕ, например (хотя, ИМХО, не виндовый вообще ни разу - мне он больше маки напоминает). ну и похожесть интерфейсов вообще говоря закономерна -

Я никогда не утверждал что KDE чем-то лучше гнома. И то и другое sucks - неверные концепции интерфейса, кривые графические тулкиты, недоиспользование возможностей X-Window в угоду иллюзорной кроссплатформности.

Почему иллюзорной? Да потому что реально живые платформы, не являющиеся Unix, либо имеют свои собственные десктопные среды, которые уступать место пионерским поделкам не собираются, либо не имеют достаточно ресурсов для запуска этого bloatware.

Поэтому десктопная среда, использующая преимущества X Window (сетевую прозрачность, например) имела бы реальные конкурентные преимущества. У KDE и GNOME сейчас преимуществ перед Windows практически нет, поскольку меньшая (нулевая) цена лицензии компенсируется повышенным аппетитом к ресурсам.

Что касается windows vs macos, то не буду спорить с тем, что основные интерфейсные концепции Win 9x и выше содраны с MacOS. Просто большей части читателей Windows знакома гораздо лучше, поэтому я и ссылаюсь на "интерфейс в стиле Windows"

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

И я считаю огромным маркетинговым просчетом GNOME и KDE team то, что они ориентируются на ту же целевую аудиторию.

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

Собственно эта аудитория способствовала успеху Unix в 80-х годах. Сейчас командно-строчный интерфейс слегка устарел, так как плохо приспособлен для обработки графической информации.

Но задачу естественным образом обобщить командную строку на мультимедиа данные разработчики GNOME не попытались даже поставить.

>2. пайпы - сакс. И Иказа аргументированно объяснил на тех самых страничках, почему он так счиатает.

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

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

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

>CORBA - индустриальный стандарт, а не изобретение де Иказы.

Беда, коль сапоги начнет тачать пирожник.

CORBA - стандарт для клиент-серверного взаимодействия, т.е. предоставления неким единым объектом сервером своих методов через посредство объектного брокера.

Хотя концепция удаленных вызовов методов (и вообще RPC) гибче, чем концепция пайпов, для взаимодействия между программами на десктопе она пригодна только в однопользовательской среде навроде Windows 95. Уже в Win2k с ее терминал-сервисом концепция RPC на десктопе сталкиквается с многочисленными трудностями.

А уж в реально многозадачных системах она обречена с самого начала.

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

X-протокол и настройки над ним типа Tk-шного send эту задачу решают; А CORBA - нет. Она не приспособлена для этого.

>3. по поводу кривости/прямости GTK спорить не буду, однако в теории это дает преимущество - независимость гнома от иксов (которые, вообще говоря, для десктопной машинки тоже суксь)

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

В результате GNOME (и KDE) абсолютно неприменимы в хост-терминальных конфигурациях. А работай они в них, уже при сегодняшнем наборе функциональности один мощный линуксовый сервер с парой десятков x-терминалов из бездисковых писюков убил бы нафиг локальную сеть на из 20 рабочих станций Windows XP по соотношению цена+удобство администрирования/предоставляемая пользователям функциональность.

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

vitus
()

2vitus

KDE (и GNOME тоже) прекрасно работают у меня по сети в "хост-терминальных конфигурациях". При этом терминал грузится с дискеты, монтирует с хоста разделы по NFS и все отлично бегает. Не могу понять, в чем здесь проблема?

ANDI ★★
()

2vitus (*) (2002-06-18 17:15:58.805):

Что-то разумное есть, но несколько гипертрофировано - total used free shared buffers cached Mem: 256040 252564 3476 0 11844 168564 -/+ buffers/cache: 72156 183884 Swap: 64508 0 64508

72 MB ни коим образом не отличается от загрузки памяти системой WinXP/ Win2000. Т.о. по порядку - все абсолютно одинаково.

anonymous
()
Ответ на: 2vitus от ANDI

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

В случае X-терминала на терминале выполняется только X-сервер, и, при наличии соответствующей аппаратуры - аудиосервер.

То что грузится с дискеты это вообще не терминал а убожество. Нормальный терминал грузит ядро по tftp и, иногда, если это не аппаратный терминал или если его терминалная ОС так устроена, монтирует / по NFS.

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

Проблемы с GNOME начинаются тогда, когда на один и тот же хост приходится попеременно или одновременно логиниться с разных терминалов. gtkrc не поддерживает display-specific конфигурации.

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

vitus
()
Ответ на: комментарий от anonymous

>72 MB ни коим образом не отличается от загрузки памяти системой WinXP/ >Win2000. Т.о. по порядку - все абсолютно одинаково.

Интересует не "по порядку". Интересует "на разницу в стоимости аппаратуры, необходимой для комфортной работы, равной или превышающей стоимость лицензии на XP"

vitus
()

А как по поводу SMBFS в gnome-vfs? Приделали уже или нет?

syomin
()

Поддержка smbfs уже давно есть в пакете gnome-vfs-extras

anonymous
()

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

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

>Нормальный терминал грузит ядро по tftp и, иногда, если это не >аппаратный терминал или если его терминалная ОС так устроена, >монтирует / по NFS.

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

>Только такие терминалы дают заметный выигрыш в цене, так как им не
>нужно более 16 мегабайт памяти, и не нужен быстрый процессор.
а сколько это все стоит? Монитор (новый 15") 130 баксов, а все остальное - 40 (бу простое). а помощнее (с приличной памятью и процессором) - 80-100 баксов. итого вся разница в 50 долларов на 200 (25%) единовременных выплат, и полная свобода в реализации потом.

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

Да и по деньгам это явный минус и вообще дыра для витусов (то есть вирусов :).

>Проблемы с GNOME начинаются тогда, когда на один и тот же хост
>приходится попеременно или одновременно логиниться с разных
>терминалов. gtkrc не поддерживает display-specific конфигурации.

Я (пока) не вижу в этом проблемы. Что там в gtkrc такого есть, что до зарезу требует "display-specific конфигурации". кстати, добавить эти возможности вроде как не так уж и сложно - было бы желание и предмет головной боли. А пока это больше похоже на сцену с покупателем по Довлатову, когда клиент заказывает разные фичи, а потом все равно ставит занюханый виндос, а на вопрос, "а как же твои запросы?", отвечает, "ну нет и черт с ним..."


>С KDE (с GNOME, признаюсь честно, не пробовал) есть еще та проблема

а вот я gnome хочу попробовать. причем через vnc.

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

Это понятно. Вообще странно, что кде работает по сети.

anonymous
()

2vitus

>То что грузится с дискеты это вообще не терминал а убожество. Согласен. Но возможности записать это в bootrom у меня не было.

>Нормальный терминал грузит ядро по tftp и, иногда, если это не аппаратный терминал или если его терминалная ОС так устроена, монтирует / по NFS. И то, и другое: сначала грузит ядро по tftp, а потом уже монтирует / по NFS.

>Только такие терминалы дают заметный выигрыш в цене, так как им не нужно более 16 мегабайт памяти, и не нужен быстрый процессор. Теоретически - да, а практически... Вы знаете, сколько стоит самый простой X-терминал? Получается два писюка, не меньше. Так что использование PC в моем случае более, чем оправданно.

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

>С KDE (с GNOME, признаюсь честно, не пробовал) есть еще та проблема что при одновременном логине одного и того же пользователя с двух разных терминалов система межкомпонентного взаимодействипя сходит с ума. C GNOME таких проблем не замечал. А от kdelibs я не в восторге. Но это уже другой разговор.

ANDI ★★
()
Ответ на: комментарий от anonymous

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

Ну правильно! Вместо прямых, развитых и отлаженных 20 годами эксплуатации X-ов будем использовать кривую VNC. При том что X-ы все равно использовать надо, так как оно все равно через них работает.

Удобно - не использовать GNOME и KDE, а использовать нормальные X-овые программы, использующие Xaw, Motif, Xview.

Единственное что обидно, что толпа юных OpenSource разработчиков, которые между прочим иногда делают неплохие вещи, этого не понимает.

Поэтому они используют Gtk и Qt, с которыми проблемы.

vitus
()
Ответ на: комментарий от anonymous

>Я (пока) не вижу в этом проблемы. Что там в gtkrc такого есть, что до зарезу требует "display-specific конфигурации". кстати, добавить эти

Шрифты, например. Если у тебя один терминал 1280x1024, а соседний 800x600, то шрифты им, естественно, требуются разные.

А цвета в GTK вообще настраиваются через задницу, то есть через темы.

С цветами тоже бывает отдельное развлечение если один терминал - 256 цветов, а другой true color.

vitus
()

2vitus (*) (2002-06-19 11:20:07.723):

Интересно, как гипотетическая разница в памяти может съесть разницу в цене на лицензии среднего дистрибутива Linux и WinXP?

Далее - если использовать Motif, Xaw... Вы пробовали когда-нибудь работать с TeX'ом c kdvi и с xdvi? Если нет, то конечно можно орать, что Xaw это круто. Единственно - количество оперций, которые я должен сделать под xdvi для просмотра странички и в kdvi разительно отличаются. Запускается dviviewer, редактор, консоль и дальше - в редакторе пишем, в консоли компилируем, в dviviewer'e смотрим. Так вот, мало того, что xdvi нужно перегружать, в отличие от kdvi, так еще и просто пролистать значительно труднее.

Motif - не исключаю, что действительно в свое время была очень хорошая штука, но сейчас он неудобен по сравнению с qt, gtk.

anonymous
()

>Ну правильно! Вместо прямых, развитых и отлаженных 20 годами >эксплуатации X-ов будем использовать кривую VNC.
одно другое не заменяет. vnc удобна тем, что все крутится на сервере и к клиенту вообще никаких претензий. я вот через даже через веб работал с сервером. так что иксы иксами, а vnc вносит свою радость.

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

запускать отдельные приложения по ssh -X? но тогда непонятно, как собрать весь десктоп на клиенте. совсем непонятно.

>При том что X-ы все равно использовать надо, так как оно все равно >через них работает.

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

>Удобно - не использовать GNOME и KDE, а использовать нормальные >X-овые программы, использующие Xaw, Motif, Xview.

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

>Единственное что обидно, что толпа юных OpenSource разработчиков,
>которые между прочим иногда делают неплохие вещи, этого не понимает.
>Поэтому они используют Gtk и Qt, с которыми проблемы.

довольно трудно обойтись без простых и мощных возможностей тулкитов типа gtk+ итп.


anonymous
()

К моему большому сожалению(ну люблю я Гном:), в словах Виктора много правды про недостатки Гнома... Правда, в планах разработки была поддержа per-display configs, но так как я 2.0 еще не видел, то не знаю, есть ли она там...

Единственно, можно сказать что Виктор пристрастен в представлении Tcl/Tk вкупе с pure X как решение всех проблем GUI в UNIX :)))

Кстати, Tcl/Tk не представляет с точки зрения GUI что-то кардинально отличное от тех же Win/GTK/QT intefaces :)

BaT ★★★★★
()
Ответ на: комментарий от BaT

>Единственно, можно сказать что Виктор пристрастен в представлении Tcl/Tk вкупе с pure X как решение всех проблем GUI в UNIX :)))

Совершенно не верно. Я только утверждаю что использование Tcl/Tk или Perl/Tk или STK решает некоторые более другие проблемы, решение которых повышает usability сильно больше, чем решение тех проблем, которые решают KDE и GNOME.

А для полноценного решения проблем GUI в Unix нужен какой-то новый подход. Но GNOME и KDE в этом смысле - шаг НАЗАД по сравнению с традиционными X-приложениями.

vitus
()

2vitus (*) (2002-06-20 11:52:42.371):

Это шаг назад в описаном Вами случае. В других случаях это несомненный шаг вперед. Да, для определенных сегодняшних задач GNOME и KDE подходят хуже. Но то usability с помошью ваших любимых средств повышается ЛИШЬ на части задач, поэтому нельзя говорить, что лучше, а что хуже вообще. Только на конкретных задачах. А из-за того, что вы не понимаете этой простой истины весь спор и разгорается.

anonymous
()
Ответ на: комментарий от anonymous

Это шаг назад вообще. С точки зрения общей концепции общения человека и компьютера. Потому что GUI образца MacOS 85 исходит из точки зрения что пользователь идиот, и что он должен делать тупую работу (с минимальными затратами труда, но делать), а компьютер должен "водить его за ручку", выкидывая системные модальные диалоги, если что не так.

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

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

vitus
()

по моему явный перебор. гном ничего не предлагает и не заставляет. питон+pygtk+pyglade+pygnome это "я делаю, а машина меня может и послать"?
просто есть выбор приложений для разных стилей работы. каждому свое. "Бог придумал людей, а кольт сделал их равными." можно применить и к гному. Гном дал всем пользователям то, что они хотели, а гном2 наконец-то сделал русский язык равноправным с английским...

anonymous
()

2vitus (*) (2002-06-20 13:50:49.422):

Насчет MacOS и UNIX - часто нужно сделать некую операцию лишь один раз. В таком случае ее проще проделать самому. Если что-то надо делать несколько раз - нужно писать задание (программировать). Этим самым GNOME среду UNIX никто не отменял. Терминал обычно занимает соседнюю с G кнопку.

anonymous
()
Ответ на: комментарий от anonymous

>Насчет MacOS и UNIX - часто нужно сделать некую операцию лишь один раз.

Часто? А мне крайне редко. Может потому что меня в университете обобщать научили. Поэтому для меня обычно очевидно, что данная операция - частный случай некоторой более-менее регулярно выполняемой операции, которую я и автоматизирую с соответствующей параметризацией.

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

Скрипты для решения GUI-шных задач должны писатьcя drag'n'drop-ом.

vitus
()

2vitus (*) (2002-06-21 12:02:03.939):

Тебя не обобщать научили, а посадили администрить. Отсюда и задачи.

anonymous
()
Ответ на: комментарий от anonymous

>Тебя не обобщать научили, а посадили администрить. Отсюда и задачи.

Нифига. Сначала я себе поставил Linux для того, чтобы GIS-задачи под ним решать.Потому как задрали ограничения доса и 3.1-х виндов. И это было лет через пять после окончания университета.

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

А в порядке хобби я книжки верстаю.

vitus
()
Ответ на: 2vitus от ANDI

Учитесь, Киса. Хорошо излагает (цэ)

anonymous
()

Эта, не нада свистеть про xdvi. Перерисовывает. Сам так сижу.

Backson

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.