LINUX.ORG.RU

GNOME - обзор планов


0

0

В документе "GNOME Community Road Map" обобщаются наиболее интересные детали планов по развитию проекта GNOME в будущем (улучшения версии 2.6, планы для версии 2.8, идеи отложенные на далекое будущее).

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

anonymous

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

Особенно интересен последний абзац:

> * GNOME is currently implemented in C, with language bindings > implemented for use in third-party applications. There is some > consensus in the community that adoption of a higher-level > language and runtime would be beneficial to the development of > the desktop. > Java and C# have been proposed as alternatives. The community > is currently discussing the technical, political, and legal > ramifications of adopting these languages into the desktop.s

alexros
()

Текст новости опять содран с новостей OpenNet.ru: http://www.opennet.ru/opennews/art.shtml?num=3963

Если и берете новости, то указывайте ссылку на первоисточник или хотябы переписывайте текст.

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

Ну все, перепишут на C#, и будет нам щастье. Блин, делать людям нечего... Лучше уж на C++.

Похоже, людям некуда девать производительность машин, кроме как на рюшечки всякие :-/

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

2Spectr> Не флэйма ради, но почему у вас высоуровневые языки (Java, C#)ассоциируются сразу с рюшечками? Переход на эти языки позволил бы проекту развиваться гораздо быстрее. Самое главное, что для Java есть среды (IntelliJ IDEA, Eclipse, Re#), которые поддерживают refactoring

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

Никак не врублюсь почему именно Java и C#? Почему не C++, который знает намного больше народу или Питон? Ааа, догадался :) Mono - это же детище того же Ximian, вот они его и проталкивают.

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

> но почему у вас высоуровневые языки (Java, C#)ассоциируются сразу с рюшечками?

не из-за рюшечек, ессно, а из-за скорости приложений, написанных на них. Если будет компилироваться Java в native bytecod через GCC - не сталкивался, но вроде можно такое, то тогда пожалуйста. IMHO такие системы надо все-таки писать на компилируемых языках, не для виртуальных машин. А то ось - на вирт. машине, десктоп - тоже, приложения - тоже. В результате получится подмена более высоким уровнем абстракции за счет производительности :-/

Скорость разработки и на C++ можно поднять.

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

Питон они рассматривали/рассматривают. Насколько я понял, боятся IP. Вообще, с этим IP просто идиотизм получаемся. Боимся Java, потому что IP принадлежит Сану и он может сделать козью морду. Боимся C#, потому что IP принадлежит сами-знаете кому и он может... Боимся Питона, потому что IP явно никому не принадлежит, а патентный анализ почему-то не сделать. Короче, лично меня уже достала возня. Я лично только изредка выступаю против включения С# в зависимости гнома. Но пока им слабО - моно еще не доработан на фряхе (разве что BaT им поможет - он, вроде, занимался).

С++ is not an option потому что не managed (ну, если не брать его реализацию на Моно). В С++ можно испортить память как и в С. А вот Вы попробуйте это сделать на жабке...

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

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

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

API для других языков и сейчас делается. Я так понял новыек проги будут писать на этих языках.

ЗЫ: Вот непонятно, если они так боятся Java и C#, то почему бы им не взять Scheme, тем более, что есть GNU-шная реализация - Guile?

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

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

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

> то почему бы им не взять Scheme, тем более, что есть GNU-шная реализация - Guile?

Это в ответ на призывы FSF и Столлмана о том, что открытые проекты надо писать на лиспе, т.к. он, как грит Антихрист, ортоганальный язык :)

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

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

scheme и lisp -два разных языка с похожим (отсутствующим) синтаксисом.

Это не чистые функциональные языки.

Гному лучше подойдёт logo.

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

Ни Lisp, ни Scheme не являются чисто функциональными языками, и никто вам не запрещает мешать в программах, императивный и функциональный стили. Другой вопрос, что эти языки таковы, что поощрают к написанию программ в функциональном стиле. Испальзование этого стиля ИМХО наиболее эффективно при реализации логики обработки данных. BTW, Guile имеет достаточно развитые средства для объектно-ориентированного программирования.

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

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

Не программеров, а кодеров, они умеют писать на васике, но не проектировать программы.

И еще вопрос - есть ли какие нибудь идеи/проекты по автоматизации создания wrapper-ов? В смысле, чтобы определения API писались на каком-нибудь языке (типа IDL), а по этому олисанию затем гененировать wrapper (ну и ручная правка/добавление, чего генератор сделать не смог). В Gtk есть ведь объектная модель не привязанная к конкретному языку.

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

> нет это как раз для тебя - самое оно.Тем более чувствую что ты проникся уже =)

Да не, ты на самом деле посмотри. Правда черепашка прикольная?

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

>а не, ты на самом деле посмотри. Правда черепашка прикольная?

нет чтобы совсе прикольно было надо найти atari и на него logo поставить- так logo не рулит =))))

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

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

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

в pygtk так и построен поэтому делать враперы для gobject based библиотек достаточно просто

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

> Я лично только изредка выступаю против включения С# в зависимости гнома.

А что, там сейчас серьезный перевес в пользу C# против явы?

При всей моей нелюбви к яве как языку (о платформе речь не идет) - я бы предпочел увидеть там ее, а не шарп. С учетом последних поползновений майкрософта в плане патентов... да и вообще, неплохо было бы, нативная гткшная морда + все навороты J2EE. И CORBA туда намного лучше впишется.

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

Кстати есть wrapper гномовских библиотек для Java, работает как с jdk, так и с gcj.

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

Фуй какая некомпетентность, gkrellm - это же клиентская тулза, а EJB - для сервера!:) На EJB мы сделаем gkrellm-daemon. А мородочку к нему - на swing+javastart. И будет нам щастье. Заняться, что ли, на выходных?...:)

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

> Фуй какая некомпетентность, gkrellm - это же клиентская тулза, а EJB - для сервера!:) На EJB мы сделаем gkrellm-daemon.

Сие разумеется и имелось в виду =) Ну да вы меня поняли...

А интересные однако в голову приходят мысли по мере прочтения книжки по EJB, правда? ;)

> А мородочку к нему - на swing+javastart.

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

(кстати, вот IBM'овцы тогда со своим SWT обломаются ;)

> И будет нам щастье.

Ох, боюсь, не оценит народ JBoss в депах gkrellm... =)

> Заняться, что ли, на выходных?...:)

На этих выходных вы обязались прикрутить к gconf'у Xrm! ;)

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