Комментарии 68
было бы интересно какой-нить толстый гайд по созданию/редактированию .gtkrc-шных тем.
На первый взгляд ну оочень похоже на Qt. Даже сигналы и слоты есть.
Насчет комментариев не понял. Кто-нибудь просветит?
В официальной документации советуют не использовать комментарии в стиле C++ (//), т.к. могут быть проблемы на некоторых компиляторах.
Это относится, стати, не только GTK, но и ко всем программам на чистом Си.
Это относится, стати, не только GTK, но и ко всем программам на чистом Си.
В С89 отсутствуют одинарные комментарии. В C99 они присутствуют.
Я бы не стал особо заморачиваться поддержкой C89; согласно этому стандарту, переменные можно объявлять только в начале блока и нельзя объявлять переменную внутри конструкции for. Большинство современных компиляторов основные особенности C99 отлично переваривают.
Я бы не стал особо заморачиваться поддержкой C89; согласно этому стандарту, переменные можно объявлять только в начале блока и нельзя объявлять переменную внутри конструкции for. Большинство современных компиляторов основные особенности C99 отлично переваривают.
Кстати, а как у него с компиляцией под Win?
Что-нибудь известно по портированию GTK 3 на Windows и OSX? Когда я проверял последний раз, желающих портировать под Windows не было вообще, под OSX один энтузиаст неторопливо копал на основе jhbuild, но у него 10.5, апгрейдиться не собирается, и начинаю с 10.6 сборка, понятное дело, не работает :(.
Хотелось бы скачать весь исходник файлом.
Выложил на PasteBin — pastebin.com/iPttWBne
О, спасибо, хороший блог!
Для начинающих с GTK в C++ — лучше использовать gtkmm, не знаю как сейчас, но ранее (3-4 года назад где-то) — использовать сишный чистый gtk в программах с классами — намучился, определял, где нужно после передачи по указателю разрушать объект, где нет… документация была не на самом высоком уровне, так что приходилось экспериментировать.
В общем, если пишете на C++ лучше сразу использовать gtkmm, в своё время кучу кода переписывал из-за того, что посчитал проще пользоваться чистым gtk.
ps
Будет время, может, накатаю пару статей про использование pango\cairomm, да и остальные библиотеки в связи с gtk (скажем, opengl).
Для начинающих с GTK в C++ — лучше использовать gtkmm, не знаю как сейчас, но ранее (3-4 года назад где-то) — использовать сишный чистый gtk в программах с классами — намучился, определял, где нужно после передачи по указателю разрушать объект, где нет… документация была не на самом высоком уровне, так что приходилось экспериментировать.
В общем, если пишете на C++ лучше сразу использовать gtkmm, в своё время кучу кода переписывал из-за того, что посчитал проще пользоваться чистым gtk.
ps
Будет время, может, накатаю пару статей про использование pango\cairomm, да и остальные библиотеки в связи с gtk (скажем, opengl).
Хочу спросить, есть ли где-то описание/пример создания не окошка с 3 кнопками, а сколько-нибудь серьезного приложения, с таблицами, лейаутами и формами?
У меня есть подозрение, что этот GTK — тяжелая, медленная, плохо работающая под Windows, неэффективно взаимодействующая с графичским сервером, неудобная для разработчика библиотека. К тому же она написана в странной манере, на одних функциях.
У меня есть подозрение, что этот GTK — тяжелая, медленная, плохо работающая под Windows, неэффективно взаимодействующая с графичским сервером, неудобная для разработчика библиотека. К тому же она написана в странной манере, на одних функциях.
Это как раз те стереотипы, о которых я писал вначале топика. Для серьёзных приложений нужно наследовать класс GtkApplication и плясать от него. Я планирую написать целую серию уроков в этом блоге.
С каким графическим сервером и на какой OS оно неэффектино взаимодействует? С X11 на Windows?
Довелось работать с GTK и с Qt. GTK конечно не такой плохой, как вы его описали, но желания к нему возвращаться у меня нет никакого. Qt мне понравился намного больше. В Qt есть чёткая структура, а в gtk просто зоопарк каких-то функций, причём порой приходится через каждую минуту лезть в документацию, чтобы понять что к чему. К тому же Qt прекрасно работает под windows, да и вообще кроссплатформенность это главный козырь Qt, чего не скажешь про gtk. Плюс, у Qt документация лучше. Возможно когда-нибудь его допилят, а пока, если хотите изучать gtk, советую сначала посмотреть в сторону Qt.
Капитан Очевидность подсказывает что GTK+ также является кроссплатформенным и прекрасно работает и под Windows и под Mac OS: www.gtk.org/screenshots/
Насчет прекрасно я бы не совсем согласился. Все-таки, в отличие от Qt, GTK изначально не позиционировался как кроссплатформенный тулкит. Да, впоследствии он стал очень успешным и был портирован под OSX и Windows — но энтузиастами, по остаточному признаку. Как следствие — неродной вид интерфейса (Qt, между прочим, тоже рисует виджеты самостоятельно — но при это найти отличия от родного интерфейса очень трудно), сильное запаздывание новых версий (GTK3 в данный момент нормально работает только под *NIX, то же можно сказать про GObject Introspection — а технология довольно перспективная), баги вида «ничего не работает», которые не чинят годами (например, если окно GEdit под OSX попытаться поресайзить — он упадет. Известный баг GTK, но никто не чинит потому что нет энтузиастов возиться с «ненужными» OSX и Windows).
Написание комментариев в стиле /* коммент */ — это зло! Любые многострочные комментарии должны использоваться только во время отладки отдельным программистом. Самое банальное — я хочу переписать чью-то функцию, и комментирую её /* void some_func()… */, это заставляет лезть и выискивать все встроенные /*комментарии*/, тратить время.
Не понял, зачем вам искать все встроенные комментарии?
Извините, это наболевшее командной работы, когда нужно всё срочно, а приходится на таких мелочах тратить минуту-две выискивая эти комментарии.
А, понял о чём вы. Смутило слово «встроенные», я бы назвал их внутренними. Но с основным вашим тезисом не согласен — для отладки/тестирования/рефакторинга лучше использовать // (как раз из-за однозначности и легкости отмены), а для документирования /* */, которые со временными // не конфликтуют. Плюс /* */ любой компилятор съест, а не только тот, который вы используете для отладки, более переносимый способ для постоянных комментов.
Хотя, дело вкуса и соглашений проекта. Если, конечно, вы не блокноте работаете, и закомментировать блок в // много сложне чем в /* */ :)
Хотя, дело вкуса и соглашений проекта. Если, конечно, вы не блокноте работаете, и закомментировать блок в // много сложне чем в /* */ :)
Нормальные комментарии появились только в C++ и хотя многие компиляторы уже принимают и их в коде, по-прежнему есть компиляторы, которые будут выдавать ошибку. По этому, если пишете на Си, то используйте комментарии вида /* */, а если на С++, то можете использовать и то, и то.
#if 0
void f()
...
#endif
+1. Но не во всех редакторах такое комментирование переключает подсветку. Когда пишешь одновременно и на плюсах и на скриптовых языках, не сразу вспоминаешь про то, что можно воспользоваться препроцессором.
В нормальных редакторах есть функция которая (рас)комментирует блок, корректно обрабатывая внутренние комментарии.
когда я дома налегке пишу или в офисе неспеша — это одно. А когда срочно-срочно надо что-то пофиксить, а тем более удаленно — это другое. И вот в таких моментах. когда удалённо, начинаешь испытывать большую нелюбовь к многострочным комментариям.
Особенно на этом шишек набил, когда на производстве сидишь возле большого станка, срочно фиксишь что-то, а у тебя из имеющегося только простенький ноутбук с mc.
Особенно на этом шишек набил, когда на производстве сидишь возле большого станка, срочно фиксишь что-то, а у тебя из имеющегося только простенький ноутбук с mc.
Про #if 0 / #endif не слышал? Рикаминдую.
Спасибо, жду продолжения.
2012-й год. 17 лет после изобретения Delphi. Рисуем GUI ручками…
Надеюсь, для GTK+ есть удобный кроссплатформенный интегрированный редактор GUI. Иначе, для чего всё это?
Надеюсь, для GTK+ есть удобный кроссплатформенный интегрированный редактор GUI. Иначе, для чего всё это?
Конечно есть, это же статья для новичков. Позже будет и про редактор и про специальную среду разработки.
Есть glade, в котором можно набросать сложную формочку (да еще и с поддержкой gettext). Но некоторые формы удобнее создавать вручную.
Как правило, главная форма приложения создаётся вручную, а диалоги с настройками и т.д. в Glade. Такова традиция :-)
Смотря что там за форма. Мне удобнее было главное окно (с кучей менюшек и т.п.) сделать в glade, а также вспомогательные окна; всякую мелочевку (простенькие диалоги настройки, диалог открытия файла и т.п.) же я делал вручную.
В своё время долго копался в исходниках GNOME'овских программ, там везде, насколько я помню, диалоги лепятся в Glade, а главное окошко в коде. Ваша проблема, наверное, в том, что вы пытались делать тулбары и менюшки в коде, но это не true. Поищите в документации GtkUIManager — это как раз то, что вам нужно.
Пользуясь случаем, хочу передать привет задать вопрос специалистам по GTK. Вот такие комбобоксы — это разрабы Wireshark'а поленились пару пропертей выставить, или GTK по-другому не умеет (или не умел — скриншот старый)?
Сейчас проверил на последней версии (GTK 3.2). Комбобокс уходит вверх до конца экрана, но вниз не идёт. Наверное, это фича, а не баг.
Это фича GTK+. При раскрытии список комбобокса позиционируется так, чтобы выделенный элемент оставался под курсором.
Я не училсяся на программистов, но по роду деятельности иногда нужно писать простые приложения с графическим интерфейсом для настройки чего либо. Из последнего опыта, две программы для iPhone и одна на QT под линукс.
Акцентирую еще раз внимание, что я не программист, но начиная изучение c++ и qt с нуля, уже через месяц я написал нужную мне программу, на Айфоне я это сдела уже за несколько дней.
Но посмотрев как программировать на gtk, мне кажется тут с ума сойдешь изучать все эти функции, библиотека совершенно не само документирована, это очень усложняет и замедляет разработку.
Акцентирую еще раз внимание, что я не программист, но начиная изучение c++ и qt с нуля, уже через месяц я написал нужную мне программу, на Айфоне я это сдела уже за несколько дней.
Но посмотрев как программировать на gtk, мне кажется тут с ума сойдешь изучать все эти функции, библиотека совершенно не само документирована, это очень усложняет и замедляет разработку.
Вы не хотите продолжить курс лекций? Дело в том, что в рунете нет уроков по GTK. Единственное, что удалось найти — это ваши уроки. Хотелось бы продолжить изучение GTK.
Честно говоря, эта статья писалась только для того, чтобы заполнить пустой хаб «GTK+» на Хабре. Планов продолжать у меня не было.
Если вы хотите разобраться в GTK, то, я считаю, главное понять как в нем реализовано ООП (если вы пишете на C++ и gtkmm, то этот пункт для вас не актуален) и идею с контейнерами и виджетами (хотя, опять же, можно класть все в GtkFixed, но лучше так не делать). Дальше просто открываете документацию и изучаете, какие в GTK есть классы.
Также вам стоит посетить "Центр разработки GNOME", где собраны все актуальные примеры и руководства.
Если вы хотите разобраться в GTK, то, я считаю, главное понять как в нем реализовано ООП (если вы пишете на C++ и gtkmm, то этот пункт для вас не актуален) и идею с контейнерами и виджетами (хотя, опять же, можно класть все в GtkFixed, но лучше так не делать). Дальше просто открываете документацию и изучаете, какие в GTK есть классы.
Также вам стоит посетить "Центр разработки GNOME", где собраны все актуальные примеры и руководства.
Прекрасно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в GTK