While I'm waiting for some external things to get finished up for the 2.6 release, I've been tinkering around with AppleScript support. It's been kind of a rocky road. AppleScript from the developer's side isn't always as easy to implement as they tell us. In a simple case it can be easy from what I hear, but what is a simple case anyway? Supposedly some apps can do it with zero extra code. MacJournal 2.6 is entirely MVC-friendly, but I've still encountered problems. I've been able to get some things working, but other things are broken inexplicably with little or no apparent reason why. AppleScript is hard to debug: Script Editor gives you no help when something goes wrong. You end up with an error name that isn't descriptive and an error number that isn't explained anywhere. I lost a lot of time to a problem that really shouldn't have been an issue in the first place. Apple is assuming something about how I set up my application that turns out to be wrong, and now I have to work around it by adding more extra code. It's always a little disappointing whenever that happens.
The heart of AppleScript-ability lies in two well-formatted text files. It seems weird that with all the fancy developer tools they give us, a simple graphical tool to create these files weren't include. At the very least something to validate the files would have been nice because small errors can be very hard to ferret out, especially when you don't know where the problem is. Maybe something like this will be coming in Tiger with the new release of Xcode. One can only hope.
But I am optimistic about MacJournal's AppleScript support. Admittedly this is my first AppleScript implementation that I have done, so I'm hitting a lot of the first-timer roadblocks that will no doubt get easier with experience. Hopefully a basic set of features can be available for the very next version, with more features coming after that.
Tuesday, August 31, 2004
Monday, August 30, 2004
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.
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.
Friday, August 20, 2004
Setting the Data Path in 2.6b4
There is a bug in 2.6b4 where trying to change the data path in the Advanced preferences will lock up MacJournal. Here is a workaround for this until the next release comes out:
1. Quit MacJournal
2. Open Terminal
3. Type
4. Type
5. Open MacJournal
Replace the "~/Desktop" with wherever you want your data to be saved. When you open MacJournal again, that's where it will look for its data.
1. Quit MacJournal
2. Open Terminal
3. Type
defaults delete com.DanSchimpf.MacJournal StoragePathAlias and hit Return4. Type
defaults write com.DanSchimpf.MacJournal "Storage Directory" "~/Desktop" and hit return5. Open MacJournal
Replace the "~/Desktop" with wherever you want your data to be saved. When you open MacJournal again, that's where it will look for its data.
Thursday, August 12, 2004
Last Call For Spanish
Pending a few external issues, MacJournal 2.6 is pretty much ready for a release. I have had a few small bug fixes in the days since beta 4 has been released and I'm confident that the release is ready. There's even a Taiwanese localization now. But we're still missing Spanish and French localizations. I've got a possible lead on French, but still nothing for Spanish. If you'd like to donate some of your time to translate 2.6 into Spanish please email me so we can work something out fast. Otherwise 2.6 will have to ship without Spanish.
Monday, August 09, 2004
MacJournal 2.6b4 Released
Welcome to the fourth and final beta of MacJournal 2.6. Download it from here. This release picks up the Serbian localization and a number of small changes. 2.6 is going to be a great release.
Here are some of the changes:
- Text sent to Blogger and LiveJournal will no longer be heavily stylized. I tried to cut out a lot of what they already do, like font and color. Bolds and italics will still be sent. Also, any changes in font size or text color from what the majority of your text looks like will also be picked up.
- Titles of entries may very well be sent to Blogger now.
- Copy and Paste support in the drawers for moving entries around
- You can now delete a locked journal if you have the system administrator password
- You can now drag attachments from entries into the Finder and elsewhere
- Other smaller, but important bug fixes.
Other enhancements are noted in the Version History (there are a lot of little items).
As always, install and use developmental software at your own risk! Be sure to back up your data before each new build just in case. Just for fun, MacJournal itself will back up your data with each new build that you install as well.
Please let me know of any problems that you have with this build as soon as possible.
Reporting Bugs
Please let me know about any bugs you find in this release as soon as possible. New in 2.6: use the "Report A Bug" menu item in the Help menu to see a list of known issues for your current build (as they arise). You can also automatically create a new e-mail.
If MacJournal crashes on you, look for a crash log in ~/Library/Logs/CrashReporter and include that in your report. If there's some funny behavior, try looking in the Console (in /Applications/Utilities/) and include any output related to MacJournal in your report. Please be specific about things that you are doing that aren't working out, whether it's a crash or a behavior that you don't like. Also, include what release of MacJournal you are using in your e-mail. I appreciate your feedback!
Here are some of the changes:
- Text sent to Blogger and LiveJournal will no longer be heavily stylized. I tried to cut out a lot of what they already do, like font and color. Bolds and italics will still be sent. Also, any changes in font size or text color from what the majority of your text looks like will also be picked up.
- Titles of entries may very well be sent to Blogger now.
- Copy and Paste support in the drawers for moving entries around
- You can now delete a locked journal if you have the system administrator password
- You can now drag attachments from entries into the Finder and elsewhere
- Other smaller, but important bug fixes.
Other enhancements are noted in the Version History (there are a lot of little items).
As always, install and use developmental software at your own risk! Be sure to back up your data before each new build just in case. Just for fun, MacJournal itself will back up your data with each new build that you install as well.
Please let me know of any problems that you have with this build as soon as possible.
Reporting Bugs
Please let me know about any bugs you find in this release as soon as possible. New in 2.6: use the "Report A Bug" menu item in the Help menu to see a list of known issues for your current build (as they arise). You can also automatically create a new e-mail.
If MacJournal crashes on you, look for a crash log in ~/Library/Logs/CrashReporter and include that in your report. If there's some funny behavior, try looking in the Console (in /Applications/Utilities/) and include any output related to MacJournal in your report. Please be specific about things that you are doing that aren't working out, whether it's a crash or a behavior that you don't like. Also, include what release of MacJournal you are using in your e-mail. I appreciate your feedback!
Wednesday, August 04, 2004
More Status Updates
Where is MacJournal nowadays? As I've said many times before (but this time I mean it), MacJournal 2.6 is very close to release. I'm waiting for one or two things now and then I will release 2.6b4 to everyone. Very soon after this will come the final 2.6 release. The reason for this is I want to give everyone a chance to see beta 4 and report any bugs that are found before the final release. I've been doing a lot of testing with the current daily builds and I think it's really solid. I know I said I wanted to get it out before August, but then I went on vacation. :-) As always you can check out the current build notes before beta 4 is released so you know what is coming.
Subscribe to:
Posts (Atom)
