Beta release of FocusWriter

I have made the first ever beta release of FocusWriter, version 1.3.80. At this point I will not be adding any more features to the next feature release of FocusWriter. I have been meaning to start making public betas for my bigger projects, and the hiccups with the recent release of Kapow has just reinforced that decision.

I have added the beta as a separate bubble on my website that is just straight hyperlinks. This way you can still download the latest stable release (1.3.6) if you do not want to try the beta.

Now, there are a few bugs with this beta. The most noticeable is that sounds effects are broken in Windows. Please don’t tell me, I know, and I will fix it shortly. There are a few other known bugs, but they should not affect anywhere near as many users. This beta is to find bugs I don’t know about, especially with any of the new features.

This beta is the last release that will include dictionaries. When I first added spellchecking to FocusWriter it had very few translations, so I included their respective dictionaries and thought nothing of it. As more and more translations have been added, however, I have to reconsider that decision as they now take up over 60 MB on disk! With the switch to native spellchecking on the Mac, Windows is the only platform that needs those files. I will be adding downloads for dictionaries to my website so that you can get them at the same time you get FocusWriter.

I know that some of you have really been looking forward to getting your hands on the new features, and now is your lucky day! Enjoy!

Advertisements

8 Responses to Beta release of FocusWriter

  1. Todd Lucas says:

    Thank you, Graeme.

    Everything looks and works beautifully (especially since you’ve added customizable shortcuts). I’ll have a set of comments about stuff later, I’m sure. Found one thing right off that might be a bug, but I’m trying to figure out how to replicate it elsewhere before I bring it up, mainly because its ridiculously small and super easy to work around.

  2. Graeme says:

    Glad you like! I’m interested in the details of the bug, even if you can’t replicate it.

  3. Todd Lucas says:

    Here or on github?

  4. Graeme says:

    Either would do. If you think it is really a bug, then github is more appropriate. If it is something that is just behaving oddly, then feel free to describe it here as I can always create a github issue if it turns out to be more complicated or serious.

  5. Todd Lucas says:

    After playing with it enough, I’m finding that its a few related things concerning the scene list and most are not hard to reproduce.

    What seems to be happening, frequently, is that when you move a scene, instead of showing up as an entry on the list where you’ve placed it, the scene text is moving in the document and just sorta gets appended to the scene before, as far as the list is concerned. This generally clears up by going out of the list, moving the cursor up or down then going back into the list.

    Now, I don’t know if this happens with a real doc with full sized chunks of text as scenes or not, but making a little text doc with 2 scenes, with the marked line and one other line of text, if you move the top scene down, it disappears from the list, though not the actual text, as described above. However, if you grab the remaining scene and drag it around (yes, I understand there’s no actual place to move it to since it is the only entry on the list at that point), I suppose it tries to append to nothing, and at that point there are no entries on the list and no text in the file at all. That one’s a bit scarier ;-p

    Another minor glitch is that if your margin is low enough that the scene list area dips into the bottom bar, it will grab and hold part of the tab graphics after you mouse into the bar and back out. If you move to the filter field, it overdraw’s that garbage but just for itself, leaving tabs with the filter bark carved out of them. Of course closing the list and reopening it clears the glitch, but still, its a glitch.

    The focus mode works nicely, but you can force it to act up ever so slightly. Change themes that mess with how much text is displayed in some way from the one its currently in, and it will keep the exact same set of character focused, regardless of how many lines they span under the new theme. This of course updates to your selected setting once you mouse in or move up or down, but there it is.

    Good enough for now, I think đŸ™‚

  6. Graeme says:

    Thanks for feedback!

    I’m troubled by the issues with rearranging the scenes. I spent a long time fixing those same issues before, and having them reappear makes me concerned that I won’t be able to solve them completely (in which case the only option I will have is to remove dragging scenes until I am sure that it is safe).

    The other issues you listed are pretty minor and I think should be quick to solve.

  7. oalinga says:

    BUG-REPORT
    Great work!
    #1: First a little suggestion: please add a short-cut for visualizing the scene-sidemenu.
    #2: when I hit alternating the ctrl+shift+up und ctrl+shift-down shortcuts in the scene-sidemenu to move scenes up and down, they disappear … and also the text in textarea disappears…
    #3: finaly a whish: please add a preference for file-format (at “save-as”). I (and I think many other people) use plain-text-files instead of odt-files.

  8. Graeme says:

    #1: First a little suggestion: please add a short-cut for visualizing the scene-sidemenu.

    If you mean hide or show it, there actually is one: Shift+F4

    #2: when I hit alternating the ctrl+shift+up und ctrl+shift-down shortcuts in the scene-sidemenu to move scenes up and down, they disappear … and also the text in textarea disappears…

    That bug is related to the dragging scenes bug (since it just creates a fake drag-and-drop operation). If I can’t fix drag-and-drop, I will also be dropping moving scenes up and down unfortunately.

    #3: finaly a whish: please add a preference for file-format (at “save-as”). I (and I think many other people) use plain-text-files instead of odt-files.

    That’s a good idea, but it won’t be in 1.4 as it is a new feature, and it would also require new strings.