Major projects I have been involved in
Areas of expertise I have gained
Parametric Technology is a young company but already the seventh largest software company in the world. They are the World leader in the CAD/CAM/CAE market with their main product, Pro/Engineer being used by thousands of major companies world wide through the entire design and analysis stages to the manufacturing and tooling process on the workshop floor. The chances are high that you may drive a car that has a part or own an item that was engineered with this product. Enough advertising, but, at this time, I do still work for them.
Pro/Engineer, until a couple of years ago had a basic user interface - the main working window and a huge number of vertically cascading expanding and expanding menus. No menubars, no drop down menus as we know them, and no dialogs. It had a style which was typical of the mid-eighties. The R&D group in England was charged with creating the interface and the tools for use by the application engineers at PTC's headquarters in Boston, USA. These software engineers would, over the course of several years bring Pro/E into the 90's to become a fully fledged dialog and menu driven application, whilst never subtracting, but only adding functionality with speed and ease of use.
Since I joined PTC's group in the UK over three years ago, I have been one of the members of the small team involved with creating the GUI and it's related tools for use by others. Pro/E is certified to run on a huge number of platforms with varying graphics cards and operating systems. The GUI was written with little reliance on platform specific components (eg XmPushButton, to name one of the simplest) so as to appear and behave as similar as possible on all these platforms. Written in C, using X11, Xt, Motif, Win32 and WinNT, the GUI worked on all the combinations of platforms and graphics cards in European Languages as well as Japanese, and using X, SGI GL, OpenGL, Starbase, XGL, or NT graphics.
Major projects I have been involved with
As well as being involved in many aspects of the design, implementation, performance and testing of the UI and its tools, I was specifically responsible for a number of major projects in the UI:
Japanese language support
Firstly I had responsibility for making sure that the UI worked in the Japanese Language on all the supported UNIX platforms - mainly SGI, DEC, SUN, HP, IBM and Hitachi. This six month project included a time critical two month period working at the company's headquarters in Waltham, MA, testing the Japanese Input Methods on as many variants of machine as possible. The project meant liasing with each of the support engineers from these companies whenever problems arose which required it
Overlay plane support
Secondly, the advent of all the new dialogs and menus meant that the main graphics area was continually being exposed and redrawn. I had the task of removing this problem by using overlay planes on all UNIX platforms fitted with graphics cards which supported this functionality. This meant an intimate understanding of how each platform implemented overlay planes, and how each differing graphics card supported 'Visuals' of varying depths and colormaps. Close liaison with each of the hardware vendor's support engineers was critical since few applications have ever been written which make such full use of this functionality across so many platforms for which so many graphics cards are supported. The few months on which I worked on this project was an intense learning period and culminated with another month of testing in the USA, and helping the hardware vendors solve the many problems this functionality was showing up in their code.
Resource file re-use
The GUI dialogs were described by a resource file in which nearly all aspects of a dialog could be laid out. As the GUI developed and the number of dialogs grew and grew, I was given the task of adapting the UI database and resource file parsing to cope with the re-use of portions of a dialog in a kind of #include style. This reuse had to work both by naming the included file in the resource file or by programmatically naming the included file at run time to provide context dependent adaptability of the dialogs without having to describe all possible dialogs at start-up or generate whole new dialogs during runtime. The complexity of dialogs available meant this was a complicated process requiring full attention to detail and testing.
Areas of expertise I have gained
