Bringing the power of HTML5 to P4V
Although it was clear to me that HTML was a natural choice for user interface development, there were numerous problems to actually creating a usable implementation- not the least of which was lack of an HTML rendering engine in C++! I looked into porting the rendering engine from an open source browser, but decided that was too much work to be practical.
Now the dream of using HTML to create interfaces in P4V became a reality, and I checked a tiny prototype into my dev branch. A small group of HTML visionaries formed: Jason Gibson, Bill Baffy and Michael Bishop.
Although we created a working HTML prototype of the Administration Tool’s Home Page running inside P4V, three problems became clear: first, without access to data in the Perforce server, the interface could not be very useful; second, where could the HTML files be stored?; and third, how do we know which HTML file goes where in P4V?
e.g. to list pending changelists of user “myuser”:
p4 changes -u myuser -s pending
p4(“changes -u myuser -s pending”);
The second problem, where to put the HTML, proved trickier, and was not completely solved for almost another year due to other intervening responsibilities.
Now we had a powerful and flexible mechanism to determine “what” HTML is used. To determine “where” in P4V, we introduced the idea of “extension points” in P4V.
(Extension points come in two flavors: “extension by addition” and “extension by replacement”. “Extension by addition” creates new HTML windows. “Extension by replacement” substitutes an HTML application in the place of an existing P4V window.)
The text keys that define extension points are the link between the central settings file and P4V: P4V asks the central settings file about a specific key at the point it is creating new tabs or about to display, for example, the submit dialog, and the central settings file can opt to return the name of an HTML file to use at that extension point. The name of HTML files used at extension points we call “entry points”.
(Entry points are analogous to the index page of a website- they are the first page you see, but can be the doorway into other pages.)
Now we can define generic extension points during P4V development very quickly- simply define the key name, ask the central settings file when creating or using that window, and load the HTML of the entry point into the WebKit window. Best of all, the externalized central settings file lets us customize and extend an installed P4V endlessly.
Now we faced a new problem: we supported only local files as entry points, which leaves to the customer the unacceptable problem of getting the files into the right locations on each hard drive.
The solution was to enhance P4V’s processing of entry points to encompass four different syntaxes:
- Perforce Depot
Depot paths are loaded by using p4 print to load the contents of a file on the Perforce server directly into the WebKit engine. Extending Qt’s Network Access Manager, we added a P4URI type to extension points. This allows the central settings file to return entry points that are in a different Perforce server. This also enabled using an http: entry point. In essence, P4V now sees a Perforce server as if it was a web server.
So now we knew, given a central settings file, how to get the right HTML entry points to the right extension points in P4V. One perplexing problem remained- how does P4V find the right central settings file? I rejected hard-coding a depot location- too fragile. Storing the central settings file in a counter was considered, but that requires hard coding a counter name, and counters can be modified by non-super users. I needed something that only a super user could change, but any user with read permission could see. The answer was in the protect table: only a super user can modify it, but a user can read lines from it that match their user using “p4 protects”. I could put the location of the central settings file into the depot path field of the protect form; luckily it would also take a local path. P4V simply runs “p4 protects” and reads the central settings file location from it. This was a powerful solution- no hard coding of locations or key names that could collide with user identifiers, great security, and as a freebie, full access to the users and groups functionality in the protect table. The administrator can conveniently assign central settings files, and thus, GUI extensions, via the existing group structure.
Now we have a system where the central setting file is stored and versioned on the server. The HTML applications, now called “applets”, are stored and versioned on the server and transparently delivered to P4V and P4Admin all under central control.
One more surprise
It was just this year, 2010, that the industry began waking up to the power of HTML5, and here it is, already integrated in P4V and P4Admin in the 10.1 release. What will you build with it?