LINUX.ORG.RU

Вышел Gnome 2.8


0

0

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

Вкратце о том, что нового:

- Файловый менеджер Gnome 2 использует улучшенную и стандартизированную систему файловых типов. Утверждается, что вскоре та же система будет использоваться в KDE
- Теперь гном поддерживает DNS-Based Service Discovery
- Съемные устройства/накопители (cd, dvd, карты памяти, камеры) теперь могу быть распознаны и подключены автоматически
- Новая тема Glide
- Добавлена возможность показа любой клавиатурной раскладки
- Добавлена интеграция календаря с Evolution
- В сетевой монитор добавлена поддержка беспроводных устройств, показ силы сигнала
- Добавлена поддержка VNC
- Evolution 2.0
- Добавлен клиент Groupware
- Различные мелкие логичные исправления исправления.

>>> Обзор изменений

★★★★★

Проверено: Demetrio ()

Ответ на: комментарий от svu

>какой подход у kde

неее, svu, никто не может - ты тут самый умный :)

Pi ★★★★★
()

Вот тут читаю я закус с UTF8 и KOI8-R и назревает вопрос.

Вот вы тут братья базарите про Юникод и КОИ, а реально слышится тема пардон, "У кого писька длиннее".

Дык действительно.

--- === Что же мне даст переход с KOI8-R на UTF8??? === ---

Просьба если кто будет отвечать мне на моё сообщение, то от темы не отходите, а говорите целостно и точно.

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

>А зачем перемонтировать-то было? for i in *; do { n=`echo "$i" | iconv -f utf8 -t koi8-r | tr -d "\n"`; mv "$i" "$n"; } done

Ленивый, потому что.

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

>Если девушки симпатичные, а я был бы холостым - да, конечно:) А так - нет, спасибо:)

Знаешь, с их уровнем сообразительности они бы тебя раздражали. :)

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

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

Больше ничего.

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

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

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

честно говоря не знаю какое представление внутреннее у КДЕ но локаль для файловых систем по умолчанию у меня koi-8r прописано в /etc.sysconfig/i18n

а для разделов виновс и cdrom : в /etc/fstab iocharset=koi8-r,codepage=866

и названия файлов при чтении записи приводятся к сооветсвующей кодировке

так что пункт 2a

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

> Я лично себя полиглотом (и тем паче эмигрантом) не считаю (всего-то -- два иностранных свободно и ещё один иностранный со словарём), но вот повсеместный переход на юникод всячески одобряю. Знаете почему?

Дык, ты попадаешь в категорию "переводчик" или "полиглот". То бишь 1% от всего населения (или около того). Вполне допускаю, что тебе нужно utf8. Но как ты думаешь, таких как ты много в России? Мой личный опыт (вполне допускаю, что нерепрезентативный), так вот, судя по нему ~70% юзеров знают только русский, ~30% -- русский и (более-менее) английский. При дальнейшей компьютеризации страны будет увеличиваться процент знающих только один (русский) язык. Надо объяснять, почему?

Тут на LOR регулярно всплывают заявы, что однобайтные кодировки must die, 21 век на дворе, и прочая шелуха. Так вот, вопрос: если большинству не нужен юникод, то с какого это перепоя оно должно прогибаться под меньшинство? При этом я вполне допускаю, что тебе, svu и кому-то еще юникод нужен -- ну так и юзайте его, но не надо его навязывать всем остальным, потому что пользы от него нам нет, а гемор -- есть.

> Потому что я как простой российский юзер (кстати, спасибо Вам за заботу обо мне :)), слушаю музыку.

:) Я не о тебе забочусь, а о себе. О тебе ты сам заботься.

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

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

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

Давайте, гражданин прокурор, разберемся. Итак, подсудимый отказывается видеть на своем мониторе иностранные буквы, мотивируя это тем, что он их не понимает. Можно ли это считать неуважением, ксенофобией, пропагандой фашизма и разжиганием национальной розни? Нет, и нет! Это следует считать проявлением социалистической сознательности, свойственной подсудимому, как и всякому достойному члену КПСС. Почему? А потому что неизвестно, что эти иностранные буквы означают. А вдруг в них содержится призыв к свержению власти рабочих и крестьян?! Такие происки американского империализма следует пресекать сразу же! Поэтому предлагаю снять с подсудимого все необоснованные обвинения и объявить ему благодарность по партийной линии -- за проявленную бдительность.

nobody ★★
()
Ответ на: Хмм =) от Zloy_Krys

>>UTF-8 без вариантов будущее
А почему именно UTF-8 ? Может UTF-16 (гораздо более логичное).

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

>Единственный выход - насильственное насаждение уникода в именах >файлах.
Вот это правильно. С этого вводить юникод и надо было. Вот только какая файловая система на сегодняшний день может этим похвастать ?

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

