What's the difference between a project and a workspace in sublime? - sublimetext

I think both are doing the same! When should I use aworkspace and when a project, and what are the differences?

Projects in Sublime are contained in sublime-project files, and allow you to:
Control what folders are present in the project
Per folder control of what files and folders from within are rejected from the project or included in the project
Can contain settings that apply only to files open in that window
Can contain build systems that apply only from within that window
Persist the window layouts, open files, undo buffers, selected items in panels, and so on in an associated sublime-workspace file (or files; you can have more than one sublime-workspace associated with a particular project.
Workspaces in Sublime are are stored in sublime-workspace files, and:
Contain anonymous project data as in a sublime-project file, except that your only access is to the list of folders open; the ability to control the contents of them or to use project specific settings and build systems is not present. This information is considered Anonymous because it's not persisted to disk, and is not editable (except in adding or removing folders using menu items)
Persist the window layouts, Open files, undo buffers, selected items in panels, and so on.
A sublime-project always has one or more sublime-workspace files associated with it, whereas it is possible to have a sublime-workspace file that is not associated with a project if you desire.
Generally speaking, if you're working with source control (e.g. git), then you would include a sublime-project file in the repository but not a sublime-workspace file. This is because anything you do will modify the workspace file as well, making life painful when it comes to checking things in.
So, overall, the tradeoff between using Projects or just Workspaces revolves around what you're doing. If you're just opening folders and want to persist that window, but you don't have any need for the more advanced abilities that Projects provide, there's no reason to use them.

Related

Folder to an application

I apologize upfront for butchering the verbiage. Here is what I am trying to figure out.
I work with projects that currently use windows folders to store project files (500-1000) per project. The current interaction with a project is clicking through folders and opening individual files. There are also a lot of macros already in use in the various excel workbooks.
I would like to create a desktop "application" that stores files but also runs script, basically cleaning up the project interface and turning the project folder structure into a single desktop "object".
The "application" would open an interface (such as a vba user form) when double-clicked.
The "application" would contain the project files (excel, word, pdf, etc.)
The interface would be used to navigate through the contained files and update the various files in the "application" with user input data.
The "application" could be "cracked open" to see the files inside in windows explorer (similar to how .exe can be changed to .zip)
I've not been able to find anything that matches what I'm looking for so any that points me in the right direction would be greatly appreciated.

How do I save and load all files in a sublime text session as a 'project'?

I've read that you can save a ' project ' but apparently I'm doing it wrong.
What I've done is...
Create a js, html and css file and use view/layout with 3 columns so
each file has its own section of the layout.
I then went to Project / save project as / and saved the respective file in
a directory
I assumed that all files should be saved in this directory along with a file that I can click that loads them all up to reflect the workflow.
Apparently sublime has a different idea of how this should work and I do not understand it.
Essentially, there are two parts to a Sublime project - a .sublime-project file, and a .sublime-workspace file. Please see both the "unofficial" docs and the official website for information regarding projects, and the setup of .sublime-project files. These files are JSON-formatted and contain paths to any folders contained in your project, project-specific settings, and project-specific build systems. This file can (and should) be edited to customize the project to your needs. Double-clicking this file (after associating its file type with Sublime, following the procedure of your operating system) will open the project, any open files within it, and any folders you've added to it (by selecting Project -> Add Folder to Project).
The .sublime-workspace file is also JSON-formatted, but is saved automatically by Sublime and shouldn't be edited unless you really know what you're doing, and even then you probably shouldn't edit it. It contains all sorts of meta information about the project's history in Sublime, which files were open and in what order/pane, previous contents of searches, find/replace, etc., your file history, settings for various plugins like SublimeCodeIntel, and lots more. By default it is hidden when viewing the contents of folders in the Side Bar, and when double-clicked it will try to open the project instead of opening for viewing/editing, so there are several measures in place to prevent your playing with it and potentially screwing up Sublime.
.sublime-project files can be saved wherever you want, but the folders and files contained within it are not necessarily saved in the same place - they stay wherever they were saved. It usually makes sense to save them in the project's root directory, so if you have a filesystem like myhomedir/projects/web/SweetWebsite/ containing html/, js/, and css/ subdirectories, you might want to save your project as .../SweetWebsite/SweetWebsite.sublime-project, just so you know at a glance what files/folders are probably in it. However, you could save SweetWebsite.sublime-project in myhomedir/Desktop for all Sublime cares, and it would work exactly the same way. While it is possible to have unsaved files in a project, of course it's always best to save your work early and often, so you don't lose anything.
Hopefully this helps, please let me know if you have further questions.

How should I organize my Xcode project files?

I'm trying to wrap my head around Xcode's file organization - or lack there of. I can do all I want in project and it looks great with all the "fake" folders and structure. I go look at the file system and boom HUGE mess. I've tried importing files with the Create Folder Reference for any added folder option checked and that works, kinda. I get the structure I want both in Xcode and on the filesystem.
Issues: When I add a file to a folder on the filesystem that is a Folder Reference in Xcode, its not in Xcode when I go look, not even after reloading the project. Files/Subfolders in a Folder Reference can't be moved around in Xcode. When I move them on the filesystem I get red links (can't find the file?) in Xcode.
How do I keep a organized project and filesystem? How can I set up a project to just recognize a folder and show its (current and up-to-date) files and subfolders in my project?
Another issue I seem to run into, if I use a Folder Reference and change a file, the file is not updated in my application unless I do a full clean & rebuild. If I don't use a Folder Reference, all my files are dumped into the Resource folder of the application bundle, not in the nice structure I have in my project.
Should I care at all? Should I just use the fake folders and let everything go everywhere and not care? My application bundle will be a mess, the filesystem will be a mess, but it will all work... I would hope?
Edit:
My biggest reason for wanting an organized filesystem is that the resource files (images, sounds, other datafiles, etc.) are not edited in Xcode. I have to access them in 3rd party apps via the filesystem. If its a mess things are harder to find and maintain in the other 3rd party applications.
Also what happens if I want a structure like the following:
Images/Backgrounds/Name.png
Images/Icons/Name.png
Images/Titles/Name.png
Should I use long filenames rather than folders to organize?
Images_Backgrounds_Name.png
Images_Icons_Name.png
Images_Titles_Name.png
I also wish Xcode automatically kept itself and the file system in sync.
So much so, that I spent an hour doing so manually for a project called acani-iphone on GitHub. Basically, I just moved some of the files around using Finder, creating new folders as I pleased. Then, I switched back to Xcode and saw that the files I just moved were now red (because Xcode was thinking they're where I moved them from and so couldn't find them).
UPDATE: I just figured out that I could've then just clicked on the red group or file, pressed CMD+i (Get Info from the context menu, which you can open by right-clicking on the red file or group), and under the General tab, clicked Choose, then found where I moved the file to in the filesystem. But, I didn't do that, here's what I did instead, which also works:
Then, I just highlighted all the red files in Xcode and pressed command + delete to delete the broken (red) references. Then, I right-clicked on the Group I wanted to add the files to (usually the same group), and clicked Add > Existing Files.... Then, I found the same files in the new spot on the file system. I kept "Copy items into destination group's folder (if needed)" unchecked, I checked the radio button "Recursively create groups for any added folders," and I checked add to target acani if the files I was adding were being used to build the acani iPhone app.
I did the above with like a directory of files at a time. A few times I was more aggressive, adding multiple directories at a time, since I almost always selected the radio button "Recursively create groups for any added folders."
I found out that the files acani_Prefix.pch and acani-Info.plist had to stay in the root file system dir (although there may be settings you can set to allow these files to be elsewhere, like I think you can add a line to acani-Info.plist so that you can move/rename acani_Prefix.pch, but I'm fine with them in the root dir on the file system.
That was annoying to do, and perhaps not even worth the trouble, perhaps procrastination, but going forward, before adding existing files to Xcode, I'll first make sure they're in the place I want them to be on the file system.
OK, so here is how it works:
Xcode doesn't know about any files until you tell it about them. That is, even if you add a file manually in the finder (usually a bad idea) to a folder that contains files in an Xcode project, it doesn't know about them until you "add existing file to project".
The best practice (imo) for adding an existing file (or group of files) to a project (say, some code you just downloaded) is to choose "add existing files" and then "copy items to destination group's folder (if needed)" in the next dialog, if you want your project to have a copy of the files in question, rather than merely a reference to them (there are advantages and disadvantages of both).
Don't worry too much about the naming of folders in Xcode, or where you put things, but try to keep to a standard that makes sense in your environment. For example, I always put the classes I write in "Classes", and have separate folders for any library code i've downloaded for use in the project. I always put images/icons/audio etc in to "Resources".
In short, if you like what's in the project folder to be approximately the same as what's in your project, always add existing files by choosing the "copy items to destination group's folder"
The flexibility in XCode is intentional. It's up to you to decide how you like to organise things.
Should I care at all? Should I just use the fake folders and let
everything go everywhere and not care? My application bundle will be a
mess, the filesystem will be a mess, but it will all work... I would
hope?
IMO no... :) basically. The whole point is that XCode has been designed to give you the best experience of programming. If Apple wanted you to physically organise all your files and folders within the actual filesystem then they would have made it that way.
I don't really understand why you would want to organise all the files and folders in this way anyway? It makes no difference to the running of the application and the "fake" folders (groups) in XCode adequately provide the necessary visual aid for yourself (and others) to navigate through your classes and other resources. Organising it correctly in your filesystem (as you have found) surely just makes things more difficult?
Use Synx.
It rearranges your files on disk to match your Xcode groups. I try to run it before committing any code that changes the Xcode groups, and it keeps the project nice and tidy.
It would be great if Xcode could keep itself and the file system in sync. Unfortunately it doesn't. One reason for wanting it to is so the hierarchy in your SCCS matches the one in Xcode.
I fall back to keeping things organized in Xcode, and leaving the file system separated into not much more than "Classes" and "Resources".
This changed with Xcode 9. From the release notes:
Groups in the Project Navigator are now more closely associated with
directories in the file system. (28612132)
Dragging files between groups in the Project Navigator moves the files in the filesystem and updates any associated SCM working copies.
When a group is connected to folder in the filesystem, creating, renaming, and deleting groups updates the corresponding files and
folders in the the filesystem.
To remove a connection between a group and a folder in the filesystem, select the group, and then open the File inspector and
click on the on the Clear path button (X).
To add or update an association from a file or a folder in the filesystem to a file or a group in the project, select the file or
group, open the File inspector, and drag the corresponding file or
folder onto the Location section in the File inspector.
The new behaviour is available from the 'New Group with Folder' command (which may appear as just 'New Group'), while the old behaviour is available from the 'New Group without Folder' command (which may also appear as just 'New Group'!) The dominant usage amongst any existing groups in the target folder seems to determine which command gets labelled 'New Group'. It's more than a little confusing, but if you are in the habit of choosing one or the other, the idea seems to be that you can just stick with the default 'New Group' command. (See rob mayoff's far more thorough explanation.)
What I do is create a group to represent each folder and then, before adding files to it, in the right panel, first tab, immediately below "Path", there is an icon that allows you to choose the folder. In that folder dialog, I create a folder that matches the group and choose it.
In xcode3, this resulted in new and add files dialogs starting in this path. That made it worth the effort. Xcode4, however, does not respect this setting. Therefore, its questionable whether there is any real value in it. I also wish XCOde would support better file system organization.
Considering that file names must be unique within a project, regardless of groups and folders, there is justification for accepting the flat folder structure default and using groups for IDE convenience. Its difficult to come from other platforms where this is frowned upon.
i feel you and personally cannot NOT care about the actual structure and just rely on workspaces.
what would be really great is a tool that will go over the workspace structure and re-organize the file system accordingly, taking care of any re-naming of folders etc. this would be a classic solution and IMHO should be implemented as an option as we re-organize our project as we move about it.
some issues could be source control though xcode4 works with both git and SVN.

Xcode File management. What is best practice?

I've been using Xcode for a while now. One thing that always bugs me is the way it handles files. I like to have my files all in nested folders rather than one big physical folder, but when you create a group in Xcode by default it does not create a folder just a virtual folder within the project.
I can see that virtual folders are great for linking code in arbitrary places into your project but once you get beyond a few classes I find the one big folder approach really painful. And then if you try to fix it later it takes ages and is easy to break your build.
Is it possible to change this behaviour so that by default it creates a physical folder? Or am I doing it wrong and trying to cling to some other way of working? How do other people work with files in Xcode?
1) Remove all the files from the project. Select All and press Delete, and click the Delete File References button, not the Also Move to Trash one.
2) Go to the Finder or Terminal and rearrange your files in folders to your heart's content.
3) Select all the top-level files and folders and drag them back into your project. When given the choice, choose Create Groups for Added Folders.
You'll now have a group hierarchy that follows the directory hierarchy on disk.
You'll need to make sure all the proper files get back into their correct build phases and targets. It's best to do this one target at a time in a multi-target project.

Xcode organization in finder?

I have read all the suggested StackOverflow posts on this question. It bothers me that Xcode will not organize my files in the finder the same way it does in the editor view...it will only do that if I copy files in from an external source and specifically tell it how I want things organized. Is there a way to make Xcode have the Finder respect the same organization as a default? I'd love to create a directory and then a file in that directory, and see the changes in both places.
I hate opening a project and seeing ALL my files in one place.
If you want your Groups structure in Xcode to mirror your Directories structure in the file system (which is also the Folders structure in the Finder), you have to take the following steps when adding files that you want to go into Groups/Subdirectories:
Create the folder in the Finder (or the directory from the command line)
Drag that folder into your Xcode project. Import it as a Group. Make sure its reference style is Relative to Enclosing Group, and that you drop it into the Group that represents its parent directory.
To add new files, select the Group and choose Add Files. The files will be stored in the directory that that Group represents, and they will be within that Group in the Xcode UI.
If your files are not yet under SCM control, one thing you can do is just delete them all from the Xcode project, rearrange them on disk however you want, then drag all the folders and files back in, making sure to not make copies, to create groups, and to set the reference style to Relative to Enclosing Group.

Resources