I am adding programs to autostart by adding files to ~/.config/autostart and everything is working fine but I would like to know what some of the properties mean. When I google this I just see many examples of desktop entries. I am interested in a technical definition. Where is this defined?
I am interested in the general question, but for example what does the following do?
Hidden=true
NoDisplay=true
Here is the formal specification: http://standards.freedesktop.org/desktop-entry-spec/latest/
Hidden=true means to treat the desktop entry as if it had been deleted. NoDisplay=true means not to show the application in any menus, but still treat it as if it is installed, for example to associate a MIME type with it. Setting both at once seems to be redundant, or perhaps undefined.
Related
I want to create a workaround for the URL protocol file: in Chrome, as it's security doesn't allow you to open certain files or locations. This would be for a small app of mine that I designed.
I searched around, and while I've found a lot of potentially good answers (such as this answer), I don't fully understand what each line should do, and whether it would actually work in my application.
The end-result that I want for this is to have a protocol like ih-link: that would allow me to open up links in Windows Explorer or elsewhere, similar to how you can do so in say, Outlook or Microsoft Word (if you create local or network shortcuts to a folder or file, it'll open it up without issue). Attempting this in Google Chrome gives varied results, either a browser-generated directory, or an error ususally.
I'd like to know, assuming the answer I linked to would work for me...
Is "URL Protocol"="" where I'd define the name of the protocol, so I'd use "URL Protocol"="ih-link", or something like that? I remember reading something about leaving that blank, so would I replace IntranetFileLauncher with whatever protocol name I want (in this case, it'd be ih-link?)
The next part that references explorer.exe seems to just reference the icon.
After that, what do the following two lines do?
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell]
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell\open]
The last lines of that script appear to just have it strip the protocol from the URL and pass the file path to explorer.. am I correct on this? I take it I would need to format the path as I would do for windows (using \ instead of /)?
I'm afraid to experiment without knowing more, mainly because I know that many things with the registry can be very dicey, so any clarification on this would be helpful.
Reading the actual documentation is better than trying to guess what some random code sample does.
URL Protocol is just a marker, it does not need a value. The default value (#) is where the name of your protocol is stored.
Yes, that entry (incorrectly) specifies the icon.
Those two lines are pointless. They create two empty keys but only the ...\shell\open\command line is required to properly build that registry path.
Yes, you might have to change / to \, add: call set url=%url:/=\% to the command.
Using cmd.exe to parse untrusted input is not ideal, it would be better to write a custom application.
According to the documentation, the fourth parameter of FSEventStreamCreate (a function used to receive events about file changes) is "A CFArray of CFStringRefs, each specifying a path to a directory, ..." but I'm interested in changes to a specific file only. I know that I can pass the directory the file is in and then filter the events, which is what I've been doing up until now, but I have found out, that if I simply pass the file's entire path, it works perfectly fine (and allows me to simplify my code significantly).
So my question is, since I want to put this into production software, is this something I can rely on to work (e.g. in other versions of the OS), or is it a fluke? Is it documented somewhere to work this way? Does anyone else use it this way? My best guess is that the documentation is phrased like this because by default, only filesystem changes are reported, and the flag kFSEventStreamCreateFlagFileEvents has to be added to make it also report file content changes, but maybe I'm wrong.
The only thing Apple says about this is here
Request file-level notifications. Your stream will receive events about individual files in the hierarchy you're watching instead of only receiving directory level notifications.
Regarding other developers using this feature: yes, there are some.
You can probably leave a feedback on Apple, asking to improve the documentation, and maybe one day they will.
This is likely not a simple topic - I have researched this to the best of my abilities and realize that it is not supported in any typical fashion.
My goal is to enable something similar to .app files from OSX, where the application, as well as its user data, can exist in the same file. I imagine it would require writing a tool to manage this behaviour, but this question is more about how to achieve this in the Windows OS. I am quite flexible regarding the implementation details, but the more straightforward the behaviour, the better (i.e. avoiding copying or compressing/decompressing entire directories/archives at runtime would be ideal).
Approaches I have considered:
Find a way to get explorer to treat a directory as a file, so that it can be associated. I have found a way to get explorer to treat a directory as a control panel item, I have thus far been unable to find a way to use this to associate a custom program. See the infamous "godmode hack" for Windows (name a directory something to the effect of "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"). This one seems the most hopeful, but I'm at wits end trying to find information about creating a new association of this type.
Come up with some kind of archive format which can extract executable information to a temporary directory, launch this executable passing the archive as a commandline parameter. This seems like the ugliest solution, from a performance perspective. I would prefer a different solution if at all possible, one which doesn't involve making duplicates of the program or its data to run.
Find a way to associate a directory directly, though I have found no trace of this being supported in Windows, and I assume this is a dead-end.
Find a way to get an executable to include writeable embedded files. I have been unable to make any headway with this- I even tried a resource hacker approach, but obviously you cannot modify the assembly while its in use.
Tried to make a self-modifying JAR file with Java, but the route I took would add the JDK as a runtime requirement, which seems a bit overkill. Even then, it would be limited to Java, and I'm pretty sure it's not actually supposed to allow that in the first place.
Modify Windows Explorer. I shudder at the amount of work this would take, not to mention the at-best gray area it falls under legally. Perhaps there's a way to extend explorer to achieve this, I'm not sure.
A custom archive file. This seems like the most straightforward way to do it. But it would ideally need to be an archive format that has very little overhead for file I/O. Could even be some kind of virtual disk that gets mounted, but I am imagining that would be pretty heavy.
I would appreciate any insight that anyone has on this topic. I won't go into reasons as they are irrelevant to the question itself- I'm aware it is likely not the most practical solution to anything in particular. Consider it a novel pursuit.
It can be done by application virtualization,
Read this wikipedia page theory:
https://en.wikipedia.org/wiki/Portable_application
https://en.wikipedia.org/wiki/Application_virtualization
And two pages about software:
https://en.wikipedia.org/wiki/VMware_ThinApp
https://en.wikipedia.org/wiki/Turbo_(software)
Windows 7 added the ability for a Desktop.ini file to add/change the folder verbs on a per-folder basis. Using that trick it is possible to create a "folders as applications" style setup.
I want to build an application that displays the content that user types on the command prompt to the display like a presentation.
I am writing this application in golang. If there are existing libraries that I can use to do this great and if not would need direction how to approach solving this.
I did search on the internet for pointers but found none.
Have a look at the present tool, it does a similar thing using flat files and might even be useful for you.
https://godoc.org/golang.org/x/tools/present
So we recently shipped a document based application with an unfortunate oversight: the UTI for our main document type was left blank. We had a name for it, but the identifier was straight up empty.
Everything still worked great, but then we went to add another file type to the mix. The new file type is simply xml (conforms to public.xml). We set that up and dropped it into the document. This is when we caught our oversight on the first document type's UTI.
Now, if we so much as touch this document type, BOOM. The application can't read any files it has created of that type. We really want to clean this up, so what's the best way to do so?
My question is essentially:
How do you migrate your main document type in a document based application?
First, it's very difficult to debug this type of problem on the machine you're using to cut builds. The dynamic UTI system gets confused as to which app owns which files. To solve this issue, there is a command you can run in terminal to clear out the file associations on your system.
Next, we tackled the actual document types of our application. Ultimately, we want to support just two document types, our custom type and the xml type. However, we had to keep that empty, dynamically generated UTI that was shipped. In "Document types", we have three: the two we actually want to support and the legacy one we no longer want. For the first two, our application is an "Editor". For the legacy one, we changed it to "Reader".
Another thing that really helped our system out is using exported an imported UTIs. We told the system our application imports the XML type, and exports the two others.
We've done some pretty significant testing, including deployment, and this configuration works like a charm.