LINUX.ORG.RU

История изменений

Исправление FixingGunsInAir, (текущая версия) :

P.S. Я знаю, что опоздал, но вброшу немножко своего ненужного мнения для кучи.

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

Если нужно графическое приложение под Linux (и только Linux, максимум *nix), а остальные платформы пофигу - GTK. Если нужна кроссплатформенность - иди в сторону Qt/PWA/Electron/Java, сразу. Быстро, решительно. К такому выводу я пришёл, когда сам задавался подобным вопросом.

На GTK тоже можно кроссплатформенность, но это больно (за примерами - git Transmission). С Qt тоже можно в Linux, но шаг влево - шаг вправо, и вот ты уже пишешь обвязки для единственной доступной библиотеки с нужным функционалом, написанной под Glib и рот оказывается в GObject (видел где-то в репозитории qt-virt-manager обвязку над spice-glib). Ну, или, переписываешь либу…

Так сложилось исторически, что C и Glib/GTK получили главенство в Linux, пока тролли жадничали открыть Qt под нормальной лицензией. Больше половины Linux уже написано на C и имеет примесь Glib.

Glib это native-тулкит всея линукса (аминь). Похоже на то, чем является Win32 API для Windows (только лишь похоже). Вот оно такое есть и всё тут. Можно смазать обвязками, абстракциями, но не избавиться, не переписав весь линукс с ног до головы. Потому, если хочешь окунуться в глубокую системную разработку под Linux, Glib придётся коснуться.

Можно сделать приложение ни разу не коснувшись Glib и пальцем, но на самом деле оно будет работать через слои обвязок и абстракций, скрывающих суть того, чем является Linux под капотом. Даже в Qt, вроде как самостоятельный тулкит, но таится весёлая строчка, Requires: libglib-2.0.so.0()(64bit)

Я не хочу сказать, что обвязки/абстракции - это плохо. Они хороши там, где они нужны. Но если твоя изначальная цель - написать приложение для GNU/Linux, то зачем Qt? Разве что религиозные соображения.

Гном - это C

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

Оставь C бородатым системщикам, у них так заведено, а приложение сделай на Vala. Да хоть на жабаскрипте/пистоне, по вкусу. Для интероперабилити в Linux есть замечательная штука - IPC (DBUS). Написал интерфейс, заимплементил и теперь к нему можно хоть через dbus-send стучаться из shell-скрипта. KDE именно таким образом обходит некоторые моменты, где можно получить зависимость от Glib.

У KDE проще, плюсы и Qt. Легко начать разрабатывать приложение

Вкусовщина. В GTK тоже можно написать в XML/нарисовать в Glade скелет приложения и заткнуть в нужных местах точки входа. Или как в старых добрых WinForms, создать объекты и воткнуть в нужные контейнеры. Всё приходит с опытом.

Хочешь expеrience как в каком-нибудь комбайне аля Visual Studio, где IDE практически делает всё за тебя и бесплатно, вернись на винду и жди чуда.

прокачанные скилы пригодятся в оплачиваемых проектах

Я видел тред в Development, в котором выяснили, что С++ теряет в вакансиях, а Qt постепенно становится не нужен.

Исправление FixingGunsInAir, :

P.S. Я знаю, что опоздал, но вброшу немножко своего ненужного мнения для кучи.

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

Если нужно графическое приложение под Linux (и только Linux, максимум *nix), а остальные платформы пофигу - GTK. Если нужна кроссплатформенность - иди в сторону Qt/PWA/Electron/Java, сразу. Быстро, решительно. К такому выводу я пришёл, когда сам задавался подобным вопросом.

На GTK тоже можно кроссплатформенность, но это больно (за примерами - git Transmission). С Qt тоже можно в Linux, но шаг влево - шаг вправо, и вот ты уже пишешь обвязки для единственной доступной библиотеки с нужным функционалом, написанной под Glib и рот оказывается в GObject (видел где-то в репозитории qt-virt-manager обвязку над spice-glib). Ну, или, переписываешь либу…

Так сложилось исторически, что C и Glib/GTK получили главенство в Linux, пока тролли жадничали открыть Qt под нормальной лицензией. Больше половины Linux уже написано на C и имеет примесь Glib.

Glib это native-тулкит всея линукса (аминь). Похоже на то, чем является Win32 API для Windows (только лишь похоже). Вот оно такое есть и всё тут. Можно смазать обвязками, абстракциями, но не избавиться, не переписав весь линукс с ног до головы. Потому, если хочешь окунуться в глубокую системную разработку под Linux, Glib придётся коснуться.