> А почему именно UTF-8 ? Может UTF-16 (гораздо более логичное).

Естественно, 16-битный юникод лучше во всех отношениях. Но он неудобен американцам: у них, как у всех остальных, будет по 2 байта на символ. А так им хорошо: что ASCII, что UTF-8 с точки зрения американца не отличаются ничем, и там и там у них 1 байт на символ. Поэтому нам всем в будущем светит самая дурная из всех когда-либо придуманных кодировок -- utf8: это удобно американцам.

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

>> Единственный выход - насильственное насаждение уникода в именах файлах.

> Вот это правильно.

А ты сайтом не ошибся? Насильственное насаждение чего бы то ни было -- это по адресу http://www.microsoft.com

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

Скажите, дорогой nobody, а есть ли у Вас нормальные аргументы против юникода? Или только "большинство кроме русского ничего не знает"?

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

я долго пытался собрать сам с патчами, потом плюнул и сделал rpm2tgz mc* installpkg *.tgz ;)

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

> Скажите, дорогой nobody, а есть ли у Вас нормальные аргументы против юникода? Или только "большинство кроме русского ничего не знает"?

Для меня юникод -- это лишняя сущность. Я знаю только русский и (немного) английский.

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

а) насильственное насаждение юникода всем поголовно, включая тех, кому это не нужно (и меня в том числе), и

б) текущий стандарт.

Чем плохо utf8 (длинное объяснение с прелюдией):

В языке программирования Си нет такого типа данных как "строка текста". Есть тип данных "символ". И есть поддержка объединения нескольких элементов данных одинакового типа в массив. Таким образом получаются строки текста:

char string[] = "Строка текста";

В примере string -- это массив элементов, каждый из которых имеет тип char (character -- символ: буква, цифра, знак препинания и т.п.).

Для объединения данных в массив каждый элемент должен иметь один и тот же размер. В случае однобайтной кодировки символы имеют размер 1 байт. В случае 2-байтной -- 2 байта. А в случае utf8 символ имеет переменный размер, поэтому невозможно иметь массив символов в кодировке utf8, а значит нельзя работать со строками текста как с массивами.

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

Например, чтобы изменить один символ в массиве, мне нужно знать адрес начала массива и порядковый номер символа в этом массиве. Зная их, замена выполняется одной быстрой языковой конструкцией: умножить номер элемента на размер элемента, прибавить адрес начала массива, записать по этому адресу новое значение. При использовании utf8 у меня уже не массив, а список, и та же задача превращается в перебор всех символов от начала списка до тех пор, пока не дойдем до заменяемого.

Другой пример: визуализация. Есть файл с текстом, есть экран (или окно -- неважно, любая прямоугольная область вывода). Для вывода текста мне нужно приводить "координаты" символов в файле к координатам области вывода. Для 1-, 2- и 4-байтной кодировки задача вполне тривиальна: индекс в одном массиве -- к индексу в другом. А если я должен выводить текст в utf8, мне опять-таки нужен последовательный перебор. Как следствие -- тормоза.

Это было про utf8. Теперь про юникод вообще (в т.ч. и 2-байтный) и грабли с его визуализацией.

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

А что, если в выводимом мной тексте встретится не-символ? Т.е. неопределенная стандартом комбинация? Тут полная неизвестность. Стандарт оставляет отображение таких кодов на усмотрение реализации. Кто мне скажет, как конкретная реализация Х сервера будет поступать с ними? Она может вывести вместо них квадратики/вопросики/etc. А может ничего не выводить, как будто этого не-символа вообще не было. И что должен делать я?

Вот тебе пример разного отображения:

asdf

as?df

Неопределенный стандартом символ между 's' и 'd'. Если юзер дважды сдвинет курсор от начала строки вправо, а потом нажмет Delete, то какой символ в файле я должен удалить: 'd' или неопределенный? Это зависит от отображения неопределенных символов Х сервером, то бишь от реализации, поведение которой в данной ситуации стандартом неопределено.

Другими словами: в моей программе будет бага (что недопустимо в коммерческих программах), исправить которую я не смогу из-за неопределенности стандарта. Весело, правда?

Только не надо меня спрашивать, как реализуют поддержку юникода все остальные. Я вполне допускаю, что ХFree86/xorg сервер всегда печатает вместо неопределенного символа то, что возвращает в XFontStruct->default_char. Но гарантий мне по этому поводу никто не даст. И я не знаю, как поступает GDI Windows в таких случаях.

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

Это были недостатки юникода с программной точки зрения. С пользовательской имеем 2 байта на символ для русского (вместо одного) в любом случае и тормоза при использовании utf8. И, повторюсь, никаких преимуществ для тех, кто знает только русский (или русский + английский).

Я понятно объяснил?

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

