Now with Sublime Text 3 and a year on from an older question, I'd like to bring this up again.
Is it possible to setup a Sublime Text project with network paths to folder resources that can be used on Mac(OSX) and Windows platforms.
We have projects which are already created in a windows dominant environment. We are looking to have these working in OSX as well. At the moment a path for a project resource would be mapped to a windows network drive for example Z. The folder setup in the project would look like this:
"path" : "/Z/Custom/Project1"
If I was to create a network mount on OSX and drag the same folder in, it might look like this for Mac:
"path" : "/Volumes/ENV/Custom/Project1"
Is there a way to get this working for both platforms specifically using absolute network paths as the project files do not exist in the same location, so relative would not be a solution here.
Network paths are simply handled differently on Windows vs. OS X. A Windows path might look like:
//server/path/to/file
or, if the server is mounted as a drive:
/R/path/to/file
whereas on OS X all network shares are mounted through /Volumes:
/Volumes/server/path/to/file
As I see it, you have two options. The first is the most obvious: separate .sublime-project files for Windows and OS X. However, depending on the complexity of your projects, this option may take some effort to keep both files in sync.
The second option is to just have both paths in the "folders" section:
"folders":
[
{
"path": "/Z/Custom/Project1"
},
{
"path": "/Volumes/ENV/Custom/Project1"
}
],
You'll have two Project1 folders show up in the side bar, but only one will expand - Sublime gracefully handles the fact that one path doesn't exist. The major issue with this solution is that you may have other project-specific settings that are platform-dependent. For example, I use the Anaconda plugin for Python that provides code completion, linting, and other features. A couple of its settings require the path to the Python interpreter you wish to use for each project, and these paths can be platform-specific, especially if you are using virtual environments.
I suppose there is a third option as well: write a custom Sublime plugin that runs on startup to determine the platform, then generate a .sublime-project file with the platform-specific settings. That would be a non-trivial amount of work and wouldn't allow for multiple users to share the same project file simultaneously (you'd have to store the generated file locally). However, depending on your priorities, it may actually be the best option.
Related
I'm creating "JSON fragment extensions" for Windows Terminal in my code, to create some "auto-generated" Windows Terminal profiles.
In the official docs, JSON fragment extensions in Windows Terminal, there are 2 locations recommended for storing fragments (if your application is not a Microsoft Store app):
For applications installed from the web, there are 2 cases.
The first is that the installation is for all the users on the system. In this case, the JSON files should be added to the folder:
C:\ProgramData\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
In the second case, the installation is only for the current user. In this case, the JSON files should be added to the folder:
C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
This seems straightforward enough, but there's some other documentation that describes the actual settings.json file location:
The path for your Windows Terminal settings.json file may be found in one of the following directories:
Terminal (stable / general release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json
Terminal (preview release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json
Terminal (unpackaged: Scoop, Chocolately, etc): %LOCALAPPDATA%\Microsoft\Windows Terminal\settings.json
So, to be clear, these paths are not important if I'm creating profile fragment files, right? I don't need to choose a different path (%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe vs %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe vs %LOCALAPPDATA%\Microsoft\Windows Terminal) for the Fragments files because Fragments will always be loaded from C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments etc?
Disclaimer: I work for Microsoft.
So, to be clear, these paths are not important if I'm creating profile fragment files, right?
Correct! The locations Terminal looks for fragment files are well-defined and durable across different versions.
I'm new to developing Mac OSX apps via Delphi (Berlin) and don't know where to put resource files. In Windows I can write ImageControl1.LoadFromFile('aFile.png'); and know that's referencing the directory where my executable is located. Or I can do something like make and reference the path to a separate directory where I'm putting resources.
But I don't know where to put resources or how their paths work when developing on a Windows machine for an app that'll be compiled and run on a Mac. I tried putting an image file in the Delphi project's OSX subdirectory as well as entering a complete path, i.e., LoadFromFile('path/goes/here'). I also tried using forward and backward slashes in the path name expression. In each case I got an error (when compiling for Mac, not Windows). I'm sort of thinking the files should live on the Mac somewhere...but I'm lost.
I'm hoping someone could tell me where to put these kinds of resource files, or how to properly reference them, when developing Mac apps on a Windows machine (or, alternatively, a good reference or two that'll explain it to me ... I looked online but couldn't find an answer).
There's some info about the structure of macOS app bundles, here:
https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19
In the Delphi Deployment Manager, resources can be deployed to a remote path of:
Contents\Resources\
And subfolders thereof. The following code should return the root of the .app package:
NSStrToStr(TNSBundle.Wrap(TNSBundle.OCClass.mainBundle).bundlePath)
Add /Contents/Resources (and applicable subfolders) to that path, and you can load the deployed files from there
I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
I am wanting to setup a project and potentially an existing project to be SVN version controlled. I am using uberSVN for the svn server. I have installed AnkhSVN for visual studio.
Currently, the team I am working with is using visual source safe and one of the problems we have is when someone adds a reference to a DLL, it modifies the project file as you would expect, but our paths are different between different team members (XP boxes, 7, you get the idea). What I was wanting is making the project file ignored when checking in/out so that we don't mess up the references for everyone else.
Is there a way I can make SVN ignore these files within the plugin? One of the side effects of this is a person would not know if a new file has been added in the project as this modifies the project file. Other than telling everyone "hey, you need to manually add this file to your project," is there a cleaner way of doing it?
If you copy the DLL to a folder inside your VS solution folder before linking to it, I think the project link will be relative not absolute. So you can check the DLL and the updated VS project into your configuration management and everyone should be able to share it.
You should start using virtual paths for development work; that way each team member can keep work-related files at any physical location but the virtual path (the one seen by tools is always the same.
For example, my team does all work under Q:\. My physical source for work is under physical path C:\Work\<project_name> where the project_name part depends on the project. When I want to work on a given project, I map the Q:\ virtual path to the right physical path using
subst q: c:\work\project_name
When I need to switch, I run a similar command. This way there's no need to worry about different paths on different computers. This worked very well for the whole team and eliminated most issues you describe above. The only thing you need to make sure is that everyone always uses the virtual path (Q:), not the physical path when dealing with project-related files. For my team it took about a week to get used to that, after that there were no more problems.
Your project file is an important part of your project so ignoring it in the source control tool will eventually lead to problems. I recommend you don't do it (even if you can).
Edit:
If you have DLL-s in different physical folders on different machines, the best choice is to copy those DLL-s (and their dependencies) to a known location. It's fine that they can't run from there, as long as the compiler finds them.
This known location could be inside your virtual path or a common physical path (if the same DLL-s are needed for multiple projects). You can use Dependency Walker to determine what dependencies you need for native DLL-s and Reflector for .NET DLL-s.
If the size/number of DLL-s is so large that creating a copy is not an option, you can actually tell AnkhSVN to ignore certain versioned files when committing changes. Right-click the file, select Subversion > Move to Change List > ignore-on-commit. After this the file will show up in the commit dialog unselected but you can still commit it if you manually select it.
We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.