Dear Immi, > (a) When I have a thin selection (which happens often if I have some > small text, which I select by clicking on it) and I want to move it, I > often accidentally resize it. Therefore, for thin selections, I'd make > (in start_resizesel()) hmargin resp. vmargin smaller. If then resizing > becomes too difficult, one could increase resize_margin accordingly. > (Picture attached.)
This sounds reasonable. The other option is to cheat and enlarge the selection rectangle (as displayed, and as stored in the user interface data) regardless of the actual selected contents, so that it never gets too thin. Not sure which one would be most user-friendly. > (b) I often use graph paper when drawing, but then I don't want that > graph paper background to be exported to pdf. So it would be handy to be > able to turn out the graph paper in the "Export to PDF" dialog. (And > maybe one wants to save the option for that somewhere? Either in the > preferences or in the document?) Stop. Already done. Options -> Print Paper Ruling. If unchecked, then the horizontal lines of ruled paper and the grid of graph paper do not appear in printing or in PDF export. > (c) I often use xournal to create small drawings which I then want to > export on a paper size which corresponds to the size of the drawing. To > make this more handy, I'd like to implement a feature "set paper size to > size of drawing". Alternatively, this could also be an option when > exporting to pdf. Sure! I think this belongs in the Page menu, not in the PDF export -- it should affect the xoj pages already, not just the exported PDF. Perhaps it should be an item inside the Paper Size dialogbox rather than a standalone menu entry -- not sure. I think my preferred name would be "Crop page to contents" if it's a new menu entry, or even shorter "Crop to contents" if it's clear that we're talking about the paper size. There should be some small margin amount kept around the page contents, perhaps set in the config file, with a default value of about 5 points or so maybe, to allow both for the width of strokes and for aesthetic reasons in general. When Page -> Apply to All Pages is set, the resizing action should resize every page of the xoj to its contents. I have no idea what this should do on a page that has a PDF or bitmap background -- perhaps no action on pages that have such a background, as likely we don't want to change the margins. [Or rather: another feature request has been to allow for extra margin space around a PDF background page, if this ever gets implemented then cropping would allow one to shrink all the way to either the PDF page size or the closest annotation to the edge, whichever one comes first.] > (d) I'd like to have some variant of the text tool which does automatic > line wrapping. Indeed, when annotating pdfs, I often write text onto the > margin, which means (since there's not a lot of space) that a lot of > line wraps are necessary. Doing this by hand is always a bit annoying. Good idea. I agree this is needed. Technically one should check whether both types of widgets used to draw text (the GtkTextView used for editing and the GnomeCanvasText canvas item used for showing the text when not edited) can handle wrapping. The latter cannot, I think. There is also a GnomeCanvasRichText which seems to handle wrapping but it might not handle fractional font sizes (just like the GtkTextView can't, this is why text boxes change size/shape a bit when one edits them). I think when I first implemented the text feature I had some good reason not to use GnomeCanvasRichText as I was unhappy with something about it, but I can't remember. Before proceeding with wrapping, one should test thoroughly what happens if make_canvas_item_one() is modified to use a GnomeCanvasRichText for the text items, and whether there are noticeable display differences (eg: fractional font sizes? not having an opaque background? cropping to the page? not sure what else). If there's nothing bad then wrapping is realistic to implement. The printing / PDF export engines also need to be adjusted to handle text wrapping. We use pango_layout_set_text() which seems to handle wrapping if asked to, so it should be okay. (The code in the legacy pdf-export may need some further tweaking). > I'm not yet entirely sure how this alternative text tool would work, but > right now I'm thinking of the following: If, using the text tool, > instead of just clicking somewhere, one drags, then the horizontal drag > distance determines the width of the text. This is reasonable. In principle the horizontal and vertical distances together might even determine an initial size of the text box, but we could imagine that preconstrained text boxes auto-expand in the vertical direction. > There should of course also some way to change the width a posteriori; I > don't know yet how exactly to do that. Maybe while editing the text, > there could be a "handle" on the right hand side which one can move with > the mouse to change the width (and maybe also one on the left hand side?). Yes, this is a reasonable option -- to have text boxes in editing mode behave like a selection rectangle and allow resizing. There are going to be some serious trickiness issues related to XInput however, because of the way in which XInput is emergency disabled during text edition to avoid GTK bugs. You'll also have focus issues, as the text edition widget grabs the focus for clicks inside its own area, hindering the work of your proposed resize handles unless they're clearly outside of the text widget. So while this is a reasonable UI mechanism from the user perspective, it might not be easy at all to implement in a completely reliable manner. If implementing it while the text box is being edited turns out to be too tricky, the simplest technical approach would be to have the "resize selection" feature do that: if the only selected item in the selection is a wrapping / fixed-width text box (as would be the case if clicking into the text box with the select tool, rather than actually selecting something), then one could imagine that resizing the selection modifies the rectangle of the text box without changing the font size, instead of the current behavior. (Changing the font size can be done easily by other methods, e.g. selecting the text box and changing the font size in the font chooser; or doing a selection resize on a selection that contains more than just the text box). > (One could then even think of making it possible to choose between > different justifications (both/left/centered/right).) There is no end to the list of features one may want to add to the text tool. You can go full word processor if you dare, but the realistic thing is to stay inside the intersection of the features easily available for the on-screen renderer (gnomecanvas), the on-screen editor (gtktextview), and the pdf/print renderer (pango_layout_...). > (e) I'm using the "touchscreen as hand tool" feature, but I'd like to > improve it: I'd also what that it behaves like many other touch screen > aware programs in the way that you can "give it a kick" so that it goes > on scrolling for a little while. (That's much more handy when scrolling > over long distances.) That of course means that the finger does not > behave exactly like the hand tool, but rather is something separate. Not so easy right now, because xournal is not time-aware so you can't tell easily if a sequence of touchscreen events is a long slow scroll or a quick flick. Of course, input events have timestamps so this should not be impossible -- but that part of the code is already complicated enough. If you want to do this for touch gestures then I think the hand tool should do it too -- why not give a kick with the pen or with the mouse as well if those are the input devices being used to work with the hand tool ? The hand tool should morally behave like a touchscreen, whether it's being used via a touchscreen or something else. So: in the hand tool code, when starting a hand tool (look for "ui.cur_item_type = ITEM_HAND" in xo-callbacks.c) one should not just set ui.hand_refpt but also record the timestamp of the event for future purposes... but I'm not sure exactly how far you'd want to keep scrolling, and whether you'd just want to paralyze the rest of the user interface while we do this, or how to handle things if the user starts drawing while you still wanted to keep scrolling? I have not seen convincing hand gestures of this sort in applications that allow editing rather than just viewing. Because of the interaction between scrolling in such a manner and drawing immediately after a touch gesture (or imagine a spurious hand touch as you're about to start writing with the stylus!!), I am not convinced that xournal is a good place to start thinking about this. > (f) At some point, I'll probably do some experiments with further > optimization. > > Comments/suggestions? > > (I'd probably start by implementing (a), because it's easiest...) Yes, (a) is easiest. (b) is already done. (c) and (d) would be interesting, but (d) is a significant amount of work. I am not convinced about (e). Best, Denis ------------------------------------------------------------------------------ _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
