Приглашаю помочь мне в разработке vala-panel

переписывать её на C

Почему не на C++? Gtk и gtkmm можно спокойно мешать в любых пропорциях.

Хоть бы ссылку на гитхаб дал.

Домой приеду - напишу

Никаких ++, особенно на Gtk. Зачееееем? Ну и апплеты все равно на vala останутся

This is Vala rewrite of SimplePanel, GTK3 LXPanel fork.

Т.е. теперь будет:
This is a partial C rewrite of a partially rewritten in Vala SimplePanel, GTK3 LXPanel fork.

Хм.

Не, там от lxpanel уже почти ничего не осталось. Буквально пару дней назад закопал раннер, заменив его новым. Api апплетов у меня полностью изменено. От lxpanel там только трей и алгоритм позиционирования.

А зачем вообще на Си переписывать? Я наоборот за то, чтобы код на Си, использующий GLib и GObject переписывать на Vala.

-Wall -Wextra -pedantic. Ну и в mailing lists у vala писали, что она abandonware

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

Не, не только по ней. Изначально была дискуссия в багтрекере budgie-desktop. Домой приду - кину ссыль

Окей, багтрекер budgie я не читаю. Было бы интересно узнать, что там думают.

https://github.com/rilian-la-te/vala-panel - ссыль на Vala Panel

https://github.com/solus-project/budgie-desktop - ссыль на Budgie

https://github.com/solus-project/budgie-desktop/issues/501 - ссыль на обсуждение

Официальное мнение разработчика:

The codebase has begun to grow out of control..

With Vala we find many odd runtime issues, constant issues between new vapi files, an excessively heavy approach to the heap, poor debugging, poor maintainability, and frankly utterly shite C code that is emitted.

Even with those items out of the way, things to consider:

We use a seriously limited set of CFLAGS to build all Vala elements in Budgie Desktop. Given that it generates C code, this code is not actually subject to strict compiler flags, and poses security risks. We cannot enforce PIE/RELRO properly, again because the resulting code buckles (Solus employs full relro (bind now) by default) There are over 400 bugs encountered by static analysis in the generated C code, some of them having the potential to grow into critical bugs I'm good at C, I don't need a translator... Stable ABI: Completely SOL with Vala as we cannot access GCC attributes, so must rely only on linker scripts, without the ability to correctly track ABI changes. The code is horrifically inefficient. Vala is a complete heap-whore, ignoring stack space and copying All The Things, and explicitly copying things living in .text. No proper tooling around Vala for any form of real world continuous integration or code formatting (clang-format..) In many, many situations, we've been completely roadblocked because Vala isn't advanced enough to speak the level of C we need, i.e. dealing with long transfers via X atoms (bitwise shift isn't a strength here.). At the end of the day, it's not a real programming language. It's translated into C and then the compiler does the real work, if it was even interpreted or contained its own toolchain based on LLVM then we wouldn't have half of these issues, as it stands, it's a translator.

It's been spoken about for a while to do the C rewrite, now lets schedule this as a base requirement for the next major Budgie release, and rip all the shit out of the codebase

Right now we're busting at the seams with non-interoptable crap:

Totals grouped by language (dominant language first): vala: 10183 (53.34%) ansic: 8502 (44.54%) xml: 308 (1.61%) sh: 96 (0.50%)

Total Physical Source Lines of Code (SLOC) = 19,089 Development Effort Estimate, Person-Years (Person-Months) = 4.42 (53.09) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.94 (11.31) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 4.69 Total Estimated Cost to Develop = $ 597,673 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler

Requirements going forward:

Travis CI for all PRs Require all C code to comply with our .clang-format configuration, with absolutely no exceptions. Enforce heavier CFLAG requirements and respect distributionCFLAGS fully. Drop ALL Vala code from the core of Budgie - no more Vala additions will be accepted now. Bump the ABI to become incompatible with the current 10.2 branch of Budgie (intentionally)

если быть кратким: «на 3 день» (с) хипсторы обноружили, что очередной хипстерский суперязычок оказался непроработанным говном, непригодным дажЫ для хипсторских поделок. Хипсторы заплакали и ушли в свои айфоны... Пришлось вернуться на пестон 😣 Невиданная история, Сэры.

Причём тут вообще питон?

Внесу свою лепту: не нужно.

Официальное мнение разработчика:

Ну там по большей части мнение.
Надо просто понимать, что язык не самый распространенный, а потому количество тулзов вокруг него весьма ограниченное, с этим приходится мириться.
Зато не писать вручную наследования, свойства, исключения, деструкторы, что на Си выливается в много кода,
а Си ABI + Си API + GObjectIntrospection с их уникальной гибкостью при этом остаются.
Если же писать на C++/Питоне/Rust/etc, то и все замыкается автоматом на одном языке.

-Wall -Wextra -pedantic.

Там что-то конкретное смущает или просто обилие предупреждений (что для vala всегда было нормальной ситуацией)?

Согласен с тобой. Но тут не только в тулзах дело. У меня в vala-panel в vala-части кода около 100 C Warnings. В C коде - ни одной:) (с -Wpedantic появятся скорее всего, но мало).

А касательно

Зато не писать вручную наследования, свойства, исключения, деструкторы, что на Си выливается в много кода, а Си ABI + Си API + GObjectIntrospection с их уникальной гибкостью при этом остаются.

смотри мой пост там же:

writing C boilerplate makes me boring. Is there any tools to automate its writing? And Vala gives to us many convenient functions like DBus annotation (whole interface without XML), GtkTemplate annotation (very convenient template automation) and some smaller. Rewriting it in C is painful, very painful. But benefical.

