Всеравно все эти панели не нужны... А какие-то мартышки их ещё и переписывают по тыще раз, да добавляют всякие ненужные функции.

Националисты тоже не нужны, а поди ж ты, ты есть :}

Тонкий ты человек...

Но ведь правда же. Я уже писал в девелопменте, помню, ТСу, но оттуда удалили якобы за разжигание флейма. Но по тому треду выяснилось, что так считаю не только я :).

Что-то мне подсказывает, что в перспективе LXDE скатится в третьегном^Wнефункциональное тормозное говно

С чего бы это? Vala - тормоз?

С чего бы это?

С подхода к разработке. Вменяемые разработчики не переписывают с нуля продукт ради Нового-Крутого-Язычка.

С подхода к разработке. Вменяемые разработчики не переписывают с нуля продукт ради Нового-Крутого-Язычка

Вменяемые разработчики не пишут прикладные задачи на чистом C. Vala, кстати, транслируется в C, так что различия в скорости должны быть незначительны.

Кстати, там еще и конфиг на xml-е теперь.

Запустить, не удалось, к сожалению. Падает с SIGFPE.

Все правильно сделал. Писать гуй на не ООП языке в 21 веке крайне глупо, ящитаю.
Си можно оставить только в критичных байтоё*ских местах. Типа там ядро например.

Напиши нескучный DE на питоне ._.

Вменяемые разработчики не пишут прикладные задачи на чистом C.

Об этом думать надо было лет 6 назад. А учитывая, из какого проекта растут ноги у lxpanel, то и вовсе лет этак 10 назад. Сейчас же имеем ситуацию: ядро панели написано, оттестировано, работает. И поэтому абсолютно похрен, на чем оно написано.

vala + libwnck = lxpanel2 (комментарий)

Тс, ты сейчас батхёрт вызовешь у ТС :).

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

Гм. Ты осознаешь, что миграция на другой язык == переписывание всей программы с нуля?

Они потратят год на то, чтобы довести этот проект до более-менее работоспособного состояния, потеряв по пути половину возможностей изначального продукта. Т.е. на протяжении многих месяцев у них будет картина, когда на развитие старой версии сил уже нет, а новая еще не готова. Это абсолютно не сопоставимо с ничтожными затратами на развитие и поддержку нескольких *.c файлов. Заметь, мы говорим об ядре панели, а не о апплетах. Апплеты вполне можно было бы один за другим переписать на vala, и это ничуть не сказалось бы продукте — он в любой момент оставался бы целостным и работоспособным.

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

Это с чего бы?

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

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

Это абсолютно не сопоставимо с ничтожными затратами на развитие и поддержку нескольких *.c файлов

Если речь о «нескольких *.c файлах», то их переписывание займет мало времени, зато куча проблем отпадет.

facepalm.vala

Если речь о

Речь идет о полностью новой программе, не имеющей ничего общего со старой, кроме названия.

Речь идет о полностью новой программе, не имеющей ничего общего со старой, кроме названия

Ты так говоришь, как будто это что-то плохое.

В самом деле, не вижу проблемы. Если переписывание программы положительно скажется на скорости и лёгкости дальнейшего её развития, то почему нет? И потом, вы же всё равно её форкнули и развиваете самостоятельно. Вы теперь сам себе апстрим, и можете решить проблему просто не делая того, что считаете неправильным.

Тред не про мой форк. :}

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

А плюшки есть какие-то, али просто переписано?

И вообще, lxpanel - имхо, далеко не основная беда lxde.

В последнее время развитие lxpanel стагнировало

Это справедливо относительно почти всех компонент lxde.

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

Девелоперов нет не потому, что сишечка. Их просто нет. Не думаю, что vala на что-то может повлиять.

Я думаю, что в этом пока ничего страшного нет, посмотрим, как помню это уже не первый раз, когда разработчики lxde выбрасывают весь написанный код и начинают все с нуля(вроде pcmanfm).

Девелоперов нет не потому, что сишечка. Их просто нет. Не думаю, что vala на что-то может повлиять.

Ну кто-то же её переписывал. Может, ему сишечка просто уже в печёнках встала...

Девелоперов нет не потому, что сишечка. Их просто нет.

А нету их «просто» потому, что не нужно.

Вменяемые разработчики не пишут прикладные задачи на чистом C

2^64 чашек чая этому господину!

dismal_faun> Писать гуй на не ООП языке в 21 веке крайне глупо

Программисты на Tk смеются над тобой.

encyrtid> Или от того что разработчики начнут заниматься новой версией, старая сразу перестанет работать?

Бинго! Через некоторое время её не будут поддерживать, поэтому без красноглазия поставить её будет нельзя.

geekless> Девелоперов нет не потому, что сишечка. Их просто нет. Не думаю, что vala на что-то может повлиять.

Vala знает несоизмеримо меньше народа, чем тот же C, посему я могу обрисовать очень пессимистичные перспективы.

Си можно оставить только в критичных байтоё*ских местах

А потом мы удивляемся, почему это плеер есть 100 мбайт ОЗУ, и как раньше работали на 64мбайтах в лучшем случае.

Оу, умельцы умудряются и на чистом Си писать редкостный говнокод. В Gtk время появления (не создания! создание-то относительно не тормозит) всплывающего меню есть не меньше O(N) от количества элементов в нём. Наткнулся сейчас на эти замечательные грабли при отладке апплета «Дерево каталогов».

А теперь умножаем кривость тулкита на кривость реализации прикладного ЯП и на кривость программиста конкретной софтины... oh, shi~

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

Что изменилось? Почему те же браузеры отжирают ОЗУ сотнями мбайт? Почему плеер в лучшем случае весит 50-100 мбайт? Что такого эксклюзивного добавилось в современные плееры, по сравнению с тем же древним xmms кажется (livecd knoppix 2005 года), что плееры жрут в десятки раз больше?

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

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

Такие проекты как tiny core linux и connochaetos показывают, что современная gnu/linux система с низкими системными требованиями вполне возможна даже на существующем массиве софта, без переписываний.

tiny core linux

Маленький оффтоп: на 486-ом проце с 8 мбайт ОЗУ взлетит?

Понятия не имею :}

А что плохого в вале?

lxpanelx - не то же самое?

Вменяемые разработчики не пишут высокоуровневые задачи с применением ООП на голом C.

А? Чо сказать хотел?