Mac install ItemTemplates directory empty on both 21.0.1 and 21.0.2!!

[jwiede]

This was posted in another thread w.r.t. ItemTemplate dir being missing on Linux for 21.0.1...

This is fixed for the next point release, 21.0.2.

On Mac, both 21.0.1 and 21.0.2 on Mac have ItemTemplates directories empty.  Please fix!!

Also, where can we obtain the templates for 21.x if they're not being properly installed?  Would really appreciate solution for this ASAP, as have acute need for set of basic templates.

Thanks!

[patrick]

The ItemTemplates directory under the config directory only has user created templates, not the ones that ship with the system.  The bug in 21.0.0 & 21.0.1 was with how we collected and merged those for the dialog. 

If you need to manually unpack template files, the templates shipped with the system are in INSTALLDIR/plugins/com_slickedit.base.zip

I'm not sure why you'd see this on 21.0.2, I'm taking a look at it now. 

[jwiede]

The ItemTemplates directory under the config directory only has user created templates, not the ones that ship with the system.  The bug in 21.0.0 & 21.0.1 was with how we collected and merged those for the dialog. 

If you need to manually unpack template files, the templates shipped with the system are in INSTALLDIR/plugins/com_slickedit.base.zip

I'm not sure why you'd see this on 21.0.2, I'm taking a look at it now.

The contents of the zip file's "...\sysconfig\templates" dir you mentioned do not appear (unpacked) anywhere on either my Mac OSX 10.12 or Win10 systems after fresh installs of SE21.0.2.  In the fresh SE installs, neither shows anything under "Installed Templates".

Can you please clarify where the installed, uncompressed template files should be located after a fresh install of v21 on Win10 and Mac?

Whatever the past problem was, the current problem is that fresh installs of 21 aren't installing the stock templates at ALL (on either Win10 or Mac) as far as I can determine, and thus SE is accurately reporting no installed templates present.

Thanks!

-John

[jwiede]

Can you please clarify where the installed, uncompressed template files should be located after a fresh install of v21 on Win10 and Mac?

Whatever the past problem was, the current problem is that fresh installs of 21 aren't installing the stock templates at ALL (on either Win10 or Mac) as far as I can determine, and thus SE is accurately reporting no installed templates present.

BTW, needless to say this is a fairly significant workflow impediment compared to working with prior versions/revisions of SE.  If y'all have any short-term workaround that'll make the templates in that one referenced .zip file available to SE in the "Installed Templates" section, that'd be quite appreciated. 

As it stands I can move them to the user-installed area, but obviously that doesn't solve either the muscle-memory issue nor the longer-term install/availability issue for those templates.  Also, as it seems like there have been some recurring problems in this specific area of late, do you have any ideas why that's occurring and how you intend to address it?

[patrick]

The files live in the zip file.  They are not unpacked anywhere else.

I'll let you know as soon as I have a hotfix for this.  It should be sometime today, unless I have bad luck.

[jwiede]

The files live in the zip file.  They are not unpacked anywhere else.

I'll let you know as soon as I have a hotfix for this.  It should be sometime today, unless I have bad luck.

Much appreciated, thanks!

P.S. Any chance you can throw in a fix to make C/C++ block comments obey line length restrictions too? 

[patrick]

It ends up this isn't hotfixable.  It's fixed for 21.0.3, which is coming soon.

There is a workaround, if you don't mind mucking around in your install directory.  If you go to the INSTALLDIR/plugins directory, you can unzip the com_slickedit.base.zip file that's there, and then move the zip file out of the directory.  (once you're done, the plugins directory should just have a com_slickedit.base/ directory, rather than a zip file).  This will work because the bug is in how the files are traversed when the source is a zip file.

That workaround is probably why we missed this was broken a second time - during development, those directories are unpacked; they get packed up when we build installers.  I'd bet I ran it on a dev install when I was testing it, and didn't realize it.

[jwiede]

That workaround is probably why we missed this was broken a second time - during development, those directories are unpacked; they get packed up when we build installers.  I'd bet I ran it on a dev install when I was testing it, and didn't realize it.

Presumably the testing process has been changed to block this from occurring in future?

Thanks!