Auckland

Results: S&T Evaluation and Web Survey

Blog post by czeidler on Tue, 2013-09-24 00:27
, , , ,

Most work on my PhD thesis is done and I like to provide you with the results from our research at Uni Auckland on Stack & Tile. At BeGeistert 023 (October 2010) I conducted a user evaluation of Stack & Tile to answer the question whether stacking and tiling within an overlapping window manager bring any benefits to the user. At the end of last year I used a web survey to investigate if and how Stack & Tile is used by actual users. The results of both studies have been presented recently at the INTERACT'13 conference in Cape Town. INTERACT is an A ranked conference for Human Computer Interaction (HCI) and hopefully I was able to interest some other researchers in Haiku. Thanks again for all participants of the evaluation and the survey!

The encouraging results are summarized in the following. The complete paper can be found here.

Stack & Tile Evaluation (BeGeistert 023)

We investigated the benefits of Stack & Tile's stacking and tiling features in a traditional overlapping window manager. Therefore we looked at use-cases where the user is working with documents of the same or of different applications, and a use-case where data is exchanged between documents of the same application, and designed experimental tasks accordingly. Another task measured the time needed to switch between different groups of windows.

In a controlled experiment, we found that stacking and tiling features can significantly improve completion times for tasks involving several windows (of the same application as well as of different applications). Furthermore, switching between different tasks was found to be much faster when windows were grouped by task using Stack & Tile. Setting up a Stack & Tile group is an initial overhead that may prevent users from using these features. However, the potential time savings as well as questionnaire answers indicate that the advantages outweigh this overhead.

Stack & Tile Web Survey

Stack & Tile is already integrated into Haiku for over two years, and thus is already exposed to a large group of developers and users. This allowed us to target another interesting question: How are stacking and tiling features used and accepted by real users? In a web-based survey we asked the Haiku community about their opinions and experiences of Stack & Tile. From 146 responses we got a detailed insight into how, how often and for what applications Stack & Tile is used.

There was a wide agreement that Stack & Tile can be useful, especially by participants who had used Stack & Tile before the survey. The stacking feature was perceived as being slightly more useful and also estimated to be used more than the tiling feature. We found that people were using the stacking and tiling features for a multitude of different use-cases, e.g., programming, browsing or file management. In a field for general comments many people wrote that they like Stack & Tile and suggested further ideas to integrate it more into the desktop. These ideas include future works such as grouping of windows by their Stack & Tile group in the taskbar and Stack & Tile group persistence.

ALE (Auckland Layout Editor)

Blog post by czeidler on Mon, 2012-09-03 09:49
, ,

Recently I spend some time to develop ALE the Auckland Layout Editor and now it's getting time to release a first testing version! ALE is a tool for developers to create GUIs. These GUIs can then be loaded from an application. This first version is still very basic and I hope I can get some feedback what can be improved and which features are most needed. It mainly focus on layout creation and less on editing view properties.

While working on user interface customization it turned out that the step to creating a GUI builder is not that big. When changing a layout at runtime the user must be able to move existing views around, insert them between other views or swap the position of two views. Furthermore, it should be possible to temporary remove unused views from the layout and add them again at a later point. It is also important that the user can't create invalid layouts. For example, views should never overlap each other and the layout must stay solvable. What is missing for a GUI builder is that new views can be created and added to a layout. Furthermore, it must be possible to save and restore a layout and access the items from within an application, i.e. get a pointer to the c++ object.

ALE is a constraint based layout editor that based on the BALMLayout layout class. BALMLayout is a very powerful constraint based layout and can describe layouts that can't be described with other layout classes, like for example the grid-bag layout. Layouts created with ALE are automatically resizable and overlap-free. This means while editing a layout you can't create a layout that has two overlapping views.

ALE has a component factory that can be used to create GUI elements, e.g. buttons or text views. Each view in the layout gets a string id which can be changed in the editor. After the GUI developer designed a GUI the layout can be saved into a BMessage and be attached to a GUI specification file. From the c++ application this BMessage can be read and restored using a LayoutArchive class. This class also allows to map the string identifier of a view to an actual c++ object.

A test version of the editor can be downloaded from *) This is a debug version and relatively large. If you want to take a look at the source code, it is on github **). I you want to build it please come back to me and I will give you some more information about that.

There is also a very simple sample application in the Demo directory. This piece of code shows how to get a pointer to the objects in the layout. To build it just call make in the demo directory. It is using a GUI specification file called TestLayout which is also in the Demo directory. This file must be in the same folder as the app binary file is. Furthermore, it can be opened in the editor to change the layout or add new views.

Known bugs:
- some crashes
- explicit sizes are not stored at the moment
- the layout min size is not restored from the layout specification, this means overlap can occur in your app.

thanks for testing and feedback is welcome!

*)
http://www.cs.auckland.ac.nz/~clemens/ALE_3_9.zip
**)
https://github.com/czeidler/haiku

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.

Haiku on Java

Blog post by yourpalal on Thu, 2012-03-01 22:36
, , , ,

As part of my work at the University of Auckland (which is drawing to a close soon) I have been looking at Java on Haiku. There is already some support for Java on Haiku. By running installoptionalpackage DevelopmentJava you can get the JamVM java virtual machine, GNU Classpath (including gjar, gjavah and maybe some other utilities), and ecj (the Eclipse Java compiler, which is written in Java). This is enough to run and compile basic Java apps. For instance, the popular Java buildtool Ant can run on Haiku.

Anyway, the reason I was investigating this is because the University of Auckland has a big Java library (a database, actually) that has been developed here, and Christof and Gerald (my supervisors) want to bring it to Haiku. To do this, we require the ability to write code that integrates with both Java libraries, and the Haiku API. I looked at various solutions:

  • gcj compiles Java to C++, but seemed like too big of a port
  • Java Native Interface (JNI) allows for writing C++ code that hosts a JavaVM and calls Java code, but is tedious to write.
  • SWIG can generate Java bindings to C++ libraries, even allowing Java classes to inherit from, and override virtual methods in, C++ classes.

SWIG is a mature solution that handles writing lots of JNI code, and the input files are pretty much just C++ headers, so it doesn't require too much tedious work. Given these points, I decided to go with SWIG, and I have put the results (so far) on Github.

Currently, I have two tests, one that runs a custom handler on the BApplication thread (also works running it on an extra BLooper) and listens for messages. The other test makes a very simple GUI using the Haiku API. Check out the result of this test in the image on the right. That's a BWindow with a BButton and a BGroupLayout and a BStringView, all created with Java code!!!

There are still some issues, but I'm really excited about the progress that I've made already, and I'm very impressed with SWIG! As I said in the README on Github, having Java bindings also opens up the door for any JVM language to use the Haiku API, for instance Jython, JRuby, and Scala to name a few. If you're interested in contributing, head over to github and fork the project. If you just want to try it out, it's really easy to do that, there are instructions on github in the README.

Syndicate content