Gui linux на чем писать

что нужно знать чтобы писать программы с графическим интерфейсом на Си? [закрыт]

Закрыт. На этот вопрос невозможно дать объективный ответ. Ответы на него в данный момент не принимаются.

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

Закрыт 1 год назад .

Проблема такая — изучил основы Си. Написал кое какие программы консольного формата которые ныне решают мои задачи. Но теперь мне понадобилась программа с графическим интерфейсом поскольку меня заинтересовала работа с изображениями, а консоль тут даже отдаленно ничем помочь не может. Интересно именно под linux с использованием xlib : я уже пытался понять с чего начать, но кроме этого ничего вразумляющего не нашел, и даже тут сразу столкнулся с системными переменными. Сразу после этого море вопросов по типу: 1) а что это? 2) а где их брать? 3) а как понять за что какая отвечает? 4) а какие у них есть свойства? и т. д. И как я понимаю это наверняка не единственное что необходимо знать, чтобы писать подобные программы. Прошу тех кто уже занимается подобным — очень нужен какой-нибудь гайд или своего рода roadmap — просто очень многие вещи которые гуглишь на эту тему либо бесполезны(не по теме в итоге) либо есть нужное но для их понимания надо еще что-то знать — как в случае с системными переменными(в том смысле что — а с чего начать изучать эти системные переменные и т. д. Ведь все постигается на практике) Заранее спасибо))

На чем писать gui-программы для debian?

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

Или я вообще не в ту сторону смотрю??

Вопрос задан более трёх лет назад
1322 просмотра

Комментировать
Решения вопроса 1

ri_gilfanov

Руслан Гильфанов @ri_gilfanov
Web- and desktop-developer

Python часто называют «лучшим вторым языком для большинства задач». Написание графических приложений — не исключение. Особенно, если нет задачи защитить исходный код приложения от изучения посторонними.

Библиотек для создания графических приложений много.

GTK+ 3
- Python GTK+ 3 (зависит от PyGObject) — рекомендую. Во-первых, тулкит Gtk проще в освоении, чем монструозный Qt. Во-вторых, есть приличная по объёму официальная документация для Python (хотя и не полная). Приложений с большим количеством окон и виджетов пока не писал.
- PyQt5 — несколько лет назад пробовал PyQt4 и PyQt5. Для написания чего-то сложнее «Hello world!» надо курить много документации к оригинальному Qt, а изложено там всё в контексте языка C++. Например, пару дней пытался разобраться как обойтись без Qt-шных классов для работы с СУБД (чтобы не извращаться с голым SQL) и подружить Qt-шные виджеты для таблиц с SQLAlchemy — в итоге понял, что Qt не для меня.
- PySide2 — не пробовал. Лучше PyQt5 по части лицензий (есть под LGPL, что позволяет бесплатное использование и в проприентарных проектах) и, если не ошибаюсь, PySide2 лучше дружит с питоновскими типами. В остальном, тот же Qt5.
- wxPython — не пробовал. Говорят проще PySide2 / PyQt5. Однако, тулкит не дотягивает по популярности до GTK+ 3, так что вероятно и инфы по нему меньше. Как я понял, стабильной версии под Python3 до сих пор нет, находится в разработке под названием Phoenix.
- Tkinter — пробовал. Собственно исходный тулкит Tk кажется морально устаревшим. Добиться более-менее приличного оформления приложений затруднительно. Для реализации сложных вещей надо писать заметно больше кода, чем в вышеупомянутых тулкитах.
Ответ написан более трёх лет назад
Нравится 4 7 комментариев
protasovmikhail @protasovmikhail Автор вопроса

Скажите а, например, программы сделанные в Python GTK+ 3 или qt5 на выходе чувствительны к окружению?

gnome, kde, xfce ?? Верно думаю что для всего можно сделать не переписывая основной скрипт.

Руслан Гильфанов @ri_gilfanov

