Блоатварь - неизбежное будущее линуксового народа. Таков путь.

Других он хочет на 486 посадить, а сам - на электроне писать. Непоследовательно как-то.

Я хочу не столько на электроне писать, сколько иметь толковую систему рисования ГУЯтины, и опционально систему обработчиков этой гуятины.

JS c inline HTML (или HTML с inline JS) для этого подходят лучше всего.

Пожалуйста, пусть в тулкиты внедряют возможность писать на разметочном языке, абстрагируясь от тупорылых классов, наследований, функций и прочей срани (это когда ты описываешь стили, добавляешь их в текущий дисплей, загружаешь в объект, добавляешь кнопку, добавляешь добавленную кнопку в дочерний виджет, добавляешь стиль из загруженного объекта к кнопке, рисуешь окно, вместо того чтоб млять написать одну строчку - <button style='border: 1px solid red;'>Кнопка</button>) - я только за.

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

Вы GUI builder переизобретаете?

Вы GUI builder переизобретаете?

Эти гуи буилдеры можно засунуть в /dev/ass, потому что говнософт написанный при помощи этих уибуилдеров, мало того что тормознут, так еще и нечитаем, примерно как софт на пыхе с инклудами в рантайме (но там это хотя бы оправдано выгодой). Особенно ржачно это наблюдать на демках самого ГТК, например демке «Builder»: 66 строк С-шного кода, и 461 строка UI-разметки, рисуют окно с 15 кнопками.

Если ГНОМ написан по такому же принципу - то не удивительно почему оно со старту сьедает полгига, и еще полтора ему требуются для вменяемой работы.

КАДы на электроне

Press F.

У тебя снова взаимоисключащие параграфы. Формы на мини-языке разметки жрут много, а всё приложение целиком в браузере будет жрать не много? Лол.

Особенно ржачно это наблюдать на демках самого ГТК, например демке «Builder»: 66 строк С-шного кода, и 461 строка UI-разметки, рисуют окно с 15 кнопками.

Если ГНОМ написан по такому же принципу - то не удивительно почему оно со старту сьедает полгига, и еще полтора ему требуются для вменяемой работы.

Так ты уж определись, тебе надо или большую кнопку «сделать ХАРАШО», и пофиг сколько оно жрёт по итогу, или сидеть выписывать код с ручным управлением памяти.

А то оскорбился сам не понял на что.

https://github.com/sde-gui/libsmfm-gtk - эффективно работает на утюге уровня Pentium 4. В том числе с десятками тысяч файлов. В том числе с HDD. Использует отложенную загрузку данных и многопоток для избегания блокировок UI.

Из известных мне реализаций - эффективнее только реализация в современном Dolphin.

Удачки реализовать это на электроне.

А что делать тем, кто без рук?

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

https://ibb.co/s52r3yK

В WxWidgets (который как ты знаешь «нативный», т.е. юзает и ГТК, и КТ, и Cc, и winapi) есть класс WebView. Он позволяет просматривать полноценный HTML в обыкновенном окне. С гипертекстовыми ссылками и JS, да-да.

PHP умеет во встроенный вебсервер, который в принципе работает сам для себя, и жрет при этом мизер. Даже рута не нужно.

Запустив его, и написав на WX программульку, которая открывает http://localhost/чо-то-там.php - мы получаем обыкновенное десктопное приложение, в моем случае написанное на PHP, со всеми вытекающими из этого плюсами.

Веб-сервер потребляет 100кб ОЗУ, запущенное ПЫХом окно на WxWidgets потребляет 190кб ОЗУ.

Веб-сервер потребляет 100кб ОЗУ, запущенное ПЫХом окно на WxWidgets потребляет 190кб ОЗУ.

Ну ты ври да не завирайся. У тебя просто при запуске cat в терминале резидентный набор процесса уже будет больше одного мегабайта.

В WxWidgets (который как ты знаешь «нативный», т.е. юзает и ГТК, и КТ, и Cc, и winapi) есть класс WebView. Он позволяет просматривать полноценный HTML в обыкновенном окне. С гипертекстовыми ссылками и JS, да-да.

Я тебя поздравляю с открытием виджета WebView, который существует буквально в каждом тулките.

