I have a few applications that I run whilst I’m using my computer, these applications are literally only used upon startup and then never touched again until I need to restart my computer.
What’s the point in having them in the system dock? Well, none. Usually you can do a simple right click on the application and then hide from dock. Though some programs are stubborn don’t like to behave as they should.
The way you can avoid all aggravation with these programs and get them to hide forcefully is to edit the applications info.plist.
To find this file, navigation to where your application resides, usually in the applications folder within OSX. Once there find the application.app and right click and hit “Show Package Contents”.
This will take you to a new folder and within here you should be able to see a info.plist. This is a small xml file in Apple’s Property List XML format. It’s contents is a key pair value structured file that contains a few default rules. Apple states the file to be:
“Launch Services (part of the Core Services framework in OS X) provides support for launching apps and matching document types to apps. As a result, the keys recognized by Launch Services allow you to specify the desired execution environment for your bundled code. (In iOS, Launch Services is a private API but is still used internally to coordinate the execution environment of iOS apps.)”
Here we can specific whether or not to show it in the dock bar.
Open the file with a text editor, I suggest Sublime Text, once opened do a quick find for “LSUIElement” – if found we just need to add a value true, to this element. However if “LSUIElement” doesn’t exist we can simply add the following at the bottom of the file before the ending </dict> </plist> –
First off, many people will disagree with including Plugins with your themes. Yes and generally rightly so:
- Automatic Updates: If the plugin is freely available from WordPress.org already, then so are automatic updates to the plugin. The original author can add features, fix bugs, and deploy them quickly. Your clients and customers then benefit from on-going development. If you were to package them in your theme, though, you are essentially freezing the code at that point in time – any further updates, bug fixes, etc. would have to come from you. This means you’ll need to continuously release theme updates whenever the included plugins update.
- Core: When WordPress updates, some plugins will break. This is because the original authors didn’t take the time to remove deprecated functionality or test with new versions of WP. Do you really want to commit to maintaining your theme + someone else’s code?
- Interoperability: As the great mfields once said, “If you’re building a bathroom and you change the wallpaper, the toilet shouldn’t disappear, too.” Users should be able to swap out themes whenever they want without losing their content, their custom data, or the additional functionality they have on their site. Remember, themes are meant for presentation, plugins are meant for functionality.
- Bad Practice: Whether the theme updates or not, whether the plugin updates or not … WordPress will eventually update. Limiting your client to a single version is, frankly, insulting and bad business. Instead of hard-coding a drop-in plugin, just make your theme play nice with provided hooks and encourage users to install the other system. If you’re using WordPress hooks (actions and filters) rather than direct function calls, you aren’t risking much in terms of stability. If a hook changes, the feature is just disabled as if the plugin weren’t installed.
Though there may be specific cases where including a plugin in our themes is needed. For example, a recent case where I was building a content platform for a network of sites that would use the same basic theme across each site. I needed a way to bundle these plugins with a theme. The plugins were the fantastic advanced custom fields using the options page, the main plugin and some addons such as the repeater field.
I bundled all the plugins within my theme using the TGM Plugin activation library. With this plugin we create a hook and use php require_once function to call our plugins.
Sources: Adding plugins to WordPress themes, Are drop-in plugins a product of design, TGM Plugin Activation, Advanced Custom Fields
Found a great little font “cheat sheet” I’m going to leave it here, else I’ll never remember where I found it!