Примеры GUI программ без фреймворков

Знакомы.

На чистой манипуляции X11

Такой некрофилии я не видел со времён Xeyes (или типа того).

или Wayland.

Это невозможно, вейланд даёт поверхность для рисования, он не дает примитивов гуя.

А так есть например Steam Dev Client, оно на ImGUI.

Да, я сам писал году в 2001-м. Исходники, может быть, лежат на сурсфордже.

Знакомы ли вам полноценные десктопные графические программы, написанные без использования фреймворков QT/GTK и подобного?

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

Есть такое:

https://github.com/wolfpld/tracy (imgui библиотека)

https://www.aseprite.org/ (своя библиотека)

http://grafx2.chez.com/index.php?static2/screenshots (своя библиотека)

Такой некрофилии я не видел со времён Xeyes (или типа того).

Opera Presto

AzPainter

fontforge

cinelerra, blender.

Этих двоих уже достаточно.

mpv

Писал такую полгода назад на Go и Fyne, например. Последний работает как imGui, сам отрисовывает все контролы в окне.

Установщик дебиана?

Такой некрофилии я не видел со времён Xeyes (или типа того).

Некрофилия - это делать что-то на вайланде. А под иксы писать норм.

Это невозможно, вейланд даёт поверхность для рисования, он не дает примитивов гуя.

Вайланд, конечно, не нужен, но я и в иксах таким способом некоторые (не все) проги писал (рисование в своём буфере полностью своим кодом + XShmPutImage его при получении Expose события).

Но ведь тогда самому придется создать фреймворк.

Ну очевидный Блендер, например.

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

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

Я про то что во всяких gtk/qt есть такое явление как «создать кнопку» (не нарисовать, а создать), к которой можно привязывать всякие обработчики итд. Если библиотека будет именно рисовать, то она наверно тоже в каком-то роде фреймворк, но многие не поймут.

вот инструкция от alex0x08: Линукс, ассемблер и X11

прочти, сядь и сделай

Не просто поделки какие-нибудь, а реальные качественные программы

удачи! :)

Написано на X11 (xlib/xcb):

1. Worker (двухпанельный файловый менеджер).

2. sxiv (просмотр изображений; актуальный форк – nsxiv).

3. MuPDF (просмотр файлов PDF, XPS, EPUB, XHTML, CBZ).

4. AzPainter (графический редактор, который хорошо подходит для рисования).

5. ImageMagick (графический редактор для простых операций над изображениями).

6. recordMyDesktop (запись экрана).

7. MPlayer (медиапроигрыватель; его форком является mpv, который, вроде как, чисто на xlib/xcb – без SDL – работать не может).

8. XNeur (автоматически переключает раскладку клавиатуры при наборе текста не на том языке).

9. Conky (информация о системе и железе).

10. unclutter (скрывает курсор мыши при бездействии).

11. SoftMaker FreeOffice (офисный пакет).

12. Bristol (эмулятор синтезатора).

13. st (эмулятор терминала).

14. xterm (эмулятор терминала).

Зависит от того, что считать фреймворком, особенно «и подобное» — смотря насколько подобное.

foot, например. Да и вообще большинство эмуляторов терминала.

Например, если OpenGL и Vulkan мы такими фреймворками не считаем, то mpv, например, а также куча игр. А если не считаем ещё и SDL, то ещё больше.

Лично я ничего не могу вспомнить из того, чем я регулярно пользуюсь.

Но тут вот подсказывают: mpv. А значит и mplayer и ffplay. Возможно kodi. А ещё по сути любая игрушка под полноэкранный/оконный режим. Вероятно можно считать и те, что используют sdl - это не тулкит. И джава-приложения.

ну гуи это единственная сфера где все фишки ООП нужны и пригождаются

GUI-установщик на GTK.

На Хабре недавно была статья где человек рассказывал как рулить X-сервером через его сокет - что туда посылать чтобы он рисовал нужное на экране. И этот человек написал таким образом «программистский» редактор FreshIDE.

А вообще выше правильно было сказано - даже если напрямую управлять Х-сервером без xlib - всё равно создаются какие-то функции которые потом переиспользуются. То есть фактически получается некий собственный тулкит.

Xaw нещитово.

