Frequently Asked Questions

Q: Can I put journals inside of other journals?
Not yet. This is a big change inside of MacJournal and it needed to happen slowly in order to protect your data. This will be coming in the very next version of MacJournal after 2.6. MacJournal 2.6 represents a lot of work behind the scenes that is not yet visible, but will pay off after 2.6 with a lot of features that will be able to come quickly.

Q: Can I drag entries around inside of journals to reorder them?
Not yet. Right now everything is assumed to be sorted; it's been this way from the start. A more level-headed developer probably would have made everything unsorted to begin with and then add sorting later, but such is life. So it's another big chunk of assumptions that will need to be removed before this will work. This should be coming in MacJournal 2.7 along with nested journals.

Q: It takes a really long time to launch and quit; what's up?
This is due to a very large data file that MacJournal has to encode and write out to disk. This is most likely because of a lot of pictures being stored in the data file; having a lot of entries and/or journals will not generally cause this by itself. So what are the solutions here? An option to store pictures outside of the big data file is forthcoming, but a better solution is to allow for multiple data files better coupled with a fancy new file format. This will probably be coming in something like MacJournal 3.0.

Q: Why is the data file stored in Application Support? Wouldn't my Documents folder be better?
This may seem arbitrary, but putting the data file where it is was actually thought out and it was decided to be the best place. In its current incarnation, MacJournal handles all of the data for you behind its back so you don't have to. So because the user does not have day-to-day interaction with the data file, it is not appropriate to put the data file in their Documents folder by default (you're free to change it yourself). It's the difference between Address Book and TextEdit: TextEdit documents are all distinct and need to be handled individually, whereas Address Book handles your data for you. It would be annoying if Address Book put its data in your Documents folder because you would never touch it and it would just take up space. Microsoft Word creates a "Microsoft User Data" folder in my Documents folder every time I open it and it annoys me more each time. In the future, if MacJournal becomes more document-based, changes would be made. But for now it remains in Application Support.

Q: It would be cool if I could resize pictures that I drag into MacJournal. Is that a possibility?
Yes, this is being considered for the future. This is one of those things that might be really easy for me to do, or really really hard. I have yet to sit down and attack it, but I have been thinking about it. I'm hoping for really easy. :-)

Q: Why do the MacJournal alphas/betas have an expiration date?
MacJournal 2.6 is the second time I've done public pre-releases. It worked fantastically for 2.5 and has been even better for 2.6. But one of the things I learned from the 2.5 process is that people won't always update to the latest pre-release build even if they understand it is pre-release software. I can understand it from their perspective (as the user who wants things running smoothly and if it isn't broken then don't fix it), but from my perspective (the developer who can't support pre-release builds forever) it's less than optimal. I can't support 2.5b4 18 months after 2.5b5 was released. I need people to stay as current as possible to ferret out any problems that they may have. If you tell me about it now, I can fix it for the final build. If you e-mail me a year later I can't help you. So it works to everyone's advantage to stay within a build or two of the most current release. I try to stage the 2.6 releases so at least 2 builds still work, so if the most recent one doesn't work you can still use the last one for a while until a fix is released. That way everyone is happy when the final product is released.

Q: I don't like thing 'X' that you added in 2.6! Can you take it out?
Most changes that have been made have been done in such a way to provide minimal interference with what is already there. Too many toolbar items available? Remove the ones you don't want or just hide the toolbar entirely. Through tweaking some interface elements and preferences, you can achieve a simpler UI than what is enabled by default. However, if that isn't enough for you, there are generally hidden preferences that you can enable to customize the appearance even more. I'm just one guy working in my spare time so I can't do everything, but I try to make people happy.

Q: Why are there so many hidden preferences in MacJournal 2.6?
There are two reasons for creating a hidden preference (a preference that does not show up in the actual user interface but must instead be activated via the Terminal):
1. Option or feature came too late in the process and could not be accounted for in all of the localizations that have already been updated
2. Option falls outside of the intended functionality of the program.

Number 1 is pretty easy to understand; I have to lock down the interface at some point to get the many localizations updated so things added after that either have to be delayed until the next release or only exposed from the Terminal and English-only. Number 2 is a little trickier. MacJournal 2.6 has a hidden preference to change the main window to be a metal window, a la Safari or iPhoto. There are many things wrong with this on a UI standpoint: text editors should never be in metal. But some people want it and it's kind of a fun like setting to tweak and see how it looks. So it's there, but will never be an option in the Preferences window. Some are in a little more gray territory: I don't think they'll ever be options, but they might if it becomes useful enough, so making it available from the Terminal is a good way to do that. In the next release I hope to have a better system of enabling hidden preferences though. Maybe there will be one switch you throw in the Terminal (or even in the UI) that shows a bunch of checkboxes for all the different hidden preferences with appropriate warnings everywhere about hidden preference support. But for now the Terminal is your friend.

Q: Can I create a link from one entry to another?
Indeed you can! You could actually do this in 2.5, but it wasn't very easy to figure out or even know that you could. However, MacJournal 2.6 makes it a lot more apparent. In the sheet for editing links there are two new buttons: one for linking to an entry and one for linking to a file. Clicking the latter will bring up an open panel to select a file on disk and clicking the former will bring up a different kind of open panel: it will show you all of your journals and entries and you can select the one to which you want to link. These are just assistants; you can still just type in the URL manually, or drag an entry from a drawer or a file from disk into the URL field to paste the URL.

Q: Can I send entries to Movable Type blogs?
Yes, this is possible via the Blogger sheet. See the Movable Type website for details about how to accept Blogger connections on the server side.

Q: What about TypePad? Weblog Service X?
Most services accept the Blogger protocol as a de facto standard. Check with your provider to see if they do and what the details are. In the future, MacJournal will use the Atom protocol (once it is finalized) as this will allow for a greater range of features and should allow you to send to any ol' arbitrary website. Atom is supposedly the protocol-to-end-all-other-protocols and all of the major sites have committed to supporting it. Some sites already do (including Blogger). This will mean that there would be just one Atom sheet, instead of a Blogger and LiveJournal sheet, that is powerful enough to send to any server. In theory, of course.

Q: Can I download entries off of my weblog into MacJournal?
Not at this time. MacJournal isn't an online blogging client per se, so features like this are mere conveniences. With the whole Atom thing (and a standard, singular sheet for interacting with a server) it may be a lot easier to grab a bunch of entries off of any server in the world, so I will definitely reevaluate things at that point. I'd like to do it if it could be integrated into the existing UI nicely and it was fairly reliable (dealing with the Internet is a pain and a half).

Q: Can I send you a million dollars?
Yes. Yes you can.