Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Пакет PIGUI (Platform Independent Graphical User Interface) - это библиотека программного обеспечения, которую программист использует для создания графического интерфейса для нескольких компьютерных платформ. Пакет представляет подпрограммы и/или объекты (наряду с подходом к программированию), которые независимы от ГУИ, на которые нацелен программист. Для того, чтобы программное обеспечение квалифицировалось как PIGUI, оно должно поддерживать несколько графических интерфейсов по крайней мере в двух разных операционных системах (например, поддержка только OPEN LOOK и X11 на двух коробках Unix не учитывается). Пакет не обязательно обеспечивает какие-либо дополнительные функции переносимости. Природный вид и ощущение - это желательная особенность, но не является обязательной для PIGUIs.
A PIGUI (Platform Independent Graphical User Interface) package is a software library that a programmer uses to produce GUI code for multiple computer platforms. The package presents subroutines and/or objects (along with a programming approach) which are independent of the GUIs that the programmer is targeting. For software to qualify as PIGUI it must support several GUIs under at least two different operating systems (e. g. just supporting OPEN LOOK and X11 on two Unix boxes doesn't count). The package does not necessarily provide any additional portability features. Native look and feel is a desirable feature, but is not essential for PIGUIs.
Рассмотрение
Использование PIGUI имеет ограничения, например, PIGUI занимается только графическими аспектами программы, поэтому программист отвечает за другие проблемы переносимости, большинство PIGUI замедляют выполнение полученного кода, и программисты в значительной степени ограничены набором функций, предоставляемых PIGUI. Зависимость от PIGUI может привести к трудностям в проекте, поскольку меньше людей знают, как кодировать любой конкретный PIGUI, чем GUI, специфичный для платформы, ограничивая количество людей, которые могут дать расширенную помощь, и если поставщик выходит из бизнеса, может не быть дальнейшей поддержки, включая будущие улучшения ОС, хотя доступность исходного кода может облегчить, но не устранить эту проблему. Кроме того, ошибки в любой упаковке, включая PIGUI, фильтруются вниз до производственного кода.
Using a PIGUI has limitations, such as the PIGUI only deals with the GUI aspects of the program so the programmer responsible for other portability issues, most PIGUIs slow the execution of the resulting code, and programmers are largely limited to the feature set provided by the PIGUI. Dependence on a PIGUI can lead to project difficulties since fewer people know how to code any specific PIGUI than do a platform specific GUI, limiting the number of people who can give advanced help, and if the vendor goes out of business there may be no further support, including future OS enhancements, though availability of source code can ease but not eliminate this problem. Also, bugs in any package, including the PIGUI, filter down to production code.
Альтернативные подходы
Веб-браузеры предлагают удобную альтернативу для многих приложений. Веб-браузеры используют HTML в качестве уровня презентации для приложений, размещенных на центральном сервере, а веб-браузеры доступны практически для каждой платформы. Однако некоторые приложения не подходят для веб-парадигмы, требуя локального приложения с возможностями графического интерфейса. Если такие приложения должны поддерживать несколько платформ, PIGUI может быть более подходящим. Вместо использования PIGUI разработчики могли разделить свои приложения на объекты GUI и не GUI и реализовать объекты GUI в собственном API. Затем, при переносе, только объекты графического интерфейса должны быть переписаны для новой платформы. Некоторые разработчики программного обеспечения рекомендуют этот способ, поскольку он лучше подходит для каждой платформы и устраняет накладные расходы, часто связанные с инструментами PIGUI. Очевидно, что это может потребовать больше усилий как в начальной разработке, так и в текущем обслуживании (нет единой базы исходного кода). Это также означает, что нужно научиться программировать для каждой целевой платформы, что (обычно) не является тривиальной задачей, отсюда и рынок для пакетов PIGUI.
Web browsers offer a convenient alternative for many applications. Web browsers utilize HTML as a presentation layer for applications hosted on a central server, and web browsers are available for pretty much every platform. However, some applications do not lend themselves well to the web paradigm, requiring a local application with GUI capabilities. Where such applications must support multiple platforms, PIGUI can be more appropriate. Instead of using a PIGUI, developers could partition their applications into GUI and non GUI objects, and implement the GUI objects in the native API. Then, when porting, only the GUI objects need to be rewritten for the new platform. There are some software developers who recommend this course of action, as it produces a better fit on each platform and eliminates the overhead often associated with PIGUI toolkits. Obviously, this may require more effort in both the initial development and in ongoing maintenance (no single base of source code). It also means learning how to code for every target platform, which is not (usually) a trivial task, hence the market for PIGUI packages.
Подходы к пользовательскому интерфейсу
Большинство, если не все, пакеты PIGUI используют один из трех подходов к обеспечению независимости платформы. Два наиболее распространенных подхода - это "слойный" и "эмулированный" пользовательский интерфейс, но новый подход - это "эмулированный" интерфейс API. Пакеты, использующие многоуровневый интерфейс, имеют доступ к нативным, сторонним, GUI-инструментальным наборам для создания внешнего вида и соответствия каждому конкретному GUI. У слоистых пользовательских интерфейсов есть преимущество в том, что, поскольку они зависят от других продуктов, которые сосредоточены на одном графическом пользовательском интерфейсе, они должны предоставлять меньше программного обеспечения (и, следовательно, обычно дешевле), чем эмулированные интерфейсы. Слоистые интерфейсы также с большей вероятностью получат свой внешний вид и будут чувствовать себя правильно на всех платформах. В эмулированном пользовательском интерфейсе полученный код PIGUI производит вызовы низкого уровня, и все внешние характеристики выполняются самим программным обеспечением PIGUI (например, для поддержки OpenWindows программное обеспечение НЕ будет создавать программу XView, которая должна быть скомпилирована с XView; программное обеспечение будет создавать код, который напрямую взаимодействует с внутренними компонентами X). Для обеспечения эмулированного пользовательского интерфейса поставщику пакетов приходится разрабатывать много дополнительного кода для поддержки внешнего вида. Эмулированные пользовательские интерфейсы имеют преимущество в том, что кто-то на рабочей станции X11, например, может увидеть, как будет выглядеть пользовательский интерфейс в стиле Macintosh (поскольку внешний вид и ощущение являются частью продукта). Эмулированные интерфейсы имеют возможность обеспечить более быстрый графический интерфейс, чем многоуровневый интерфейс; кроме того, он не требует покупки (или изучения использования) других пакетов для создания программного обеспечения графического интерфейса. Третий подход к независимости платформы - эмуляция одного из поддерживаемых API-интерфейсов целевой платформы (обычно API-интерфейса Microsoft Windows) для нацеливания на другие графические интерфейсы. С одним из этих продуктов можно было бы программировать с использованием эмулированного API, и код был бы (в той степени, в которой продукт обеспечивает переносимость) переносим на другие графические интерфейсы.
Most, if not all, PIGUI packages take one of three approaches to providing platform independence. The two most common approaches are the `layered' and the `emulated' user interface but an up and coming approach is `API emulated' interface. Packages using a layered interface access native, third party, GUI building toolkits to provide the look and feel compliance for each particular GUI. Layered user interfaces have the advantage that, since they depend on other products which concentrate on a single GUI, they have to provide less software (and, hence, are usually less expensive) than emulated interfaces. Layered interfaces are also more likely to get the native look and feel correct on all platforms. In an emulated user interface, the PIGUI's resultant code produces low level calls and all the look and feel compliance is handled by the PIGUI software itself (e. g., for OpenWindows support, the software would NOT produce an XView program that must be compiled with the XView toolkit; the software would produce code that interfaces directly with X intrinsics). To provide an emulated user interface, a package provider has to develop a lot of extra code for look and feel support. Emulated user interfaces have the advantage that someone on a X11 workstation, for example, can see how the Macintosh style UI will look (since the look and feel is part of the product). Emulated interfaces have the opportunity to provide a faster GUI than does a layered interface; in addition, it does not require purchase of (or learn how to use) other packages to build GUI software. A third approach to platform independence is emulating one of the supported target's APIs (usually, the Microsoft Windows API) to target other GUIs. With one of these products, one would program using the emulated API and the code would be (to the extent to which the product provides portability) portable to other GUIs.