Разработка графических приложений под Linux для Windows Программистов. С чего начать? (перевод)

Разработка графических приложений под Linux  для Windows Программистов.

С чего начать?

Anthony Barker

Переходя с Windows на Linux вы начинате путаться в куче опций. QT или GTK+? Какой язык использовать: c/c++/java/perl/tcl/python/ruby или javascript? Должен ли я использовать коммерческие/проприетарные laypout/rad инструмента (QT или Kylix), либо opensource? А Mozilla? Я умею программировать в Visual Basic и Lotus Notes (Basic, Java, C / C + + API). С чего мне начать?

Начинайте с того что нравится

Я знал, что я люблю язык программирования Python, с его способностью сделать программирование «как можно более простым, но не простейшим» (Эйнштейн). Он позволяет программировать на высоком уровне и ваш разум освобождается для работы по другим вопросам. Поскольку структура кода является неотъемлемой частью языка я считаю, что такой код другим людям гораздо легче читать и понимать. Отсутствие необходимости компилировать экономит мне время на отладку и тестирование. Сбор мусора — это то, что я считать само собой разумеющимся. Так же я могу выбрать подходящий для меня стиль программирования, будь то процедурное, функциональное, объектно-ориентированное или смесь — за счет чего я могу выполнить работу  более быстро и эффективно. Приложения могут быть заморожены — сделать для облегчения распространения. Наконец, «batteries included» характерное для Python библиотек способствует повторному использованию кода и скорости развития.

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

Выбор инструментов

Я рассмотрел TK(2), GTK+(3), QT(4), wxWindows(5), MFC, Windows Forms (.NET), Swing (Java), и FOX(6) и пришел к следующим критериям оценки инструментов:

  1. Шаблонизация (Kylix, QT, GLADE)
  2. Интерфейс — Объектно-ориентированный язык или полу-OO
  3. Завершенность инструмента
  4. Количество и типы виджетов
  5. Качество виджетов/контролов
  6. Потребление ресурсов и Быстродействие
  7. Поддержка кроссплатформенности
  8. Лицензия
  9. Поддержка кросс-языковости
  10. И дополнительно:

  11. Нативный вид (часто важно для пользователя)
  12. Масштабность сообщества разработчиков
  13. Документация
  14. Легкость изучения

Результаты:

Оценка до 5 TK GTK+ QT -Kylix QT wxWindows MFC Windows Forms Swing FOX
Шаблонизация (Kylix, QT, GLADE) 2 4 5 5 4 3 5 4 3
Интерфейс — Объектно-ориентированный или полу-OO 2 2 5 5 5 3 5 5 5
Завершенность инструмента 4 4 5 5 4 5 3 3 3
Количество и типы виджетов 3 4 5 5 4 3 5 3 ?
Качество виджетов/контролов 3 4 5 5 5 4 5 4 ?
Потребление ресурсов и Быстродействие 4 5 5 5 5 5 5 2 ?
Поддержка кроссплатформенности 5 5 4 4 5 1 1 2 5
Лицензия
5 5 1 1 5 4 2 2 5
Поддержка кросс-языковости 5 5 1 4 5 2 4 1 ?
Нативный вид (часто важно для пользователя) 1 3 5 5 5 5 5 1 5
Масштабность сообщества разработчиков 3 4 4 4 4 5 5 4 3
Документация 4 3 4 5 4 2 3 4 2
Легкость изучения 4 3 4 4 4 1 3 2 ?
Весомый итог 55 61 60 64 69 48 54 41
Невесомый итог 45 51 54 58 59 43 51 37

Проприетарная помощь

Три или четыре варианта попираются на вершину. QT и Kylix оба предлагают великолепные, довольно простые в использовании RAD среды. Тем не менее, я использовал FoxPro и Lotus Notes — и я очень устала от собственных решений (оба поддерживают Unix, но я забросил это дело). Закрытость инструмента может очень негативно сказаться на вашем приложении в будущем. Компании создавшие ваше ПО могут принять решение об изменении направления и больше не вкладывать средства в ваш инструмент — и ваше приложение или устаревает, или умирает. Если вы разрабатываете приложение с открытым кодом на QT — вы ограничены в соответствии с лицензией на открытый код. Дорогое лицензии могут быть необходимы для портирования кода на Mac или Windows. Некоторые компании и инструменты (Java & Notes) ограничивают ваше право на распространение кода без дополнительной оплаты лицензий.

