Recently I was trying to put a SQLite database into a QT 5 application I'm writing. I want it to be universally accessible - that is on all systems regardless of where it's installed. I put it as a resource then found out that evidently you can't put databases in resources as the string for the database path passed to setDatabaseName doesn't get translated to the resource system so the database can't be found.
So where can I put it? I don't want to just put it at the root of the drive like C:\repo.db or D:\repo.db as many people hate files cluttering their root directories (like me). I was going to put it just in the source folder and access it as "repo.db" or as I tried "./resources/database/repo.db" but even QFile doesn't see that. Where can I put it and how to access it there? My settings file was going to be in my resources but I wasn't sure if I could update the file then. I need a place that is available from the moment the application is installed on any system including my own so that it can be accessed both while coding it and when it's built.
I'm not asking for opinions - I want a place that is not in the root, somewhere universal like the installation directory (but how do I find that with code?) or a settings directory (but how do I set that somewhere so I can find it later??)
For such purposes Qt provides a list of QStandardPaths functions that return platform specific standard paths, such as a path to desktop, temp directory etc.
For your particular case you might put your database in the directory that corresponds to the QStandardPaths::AppDataLocation key.
You can use QSettings to save path,settings and restore them.
QSettings m_Arhive("Company", "app_name");
//Set DB path
m_Arhive.setValue("DBPath", "c:/somewhere/database");
//Get DB path
m_Arhive.value("DBPath").toString()
as of recently I am noticing that the assets folder of my Xaringan presentations fill up with loads of weird folders, after knitting. I have several useful subfolders (e.g., css, images, js), but there are easily 200 folders created after knitting. All of then have random names like "00e3144c-c556-4b66-b50a-c44d64246b85-9.9.9" (the "-.9.9.9" seems the only non-random repetitive part of the folder names).
Where do these folders come from/what causes their appearance? And: are they strictly necessary or can I prevent them from being created? They are empty, but totally flock the assets folder.
I experienced the same overwhelming empty directory problem.
Yihui gave a possible cause - HTML dependency. I went down that route and discovered it was xaringanExtra which uses htmltools that would lead to empty directories - xaringan alone wouldn't.
It seems Garrick (author of xaringanExtra) has been aware of such issue, hence this PR. I'd wait for it to be merged then try again. Hope this is helpful.
I'm using sphinx and RST to generate some tech documentation as HTML and having issues getting a local PDF reference to work as a hyperlink. I've seen people use :download: to link to local PDFs, but I'm embedding the PDFs inside a /docs directory for reference. I don't like :download: because it doesn't display the PDF inline in the browser which requires an extra step on the users' behalf for consumption.
sphinx-build -b html does not copy any files unless they are specified in config.py hook html_static_path or html_extra_path - and even then they are dropped to the root directory or _static folders.
Is there a suggested approach for embedding linked binary files within sphinx or is this a poor practice? Often times the links are to slide decks or design diagrams that are not hosted anywhere else.
Sample RST for linked PDF
.. important:: View the agile course on scrum basics
- View `these slides to dive deeper into Agile Basics <docs/agile-101.pdf>`_.
The solution I came up with was to just add the PDFs to html_static_path and reference the _static output path in the link instead of the docs path where it lives in the source. Now PDFs open up in the browser instead of having to download them to view.
Would be great if there was an sphinx extension / directive to handle this (:download-inline:).
conf.py
html_static_path = ['_static', 'agile-101/docs']
agile-101.rst
.. important:: View the agile course on scrum basics
- View `these slides to dive deeper into Agile Basics <../_static/agile-101.pdf>`_.
First time asking a question here, and might not be my last. This is in regards to WiX 3.8
My company is starting to go into the installer business, and one of the requirements I have been tasked to do is to create a multi-disc installation for our product. I have used WiX before for simple patches, but now we want to create a full installation. Some of the requirements include:
Creating external cab files for multiple discs [Which I enabled with setting the 'EmbedCab' property in the media tag to 'no' and setting the disc ID's to each file element with Compression to low]
The finished build will have the 5 discs in separate folders, with the respected external cab files in each [Media tag 'layout' set to destination]
Executing the .msi file inside the 'Disc1' folder [Which works...almost]
The problem I am running into is that when the .msi file is located on the hard disk, either outside the Disc layouts or inside the 'Disc1' subfolder, it cannot find the other .cab files. The requirement I have is that I need to find a way to be able to only prompt for a disc if and only if after searching inside the next subfolder 'Disc2' and finding the next .cab file to install. Therefore it can not only look in the root where the .msi is located, but also check the subfolders for the required cab files. (This almost mimic's InstallShield, but I REALLY don't want to go that route.)
The second issue I have is regards to the bootstrapper. The .exe file needs to embed the .msi file as per the requirement. However, even when disabling caching of the msi file, the bootstrapper seems to start caching all the other .cab files (we are talking about a 20GB installation). Even disabling repair and rollback, the bootstrapper continues to try to cache the cab files into the PackageCache area on my system.
I've looked online and read the WiX books to help find a solution, but I seem to finally hit a dead end. Can anyone give me any thoughts or insight to help with this issue?
Some things I have tried so far:
- Using a custom action (C++) to perform a 'ResolveSource' to try to change the 'SourceDir' property to continue installation
- Thought about making a custom bootstrapper to disable the package caching event entirely, but I have no idea where to start.
Any advice, direction or even a sample to help would be greatly appreciated.
Thanks!
IMPORTANT: The accepted answer was accepted post-bounty, not necessarily because I felt it was the best answer.
I find myself doing things over and over when starting new projects. I create a folder, with sub-folders and then copy over some standard items like a css reset file, famfamfam icons, jquery, etc.
This got me thinking what the ideal starting template would be. The reason I'm asking is that I'm going through once again and am wondering what I should include in my template so that I don't have to go back in the future and do this all over again with every new site I start.
What I currently have follows:
Project Template Folder
index.html -- XHTML 1.0 Strict Doctype. Meta Tags. CSS/js Files Referenced.
css/
default.css -- Empty. Reserved for user-styles.
960/ -- 960 Grid System for CSS Layouts.
960.css
reset.css
text.css
js/
default.js -- Empty. Reserved for user-scripts.
jQuery/ -- Light-Weight Javascript Framework
jquery-1.3.1.min.js
img/
famfamfam/ -- Excellent collection of png icons
icons/
accept.png
add.png
...etc
I have a similar structure and naming convention but for CSS, I use BluePrint which I find is more extensible. Also prefer jQuery having recently switched from prototype. In addition I have a common.js file that is an extension with custom functions for jQuery.
A /db/ folder with .sql files containing schema definitions. A /lib/ folder for common middle-tier libraries.
I will also have a /src/ folder which will sometimes have raw files such as Photoshop templates, readme's, todo lists etc.
If you have a lot of projects with a lot of static content in common (e.g. jquery, css framework, etc) make yourself a media server to serve all these. Then, instead of creating a bunch of folder structure from a "template" all you do is include the right files in your project's html. If you really want a template, your template becomes one html file instead of a directory structure.
This also gives you an easy way to update the static media for your sites (e.g. moving to the next version of 960). you only have to do it in one place. Of course, you still have to make sure that your updates don't break existing sites! :)
You can make the scheme a bit more complicated if certain projects have overlapping needs but are different from others. Just have a directory at the top level of the server for each setup and to each setup corresponds one html "template". The main idea is to have to deal with only one copy of everything that is common.
You can certainly do this on a small VM (e.g. linode) for $20/mo or a virtual web-server on your current web server. You don't really need a server, for that matter, you just need a folder. However, I think you can have some significant performance gains by having a dedicated media servers. I'd recommend using a fine-tuned apache or nginx for this purpose.
As for site-specific static files, it is also a good idea that they live on the media server and the directory structure would probably be exactly what you have, but they would/should be empty directories.
My web development framework sits in a git repository. Common code, such as general purpose PHP classes gets developed in the master branch. All work for a particular website gets done on a branch, and then changes that will help in future work get merged back into master.
This approach works well for me because I have full revision control of all the websites, and if I happen to fix a bug or implement a new feature while working on a branch I can do the merge, and then everything benefits.
Here's what my template looks like:
/
|-.htaccess //mod_rewrite skeleton
|-admin/ //custom admin frontend to the CMS
|-classes/ //common PHP classes
|-dwoo/ //template system
|-config/ //configuration files (database, etc)
|-controllers/ //PHP scripts that handle particular URLs
|-javascript/
|-tinyMCE/
|-jquery/
|-modules //these are modules for our custom CMS
|-news/
|-mailing_list/
|-others
|-private/ //this contains files that won't be uploaded (.fla, .psd, etc)
|-.htaccess //just in case it gets uploaded, deny all
|-templates/ //template source files for dwoo
I use a similar layout, but with one major exception: all of these directories live under a top-level media/ directory. This is for a few reasons:
This directory is rsync'd to two other servers which handle all of the static media requests.
Having multiple hosts allows some browsers to make more parallel requests for support files.
The media/ directory has its own .htaccess file which strips off a psuedo directory from the path which is the date-time last modified of the image (or whatever).
A custom template tag (I have used this with 2 Django projects, but you could do it in PHP, etc.) generates urls which a) semi-randomly choose one of the media servers, b) add the time-based pseudo directory to the path, and c) give the object an Expires time of now + 10 years.
I think the structure is good. The addition of a few other folders depends on what type of work you are completing.
For freelancing and the like, the addition of PSD folders, client comments would be a nice addition.
A very MS skewed view, but my SOP right now is along the lines of:
documentation/
architecture/ (what you might call code documentation)
communications/ (important client docs)
spec/
whitepapers/
graphics/
*.psd
source/
com.mycompany.projectname.solutionA/
com.mycompany.projectname.solutionB/
com.mycompany.projectname.solutionC/
com.mycompany.projectname.solutionX/ (project in the business sense here)
businesslogic/
*.cs (or whatever)
(further projects - in the visual studio sense)
site/
handlers/ (rarely do I use actual .html these days)
modules/
resources/
img/ (pngs jpegs, gifs whatever)
skin/
icons/
backgrounds/
js/ (compressed when published)
library/ (standard code)
common/ (app specific code)
*.js (app specific code, hopefully nil)
css/
skinX/ (even if there is only "default")
extension.css
base.css
transforms/(always hidden from public by config or build process)
*.xslt
unittests/
mocks/
testmain.cs (or whatever)
thirdparty/
dependencies
I definitely love the idea of having a skeleton template folder like this, but if you use a few different technologies, definitely pay close attention to the structure. My VB.net folder structure has a totally different setup compared to PHP. It sounds like common sense, but I have seen people approach both the same way.
At work we use Code Igniter as a PHP framework for our web applications and have created a new project template which does exactly that: Simple directory structure, Blueprint CSS, jQuery and the Code Igniter application folder, filled with a couple of commonly used libraries (Authentication, some speciales models for often used databases...).
The main motto here is: It's always easier to delete components than to add them. So fill your template up.
(And when I'm starting a new project in my spare time I sorely miss that template...)
I think what you have here is great.... What you've listed is of course all about the public front end of your app. My only addition to this, is to keep all your backend code and source out of the public web space if possible, as the less things you have in the public space, the more secure your app is.
So I'd suggest you take your entire tree, and put it in:
httpdocs/(all you had in your project template folder)
then put all your backend code (e.g. php libraries, sql files, etc) in adjacent subdirectories:
httpdocs/(all you had in your project template folder)
phplibs/
sql/
etc.
And, even for your front end stuff, make sure you don't copy in any example files that may come with your front end libraries, as the examples themselves may have security problems that would allow people to XSS or otherwise compromise your site.
I have been using the following setup for a while now with great results:
/site: This is where my actual working website will live. I'll install my CMS or platform in this directory after the templates are created.
.htaccess (basic tweaks I usually find myself enabling anyway)
robots.txt (so I don't forget to disallow items like /admin later)
/source: Contains any comps, notes, documents, specifications, etc.
/templates: Start here! Create all static templates that will eventually need to be ported into the CMS or framework of /site.
/behavior
global.js (site-specific code; may be broken out into multiple files as needed)
/media: Images, downloadable files, etc. Organized as necessary
/style: I prefer modular CSS development so I normally end up with many stylesheet for each unique section of the website. This is cleaned up greatly with Blender - I highly recommend this tool!
behavior.css (any styling that requires a JS-enabled browser)
print.css (this eventually gets blended, so use #media print)
reset.css (Eric Meyer's)
screen.css (for #media screen, handheld)
/vendor: all 3rd party code (jQuery, shadowbox, etc.)
Blendfile.yaml (for Blender; see above)
template.html (basic starting template; can be copied and renamed for each unique template)
I like OPs as a default start point. your standard template should err on simplicity, with the ability to add complexity only if it's needed.
one addition:
/robots.txt