Blogs

OpenJDK port: community bonding report

Blog post by hamish on Thu, 2012-05-24 20:09

Over the community bonding period I've been researching the best approach to take for the AWT port, and over the past week or two I've been implementing a prototype.

AWT demands the implementation of a number of 'peers' for buttons, text boxes, etc. which have historically been implemented using the native widgets of the underlying platform. The time taken to implement and maintain these peers is quite large, especially considering that these AWT widgets have been superseded by Swing and are rarely used anymore.

An alternative implementation approach used by the Caciocavallo project involves providing native heavyweights for the windows and views and then calling on Swing to provide drawing and event handling for the various widgets. This eases the porting of AWT and reduces the amount of platform-specific code to maintain. This approach is also taken by the recent port of OpenJDK to Mac OS X.

Over the past week or two I've written a prototype implementation using the Caciocavallo Swing AWT peers. It's very incomplete thus far, but I've got drawing working pretty reliably, as well as some event handling including mouse input. Screenshot below the fold.

Decorators and Stack and Tile

Blog post by czeidler on Mon, 2012-05-21 21:40

Just saw on Haikuware that there is another GUI for setting a decorator. First, I'm happy that people are actually using this "hidden" functionality to write custom applications. However, after Alpha 3 I changed the decorator API which broke all other decorators.

The reason for that is that the stacking feature of Stack and Tile is now integrated into the decorator. In other words all decorators have to support Stack and Tile now! Stacked windows share the same decorator and the decorator is responsible to display multiple tabs. This has the advantage that the developer has more freedom to design the appearance of the tabs. Furthermore, tabs can be arranged more flexible. For example, you can add the stacking features to the Amiga decorator by drawing the tabs beside each other into the title bar.

Updating the existing decorators is not too difficult but it's a bit of work. First, most decorator methods take a tab index now which has to be handled correctly. Secondly, the decorator must be able to somehow draw multiple tabs.

If you are interested to port an alternative decorator to the new API and so make it support Stack and Tile take a look at Decorator.h header and the DefaultDecorator *).

http://haiku.it.su.se:8180/source/xref/src/servers/app/decorator/

Status Report (Stack and Tile)

Blog post by czeidler on Mon, 2012-05-14 23:31

Having started my PhD at the University of Auckland two years ago I think it's time to provide a brief overview for the Haiku community about what I am doing here. Since a complete overview would result in a pretty big post I intend to split it into multiple smaller posts. Fingers crossed that I remain motivated enough to keep writing :).

The topic of my PhD is "User Interface Customization" and covers three aspects. First, customization in the large which targets the management of multiple windows of different applications using Stack and Tile. Secondly, customization in the small. Here I take a look at how customization can be effected within an application, especially how the user can change the layout of an application at runtime, e.g. to optimize an application for his special use-cases. Finally, I'd like to take a look at how far it is possible to also let the user customize the functionality of an application, e.g. connect a button click event to a new component that plays a sound effect to emphasize the importance of the button clicked event.

Stack and Tile

Stack and Tile is now integrated into the Haiku app_server and is enabled on default. There are two main operations in Stack and Tile which are, guess what?, stacking and tiling. Stacking allows the user to stack windows on top of one another and tiling allows the tiling of windows beside each other. To do this, just press the Windows key while dragging a window:
a) by the tab onto another window tab to stack them or
b) beside another window to tile them. In this way it's possible to create complex groups of stacked and tiled windows.

The main purpose of Stack and Tile is to make window management easier and working with multiple windows more efficient. When using multiple windows on the same desktop the user frequently runs into the problem that windows occlude each other. To make the occluded parts visible the user has to move other windows aside or bring the occluded window to the front. All these operations can result in more occlusion of other windows. This problem can makes window management quite tedious. Another problem arises when working on multiple tasks in parallel. For example, if one task is a programming task and involves multiple editor windows and a terminal, and another task uses a browser and a mail application, while a third task has a word processor and tracker window with related documents. Switching from one task to another could make it necessary to activate all windows of a task. This can be done by bringing the windows of a task to the front or moving unrelated windows aside. The more windows which belong to a certain task, the more window operations are needed to bring all windows of that task to the front thus slowing down task switching.

Stack and Tile provides a solution to these problems. Windows in a Stack and Tile group are not occluded at all if they are tiled, and windows are completely occluded if they are stacked. This solves the first problem that windows are fully or partially occluded. Tiled windows in a Stack and Tile group are always visible and stacked windows do not occlude other windows unintentionally. Furthermore, the problem of task switching is targeted, activating one window in a Stack and Tile group brings the complete group to the front and thus switching between Stack and Tile groups is very easy.

User Evaluation

To evaluate how Stack and Tile performs compared to the traditional window system a user evaluation has been done. During BeGeistert10 many of the attendees participated in this evaluation. Thanks again for that! The results have been very positive. The measured task completion time and task switching time have been significantly lower using Stack and Tile than under non Stack and Tile conditions. Furthermore, the setup time to create a Stack and Tile group is acceptably low and does not outweigh the time saved while using a Stack and Tile group.

