LINUX.ORG.RU

Разработчики Debian говорят о возможных проблемах при переходе на GTK 3.0 и GNOME 3

 ,


0

0

Разработчики Debian представили предварительный список возможных проблем, которые могут возникнуть при интеграции GTK 3.0 и GNOME 3 в дистрибутив.

Релиз GTK 3.0 запланирован на март 2010 года, а релиз GNOME - вскоре после этого. Поэтому перед разработчиками Debian встала проблема: интегрировать в будущий релиз дистрибутива новую, не совсем отлаженную, версию или остаться на ветке 2.x, но столкнуться с проблемами длительной поддержки релизов Glib, GTK и GNOME, развитие и официальная поддержка которых будет прекращена.

В списке рассылки приводятся меры, которые упростят переход на GNOME, и обсуждается совместимость приложений с будущей GTK 3.0, в частности:

  • GLIB и GDK/GTK+ - предлагается компилировать пакеты с отключенным режимом совместимости с ранними версиями GTK (без устаревшего кода). Особых проблем не ожидается.
  • ESOUND - будет убрано, в связи с чем предлагается портирование на libcanberra/GStreamer
  • GCONF - планируется заменить с помощью dconf
  • LIBBONOBO / LIBBONOBOUI - планируется полное удаление, что является весьма нелегким делом.
  • LIBGNOME / LIBGNOMEUI - планируется удаление.
  • LIBGNOMECANVAS - объявлен устаревшим.
  • GTKSOURCEVIEW 1.x объявлен уставершим, его планируется заменить на GTKSOURCEVIEW 2.x.

и ряд других.

>>> Подробности

★★★★★

Проверено: hibou ()
Ответ на: комментарий от BeerSeller

> И вопрос ЗАЧЕМ ФОРМУЛЫ в конфиге O_O

Я так понимаю, что гном и его реестр разрабатывался для тех, кому формулы не нужны?

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

>> И вопрос ЗАЧЕМ ФОРМУЛЫ в конфиге O_O

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

Вообще-то насколько я понимаю обычно внешний скриптинг программы с конфигом не мешают. По крайней мере в том проекте где я щаз работаю есть и то и то.

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

> Вообще-то насколько я понимаю обычно внешний скриптинг программы с конфигом не мешают.

А вот в других случаях -- emacs, netscape/firefox, ... конфигом служит скрипт, и у этого тоже есть некоторые преимущества.

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

Формулы в _конфиге_ не нужны никому. Так же как сиквеловские запросы на вебовых страничках или духовые инструменты духовенству.

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

> А вот в других случаях
... И он привел примеры архитектурных чудовищ.

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

>> Вообще-то насколько я понимаю обычно внешний скриптинг программы с конфигом не мешают.

>А вот в других случаях -- emacs, netscape/firefox, ... конфигом служит скрипт, и у этого тоже есть некоторые преимущества.

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

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

> Формулы в _конфиге_ не нужны никому.

Как минимум, формулы в конфиге позволяют поменять значение ключика простым echo "path.to.key=value" >> config без парсинга, а еще позволяют поменять несколько ключиков, по условию, ...

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

>echo "path.to.key=value"
>echo "path.to.key=value"

>echo "path.to.key=value"


path.to.key=value
path.to.key=value
path.to.key=value

Да да :)

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

>> Формулы в _конфиге_ не нужны никому.

>Как минимум, формулы в конфиге позволяют поменять значение ключика простым echo "path.to.key=value" >> config без парсинга, а еще позволяют поменять несколько ключиков, по условию, ...

А что мешает те же формулы в gconf-овских ключах хранить?

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

> как-то невнятно сделано: то что в конфигураторе внесено пропадает после перезагрузки пока ты это явно в ~/.emacs не опишешь. По сути, конфигуратор там сделан с целью копипейста параметров оттуда в ~/.emacs.

подозреваю, что достаточно в конец самописного конфига добавить что-то вроде (eval-from-file emacs-persistent-config) и научить emacs-persistent-config конфигуратор сохранять результат в emacs-persistent-config.

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

s/научить emacs-persistent-config конфигуратор/научить конфигуратор/

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

>> как-то невнятно сделано: то что в конфигураторе внесено пропадает после перезагрузки пока ты это явно в ~/.emacs не опишешь. По сути, конфигуратор там сделан с целью копипейста параметров оттуда в ~/.emacs.

>подозреваю, что достаточно в конец самописного конфига добавить что-то вроде (eval-from-file emacs-persistent-config) и научить emacs-persistent-config конфигуратор сохранять результат в emacs-persistent-config.

Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.

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

> path.to.key=value
К формулам это не относится.

> позволяют поменять несколько ключиков, по условию, ...

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

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

Правильно, назвать этот файл скриптом, и оставить систему конфигурирования наконец в покое. Это - не она.

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

> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.

Но техносноб может захотеть, чтобы часть переменных сохранялась, а часть нет. И вот для этого ему и предлагается самому написать (eval-from-file emacs-persistent-config), а посли этой строчки -- то, что надо перезаписать.

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

> Правильно, назвать этот файл скриптом, и оставить систему конфигурирования наконец в покое. Это - не она.

А система конфигурирования вне этого файла будет равна нулю. Зачем тратить время еще на одну?

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

>> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.

>Но техносноб может захотеть, чтобы часть переменных сохранялась, а часть нет. И вот для этого ему и предлагается самому написать (eval-from-file emacs-persistent-config), а посли этой строчки -- то, что надо перезаписать.

Уже не в конец а в начало?

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