А ржу я с того, что человек, который буквально хотел посадить программистов на 486, сам хочет писать с использованием фреймворка вот с таким списком зависимостей:

https://pastebin.com/kzp5Fna5

Сейчас мы еще размер этого кода подсчитаем:

$ du -c -h -D --apparent-size `ldd /usr/lib/libwx_gtk3u_webview-3.2.so | grep -o '/.*\.so\.[^ ]\+'` | tail -1
249M	итого

мы получаем обыкновенное десктопное приложение

Обыкновенное да не очень.

Ну ты ври да не завирайся.

Дык я ж через ps посмотрел.

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

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

Ну вот например WM я бы не рискнул писать на пыхе. И даже на пистоне бы не рискнул. Только компилируемый язык, как можно меньше зависимостей и меньше кода.

А какой-нибудь шедулер (в смысле календарь с напоминалками) - почему бы и нет. Или офис.

GTK я выбрал только по одной причине - распространенность. Была б моя воля - вообще б кнопки ректанглами рисовал, как в Поцкале. Но нет смысла рисовать быстрый минималистичный софт, если юзер в первые же минуты после установки системы, поставит Хромого\Файерфокса которые притащат его за собой.

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

Вот тебе история.

Есть такой виджет gtksourceview, при помощи которого gedit рисует текст с раскраской синтаксиса.

Тормозилово страшенное, хоть и реализовано на чистом Си.

Я еще под GNOME2 помню эти эпичные лаги в рендеринге текста в gedit, стоит открыть мало-мальски объемный документ. Вряд ли за прошедшие годы ситуация улучшилась, у продукции гнома эволюция, как правило, обратная.

Так вот, некий разработчик Евген Мунтян форкнул весь этот виджет (там кода дофига, по сути отдельный мини-«фреймворк») целиком, и я уж не знаю, как именно он его оптимизировал. Но результат получился прекрасный. Называется Medit.

Его версией я до сих пор пользуюсь, вот мой форк его форка: https://github.com/sde-gui/qk

Второй пример.

pcmanfm в своё время появился не потому, что автор страдал NIH-синдромом. А потому, что PCMan хотел сделать легковесную графическую оболочку, а nautilus при отображении файлов лагал на актуальном железе того времени.

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

PCMan при использовании того же самого графического тулкита сделал ФМ с принципиально иным порядком скорости работы и трейд-оффами по производительности в архитектуре.

Я его работу в своей версии еще ускорил, ссылку ранее приводил.

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

На первый взгляд кажется, что это не важно, это же не бутылочное горлышко софта. А потом ты берешь какой-нибудь софт на интерпретируемом ЯП и пытаешься им открыть данные, которые в 10-50 раз больше, чем те, на которых его тестировал разраб. И у тебя получается слайд-шоу.

А оптимизировать уже может быть некуда. Кроме как переписать на Си/Си++.

запустить какую-нибудь Haiku

Вся базовая система Haiku, вместе с драйверами, графикой, десктопной средой и gui утилитами собирается быстрее чем одно только ядро linux. Причем быстрее раза в три. Притом что Haiku на плюсах а не на си.

которая по функциям не далеко ушла от какого-нибудь виндового Проводника из 90-х?

Закон Парето в действии. 20% новых функций требуют на 80% больше кода.

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

Да я не то что бы переживаю. Это мысли вслух и кухонная философия по мотивам.

Я вообще сейчас занят тем, что подготавливаю черновик релиз-нотесов к этому, пока выдался свободный день) https://github.com/sde-gui/libsmfm-gtk

Та уговорил :)) Перехожу на С.

Этот питон такой мерзкий, непонятный, неудобный и нелогичный, что просто ппц.

ООП вообще мерзость гг

xclock уже 12мб занимает если смотреть через диспетчер задач xfce, хотя подобную программу наверное можно уместить в бутсектор, так можно легко придти к выводу что перерасход памяти был сильнее в 24576 раз.

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

Похоже на правду, у меня гейоси нарисовало 11Мб.

Но таких легких приложений уже никто не пишет, наверное вкладка в Electron занимает где то 300 мб, так что перерасход современного приложения по памяти происходит как минимум в 614'400 раз.