\documentclass[12pt]{article} \usepackage[british]{babel} % Proper, UK-English hyphenation \usepackage{graphicx} \usepackage[footnotesize]{caption} \usepackage{url} % Use {\url foo} to format URL correctly (used in bib) %\usepackage[left=35mm, top=24mm, right=24mm, bottom=24mm]{geometry} \usepackage[dvipdfm, left=35mm, top=24mm, papersize={210mm, 297mm}]{geometry} % Include dvipdfm specials, and use ISO A4, not shonky LaTeX A4. \usepackage{tocbibind} % Puts TOC and references in the TOC \usepackage{charter} % Charter font is a little nicer \usepackage{type1cm} % Allows rescalable Computer Modern \usepackage{longtable} % Tables that break over pages % booktabs -- nice tables % tabularx -- multi-line table cells (paragraphs in table cells) %\bibliographystyle{plain} \bibliographystyle{ieeetr} \newcommand{\superscript}[1]{{\scriptsize{\ensuremath{^\textrm{#1}}}}} \newcommand{\subscript}[1]{{\scriptsize{\ensuremath{_\textrm{#1}}}}} \begin{document} \begin{titlepage} \begin{center} {\large {\sc School of Electronics and Computer Science\\ University of Southampton}\\[4.5cm] }{\Large Chris Lord\\[0.8cm] \today\\[2.0cm] {\bf Small-Screen HTML Rendering on Memory Constrained Devices}\\[5.5cm] Project supervisor: Dr Kirk Martinez\\ Second examiner: dr monica schraefel\\[2.0cm] A project report submitted for the award of\\ MEng Computer Science } \end{center} \end{titlepage} \pagenumbering{roman} \begin{abstract} \setlength{\parindent}{0pt} \setlength{\parskip}{2ex plus 0.5ex minus 0.2ex} Most web content is designed to be viewed on a desktop PC with a large, high-resolution display. With the increasing popularity of mobile, web-capable devices, it is advantageous to have a method of increasing the accessibility of this content on platforms it wasn't designed for. In this report, a technique is proposed that uses styling and JavaScript to provide a browser-agnostic method of reformatting web-pages for small screens. For these techniques to be effective on a memory-constrained device, work was undertaken on a small, open-source HTML rendering engine to increase its functionality in regards to viewing modern web-pages, and a browser was created to use it. It was shown that style-sheets and selective styling using JavaScript are effective methods for reformatting web content, and that these techniques can be applied in a modern web browser with very little overhead. The rendering engine provides a comprehensive base for development; however, at this stage is not deemed stable enough for mainstream use. \setlength{\parskip}{0ex plus 0.1ex minus 0ex} \end{abstract} \newpage \tableofcontents \newpage \null\vfil \begin{center} \begin{minipage}{14cm} \begin{center}\textbf{Acknowledgements}\end{center} \addcontentsline{toc}{section}{Acknowledgements} I would like to thank Matthew Allum of OpenedHand, for providing me with a subversion repository to store my work, and Dr. Kirk Martinez for his encouragement and support throughout this project. Thanks also goes to fellow students John-Mark Bell, for his help in the understanding of w3c standards and HTML rendering issues, and Philip Boulain, for the \LaTeX{} template used in this document. \end{minipage} \end{center} {\par\vfil\null} \newpage \pagenumbering{arabic} \setcounter{page}{1} \setlength{\parindent}{0pt} \setlength{\parskip}{2ex plus 0.5ex minus 0.2ex} \section{Introduction} The majority of web content is not suitable for viewing on small displays\cite{web-interaction}. Additionally, convergent devices such as smart phones and Internet tablets are becoming more popular. It is becoming more common for entry-level mobile phones to include web-browsing capabilities and as such, a wider user-base is being subjected to web content on small screens. Unfortunately, this trend has failed to be adequately handled by the web at large, with very few non-technical pages providing for small-screen devices. It is clear that an interim solution is called for, that allows unaltered web pages to be viewed on devices with small screens. There are several methods currently employed in modern mobile browsers for reformatting web content that wasn't intended to be displayed on small screens (see \ref{mult-paper}). Most of these techniques involve the use of styling or content extraction. \subsection{Project Goals} This project aims to provide an open alternative to the current closed, commercial solutions (e.g. Opera\cite{opera}) to web-browsing on small-screen, memory constrained devices. This problem will be addressed on multiple levels. \subsubsection{Browsing Interface} A browser interface must be designed that will be suitable for use on small displays. The target device for this project will be an average PDA (Personal Digital Assistant), such as an HP Ipaq\cite{ipaq}, a Palm\cite{palm} or a Sharp Zaurus\cite{zaurus}. Ideally, this interface will scale down well enough to be used on smart-phones and scale up well enough to be used on slightly larger form-factor machines, such as tablet PCs or small-form-factor notebooks. This also infers that the interface must be possible to operate with input methods ranging from a key-pad, to a touch-screen, up to the more conventional keyboard and mouse. \subsubsection{Rendering Engine} A rendering engine must be chosen or created, that is capable of displaying modern web-sites adequately and that is memory-efficient. As bandwidth availability increases and pages become more media-rich, it is important that memory be conserved as much as possible. This rendering engine must include the ability to parse JavaScript and CSS (Cascading Style Sheets), to not only display pages correctly, but to allow for restyling. \subsubsection{Small-Screen Rendering} A set of scripts must be developed that increase the accessibility of web content not designed to be displayed on small screens. The nature of these scripts will be determined by the rendering engine, but there must be the possibility for them to be easily reused in other browsers. What comprises `increasing accessibility' will be determined via research and analysis. An important distinction that must be made in the design process is the difference between pixel resolution and DPI (dots per inch)\cite{design-small}. \newpage \section{Research Report} Note, some of the information in this section is covered in greater detail in the attached research paper (see \ref{mult-paper}). \subsection{DOM-based Content Extraction of HTML Documents\cite{dom-extract}} \label{research-dom} The technique covered in this paper performs simple analytical techniques on the DOM (Document Object Model) to perform content extraction. For example, one of the techniques it proposes, is that by analysing the percentage of text that is a link in a particular paragraph, it can be identified whether that paragraph contains important information. Depending on the result, the paragraph can be positioned elsewhere in the document, or removed from the DOM tree entirely. An advantage of this technique is that the original structure of the page remains, thus reducing the amount of input necessary to view content. This technique could prove to be problematic for pages that make heavy use of JavaScript though, as these pages could rely on the structure of the DOM and may produce unexpected results if it has been extensively modified externally. Another danger of techniques that exclude content in general is that the wrong content may be excluded. For example, the method proposed in this paper fails on sites that make heavy use of links in the main content, as shown in figure 12 of said paper. \subsection{The Gateway: A Navigation Technique for Migrating Small Screens\cite{gateway}} The Gateway is a method of displaying a full page on a small screen without employing any modification of page layout or content. The advantage of this is that there is no possibility of making page content inaccessible or altering its meaning, or of breaking the functionality of any JavaScript performing on that page. The Gateway works by scaling a full rendering of the web page to the dimensions necessary to fit in a single screen on the target display. The page remains static and a user can select parts of the content that would like to view in additional detail, at which point it provides a full-scale view of that particular component. A disadvantage of this technique is that it isn't designed to be used in conjunction with any other methods, and cannot feasibly be performed in a browser-agnostic fashion. In addition to this, this method relies on some familiarity with the page content, as the paper itself admits, and does not fare well in the condition of browsing to a new page, or a recently re-designed page. \subsection{An Alternative to Scrollbars on Small Screens\cite{alt-scroll}} `Flip Zooming' (the name of the technique covered in this paper) employs a zooming view of the document and also removes all scroll-bars, similar to The Gateway. To achieve this, pages are broken up into pieces, or `cards', that fit on the target device display. The currently focused card is displayed at the original zoom level in the centre of the display, surrounded by the other cards, displayed at a much lower zoom level. Shortcuts are provided for switching between the next and previous pieces. The process of splitting a web page into cards requires some analysis for those cards to contain relevant information, and thus for the technique to be useful. The implementation in this paper uses a simple (but undocumented) lexical analysis algorithm. It was found that the unfocused cards were too small to be of use unless a user had previous knowledge of the layout of the page, and so further techniques were used to extract content, such as those used in \cite{dom-extract}, and provide a summary. A disadvantage of this technique is that there is a considerable familiarisation period. An ideal solution would be intuitive enough to be obvious on first glance how things work, or require very minimal discovery. This method relates to the proposed method of this project, in that it involves some analysis to find important/lengthy areas of the page and then a summarisation of those areas, as well as a method to switch between these two views. \subsection{Existing Packages} \label{existing} A number of browsers exist that partly fulfil these project goals, both commercial and open-source. As much as is possible, duplication of work will be minimised. \subsubsection{Minimo Browser and The ``feel-like-a-cellphone'' Style-sheet\cite{minimo}} Minimo is an open-source browser using the Gecko rendering engine, compiled with minimal build options to reduce memory requirements (both storage and system memory). To achieve small-screen rendering, it uses a style-sheet. As it is based on the same rendering engine as popular desktop browser Firefox, the rendering quality and standards support is unrivalled. Unfortunately, due to this same reason, memory requirements are also high, and Minimo struggles to run on platforms with less than 64 megabytes of RAM. By examining the CSS that Minimo uses\cite{minimo-css}, it can be seen exactly what methods it uses to reformat pages. The Minimo CSS works by overriding properties of the style of the page in question. In summary, it `stacks' elements that would otherwise have been placed horizontally, such as table rows, and enforces a maximum width of the page width on all elements, to remove the horizontal scrollbar. \subsubsection{Opera Web-Browser\cite{opera}} Opera is a leading closed-source browser that enjoys success on a diverse range of devices, from mobile phones to hotel kiosks. Rendering speed and memory usage in Opera compares favourably to Gecko-based browsers and many versions also include effective small-screen rendering\cite{opera-ssr}. Opera currently appears to be the leading browser on many mobile platforms. Opera appears to use a similar method of small-screen rendering to Minimo, but applies it selectively. Results are always either similar or superior to Minimo's primitive method. Similar results to Opera could perhaps be produced with a combination of JavaScript and CSS. Opera only uses its small-screen rendering when the site itself makes no provision for mobile devices (e.g. via the @media rule\cite{css-media}). \subsubsection{Webcore\cite{webcore}} ``{\it WebCore is a framework for Mac OS X that takes the cross-platform KHTML library (part of the KDE project)\cite{khtml} and combines it with an adapter library specific to WebCore called KWQ that makes it work with Mac OS X technologies.}''\cite{webcore} As well as Mac OS X, WebCore is also available on Qt-based platforms, via KHTML\cite{khtml}, Qt/Embedded-based platforms, via Konqueror Embedded\cite{konq-e}, and GTK-based platforms via Gtk+ WebCore\cite{gtk-webcore}. In comparison to the Gecko engine, WebCore is small (in terms of storage and system memory) and fast, but doesn't meet the same standards as the Gecko engine in terms of standards support and stability. \begin{figure} \centering \includegraphics[width=0.3\textwidth]{s60-9.jpg} \caption[Nokia's WebCore-based Symbian browser showing the `mini-map' feature]% {Nokia's WebCore-based Symbian browser showing the `mini-map' feature\footnotemark} \label{fig:nokia-webcore} \end{figure} Nokia have produced a mobile browser based on a Symbian port of WebCore for the Nokia S60. Although it features no form of small-screen rendering, it does feature a unique method of scrolling a page (the `mini-map', shown in Figure \ref{fig:nokia-webcore}) and a graphical history browser\cite{nokia-webcore}, both features that aid the browsing experience on small screens. \footnotetext{Image reproduced with kind permission of Eugenia Loli-Queru from article\cite{nokia-webcore}} \subsubsection{Dillo\cite{dillo}} Dillo is an open-source browser project whose primary features are its tiny size and its speed. It is easily the smallest and fastest product for HTML rendering in comparison to other major products (both commercial and open-source), however its support for basic web features and standards is lacking. Although Dillo has no provisions for a small-screen rendering function and inadequate support for easily integrating such a feature, it has been used as a mobile browser in the past, as the primary browser in the Familiar Linux distribution\cite{familiar}. \subsubsection{NetSurf\cite{netsurf}} NetSurf is another open-source browser, aimed primarily at RISC OS. Similarly to Dillo, it is fast and light on resource usage, but also features significantly higher rendering quality and standards support. NetSurf is tested to work on multiple platforms. Again similarly to Dillo, NetSurf features no feature specifically aimed at increasing accessibility on small-screen devices. It does, however, feature good CSS support, leaving the possibility of small-screen rendering using a special style-sheet, similar to Minimo. \newpage \section{Analysis and High-level Design} \subsection{Target Requirements} \label{requirements} It is suggested that the project be implemented on a typical low-end PDA. As such, the browser should be able to function adequately: \begin{itemize} \item within a 32 megabyte RAM limit \item with processors similar in performance to a 200Mhz StrongARM without a floating point unit \item with a touch-screen and no physical keyboard input \item at resolutions ranging from 320x240 to 800x480 \item at screen sizes ranging from approximately 3" to 5" diagonally \end{itemize} Possible open development environments could include the Opie environment\cite{opie} (based on Qtopia), which would then target all PDAs supported by distributions such as OpenZaurus\cite{openzaurus}, Familiar Linux\cite{familiar} and possibly Qtopia-based devices; or a GTK+-based environment, which would target similar PDAs to the Opie environment and also include other GTK+-based devices, such as the Nokia 770\cite{nokia770} and possible future Palm-OS based PDAs\cite{palm-linux}. \subsection{Browser Design} \label{design} In terms of architecture, a modular design will be used. This will reduce the chance that changes or failure in one unit will have a large affect on other parts. The browser will be split into four modules; user interface, HTML rendering, data fetching and bookmarks. The HTML rendering will interface with the user interface via a plug-in extension system. This will enable the parallel development of different rendering back-ends and also make the interface re-usable. As the rendering engine is the largest part of a web browser, using plug-ins allows smaller devices and larger/more powerful devices to share a unified interface but have differing engines. This modular design will help aid flexibility as it minimises the changes necessary for differences between platforms. As the primary interface will be a small touch-screen-based device, it is important to implement an easy method of scrolling and include features such as jitter-correction, when such features are lacking or inadequate on the device itself. Similarly, as storage space is limited and a portable device is unlikely to be a users' primary device for web browsing, integration with a shared bookmarks service, such as del.icio.us\cite{delicious}, would be of benefit. \subsection{Small-Screen Rendering} For small-screen rendering to be achieved in a browser-agnostic way, it needs to be implemented in terms of features that most rendering engines have. The most obvious way of implementing this would be to use a combination of JavaScript and CSS. CSS allows for styles to be aimed at particular devices with the @media rule\cite{css-media}. JavaScript would allow for a `catch-all' style-sheet to be applied in the case of a missing style-sheet, when a particular device is targeted. JavaScript would also allow special style cases (such as flattening large tables but leaving smaller tables alone) and DOM restructuring. Although a browser must then have the ability to apply a user script to any arbitrary page, it would allow the flexibility for these scripts to be used at the server-side, or even via a proxy. To increase accessibility, certain page aspects need to be tweaked. These include things like font-sizes, alignment, padding and image sizes. CSS provides a mechanism for overriding previously set attributes\cite{css-important}, allowing for certain design choices that may make sense on a larger screen to be overridden on devices where they are unsuitable. Some primitive ways of increasing accessibility on any given page would include operations such as making sure all hyper-links are underlined, making anchor titles visible without using a hover mechanism, reducing margins and padding, and resizing images to fit the page width. \newpage \section{Detailed Design} \subsection{Browser Architecture} The class diagram in Figure \ref{fig:class-diagram} illustrates the browser architecture suggested in \ref{design}. It is aimed for the exported interface to be as simple as possible. \begin{figure}[!htb] \centering \includegraphics[width=0.8\textwidth]{class-diagram.pdf} \caption{Class diagram illustrating browser architecture} \label{fig:class-diagram} \end{figure} \subsection{User Interface} The user interface module exports controls for navigation and includes history and bookmarks features. These are public attributes, to allow for the rendering back-end to implement all HTML DOM features (which include history and navigation manipulation). The user interface also has a `Pages' attribute, to allow for multiple open pages, or tabs. The user interface will be aimed primarily at small (~3-4") touch-screens, and as such, all functionality must ideally be reachable with a single click/tap. Due to the small screen size, it is also a requirement that targets be of a reasonable size. This means hierarchical menus should be avoided or at least, menus should not be necessary to reach vital functions. A side-effect of designing with a touch-screen in mind is that the interface will also be amenable to one-button mouses. \begin{figure} \centering \includegraphics[width=0.4\textwidth]{ui-design.png} \caption{Suggested design for user interface} \label{fig:ui-design} \end{figure} The user must be able to access and browse to bookmarks, add bookmarks, search the page and navigate page history, all within a single click. Each of these use cases must be obviously reachable. A suggested interface is shown in Figure \ref{fig:ui-design}. The address entry and bookmarks display would be hidden until the user chooses to visit a URL, which they do by activating the `Go' button. When the URL is loading, the bookmarks will again be hidden and the address bar will be replaced with a progress bar. Similarly, the find bar will be hidden until the user activates the `Find' button. Separate pages will be displayed in tabs, with a new page opened via clicking an always-present `New' tab. \subsection{HTML Rendering} Top priorities for the HTML rendering back-end are low memory usage, good CSS support (especially the @media rule) and JavaScript support. This will allow for the small-screen rendering scripts to be implemented without any browser-specific code. To provide an integrated look and feel, and to decrease system and storage memory use, the native shared libraries of whatever development platform is picked should be used. \subsection{URL Fetching} URL fetching is separated from HTML rendering to allow the HTML rendering engine to be as small and efficient as possible and to maintain control over data flow. Transfers should have support for local file and http access. The browser could be used as a system documentation browser, in which case only local file access would be necessary and the module could be modified accordingly. Maintaining control over URL fetching allows for features like data-limiting, which would be of benefit when service charges are calculated by consumed bandwidth. \subsection{Small-Screen Rendering} Small-screen rendering should be implemented using a combination of JavaScript and CSS. The HTML DOM provides functions for adding style-sheets, so this should be possible to implement with a single script. JavaScript can be used to selectively style certain elements, such as large tables, much like Opera appears to do. An important concern when manipulating the DOM is to maintain document integrity. The page needs to be reformatted, but not at the expense of usability. Pages are likely to rely on element IDs to remain the same and for elements to not be removed from the DOM tree entirely, so such manipulations should be avoided. Mozilla Firefox\cite{firefox} allows for arbitrary scripts to be executed on pages via the greasemonkey\cite{greasemonkey} extension, so this can be used as a test-bed for support in an external browser. The ``feel-like-a-cellphone''\cite{minimo-css} style-sheet would make a good starting point for implementing small-screen rendering. Further development on this would involve analysing what it does to a page, and splitting these tasks up to be applied selectively via JavaScript and analysis of the DOM. An example case that this style-sheet does not handle correctly is that of small tables. A table that represents a calendar, for example, has 7 columns and 5-6 rows, with each cell containing a maximum of 2 characters. There is no problem with displaying this on a small screen, but this style-sheet will make each cell display on a new line, making it unreadable and increasing vertical scrolling. An important feature of the script that will result from this is that it disables itself when a style-sheet exists on the page for small-screen rendering. If this style-sheet is aimed for the @media type 'hand-held', it must not apply any re-styling when the page already contains a style-sheet for this type. \subsubsection{Collapsing Paragraphs} In addition to condensing page width, page elements could be made to interactively expand/collapse to condense page height. For example, large paragraphs could be hidden, and in their place, an ellipses of that paragraph with an indicator to the user that clicking this ellipses will provide a full view of said paragraph. This is some-what similar to the ideas discussed in \cite{improving-usability}. A challenge with this is in identifying paragraphs. Web pages often layout their paragraphs using line-break tags, or 'div' tags. This makes the task of identifying long regions of related text a more difficult one. A potential technique for overcoming this would be to identify regions of text via text elements, but these can be interrupted by anchors. This feature will be implemented as an experimental option. \newpage \section{Implementation} \subsection{Development Process} To ensure that a deliverable will always be possible, a rapid application development process was used. This allows for evolving prototypes and has the consequence of there being a demo-able product very early in the development cycle. This was chosen over processes based on the waterfall life-cycle as it more quickly allows development to begin. The down-side of this process is that the final product may sacrifice features, but the guarantee of there being a final product overcomes this. All code and development was kept in a version control system and all changes have been recorded. The annotated change history can be viewed in \ref{web-changelog}. \subsection{Development Platform} A GNU/Linux-based development platform was chosen. Linux is increasingly being used for embedded solutions and has a very wide support of different systems. This allows the potential for the final product to work on practically any major system. In combination with cross-platform tools, it also eases portability to non-Linux platforms. By choosing Linux as the primary development platform, the active community and growing commercial support can be taken advantage of. \subsection{Tools} All tools chosen have the possibility to compile on both Linux and Windows, increasing the possibility of a port to a Windows-based platform in the future. \subsubsection{GLib, GTK+, Libglade \& GConf} GLib provides a wide array of general-purpose functions, for use in C programs, similar to the standard template library for C++. It also provides a framework for writing object-oriented code in C. This framework helps to improve general code structure, and thus issues such as memory leaks are reduced. As GLib also has a signalling system that can be used with its objects, it provides a perfect framework for implementing the DOM and DOM events. GLib also has a flexible main-loop, allowing for tasks that may usually be handled in multiple threads to be handled using co-operative multi-tasking, decreasing code complexity and increasing portability. GTK+ is a graphical widget toolkit and general graphics display and input/output library. GTK+ is based on GLib and is object-oriented, allowing any of its widgets to be extended. To make the interface design and maintenance easier, Glade was used. Glade provides a graphical point-and-click interface to design GTK+ interfaces and stores them in XML files. GConf is a system that stores application settings. It works as a daemon and has the ability to notify applications when their settings are changed, allowing applications to react to settings changes instantly, as soon as they are changed, no matter what application changed them. GConf allows for application setting schemas to be installed and removes (somewhat) the need for an application to do its own settings integrity checking and configuration file parsing. This combination of libraries was chosen for their maturity and portability. All three work in both Windows and Unix-like systems and have bindings for several languages. They have also been used in commercial embedded systems, such as the Nokia 770, thus proving their suitability to this task. \subsubsection{GTKHTML2} GTKHTML2 is a GTK+/GLib-based HTML rendering library. Unlike many HTML rendering libraries, it strictly deals with just HTML rendering and not URL fetching or JavaScript interpreting. GTKHTML2 was chosen due to its easily extensible GObject-based architecture, its semi-adequate feature set (see \ref{gtkhtml2-improve}) and its very low system and storage memory requirements. Many augmentations were required to make GTKHTML2 an adequate library for the task. GTKHTML2 takes full advantage of GTK+, going so far as to use GTK+ widgets for HTML form elements. This provides an integrated look and feel that few other rendering engines could offer. \subsubsection{SpiderMonkey: A JavaScript interpreter} Spidermonkey was the only viable, light-weight JavaScript interpreter that could be found for this project. Luckily, its support for JavaScript is comprehensive and it is used in many projects, including all Mozilla browsers (such as Firefox and minimo). As it is used in the mozilla browsers, it receives wide and thorough testing on many platforms, and so fulfils the requirement of being easily portable. \subsubsection{cURL} cURL is a multi-protocol file transfer library that is very highly portable. It supports all platforms that GLib supports and a host of others, making it the most portable element chosen to complete this project. Numerous transfer libraries were auditioned during the implementation phase, but cURL was finalised on due to its highly configurable nature, wide protocol support and sensible API (Application Program Interface). cURL is easily integrated into the GLib main-loop, as proven by glibcurl\cite{glibcurl}, which does exactly that and which is used in this project. \subsection{Implementing the Browser} The first task in implementing the browser was deciding on an API for the plug-in system. Although the class diagram in Figure \ref{fig:class-diagram} shows a suggested interface, the final interface required a slight elaboration. The rendering plug-in interface has the following functions: \begin{itemize} \item init - This function is called once when the browser is loaded, and should perform any one-time initialisation necessary. \item deinit - This function will be called before the application exits. The back-end should do any clean-up necessary in this function. \item new - This function is called when the browser needs to create a new page, and is expected to return a GtkWidget that the browser can embed. \item destroy - This function is called when the browser needs to destroy a created page. \item write - This function writes data for a particular URL request. Page requests originate from the UI, and data requests that are necessary to render a page are generated by the back-end. \item clear - This function clears the page. \item close - This function closes a request. It can also be used to cancel requests. \item get\_zoom - This function retrieves a page's zoom level. \item set\_zoom - This function sets a page's zoom level. \item add\_style - This function adds a user style-sheet to a page and returns a pointer. \item remove\_style - This function removes a style-sheet from a page. It expects a pointer that was returned from add\_style. \item add\_script - This function adds a user-script to the page. It will be executed after a page has fully loaded. The function returns a pointer. \item remove\_script - This function removes a user-script from a page. It expects a pointer that was returned from remove\_style. \item set\_media - This function sets the css media type and is applied instantly to the page. \end{itemize} The plug-in system is implemented using the GLib GModule functions. Along with the functions documented above, each plug-in also exports an API version and a plug-in name, so that the API can be modified in later versions and be handled gracefully. Although using this architecture makes it quite possible to switch rendering back-ends at run-time, back-end switching was only implemented on application start-up, to reduce development time. Fetching wasn't implemented as a plug-in architecture as it is unlikely that it'd be necessary for a user to switch fetching mechanism. A general `request' structure was created for the fetcher module that consists of a url, a parent (the page that the request originated from), a type (either `page' for html requests, or `data' for all other requests) and a data pointer that the fetching module uses internally to store any other necessary data. To open a page, the UI creates a request object of type `page' with the url of the page. This is passed onto the fetching module, which goes about fetching the page and handling any exceptions. As the page is fetched, the `write' function on the rendering back-end is called with the read data and a reference to the request. This is roughly illustrated in Figure \ref{fig:fetch}. \begin{figure}[!htb] \centering \includegraphics[width=0.45\textwidth]{fetch.pdf} \caption{An illustration of the process of requesting a web-page: The user interface generates a Request object, which the fetcher receives and works on. As data is received, it passes this data to the rendering back-end, which processes it immediately.} \label{fig:fetch} \end{figure} \subsubsection{Implementing the User Interface} The user interface was designed primarily with a hand-held system in mind, so all functions are reachable via a single tap and there are no context menus. The only feature that isn't accessible from outside of a menu is the settings window; a window which should not be necessary to access more than once, if at all. It was chosen for the browser to not only support the standard GTK+ interface, but also to support the hildon interface, used on the maemo platform\cite{maemo}. The maemo platform is used on the Nokia 770 internet tablet\cite{nokia770} and is based on GTK. Its hildon library provides special widgets to enforce a unified interface. Maemo support was implemented by providing a build switch and using the \#define C directive to choose certain different code-paths to customise the interface using hildon widgets. A comparison of the standard GTK+ and maemo interfaces can be seen in figure \ref{fig:gtk-maemo}. Further screenshots of the interface can be seen in \ref{screens}. \begin{figure}[!htb] \centering \includegraphics[width=0.39\textwidth]{web-gtk.png} \includegraphics[width=0.6\textwidth]{web-maemo.png} \caption{On the left: The standard GTK+ browser interface; On the right: The maemo-integrated browser interface} \label{fig:gtk-maemo} \end{figure} \subsubsection{Improving GTKHTML2} \label{gtkhtml2-improve} At the beginning of this project, GTKHTML2 was not adequately featured to fulfil the requirements. It lacked support for critical CSS features, such as the import and media rules, and completely lacked any JavaScript support (see \ref{gtkhtml2-js}. It also didn't fully support all DOM functions. Although a different rendering engine could have been used, it was chosen to work on improving GTKHTML2 to the point where it would be an adequate rendering engine for a mobile browser. The following is a summary of features added to GTKHTML2 (many of which have been accepted contributions, see \ref{gtkhtml2-changelog}) during the course of this project. \begin{itemize} \item @import support Support for the @import rule was added thanks to isteve@bofh.cz. Without support for the @import rule, many sites miss style-sheets. Importantly, sites that support the @media rule commonly do so using the @import rule, so this is a vital feature for a small-screen browser. \item Re-layout fixes Previously, any style-sheet that would cause an element to change its display style would be ignored, as it would cause re-creation of that layout element and all its child nodes due to the display: block type being a different class internally. This issue was fixed by adding code to re-create elements when their display type changes and adding code to replace nodes in the layout-tree. These changes exposed many memory leaks as elements weren't destroying themselves correctly when being re-created. The most obvious of these were fixed as they were exposed, but unfortunately, many remain. \item @media support Full support for the @media rule was added, as well as the ability to select what media type to identify as, and thanks to the re-layout fixes, instant application of said setting. This change finally allowed for the rendering engine to be used on a simple small-screen browser, for pages that explicitly supported hand-held devices. \item Complete DOM function/attributes and event support DOM mutation events were added for the functions that set and remove DOM elements. This allowed the engine to know when a layout node would need to be re-styled or re-layout'd in response to an attribute change. Accessor methods were also added for a DOM element's style attribute. Furthermore, basic DOM functionality was completed with the `insertBefore' function. This allows DOM nodes to be inserted at any point in the DOM tree, instead of just appended. This function was necessary to implement collapsing paragraphs (see \ref{implementing-ssr}). \item Miscellaneous Rendering Improvements Various rendering improvements have been made. Previously, if the background or background-image property of an element was set to `none', this was ignored by GTKHTML2. This had the effect of making it impossible to clear the background using css. The `max-width' property was also not supported for images. It is unspecified exactly how this should be handled by images, but it is common in many browsers to re-size the image to respect max/min-width/height while trying to maintain the aspect ratio of the image. This was implemented in GTKHTML2 as it is necessary for images to be re-sized to always remove horizontal scroll-bars. A simple bug that affected margin inheritance was also fixed. This bug had no affect on the small screen rendering, as margins are cancelled, but it did improve standard rendering on many web-sites. \item User style-sheet support Vitally, the API was altered to allow for a user to add their own style-sheet to a page, and specify what media type it should apply to (including the ability to specify no media type and have it apply globally). This allows for a custom style-sheet to be applied, meaning a more comprehensive hand-held browser can be implemented, as well as meaning the JavaScript HTML DOM interface for adding and removing style-sheets can be implemented. \end{itemize} \subsubsection{Implementing JavaScript HTML DOM} \label{gtkhtml2-js} The JavaScript HTML DOM was implemented using the spidermonkey library and writing bindings for the GTKHTML2 DOM functions using its C API. Complete support is trivial to implement, however priority was given to the functions that were used in the small-screen rendering script (see \ref{implementing-ssr}). In terms of architecture, JavaScript was kept separately from the rest of the rendering back-end, easing the possibility of splitting it into a separate library in the future. All basic DOM navigation functions and attributes were implemented, meaning that DOM nodes can be retrieved in scripts. The JavaScript DOM node objects are created on-demand to save memory. To avoid creating the same JavaScript object twice, a mapping is kept between the DOM node or node attribute, and the JavaScript object via a hash-table. For manipulation, DOM attribute manipulation functions were implemented and the DOM element `style' object was implemented. Of the style attributes, only those used in the small-screen rendering script were implemented. To add elements to the DOM tree, the document object createElement and createTextNode methods were implemented and the DOM element appendChild and insertBefore methods were implemented (the latter of which required changes to GTKHTML2, as documented in \ref{gtkhtml2-improve}). Level 2 DOM events were implemented, however, only mouse events, as these were the only events necessary for the small-screen rendering script. The event listener function works by connecting to the GObject signal and calling the necessary function on the JavaScript object. When an event listener is added, an event structure is filled out and added to a list. This event structure is used to find out what function needs to be called and to maintain a reference to the object that registered the event listener. The list of these structures is freed when the page is cleared or when the back-end or page is destroyed. For event listeners that stem from attributes in the HTML, the DOM tree is iterated over once the page has loaded and the event listener adding function is called manually. \subsection{Implementing a Small-Screen Rendering Script} \label{implementing-ssr} The ``feel-like-a-cellphone'' style-sheet\cite{minimo-css} that Minimo uses was used as a starting point for the development of the script. A clear problem with this style-sheet is that it flattens all tables, regardless of their size. Also, applying this style-sheet to all pages means that pages that already have their own hand-held style-sheets may be rendered incorrectly, or poorly. These were the first two elements that needed to be remedied with the script. To apply the style-sheet using just JavaScript, the `head' element of the document is retrieved and a new `style' element is created. The style-sheet is then appended as a text node to this element and the style element can then be appended to the head element. To apply the style-sheet only when there is no hand-held style-sheet, the script requires support of the document.styleSheets attribute. If the attribute is not supported, it will always apply the style-sheet, which can reduce rendering quality on pages that support hand-held devices. This attribute is supported in Firefox v1.0+, Internet Explorer v5.0+ and Netscape v6.0+, but not Opera (tested in Opera v8.54). To selectively flatten tables, the section of css that affects tables was first removed. In JavaScript, all tables are then traversed. Any tables containing images, form elements or strings greater than 80 characters in length are then flattened. This produces similar results to the style-sheet, but exceptional cases, such as calendars, are handled more desirably, as shown in Figure \ref{fig:ssr-calendar}. \begin{figure} \centering \includegraphics[width=0.35\textwidth]{ssr-table-before.png} \includegraphics[width=0.35\textwidth]{ssr-table-after.png} \caption{On the left: Applying a style-sheet to the whole document; On the right: The same style-sheet, with selective styling on tables. Note that the calendar is displayed correctly.} \label{fig:ssr-calendar} \end{figure} In addition to selective flattening of tables, another concept that was explored was collapsing paragraphs and images. To choose what elements are collapsed, the DOM tree is iterated over and, skipping over anchor, script and comment elements, nodes that are parents to text nodes greater than a particular length are added to an array. Unfortunately, just collapsing all paragraph elements does not work very well, as most web-pages do not use the paragraph element to organise logical paragraphs. A function was then written that can collapse any particular element. It first creates a text element that is the ellipses of the text the element is parent to. Then, it creates a paragraph element and attaches this text element to that. This paragraph is styled to appear as a hyperlink, to make it obvious to the user that it's a target. This paragraph element is inserted into the DOM tree directly before the element it is expected to collapse and expand. An event listener is then registered that responds to the mouse click event on this paragraph and collapses the element directly after it in the DOM tree. To be able to restore its previous state, the old `display' attribute of the style of the collapsed element is stored as an extra attribute, given the name `old-display'. When the event listener is first registered, old-display is set to `none', so the function need only swap these two attributes to expand and collapse the paragraph. This technique can also be applied similarly to images, however, this tends to be less successful due to images being used as frames and padding on many web-pages. Conceptually, collapsing paragraphs would allow for more information to be condensed into a smaller place. In practise, however, it tends to make the page feel cluttered, unless the page is specifically designed with collapsing paragraphs in mind. It is not enabled by default in the browser product, as it conflicts with the design of too many web-sites. The result of collapsing paragraphs on a web-site that is particularly well structured for it can be seen in Figure \ref{fig:ssr-collapsing}. \begin{figure} \centering \includegraphics[width=0.35\textwidth]{ssr-no-collapsing.png} \includegraphics[width=0.35\textwidth]{ssr-collapsing.png} \caption{On the left: http://planet.gnome.org/ with the small-screen rendering script and no collapsing paragraphs or images; On the right: The same script, with collapsing paragraphs and images enabled. More summary information is immediately visible and the user selects what information they would like to expand on.} \label{fig:ssr-collapsing} \end{figure} \newpage \section{Testing} Due to the nature of this project, tests will be heavily illustrated with figures of rendering output, followed by critical analysis. Where necessary, figures will be included to demonstrate any benefits or disadvantages to using the script. All tests were conducted on 10\superscript{th} May 2006 on a desktop PC with the following specifications: \begin{itemize} \item AMD Athlon 64 3200+ \item 1gb PC3200 dual-channel RAM \item Ubuntu Linux `dapper drake' (updated 9\superscript{th} May 2006) \item Ubuntu Linux kernel 2.6.15-22-amd64-k8 \item GNOME desktop 2.14.1 \item Firefox 1.5.0.2 \item Opera 9.00 beta \end{itemize} \subsection{Appearance} \label{appearance} Rendering appearance was tested on three pages, under four different conditions: \begin{itemize} \item Condition 1: Standard Firefox with no scripts or user style-sheets. \item Condition 2: Firefox with the developed small-screen rendering script. \item Condition 3: Opera in small-screen rendering mode. \item Condition 4: The developed browser with the small-screen rendering script. \end{itemize} These conditions are tailored to illustrate the difference between having and not having small-screen rendering on a small screen, and to compare the developed solution to the most common commercial solution. Figures are displayed in order of these conditions. \subsubsection{http://uk.gamespot.com/} \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test1-1-1.png} \includegraphics[width=0.24\textwidth]{test1-1-2.png} \includegraphics[width=0.24\textwidth]{test1-1-3.png} \includegraphics[width=0.24\textwidth]{test1-1-4.png} \caption{http://uk.gamespot.com, rendered under various different conditions.} \label{fig:test1-1} \end{figure} The effect of the style-sheet is exaggerated on media-rich sites such as is shown in Figure \ref{fig:test1-1}. Immediately the effect can be seen as the graphical banner is reduced in size to fit the width of the page, the large banner is removed and the log-in form that was previously located further down the page is anchored to the top of the page. The results of Opera and the small-screen rendering script are very similar in this situation, however, Opera appears to have some trouble with padding and margins. The feel-like-a-cellphone style-sheet cancels all margins and padding; Opera appears not to do this, at the expense of performing considerably worse in common situations such as this. A further noticeable trait of Opera is that its small-screen rendering appears to be fixed-width and does not respond to the page-width changing. In theory, condition 2 and condition 4 would render almost identically, however, this is clearly not the case. Most obviously, it appears that the text-alignment property has been ignored, meaning many page elements are centred instead of left-aligned. The navigation table also appears to be using the default page style, which would make one assume that a class style is being ignored, or some similar issue. There is also an unnecessary horizontal scroll-bar; there are no visible elements that require it. \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test1-2-1.png} \includegraphics[width=0.24\textwidth]{test1-2-2.png} \includegraphics[width=0.24\textwidth]{test1-2-3.png} \includegraphics[width=0.24\textwidth]{test1-2-4.png} \caption{http://uk.gamespot.com, rendered under various different conditions.} \label{fig:test1-2} \end{figure} The section of the page shown in Figure \ref{fig:test1-2} shows much the same results across all three small-screen rendering conditions, excluding the rendering errors already detailed in the last paragraph. As the table in this section of the document contains images, it has been flattened (the table elements have had their style display elements set to `block'). \subsubsection{http://chrislord.net/} \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test2-1-1.png} \includegraphics[width=0.24\textwidth]{test2-1-2.png} \includegraphics[width=0.24\textwidth]{test2-1-3.png} \includegraphics[width=0.24\textwidth]{test2-1-4.png} \caption{http://chrislord.net/, rendered under various different conditions.} \label{fig:test2-1} \end{figure} This page, as shown in Figures \ref{fig:test2-1} and \ref{fig:test2-2}, translates very well using the small-screen rendering script, as shown previously in Figure \ref{fig:ssr-calendar}. Floating elements that were originally on the side of the page have been anchored before the main content of the page, and in conditions 2 and 4, have been stretched to fit the width of the page. Note also that the calendar table has been displayed correctly, due to the selective styling, discussed in \ref{implementing-ssr}. Generally, pages that were designed to be completely formatted with a style-sheet respond very well to re-styling, as only the page content is contained in the HTML of the document. As this particular page is formatted completely with a style-sheet, it performs particularly well. \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test2-2-1.png} \includegraphics[width=0.24\textwidth]{test2-2-2.png} \includegraphics[width=0.24\textwidth]{test2-2-3.png} \includegraphics[width=0.24\textwidth]{test2-2-4.png} \caption{http://chrislord.net/, rendered under various different conditions.} \label{fig:test2-2} \end{figure} The comparison between Opera and the script is particularly interesting in this example. Previously, the feel-like-a-cellphone style-sheet was decidedly worse than Opera's performance, as it flattened the calendar table (see Figure \ref{fig:ssr-calendar}). With this simple alteration, however, the appearance is improved dramatically and it is Opera that appears to have problems. Because Opera doesn't cancel margins or padding, the floating elements that are anchored at the top of the page have `odd' looking sizes. This does, however, mean the page is marginally more readable once the main content is reached. \subsubsection{http://www.ecs.soton.ac.uk/news/} \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test3-1-1.png} \includegraphics[width=0.24\textwidth]{test3-1-2.png} \includegraphics[width=0.24\textwidth]{test3-1-3.png} \caption{http://www.ecs.soton.ac.uk/news/, rendered under various different conditions.} \label{fig:test3-1} \end{figure} Figure \ref{fig:test3-1} shows a very positive result for this web-site also. Although this appears to be a more complex site than in Figure \ref{fig:test2-1}, it is a good example of a site that makes proper use of style-sheets. Unfortunately, this site would not render correctly at all in the GTKHTML2 browser for unknown reasons, so it is excluded from this test. Figure \ref{fig:test3-2} shows how the main content of the page appears. In this case, the layout is mostly unchanged from the original version, other than that it fits within the width of the page. Similarly to the example in Figure \ref{fig:test1-1}, Opera's choice of not modifying padding and margins vertically elongates the navigation links section. Although this is an undesirable feature, its choice to make font-size a constant allows for more visible content and less distracting headings. \begin{figure}[!htb] \centering \includegraphics[width=0.24\textwidth]{test3-2-1.png} \includegraphics[width=0.24\textwidth]{test3-2-2.png} \includegraphics[width=0.24\textwidth]{test3-2-3.png} \caption{http://www.ecs.soton.ac.uk/news/, rendered under various different conditions.} \label{fig:test3-2} \end{figure} \subsection{Memory usage} Measuring memory usage under Linux is a complex matter, due to shared libraries. If more than one application uses a shared library, Linux will only load one copy of this library and share it between these applications. Memory usage output from standard Linux tools such as `ps' or `top' do not take this into account, and so the value given is actually only accurate if that were the only application using any of the shared libraries it uses. This needs to be taken into account when comparing memory usage values of different applications. To make comparisons fairer, all browsers were re-started for each test, with the home-page set to the testing page, to make sure there would be no system memory cache. This also helps to somewhat counteract the memory leakage issues in GTKHTML2. Also note that GTKHTML2 memory usage values (as seen in Condition 4) will be slightly inflated due to debugging symbols. The same conditions as applied in \ref{appearance} apply here. Firefox was tested with and without the script to see what kind of impact on memory usage the script would have on the average browser. \begin{figure}[!htb] \centering \begin{tabular}{|l|cccc|} \hline Page & C1 & C2 & C3 & C4 \\ \hline http://www.google.co.uk/ & 43312 & 44192 & 20040 & 21516 \\ http://chrislord.net/ & 47100 & 47964 & 19152 & 28532 \\ http://www.ecs.soton.ac.uk/news/ & 44712 & 46992 & 21924 & -- \\ http://dictionary.reference.com/ & 45576 & 47528 & 21396 & 22916 \\ http://planet.gnome.org/ & 53876 & 51944 & 36284 & 53648 \\ \hline Average & 46915 & 47724 & 23759 & 31653 \\ \hline \end{tabular} \caption{Memory usage of different browsers under various conditions, measured in kilobytes} \label{fig:memory} \end{figure} The results featured in Figure \ref{fig:memory} clearly show a large memory usage difference between the Firefox browser and the Opera and project browsers, in favour of the latter two. Unfortunately, the previously mentioned memory leak issues in GTKHTML2 skew the results on large pages featuring many images, as can clearly be seen in the case of http://planet.gnome.org/. If these issues were remedied, it could be conjectured that the memory usage would be more in-line with Opera. In terms of the added memory usage of the small-screen rendering script, the average additional memory required in Firefox was 809kb, making it a feasible proposition, if it were applied to a more memory-efficient browser. Although Opera has the lowest memory usage, the required storage space is much greater than for the project browser, and is comparable to Firefox. \newpage \section{Evaluation and Conclusions} In terms of the set goals, this project was only partially successful. The developed user interface proved flexible and the GTK+-based platform made it possible to test this interface on portable devices, as well as develop a special interface for the Maemo platform, as seen in \ref{screens}. The interface allows for full page navigation and bookmark features within a single click/tap and tabbed browsing, without cluttering. Work priority was placed on the rendering engine and improving its functionality. The work is by no means finished, but is the beginning of a new, viable, open-source rendering engine. The architecture of GTKHTML2 is flexible enough to allow it to easily support many modern features and many of its problems could be solved with some comprehensive, but basic, testing and memory auditing. Many new features were added to GTKHTML2, as are detailed in \ref{gtkhtml2-improve}, but with these new features come added instability as previously unexplored code-paths are used and existing functions are used in new and more vigorous ways. The small-screen rendering featured in this project mostly existed before, in the form of the feel-like-a-cellphone style-sheet, however, without the selective styling (see \ref{implementing-ssr}), many sites displayed undesirable rendering `glitches' (see Figure \ref{fig:ssr-calendar}). This small change improved the accessibility of many sites by reducing scrolling, however, the concept of selective styling provides the ability to do more than just this (for example, it could be used to do the same task as seen in \ref{research-dom}). An interesting trait of the small-screen rendering script with GTKHTML2, is that pages that previously showed rendering inaccuracies become readable, as the script stops certain elements from ever appearing on a page. It could be concluded that a rendering engine targeted specifically at small screens need not implement certain commonly used features, which would save on memory and code complexity. Originally, I had envisaged this project to more greatly be about small-screen rendering, but as the project progressed, it became clear that the issue isn't as complex as was first thought. It seems to be a greater issue to produce a standards-compliant browser with a low memory profile; an issue that judging from the existing packages in \ref{existing}, only Opera seems to have attempted to tackle with any real success. At this point, the project became more focused on attempting to provide an open-source alternative to Opera, with similarly low memory requirements. To limit any possible wastage, and to make sure that at least part of this work would be valuable, it was enforced as a goal that the small-screen rendering be achieved in a browser-agnostic fashion. For a lower memory profile than that which was set in \ref{requirements}, I believe a rendering engine specific solution would be called for. This project has resulted in a browser that is usable on small devices that use GTK+-based or Maemo-based platforms, such as the Nokia 770\cite{nokia770}. Due to instability and memory leakage issues, this browser cannot yet replace existing solutions, however, it provides a base for future work, either as continued work on GTKHTML2 and the browser featured in this project, or as work on the scripts provided, for use in another browser. I have learnt much from the work on this project, and plan to continue working on GTKHTML2 to make it a viable rendering engine in the future. \subsection{Further Work} This project has met limited success. Although the project goals were mostly fulfilled, perhaps this was too large a project to attempt in the time allotted. Many improvements could be made to the base which this project provides. \subsubsection{Further Improvement of GTKHTML2} \label{further-gtkhtml2} GTKHTML2 suffers greatly from memory leakage issues. An important priority for the further development of GTKHTML2 is for a memory leakage audit to be undertaken. Iain Holmes has written a short guide on fixing memory leaks with the `valgrind' tool\cite{iain}. If work on GTKHTML2 is continued without this audit, it will increase the difficulty of doing this in the future. The second priority for work on GTKHTML2 is to make the API more tidy. Currently, there is very little data in each module/object that isn't exposed publicly, making maintaining the ABI (Application Binary Interface) while simultaneously introducing new features a near-impossibility. General support of CSS and HTML features in GTKHTML2 is complete enough to render the vast majority of pages, but due to bugs and inaccuracies, most pages do not display correctly. GTKHTML2 could be improved by fixing many of its smaller inaccuracies. This improvement would aggregate into a much larger improvement, where many pages would display correctly, much like the fixed margin inheritance bug (see \ref{gtkhtml2-improve}). \subsubsection{Implementing a GTKHTML2-JavaScript Library} The JavaScript HTML DOM interface implemented in this project was implemented as part of the rendering back-end. This work could be separated into a shared library that depends only on libspidermonkey (the JavaScript interpreter) and GTKHTML2. This would allow for it to easily be used in other projects that don't want to implement the rendering back-end interface of this project, but do want a light GTK+-based rendering engine with JavaScript support. \subsubsection{Integration of Web Services} A missing feature of the project that was planned was integration of the del.icio.us social bookmarks service\cite{delicious}, as mentioned in \ref{design}. This is one example of a web service that would work well integrated into a web-browsing client, but others could also be considered, such as digg\cite{digg} and Shoutwire\cite{shoutwire}, two mechanisms for socially rating, sharing and categorising news web-sites. \subsubsection{Extensibility} It would be fairly trivial to implement support for greasemonkey\cite{greasemonkey} user scripts in the project browser. A simple parser would need to be written for the script headers and a UI introduced to control script installation. Further extensibility could be introduced by exporting a library that would allow user interface elements to be altered, similarly to the Firefox browser. This would allow features that may not be suited to all platforms to be included optionally through extensions. \newpage \begin{thebibliography}{99} \bibitem{ipaq} Hewlett-Packard Development Company, L.P., ``{\it HP Handheld Devices - iPAQ}'', http://www.hp.com/country/us/en/prodserv/handheld.html, last accessed 11\superscript{th} May 2006 \bibitem{palm} Palm Inc., ``{Welcome to Palm, Inc., formerly palmOne}'', http://www.palm.com/, last accessed 11\superscript{th} May 2006 \bibitem{zaurus} Sharp Electronics Corporation, ``{Home}'', http://www.myzaurus.com/, last accessed 11\superscript{th} May 2006 \bibitem{dom-extract} Suhit Gupta, Gail Kaiser, David Neistadt and Peter Grimm, ``{\it DOM-based Content Extraction of HTML Documents}'', Dept. of Comp. Sci, Columbia University, International World Wide Web Conference, 207-214 (2003). \bibitem{gateway} Bonnie McKay, ``{\it The Gateway: A Navigation Technique for Migrating Small Screens}'', Dalhousie University, Doctoral Consortium, CHI 2003, 684-685 (2003). \bibitem{alt-scroll} Staffan Björk and Johan Redström, ``{\it An Alternative to Scrollbars on Small Screens}'', PLAY: Applied Research on Art and Technology, Viktoria Institute. CHI '99 Extended Abstracts, 316-317 (1999). \bibitem{web-interaction} M Jones, G Marsden, N Mohd-Nasir, K Boone, G Buchanan, ``{\it Improving Web Interaction on Small Displays}'', School of Computing Science, Middlesex University UK, WWW8 / Computer Networks (1999). \bibitem{improving-usability} G Buchanan, S Farrant, M Jonrd, H Thimbleby, G Marsden, M Pazzani, ``{\it Improving Mobile Internet Usability}'', Middlesex University, University of Cape Town, AdaptiveInfo, Proceedings of the tenth internation conference on World Wide Web, 673-680 (2001). \bibitem{design-small} Lari Kärkkäinen and Jari Laarni, ``{\it Designing for Small Display Screens}'', Center for Knowledge and Innovation Research, Helsinki School of Economics and Business Administration, Proceedings of the second Nordic conference on Human-computer interaction, 227-230 (2002). \bibitem{minimo} Mozilla Foundation, ``{\it Minimo}'', http://www.mozilla.org/projects/minimo/, last accessed 1\superscript{st} May 2006 \bibitem{minimo-css} Mozilla Foundation, ``{\it Minimo small screen rendering stylesheet}'', https://bugzilla.mozilla.org/attachment.cgi?id=140182, last accessed 19\superscript{th} November 2005 \bibitem{opera} Opera Software, ``{\it Opera for Devices}'', http://www.opera.com/products/devices/, last accessed 1\superscript{st} May 2006 \bibitem{opera-ssr} Opera Software, ``{\it Opera's Small-Screen Rendering™}'', http://www.opera.com/products/mobile/smallscreen/, last accessed 1\superscript{st} May 2006 \bibitem{css-media} World Wide Web Consortium, ``{\it Media types}'', http://www.w3.org/TR/REC-CSS2/media.html, last accessed 1\superscript{st} May 2006 \bibitem{webcore} Apple, ``{\it Open Source - Internet \& Web - WebKit}'', http://developer.apple.com/opensource/internet/webkit.html, last accessed 1\superscript{st} May 2006 \bibitem{khtml} The K Desktop Environment, ``{\it Konqueror Homepage}'', http://www.konqueror.org/features/browser.php, last accessed 1\superscript{st} May 2006 \bibitem{konq-e} The K Desktop Environment, ``{\it Konqueror Homepage - Konqueror Embedded}'', http://www.konqueror.org/embedded/, last accessed 1\superscript{st} May 2006 \bibitem{gtk-webcore} Kimmo Kinnunen, ``{\it Gtk+ WebCore}'', http://gtk-webcore.sourceforge.net/, last accessed 1\superscript{st} May 2006 \bibitem{nokia-webcore} Eugenia Loli-Queru, ``{\it An Overview of Nokia's KHTML/WebCore-based S60 Browser}'', http://www.osnews.com/story.php?news\_id=12965, last accessed 1\superscript{st} May 2006 \bibitem{dillo} ``{\it Dillo Web Browser}'', http://www.dillo.org/, last accessed 1\superscript{st} May 2006 \bibitem{familiar} handhelds.org, ``{\it the Familiar Project}'', http://familiar.handhelds.org/, last accessed 1\superscript{st} May 2006 \bibitem{netsurf} ``{\it NetSurf | Open Source Web Browser for RISC OS}'', http://netsurf.sourceforge.net/, last accessed 1\superscript{st} May 2006 \bibitem{opie} ``{\it Opie - Open Palmtop Integrated Environment}'', http://opie.handhelds.org/cgi-bin/moin.cgi/, last accessed 2\superscript{nd} May 2006 \bibitem{openzaurus} ``{\it OpenZaurus}'', http://www.openzaurus.org/wordpress/, last accessed 10\superscript{th} May 2006 \bibitem{palm-linux} palmsource, ``{\it ACCESS and PalmSource Announce the ACCESS Linux Platform}'', http://www.palmsource.com/press/2006/021406\_accesslinuxplatform.html, last accessed 2\superscript{nd} May 2006 \bibitem{delicious} Yahoo!, ``{\it del.icio.us}'', http://del.icio.us/, last accessed 2\superscript{nd} May 2006 \bibitem{css-important} World Wide Web Consortium, ``{\it Assigning property values, Cascading, and Inheritance}'', http://www.w3.org/TR/REC-CSS2/cascade.html\#important-rules, last accessed 2\superscript{nd} May 2006 \bibitem{firefox} Mozilla Foundation, ``{\it Firefox - Rediscover the Web}'', http://www.mozilla.com/firefox/, last accessed 4\superscript{th} May 2006 \bibitem{greasemonkey} Mozdev.org, ``{\it mozdev.org - greasemonkey}'', http://greasemonkey.mozdev.org/, last accessed 4\superscript{th} May 2006 \bibitem{glibcurl} Richard Atterer, ``{\it glibcurl - libcurl integration for the glib/GTK+ event loop}'', http://atterer.net/glibcurl/, last accessed 6\superscript{th} May 2006 %\bibitem{dom-events} %World Wide Web Consortium, ``{\it Document Object Model Events}'', http://www.w3.org/TR/DOM-Level-2-Events/events.html, last accessed 8\superscript{th} May 2006 \bibitem{maemo} Nokia, ``{\it Welcome to maemo.org!}'', http://maemo.org/, last accessed 8\superscript{th} May 2006 \bibitem{nokia770} Nokia, ``{\it Nokia - Nokia 770}'', http://www.nokia.com/770, last accessed 8\superscript{th} May 2006 \bibitem{iain} Iain Holmes, ``{\it Checking for Memory Leaks with Valgrind}'', http://www.o-hand.com/~iain/valgrind-gtkhtml.html, last accessed 10\superscript{th} May 2006 \bibitem{digg} digg, ``{\it digg}'', http://www.digg.com/, last accessed 10\superscript{th} May 2006 \bibitem{shoutwire} SHOUTWIRE, ``{\it Shoutwire.com » Internet News for the Masses}'', http://www.shoutwire.com/, last accessed 10\superscript{th} May 2006 \end{thebibliography} \newpage \section{Appendix} \subsection{CD Contents} The table in Figure \ref{fig:cd} shows the directory hierarchy of the CD. \begin{figure}[!htb] \centering \begin{tabular}{|l|c|} \hline Directory & Contents description \\ \hline Documents & Contains the PDF of this write-up \\ Code & Contains the meta-data required to build the browser \\ Code/data & Contains shared data files for the browser \\ Code/src & Contains the source of the browser \\ Code/src/gtkhtml2 & Contains the source of the GTKHTML2 rendering back-end \\ Code/patches & Contains patches against GTKHTML2 \\ Code/gtkhtml2 & Contains a patched CVS check-out of GTKHTML2 \\ Code/writeup & Contains the LaTeX files and images for the write-up \\ \hline \end{tabular} \caption{Annotated CD directory hierarchy} \label{fig:cd} \end{figure} \subsection{User Manual} \subsubsection{Introduction} This user manual contains the information necessary to configure, build and operate this project. Users are advised that basic familiarity with the Linux terminal and GNU Autotools are required, information about which can be obtained at http://sourceware.org/autobook/. \subsubsection{Installation} This installation process assumes that it is acceptable to install files into the prefix /usr/local, as it is in most Linux distributions. If this is not the case, please replace all instances of `/usr/local' with the desired install prefix. \subsubsection*{Dependencies} The following dependencies must be present before attempting to build this project: \begin{itemize} \item gtk+ ($\rangle$= 2.6.0) \item libglade ($\rangle$= 2.5.0) \item gconf ($\rangle$= 2.6.0) \item libcurl ($\rangle$= 7.14.0) \item gtkhtml2 source (CVS HEAD check-out 20060510) \item GNU patch \end{itemize} \subsubsection*{Optional Dependencies} The following dependencies are optional for added features: \begin{itemize} \item libgail ($\rangle$= 1.8.0) - GTKHTML2 can use this for accessibility support. \item maemo (1.1) - There is an integrated maemo interface for the browser. \item quilt - Quilt is a patch management system that can ease \end{itemize} \subsubsection*{Patching and Building GTKHTML2} GTKHTML2 source-code can be obtained from GNOME CVS, by typing the following commands into a console (excluding \$ signs): {\tt \$ setenv CVS\_RSH ssh\\ \$ setenv CVSROOT :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome\\ \$ cvs login\\ \$ cvs -z3 co gtkhtml2\\ } The source must then be patched. The patching process is made easier if quilt is installed. The first task is to create a symbolic link to the patches directory in the GTKHTML2 source directory. Assuming the source directory of the browser is inside the directory above the gtkhtml2 directory, change to the gtkhtml2 directory and type the following command in the console to create a symbolic link: {\tt \$ ln -s ../Code/patches ./ } The next steps vary depending on whether quilt is installed. If quilt is installed, type the following command: {\tt \$ quilt push -a } If quilt is not installed, type the following command: {\tt \$ for file in at-import\_box-pos.patch css-stylesheet-user.patch $\backslash$ \\ css-media.patch add-end-element-signal.patch $\backslash$ \\ add-dom-functions.patch iain-mem-leak.patch; $\backslash$ \\ do patch -p0<../Code/patches/\$file; done } GTKHTML2 is now ready to be configured and built. To configure GTKHTML2, type the following commands (if libgail is not installed, `--disable-accessibility' should be suffixed to the first command): {\tt \$ ./autogen.sh --prefix=/usr/local\\ \$ make } Installation of GTKHTML2 may require root privileges. Attaining root privileges differs between Linux distributions. If you are unsure how to attain root privileges to execute this command, please check your distribution's manual. To install GTKHTML2, attain root privileges if necessary and type the following command: {\tt \$ make install } \subsubsection*{Building the Browser} To configure and build the browser, change to the Code directory and type the following commands (if the maemo libraries are installed, --enable-hildon should be suffixed to the first command): {\tt \$ setenv PKG\_CONFIG\_PATH /usr/local/lib/pkgconfig:\$PKG\_CONFIG\_PATH\\ \$ ./autogen.sh --prefix=/usr/local\\ \$ make } To install the browser, gain root privileges and type the following command: {\tt \$ make install } \subsubsection{User Interface} \begin{figure}[!htb] \centering \includegraphics[width=0.6\textwidth]{maemo01m.png} \caption{The main interface} \label{fig:main} \end{figure} Figure \ref{fig:main} shows the main browser interface. The browser controls are split into three sections: \subsubsection*{Section 1} Section 1 is the menu-bar, accessible on the pictured maemo interface by tapping the title-bar of the window. The menu-bar is always visible when using the GTK+ interface. The menu-bar provides access to all features of the browser and are named similarly to their counterparts in the following sections. The menu-bar also allows you to travel instantly to a particular page in the browser history (see Figure \ref{fig:menu}) and enter the browser configuration, options only available from this section of the user interface. \begin{figure}[!htb] \centering \includegraphics[width=0.6\textwidth]{maemo07m.png} \caption{The expanded menu-bar} \label{fig:menu} \end{figure} \subsubsection*{Section 2} Section 2 is the page tabs area, and provides an overview of the currently open pages. You can switch between pages by tapping their titles in this area, or open a new page by tapping the 'New Page' tab. Pages can be closed by tapping the 'X' that appears in all page tabs. When the last page is closed, the browser will exit. \subsubsection*{Section 3} Section 3 is the main tool-bar and houses all commonly-used functions. To navigate to a particular URL or bookmark, tap the 'Go' button. This will present the interface shown in Figure \ref{fig:bookmarks}, which allows a URL to be entered, or a bookmark to be chosen. To navigate to a bookmark, select the bookmark from the list and tap the arrow icon to the right of the address entry. While a page is loading, the interface in Figure \ref{fig:loading} is presented. To stop the loading process, click the 'X' icon adjacent to the loading progress-bar. \begin{figure}[!htb] \centering \includegraphics[width=0.6\textwidth]{maemo03.png} \caption{Browsing bookmarks and entering a URL} \label{fig:bookmarks} \end{figure} \begin{figure}[!htb] \centering \includegraphics[width=0.6\textwidth]{maemo05.png} \caption{Loading a URL} \label{fig:loading} \end{figure} \subsubsection{Configuration} \begin{figure}[!htb] \centering \includegraphics[width=0.45\textwidth]{maemo08.png} \includegraphics[width=0.45\textwidth]{maemo09.png} \caption{Configuring the browser} \label{fig:preferences} \end{figure} The configuration screen is reached through the menu-bar, by choosing `Edit', then `Preferences'. The configuration dialogue has two sections, pictured in Figure \ref{fig:preferences}. The configuration screen allows the user to set the home-page of the browser (the page that is shown whenever a new page is opened), and to set the type of device that the browser is targeted to. \subsection{Screenshots} \label{screens} \subsubsection{GTK+ Interface} \label{screens-gtk} \includegraphics[width=0.33\textwidth]{gtk01.png} \includegraphics[width=0.33\textwidth]{gtk02.png} \includegraphics[width=0.33\textwidth]{gtk03.png} \includegraphics[width=0.33\textwidth]{gtk04.png} \includegraphics[width=0.33\textwidth]{gtk05.png} \includegraphics[width=0.33\textwidth]{gtk06.png} \newpage \subsubsection{Maemo Interface} \label{screens-maemo} \includegraphics[width=0.49\textwidth]{maemo01.png} \includegraphics[width=0.49\textwidth]{maemo02.png}\\ \includegraphics[width=0.49\textwidth]{maemo03.png} \includegraphics[width=0.49\textwidth]{maemo04.png}\\ \includegraphics[width=0.49\textwidth]{maemo05.png} \includegraphics[width=0.49\textwidth]{maemo06.png}\\ \includegraphics[width=0.49\textwidth]{maemo07.png} \includegraphics[width=0.49\textwidth]{maemo08.png}\\ \includegraphics[width=0.49\textwidth]{maemo09.png} \newpage \subsection{Project Change-Log Entries} \label{web-changelog} {\scriptsize{ \begin{verbatim} 2006-05-10 Chris Lord,,, * data/ssr.user.js: Minor changes * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_Style_setProperty): Fix possible memory corruption 2006-05-09 Chris Lord,,, * data/web-browser.png: Replace gPerfection icon with Tango icon * data/Makefile.am: Install ssr.user.js * data/ssr.user.js: Selectively flatten tables, for nicer looking pages * data/web.glade: - Put the preferences dialogue in a scrolled window - Remove SSR option, automatically applied in hand-held mode * src/web_main.c: (web_apply_ssr), (web_preferences_cb): - Apply ssr.user.js only, instead of style-sheet + collapsing.user.js - Remove SSR option, toggle on in hand-held mode 2006-05-08 Chris Lord,,, * data/web.glade: Use a toolbar instead of an hbox with buttons and restore zoom buttons * src/web.h: Store the HildonAppView in the WebPages structure * src/web_main.c: (web_reset_url_entry), (web_zoomout_cb), (web_preferences_cb), (web_key_press_cb), (main): Respond to hildon zoom keys and full-screen key and use the hildon toolbar for better integration. 2006-04-26 Chris Lord,,, * src/web.h: More changes that shouldn't really be here * src/web_main.c: (main): Add call to osso_initialize when building with hildon support 2006-04-25 Chris Lord,,, * data/collapsing.user.js: Collapse images, fix duplicate summaries * src/web.h: * src/web_main.c: (main): Some changes for hildon that really shouldn't be in these files (will change in the future) 2006-04-13 Chris Lord,,, * configure.ac: * data/web.glade: * src/web.h: * src/web_main.c: (web_apply_ssr), (web_go_button_cb), (web_preferences_cb), (main): - Add hildon support 2006-04-12 Chris Lord,,, * data/collapsing.user.js: - Use hasAttribute and getAttribute instead of checking each attribute * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_HTMLElement_insertBefore): - Implement hasAttribute and getAttribute methods 2006-04-12 Chris Lord,,, * patches/add-dom-functions.patch: - Fix html_event_find_box_traverser (make it not traverse boxes with display: none;) 2006-04-01 Chris Lord,,, * patches/add-dom-functions.patch: - Add new function html_style_dup * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_Style_setProperty): - Use html_style_dup before altering style 2006-04-01 Chris Lord,,, * data/Makefile.am: - Install collapsing.user.js * data/collapsing.user.js: - Change a few things to work with Web (still works with Firefox) * patches/add-dom-functions.patch: - insertBefore now actually works * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_init), (web_gtkhtml2_dom_foreach), (web_gtkhtml2_clear), (web_gtkhtml2_close), (web_gtkhtml2_add_style), (web_gtkhtml2_remove_style), (web_gtkhtml2_add_script), (web_gtkhtml2_remove_script), (web_gtkhtml2_set_media): * src/gtkhtml2/web_gtkhtml2.h: - Add support for custom JavaScript (like Greasemonkey) * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_get_object), (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLElement_addEventListener), (web_gtkhtml2_js_HTMLElement_appendChild), (web_gtkhtml2_js_HTMLElement_insertBefore), (web_gtkhtml2_js_HTMLElement_setAttribute), (web_gtkhtml2_js_Attr_getProperty), (web_gtkhtml2_js_HTMLDocument_createElement), (web_gtkhtml2_js_HTMLDocument_createTextNode), (web_gtkhtml2_js_get_elements_by_tag_name_cb), (web_gtkhtml2_js_HTMLDocument_getElementsByTagName), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_find_by_tagName), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_js_Style_getProperty), (web_gtkhtml2_js_Style_setProperty), (web_gtkhtml2_js_event_free), (web_gtkhtml2_js_parse), (web_gtkhtml2_js_dom2_event_cb), (web_gtkhtml2_js_run_from_attr), (web_gtkhtml2_js_dom_event_cb), (web_gtkhtml2_js_init), (web_gtkhtml2_js_add_events), (web_gtkhtml2_js_remove_events), (web_gtkhtml2_js_init_events), (web_gtkhtml2_js_clear), (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_js_src_write_cb), (web_gtkhtml2_js_run): * src/gtkhtml2/web_gtkhtml2_js.h: - Add document.body - Add Style property setter for display - Store type with object data in JS objects hash-table for more flexible retrieval * src/web.h: - Add function prototypes for new custom JavaScript feature * src/web_main.c: (web_gconf_ssr_cb): - Add collapsing.user.js in SSR mode (very broken) 2006-03-31 Chris Lord,,, * data/web.schemas: - Make handheld + ssr the default 2006-03-31 Chris Lord,,, * data/web.glade: - Complete UI re-design * src/web.h: * src/web_bookmarks.c: (web_bookmarks_create_tree), (web_bookmarks_cursor_changed_cb), (web_bookmarks_init): * src/web_history.c: (web_history_clear), (web_history_append), (web_history_build): - Add callback to go to bookmarks * src/web_main.c: (paste_cb), (web_stop_cb), (web_go_load_idle), (web_go), (web_go_cb), (web_zoomout_cb), (web_back_cb), (web_forward_cb), (web_data_free), (web_new_tab_cb), (web_switch_page_cb), (web_preferences_cb), (main): - Hook up new UI 2006-03-30 Chris Lord,,, * patches/add-dom-functions.patch: - Add dom_Node_insertBefore (untested) * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_init), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write): * src/gtkhtml2/web_gtkhtml2.h: - Initialise JS after first write (guarantees document node existing) - Add a function for executing general functions on each element in the DOM tree * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_find_object), (web_gtkhtml2_js_get_object), (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLElement_addEventListener), (web_gtkhtml2_js_HTMLElement_setAttribute), (web_gtkhtml2_js_Attr_getProperty), (web_gtkhtml2_js_HTMLDocument_getElementsByTagName), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_js_Style_getProperty), (web_gtkhtml2_js_Style_setProperty), (web_gtkhtml2_js_event_free), (web_gtkhtml2_parse_javascript), (web_gtkhtml2_js_dom2_event_cb), (web_gtkhtml2_js_run_from_attr), (web_gtkhtml2_js_dom_event_cb), (web_gtkhtml2_js_init), (web_gtkhtml2_js_add_events), (web_gtkhtml2_js_remove_events), (web_gtkhtml2_js_init_events), (web_gtkhtml2_js_clear), (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_js_src_write_cb), (web_gtkhtml2_js_run): - Add Style object - Add style property to Element object - Add function getElementsByTagName to Document object - Declare Attribute object 2006-03-30 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.h: * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_js_event_free), (web_gtkhtml2_parse_javascript), (web_gtkhtml2_js_register_events), (web_gtkhtml2_js_register_events_recurse), (web_gtkhtml2_js_init_events), (web_gtkhtml2_js_clear): - Add support for DOM2 events via addEventListener 2006-03-29 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_node_finished_cb), (web_gtkhtml2_new), (web_gtkhtml2_write), (web_gtkhtml2_close): * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_js_init), (web_gtkhtml2_js_register_events), (web_gtkhtml2_js_register_events_recurse), (web_gtkhtml2_js_init_events), (web_gtkhtml2_js_clear), (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_js_src_write_cb): * src/gtkhtml2/web_gtkhtml2_js.h: - Add basic DOM event support to JavaScript 2006-03-29 Chris Lord,,, * data/collapsing.user.js: - Add small comment about Firefox oddities * patches/add-dom-functions.patch: - New gtkhtml2 patch: - Adds style-changing functions to DomNode - Adds DOM event DOMAttrModified * patches/css-media.patch: - Refresh * patches/css-stylesheet-user.patch: - Remove return from void function * patches/series: - Refresh * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLElement_setAttribute): - Add DOM node type constants to HTMLElement - Use DomElement functions for altering attributes (removed hack) 2006-03-24 Chris Lord,,, * configure.ac: - Add libxml-2.0 to the required libraries (used for bookmarks) 2006-03-04 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_close): * src/gtkhtml2/web_gtkhtml2.h: * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_get_object), (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_init_js): - Add JS functions to get node name/type/value - Add JS function to set node attributes - this is done very hackily and should really require a gtkhtml2 patch to dom-node.[ch] 2006-03-04 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_new): * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_get_object), (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_init_js), (web_gtkhtml2_parse_javascript), (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_js_src_write_cb), (web_gtkhtml2_do_javascript): Finish full JavaScript DOM traversal 2006-03-03 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_init): * src/gtkhtml2/web_gtkhtml2.h: * src/gtkhtml2/web_gtkhtml2_js.c: (web_gtkhtml2_js_create_object), (web_gtkhtml2_js_HTMLElement_getProperty), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_init_js): Add basic DOM traversal in JavaScript 2006-03-02 Chris Lord,,, * src/gtkhtml2/Makefile.am: * src/gtkhtml2/web_gtkhtml2.c: * src/gtkhtml2/web_gtkhtml2.h: * src/gtkhtml2/web_gtkhtml2_js.c: * src/gtkhtml2/web_gtkhtml2_js.h: Split JavaScript into separate files 2006-03-02 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_print_dom), (web_gtkhtml2_js_HTMLDocument_writeln), (web_gtkhtml2_new), (web_gtkhtml2_write), (web_gtkhtml2_close): Fix support for external JS sources - Stall until loaded, but buffer the rest of the page while stalling. JS fetch can be cancelled by hitting stop/time-out and rest of page will load (still buggy) * src/web_bookmarks.c: (web_bookmarks_init): Don't free envvars * src/web_request.c: * src/web_request.h: Add web_request_copy function 2006-02-28 Chris Lord,,, * data/web.glade: Make expander resizable * src/web_bookmarks.c: (web_gtkhtml2_print_dom): * src/web_main.c: (web_preferences_cb), (main): Add support for viewing Epiphany bookmarks 2006-02-12 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_submit_idle), (web_gtkhtml2_link_clicked_cb): * src/web.h: * src/web_history.c: (web_history_go): * src/web_main.c: (web_go_load_idle), (web_go), (web_go_cb), (web_new_tab_cb): Remove preserve_history var from WebData and add it as a parameter to web_go * src/web_request.c: (web_request_close), (web_request_header_cb), (web_request_remove), (web_request_read_cb), (web_request_perform): Fix redirects 2006-02-12 Chris Lord,,, * data/web.glade: Rename incorrectly named entry widget * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_append_node_recurse), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_src_write_cb), (web_gtkhtml2_do_javascript), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close): Change how JS works (again) - The document is parsed in a way that allows document.write to alter the stream, providing perfect support for it and not relying on libxml2 CVS. Relies on "add-end-element-signal.patch" gtkhtml2 patch. * src/web.h: * src/web_main.c: (web_go), (web_gconf_home_cb), (web_gconf_media_cb), (web_switch_page_cb), (web_preferences_cb), (main): Hook up the preferences dialogue * src/web_utils.c: Make util functions a bit more robust 2006-02-10 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_stream_cancel_cb), (web_gtkhtml2_request_url_cb), (web_gtkhtml2_new), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close), (web_gtkhtml2_add_style), (web_gtkhtml2_remove_style): - Add CSS before parsing document at all (this needs work..) - Add function for setting media type - Add work-around for gtkhtml2 bug (cancel being called after close of stream) * src/web.h: - Add function for setting media type in back-end * src/web_main.c: (web_new_tab_switch_idle), (web_new_tab_cb), (main): - Don't iterate over list while removing elements from it - Add gconf setting callback for media type * src/web_request.c: (web_request_free): * src/web_request.h: - Fix stopping/removing of requests 2006-02-08 Chris Lord,,, * configure.ac: Add --with-libspidermonkey=prefix option * data/web.schemas: Add gconf options home, media, ssr * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_write), (web_gtkhtml2_add_style): Apply user styles instantly * src/web.h: * src/web_main.c: (web_go_cb), (web_title_change), (web_gconf_zoom_cb), (web_data_free), (web_notebook_scroll_event_cb), (web_close_tab_cb), (web_new_tab_switch_idle), (web_new_tab_cb), (web_switch_page_cb), (main): Add support for new gconf options home, media, ssr 2006-02-07 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close), (web_gtkhtml2_get_zoom), (web_gtkhtml2_set_zoom), (web_gtkhtml2_add_style), (web_gtkhtml2_remove_style): * src/web.h: * src/web_main.c: (web_go_load_idle), (web_new_tab_cb), (main): * src/web_request.c: (web_request_find_cb), (web_request_read_cb): - Handle redirects and cancelling in requests - Refactor user css, styles now get parsed once only and applied after the first document write (often avoids recreating the block tree, can probably refine further) 2006-02-04 Chris Lord,,, * configure.ac: * libcurl.m4: * src/Makefile.am: * src/glibcurl.c: * src/glibcurl.h: * src/web_main.c: (main): * src/web_request.c: (web_request_close), (web_request_cancel), (web_request_read_cb), (web_request_perform): * src/web_request.h: Use glibcurl instead of libsoup - Doesn't handle redirects or cancelling yet, draws attention to other major bugs that need fixing 2006-01-31 Chris Lord,,, * data/Makefile.am: * data/minimo-userContent.css: Add minimo stylesheet * data/web.glade: Design UI for preferences dialogue * src/gtkhtml2/Makefile.am: * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_do_javascript), (web_gtkhtml2_new), (web_gtkhtml2_clear), (web_gtkhtml2_get_zoom), (web_gtkhtml2_set_zoom), (web_gtkhtml2_push_css), (web_gtkhtml2_pop_css): * src/web.h: * src/web_main.c: (web_go_load_idle): Add preliminary custom css code for applying minimo stylesheet when in handheld mode. Needs re-working. 2006-01-20 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_init_js), (web_gtkhtml2_parse_javascript), (web_gtkhtml2_js_src_cancel_cb), (web_gtkhtml2_js_src_close_cb), (web_gtkhtml2_js_src_write_cb), (web_gtkhtml2_do_javascript), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear): - Add document.domain - Add support for 'src' attribute in 'script' tag 2006-01-19 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_js_HTMLDocument_getProperty), (web_gtkhtml2_dom_mouse_over_cb), (web_gtkhtml2_dom_mouse_out_cb), (web_gtkhtml2_init_js), (web_gtkhtml2_do_javascript): Add document.URL and document.title 2006-01-19 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_print_dom), (web_gtkhtml2_append_node_recurse), (web_gtkhtml2_js_HTMLDocument_write): Work around libxml2 a bit better with document.write 2006-01-18 Chris Lord,,, * configure.ac: * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_print_dom), (web_gtkhtml2_append_node_recurse), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_motion_tooltip_cb), (web_gtkhtml2_title_tooltip_cb), (web_gtkhtml2_init_js), (web_gtkhtml2_do_javascript), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close): * src/web_main.c: (web_new_tab_cb), (web_switch_page_cb), (main): * src/web_request.c: (web_request_read_cb), (web_request_perform): * src/web_utils.c: (web_get_abs_url): - Add cut/copy/paste callbacks - Add libtidy support (optional) - Fix some redirecting/absolute URL issues - Fix document.write to work with multiple tags, multiple writes, nested tags, etc. (REQUIRES CVS LIBXML2) 2006-01-17 Chris Lord,,, * src/web_main.c: * src/web_request.c: (web_request_read_cb), (web_request_perform): * src/web_utils.c: (web_get_base_url), (web_get_abs_url): * src/web_utils.h: Fix non-page-url redirects, broken base url generation and protocol assumption in relative urls 2006-01-17 Chris Lord,,, * src/web_request.c: (web_request_read_cb), (web_request_perform): - Fix crash on zero-length reply - Add a User-Agent (w3schools.com rejects if you don't!) 2006-01-17 Chris Lord,,, * gtkhtml2-htmlparser.patch: * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_stream_cancel_cb), (web_gtkhtml2_request_url_cb), (web_gtkhtml2_set_base_cb), (web_gtkhtml2_title_tooltip_cb), (web_gtkhtml2_dom_mouse_over_cb), (web_gtkhtml2_dom_mouse_out_cb), (web_gtkhtml2_init_js): Rewrite JS support - No need for patched gtkhtml2, complete support for document.write (in standards-compliant pages) 2006-01-16 Chris Lord,,, * configure.ac: * gtkhtml2-htmlparser.patch: * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_print_dom), (web_gtkhtml2_js_HTMLDocument_write), (web_gtkhtml2_deinit), (web_gtkhtml2_stream_cancel_cb), (web_gtkhtml2_request_url_cb), (web_gtkhtml2_set_base_cb), (web_gtkhtml2_submit_idle), (web_gtkhtml2_submit_cb), (web_gtkhtml2_title_changed_cb), (web_gtkhtml2_link_clicked_cb), (web_gtkhtml2_motion_tooltip_cb), (web_gtkhtml2_title_tooltip_cb), (web_gtkhtml2_dom_mouse_over_cb), (web_gtkhtml2_dom_mouse_out_cb), (web_gtkhtml2_init_js), (web_gtkhtml2_node_inserted_cb), (web_gtkhtml2_html_end_element_cb), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close): * src/web_main.c: (main): Preliminary support for document.write - Requires patch to gtkhtml2 2006-01-15 Chris Lord,,, * configure.ac: Check for libspidermonkey (for gtkhtml2 back-end, in the future) * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_title_changed_cb), (web_gtkhtml2_link_clicked_cb), (web_gtkhtml2_title_tooltip_cb), (web_gtkhtml2_dom_mouse_over_cb), (web_gtkhtml2_dom_mouse_out_cb), (web_gtkhtml2_new), (web_gtkhtml2_destroy): Implement tooltip support for the 'title' attribute 2006-01-15 Chris Lord,,, * configure.ac: * src/Makefile.am: * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_stream_cancel_cb), (web_gtkhtml2_request_url_cb), (web_gtkhtml2_submit_idle), (web_gtkhtml2_title_changed_cb), (web_gtkhtml2_new), (web_gtkhtml2_clear), (web_gtkhtml2_close): * src/web.h: * src/web_history.c: (web_history_go): * src/web_main.c: (web_stop_cb), (web_go_load_idle), (web_go), (web_go_cb), (web_new_tab_cb), (main): * src/web_request.c: (web_request_find_cb): * src/web_request.h: Use libsoup instead of gnome-vfs, refactor a couple of things - Ups stability and speed a lot 2006-01-14 Chris Lord,,, * src/web_request.c: (web_data_close_cb): Don't try to close stream unless result was a success (fixes crashes opening pages that don't exist and closing tabs) 2006-01-09 Chris Lord,,, * src/gtkhtml2/web_gtkhtml2.c: (web_gtkhtml2_set_base_cb), (web_gtkhtml2_submit_cb), (web_gtkhtml2_title_changed_cb), (web_gtkhtml2_new), (web_gtkhtml2_destroy), (web_gtkhtml2_write), (web_gtkhtml2_clear), (web_gtkhtml2_close): * src/web.h: * src/web_main.c: (web_show_url_entry), (web_go), (web_new_tab_cb), (main): * src/web_request.c: (web_data_cancel), (web_data_close_cb): Fix regressions - Stop/cancel/close code needs work, sometimes crashes 2006-01-09 Chris Lord,,, * configure.ac: * data/web.schemas: * src/Makefile.am: * src/gtkhtml2/Makefile.am: * src/gtkhtml2/web_gtkhtml2.c: * src/web.h: * src/web_main.c: (web_stop_cb), (web_go), (main): * src/web_request.c: (web_request_find_cb), (web_data_close_cb), (web_open_callback): * src/web_request.h: Huge overhaul - Rendering backend now a plug-in, via g_module Regressions: - Zoom doesn't work - Closing tabs doesn't work - Form submission doesn't work 2005-12-28 Chris Lord,,, * src/Makefile.am: New files (src/web_request.*) * src/web.h: * src/web_history.h: Move history and request structures to the relevant header files * src/web_main.c: - Don't allow to scroll to the New page tab - Close application when last open tab is closed * src/web_request.c: * src/web_request.h: Move fetching code out of web_main.c 2005-11-09 Chris Lord,,, * data/web.glade: Remove toolbar style to follow gtk preferences 2005-11-09 Chris Lord,,, * data/Makefile.am: Distribute web.schemas 2005-11-09 Chris Lord,,, * data/web.glade: - Add preferences and about dialogs - Populate menu * src/web_main.c: (web_gconf_zoom_cb), (main): - Connect lots of menu signals 2005-11-08 Chris Lord,,, * configure.ac: * data/Makefile.am: * data/web.schemas: * src/web.h: * src/web_main.c: (web_go), (web_submit_cb), (web_new_tab_switch_idle), (web_new_tab_cb), (web_switch_page_cb), (main): Add gconf setting to make last zoom level persist between sessions/tabs 2005-10-26 Chris Lord,,, * src/web_main.c: (web_go): Respond to set_base signal so pages that use the tag work 2005-10-24 Chris Lord,,, * data/web.glade: Make tabs scrollable and disable forward button by default * src/Makefile.am: Add new source files (web.h, web_history.c, web_history.h) * src/web_main.c, src/web_history.c, src/web_history.h: Fix bugs here and there, implement history, error pages and tab-closing. 2005-10-22 Chris Lord,,, * data/web.glade: Remove new page button, add notebook widget back to glade file and add a 'new page' tab * src/web_main.c: (web_show_url_entry), (web_stop_cb), (web_go_load_idle), (web_go), (web_request_url_cb), (web_set_base_cb), (web_go_cb), (web_title_changed_cb), (web_submit_idle), (web_submit_cb), (web_new_tab_cb), (web_switch_page_cb), (main): Various small changes and fixes. Change new page mechanism to work similarly to Internet Explorer 7. \end{verbatim} }} \subsection{GTKHTML2 Change-Log Entries} \label{gtkhtml2-changelog} {\scriptsize{ \begin{verbatim} 2006-07-04 Chris Lord * libgtkhtml/layout/htmlbox.c (need_containing_width): Only return true if the box has a containing block, otherwise return FALSE 2006-03-15 Chris Lord * libgtkhtml/view/htmlview.c (html_view_style_updated): If the style is NULL or set to HTML_DISPLAY_NONE, just break, not remove the node Handle the properties on new_box Check box->parent before ->prev and ->next Create a temporary HtmlBox for the next child * libgtkhtml/graphics/htmlimage.c (html_image_init): Initialize the stream to NULL * libgtkhtml/graphics/htmlimagefactory.c: (html_image_factory_get_image): Use g_signal_connect_swapped instead of g_object_weak_ref to call html_image_shutdown Add a weak pointer to the stream 2006-03-14 Chris Lord * libgtkhtml/layout/htmlbox.c (html_box_check_min_max_width_heigh): Use else if rather than multiple if statements * libgtkhtml/layout/html/htmlboximage.[ch] (html_box_image_relayout): Guard against oscillation of the image between a size that requires a scrollbar to be shown, and one that does not, to avoid infinite loop conditions 2006-03-04 Chris Lord * libgtkhtml/view/htmlview.c (html_view_realize): Rather than trying to copy the style and modify it directly, use gtk_widget_modify_bg (html_view_style_set): Call gtk_widget_modify_bg if the bg and base colors are not the same, and return to avoid an infinite loop condition 2006-02-04 Chris Lord * libgtkhtml/layout/htmlstyle.c (html_style_compare): Fix to compare s1->display against s2->display 2006-02-02 Chris Lord * libgtkhtml/css/cssmatcher.c (css_matcher_html_to_css_after): Check that the display style is not block for the align property * libgtkhtml/document/htmldocument.c (html_document_restyl_node): Remove workaround for recreation issues with dom nodes and layout boxes * libgtkhtml/graphics/htmlimagefactory.c (html_image_shutdown): Change the prototype to be used with g_object_weak_ref (html_image_factory_get_image): Use a weak ref for html_image_shutdown rather than connecting to the last_unref signal of the image * libgtkhtml/layout/htmlbox.c (html_box_{left,right}_margin): (html_box_check_min_max_width_height): Use the containing block of the box rather than box->parent * libgtkhtml/layout/htmlboxblock.c: (html_box_block_real_get_boundaries): Use the containing block of the box rather than the ->parent pointer * libgtkhtml/layout/htmlboxfactory.[ch]: (html_box_factory_new_box): Add the force_new argument * libgtkhtml/view/htmlview.c (html_view_insert_node): Call the html_box_factory_new_box method with FALSE for force_new (html_view_style_updated): Handle the CHANGE_RECREATE type of style change when the style gets updated Fixes #73643 2006-02-02 Chris Lord * libgtkhtml/layout/htmlbox.c (html_box_check_min_max_width_height): Maintain the aspect ratio of images when resizing * libgtkhtml/layout/html/htmlboximage.c (html_box_image_relayout): Recalculate the min/max width/height when doing a relayout 2006-02-02 Chris Lord * libgtkhtml/layout/htmlboxtext.c (html_box_text_finalize): Destroy the text box's slaves * libgtkhtml/layout/html/htmlboxembeddedimage.c: (html_box_embedded_image_finalize): Disconnect the signal handlers to resize and repaint the image (html_box_embedded_image_class_init): Override the finalize method * libgtkhtml/layout/html/htmlboximage.c (html_box_image_finalize): Disconnect the signal handlers to resize and repaint the image 2006-02-01 Chris Lord * libgtkhtml/css/cssmatcher.c (handle_background_image): (css_matcher_apply_rule): Handle the "background: none;" and "background-image: none;" properties for pages \end{verbatim} }} \newpage \subsection{Displaying Web Content on Small Displays} \label{mult-paper} \includegraphics[width=\textwidth]{paper-revised1.pdf} \newpage \includegraphics[width=\textwidth]{paper-revised2.pdf} \newpage \includegraphics[width=\textwidth]{paper-revised3.pdf} \newpage \includegraphics[width=\textwidth]{paper-revised4.pdf} \newpage \includegraphics[width=\textwidth]{paper-revised5.pdf} \end{document}