Скажите а, например, программы сделанные в Python GTK+ 3 или qt5 на выходе чувствительны к окружению?

gnome, kde, xfce ?? Верно думаю что для всего можно сделать не переписывая основной скрипт.

protasovmikhail, не особо. Это окружение рабочего стола и отдельные приложения зависят от соответствующих библиотек (GTK и Qt). На практике, в одном дистрибутиве рядом часто могут стоять приложения написанные как на GTK, так и на Qt. К тому же, графические приложения можно запускать и вместо окружения рабочего стола (например, те же окна приветствия с вводом логина и пароля запускаются до окружения рабочего стола).

Если приложение на Gtk+ 3 запускается в KDE 5 или приложение на Qt5 запускается в Gnome 3, то основные проблемы обычно связаны с поддержкой тем оформления (цветов, шрифтов, отступов) и пр. И разработчики окружений рабочего стола стараются это исправлять.

По другим окружениям. Cinnamon изначально писался на Gtk+ 3. XFCE недавно перешёл на Gtk+ 3. Mate по-большей части на Gtk+ 3, зависимости от старых версий Gtk в процессе удаления.

Думаю если Вы планируете писать приложения для популярных и современных дистрибутивов Linux, то я не предвижу необходимости как-то менять исходный код, отвечающий за графический интерфейс. У меня один и тот же Python код с вызовами GTK+ 3 работает как в Linux Mint 19.2 (с Cinnamon 4.2.4), в Debian 8 (тонкие клиенты без графического окружения) и в Alt Linux 8.3 (с KDE 5).

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

Некоторая мешанина из высокоуровневых кроссплатформенных библиотек (Qt / wx) и низкоуровневых, на которых человеку, задающему такие вопросы, лучше вообще не смотреть. Сравнивать wx с GTK вообще странно, поскольку первая под Линукс является оберткой над второй.

protasovmikhail @protasovmikhail Автор вопроса

Менть код этих, Мужиков??

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

Руслан Гильфанов @ri_gilfanov

Я имел ввиду мой код ( к их api ? я не разбираюсь в вопросе), придется подправливать под ( api . ) гнома или кеды, а не их код конечно.

protasovmikhail, не думаю, что Вам придётся что-то подправлять под Gnome или KDE.

В Python-обёртке над GTK+ 3 у окон есть методы resize(), maximize(), unmaximize(), fullscreen(), unfullscreen() и другие. Они должны одинаково работать как в KDE, так и в Gnome.

Руслан Гильфанов @ri_gilfanov

Некоторая мешанина из высокоуровневых кроссплатформенных библиотек (Qt / wx) и низкоуровневых, на которых человеку, задающему такие вопросы, лучше вообще не смотреть. Сравнивать wx с GTK вообще странно, поскольку первая под Линукс является оберткой над второй.

Adamos, я дал ссылки на разные инструменты для разработки графических приложений на Python, а так же указал их C/C++ зависимости.

С точки зрения разработчика, что будет писать графические приложения на Python под Debian — знание, что wx в Linux является обёрткой на Gtk конечно хорошо, но куда важнее знание об отсутствии стабильной версии wxPython под Python 3.x и скорое прекращение официальной поддержки Python 2.x.

Касательно уровня абстракции и порога входа. В данном случае ровно наоборот, низкоуровневые решения порой обладают более низким порогом входа и большей свободой кастомизации. Поэтому я и предпочёл Python GTK+ 3, а не PyQt5 или PySide2.

protasovmikhail, Да практически нет. Пишу в основном на PyQt и GTK+3. У меня IceWM и все работает прекрасно.

Создание графических приложений

Настоящая статья является дополнением к книге «Инструменты Linux для Windows-программистов». Это не описание как делать GUI приложения в Linux, это описание того, как ПРИСТУПИТЬ к созданию графических приложений в Linux, и, хотелось бы надеяться что это прозвучит — чем принципиально программирование графики в Linux отличается от того же занятия в Windows. Главным требованием здесь была простота. Сделав простейший шаблон GUI прложения, дальше двигаться уже гораздо проще. Кроме того, все эти простейшие приёмы программирования показаны сравнительно: на основе основных графических технологий (библиотек), используемых в UNIX.

