Hype Resource Files Location

1

Hey guys! So, I noticed that when I create a project in hype, hype automatically creates a hidden folder in which my resource files are saved and referenced. I am wondering where this folder is typically located because sometimes it is inconvenient to have to go digging for my files, especially if I want to compress them at a later time. Also, would it be possible to have a preference menu option for where these files are saved? Or maybe it would be helpful to be able to turn this function on or off. I am concerned that these resource files might be cluttering my hard drive. I just feel as though it is easier to keep the files organized myself. Why does hype create a separate folder of files to reference after I create my project?

Any help our knowledge would be appreciated! Thank you.

-David

2

When you add a file to Hype, a link is made to that file and it is also copied into the filename.hype file. When updating that external file, you're asked in Hype if you want to update it. As much as possible, the actual .hype file is trying to be the container for all media, images, etc. You could dig into the actual Hype file and find the resources folder to make modifications to files, but keep these things in mind:

  • If you modify any image dimensions, Hype won't know about this change.
  • Hype will optimize images during export, so any compression you do on images in this folder may not carry through unless you uncheck 'Automatically optimize will exporting'. Check out this section of the docs for info on how images are handled: Image Optimization

This is a good suggestion. Is your main pain point the after-export compression step?

If you're just working in Hype and adding assets to your document it shouldn't create any folders for you. (Though there is a bug where on some network drives a folder is created temporarily during saving -- this is sometimes not deleted).

3

Hi @Daniel,

Thanks for the quick response! So, the main pain point is either compressing or making changes to the content of the original file (without altering its dimensions). I’ve included a screenshot of where Hype seems to save files after I’ve saved a project, quit, and re-opened it:

18%20AM
Screen Shot 2018-11-28 at 9.32.18 AM.png3282×620 361 KB

Typically, in my project folders, this is where I save my work:

15%20AM
Screen Shot 2018-11-28 at 9.37.15 AM.png2244×336 83.6 KB

I wish that Hype would continue to reference my files from the original location, rather than putting them into a Scratch/Resources folder. Would this be possible? If not, it is possible to work around it, but at first I was very confused as to why my files wouldn’t update in Hype after making changes.

Thank you!
-David

4

This area is not where you would make changes.
Part of it’s use is to run files while in preview mode.
The other part I think is to keep a record of the data hype is using.

It is unlikely to get you the results you want by making changes here. You will also lose any changes you make because when you quit Hype ALL the files and directories are deleted permanently.

This is not the area that @Daniel mentions.

Once you save a project to disk you get a xxx.hype file. This is where he is talking about.

Control click one and show package.
(On a train /iPad so cannot tell you the exact menu)

5

Hype is storing those files in the scratch folder temporarily. It is cleared during a restart. Even after closing or restarting, the link should still be maintained between the image you originally dragged into Hype and the version in Hype. To clarify: if you drag the file from its original spot in the IMG folder (in your second screenshot) and then work in Hype a bit, then edit the image, Hype will ask if you want to update the file.

If the resource isn't being updated after you modify it, we might get some clarity as to why in your logs. (But you shouldn't modify files in that scratch folder)

6

Hype documents need to keep their own copies of assets because of macOS app sandboxing restrictions, required for the Mac App Store. Sandboxed applications cannot read files outside of those that the users has explicitly chosen via open/save panels or drag operations to the app. The mechanism in which you can update the original file and Hype will notice (called “Security Scoped Bookmarks”), is very fragile and can lose its link in many cases so it unfortunately cannot be an option to use instead of Hype’s copy behavior.

Editing the file in the .hype document or within the app sandbox Library folder is not recommended or supported.

