My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
Related
I'm on OS-X (Mavericks, if that matters), and I'm making a bash script that will use resources from a folder called "templates". I'm trying to figure out where I should put it (the templates folder). I'd like to make it so the user doesn't need to modify their path when they install it, so I'd rather not do it the way the terminal mysql command does it (it lives in a folder in /usr/local/mysql/bin). I really want to be able to put them into usr/bin, but I don't know if it's "polite" to put folders in there (I don't see any in there).
Right now I'm leaning towards putting the scripts in usr/bin and having the templates in usr/lib. Is that how this type of thing is normally done, or is there another way? I'd like to follow a convention, assuming there is one. I'd also like it to apply to as many Unix platforms as possible (I'd like to put in a directory where bash scripts live that's consistent across as many Unix platforms as possible). Thanks.
If you follow the Filesystem Hierarchy Standard (FHS), your executable goes in /usr/local/bin, while read-only template files go in /usr/local/share/YOURAPP/. To quote the FHS:
/usr/local/share
The requirements for the contents of this directory are the same as /usr/share. […]
and:
The /usr/share hierarchy is for all read-only architecture independent data files.
(Emphasis added)
If the system admin is meant to customize the template files to take effect system-wide, then they would simply go in /etc/YOURAPP/templates (or something like that).
If the template files are customized on a per-user basis, then the modified copies of the templates (copied from /usr/local/share/YOURAPP/templates) need to be saved in the user's directory, under $HOME/.config/YOURAPP/templates or something like that (thanks to technosaurus for the correction).
You mentioned that you want to install the templates in a directory alongside your executable. That is not the standard approach on UNIX, at least going by the FHS. If you really want to go this route, there is a sort of convention of installing your app to /opt/YOURAPP/, using whatever organization you want inside that folder.
In all cases, it is not good practice to install executables directly to /usr/bin, as that directory is considered to be under the exclusive control of the OS/distribution. If you want to install there, the accepted way to do that is to create a package for the package manager of every supported OS/distribution.
For an application I would like to store a collection of files together, and have them appear in the filesystem as a single file so its easy to manage. I am currently storing everything in a folder.
I would like to keep things accessible so you can manually edit the inside contents if neccesary.
One way to do this would be to create a zip archive and give it a custom extension other then .zip. Then it appears as a filetype and if needed you can unpack and access the content, but for normal use keep it hidden.
I can't seem to find a convenient way to do this. Boost and zlib can do the compression but don't work with archives. I found libzip but I have a hard time understanding how to use it and to me it seems that it only reads/writes zip archives without doing the actual compression.
Is there a more convenient way to tackle this?
Can you call system functions for creating an archive on OSX from c++ / Carbon?
Is there another way to make a folder appear as a single file?
In OSX, you can create Document Packages (similar to application bundles) which are treated as a single file in the Finder, but are really just directories with some internal structure.
Apple does not zip these packages, but they do provide the functionality you describe and they can be created and accessed through CoreFoundation by using CFBundleRef .
From the documentation:
... The important thing to remember about creating a document package is that it is just a directory. As long as the type of the document package is registered (as described in “Registering Your Document Type”), all you have to do is create a directory with the appropriate filename extension. (The Finder uses the filename extension as its cue to treat the directory as a package.) You can create the directory (and create any files you want to put inside that directory) using the standard BSD file system routines ...
As 1st step, simple rename the folder and add the extension .bundle, e.g. Myappdir.bundle
That's will show the whole folder as one file with a lego-like bundle icon.
The next step is you must create one Info.plist file inside.
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...
What I need is a directory which the user can handle as a single file in the Windows explorer. Does something like this exist? If not, what comes closest?
The closest thing is probably Alternate Data Streams, although those are more akin to MacOS Named Forks than Bundles.
There are also some special cases, for example if you save a website with Internet Explorer you get an HTML file and a folder which are linked together.
Depends on your particular needs. As mentioned above, named streams are possible (on NTFS), however you should notice that not all applications copy files with named streams correctly. In some scenarios regular ZIP archives can work (Explorer shows them as folders). If you are doing software development, there exist libraries that let you store many files in one container file (eg. SolFS).
I think you can create a folder with an extension, e.g. Myfolder.bundle, then you can associate that extension with a custom icon. So it looks like a bundle as far as the end user is concerned.
I have a program that I need to run under *nix and windows. because the program takes file paths from files the issue is what to do about the \ vs / issue.
My current thought is to put in a regex that converts the wrong one to the right one depending on what system I'm on. This will have the effect of letting either type work on either system. Aside from the fact that now I have two problems, does anyone see any other problems?
(Other better solutions are more than welcome)
Edit: the primary issue is getting windows paths to work on unix rather than the other way around.
The / is fully supported in win32 too.
Also see this related question
Windows will generally accept either \ or /,so standardizing on / may make your problem simpler as long as you have complete control over the filenames.
Have you considered creating a "file manager" class that will handle all of the file pathing issues for you? That way in your mail application, when you're loading a data file, you can call something like this.
LoadApplicationData(FileManager.GetDataFilePath)
Then your file manager will detect the environment that it is in and return the proper file path option. That way you can also accomodate for Win32 vs. Unix locatio standards (like Program Files vs /usr or whatever) as well.
Note that Win32 paths are complex when you consider drive letters (no analog on Unix) and the special 'forks' (MacOS pre-X term - likewise no analog on Unix in general, though MacOS X has them - surprise, surprise) that can be provided. Be careful.
Create a parser for your input to create a tree structure of nodes representing directories. Then you can 'save' by walking the tree and writing whatever delimiters you want or optionally doing different things, like checking if the directory exists or writing meta files. This is actually something that I am just now thinking would be useful for my own application :-)
You didn't say what language you are using, so I'm going to selfishly assume c/c++. boost, if you are willing to use it, has a filesystem library. Of course, if you are using a dynamic language, FS abstraction libraries probably already exist there too (e.g. in perl, File::Spec is quite standard).
You haven't told us what sort of files you are reading paths in from. I am going to assume that they are config files. In which case, there are many ways, IMHO the correct answer is to design your program to avoid manipulating paths, if possible. I posted an answer here: https://stackoverflow.com/a/40980510/2345997 which is relevant.
ways:
Add a command line option which allows a user to specify the path in question instead of reading it from a config file.
Add a command line option so that the user can specify a base path. Paths in the config file will be interpreted as located under this base path.
Split your config file into three. One file will have cross platform configuration, another file will have windows only configuration and a final file will have Linux only configuration. Then the user can specify the correct path for both Windows and Linux. On windows your program will read the cross-platform config file and the windows only config file. On Linux it will read the cross-platform file and the Linux only config file.
Add preprocessing to your config file parsing. This will allow you to have one config file where the user can make your program ignore some of the lines in the file depending on which OS the program is running on. Therefore, the user will be able to specify the path to the file twice. Once for Linux, and once for Windows.
Change the design so that the files are always located in the same directory as your executable - then the user only specifies file names in the config file rather than paths to files.
Use a simple function that switches "/" to "\". Then document to the user that they must specify paths as Linux paths and this transformation will be applied for windows.
Create your own path mini-language for this and document it to the user. E.g: "/" - specifies a directory separator, {root} - expands to the root of the filesystem, {cwd} - expands to the current directory, {app} - expands to the path to your application etc... Then the user can specify file paths like: {root}/myfiles/bob.txt on both platforms.
Some paths will work on both platforms. E.g: relative paths like ../my files/bill.txt. Restrict your application to only work with these paths. Document this limitation and how your application handles paths to the user.