Все примеры к тексту вы можете скачать в виде общего архива.

Создание приложений, взаимодействующих с пользователем посредством графического интерфейса (GUI приложений), является частным классом задач, отдельной областью программирования. Из числа других подобных областей приложения можно было бы привести, как примеры:
- реализация алгоритмов цифровой обработки сигналов (DSP): быстрые спектральные преобразования (FFT и другие), вэйвлеты, авторегрессионные разложения. ;
- обработка аудио-потоков (пакеты: sox, ogg, speex и другие);
- задачи IP-телефонии, SIP протокола, реализация разнообразных программных SoftSwitch;
Это сравнительный ряд автономных областей развития приведен как пример таких частных классов, одним из которых является и разработка GUI приложений. И как частный класс, со своей спецификой инструментов и средств, он не заслуживал бы отдельного упоминания, если бы не одно обстоятельство — принципиально отличающееся, диаметрально противоположное отношение к GUI в операционных системах семейства Windows и в UNIX (и в Linux, как его частный вид):
- В Windows каждое приложение является принципиально GUI, неотъемлемым атрибутом любого приложения в Win32 API (низкого уровня) является главное окно приложения, уже само приложение «вяжется» вокруг его главного окна. Операционная система регистрирует классы окон и уже далее к ним соотносит конкретные приложения. Не может существовать приложения (взаимодействующего с пользователем, не системные службы) без окна, с этим были связаны и первоначальные сложности Windows в реализации консольных (терминальных) приложений.
- в UNIX картина принципиально обратная: первичным является приложение, которое, по умолчанию, является консольным, текстовым, вся графическая система не является составной частью операционной системы, а является надстройкой пользовательского уровня. Чаще всего такой графической надстройкой является X11 (в реализации Xorg или X11R5), но и это не обязательно: практиковались и другие графические системы, хороший пример тому графические системы Qwindow, а затем Photon в операционной системе QNX, сосуществующие там одновременно с X11.
- Показательно в этом смысле то, что вся оригинальная часть реализации X11 работает в пространстве пользователя, не в привилегированном режиме ядра (супервизора): работа с аппаратурой видеоадаптеров, устройствами ввода и другое. Отдельные реализации (видеосистемы NVIDIA или ATI Radeon) могут быть реализованы в режиме ядра (модули), но это а) сторонние относительно X11 разработки, и б) решение вопросов только производительности.
Из-за обозначенной специфики, разработка GUI приложений в UNIX (Linux) принципиально отличается:
- вся работа GUI приложений ведётся через промежуточные слои (библиотеки) пользовательского уровня;
- из-за того, что это ординарный пользовательский уровень, для разработчика предлагается широкий спектр альтернативных инструментов (библиотек), практически равнозначных, и конкурирующих друг с другом: Xlib, GTK+, Qt, wxWorks и многие другие.
- базовый API работы с X11 предоставляет Xlib, все другие используют уже её функционал, как это показано на рисунке.
- разработчик имеет возможность широкого выбора тех уровня и инструментов, которые он предполагает использовать, начиная от Xlib и выше (хотя уровень Xlib и слишком низок и работа с ним громоздкая).
Из-за названной специфики GUI приложений в Linux, все они, независимо от используемых средств создания, имеют абсолютно сходную структуру. Рассмотрим, для сравнения, код нескольких простейших GUI приложений, подготовленных с помощью различных инструментов. Важнейшей задачей такой экспозиции будут команды компиляции и сборки, чтобы, исходя из таких примеров, показать возможность начать создавать свои собственные GUI приложения.