> А система конфигурирования вне этого файла будет равна нулю.
Значит, проблемы в консерватории архитектуры.

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

> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.

А потом были бы феерические глюки при апгрейде. Нафиг-нафиг.

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

>> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.

>А потом были бы феерические глюки при апгрейде. Нафиг-нафиг.

А ломка скриптов в ~/.emacs при апгрейде компонент чем-то принципиально отличается?

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

>>> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней.
>> А потом были бы феерические глюки при апгрейде. Нафиг-нафиг.

> А ломка скриптов в ~/.emacs при апгрейде компонент чем-то принципиально отличается?


1. Воспроизводимостью
2. Простотой workaround-а при проблемах (очистить ~/.emacs)

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

> Значит, проблемы в консерватории архитектуры.

А давайте честно скажем, какие будут проблемы, а?

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

А при имакс-лайк варианте конфига это уже становится проблемно.

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

>>>> Сохранение переменных между сессиями было бы в 1000 раз прямее и надежней. >>> А потом были бы феерические глюки при апгрейде. Нафиг-нафиг. >> А ломка скриптов в ~/.emacs при апгрейде компонент чем-то принципиально отличается?

>1. Воспроизводимостью

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

>2. Простотой workaround-а при проблемах (очистить ~/.emacs)

Удалить файл с persistent-переменными какбе должно быть нельзя по какой-то причине?

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

> А давайте честно скажем, какие будут проблемы, а?
Хочу я, допустим, как самодур, насадить корпоративный стандарт на размер отступа в редакторе...

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

> Хочу я, допустим, как самодур, насадить корпоративный стандарт на размер отступа в редакторе...

Ну это-то не проблема. В самом конце конфига добавляем еще (eval-from-file emacs-corporate-config) а дальше в зависимости от полититки этот emacs-corporate-config меняем.

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

> Хочу я, допустим, как самодур, насадить корпоративный стандарт на размер отступа в редакторе...

Не высасывай пальцы, они тебе ещё понадобятся!

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

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


Это ты на каком языке сказал?

>> 2. Простотой workaround-а при проблемах (очистить ~/.emacs)

> Удалить файл с persistent-переменными какбе должно быть нельзя по какой-то причине?


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

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

> Хочу я, допустим, как самодур, насадить корпоративный стандарт на размер отступа в редакторе...

Лучше: а вот хочу я сделать, чтобы юзер для ходьбы сюда юзал один прокси, для ходьбы туда -- другой, а во внешний мир -- третий. Есть еще родная локалка, куда ходить без прокси. Как это делается? Нетскейп тянет яваскриптовый файл, в котором записана функция, которая вычисляет прокси. (Кажись это даже эксплорер научился)

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

Кому нужны формулы в конфиге не будут использовать такую вещь как реестр, которую без regedit'а то толком не поправишь, а напишут свой парсер ini файлов с поддержкой формул. Благо на flex+bison оно пишется за 15 минут.

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

> Кому нужны формулы в конфиге не будут использовать такую вещь как реестр, которую без regedit'а то толком не поправишь, а напишут свой парсер ini файлов с поддержкой формул.

Собсно, к тому я постоянно и веду, что "реестр" удобен далеко не всем.

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

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

Кстати, замечательное реверс-определение - конфигурация это то, для чего годится реестр, оно должно понравится;)

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

> Собсно, к тому я постоянно и веду, что "реестр" удобен далеко не всем.
А есть вещи поголовно удобные для всех и всегда ? :)))
А если, принять ваши взгляды за основу ,то думаете некому будет "метать икру" на форумах против вас ? :)))

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

>Кстати, замечательное реверс-определение - конфигурация это то, для чего годится реестр, оно должно понравится;)

Только мне оно кажется несколько надуманным?

для преодоления трудностей их надо сперва создать

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

>подозреваю, что достаточно в конец самописного конфига добавить что-то вроде (eval-from-file emacs-persistent-config) и научить emacs-persistent-config конфигуратор сохранять результат в emacs-persistent-config.

Оффтоп.

Есть такой пакетик initsplit, которым я активно пользуюсь. Он умеет раскидывать переменные и фейсы, выставленные в конфигураторе, по разным конфигурационным файлам в зависимости от регулярного выражения над именем этой переменной. У меня, например, автоматом раскидываются "^jabber-", "^gnus-", "^slime-", " "^\\(preview\\|font-latex\\|latex\\|tex\\)-" и т. д. Весьма удобно, так как я для каждого крупного пакета держу конфигурацию в своем файле. Думаю, что если поиспользовать регулярное выражение, охватывающее все переменные и фейсы (или большую часть), то они автоматом все туда будут скидываться.

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

>Ну это-то не проблема. В самом конце конфига добавляем еще (eval-from-file emacs-corporate-config) а дальше в зависимости от полититки этот emacs-corporate-config меняем.

Вдогонку. Это лишнее, пожалуй. (load "emacs-corporate-config") достаточно будет. :)

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

>> Собсно, к тому я постоянно и веду, что "реестр" удобен далеко не всем.
> А есть вещи поголовно удобные для всех и всегда ?


Нету.

> А если, принять ваши взгляды за основу ,то думаете некому будет "метать икру" на форумах против вас ?


Я не практикую безоговорочных всеобъемлющих решений.

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

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


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

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

> Я не практикую безоговорочных всеобъемлющих решений.

Кстати, другие тоже придерживаются подобных взглядов.
Хотя,практические результаты взглядов куда более интересней бесплодных гипотез:)))

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