Можно сделать приложение ни разу не коснувшись Glib и пальцем, но на самом деле оно будет работать через слои обвязок и абстракций, скрывающих суть того, чем является Linux под капотом. Даже в Qt, вроде как самостоятельный тулкит, но таится весёлая строчка, Requires: libglib-2.0.so.0()(64bit)

Я не хочу сказать, что обвязки/абстракции - это плохо. Они хороши там, где они нужны. Но если твоя изначальная цель - написать приложение для GNU/Linux, то зачем Qt? Разве что религиозные соображения.

Гном - это C

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

Оставь C бородатым системщикам, у них так заведено, а приложение сделай на Vala. Да хоть на жабаскрипте/пистоне, по вкусу. Для интероперабилити в Linux есть замечательная штука - IPC (DBUS). Написал интерфейс, заимплементил и теперь к нему можно хоть через dbus-send стучаться из shell-скрипта. KDE именно таким образом обходит некоторые моменты, где можно получить зависимость от Glib.

У KDE проще, плюсы и Qt. Легко начать разрабатывать приложение

Вкусовщина. В GTK тоже можно написать в XML/нарисовать в Glade скелет приложения и заткнуть в нужных местах точки входа. Или как в старых добрых WinForms, создать объекты и воткнуть в нужные контейнеры. Всё приходит с опытом.

Хочешь expirience как в каком-нибудь комбайне аля Visual Studio, где IDE практически делает всё за тебя и бесплатно, вернись на винду и жди чуда.

прокачанные скилы пригодятся в оплачиваемых проектах

Я видел тред в Development, в котором выяснили, что С++ теряет в вакансиях, а Qt постепенно становится не нужен.

Исходная версия FixingGunsInAir, :

P.S. Я знаю, что опоздал, но вброшу немножко своего ненужного мнения для кучи.

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

*Если нужно графическое приложение под Linux (и только Linux, максимум nix), а остальные платформы пофигу - GTK. Если нужна кроссплатформенность - иди в сторону Qt/PWA/Electron/Java, сразу. Быстро, решительно. К такому выводу я пришёл, когда сам задавался подобным вопросом.

На GTK тоже можно кроссплатформенность, но это больно (за примерами - git Transmission). С Qt тоже можно в Linux, но шаг влево - шаг вправо, и вот ты уже пишешь обвязки для единственной доступной библиотеки с нужным функционалом, написанной под Glib и рот оказывается в GObject (видел где-то в репозитории qt-virt-manager обвязку над spice-glib). Ну, или, переписываешь либу…

Так сложилось исторически, что C и Glib/GTK получили главенство в Linux, пока тролли жадничали открыть Qt под нормальной лицензией. Больше половины Linux уже написано на C и имеет примесь Glib.

Glib это native-тулкит всея линукса (аминь). Похоже на то, чем является Win32 API для Windows (только лишь похоже). Вот оно такое есть и всё тут. Можно смазать обвязками, абстракциями, но не избавиться, не переписав весь линукс с ног до головы. Потому, если хочешь окунуться в глубокую системную разработку под Linux, Glib придётся коснуться.

Можно сделать приложение ни разу не коснувшись Glib и пальцем, но на самом деле оно будет работать через слои обвязок и абстракций, скрывающих суть того, чем является Linux под капотом. Даже в Qt, вроде как самостоятельный тулкит, но таится весёлая строчка, Requires: libglib-2.0.so.0()(64bit)

Я не хочу сказать, что обвязки/абстракции - это плохо. Они хороши там, где они нужны. Но если твоя изначальная цель - написать приложение для GNU/Linux, то зачем Qt? Разве что религиозные соображения.

Гном - это C

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

Оставь C бородатым системщикам, у них так заведено, а приложение сделай на Vala. Да хоть на жабаскрипте/пистоне, по вкусу. Для интероперабилити в Linux есть замечательная штука - IPC (DBUS). Написал интерфейс, заимплементил и теперь к нему можно хоть через dbus-send стучаться из shell-скрипта. KDE именно таким образом обходит некоторые моменты, где можно получить зависимость от Glib.

У KDE проще, плюсы и Qt. Легко начать разрабатывать приложение

Вкусовщина. В GTK тоже можно написать в XML/нарисовать в Glade скелет приложения и заткнуть в нужных местах точки входа. Или как в старых добрых WinForms, создать объекты и воткнуть в нужные контейнеры. Всё приходит с опытом.

Хочешь expirience как в каком-нибудь комбайне аля Visual Studio, где IDE практически делает всё за тебя и бесплатно, вернись на винду и жди чуда.

прокачанные скилы пригодятся в оплачиваемых проектах

Я видел тред в Development, в котором выяснили, что С++ теряет в вакансиях, а Qt постепенно становится не нужен.