Since I know you’re on the beta, I’ll mention there’s a new feature in v4 called External Resource Editing that allows you to edit the Hype version of the file with other applications. See the “Edit In” menu in the Resource Library or control-click on the file. When it is saved in the other application, Hype will use the updated version. There’s a demo at the 37:05 mark of the (Hype Conference 2017 video](https://youtu.be/d_PKAJJhRoM?t=2225). Hype v4 also will ask to replace files with the same name when re-dragged into the resource library, making it easier to swap new versions.

1 Like
7

Hi everyone,

I really appreciate the responses here! I guess I didn’t fully understand how everything works behind the scenes…

The issue I was having was that I was updating multiple files (compressing them via an online PNG compression website) in my personal folders and not seeing Hype recognize that all of the original files had been updated. In cases where Hype didn’t recognize the updated files, I had to right-click and replace them manually in order to re-link them.

While this method works just fine in projects with a small number of assets, in larger projects with many assets, right-clicking and replacing many updated files can be very time consuming. My incorrect assumption was that Hype was relocating the source files into a scratch or resources folder, which would have explained why changes to the source files in my personal folder were not being detected by Hype. Therefore, if I had knowledge of this folder’s location, perhaps I could simply update the files there so that Hype would recognize the updates.

This, however, as I have learned is not how Hype functions! So, I guess the main issue I’m having is that Hype just doesn’t always seem to detect changes to source files from my personal folder.

Should I have perhaps filed this under issue reports? My apologies in advance if I have made an error here.

Thank you everyone for your help and insight!

-David

8

No error :slight_smile:. About the only suggestion would be to also include a high-level reasoning on why you are asking about it in the first place which can help make suggestions sooner.

Like I mentioned, Hype has to use the Security Scoped Bookmarks, which is fragile and error prone in many regards to try to keep external files linked to the Hype document. There's a lot of situations we're unfortunately aware of where the link cannot be maintained (most move operations, certain writes back to the file, v3->v4 upgrade, cross-machine usage, etc.). You're welcome to elaborate on your use case. We added the two new features of external editing and replace-with-same-name in v4 to help with this situation.

I'm impressed you even found the HypeScratch folders! The reasoning for these is that with Hype's copy behavior:

  • it needs a place to put assets that are in an unsaved document
  • if you copy an element with a background image and then close the document, we still need to keep the image somewhere for a potential future past
  • Similarly, if you delete an element, we need to store the asset somewhere for an undo

On quit, Hype will delete the entire Scratch folder.

9

I just came across this discussion, and I have an additional question about it. Like @dduncs, I’m having trouble understanding the workflow here. When I choose “Edit in…photoshop” from the Resource Library, the file that opens is from the scratch folder, not my original linked file. Hence, when I make a change there, it is not updating my source file. If I then go in and make a change to the original source file, not using “Edit in…” it no longer recognizes a change was made. If you try to manually “Update from original file” it cannot find the file. Ideally, when you say “Edit in…” it should be editing your source file, not a scratch file, otherwise you have no way to track those changes for your internal workflow.

10

tl;dr: Hype always keeps its own copies of files and “Edit In…” works on those. To use external editors, a temporary copy is made which is only known about for as long as the Hype document is open.

There’s a bit of history and coming up platform limitations Apple has imposed, so I will try to clarify.

Hype has taken the approach of “preserve a working document at all costs” which means that when an asset is added to a Hype document, it is copied into that document.

If you were to change the dimensions of the original file, modify it in ways not for a specific document, or trash it, we would not want to modify the Hype document. While there’s a lot of workflows where this is desired and intentional, I can tell you there’s a lot where it isn’t and we’d get tons of support about broken documents!

Therefore your Hype document is insulated from any changes of the original asset and you can move around the document to different folks or different computers and have everything operate without missing files.

We do try to preserve a link to the original file so you can edit that and hopefully Hype will pick up the changes.

Unfortunately the App Sandbox feature makes it ridiculously hard to keep track of these files correctly in most cases (see my above post). Pretty much if we want to be on the app store, we cannot count on being able to see any files outside of the .hype document.

So given that we have our own copy, and we might not be able to see the original, the “Edit In…” features acts on Hype’s copy.

To edit in different editors, an actual file is necessary to open in those applications. Sometimes there was an original file in the .hype document folder, but changing that on the fly is a bad idea. Other times there is no file at all, like external editing of a javascript function. The solution is to write out another copy to a scratch folder and monitor it. When there are changes, it re-integrates it back into the Hype document.

If you close the hype document, it then loses the connection to this scratch file. So you could keep making edits, but it was really only meant to be a temporary proxy for what is currently in the Hype document.

Is this the most ideal workflow? Probably not, but it gets around some larger issues and deals with platform limitations. There’s definitely ways it could still be improved and clarified.

2 Likes
11

Thank you for the thorough and quick reply, Jonathan. I appreciate why Hype is trying to preserve assets, but from an internal asset management and workflow standpoint, it’s sort of a nightmare in an agency environment like I’m in, where multiple users are creating and updating assets for projects. In this environment, we are used to managing shared assets across projects (Premiere or InDesign or After Effects files, etc.) so it would be really great to have the option of deciding how Hype handles assets, especially since it is not consistent from asset to asset. Something for a later update, I hope. We otherwise really love working in it.

12

Thanks for the feedback - all good points and resource library improvements are definitely on the radar :slight_smile:.