There were four different groups of tasks:
1) Window switching between windows with unrelated content of the same application (e.g. a stacked group of pictures).
2) Window switching between windows with unrelated content of different applications (e.g. a stacked group of a pdf viewer, a browser and a text document).
3) Window switching between related windows (e.g. exchange data between text documents which are tiled beside each other).
4) Task switching between multi-window tasks.

In all tasks Stack and Tile was superior to the non Stack and Tile setup and on average participants were able to complete the tasks much faster. If somebody is interested in more details I'd like to publish a more detailed summary at a later point.

Future Work and Session Management

Although I have finished working on Stack and Tile as part of my PhD there are still many ideas around to improve Stack and Tile and integrate it further into Haiku. There are, for example, ideas to show Stack and Tile groups in the Deskbar, merge two different Stack and Tile groups, or make the Stack and Tile key customizable. Moreover, there are still some drawing bugs which should be fixed one day.

Personally, the most important missing feature is to make Stack and Tile groups persistent. This means Stack and Tile groups can be reloaded or can be restored after a Haiku restart. To implement that functionality the states of all windows of an application in a group and the Stack and Tile configuration of these windows must be stored. At first, that sounds not very difficult but is actually quite complicated and can not be
implemented using the current Haiku API. The first problem is that a stacked or tiled window is not the main window of an application. Just starting an application would not give the right window in this case. The second problem is that windows in Haiku have no ID and cannot be identified after an application restart.

To solve these problems a new API has to be introduced that allows for storing and restoring an application state. When storing an application state each window of the application gets a unique ID which can be used by Stack and Tile to store the group configuration. To restore all Stack and Tile groups after a reboot, first all applications have to be restored and then all windows have to be stacked and tiled again.

A base implementation of a session manager that also is able to restore Stack and Tile groups can be found on github *) There was also some discussion about the session manager API on the developer mailing list a while ago **)
As I have not much time to work on any of these, volunteers are welcome!

*) github.com/czeidler/haiku (SessionManager branch)
**) http://www.freelists.org/post/haiku-development/session-manager

Back from Auckland

Blog post by yourpalal on Thu, 2012-05-03 16:51

With one big push the work I did on ALM (Auckland Layout Model) while I was at the University of Auckland is now in the main Haiku repo. In short, I’ve brought the BALMLayout up to standard with the other layouts in Haiku, and added some new features as well.

Work in progress on the xHCI driver

Blog post by korli on Tue, 2012-05-01 22:23

I started to work on the xHCI driver in late 2011: I found the code provided during the Google Summer of Code 2011 was promising and didn't get its full exposure. Another reason was Haiku Inc. provided me with hardware I needed to mentor the xHCI project by Jian Jiang.

GSoC Introduction: BFS Partition Resizer

Blog post by ahenriksson on Mon, 2012-04-30 12:43

The goal of this project is to create code for resizing a BFS volume in a safe manner, through the existing volume resizing interface. At first utilized with a command line tool, and toward the end of the summer hopefully integrated with DriveSetup if time allows.

During the community bonding period, I want to get my development environment set up, and gain some basic familiarity with writing to disk. To accomplish that, I'm going to write a small program that can read and write sectors to the hard drive.

I'm also going to read up on documentation and code, in order to get a clear picture of where to begin when I start the coding.

You can check out my submitted proposal at https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/... for a brief introduction of me, a technical overview and timeline.

GSoC Introduction: NFSv4 client

Blog post by Paweł Dziepak on Mon, 2012-04-30 02:04

My GSoC project is to implement a Network File System version 4 client. NFS since its early versions became one of the most popular way of sharing files among Unix-like (and not only) systems. The fourth version brings many changes to the protocol that both simplify implementation and make it more efficient. That includes better support of client side caching which can significantly improve performance. In addition to that neither mountd nor NLM needs to be used anymore since services they provide are now part of the protocol.

Community Bonding Period

During the community bonding period I am going to get myself familiar with every detail of all RFC containing information on how does NFS protocol works. That includes specifications of Remote Procedure Calls (RPC) and External Data Representation (XDR) which are used by NFS as well as the specification of NFSv4 itself. I think it may be also a good idea to check how NFS clients are implemented in other operating systems in order to find some interesting solutions.

I also need to get myself familiar with the Haiku itself. Specifically, with the parts of the kernel the NFSv4 will work with. That includes, among others, file caching, notifications, network. Since disk based file systems behave in a different way than NFS there may be need to make some changes in these parts of the code, so I will have to know exactly how to do it.

Summer and later

When I am ready with all preparations and the coding starts I am going to, firstly, write NFSv4 client that just works. That will require proper implementation of RPCs and basic NFS requests. Then I will be able to start making it usable, i.e. add client side caching, notifications, support for file attributes.

After GSoC, when NFSv4 client will be ready I will want to add support for NFSv4.1 mostly because of its interesting extensions such as directory delegation, which can improve notifications support or pNFS, parallel access to a clustered server implementation.

Syndicate content