MalcolmTredinnick

malcolm@commsecure.com.au

linux.conf.au Wednesday 14 January 2004 You now have enough knowledge to be able to learn the details of areas that are needed for your applications. Tutorial notes contain links to reference documentation and tutorials for many of the areas mentioned here. (Three hours earlier...) GNOME provides a large number of support libraries for building applications. Each piece can be understood (at least partially) in isolation. Working out the bigger picture can be difficult. Learning from existing applications does not always provide clear guidelines. Unless there is something similar to copy, where to get inspiration? GTK+ provides a basic collection of user interface widgets. Basic window types Some standard dialogs Input and display widgets Short string input (e.g. name) Larger text input and display (including markup). Numerical input via sliders. Tree and list displays. Based on a model/view architecture, so highly customisable. Layout based on a compose-and-pack model. Containers contain other widgets. Can have one (GtkBin, GtkRange) or multiple children (GtkVBox) Placing a larger widget inside a smaller one is not difficult (GtkScrolledWindow, GtkViewport). Constructing layouts best done using Glade Glade is a tool for designing user interfaces that use GTK+ and GNOME widgets. Libglade is a library that reads the XML produced by Glade (or another conformant tool) and constructs the usre interface when a program is run. True ListView Test Application GTK_WINDOW_TOPLEVEL GTK_WIN_POS_NONE False True False True True ... True True True ... ]]> Nice, easy to read text display is important. Internationalisation is important. Pango handles the layout of text. Direct interaction usually not needed ...but it does have a documented, public API if required. GtkTextView is the widget to use to display text. Portability layer. Constants and macros for data sizes, byte ordering, print format specifiers, ... Useful data structures and algorithms for working with them. Lists (single- and double-linked) Hash tables Trees Memory management assistance: various caching structures and helper functions. String functions (including Unicode support). Filesystem and process support. GLib (via GThread) provides an abtraction over common threading implementations: POSIX, Solaris. Code can be written to run with or without thread support. Libraries can be written to run correctly whether or not threads have been initialised. Event-based applications have many things waiting for something to happen. GLib main loop (g_main_*()) coordinates all of this activity. Functions can be called based on various triggers: During idle moments (priorities against other idle functions can be set). On a scheduled basis (using timeouts) When input arrives or output is ready to be sent (controlled by polling file descriptors). Not all external libraries fit into the GLib main loop structure easily. This can be a hinderance when leveraging existing work. Started out as a way to do object oriented C. Has grown into benefits beyond that. Objects have parameters which can be accessed controlled Read-only Read / write Write only at construction time, read any time. Parameter values can have a known type or be "boxed", making them opaque to applications. Objects can have descriptive enums associated with them. Slightly more powerful than the corrseponding C construct. Objects (can) communicate with other objects by emitting signals. Signals can be anything (new ones can easily be created). GTK+ widgets emit signals when they are deleted, changed, resized, edited, focused, clicked, dragged, ... Handlers for signals can be changed. Priorities can be assigned and bubbling of signals can be terminated. Very friendly to language bindings and dynamic programming. Introspection is possible (e.g. see gtk-doc) Parameters and signals comes with description strings (which should be filled in). Presenting help and tooltips is therefore simple. Some restraint is required! Not everything should be a GObject. Some performance impact (but don't overrate this problem. As a general rule: use GObjects for externally visible data structures. They are a bit more powerful than straight C structures (more language-binding friendly, for a start). Use GObjects when using signals + callbacks to communicate data and state changes is a good idea. A standardised daemon and API for storing configuration information. Information stored under a path into a registry-like structure. Originally designed to store parameters for running applications, not so much for persistent state. That is changing a bit now, since there is nothing else to server the "persistent state" requirement. Best description and overview of GConf is Havoc Pennington's paper from OLS 2002. Do not be tempted to use gnome-config in place of GConf. The former is not safe except when the user is only logged in once and running a single copy of the application. The bonobo infrastructure (named after the monkeys) provide a way to create reusable, composable components. Libbonobo provides the mechanism to create the components themselves. Factory management and object creation. Components can be activated by names based on the type of service interface they provide. This permits multiple implementations of an interface, although that feature is not really used in GNOME. A way to embed widgets managed by one application into another application. This is not too difficult. For example, to embed a PDF viewing component (in C): GtkWidget *widget; widget = bonobo_widget_new_control ("OAFIID:GNOME_PDF_Server"); gtk_container_add (GTK_CONTAINER (container), frame_widget); gtk_widget_show (frame_widget); For good example code of how to effectively use bonoboui and pluggable components, have a look at GEdit. High level application management. Program initialisation Help support High score handling for games Displaying URLs in configured application Some generic process management support (forking / execing programs). Obviously does not have to be used, since many programs exist that do not depend upon libgnome. Don't try to be too cute. Use it unless you have a good reason not to. Some extra widgets that are not currently available in GTK+ or that require extra dependencies above GTK+ in the stack. Plans to move as much as possible down into GTK+ in the future (much of this happening already). Generic filesystem layer. Makes manu resources accesible with Unix-like file commands. Lots of MIME-type detection knowledge. Support for finding standard directories such as the Desktop and Trash folders. Writing new modules is not difficult, but does not need to be done very often. Modules can be written and made available without needing to recompile the library. Provided by GStreamer Pluggable architecture. Components are strung together as a pipeline (which can branch and merge). Handles audio and video formats. Many different formats available. Writing new modules is not too difficult. Thursday 13:45 in Napier: Steve Baker talks about "The GStreamer Multimedia Architecture". Libxml is an extremely fast, highly correct implementation of a number of XML-related specifications. XML and XML Namespaces Schema support (in progress) Relax NG Used in a number of applications that require heavy XML processing: Gnumeric, Yelp, libbonobo Libxslt is an XSLT processor built upon libxml. Correctness and speed are the design goals and are well met. Active mailing list, good documentation (from beginner-level tutorial up to API documentation), very readable code. Libgnomeprint provides the application-level support. Libgnomeprintui provides the user interface portions. Suffered from some teething problems. Climbing back into respectability and acceptance. Future looks good with Cairo support in the pipeline. vte Embeddable terminal widget. Accesible, internationalisation support. Written as an experiment in reversing the purpose of termcap. Obvious example of use is gnome-terminal (which is vte in a window with a menu bar). gtksourceview Source code colouring (based on syntax file). Easily configurable. Look at source code highlightin plugin in GEdit. libwnck Common window-manager utility functions. Any utility that wants to work with desktop windows needs to use this. panel applets libpanelapplet provides common functions for creating these. The ability to use GNOME functionality through many languages is a real benefit. Extensive bindings exist for large portions of the platform. Python 11:00 on Friday in Napier: James Henstridge talks about GNOME + Python C++ C# Java Ruby Perl ... "Language Bindings" bundle being released. Does not contain all important bindings, but does have a good cross-section. You now hopefully have enough knowledge to be able to learn the details of areas that are needed for your applications. Tutorial notes contain links to reference documentation and tutorials for many of the areas mentioned here.