Как минимум обилие предупреждений. Еще приходится очень сильно извращаться с xcb в extras и носить с собой файл gio-addons.vapi, в котором определены функции GLib, отсутствующие в официальных vapi, к примеру g_keyfile_settings_backend_new

И еще течь. Почему-то это все течет просто адски, причем именно в still reachable. И если в C еще можно как-то поиграться с памятью, то в Vala - фиг-то там.

Что за день сегодня, нерабочая плата пришла, Валу закапывают...

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

Я бы на твоем месте лучше Валю пилил. Чтоб и предупреждения убрать, и функции добавить.

Тут на ЛОР в архивах были:-)

Ну и в mailing lists у vala писали, что она abandonware

Очень жаль. А нельзя ли пруф на мессагу?

Да как так можно-то?!

Вон, Plank на Vala написан и работает просто отлично и быстро.

Лучше бы QML закопали или сделали такую же фичу, как и у Vala: компилятор в C или C++.

Лучше бы QML закопали

++

Разделяю недоумение по поводу Vala. Казалось очень неплохим решением в 2010, но стагнировало

Вот начало треда.

Ну вот, а я только начал изучать vala. Что делать? Куда бежать?

Что делать?

Вернуться к истокам: Си. C учетом опыта прожитых лет, примерно сформулированных https://matt.sh/howto-c , как-то так.

Ну вот, а я только начал изучать vala. Что делать? Куда бежать?

Переходить на Go.

http://harmful.cat-v.org/software/

Переходить на Go.

Может лучше на Rust?

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

А на чем сейчас можно гуй писать?

Да сам не очень представляю. Полагаю, что если нужен GUI и высокая производительность, то кроме C++ или C особых вариантов-то и нет (разве что под macOS и iOS это будут Objective-C и Swift).

Если вопрос производительности остро не стоит, что диапазон вариантов более чем широк: начиная от скриптоты (вроде Tcl/Tk или Python-ов с Ruby-ями с биндингами к Qt), заканчивая Java. Включая сюда и такое порождение человеческой мысли, как Electron (Chromium+JS+Node.js, но для десктопа).

Ну, если уж потянуло на маргинальщину типа раста, то можно потыкать и биндинги к libui или гтк (https://github.com/kud1ing/awesome-rust#gui)

Спасибо, не надо. Большинство фич нереализуемо на нем.

А на чем сейчас можно гуй писать?

На тикле, например.

Написать ядро программы на Сях, а GUI на GJS.

GUI и высокая производительность, то кроме C++ или C особых вариантов-то и нет

Лолшто? Gtk гуй на расте прекрасно пишется, слава GI.

И хороших примеров этого можно увидеть буквально на каждом шагу?

Я это к тому, что в мире не так много любителей бегать по граблям, коих множество в любой молодой технологии (коей и является GUI на Rust-е).

И хороших примеров этого можно увидеть буквально на каждом шагу?

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

Сам биндинг там генерится как и везде с помощью GIR, который уже оттестирован по самое ``не могу".

что в мире не так много любителей бегать по граблям

И это говорит человек, который посоветовал свифт, сишку и тикль с тк. Там-то нет граблей, особенно в тк — такой-то тулкит: адовый колбэкхэл и виджеты работают не так, как того от них ожидаешь.

Последовательный, че. С гткмм ты по граблям не меньше бегать будешь с RefPtr-ами и багами реализации. Как и на чистом сишном гтк.

И это говорит человек, который посоветовал свифт, сишку и тикль с тк.

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

Но фанаты Rust-а вольны бегать по граблям сколько им вздумается.

будет сильно побольше, чем Rust-а и Rust-овых биндингов. Даже у Swift-а.

И много у тебя опыта в разработке на тикле со свифтом? В свифте до сих пор синтаксис перелопачивают, какое там разработка. В тикле/тк до сих пор entry фокус тупо не работает. Но грабли, разумеется, в расте. Тебе с дивана виднее, че.

https://i.imgur.com/Hi8nvvq.png

И много у тебя опыта в разработке на тикле со свифтом?

У меня нет ни того, ни другого. Но это никак не влияет на тот факт, что в Интернете документации и пр. материалов для Tcl/Tk и для Swift-а, а так же готовых библиотек для них, в разы больше, чем для любого из биндингов Rust-а к любой GUI библиотеке.

Грабли есть везде, но в молодых технологиях, к коим относится Rust и Rust-овые биндинги, их просто-напросто больше. Плюс, у молодых технологий есть такой риск оказаться заброшенным, когда интерес у основных мейнтейнеров иссякнет. Мы как раз находимся в теме, которая возникла из-за невнятных перспектив Vala.

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

что в Интернете документации и пр. материалов для Tcl/Tk и для Swift-а, а так же готовых библиотек для них, в разы больше, чем для любого из биндингов Rust-а к любой GUI библиотеке.

Мой диванометр зашкалило. Готовых библиотек для раста, наверное, более, чем для тикля и свифта вместе взятых. Загляни хоть в карго, а потом посмотри на то, что есть для свифта и тк, и не говори больше таких глупостей.

из-за невнятных перспектив Vala

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

Готовых библиотек для раста, наверное, более, чем для тикля

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

результат не одного года разработки

готовые качественные библиотеки

Ну на тикле их, обычно, просто нет. Даже тк — редкостное говно, по сути. И годы ему как-то не помогли.

А почему?

результат не одного года разработки

А потому что ты забыл, что время разработки измеряется не в часах, а в человекочасах. Если у тебя комьюнити в три инвалида, как в тк или вале, то никакие годы не помогут.