So it works to everyone's advantage to stay within a build or two of the most current release. If you e-mail me a year later I can't help you. If you tell me about it now, I can fix it for the final build. I need people to stay as current as possible to ferret out any problems that they may have. I can't support 2.5b4 18 months after 2.5b5 was released. 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. 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. It worked fantastically for 2.5 and has been even better for 2.6. MacJournal 2.6 is the second time I've done public pre-releases. Q: Why do the MacJournal alphas/betas have an expiration date? I have yet to sit down and attack it, but I have been thinking about it. This is one of those things that might be really easy for me to do, or really really hard. Yes, this is being considered for the future. Q: It would be cool if I could resize pictures that I drag into MacJournal. But for now it remains in Application Support. In the future, if MacJournal becomes more document-based, changes would be made. Microsoft Word creates a "Microsoft User Data" folder in my Documents folder every time I open it and it annoys me more each time. 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. 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. 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). In its current incarnation, MacJournal handles all of the data for you behind its back so you don't have to. 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. Q: Why is the data file stored in Application Support? Wouldn't my Documents folder be better? This will probably be coming in something like MacJournal 3.0. 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 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. This is due to a very large data file that MacJournal has to encode and write out to disk. Q: It takes a really long time to launch and quit what's up? This should be coming in MacJournal 2.7 along with nested journals. So it's another big chunk of assumptions that will need to be removed before this will work. A more level-headed developer probably would have made everything unsorted to begin with and then add sorting later, but such is life. Right now everything is assumed to be sorted it's been this way from the start. Q: Can I drag entries around inside of journals to reorder them? 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. This will be coming in the very next version of MacJournal after 2.6. This is a big change inside of MacJournal and it needed to happen slowly in order to protect your data. To see this for yourself, use Chrome to play with the following code.Q: Can I put journals inside of other journals? Browsers (with the exception of Chrome) only fire clipboard events when there is a valid selection and focus on HTML elements.These are fired when a user presses the keyboard shortcuts or uses the browser’s menu. In general, you can only access the clipboard during a system cut, copy, or paste event. Because of this, browsers limit access to the clipboard. There are several security issues with letting a web page access the system clipboard.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |