А что именно напугало? Баги? С каких это пор посетителя ЛОРа можно напугать багами? Неполная локализация - жалуйтесь в gnome-cyr@gnome.org

> svu, оцените скриншот. А потом подпись - отдельно:

Вы меня с К48 не перепутали?:)

>> "Неполная локализация - жалуйтесь в gnome-cyr@gnome.org"

В том-то и дело, что это не неполная локализация. Я уже давным-давно как-то про это писал. Это неправильная трактовка программами переменных LC_*. У меня они настроены так, чтобы везде иметь возможность читать/писать в том числе и по-русски, но интерфейс чтобы был англоязычный. Многие проги таких ньюансов не различают. Та же самая фигня у меня была когда-то с fluxbox, но там это всё решилось патчем в дюжину строк, а тут этим дело, мне кажется, не обойдётся - слишком много прог надо патчить.


>> "Баги?"

Баг багу рознь. _Такие_ баги - это, имхо, черезчур.


Повторюсь ещё раз. Десктопа под линукс не будет никогда. Потому что для создания нормального интегрированного десктопа требуется приличная команда с соответствующим менеджментом, проектированием и тестированием. Это возможно только при условии если этим займётся какая-нибудь _коммерческая_ фирма с целью выпустить _коммерческий_ десктоп. Пока этого не будет - на никсах всю дорогу будут рулить небольшие проги написанные командой в один-два человека и заточенные под какую-нибудь одну задачу (юникс вей).

Поддержка Гнома Саном - в данном случае, имхо, - полная лажа. Сан всего-навсего рассчитывет если повезёт, то заработать денег не вкладывая практически ничего. Даже выбор гнома обусловлен именно этим. Если бы даже гном был полным фуфлом, а KDE - конфеткой (что, в общем-то, признаю, на мой взгляд, совсем не так), то всё равно был бы выбран Гном, по причине того, что лицензирование Qt требует определённых затрат, а значит вложений, планирования и ответственности. А в случае с гномом Sun совершенно спокойно может через полгода-год, наигравшись, забить на него, не потеряв при этом ничего, потому что, я уверен, что те деньги, что они подкидывают комьюнити на его разработку - это сущие копейки по сравнению с тем что потребовалось бы вложить в нормальную организацию собственной разработки.

> Это неправильная трактовка программами переменных LC_*. У меня они настроены так, чтобы везде иметь возможность читать/писать в том числе и по-русски, но интерфейс чтобы был англоязычный.

Очень интересно. По моему скромному мнению, нетривиальные комбинации LC - это все-таки довольно тонкие баги. У меня стоит локаль LANG=en_US.UTF-8 - и я прекрасно имею все прелести английского интерфейса с возможностью читать-писать русский язык. А у Вас как?

> Такие_ баги - это, имхо, черезчур.

Имхо эти баги вполне логичны в среде, разрабатываемой, в основном, англоязычными (и относятся к разряду нетривиальных - потому что очень немного людей живут в такой среде). Единственный способ их пофиксить - доложить в багзиллу. Пробовали?

> Сан всего-навсего рассчитывет если повезёт, то заработать денег не вкладывая практически ничего.

Позиция сана действительно местами сомнительна, но я все-таки Вас прошу просмотреть на количество адресов @sun.com в сырцах гнома. Особенно - в разделе accessibility. В разделе документации.

> лицензирование Qt требует определённых затрат, а значит вложений, планирования и ответственности

Мы будем сравнивать цену лицензии на Qt с зарплатами сановцев, работающих над гномом?

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

В этом и есть смысл НОРМАЛЬНОЙ бизнес-модели для открытого софта. Ты добавляшь в ящик совсем немного - а делаешь деньги на всем содержимом ящика. За счет того, что в ящик добавляет куча народа и компаний - эта модель может работать. Скажите, а Вы считаете Alt аморальной конторой на основании того, что большая часть Alt Linux не написана его сотрудниками?

>> "нетривиальные комбинации LC - это все-таки довольно тонкие баги."

Да ничего там, имхо, тонкого. Просто локаль интерфейса, если не задан LC_ALL должна браться из LC_MESSAGES - по крайней мере у меня это почти всегда и везде работало.

>> "Имхо эти баги вполне логичны в среде, разрабатываемой, в основном, англоязычными"

Я имел в виду кнопку "Up". Тот кто это кодил - он на неё сам жать пробовал?

>> "Скажите, а Вы считаете Alt аморальной конторой"

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

>> "Мы будем сравнивать цену лицензии на Qt с зарплатами сановцев, работающих над гномом?"

Давайте сравним. Вы знаете з/п сановцев, работающих над гномом?

> Да ничего там, имхо, тонкого. Просто локаль интерфейса, если не задан LC_ALL должна браться из LC_MESSAGES - по крайней мере у меня это почти всегда и везде работало.

Я же сказал - там тонкость не техническая, а статистическая. Очень немного народу (известного мне) пользуется несогласованными LC. Возможно, никто не репортил такие проблемы. Вы попробовали из доложить в багзилле?

> Я имел в виду кнопку "Up". Тот кто это кодил - он на неё сам жать пробовал?

Не знаю:) Что такое "это" в компонентной архитектуре? Контейнер? Компонент? bonobo?

> Я просто считаю маловероятным при таком подходе сделать что-то стоящее.

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

> Давайте сравним. Вы знаете з/п сановцев, работающих над гномом?

Вряд ли сильно меньше 50КЕвро в год (в Ирландии, да еще в Дублине). Сколько стОит лицензия Qt?

>> "Вряд ли сильно меньше 50КЕвро в год"

И много их, таких разработчиков? И вы точно знаете, что они за эти деньги ничем больше, кроме разработки гнома не занимаются?

> И много их, таких разработчиков? И вы точно знаете, что они за эти деньги ничем больше, кроме разработки гнома не занимаются?

Скажем так, на Гвадеке я сановских пиплов как минимум десяток видел. Возможно - их больше. Какой процент их рабочего времени уходит на гном - я не знаю. Вообще, в Дублине находится сановский десктопный офис. Я не знаю, что там еще разрабатывают, кроме ООо и гнома (направление CDE, вроде, не особенно развивается - я не видел принципиальных отличий в разных версиях). Вряд ли на долю гнома приходится 1% усилий этого офиса...

Вы не ответили на мой вопрос по поводу стоимости лицензии Qt

> Вряд ли сильно меньше 50КЕвро в год (в Ирландии, да еще в Дублине). Сколько стОит лицензия Qt?

Смотря на что и сколько =) Одна линуховая энтерпрайз - $2500 с носа. В год.

http://www.trolltech.com/products/qt/pricing.html

> Язык С, не будучи ОО, _годится_ для ОО программирования. Не сильно меньше, чем ОО С++. Примеры - windows.h, gobject, xlib.

Согласен, что годится. Здесь можно даже вспомнить, и про первый компилятор для C++, создававший C-код из C++ -кода, и загаловочный файлы COM, где таблица виртуальных методов имитировались также на голом C. Но речь идет о другом. Считаю, что заниматься OO-программированием (и ООА, и OOD) значительно проще, если сущности этого самого OO поддерживаются на уровне языка.

Безусловно, стандартный C++ не так идеален. Там не хватает пары вещей, и мне, например, нравятся такие расширения Qt как сигналы и слоты (напомниающие делегаты .NET). Но как средство OO-программирования С++ - лучше, чем просто C.

С другой стороны, я видел код очень многих программеров (на C, C++, Delphi, C#, Java). Часто то ли там использовалось OO? Нет, довольно редко, даже если бы в нем был смысл. Причем, это - люди с вышим техническим образованием (специальность ПС), пару-другую лет занимающихся оффшором.

Может быть, вопрос даже следует поставить в иную плоскость.

Для какого способа ОО-программирования годится "просто C"? Для использования библиотек (1), или для их создания (2)?

Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

>> "Там не хватает пары вещей, и мне, например, нравятся такие расширения Qt как сигналы и слоты"

Советую взглянуть на:

http://www.boost.org/doc/html/signals.html

великолепная штука без всяких трольских извратов с "расширениями С++".

Да, но у этого решения на шаблонах (см. также libsig++, являющийся основой для gtk--), есть один недостаток - оно может не очень хорошо поддерживаться некоторыми компиляторами. gcc3 обычно с такими штуками работает "на ура", а вот например у msvc6, помнится, были проблемы.

> Язык С, не будучи ОО, _годится_ для ОО программирования. Не сильно меньше, чем ОО С++. Примеры - windows.h

windows.h - OO-программирование? Не смешите =)

А вот из удачных примеров могу еще вспомнить QNX Photon.

> Советую взглянуть на: > http://www.boost.org/doc/html/signals.html > великолепная штука без всяких трольских извратов с "расширениями С++".

Спасибо! Это - очень полезная ссылка для меня. Прежде не знал о ней.

И еще. Тролльские "извраты" ведь не ограничиваются сигналами и слотами - там еще и метаданные всякие, для GUI-дизайнеров.

Re:

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

Вообще-то, создавать иерархию _объектов_ средствами C++, видимо, ничуть не легче. А GObject - неплохая подложка для сотворения всяких нетривиальных штуковин, посмотрите на наработки А. Бокового в рамках Midgard2. И возни с GObject'ом, в общем немного

Re:

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

Она, возможно, и удобна. Хотя совсем необязательна. Повторяю, я задал в терминале именно тот шрифт, который хотел.

Re:

> Насчёт gnome-terminal - я своими глазами наблюдал, как он показывал даже не тот шрифт, который выдавал fc-match вызванный с теми же параметрами, которые были в его фонтовом диалоге. (Учитывая вышесказанное это даже нельзя считать багой)

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

Re:

> > Мне перечислять, чем скриновский терминал отличается в худшую сторону от табов?

> А мне перечислять, чем табы хуже screen'-а?

Давайте, перечисляйте :-)

> И мерзкое пищание в PC-спикер - это последний тип нотификации

> RTFM. Keywords: active icon

Я ж попросил не лечить меня, а? :-)

Я знаю, что искейп последовательностями можно модифицировать свойства _окна_: заголовок, иконку и т. п. Но, повторяю, "панель окон" ("панель задач") в обычном состоянии у меня _скрыта_. Я ее НЕ ВИЖУ. Ваши предложения? ;-)

Да, и не надо мне навяливать bash :-). У меня zsh здесь :-)

Re:

А Александр Боковой давеча на GObject'е динамическую типизацию с загрузкой типов из внешних источников (XML, SQL) замутил. Будем соревноваться, что гибчее? :-)

А я где-то вел речь о гибкости? =)

И вообще, для вышеописанных извратов имхо доктор все же прописал Java.

Re:

Джава? А её-то каким боком в _динамическую_ типизацию? :-)

Извиняюсь, не понял, о чем идет речь. Я думал вы о рефлекшенах всяких =)

Ладно, тогда .NET с его System.Reflection.Emit. Это имхо переплюнуть сложно.

> Я знаю, что искейп последовательностями можно модифицировать свойства _окна_: заголовок, иконку и т. п. Но, повторяю, "панель окон" ("панель задач") в обычном состоянии у меня _скрыта_. Я ее НЕ ВИЖУ. Ваши предложения? ;-)

У вас же sawfish. Просто повесьте хук на изменение пропертей. Или там что-то сломано?

Re:

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

Re:

:-). Это переплюнуть можно. Если знать, куда плевать :-)

Эээ, в smalltalk? =)

Хотя вот кстати подумалось, что если скомбинировать этот ваш "динамический GObject" с libtcc (который Tiny C Compiler), то пожалуй что и да, очень даже можно...

письмо спамобойка не прибила?

> Одна линуховая энтерпрайз - $2500 с носа. В год.

И эти копеечные деньги должны заставить сан более ответственно подходить к организации разработок в области десктопа???? Три раза "ха"!:)

> Считаю, что заниматься OO-программированием (и ООА, и OOD) значительно проще, если сущности этого самого OO поддерживаются на уровне языка.

А я не спорю. Просто С++ не годится на роль той самой Silver Bullet. И Java не очень годится. И С#. А человек - существо адаптивное, быстро привыкает в ОО программированию на не-ОО языке.

> Для какого способа ОО-программирования годится "просто C"? Для использования библиотек (1), или для их создания (2)?

> Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

> windows.h - OO-программирование? Не смешите =)

Да, это ОО подход. Местами криво реализованный - но тем не менее ОО. Что такое окно, если не объект, у которого реальное содержимое запрятано от глаз за безликим Handle?

> А вот из удачных примеров могу еще вспомнить QNX Photon.

Возможно. Я не видел их API, ничего не могу сказать...

Это не `OO' подход. `Объектный', но не `Объектно-ориентированный'. Потому что есть инкапсуляция, но нет наследования.

> Потому что есть инкапсуляция, но нет наследования.

Возможно, тут Вы правы. Я не помню, как там дела с наследованием (100 лет не видел в глаза windows.h). Ну я же признал уже - местами кривоватая реализация:)

> Это не `OO' подход. `Объектный', но не `Объектно-ориентированный'. Потому что есть инкапсуляция, но нет наследования.

Строго говоря, сабклассинг можно обозвать наследованием, т.к. можно перехватывать window messages и обрабатывать их по своему желанию. Так что полиморфизм имеет место быть.

> письмо спамобойка не прибила?

Не прибила. А вот я до вас не могу достучаться:

... while talking to time.fannet.ru.:

>>>>>> DATA <<< 550 5.0.0 error 377 554 5.0.0 Service unavailable

>> Для использования библиотек (1), или для их создания (2)?

>> Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

> Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

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

таки про мышление...

2 :anonymous (*) (22.05.2004 2:11:40)

> Решение, принятое на основе неполной информации не может быть результатом ЛОГИЧЕСКОГО мышления.

Шагом марш в школу, в 5-й класс, на урок математики. Тема -- математическая индукция.

> Пример нелогического подхода к мышлению -- человеческое мышление.

ЧелОвеческое, я бы сказал.

Ладно, хватит страдать оффтопиком =) Модераторы - хвала им! - уже почистили тред. Пусть так и будет. А для обсуждения таких вещей есть другие места (и емэйл).

> А я не спорю. Просто С++ не годится на роль той самой Silver Bullet. И Java не очень годится. И С#. А человек - существо адаптивное, быстро привыкает в ОО программированию на не-ОО языке.

Полностью согласен. Для одних задач хорош C++, а для других - Java или C#. И вряд ли, существует "золотая середина"...

> Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

Вот, здесь хорошо за меня ответил int19h - поддерживаю его.

_____

Могу затронуть еще одну прелюбопытную тему :)

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

Так что, боюсь, одним gobject не обойтись! :)

Кстати, на сановском сайте java.sun.com изредка бывают очень интересные статьи на эту и похожие темы.

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

А ты уже обучился вырезать аппендицит?
Нет?
Тогда с точки зрения моей жены, которая хирург, ты дебил...

Ты уже обучился тепловозы водить? Нет?
С точки зрения машиниста - ты дебил

Если исходить из твоей логики то выходит именно так

> Обращаю внимание - речь шла о том, что если _использовать_ такие библиотеки вполне можно, то вот _создавать_ их - очень тяжело.

Извините, я Вас неправильно понял. Да, создание ОО структуры на С - процесс тяжкий и муторный, это правда. Но ведь у нас уже есть GObject:)

И компилятор действительно не очень помогает - одна надежда на правильные макросы (которые, увы, в С очень тупы и ненадежны).

Да, не все в порядке в датском королевстве - но в мире GObject жить вполне можно...

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

Это очевидно. Кто, вообще, тут сказал, что ОО - венец программистской мысли?:)) Прогресс - бесконечен и неизбежен. Неотвратим, я бы сказал:))

Да кто ж спорит, что можно. А на макросах я вам и на nasm'е объектно-ориентированное наваяю - тоже можно будет =)

Но все равно это сродни закручиванию шурупов кувалдой, имхо...

> Да, создание ОО структуры на С - процесс тяжкий и муторный

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

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

Да, создавать эти классы - тоже не пикник. Правда, немного упрощает жисть gob. А использование - действительно достаточно просто и ненапряжно...

про обучение

> А ты уже обучился вырезать аппендицит?

Давайте таки не путать 1) базовые знания ( a la грамотность, в том числе -- и компьютерная ) и специальные ( a la квантовая теория поля ), 2) _способность_ к обучению и уже накопленные знания.

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

Нет, так не выходит.

в гамаке, стоя, в противогазах...

> Да, создавать эти классы - тоже не пикник.

У меня складывается впечатление, что большинство разработчиков GNOME родом из Китая -- сами себе создают проблемы, а потом героически решают.

Куда ни глянь -- везде "закат Солнца вручную"...