Средства Xlib (архив Xlib.tgz ):
```
#include #include #include #include #include extern int errno; int main( void ) < Display *d; Window w; XEvent e; char *msg = "Hello, World!"; int s; if( ( d = XOpenDisplay( getenv("DISPLAY" ) ) ) == NULL ) < // Соединиться с X сервером, printf( "Can't connect X server: %s\n", strerror( errno ) ); exit( 1 ); >s = DefaultScreen( d ); w = XCreateSimpleWindow( d, RootWindow( d, s ), // Создать окно 10, 10, 200, 200, 1, BlackPixel( d, s ), WhitePixel( d, s ) ); XSelectInput( d, w, ExposureMask | KeyPressMask ); // На какие события будем реагировать? XMapWindow( d, w ); // Вывести окно на экран while( 1 ) < // Бесконечный цикл обработки событий XNextEvent( d, &e ); if( e.type == Expose ) < // Перерисовать окно XFillRectangle( d, w, DefaultGC( d, s ), 20, 20, 10, 10 ); XDrawString( d, w, DefaultGC( d, s ), 50, 50, msg, strlen( msg ) ); >if( e.type == KeyPress ) // При нажатии кнопки - выход break; > XCloseDisplay( d ); // Закрыть соединение с X сервером return 0; >
```
```
$ gcc Xlib.c -o Xlib -lX11 .
```
Средства GTK+ (архив GTK+.tgz ):
```
# include /* Подключаем библиотеку GTK+ */ int main( int argc, char *argv[] ) < //Объявляем виджеты: GtkWidget *label; // Метка GtkWidget *window; // Главное окно gtk_init( &argc, &argv ); // Инициализируем GTK+ window = gtk_window_new( GTK_WINDOW_TOPLEVEL ); // Создаем главное окно gtk_window_set_title( GTK_WINDOW( window ), // Устанавливаем заголовок окна "Здравствуй, мир!"); label = gtk_label_new( "Здравствуй, мир!" ); // Создаем метку с текстом gtk_container_add( GTK_CONTAINER( window ), label ); // Вставляем метку в главное окно gtk_widget_show_all( window ); // Показываем окно вместе с виджетами g_signal_connect( G_OBJECT( window ), "destroy", // Соединяем сигнал завершения с выходом G_CALLBACK( gtk_main_quit ), NULL ); gtk_main(); // Приложение переходит в цикл ожидания return 0; >
```
$ gcc gtk.c -o gtk `pkg-config —cflags —libs gtk+-2.0`

Средства Qt (архив Qt.tgz ):

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

#include #include int main( int argc, char** argv )

Теперь проделываем последовательно:
```
$ ls index.cc $ qmake -project $ ls index.cc Qt.pro $ qmake $ ls index.cc Makefile Qt.pro
```
Исходя из «подручных» файлов исходных кодов, у нас сгенерировался файл проекта и, далее, сценарий сборки ( Makefile ). Далее проделываем традиционную сборку, а заодно и посмотрим опции компиляции и сборки, которые нам сгенерировал проект:

g++ -c -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector —param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables

g++ -o Qt index.o -L/usr/lib/qt-3.3/lib -lqt-mt -lXext -lX11 -lm

index.cc index.o Makefile Qt Qt.pro

Средства wxWidgets (архив wxWidgets.tgz):

simple.cc :
```
#include class Simple : public wxFrame < public: Simple( const wxString& title >; Simple::Simple( const wxString& title ) : wxFrame( NULL, wxID_ANY, title, wxDefaultPosition, wxSize( 250, 150 ) ) < Centre(); >class MyApp : public wxApp < public: virtual bool OnInit(); >; bool MyApp::OnInit() < Simple *simple = new Simple( wxT( "Simple" ) ); simple->Show(true); // старт петли обработки событий return true; > IMPLEMENT_APP(MyApp ) // этот макрос реализует функцию main() в приложениях wxWidgets, // скрывая подробности главного цикла ожидания события.
```
$ g++ simple.cc `wx-config —cxxflags` `wx-config —libs` -o simple

