calibre 5: Beta testers needed

[kovidgoyal]

Originally Posted by jony08

The annotations are not synchronized with the main view from the server and vice versa. Am I doing something wrong? I tried clicking on the Sync button in the controls.

You need to tell the viewer which server user to sync with in the miscellaneous section of the viewer preferences.

[jony08]

Originally Posted by kovidgoyal

You need to tell the viewer which server user to sync with in the miscellaneous section of the viewer preferences.

I understand. Can the local calibre user be the default if no user has been set even if another user logged in to the server? Could the setting be a dropdown menu? I think it would make it less confusing for other users as well.

[jony08]

Originally Posted by jony08

Bug 2: If you select an image, the image will be blue.

The images still turn blue when selected, can this be fixed?

[kovidgoyal]

Originally Posted by jony08

The images still turn blue when selected, can this be fixed?

That's how browsers behave.

[jony08]

Originally Posted by kovidgoyal

That's how browsers behave.

OK, I understand.

Is it possible that you could add the option to delete/export all annotations from the selected book in the Browse annotations window?

And add the option to delete all annotations from a chapter in the Browse annotations panel.

[davidfor]

Originally Posted by chaley

Found it, I think. The inlined raw_field didn't handle None-valued fields properly.

If you are willing, try using this code:

    def do_node_raw_field(self, prog):
        try:
            name = self.expr(prog.expression)
            res = getattr(self.parent_book, name, None)
            if res is not None:
                if isinstance(res, list):
                    fm = self.parent_book.metadata_for_field(name)
                    if fm is None:
                        return ', '.join(res)
                    return fm['is_multiple']['list_to_ui'].join(res)
            return unicode_type(res)
        except ValueError as e:
            raise e
        except:
            self.error(_('Unknown field {0}').format('parse error'))

It goes in utils.formatter.py, replacing the existing method starting at line 387.

EDIT: Kovid accepted the change. It is in source now.

I updated the source, and it no longer gives an error. But, with the column template as just "{:'raw_field('#pages')'}", I get the word "None". I was expecting an empty string, but, I don't remember what it was before.

[chaley]

Originally Posted by davidfor

I updated the source, and it no longer gives an error. But, with the column template as just "{:'raw_field('#pages')'}", I get the word "None". I was expecting an empty string, but, I don't remember what it was before.

That is what it did before. I have considered changing it but that could break a lot of stuff.

[jony08]

I do not know if I fully understand the complexity of annotations, but if there is no way to do this: please add an option to the User accounts on the Content server to always see annotations taken by the local user. I thinks that it would also be useful to be able to share annotations between different users. Maybe it is too much work to implement to see other users' annotations at the same time, can it instead be possible to copy/move annotations to other users?

I tested and found that the annotations are always saved for the local user and that you can choose to save the annotations to another user as well, can this be extended to save for more users or all users? Is it possible to only show an annotation once in the Annotation browser list when the same annotation is also saved to another user?

[nixsee]

When I start reading a (good) book, I tend to do a lot of highlighting, which I then aim to make more concise when I go back and re-read/grapple with the book. Perhaps this is a foolish process (and I'm open to any suggestions of better methods), but it is what I do.

As such, sometimes I have highlights that are back-to-back. Right now, they appear as one large highlight. So, it would be great if there were some sort of markers to demarcate them. My suggestion is to make use of the existing "Annotation White Dot" to signify the start and/or end of a highlight, and a colored dot to signify the start/end of an annotation. An example is in the attachment below, where it would otherwise be impossible to know whether it is 1, 2, or 8 separate highlights.



On second thought, it would be better with just a single trailing dot - as it is currently implemented for the white annotation dot.

An alternative would be to remove the margin/padding for the highlights so that there are no blank spaces between lines. But this is likely to be messy with indents and line endings, so I prefer the dots.

[nixsee]

Another request/suggestion: could there be some settings to change the font that is used in the annotation pop-up? I'd like a smaller font size and no monospacing. For that matter, I'd like to be able to increase the font size in the secondary Edit Notes window as well.

[jony08]

Bug 1: Making a new highlight that overlap an existing highlight will remove the existing highlight.

Bug 2: When removing a highlight by selecting it and clicking remove in the selection bar, the handles will be kept at the same place where the highlight was but the only the last part of the the text between the handles will be selected.

[kovidgoyal]

Originally Posted by jony08

Bug 1: Making a new highlight that overlap an existing highlight will remove the existing highlight.

Not a bug. You cant have overlapping highlights.

Bug 2: When removing a highlight by selecting it and clicking remove in the selection bar, the handles will be kept at the same place where the highlight was but the only the last part of the the text between the handles will be selected.

Will be fixed.

[kovidgoyal]

@nixsee: There is no monospaced font and no you are not going to get a config option to control the font size of individual UI elements, ever. There are limits to how much configurability I am willing to implement.

As for not knowing where one highlight starts and another begins, use different colors. Adding margin/dots whatever is both expensive and looks ugly, as it change the size of the text, thereby causing reflow.

@jony08: Annotations cannot be copied between different users, except by export and import. I am not going to implement automatic copying that's insanely confusing.

[chaley]

Originally Posted by davidfor

I updated the source, and it no longer gives an error. But, with the column template as just "{:'raw_field('#pages')'}", I get the word "None". I was expecting an empty string, but, I don't remember what it was before.

New version of the formatter pushed. This one fixes an incompatibility between the infix compare operators and the cmp function. Cmp turns undefined into zero then compares, where the infix ops used to turn any compare involving undefined into False.

Thanks much for helping find the corner cases!

[nixsee]

@nixsee: There is no monospaced font and no you are not going to get a config option to control the font size of individual UI elements, ever. There are limits to how much configurability I am willing to implement.

That's fine regarding no font size configuration, but it definitely looks like monospaced font to me, and a web-based Font Identifier tool concurs... See picture below:



And here is how it looks for me with the secondary Edit Notes window - the font is not monospaced and is a considerably smaller size.



At the very least, could the font style be consistent between the two, and the size perhaps somehow tied to your general viewer settings?

As for not knowing where one highlight starts and another begins, use different colors. Adding margin/dots whatever is both expensive and looks ugly, as it change the size of the text, thereby causing reflow

Using different colors for adjacent highlights is not a solution at all, because colors/styles have meaning in my system. If dots are too ugly (which I don't find to be the case whatsoever - they're quite an elegant solution that you came up with for this problem) or too expensive, why did you implement them to begin with for annotations?

I agree, changing the margins would indeed be uglier. But it wouldn't be expensive. It was simply an alternative.

So, given that dots are already implemented for annotations (which I'm grateful for), I don't see any reason not to implement a different-colored dot for non-annotated highlights.