Мне нравится нативный вид

GTK+ и TK довольно неуклюже работают под windows и я хотел бы чтобы то что я пишу выглядело замечательно как на windows так и на mac. Посмотрим правде в глаза — большинство пользователей привыкли к использованию родных виджетов и, как правило оценивают приложение, по внешнему виду. Если вы хотите придерживаться стиля Unix то платформа GTK + и PyGTK являются хорошим выбором.

Mozilla — XUL
Другой вариант, кажется интригующим. Им является XUL — XML код, который создает основу для GUI Mozilla.
Среди его преимуществ — кроссплатформенный набор виджетов и возможность установки через браузер (. XPI-файлы) или можно запускать прямо с сервера (на XULPlanet есть прекрасный учебник). Я обнаружил protozilla — который дает способом создания локальных сценариев CGI или с использованием IPC (pipe), — но он показался мне нестабильным. Я также обнаружил, что вы можете получить доступ к COM-объектам через интерфейс IDispatch. Код в настоящее время выключен и не является частью программы Mozilla. Кроме того,код очень сырой, и тщательно не протестирован.
из почтовой рассылки:

Нестабильность Mozilla как платформы для разработки заставила отложить её до лучших времен.  Возможно, что все изменится в будущем.

wxWindows

wxWindows это открытый c++ инструмент который работает как тонкая прослойка между родными виджетами — GTK+, WIN32, Mac OS, Motif и т.п. У него имеется интерфейсы для c++, perl, python и ruby. Мне нравится идея набора виджетов, который представляет собой тонкую оболочку вокруг других — тем самым защищая вас от изменений и позволяющий вести кроссплатформенную разработку. Вначале были проблемы запуска WxPython под управлением Linux — Python — WxWindows, но Робин Данни улучшил установку для Linux — и теперь это доступно как обычная установка пакетом.

WxPython была создана Robin, который сделал инструмент, который помогает автоматизировать создание Python классов C или C + + API и WxPython — Python интерфейс для WxWindows. Существуют также интерфейсы для Perl & Ruby для тех, кто предпочитает эти языки. Еще одним преимуществом является возможность использования XML для программирования интерфейса (например, GTK +, QT, XUL). В теории это позволяет отделить графический вид программы от логики отображения. Также я бы хотел отметить, что очень быстро и легко можно создать графический интерфейс приложения. С другой стороны, хотя существует множество фрагментов и примеров кода, имеющихся пособий, большая часть документации, направлена на C + + программистов. Также замечу, что порт на Mac OS X не является полным.

В конце хочется спросить, «Что используют люди поумнее?»

Open Source Applications Foundation приняли решение об использовании WxPython через год раздумий
GNU Entreprise — используют WxPython в качестве основы для приложений клиент-сервер.
Многие другие организации используют WxWindows в той или иной форме

Итак. Какие виджеты я использую?

wxDesigner:
самый полный, но закрытый и коммерческий.
Сфокусирован на разработке под C++
Их редактор мне не понравился
Выводит xml, python, c++, или perl код
Хороший, дешевый, стабильный. Разработан одним из разработчиков WxWindows
wxGlade:
мой новый любимец — копирует все лучшее из glade. Легок в использовании и расширяем.
Не полный rad — больше экранной графики.
выводит xml, c++ или python код
хорошее руководство
Активная разработкаPythonCard:
Отлично подойдет для простых шустрых приложений.
Я считаю такого рода инструментов заставляет людей объединять бизнес-логику в графическом интерфейсе.
Скорость развития путем упрощения модели событий.
Вывод Python кода
Нет опции для XML-вывода — но это может быть скоро устранено
Активная разработка

XRC:
Простой редактор xml widget

Boa:
IDE
Слышал только хорошее и даже немного с ним поигрался

GNU Enterprise Form Developer
Нестабилен, но задатки хорошие.

Выбор текстового редактора

Самый популярные редакторы для Python это emacs, vi , и nedit. Я использую editplus под windows (из-за лени) и emacs, nedit , и vi под linux. Но выбор неограничен.
Если у вас есть отдельный от отрисовки интерфейса текстовый редактор попробуйте его — может быть вам понравится.

Автор: Mirivlad

Скромный труженик консоли и окошек.