Средства GLUT (архив glut.tgz):

OpenGL Utility Toolkit, как и следует из названия, это средства использования технологии OpenGL в приложениях, которая требует определённой поддержки со стороны видео оборудования.

#include void Draw( void ) < glClear( GL_COLOR_BUFFER_BIT ); glColor3f( 0.0f, 0.0f, 1.0f ); glLineWidth( 1 ); glBegin( GL_LINES ); glVertex2f( 0, 0.5f ); glVertex2f( 0, -0.5f ); glEnd(); glFlush(); >int main( int argc, char *argv[] )

$ gcc glut.c -o glut -lX11 -lglut

То, что показано выше, это фактически не приложения, а скелеты приложений, но они позволяют: а) сравнить подобие всех GUI технологий в X11, и б) быть отправной точкой для сборки более содержательных GUI приложений. Показано только несколько GUI технологий, применяемых в X11 (большинство из них являются кросс-платформенными, и применимы в большинстве существующих операционных систем). Каждая из этих технологий, а названы только немногие из значительно большего числа, присутствующих в UNIX, могут быть полной альтернативой любой другой из этого же ряда, они взаимно заменимы, и даже взаимно дополняемые.

В данной статье были показаны образцы кода GUI приложений. Естественно, визуальные образы таких приложений строятся не путём непосредственного кодирования, а при использовании некоторых визуальных построителей, в составе тех или иных интегрированных средств разработки (IDE).

Что выбрать для написания GUI в 2021.

Что лучше выбрать для написания десктопного GUI приложения в 2021 году.

Нужно написать кросплатфоменный интерфейс.

Там должны быть дерево, таблицы (большие, сортировки, группировки, …), формы. Хочется не писать их самостоятельно.
- C# (WinForms или Avalonia, Gtk), поскольку на c# писал мало, и есть ощущения, что скорость разработки не очень высокая. Сходу полноценных таблиц и деревьев вообще не нашел.
- Python (PySide6), посмотрел по gui на python. Варианты по сути:
  - PyQt(PySide) 6 версия уже достаточно стабильна ? Документации навскидку не очень много нашел.
  - wxWidgets есть ощущение, что менее мощный. (тут смущает, что будет медленнее C# и опять же GIL).
  В C++ лезть не хочется, так как давно на нем не писал, и есть ощущение, что на нем разработка будет еще медленнее чем на C#.
  
  Предварительно кажется, что python будет компромисным вариантом.
  
  Разработчик пока всего один, и не хочется надолго увязать в написании GUI, так как есть и другие задачи.
  
  У кого какие соображения по данному вопросу ?
  
  ol1mp ★
  13.07.21 20:14:13 MSK
  ← 1 2 3 →
  
  Сам спросил — сам ответил. Уносите.
  
  anonymous
  ( 13.07.21 20:18:29 MSK )
  
  wxWidgets написаны на c++, сами виджеты не тормозят. GIL при правильной многопоточности (у wxPython свои расширения для этого) ты вообще не заметишь.
  
  Посмотри ещё таблицы на TkInter — там есть ОЧЕНЬ навороченные решения, и всё буквально летает (для web ui до таких таблиц как до луны раком), в wx таблицы в комплекте хорошие, но для Tk сторонние решения.
  
  Я для просмотра гигантских pandas таблиц вот это использую:
  https://pandastable.readthedocs.io/en/latest/examples.html — там для таблицы виртуальный буфер, она вообще ракета.
  
  Думаю, если для группировки/сортировки возьмёшь pandas/numpy и грамотно запроектируешь ui (с буфером), то на python можно будет сделать очень быстрое приложение.
  
  Для QT и wx есть визуальные форморисовальщики.
  
  Shadow ★★★★★
  ( 13.07.21 20:19:28 MSK )
  Последнее исправление: Shadow 13.07.21 20:25:32 MSK (всего исправлений: 3)
  Похожие публикации: