sysutils/bpm cannot handle ports with OPTIONS, since it launches a dialog process in a shell invisible to the user. This makes the operation appear like halted. This patch is probably the simplest solution to the OPTIONS handling problem. Using gdialog (from x11/zenity) we get a popup window with the specified options, although without correct initial values. Nevertheless, this way the user has a chance to build or upgrade a port without the process hanging in the background, waiting for user input, making bpm usable for every use case I've come across. How-To-Repeat: Try to use bpm to build/update a port that has OPTIONS in the Makefile.
State Changed From-To: open->feedback Awaiting maintainers feedback
Looks good. The only thing I want to avoid is unwanted GNOME linkage. Currently BPM has no forced GNOME-libs dependencies. Can zenity be built with GTK+ only?
Doh, I never received your followup for some reason. Looking at the zenity port it appears that it will bring along a few low-level GNOME stuff (ORBit2, gconf2, gnomehier, etc.), not the real heavyweights (gnomemedia, gnomelibs, gnomeapplets, etc.). Naturally, users that get bpm as a gnome2-power-tools dependency won't care, but others might. Unfortunately I haven't found anything similar, but DE-agnostic. Since bpm is a desktop application, I personally don't mind a little extra cruft every now and then in exchange for unique functionality. Perhaps this should be considered a temporary measure, until proper OPTIONS handling is implemented in bpm without extra helper applications.
State Changed From-To: feedback->feedback Seth, what do you think? Is it OK with the few extra dependencies zenity requires?
State Changed From-To: feedback->open Feedback received, dep on zenity is OK.
Responsible Changed From-To: freebsd-ports-bugs->lawrance Take.
State Changed From-To: open->closed Committed, thanks!