Джеймс Вестман (James Westman), разработчик приложения GNOME Maps, представил новый язык разметки Blueprint, предназначенный для построения интерфейсов с использованием библиотеки GTK. Код компилятора для преобразования разметки Blueprint в ui-файлы GTK написан на языке Python и распространяется под лицензией LGPLv3...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56283
Внешне выглядит как пародия на QML.
GTK давно было пора иметь подобную пародию. QML очень даже неплох.
Безусловно. Но в GNOME это будет сделано криво, с половиной запланированных фич и с постоянной поломкой сделанного в новых релизах.Мы говорим о DE, в которой нормальной поддержки тем нет. Хотя её делали дважды. И дважды выкидывали. И сейчас героически делают в третий раз.
В KDE что ли есть нормальная поддержка тем? Ну-ну.
В кде всегда были проблемы только с гтк3 темами. В том же жырнолисе при задании тёмной темы невидимый текст.
Попробуй сделать в кедах что-то наподобие orchis без замены штатного движка тем
А зачем? Оно же уродское.
> А зачем? Оно же уродское.Просто как иллюстрация возможностей штатного движка тем.
Да
головка от гуя
там даже движки поддерживаются на полную катушку, а вы о темах
aurorae + kvantum и делайте че угодно (про плазма-темы даже не заикаюсь, если плазма считается).
Вот именно, так и есть! Причем даже на windows, всё это выглядит очень аккуратно.
А ещё в qt5ct можно написать свой css (только тсс - я не сильно пробовал).
В КДЕ есть нормальная поддержка тем, а вот в GNOME темы как раз пытаются противоестественным образом ликвидировать и запретить.
В кедах до сих пор не могут починить прозрачность при вкюченном размытие в темах с закругленными углами. Дакуча всяких недоделок там, как только начинаешь настраивать под себя начинают вылезать баги.
Так один QML уже есть, я ещё удивлён, что из него сделали что-то относительно вменяемое в кедах (сколько лет на это ушло?). Пародия будет ещё хуже. Но скажу честно меня это не затрагивает, у меня нет и никогда не будет гтк софта (во всяком случае покуда на этом тулките не начнут появляться приличные программы, вероятность чего убывает с каждым днём). Я бы и сам гтк удалил, если бы не диалоги в юнити и не браузеры.
> диалоги в юнити и не браузеры
> у меня нет и никогда не будет гтк софтачто ты заливаешь?
Меня не спрашивали. До сих пор бы собирал фф с гтк2, если бы его поддержку не поломали. В юнити это только стандартный диалог выбора разрешения и биндов, в браузере только файловые диалоги (а порталы не лучше и всё равно завязаны на гном, нужно патчить). И в браузерах свои тулкиты, зачем они так упорно гтк волочат?
Пользуйся Falkon.
> у меня нет и никогда не будет гтк софта
> Я бы и сам гтк удалил, если бы не диалоги в юнити и не браузеры.Какое лицемерие :) Всё-таки есть у тебя гтк-софт, от которого ты никогда не сможешь отказаться, ибо на кутэ никогда такого не напишут.
Какой это? И почему не напишут? Ну, пиджин получше кутешных недоделок, но он тоже на гтк2 или можно в консоли при большом желании использовать без гтк. Раньше был audacious, но теперь он на кутэ. Есть ещё пара программ на wxwidgets (гтк2, но может быть кутэ в теории). А вот вспомнил nvidia-settings на гтк (тоже 2 вроде бы). С гтк есть практическая проблема: если кутэшный софт работает на вейланде без иксов, то гткшный нет (может, в 4 поправили?). Глиб в теории можно выкинуть, там вроде только ивентлуп используется в кутях. Gstreamer вот нечем заменить, это да. При этом, сам по себе gstreamer работает вполне сносно, но вот в софте что-то не работает ни в какую. Основное применение это бэкенд для phonon -- vlc намного хуже по всем параметрам и я хочу нормальный звук без искажений и артефактов, тут gstreamer вполне справляется. Пока не придётся проприетарные форматы воспроизводить (mp4/mp4a), тогда он обламывается.
Нет, серьёзно, какие программы на гтк? Тот же браузер совсем не на гтк, кутэвебэнжин от гтк не зависит совершенно и собирается из одних исходников. Я не вижу ни одной гтк-программы, которую было бы сложно написать на кутях. И о каких преимуществах гтк речь? Одни недостатки, то трей отломают, то хоткеи, то контекстные меню.
Странно, но пользуюсь гтк и сижу на гноме уже не первый год, и чето не отваливается нечего... может дело в прослойке между елавай и мониеом?)) А вот перед ним пытался на qtах сидеть и вот там, все по кд отваливалось)) странность конечно, но все же) несколько раз пробовал qtы, но исход один.
Дело действительно в прослойке, я вот сижу на них всех не первое десятилетие и видел всякое, вполне могу судить. Кеды не то чтобы без проблем всегда были, но никогда не ломали мне буфер выделения например -- это та функция, без которой я работы с ПК не представляю. Уже ощущение, что каждое МИНОРНОЕ обновление гтк что-нибудь отваливается и ломается.
Странно, но пользуюсь гтк и сижу на гноме уже не первый год, и чето не отваливается нечего... может дело в прослойке между елавай и мониеом?)) А вот перед ним пытался на qtах сидеть и вот там, все по кд отваливалось)) странность конечно, но все же) несколько раз пробовал qtы, но исход один.
Чисто для примера - использую zathura для pdf. Выглядит как обёртка для кучи всего типа mupdf, с интерфейсом в стиле vim. Но ведь на gtk3 жеж :-/ . Хотя скорость взлёта от этого не сильно страдает.
>ибо на кутэ никогда такого не напишутТы про Firefox? Зато его под Wine давно написали.
А вот прикинь - нету. Вообще gtk нет. И прекрасно.Или ты мне про браузер будешь заливать? Так он у меня на Qt. Один из оствшихся вменяемых.
>GTK давно было пора иметь подобную пародию. QML очень даже неплох.ГТК пора на помойку. Когда джини перешёл на гтк3 — то пал последний бастион. Это была единственная программа на гтк, которая выглядела прилично. Теперь все актуальный версии всех программ на гтк выглядят уродливо. Этакая кунсткамера в мире ПО.
Как говорится, «кашу маслом не испортишь», но и гогно маслом не улучшишь.
На Адвайте что-ли? Только не надо про уродство тем, возможностей CSS там достаточно.
Может и тормоз, но вполне красивый (ещё говорят смазливый), особенно если времени на тему не пожалеть (поискать готовую или самому запилить).
Raleigh - окаменелость по сравнению с Адвайтой.
Интересно, когда в gtk2 завезут связанный стиль для кнопок и прочих рамок?
Даже без изменения основного стиля - склеивание кнопок делает гуй намного опрятнее.
Жаль только, склеивание в 2d пока только через одно места (в адвайте нет - надо самому писать через вложенные боксы).
Так и есть. Только сейчас доросли.Хотя не считаю QML удобным. Дизайнер в Qt Creator позволяетс соершенно легко работать с нормальными виджетами и С++ кодом.
Херня какая-то уровня sed скрипта с заменой угловых скобок на пробелы и переносы строки — ну не нравится чуваку xml, хорошо что не yaml хоть выбрал, только толку от этого тулкиту и экосистеме?
Он слишком для него многословен, но то что HTML 😄
хтмл божественен
... для нурглитов.
хтмл - как язык разметки - не доставляет вообще никаких проблем. Проблемы появляются из-за лишних "слоев абстракции" при написании стилей
То-то все используют pug (бывший jade) и другие генераторы.Видимо HTML настолько прекрасен, что на него невозможно прямо смотреть не ослепнув от великолепия.
Как это какой толк? Чем гном более БЛОАТЕД - тем лучше. Разве не для этого его пилят?
Очередной троль который гном в глаза не видел, гном у него блоатед...
Если кому-то не нравится xml - это нормальный адекватный человек.
Наверное он просто еще не трахался с пробелами, названиями некоторых стран и булевыми значениями в yaml. И не задумывался о там как собственно проверять документ по схеме.После вышеозначенных действий пациент приходит к пониманию, что XML как формат пусть и не моден, но работает.
Наверное, он лучше, чем Elm.
Столько грязи некомпетентной в коментах понаписали, а тульчик-то что надо!
Запилили бы инсталятор.msi под винду на подобие QtCreator-a, назвали бы его GnomeCreator, чтобы всё под ключ собирал по нажатию кнопки "билд".
И вот увидите, птичка запоет " Гном лууучшииий!! ", " КДЕ ниработает!! "
Ещё раз придумать https://wiki.gnome.org/Apps/Builder ?
Под виндоус нужно, под виндоус! Чтобы любой студент мог скачать инсталлер, скопипастить код с хабрахабра, и нажать на зелёный треугольник.
При переходе от gtk2 к gtk3 перестали делать сборки для win, испортили
usability для парочки виджетов, раздули механизмы отрисовки виджетов, так что некоторые разработчики уже смигрировали на qt. Боюсь, что тут уже мало чем можно исправить ситуацию. GTK по всем параметрам проигрывает QT.
Ну, не по всем, но всё больше и больше. Возможности для разработчиков и отладчиков самого GTK становятся обширнее. И, якобы, более эффективный рендеринг через OpenGL (разве что если ваш видеоускоритель не поддерживает OpenGL 3).
Фанатик детектед. И чем тебе Glade не подходит? Он есть под вендоузъ
msi никого не интересует
фиг знает, я бы предпочёл на XML писать чем на специально свелосипеденном формате. Форматов что ли мало придумано?
> Форматов что ли мало придумано?Языков что ли мало придумано? Но растаманы изобрели трёхколёсный велосипед.
Вы задолбали все подряд Blueprint называть. Других названий нет что-ли?Шейдеры - blueprint, какая-то херня в монтажке для видео - blueprint. Теперь и это blueprint
а еще формат мейкфайлов в андроиде (один из них)
Blueprint - "я не знаю как назвать". Вполне нормальное название.
Вроде "foo".
>написан на языке Python и распространяется под лицензией LGPLv3Джеймс Вестман - правильный пацан.
А зачем в новом ГТК такие жЫрные заголовки и такой-мелкий-мелкий текст?!
Чтобы не выходить за рамки 1%.
что бы помещать в заголовки кнопки
Ну там в заголовке ещё и панель управления - этим оправдан такой заголовок.
А вот когда я на днях запустил konsole в кедах, то офигел. Там такой вот бутерброд:
1. Заголовок с названием и кнопками.
2. Панель меню.
3. Панель с какими-то сеточками (видимо для режима тайлинга).
4. И только вот тут начинается "такой мелкий-мелкий текст".
Я в этот момент вспомнил про поговорку с соринкой и бревном, ибо настолько широкая шапка ни одной проге на другом тулките и не снилась.
Ну ладно, решил всё это дело убрать, а то аноны с опеннета заклюют про каштомизируемость. Полез в настройки и тут я офигел второй раз: там несколько пунктов настроек и каждая настраивает перечисленное выше в отдельном месте. Какой гений это придумал?
К работе самого konsole никаких претензий - отличный эмулятор терминала. Но такое ощущение, что он попал в руки к студентам, которые решили запихнуть в него всё и сразу самым топорным способом.
Другие проги в кедах не запускал. Возможно там всё хорошо. Но если нет, то я перестаю понимать претензии к гному, ибо он намного компактнее дефолтных кед.
П.С. Кеды - последние, ванильные, без тем и прочего.
Знать бы еще куда эти виджет тулкиты приткнуть. Парадоксально, но единственная хоть сколько принимая канва даже не входит в основной дистрибутив тулкита. А ведь это на секундочку гимповый тулкит..
> единственная хоть сколько принимая канварасшифруй свой поток мысли...
Это про программирование. Проходи мимо
Бессмысленный оверинжиниринг. В си можно json-подобные структуры писать на designated initialisers, в т.ч можно дерево ui виджетов описать компактно.
Да весь современный Linux - бессмысленный оверинжиниринг.
Весь современный IBM Gnome оверинжинирингfftgj
Ох, как хорошо. Теперь программистам есть что учить. Есть чем ещё забить свою голову. Ещё одна специальность.
Скажи это растаманам.
Казалось бы какое местным экспертам дело до того на чем делают разметку расположения контролов gtk? Они же все равно не пишут на gtk и не будут писать
а почему не jsx?
Свой, исконно рус...ой GTK-шный, путь.
Шляпа какая-то. Даже в такой минимальной демке вместо "title: _("My App Title");" получилось "blueprinttest". А что будет с более сложными интерфейсами?
Скриншот из другого блога, если вместо того чтобы ехидные комментарии писать включили бы мозг на секунду, заметили бы что в примере и кнопку в заголовке никто не обьявлял.
Чем ему json не угодил?
Вообще считаю что все надо на json перевести в том числе и конфиги линей из etc. Всё в один формат и огонь.
Ты прав кроме опечатки в слове yaml.
вы бы, любители джейсонов, для начала с зоопарком парсеров этого барахла разобрались бы, а потом уже ein folk, ein reich, ein fuhrer для конфигов педалировали бы
забыл одну скобку и весь конфиг превращается в...
сейчас такие времена что от фразы "придумал свой формат хранения данных" руки должны сами тянуться за мухобойкой.
Чувак решил качнуть свое ЧСВ придумав несовместимый формат?
В помойку сразу
Это vala, но с убогим синтаксисом и компилятором на python?
Так, не дайте пациенту сбежать - я пошёл за лопатой!
Да, вот тоже хотел написать, что зачем изобретать велосипед. Хорошо если бы они там собрали какой-то простой API для создания UI, но нет опять еще один вариант трансляции своих DSL-ей в код. Что за мания делать повсюду какие-то разновижности сегментирования.
Зачем вообще новый язык для интерфейсов? Сделали бы на JSON что нибудь (или XML, как в Qt, но там писанины больше).
> или XML, как в QtЗачем в кутэ сделали кучу языков? XML, QML, JS...
Нет там JS, проглатывай.
Эти ребята явно не понимают, что учить 100500 языков программирования - это на самом деле трэш, а потому продолжают и продолжают их клепать. По хорошему программа должна писаться на одном языке. От начала и до конца. А всякая ересь, типа смешивания PHP с JS - идет лесом.
Именно поэтому существует привязка gtk для js и возможность писать css.
Blueprint - подходящее названия языка для GMOME ;)
Чтобы шутка удалась, нужно было пробельчик поставить;)
Гномеры изобретает qml?
Чего все так возбудились? Ну выкатили очередное ненужно для ненужно, ну загнется оно через пару лет так и не набрав популярности в проде. Вам какая разница, никто же заставляет это использовать!
> В качестве причины создания проекта называется привязка применяемых в GTK ui-файлов описания интерфейса к формату XML, который перегружен и неудобен для написания или редактирования разметки вручную.Эта цитата - блестящий пример того, как посредством одного предложения можно снизить IQ целого форума.
Во-первых, XML - это контекстно-свободный язык разметки, который используется в первую очередь для сериализации сложно устроенных данных в текстовое представление по заранее известной схеме.
Во-вторых, вот что важно знать про XML:
1) Он не предназначен для ручного редактирования через простой текстовый редактор живым человеком. Если вы исправляете его содержимое руками, то это сродни забивания гвоздей микроскопом. Для работы с XML вы должны иметь редактор, который изначально работает с описанными в нем объектами.
Для автоматизации преобразования XML-объектов вне редакторов есть XSLT. Ну или в крайнем случае вы создаёте свой редактор и инструментарий с последующим преобразованием, как это сделал автор.
2) Он не может быть распарсен регулярным выражением, потому что он имеет КС-грамматику. Любая попытка найти что-то в XML посредством работы с ним как со структурированным текстом закончится болью и страданиями. Если вам нужно получить данные оттуда, для этого придуман XPath
3) Согласно спецификации XML данные фрагменты идентичны.
Фрагмент 1:
<elements>
<item>1</item>
<item>2</item>
</elements>
Фрагмент 2:
<elements>
<item>2</item>
<item>1</item>
</elements>
В тегах XML нет порядка. Порядок нужно указывать явно, объявляя его как атрибут к каждому элементу и трактуя так, как хочется. Исходя из этого, утилиты вроде diff не могут быть использованы для XML по смыслу, потому что, помимо лютого вырвиглазного неудобства, будут показывать отличия в XML-файлах, которых нет в реальности.Использование XML для декларативного описания интерфейсов более чем разумно, вот только это совсем не значит, что они будут писаться людьми от руки. Дальше всё сводится к наличию тулсета по работе с XML и удобства изначального редактора, который его генерирует.
А что мы имеем у разработчика:
1) diff
2) VS CodeЯ не собираюсь тут критиковать конкретно GTK.Builder, а лишь скажу что 2 вышеозначенных инструмента - главная проблема, почему автору так не удобно жить. И вот он создаёт транслятор на python, на языке в стандартной библиотеке которого чуть ли не самая убогая реализация XML, чтобы пихнуть его в другой редактор. Это, кстати, тоже такой способ пытки, работать с XML в Python, но я уверен, что у автора и на это есть причины, чай интеграция с Builder.
Вообще работа с XML в Linux в целом - дело трудное, потому что стандартная для большинства дистрибутивов libxml2 (изначально часть проекта GNOME, ЕМНИП) - редкостный мусор с точки зрения поддержки современных стандартов. Обычно XML используется там, где нужно работать с большими объемами и/или сложно устроенными данными, для организации удаленного вызова процедур и потоковой проливки объектов с последующей фильтрацией и преобразованием между несколькими разными информационными системами. То что никто не старается привести в порядок libxml2 не удивительно, потому что в GNOME масштабы не те...
Вот и получается идиотство. Есть разработчик Blueprint, который создаёт себе костыль^W автоматизацию, потому что те инструменты, которые есть, его не устраивают (что вполне логично). Есть разработчики GNOME, которых всё устраивает как есть и которые не предоставляют вменяемого инструментария по работе с XML даже за деньги. И есть писатель новости, у которого XML виноват в том, что его не удобно редактировать как INI-образный файлик, которых тьма тьмущая в /etc, потому что понятия не имеет что такое XML, кому и зачем это надо.
Для пущей радости не хватает набега смузихлёбов с JSON, которые понятия не имеют ни о схеме, ни о трансформации, ни о запросов без полной десериализации в ОЗУ. И еще не хватает откровенных маргиналов с YAML, форматом данных, который перегружен посильнее XML, но в отличии от последнего при большом объеме данных не может быть эффективно прочитан и отредактирован ни человеком, ни компьютером. Ой всё...
>И вот он создаёт транслятор на python, на языке в стандартной библиотеке которого чуть ли не самая убогая реализация XML, чтобы пихнуть его в другой редактор. Это, кстати, тоже такой способ пытки, работать с XML в Python, но я уверен, что у автора и на это есть причины, чай интеграция с Builder.Очень похоже на ГНОМ, только непонятно где тут JavaScript.
Люто-бешено плюсую!
Вообще это новомодное поветрие всё делать одним-единственным инструментом по меньшей мере удивляет.
То они универсальную файловую систему ищут, то универсальный язык программирования, то универсальный формат хранения данных, то универсальный...
А на поверку оказывается, что им попросту некогда ознакомиться с уже существующими инструментами и форматами.
- Чо тут думать? Прыгать надо! - повторяют они, и годами скачут за недостижимым бананом.
нету для linux инструментов на подобии PlistEdit Pro
Что за PisdEts Pro?
Спасибо за рассказ! Всё, что ты сказал - это на тему, почему НЕ надо использовать XML.
походу, gtk не использует libxml2, только парсер, встроенный в glib
> транслятор на python, на языке в стандартной библиотеке которого чуть ли не самая убогая реализация XML
> libxml2 редкостный мусор с точки зрения поддержки современных стандартов.примеры бы неплохо привести какие-то, а то пока это голословные утверждения.
> примеры бы неплохо привести какие-то, а то пока это голословные утверждения.Ну, те кто использовал и XML в целом, кто знает Python и кто юзал libxml2 в этих примерах не нуждаются... это факты, которые станут заметны невооруженным взглядом просто от использования инструментов.
Как это сделать:
1. Стандарты XML, Xpath и XSLT определяет консорциум W3.org. Вы можете сличить версии всех стандартов с тем подмножеством, которое поддерживает libxml2 и вам станет понятно о чем идёт речь.
Например, отсутствие xslt и xpath старше спецификаций 1.0 - это самое болезненное для тех кто работает с XML, потому что то количество работы по написанию и отладке одного и того же по смыслу сценария запроса/трансформирование усложняется условно в 3 раза.
Далее, несмотря на бахвальство в прохождении сотен тестов консорциума OASIS, libxml2 валится на обработке самых простых объектов допустимых с точки зрения спецификации XML и валидных в рамках заявленной схемы, потому что тесты не все, и там куча специфики. Для теста попробуйте написать маленькую реализацию выборочной десериализации объектов на языке С с последующим текстовым выводом значений в сокет, которые вы предварительно забираете с SOAP-вебсервиса, какой-нибудь 1С. Удачи вам обработать и трансформировать это всё без парсинга.2. От Python как языка требуется больше, чем просто от библиотеки. Если у вас есть нормальный язык который умеет работать с ООП пусть даже не совсем строго в академическом смысле, предполагается, что вы можете сериализовать и десериализовать свою объектную модель. И было бы не плохо, чтобы у вас были представления для сериализации для внутреннего использования (Model в MVC) и внешнего (View в MVC). В случае написания API за View можно считать DTO. Поддержка XML как одного из основных международно принятых стандартов сериализации предполагает наличие сериализатора ВАШЕЙ объектной модели в ВАШЕ желаемое XML-представление. Желательно, чтобы можно было чётко дать понять сериализатору, как это сделать, или в крайнем случае создать кастомный сериализатор унаследовавшись/реализовав интерфейсы от стандартного. Ну и вообще круто если вам дадут какой-то синтаксический сахар, как например, аннотации, которые автоматически подстроят сериализатор на этапе проектирования объектной модели. Всё это есть и в Java и в .NET, например.
А что умеет Python? А он вам даёт minidom. Во-первых, это позволит вам работать с XML из коробки только как с документами, а, во-вторых, вы не сможете использовать свою собственную объектную модель. Вместо этого вам будет вменена объектная модель документа (DOM), которая настолько абстрактная, что вы никогда не подгоните её под свои объекты, если только не пишете web-фронтенд, хотя причем тут Python и XML тогда не совсем понятно.
А как сериализовать классы Python, а вот по-человечески никак =)
У него там pickle вместо сериализации. Pickle - это бинарный велосипед^W протокол, который ломал^W менял свою спецификацию уже 5 раз. Не так чтобы сильно, но то что последние 3 версии приходятся на 3-ю ветку питона, вызывает лично у меня леденящий душу восторг. Семь раз отрежь, один отмерь.
Есть около 5-ти библиотек в pip для поддержки xml разной степени паршивости. Те из них которые пытаются реализовать сериализацию костыляют вокруг трансляции бинарного представления pickle cоотсетствующей версии в XML и последующей догонкой результатов как документов либо через minidom, либо через ту же libxml2 к которой изволят ручками биндиться через ctype, потому что в Python нет автоматизации маршалинга для библиотек. Результат с точки зрения удобства использования, производительности, переносимости и сопровождения только разве что на РЕН-ТВ показывать.С JSON там ситуация не столь печальная, но документация Python явно заявляет об отсутствии поддержки сериализации и десериализации JSON кастомных объектов стандартным модулем json. Только словари с минимальной кастомизацией выхлопа. А теперь представьте, что нужно сделать в Python, если нужно часть полей собсвенного класс писать как элементы, а часть как атрибутах. Правильно, начать использовать нормальный язык программирования. Я задавал этот вопрос представителям сообщества Python и услышал именно то чего так боялся. Если тебе нужна кастомная сериализация в XML для системы, которая ожидает определенную схему получаемых объектов, то ты должен писать словари и сериализировать их руками... мусор, короче говоря.
Питонисты ведь не от хорошей жизни велосипедят REST API на каждый чих, у них вообще никак по-нормальному данные не передать кроме как через словари и JSON. А потом когда запутаются в своей микросервисной лапше из вебсервисов, бегут пихать всё это в RabbitMQ, начинают GraphQL внедрять, когда нужно выбирать часть данных в ответах и gRPC, когда нужна потоковая проливка, но это уже сильно-сильно мимо стандартной библиотеки.
Ви, таки, попrобуйте всем этим попользоваться, что этот ваш Python, что libxml2. =)
Это не мнение там какое-то, которому требуется сложное доказательство с аргументами. Всё что я писал про стандартную библиотеку Python и про libxml2 увидит каждый, кто просто ткнётся туда на задачах сложнее микросервиса в докере, который раздаёт "Hello World" по REST API.
а накой вообще ui файлы редактировать вручную, когда есть glade?
Иногда проще текстом написать чем мышкой расставлять.
обычно в таких случаях проще вообще не заморачиваться с ui и GtkBuilder, а явно из кода интерфейс делать
когда уже гнум/гтк будет Одна Большая Кнопка
Питон универсальный язык
Какое нзкое коварство - полуживого забавлять!
Что только не придумают, чтобы на сях не писать.
Это ты про растаманов, что ли?
> Это ты про растаманов, что ли?Нет. Про сабж.
Так они даже на своих поделках потом не пишут. Всю жизнь пытаются их допилить а потом уже и оп, новая порция шлака.Зато какая ИБД. Всю жизнь учишь учишь и ничего не выучишь
Надо больше языков. Надо чтобы даже простая программа требовали не менее 10 компиляторов и 500 движков Жoпаскипта.