[tor-bugs] #2163 [Vidalia]: Disable menubar icon in OS X

[Tor Bug Tracker & Wiki]

#2163: Disable menubar icon in OS X
---------------------------------+------------------------------------------
 Reporter:  jabes                |          Owner:  chiiph        
     Type:  enhancement          |         Status:  assigned      
 Priority:  normal               |      Milestone:                
Component:  Vidalia              |        Version:  Vidalia 0.2.10
 Keywords:  os x, menubar, icon  |         Parent:                
   Points:                       |   Actualpoints:                
---------------------------------+------------------------------------------

Comment(by edmanm):

 Replying to [comment:5 jrklein]:
 >1) The .plist template is already being populated by CMAKE and placed in
 the correct folder (Vidalia.app/Contents/Info.plist). This was happening
 before I came along. I just specified a custom file so that I could add
 the LSUIElement setting required by this patch. Please confirm if
 something should be done differently here?

 Ah, yeah, I think CMake does this automatically on OS X. If you specify
 the `.plist.in` file, CMake will use that and the `${foo}` string
 replacements may or may not be filled in properly. In either case, you
 really should do something like

 {{{
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/your.plist.in
                  ${CMAKE_CURRENT_BINARY_DIR}/your.plist
   set_target_properties(${vidalia_BIN} PROPERTIES MACOSX_BUNDLE_INFO_PLIST
                         ${CMAKE_CURRENT_BINARY_DIR}/your.plist)
 }}}

 That way string replacements in your `.in` file will be properly filled
 in, the result will be placed in the correct output directory and you will
 use the outputted file as the `.plist` for the app bundle.

 > 2) This makes sense.  After investigating names for #3, I'll likely
 rename "Dock" to "TaskbarOnly" and "Tray" to "TrayOnly" while defining
 these constants.  Open to other name suggestions.

 It doesn't really matter what you call them in the `vidalia.conf` file. My
 point is that the caller to `VidaliaSettings::getIconDisplayPreference()`
 (or whatever you end up calling it) shouldn't need to know what strings
 you decided to roll with. If you look at
 `TorSettings::getAuthenticationMethod()` or
 `TorSettings::getControlMethod()`, you'll see that they both return an
 enum value (e.g., `TorSettings::PasswordAuth`). You could define an enum
 with the three states you want and some private methods within
 VidaliaSettings to handle converting between enum values and whatever
 string constants you want to use in `vidalia.conf`. Check out how it's
 done in `TorSettings::toString(AuthenticationMethod)` and
 `TorSettings::fromString(AuthenticatMethod)`. It's a little more code to
 add, but it gives callers a cleaner API to use. Plus, if you have to
 change the strings you chose later for some reason, callers to
 `VidaliaSettings::getIconDisplayPreference()` won't have to change.

 > I'll submit an updated patch in the next day or two.  Thanks again!

 No problem. Good work so far.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2163#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online