Yesterday I tried updating from MATE 1.4 to MATE 1.6. I didn't like some things about it, and I decided to switch back, at least for now. One of the changes was a switch from the mateconf configuration system to GNOME 3's GSettings. As I understand this is a frontend to a system called dconf (or connected some other way).
This rendered many of my settings viod. I figured I could try to migrate them, but unlike gconf and mateconf, which created convenient folders in my home directory and filled them with XML I could edit or copy, I wasn't able to find any trace of dconf's settings storage.
A new Control Center is provided (and mandatory to install) but I don't want to be clicking through dozens of dialogs just to restore settings I already have. The Configuration Editor utility might be okay, but it only works with mateconf.
So what I want to know is where I can find the files created by dconf and how I can modify them directly, without relying on special tools.
I almost forgot that I asked this, until abo-abo commented on it. I now see that this is a SuperUser question, but for some reason I can't flag it. I would if I was able to.
The best solution I found was to install dconf-tools, which is like the old conf-editors.
As for the actual location of the data on disk, it seems to be stored in /var/etc/dconf as Gzipped text files, but I'm not entirely sure because I'm not using Mate 1.6 right now. I wouldn't advise editing them directly.
I've been having another issue with dconf, and I checked the folder that I mentioned above. It doesn't even exist. There now seems to be a single configuration file at ~/.config/dconf/[USERNAME]. It isn't in text format, so special tools are required to edit it.
This might be the result to an update to dconf.
I had a similar problem (was trying to back up keyboard custom shortcuts). The path for that was:
dconf dump /org/gnome/desktop/wm/keybindings/ > wm-keybindings.dconf.bak
dconf dump /org/gnome/settings-daemon/plugins/media-keys/ > media-keys-keybindings.dconf.bak
This thanks to redionb's answer on Reddit.
Related
Ive been looking on the the internet for answer but none comes close to what i was looking for. What is the folder for?
and inside is this json file:
What happen if i delete the folder and do i really need that to be in the folder? Thank you
Short answer:
If you delete it, probably nothing much bad will happen. It'll probably get created again. Your live server may or may not end up on the same port. Probably don't commit it to source control (but maybe you want to).
Longer answer:
.vscode as a folder name has a few clues:
the leading . kind of means "hide this folder". It comes from *nix operating systems where by default if you name a file or folder .anything it'll get hidden.
being called .vscode, which is the name of the editor you're using, suggests it relates specifically to using vscode.
The fact that it gets created when you "do something" suggests that it'll cope if it's not there, but probably the way it'll cope is to re-create it. That's a pretty common thing too.
One use for a settings.json file in a folder is for settings that are specific to that folder. Often you'd have settings that you want to apply to vscode wherever you're using it. But sometimes you have settings that apply to a specific bit of code.
The people that wrote the LiveServer extension seem to think that what port the live server runs on is one of those "per project" settings. I'd agree. You may want to run 2 or 3 live servers (e.g. a PHP web-site and another one that just does API, maybe), or the port that they chose might be in use by something completely else. So to deal with that, they create this settings file. I'd take a stab that if you edit that, then the LiveServer is going to show up on a different port.
But you can probably find the code and check it. Probably this document will tell you what to know.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
(A possibility here that I've chosen the wrong extension, but most vscode extensions are open source, so you should be able to follow the trail to a github repo, and then to either some docs or some code).
Editor settings are that border-line with source control - whether to check in or not. Lots of projects have defined editor settings, such as tabs vs spaces or linting engines. Lots don't. Possibly in this case, if you're part of a large project, the specific ports to use are defined, so it'd go into source control. If it's just you, do what feels good.
I'm using VS code (v1.74.3),Live Server (v5.7.9). There is no settings.json in .vscode folder of my JS project. Instead the settings.json is created in the folder "C:\Users\USER NAME\AppData\Roaming\Code\User" and it is a global settings file to specify extension properties. Most of the Live Server configuration settings mentioned in the documentation can be applied at global level.
I attempting to edit Windows Terminal's JSON config file:
When I save, the document is minified:
I only have two extensions (I have removed others and restarted vscode). How do I find out where the minification is occuring? How do I stop it?
This is a bug in Windows Terminal. It's now fixed in the current Preview release. Mike Griese from Microsoft answered this via GitHub:
The profiles.json thing is a temporary thing. Unfortunately, Windows.Data.Json always writes out json as a single line, without the ability to pretty-print it, and we re-write the profiles.json to make sure that it stays up to date with the schema of the app. So currently, it'll keep re-writing it. But that's a huge pain point that we want to fix ASAP.
I'm considering to move one of the company internal wikis (very basic wiki with few/no extensions and not so many pages) to another machine and wondering if at the same time I can upgrade the mediawiki version, passing from 1.6 to the current latest 1.25 (in order to use extensions only available for the latest versions)
The Upgrade guide
https://www.mediawiki.org/wiki/Manual:Upgrading
seems to omit the scenario in which an upgrade of the underlying software (apache,mysql) is also required for setting up the target version.
and the Moving guide
https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
strictly recommends that source and target wikis share the same software level.
So I'm a bit stuck. I would attempt an export/import of an xml dump, but I'm not confident for the above reason (there is a huge version gap in source and target wikis)
Or is there a better way to approach the problem? Thx
Edit after some tests
I consider Florian's answer the most safe and advisable, but I would share the final solution I came up with.
Install the new wiki (blank)
Export an xml dump of the original wiki
php maintenance\dumpBackup.php --full > dump.xml
I first encountered a "Cannot connect to database" error. So i had to add in the LocalSettings.php the lines
$wgDBadminuser=...
$wgDBadminpassword=...
Import the xml dump in the new wiki (first try in dry-run mode)
php maintenance\importDump.php --dry-run < dump.xml
php maintenance\importDump.php < dump.xml
Then I was prompted to run
php maintenance\rebuildrecentchanges.php
Copy the physical files from the old to the new wiki, in the same path(for common wikis they should be in the "images" folder. That was not my case).
Re-create the users (manually) in the new wiki
Last edited the LocalSettings.php with the most essential settings I wanted to preserve (groups, restrictions,...) .
And the moving was done! The new wiki is ok and already usable at this stage: pages are there, links are working..
In fact, it should work, if you move the wiki from one server to another and after that upgrade it on the new server. Like you may already know, it's important to backup all files and data you have for the wiki in the "old" environment, so you can easily restore it from there.
If I would want to do, what you want to do, I would first follow the "Moving a wiki" guide except the "Test" section. After that I would upgrade the wiki to the newest version. Now I can test the wiki intensively to see, if anything worked well.
If you don't want to do that, you really need to upgrade the wiki in the "old" source and move it after that. If I understand you correctly, that would require an update of the server software (I expect php and mysql?).
I am using PhpStorm for few months now and I have just noticed something really weird about language injections in the version 9.0.
Sometimes I have to declare that some strings in my PHP are Javascript instructions. When I do so and save my file (with auto-upload on), it looks like PhpStorm is doing a lot of remote checks, file moves and transfers, I dont really understand why... and I'm afraid that it may overwrite files that I didn't modifie. I'm working directly on a production server with other people, I know it's dangerous but we have no choice for the moment.
In the file transfer logs, I have something like that :
[18/09/2015 10:47] Automatic upload completed in less than a minute: 2 items deleted, 50 items moved, 4 files transferred (4 Kb/s)
Can someone help understand what is going on ?
I have found a way to do what I want, but didn't find the reason of theses uploads that PhpStorm does without asking anything...
The problem is that, until now, I didn't found a way to save files one by one. It looks like PhpStorm has only a "Save all" option that uploads every files changed since last save (if you ask for auto-upload). And in the case of a language injection PhpStorm seems to change a something in the opened files that forces it re-upload them all.
So I disabled auto-upload and bound a shortcut to "Upload to default server". This option uploads only your current file but it saves it before. So it's a kind of auto-upload but a little less agressive and it gives me the possibility to just save my files (with "save all") or to save only the current one and upload it instantly.
This is the way I used to work before using PhpStorm, I find it more convenient and less violent than this automatic upload process that Phpstorm uses.
If someones find something better I'm opened to any advice.
Since MathWorks release a new version of MATLAB every six months, it's a bit of hassle having to set up the latest version each time. What I'd like is an automatic way of configuring MATLAB, to save wasting time on administrative hassle. The sorts of things I usually do when I get a new version are:
Add commonly used directories to the path.
Create some toolbar shortcuts.
Change some GUI preferences.
The first task is easy to accomplish programmatically with addpath and savepath. The next two are not so simple.
Details of shortcuts are stored in the file 'shortcuts.xml' in the folder given by prefdir. My best idea so far is to use one of the XML toolboxes in the MATLAB Central File Exchange to read in this file, add some shortcut details and write them back to file. This seems like quite a lot of effort, and that usually means I've missed an existing utility function. Is there an easier way of (programmatically) adding shortcuts?
Changing the GUI preferences seems even trickier. preferences just opens the GUI preference editor (equivalent to File -> Preferences); setpref doesn't seems to cover GUI options.
The GUI preferences are stored in matlab.prf (again in prefdir); this time in traditional name=value config style. I could try overwriting values in this directly, but it isn't always clear what each line does, or how much the names differ between releases, or how broken MATLAB will be if this file contains dodgy values. I realise that this is a long shot, but are the contents of matlab.prf documented anywhere? Or is there a better way of configuring the GUI?
For extra credit, how do you set up your copy of MATLAB? Are there any other tweaks I've missed, that it is possible to alter via a script?
shortcuts - read here and here
preferences - read http://undocumentedmatlab.com/blog/changing-system-preferences-programmatically/
At the moment, I'm not using scripts, though this sounds like a very interesting idea.
Unless there are new features that you also want to configure, you can simply copy-paste the old preferences into the new prefdir. I guess this should be doable programmatically, though you might have to select the old prefdir via uigetdir. So far, this has not created major problems for me. Note also that in case of a major change in the structure of preferences, any programmatic version would have to be rewritten as well.
I'm adding paths at each startup, so that I don't need to think of manually adding new directories every time I change something in my code base (and I don't want to have to update directory structures for each user). Thus, I also need to copy-paste startup.m for each installation.
If I had to do everything manually, I'd also want to change the autosave options to store the files in an autosave directory. If I recall correctly, Matlab reads the colors and fonts from previous installations, so I don't have to do that.