FreshIDE не просто какой то редактор, а IDE для ассемблера, на ассемблере.

Нашел эту статью, сейчас буду лакомиться... https://habr.com/ru/articles/784282/

У него же в профиле можно найти посты о создании cms на ассемблере.

На чистой манипуляции X11 или Wayland.

С иксами такое конечно прокатит, но на вейленде тупо нет рисовалок, только буферы туда-сюда ходят.

По теме: всё что на SDL (недавно в новостях редактор кода lite-xl был), большинство игр что-то там изобретают заново. Да и смысла как-то особенно большого нет отказываться от Qt/Gtk/etc. Чтобы что? Всё равно с нуля что-то своё напишется.

Чтобы что?

Что бы работало быстрее.

Чтобы сделать удобный интерфейс, не упираясь в ограниченную парадигму gtk или устаревшую qt

Чтобы быстрее работало надо использовать gpu. Чтобы ещё не стрёмно выглядело и не тормозило при обновлениях, нужен свой аналог gsk, который будет всё кешировать прям в том же gpu. Чтобы корректно отрисовать текст нужны всякие libicu, pango, рендер шрифтов, движок позиционирования текста, расстановка переносов. В общем, переизобрести надо целую вселенную для банальной быстрой кнопки с текстом.

Обычно, когда пишут быстрое своё, получается рендер ascii таблицы, максимум с поддержкой кириллицы, с уродской вёрсткой, поехавшим лейаутом, без документации и тонной багов. И вот чтобы что?

Чтобы быстрее работало надо использовать gpu.

Что бы отрисовать кнопочки? Не смеши.

Чтобы корректно отрисовать текст

Вот кстати на gpu никто его рисовать еще не научился, она не особо применима...

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

Обычно, когда пишут быстрое своё, получается рендер ascii таблицы, максимум с поддержкой кириллицы, с уродской вёрсткой, поехавшим лейаутом, без документации и тонной багов. И вот чтобы что?

У меня gtk4 приложения запускаются несколько секунд, и почти все сломаны, не работают на rtx 3060, и теперь уже на rtx 4070. А вот например grafx2 всегда радует привычным, удобным интерфейсом, который еще и очень быстро работает.

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

Я не говорил что текст рендерится на gpu, обычно не рендерится, на gpu уже готовые слои друг на друга накладываются. Но сам процесс сложный, и его практически невозможно самому сделать с нуля. Даже корректно обрезать строку без libicu нельзя, не порезав кластеры графем типа лайка с тоном кожи или буквы ё из е и умляута. Люди обычно сильно недооценивают сложность текста и юникода.

В иксовых приложениях очень много чего ещё нету, что уже считается стандартным, особенно когда есть денег на rtx 4070. Купи себе ssd чтобы всё быстро запускалось. Качество приложений на gtk хромает, это правда, но вряд ли проблема в самом gtk, как в фреймворке, чтобы прям с нуля свой писать.

Купи себе ssd чтобы всё быстро запускалось

У меня NVMe, но я думаю что gtk4 приложения запускаются из памяти, потому что это появляется и при повторном открытии.

но вряд ли проблема в самом gtk, как в фреймворке, чтобы прям с нуля свой писать

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

ssd чтобы всё быстро запускалось.

Недавно упоминал о проблеме gtk4, которая, якобы, в mesa: В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор (комментарий).

Да и смысла как-то особенно большого нет отказываться от Qt/Gtk/etc

От GTK и QT как раз отказываться смысл есть - из-за уровня сложности разработки под них. Если это не продукт уровня какого-нибудь ОпенОфиса или Гимпа - то разумнее будет использовать существенно более простые тулкиты. Меньше шансов наплодить глюков и получить неудобный интерфейс у своей программы.

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

На GTK и QT мир не заканчивается. Есть куда более простые в использовании. Тут недавно где-то поблизости была тема про «что бы такое написать на Си» так вот там перечисляли,желающие могут поискать то обсуждение. Сам для своих поделок использую слегка перенастроенный относительно дефолтных умолчаний http://xforms-toolkit.org

Ох не знаю, постоянно в чатах про питоны спрашивают как заставить tkinter работать как надо. И глюки, и неудобный интерфейс, всё на месте. Хотя казалось бы, тулкит попроще.

