According to https://github.com/mintty/mintty/issues/944 since mintty 3.5.1 there should be a tab bar where you can open multiple tabs with terminals in parallel. For that reason I performed an installation of MSYS2 which includes mintty 3.5.1, as this seems to be the way how to use the mintty. (I verified this with invoking mintty with -V.)
However, I do not find no possibility for opening and/or managing tabs in the UI.
My requirement: I would very much like to have tabs for organizing terminals in parallel.
My question: What's going on here? Did I miss something? Do I need to execute the mintty/MSYS2 with some special commad line options? How can I enable tabs?
You could use --tabbar option when staring minnty. see here for more information.
It was difficult for me to figure out how to turn this feature on. The answer is sprinkled through the comments of this issue, but not in one place. Therefore I'm posting this to save time for others. Here's how you turn the feature on:
Add --tabbar=4 or --tabbar to the windows shortcut that opens mintty:
The 4 is documented here:
no geometry handling; terminal session windows are separate [default]
sync. position/size when switching/launching/closing a session
sync. also when window is moved or resized
sync. also when window is minimized
sync. also when window is started separately
If you'd like to create new tabs with ctrl-shift-t, close tabs with ctrl-shift-w, switch to previous tabs with ctrl-shift-tab, and switch to next tabs with ctrl-tab, add -o "KeyFunctions=t:new-window-cwd;w:close" as an option to that same line.
Personally, I'd like to have ctrl-t/w open and close tabs, respectively, but the only way I've figured how to do that is to add this option: -o CtrlExchangeShift=yes. The problem is, that changes all ctrl-shift commands to become ctrl commands. That means ctrl-r no longer searches bash history.
When you run the shortcut and create some tabs, mintty will look like this:
Is there a way to use PhantomJS's command line options programmatically?
Perhaps even from CasperJS?
I doesn't make sense to change the value for most of the commandline options programmatically. For example, why would changing the cookies file or the disk cache option be a good idea during script execution?
Others can be set in the settings such as the loadImages and webSecurityEnabled options.
A special case is the phantom.setProxy function which was merged into the master branch, but as of 1.9.8 not yet released. You will have to wait for PhantomJS 2.x to use it (or compile the source right now).
Some settings in Dymola can be altered by setting flags in the "Commands" window:
Some examples for flags are:
Advanced.AutoFormatting
Advanced.PedanticModelica
Advanced.LogStartValuesForIterationVariables
Hidden.PrintFailureToDifferentiate
Is there a comprehensive list of all Dymola flags?
Or, even better, a command to print such a list?
Or, even better, something like the about:config in Firefox?
Especially, I would like to change the default setting for the Save contents in one file checkbox to Directories - No Questions because version control software (git in my case) works better with many small files.
The Save contents in one file checkbox cannot be changed by flags, but by (un)commenting the line Dymola5StoreOnOneFile 0 in the file $Dymola$\insert\dymodraw.ini.
But many other settings can be changed using flags. Use list() to print a list of flags (unfortunately, Hidden. flags are not included in that list) or use help() to get more help.
Update
In recent Dymola versions there is user dialog with filter function for all flags. You can find it at
Tools → Options → Variables.
Since Dymola 2018 (and may be an earlier versions) there is a flag called Advanced.DefaultStoreAsOneFile. Setting to false will enable to save packages as directories.
This flag can be set via GUI as well, see Edit > Options..., and in the pop-up window, the Tab Version, uncheck As default store packages as one file. In this way, the setting will be saved in your setup.dymx (setup.mos in former Dymola versions) file and will thus not affect the Dymola for other users. You can also find some more flags in that file.
But I would suggest to split this question into two ones since there are two topics treated in just one thread.
In xcode 4.5 how do I select different target settings for different builds for example one target setting for debug, one target setting for release etc, so I can define different icons depending on the build etc.
You have two options, neither perfect. I'm going to focus on the concrete example of using different icons depending on your build configuration, as you suggest, though both techniques can be applied more broadly.
Redirect in your Info.plist
This is the simplest way. Specify your "Icon file" property in your target's Info.plist as e.g. "Icon-${CONFIGURATION}". Then, create two ICNS icons, "Icon-Release.icns" and "Icon-Debug.icns", and add them to your project. That's it. The downside with this approach is that both icons will be copied into your built app every time, rather than just the one it needs.
Use a "Run Script" build phase
This is a little more involved but it gives you a better result. Add a Run Script build phase to your target, with the following script:
cp "$(dirname "${PRODUCT_SETTINGS_PATH}")/Icon-${CONFIGURATION}.icns" "${SCRIPT_OUTPUT_FILE_0}"
Specify its output file as:
$(TARGET_BUILD_DIR)/$(UNLOCALIZED_RESOURCES_FOLDER_PATH)/Icon.icns
And make sure your "Icon file" property in your Info.plist is set to just "Icon".
This relies on your icons sitting in the same folder as your Info.plist within your source tree (though you can edit the script however you like to suit your project's configuration).
Note also that with this approach Xcode won't be able to see that you have the icon set correctly, so for example in the "Summary" tab of your target's settings it'll still show the question mark placeholder for the icon. You'll need to do an actual build to verify it's working.
My solution is pretty close from Wade's first point, you can also add an dynamic suffix using a user-defined settings in you project configuration.
I use this solution to dynamize the icon, the bundle display name and also the bundle identifier of my build to be able to use the version from the app store beside my development version.
There are several words with similar (in some sense) meaning:
Options, Settings, Properties, Configuration, Preferences
English is not my native language. Could you explain the difference in simple English please? I think the following template could be useful:
Use XXX in your GUI in order to let people change behaviour of your application (maybe preferences or settings?)
Use YYY in your GUI in order to let people change parts of an object (perhaps properties or options?)
Use ZZZ in your code ...
What are best practices?
Tricky, this, as there's no one single consistent style followed by all applications. As you say they are (broadly) synonyms.
In truth it doesn't really matter so long as your expected audience understands what you mean.
The biggest difference is between Properties, which usually affect a component or object, and the others, which affect the whole application.
Following an approximate lead from Visual Studio and other Microsoft products:
Properties represent the characteristics of a single component or object in the application.
Options alter global ways that the application works. Microsoft products use this to customise the UI toolbar, for example. There's an implication here that you can disable UI elements altogether (e.g. a "Simple" user interface or an "Advanced" user interface).
Settings and Preferences change qualities of how the application works. The implication here is to change, not disable: for example, "Metric measurements" or "British Imperial measurements".
Configuration is often where an application is customised for each user or group.
But there's no single rule.
I'd suggest you use Properties for object characteristics and Settings for everything else that's application-wide.
These aren't set anywhere, but I figured I might as well chip in my 2¢ on the topic. When I see these in an application, this is what they imply to me:
Settings: "View or modify the list of things that can be set"
Options: "We have set some things already, and give you the option to change them"
Preferences: "Tell us how you prefer this to work"
Properties: "Change one or more properties of this item"
Edit: "This thing is already in a good state, but you can change it if you like"
Configuration: "We have defaults, but they're so barebones you probably want to configure it yourself"
I just did a quick scan and wanted to post this list for reference.
Edge Settings
Google Chrome Settings
Google Chrome DevTools Settings > Preferences
Mozilla FireFox Options (about:preferences) > Network Settings
Mozilla FireFox DevTools Settings > Editor Preferences
Opera Settings
DeviantArt Settings
Facebook Settings, News Feed Preferences
GitHub Settings
Google Settings
IMDb Account Settings > Preferences
Instagram Options (aria-label)
JSFiddle Settings
StackOverflow Settings > Preferences
Twitter Settings
YouTube Settings
FileZilla Edit > Settings
GitHub File > Options
Notepad++ Settings > Preferences
VS Code Preferences > Settings
Audacity Preferences
IcoFx Options > Preferences > Options
Process Explorer Options
TeamViewer Tools > Options
uTorrent Options > Preferences
Windows Media Player Tools/Organize > Options
phpmyadmin Settings
XAMPP Config > Service and Port Settings
> Log Options
MS Word File > Options > Proofing > AutoCorrect Options
> Writing Style Settings
Photoshop Edit > Color Settings
Edit > Preferences
Type > Language Options
3D > 3D Print Settings
Viev > 32-bit Preview Options
Window > Options
Windows Settings
Used as the parent (window/choice):
Settings : 20 times
Options : 10 times
Preferences : 4 times
Config(uration) : 1 time
Total mentions:
Settings : 24
Options : 15
Preferences : 12
Config(uration) : 1
Based on this, I'd sort these in this order (from general/fixed/app-related to specific/dynamic/user-related):
Settings > Options > Preferences
I think that one point of view is missing here namely the relation between configuration/settings/options/preferences.
To me a configuration or preferences contain many settings or options so there can be one setting or one option.
You usually say "Change this option/setting" and not "Change this preference/configuration", don't you?
When someone says preferences or configuration I understand it as a set of settings or options.
One thing that I don't see in the answers here (although bobince alludes to it) is that you should consider what is typical for your environment/operating system. For instance on windows I think "Options" is the most common choice even though many programs use different words. Likewise "Preferences" for mac os. Android OS uses "Settings"
So bottom line, use what is most common for your environment.
I believe it's largely a matter of personal preference.
However, I feel that I usually see properties as referencing one single part of an appliation, where as Options/Settings are usually a more global property.
In addition, Preferences are probably not things that have as large of an impact as something labeled options or settings. Things such as a minor change in the display or something similar.
The most important thing is to have consistency across the application.
And personally, I prefer the term 'options', as it sounds less intimidating than settings, properties, or configuration.
Apart from Properties (which usually applies to a document or object inside a document, except when it doesn't), they're pretty much all the same. No-one agrees which terminology is best.
For example for program config, Apple style is ‘Preferences’ in the application menu, GNOME style is ‘Preferences’ on the ‘Edit’ menu. KDE style is a whole ‘Settings’ menu of its own. Windows style was ‘Options’ on the ‘Tools’ menu, though all bets are off now as more MS apps drop the menu bar and throw the old predictable controls all over the place with no consistent pettern.
RISC OS style was ‘Choices’ on the icon bar menu, just to add yet another pointless possibility.
Options: usually for components or objects. You have right to choose, so there're some options for you to choose.
Settings: There's a system. It may work as it always do, but it offers some settings for you to adjust its behaviors.
Properties: every object has properties. color, size, and etc. You 'set' settings. and you 'change' object's properties.
Configuration: usually, every system has its configurations, either a default one or a customized one. The system needs a proper configuration in order to run properly. Usually, it has little meaning of user's choice or not. Although you can adjust system's behavior with different configurations.
Preferences: you may prefer a different habit, so here comes the prefer-ences. Every user may have their own habits. Preferences is more like different users sets of prefers. In system level, it may work via different configurations, but on the GUI, we don't say configuration, we say preferences.
In conclusion, for example, in a drawing application, you may say, we change the properties of a circle, a shape. When you start the application, we have three options to choose for how the application would appear after launch. There are some configuration files under the installation folder, some may easy to understand, but some may be very technical, which is not prepared for normal users. Users they just change settings in the menu, to decide how a function works in the application. Settings and Preferences usually don't appear in the same application. Tools that more for efficiency, use Settings more. Applications that more for conveniency, use Preferences would be more friendly for users.
Hope those help.
Settings: Thinking of a slider to select a value from 1 to 10 for example
Options: Thinking of an on/off button
Preferences: Thinking of a choice from multiple choices, like morning, afternoon or evening
Configuration: Technical settings probably end users should not know about. Like what is the data source?