Hi Daniel, Thanks for the message. I'm writing with a 3-week-old baby next to me = not sure that I'll actually get to do anything on xournal in the coming weeks, but feel free to nudge me from time to time.
> - Support for metadata in Linux via gvfs to store latest page opened. Leaning against -- the more I interact with gvfs, the more I want to stay away from it. > - Support to add latest page in the MRU (specifically for cases where > gvfs is not available). gvfs has priority over MRU. I think I'd be interested in doing it this way. (As an optional feature that can be turned on/off by the user.) > - Added support for 'dot' type paper. > http://www.printablepaper.net/category/dot > Many of the parameters for the paper style are hardcoded. It would be > nice to move them to the config file, such as spacing. Leaning against, there's so many paper types one might want to add, and it seems easier to tell users to make a .pdf template. The other possible thought (but it requires more work and might not be worth the trouble) would be to move the paper templates into .xoj templates (since all those I'm aware of are made of straight lines on top of a solid background) and then it'd be user-extensible. The plan would presumably be to make it possible to store strokes in the background layer (but keeping it non-editable). This way, people could implement their favorite changes to line spacing, color of the lines, whatever, without having to patch the code. (Though, arguably, pdf templates aren't much of a hardship, which is why I'm really not sure whether it's worth the trouble). > - horizontal scroll lock (when scrolling down, fix X offset). Not sure it's worth the trouble -- after all, many users have the view wide enough to contain the paper width (then no problem), and many others may be using either the keyboard or a scrollwheel or a scrollbar to do the scrolling. This presumably leaves a small minority of tablet users in need of the feature, and I'm not sure it's worth cluttering the UI (even very minimally) for this. > - A5 paper size (I know we mentioned it before, I am ok if it does not > make it). But it is a really nice size for 8 and 10" tablets. Tend to agree. I'm not keen to add a million paper sizes, but A5 seems like a reasonable candidate. Is it ok to keep the paper ruling sizes the same as on A4 or letter (i.e. have fewer lines?) ? > - Snap-to-grid. It is based on two variables (in the UI: boolean Snap to > Grid--defaults to false, and snap_separation). Potentially interesting, but I'm worried of the pitfalls -- people will probably want the grid to magically match the underlying paper or stuff like that, it seems difficult to make it completely user-friendly. I should test your version at some point. > This is a feature that I'll probably code soon, since I just discovered > it and find it very useful to prepare notes for my students: > > - Add an option in the menu to enable/disable printing/exporting > to PDF the paper type. Should already be there, though it only affects the plain/ruled/lined/graph papers. Options -> Print Paper Ruling. Do you see a use scenario for wanting to also remove the pdf background? (I guess there is, due to the above discussion of paper styles: pdf paper templates! but I think it'd be too confusing.) > Also, i have found some bugs: > > - Once in a while, the main pointer (mouse or touch) stops > working in dialog boxes. I does not seem to matter if I select 'pen > disables touch') Interesting. Quite possibly an xinput-related issue. I haven't encountered that one, though there are enough overall reports of occasional glitches with UI responsiveness that something is suspicious. > Now, some that are usability related: > > - The apply-to-all pages does not work for PNGs. This was intentional, because I assumed people would want manual control of their PNG or PDF backgrounds. Perhaps one needs to figure out which portions of apply-to-all-pages should or shouldn't apply to PNG or PDF backgrounds. My impression is that some operations like resizing paper presumably should apply there, while others like re-coloring the paper or changing the lined/ruled/graph style might not. But maybe I am wrong ? I think some brainstorming about what is or isn't desirable is needed. My use case for PNG backgrounds is usually inserting a page with a screenshot of some other application (e.g. a web browser page) in the middle of a xournal document that otherwise has plain paper; these are kind of like post-it notes in the middle of the journal, and are not meant to ever get printed, so I care more about their on-screen readability and aspect ratio than about the paper size matching the rest of the document. This use scenario is the reason why apply-to-all-pages affects the "regular" journal pages but not the png's, and similarly why the pages scale to the png rather than the other way around. > - There needs to be an option when loading a PNG to scale it to the size > of the paper. Currently (and I had to read the code to understand it) > PNGs are scaled 1-to-1 depending on display_dpi and the paper > size. Say my page 5" long, and my display_dpi=100. I have a PNG that > is 1,000 pixels long, then when I apply that png as a background the > page ends being 10" long instead of 5" long. Yes, you are right, the paper is scaled so that at the "standard" resolution 1 pixel = 1 pixel, so that the display is maximally crisp (no excessive anti-aliasing by rescaling or shifting the png by fractional pixels). I came up with this in the early days when displays were not as high resolution as they've become, and it really made a big difference for annotating screenshots. I agree that an option to toggle between the two behaviors (scaling page size to the png size, vs. scaling the png to the existing paper size) is a good idea. What do you envision doing when the aspect ratio of the png doesn't match that of the paper -- is width or height the most important, or do you want to scale in both directions and sacrifice the aspect ratio? > - It would be nice to be able to reorder colors in the UI based on the > config file. Good idea. Shouldn't be too hard -- by not using any fancy library to generate the UI we're stuck with primitive methods, but moving widgets around based on the config file is definitely feasible, cf. the interface_vorder setting to move the toolbars/menus below/above the main drawing area. Something similar could be done to the color buttons (and corresponding menu items), and it should be possible to implement it in exactly the same manner. Best, Denis -- Denis Auroux UC Berkeley, Department of Mathematics 817 Evans Hall, Berkeley CA 94720-3840, USA aur...@math.berkeley.edu ------------------------------------------------------------------------------ _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