Вы очень интересно рассказали про недостатки уникода (и неопределенность в отображении символов). Про накладные расходы переменной длины символа тут уже упоминалось выше. Но Вы забыли одну очень важную вещь. Компутеры сегодня имеют очень вредную привычку - обмениваться данными по сети. И вот тут все недостатки 8-битных кодировок встают в исполинский рост. Не знаю кого как, а лично меня слегка достали вскрики "дайте патч для gaim, дайте патч для xmms". Все это - благодаря 8-битным кодировкам (did I say "thank you"?). Если Вы дадите подписку о том, что Ваш комп никогда не будет присутствовать в сети, никогда не выложите ни одного mp3 файла - я признаю Ваше право иметь на Вашем компе ту кодировку, которую Вам удобно использовать. А иначе я должен относиться к Вам как к человеку, случайно или намерянно создающему проблемы для окружающих. Да, Вы можете потребовать, чтобы проги, работающие с теми данными, которые имеют хотя бы малейший шанс оказаться в сети - работали бы в уникоде. А "остальные" - в Вашей кодировке. Но скажите - в какой кодировке должен быть README.ru, который Вы завтра выложите в CVS проекта на sourceforge?

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

> Вы очень интересно рассказали про недостатки уникода...

Вы очень красиво привязали проблему отсутствия стандарта на сетевую русскую кодировку к 1-байтным кодировкам. Это называется "в огороде бузина, а в Киеве -- дядька".

Вот было у нас уже 4 кодировки: koi8-r, cp1251, cp866, iso8859-5. Теперь стало у нас 5 кодировок: все вышеперечисленные + utf8. Т.е. последняя здесь -- на равных. Каким образом она поможет избежать проблем с разным кодированием? Если станет стандартом? В этом случае -- да. Но то же самое верно и для любой 1-байтной кодировки. Например, для cp1251.

Чем cp1251 хуже utf8? Давайте ее продвигать как стандартую русскую сетевую кодировку, и не будет у нас зоопарка. Она очень экономична: всего 1 байт на символ для русского. Для диалапа (весьма актуального на бескрайних просторах моей страны) 1 байт на символ все же лучше, чем 2 байта.

Итак, вопрос остается в силе: why utf8?

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

> Это называется "в огороде бузина, а в Киеве -- дядька".

Увы, нет. Это все про кодировки для обмена данными.

> Теперь стало у нас 5 кодировок: все вышеперечисленные + utf8. Т.е. последняя здесь -- на равных

У кого у Вас? У меня как человека, живущего на планете Земля - был мульон кодировок - стал уникод (какой именно UTF - вопрос отдельный). Это, разумеется, если бы народ согласился выкинуть это мульон - но это вопрос времени, я верю.

> Чем cp1251 хуже utf8? Давайте ее продвигать как стандартую русскую сетевую кодировку, и не будет у нас зоопарка.

Он будет у меня в мессенжере (как он уже есть у меня в мейлере). Мне иногда надо использовать знак фунта про общении с почти-местным населением. Где он в 1251? Или я должен хитроумно переключать кодировку своего мессенжера в зависимости от того, кому и что я пишу (не дай бог, если мне про фунты придется сообщить Вам)? Что мне нравится в жаббере по сравнению с мейлером (сорри за некорректное сравнение, но все же) - там НЕТ меню encoding (в аське его тоже нет - зато там есть гайки, оставленные 8-битным прошлым). Это выигрыш в usability.

> Для диалапа (весьма актуального на бескрайних просторах моей страны) 1 байт на символ все же лучше, чем 2 байта.

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

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

> Чем cp1251 хуже utf8?

Tem chto nekotorym lyudyam nuzhno pisat' ne tol'ko po russki. U menya naprimer v GAIM mirno sosushchestvuyut kitayskiy, koreyskiy, kirillica i angliyskiy. Kakoy eshche est' vubor krome Unicode/utf8?

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

> Инструкция по сборке с домашнего сайта подходит ?

Подходит.

Я вот недавно, как мне думалось, выкачал всё, что нужно для сборки 2.8. Начал собирать с помощью garnome-2.8.0 - фигушки! Во-первых, пришлось докачать порядочное кол-во пакетов с ftp.gnome.org (хотя garnome делает это сам, но тем не менее). Во-вторых, пришлось делать свои исправления в исходниках, так как были мелкие ошибки и описки в коде разных пакетов, например, epiphany, evolution. Может я и неправильно чего-то делаю, но в конце-концов всё заработало!

> И вообще не слишком сложно 2.8 поставить если у меня уже 2.4 стоит?

Поставить не сложно, только он поверх не встанет, а встанет рядом. Я попробовал так ставить (поверх) - запорол свой 2.4. И вообще, мне кажется, лучше всё-таки юзать garnome, меньше рутинной работы.

Правьте меня, правьте, если я не прав :-) Хотя, руки уже не исправить.

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