постоянно в чатах про питоны спрашивают как заставить tkinter работать как надо.

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

А вот сложность GTK и QT - объективна. И если человек не является профессиональным программистом,специализирующимся именно на создании интерфейсов с использованием одного из этих монстров - то нет смысла с ними связываться. Чтобы сделать простой интерфейс для простой программы - есть несколько куда более простых тулкитов. Есть даже не требующие использования «плюсового» синтаксиса,обходящиеся обычным сишным. Что тоже является достоинством с точки зрения снижения сложности использования.

Вроде как рогалик Angband использует Иксы.

Что поделать, я такое же могу сказать про приложения под мобилки и веб-приложения. Сама по себе задача сложная. Есть прям отдельные касты разработчиков под каждый стек.

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

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

Да, это правда.

Самый парадокс в том, что как раз таки простые приложения на мейнстриме сделать сильно проще

Это на QT-то проще?! В лучшем случае получится кое-как сляпать интерфейс «как получилось»,а не «как удобно» и «как хотелось». Особенно тяжко делать удобное управление программой с клавиатуры. Что мы во множестве линуксовых программ и наблюдаем,где разработчики в итоге на удобное клавиатурное управление забили из-за количества необходимых усилий. Работать с этими программами человек, привыкшему к быстрому набору - боль.

raygui, microui (rxi), TUI (SFML).

Нравится, использую

ZUI

Этот: https://zui.brimdata.io/docs/Installation?

Или этот: https://www.openzui.com/en/#control/button?

Первый выглядит интересно, не знал.

GTK

Ты про недобиблиотеку с извращённым ООП на сишке, которую разрабы гимпа по приколу сделали? Какой же это фреймворк, так велосипед

Чтобы быстрее работало надо использовать gpu. Чтобы ещё не стрёмно выглядело и не тормозило при обновлениях, нужен свой аналог gsk, который будет всё кешировать прям в том же gpu. Чтобы корректно отрисовать текст нужны всякие libicu, pango, рендер шрифтов, движок позиционирования текста, расстановка переносов. В общем, переизобрести надо целую вселенную для банальной быстрой кнопки с текстом.

А чтобы Наутилус перестал быть однопоточным куском говна, нужно сделать что?

Сколько архитектурных астронавтов нужно, чтобы завернуь одну лампочку?

Обычно, когда пишут быстрое своё,

то получается azpainter, который летает на 15-летнем утюге.

И вот чтобы что?

Чтобы не быть как дураки, делавшие Наутилус и Gedit.

Вот кстати на gpu никто его рисовать еще не научился, она не особо применима…

Что характерно, GPU там не нужен вообще.

Там нет такого порядка задержек, чтобы задача не решалась не то что на современном CPU, а даже на 10-летнем CPU.

Весь этот архитектурный булшит типа «мы перенесем рендеринг шрифтов на GPU, и окошки перестанут тормозить» – от собственной убогости как разработчиков.

Говорю как человек, решавший вот такую задачу: Midnight Commander 4.8.31 (комментарий)

У меня ощущение что ты тред не читал, сразу отвечал по ключевым словам. Да, наутилус и гедит посредственно сделаны, я и не спорил с этим. Для 15-летних утюгов я даже рекомендую изобретать заново колесо на Xlib, без шуток, но мне не интересно возиться с 15-летними утюгами, и не интересно изобретать заново велосипеды, заново поддержку юникода придумывать, изобретать ещё одну блочную модель, 15 лет завозить элементарные анимации и прочее. Никогда не понимал вот это боевое староверчество.

Да нет, это ты пытаешься воевать с самостоятельно придуманными образами. Будто icu имеет какое-то отношение к gtk. Нет, не имеет. И рендеринг шрифтов не имеет никакого отношения к gtk. Чо за блочная модель утебя в башке, вообще понятно только одному тебе.

Все эти задачи gtk делегирует в другие библиотеки.

В ОП речь шла об ИСПОЛЬЗОВАНИИ ФРЕЙМВОРКОВ.

Там нет такого порядка задержек, чтобы задача не решалась не то что на современном CPU, а даже на 10-летнем CPU.

Плавная прокрутка на 4к HDR экране во много герц?