I observe that .convert files look similar to .override files. Override files end with .gschema.override suffix. I believe that gsettings-data-convert or any other utility creates the .override files. I am looking forward to any link that can explain the complete conversion process.
GSettings vendor overrides and .convert files for gsettings-data-convert are very different.
Vendor overrides are used to allow OS vendors (for example, a particular Linux distribution) to override the default values of settings shipped by an application or part of the desktop, without having to patch the code for that application. They are used quite commonly.
.convert files were historically used to map GConf keys to GSettings schema keys, so that data stored in GConf could be migrated to GSettings/dconf without manual migration code having to be written. Now that GConf has been deprecated since 2011 and unmaintained since 2013, the need for .convert files has dropped off. There should not really be any applications left using GConf (if they are, they need to migrate away from it ASAP). Hence you wouldn’t normally ever need to use a .convert file any more.
Related
I share Sublime prefs between two machines (home, work) using Git.
My monitor at work has a higher DPI than my monitor at home, so in one of the two machines I'd like to override font_size.
I was hoping for:
The possibility to override using a command-line flag (to do something like subl --override-pref font_size=15), like kitty --override does.
Another level of prefs cascading below User.
, but I don't think any of this exists in Sublime. Language-specific config is not what I'm looking for, I want something global, but only in one of the two machines.
Ideas? Workarounds? Thanks.
The general mechanism at play for settings files is that when Sublime loads a sublime-settings file by name, it pulls all of the similarly named files across all of the known packages and combines them together (the same also happens for many other resource files) with content from later files overriding anything that appears in an earlier file.
The order that's imposed here is lexically by package, with Default always being first and User always being last. That's why the default settings are in the Default package and your custom settings are in the User package. Additionally syntax specific settings also apply (as do settings specific to projects).
Apart from this mechanism there's no direct way to override settings without some sort of manual intervention on your part. Potential solutions for this sort of problem include the following examples:
Don't sync the Preferences.sublime-settings file
If the file isn't synced across multiple machines, then this problem becomes moot because each machine can easily have it's own unique settings. The downside to that is that each machine then has it's own unique settings, which is a pain in the butt if you often move from machine to machine and things don't quite work the same way.
Use separate git branches
An alternative here if you're using git such as you are is to try and keep separate branches per host or per host type (like hi_dpi and reg_dpi or some such). Then on each machine check out the appropriate branch.
The obvious downsides here are having to try and cross-sync desired settings changes (for both User as well as any packages you might install) between branches, which is less than ideal unless you really love git.
Use extra Preferences.sublime-settings files
Here the idea is that you don't include the font_size setting in your User/Preferences.sublime-settings file at all. Instead, you use Browse Packages from the command palette to open the Packages folder, then create a new folder there with some arbitrary name. Inside of that folder include a Preferences.sublime-settings file that contains only the font_size setting.
Doing this on multiple machines, you can sync the settings in your User folder across machines without also syncing the preference that contains the font_size. As a note, if you create the file while Sublime is already running, you may need to quit and restart to get it to notice that the settings file exists; this only applies the one time, though.
Use a plugin
Looking at the link provided above, the ultimate trump card for any setting is a setting that's been applied directly to a view. Given that, you can use a plugin that selectively always applies a specific font size to any newly created or opened file:
import sublime
import sublime_plugin
import socket
class CustomFontListener(sublime_plugin.EventListener):
hostname = socket.gethostname()
def on_new(self, view):
if self.hostname in ("host1", "host1.example.com", "host2"):
view.settings().set("font_size", 20)
on_load = on_new
Now any time you open a file or create a new buffer, if the current hostname is in the list you've configured the view will immediately get an appropriate font_size applied; otherwise the one from the preferences would be used instead.
You could also extend this to be configurable via it's own settings file, apply a different font size depending on the host name, etc.
Settings in views are persisted in the sublime-session file and also in the workspace files associated with sublime-project files, so these settings will remain in place even across restarts.
Something to keep in mind is that the internal commands for changing the font size (via Preferences > Font or via the mouse wheel keyboard shortcuts) work by writing a new font_size to your user preferences.
If you're using separate preference files, then doing this will add font_size to your User settings and you will need to manually remove it and modify the other settings file.
If you're using the plugin, then these shortcuts won't seem to do anything because it applies a font_size that overrides the User preference, but in fact as outlined above your preferences file end up being changed and you may not notice right away.
So whichever way you go, if you tend to use those you may need to make manual adjustments to settings files in the aftermath. It's also possible to create smarter versions of those commands as well, if this is the sort of thing that happens often.
InnoSetup has the ignoreversion flag for items in the [Files] section to specify that the file should be copied regardless of its version information. This is kind of the default that I would expect from a setup most of the time, yet it is not the default behaviour if it is not set. So I see this flag set in most setups for every file item, executables and non-executables alike.
I'm wondering what the file types are for which this flag makes any difference? Obviously .exe and .dll are affected, and .txt is not. Is there some definitive guide on this? I'd like to get rid of these extra flags on my file items if they serve no purpose.
The general recommendation I always give is to absolutely always use ignoreversion on every file in {app}.
It causes no harm on files without resources (and potentially improves performance in that Inno doesn't have to waste time discovering that they lack resources), and is almost always what you want for app files (otherwise you can end up in some weird frankenstate with a mixture of files).
However for files installed outside of {app} (typically either {sys} or {cf}) you usually should not use ignoreversion and should instead only permit upgrades. But YMMV.
(Note that special care may need to be taken for ensuring upgrades of common files outside of {app}, as only EXE and DLL files typically have version information, and even some of those may lack it or it may not be updated consistently, depending on the source of the file. Other considerations also apply to common files, such as using sharedfile.)
(Promoted comment to answer.)
For which file types is the "ignoreversion" flag meaningful ?
For those that can have Windows resources. Version information reading in Inno Setup falls deep down to Windows API so it's actually the system which determines from which files the version information can be read. Currently, the About Version Information topic specifies the files, that can have version information briefly as:
You can add version information to any files that can have Windows
resources, such as DLLs, executable files, or .fon font files.
Which narrows the list of possible files to the list of files that may contain resources. Unfortunately, there is no (and cannot be) a list of extensions of files, that might contain resources, because you can have a file with version information having some exotic file extension (I've asked for it a long time ago).
So, there is no credible advice, for which files you should keep or remove this flag.
Is the "ignoreversion" flag really intended ? When should I use it ?
More it makes me wonder, why to include the ignoreversion flag. I would say it should be used rarely and carefully only there, where you are sure a possible downgrade of a certain file won't hurt. Without it, the Inno Setup compares version of the installed file with an existing one and replaces it when it's older, which is in my view the most wanted behavior.
The version flags refer to the version of your application installer package and not to the DLL version of a file shipped with the installer. Because of this .txt files also have a version and the 'ignoreversion' flag makes sense for any file within the installer package. It's up to the developer to trace and adjust the file updates between application versions using any of the InnoSetup provided flags.
I have a scenario where .egp's are created on Windows environment. As part of migration these need to be migrated to UNIX/Linux server and from EG 4.1 to 4.2 and we have to make the programs comply with LINUX/Unix standards (like font casing) and the directory paths to the linux or unix environment.
As we have around 300 .egp's to be migrarted, Say in the first go if we use migration wizard on sas eg 4.2 version to automatically have the .egp's converted to 4.2 standards, the bigggest question is how to incorporate changes to the sas programs.Is there any automated way to extract the program from respective node in .egp, edit and insert at the same node.
Thanks in advance.
If the code exists purely in EG, not that I'm aware of via SAS - EG is not itself programmable.
If the code objects are stored as physical files outside of EG they could conceivably be imported into EG (by looping over the folders involved) and some text substitution done.
Alternatively it involves a full on scripting language. EG files are zip files, and once uncompressed contain .sas text files in subfolders within the zip file. It should be possible to iterate over them all and make the required changes.
In neither case will it be much fun. (Though doing it manually doesn't sound great either.)
Talk to SAS - they may have a tool they've put together for someone else they can let you have.
Update: It appears that VS doesn't have the hooks needed to do what is needed in my use case. However there are a couple of options that could work for other people and as such I'm marking the question as answered but I would love to find a solution that works for me.
We have encrypted files that are routinely kept in encrypted form within source control (TFS). When I want to compare versions I use Beyond Compare and have added the encryption/decryption tool as filtering on the read/write process to allow plain text viewing and editing.
However if I just want to open the file for reading/editing it's a bit tedious using a dummy comparison just to view/edit the file.
As such as I wondering if there is a configuration setting or way in Visual Studio that would allow me to insert a filter on the read/write so that it could display/edit/save files that would otherwise be unreadable.
Edit:
*NB: The encryption aspect is just single use case *, I'm actually looking for a generic answer that doesn't require writing an editor to replace the editors within VS that already exist such as the MS supplied XML editor or the custom third party ones.
I have both custom and non custom files that are encrypted. Each file type already has an editor. We have no access to the source for any of these editors. The problem is that the file is encrypted in TFS, and all I need is the filtering on the read and write for all files regardless of editor.
I want to use all the existing features of the installed editors without change. Only the reading and writing need to be customised.
Here's a potentially hacky way to achieve what you are trying to do, if there is no other easy option.
TFS stores data in a SQL database. Therefore you can theoretically modify the read/edit command that is used to extract the data from TFS and send it to the editor/viewer. This might involve modifying a stored procedure, or putting a trigger in place to modify the data before it is presented to the editor.
You would need to run a Profiler Trace on the TFS database when you click on edit/view or browse to the node in the source control tree. This will help you to figure out what data TFS is accessing and what functions/stored procs/tables etc it used to extract said data.
The same in reverse; you'd need to modify the 'writing' of the data to use your custom tool before putting it in the DB.
SQL has the ability to call CLR code, so you could use your tool if it's written in .NET.
The easiest way would be to download the 2012 SDK, Microsoft already provide a nice walkthrough on how to implement your custom editor HERE.
The process is:
Install the SDK
Fire up VS2012; Select New Project -> Other Proj Types -> Visual Studio Package
Visual C#, company name, etc...
Tick the "Custom Editor" tickbox
Fill in the rest of the details
So now you're presented with all the source of a vanilla text editor, and the part you want to hook in to is the IPersistFileFormat::Load() and IPersistFileFormat::Save() functions found under EditorPane.cs and put your encryption/decryption routines in there, thus you'll be left with a text editor with a custom encrypted file format.
This may not do what you need, since you need to call third party exe. However this answer may be useful for others that have access to source code (or a dll or library).
You could write a file system filter that encrypts/ decrypts the data to and from disk. Note that the driver sits at the OS level, and is outside of Visual Studio.
From the MSDN article File Systems and File System Filter Drivers:
A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of File Systems and File System Filter Drivers include anti-virus filters, backup agents, and encryption products.
See this Code Project article for a tutorial: File System Filter Driver Tutorial. The article does not show how to do encryption/ decryption, but shows how to get a simple driver up and running.
There are extensions that will capture events to the current window save for example and what turns out to be document load. ** This is not a custom editor **
check out the following two links:
http://msdn.microsoft.com/en-us/library/dd885244.aspx
and a fairly complete open source addin that works with files when saved (regardless of type)
https://bitbucket.org/s_cadwallader/codemaid/src/7cf1bf6108801f48b85e30d85e1646fbc73ba889/CodeMaid/Integration/Events/RunningDocumentTableEventListener.cs?at=default
which hooks the RDT table to extend the current environment. You would need to adjust from here of course but this should get you going in the right direction.
My team lead just added a lot of binary files that shouldn't be in source control. I have to pick and choose my battles with him and this isn't one I think is worth bringing up, but I'd like to just ignore these files on my machine without affecting everyone elses. Is this possible?
We're using TortoiseSvn. I've honestly never used the command line so until I learn how to do that I would prefer a solution using the GUI. Thanks!
If all your files resides in a special directory, you could simply use the Add to ignore list from the shell-context menu.
From the settings/general tab you can also add global ignore patterns, based on extension.