See $FG_ROOT/Docs/README.gui - for instance, you could use a select widget instead of the combo if the combo turns out to be problematic.
Apart from that, the pui2canvas effort is using Canvas to parse/render a subset of the PUI/XML markup used by FlightGear to render a handful of widgets - and given that a combo box is really just an input field (possibly readonly) with a corresponding button, it should be relatively straightforward to create a full combo widget - in fact, a few months ago I created a simple combo-equivalent by using the existing ScrollArea widget, adding one button widget to the scrollArea for each combo item - ultimately, this turned out to be working well enough actually:
http://wiki.flightgear.org/Howto:Proces ... ing_CanvasIt would be trivial to tell the Canvas widget to align/layout this according to what people need.
In addition, it is worth noting that we don't really need a 1:1 mapping between PUI and Canvas, because we can usually emulate/approximate most PUI widgets rather easily using similar workarounds - as a matter of fact, the whole PUI widget set is rather archaic, and we really only need 2-3 widgets to approximate the full set of supported widgets without much of an effort.
For instance, there are a number of hard-coded widgets, such as the airport-list, waypoint.list or the property browser - under the hood however, all of these end up just being combo/select boxes with items that respond to clicks - the screenshow below is using the pui2/canvas "combo-workaround" (shown above) to simply turn the airport-list logic into a crude property-browser equivalent:
Also note that these screenshots don't just show "static" buttons, but instead use the corresponding Nasal APIs to dynamically populate the ScrollArea with the proper widgets.