I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
Related
The title tells it all:
Does breezy fully replace bzr, at least in msys2?
E.g., by aliasing.
I found little info on this:
https://github.com/NixOS/nixpkgs/issues/80740
Yes, Breezy is a full replacement for Bazaar. It's derived from the Bazaar codebase, and compatible with the Bazaar command-line interface.
There are a large number of changes to the internal API, but unless you use third-party plugins or use scripts that use the bzrlib API, that should not be relevant to you.
We've also dropped support for a number of older platforms (e.g. Windows '95 and '98). I don't think msys2 was ever explicitly supported as a platform, but we're happy to help fix any issues you may run into. See https://www.breezy-vcs.org/pages/support.html for ways to reach out to us.
You can read more about the rationale for the fork here:
https://lists.ubuntu.com/archives/bazaar/2017q2/076170.html
https://www.jelmer.uk/breezy-intro.html
I'm writing a command-line utility in Go that (as part of its operation) needs to get a password from the user. There's a great gopass module for Unix that does this, and I know how to write one for the Windows console. The problem is that the Windows module obviously won't build on *nix, and the *nix version won't build on Windows. Since Go lacks any preprocessor support (as far as I can tell), I have absolutely no idea what the right way to approach this is. I know it's possible, since Go itself must do this for its own libraries, but the tooling I'm used to (conditional imports/preprocessors/etc.) seems to be missing.
Go has build constraints, which can either be specified as comments in a .go file, or as part of the file name.
One set of constraints is for target operating system, so you can have one file for Windows, one for e.g. Linux and implement the same function in two different ways in the two.
More information on build constraints are at http://golang.org/pkg/go/build/#hdr-Build_Constraints
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...
I am installing an major upgrade of product in my system.
Folders and registry entries will be updated for this.
I would like to take snapshot of folder structure and registry before/after installing update so that i can compare them easily.
Is there any tool or simple powershell module available to do this?
I hope testers would have done this while doing installation testing. If you have followed any good approach ,please update us.
One of the best tools I've come across for before/after registry comparisons is called RegShot:
http://portableapps.com/apps/utilities/regshot_portable
The 1.8.3 version supports 64 bit registries:
http://sourceforge.net/projects/regshot/
Yet another tool is called ZSoft Uninstaller:
http://portableapps.com/apps/utilities/zsoft_uninstaller_portable
This one is tailored toward software installation analysis.
Both of these can perform registry and file system before/after comparisons.
Well, practically, I think you'll have to limit the paths you want to "monitor". You can use the PowerShell provider for registry very easily. For example:
Get-ChildItem -Path HKCU:\SOFTWARE -recurse | Out-File HKCU_Software.reg
More information here. Then, you can make a diff (before, after) using a tool like DiffMerge. Same principles for directories.
However, once again, beside a shallow check, I don't think that approach is realistic.
Don't know your context, but Microsoft's Attack Surface Analyzer might be useful.
I recommend RegistryChangesView by NirSoft.
It could be particularly good for you as you mentioned PowerShell modules in your question, and RegistryChangesView has documented command-line options. RegistryChangesView also supports exporting the comparison to a .reg, HTML, or CSV file etc.
I'm still looking for a tool that can directly output the difference in the form of PowerShell commands; until then, I can export to a .reg file and then run it through a .reg-to-PowerShell-commands converter.
Other options include the classic Regshot which has also been forked as Regshot Advanced. However, personally, I go with RegistryChangesView because I think it has better documentation/command-line options.
I have installed both the GNAT Programming Studio (GPS) and GtkAda. They both seem to work fine, but when I try to build the Simple Window project under New Project from Template, I get a bunch of errors saying "file gtk.ads not found." This seems to be a directory/dependency sort of problem - GPS doesn't know where to look for GtkAda. I'm running Windows 7, and have GPS installed at C:\GNAT\2011, and GtkAda installed at C:\GtkAda. I tried adding GtkAda to my PATH; at the moment my PATH user variable includes C:\GNAT\2011\bin, and my Path System variable includes C:\GtkAda\bin. Any advice on resolving this problem is greatly appreciated!
There are two things here.
First, "project" is key. Whenever you're building something that depends
on a library like GtkAda, it's much much easier if (a) you use GNAT
Project to manage it, and (b) you use the GPR(s) provided by the library
- always assuming it does, of course.
In the case of GtkAda, that means that your GPR needs to "with" GtkAda;
with "gtkada";
project Tinkering is
...
Second, gnatmake or gprbuild needs to be able to find gtkada.gpr.
The easiest way is to install GtkAda in such a way that gtkada.gpr is in
the default place that gnatmake/gprbuild expect to find GPR files. This
is $prefix/lib/gnat. GtkAda obeys this convention, so you could install
GtkAda under the same root as your compiler. I don't know why that's not recommended anyway.
If you don't want to do that, you can add the correct location to the
environment variable ADA_PROJECT_PATH, for example in your case set it
to C:\GtkAda\lib\gnat.
There is a lot of good stuff in the GtkAda README at libre.adacore.com, and in
the GtkAda User's Guide which I see from the README is also included with the
installed package at (in your case) C:\GtkAda\doc\GtkAda\gtkada_ug.