Hi Andreas,
First impressions of trying xournalpp (I still hadn't done so !!): it's
absolutely great!! Amazing work.
I'll look into the shape recognizer issue soon. Before that, I wanted to
do a tiny bit of general testing. Here's a list of the issues I noticed
after 10-15 minutes of playing with it (some of which you might know,
others not; some of these are serious, others are completely trivial):
- I also ran into the CairoOutputDev.h issue. Question: does this file
actually change from one poppler version to another one? if it doesn't
you could package it. If it changes, any way of having the configure
script test for poppler's version and decide whether we want to use our
own copy of the file (for new poppler) or poppler's (for older poppler)?
- The menus are mostly in English but partially in German ("Datei",
"Bearbeiten", "Ansicht", "Hilfe" in the menu bar). Do you know why?
I checked many parts of the interface localize well with LANG=..., many
remain always in English (fine for a first release), but those are
always in German...
- Select region: when I move something I've selected, the selection
rectangle moves with the pointer but the objects selected often move at
a different speed (!!!). Also, sometimes, the objects "teleport" when
selected, and "teleport" again when the selection rectangle is reset.
There's clearly a problem with the refresh of the display when selecting
/ moving selections.
- Select again: if I select two strokes of different colors, then move
the selection, everything that was selected becomes of the same color.
- Select again: if I select a highlighter stroke, it becomes invisible
while selected (it becomes visible again after resetting the selection)
- Undo/redo of "selection move" operations doesn't refresh the display
properly (it updates the region where the object is moving to, but not
the region where it is coming from, so two copies become visible).
- [NOT IMPORTANT] Text tool: when a text box is being edited,
right-clicking in it doesn't bring up the context menu to allow me to do
copy-paste operations. This is possibly related to xinput, I am not
sure. Or perhaps you are not using a GTK text edit widget but a
different widget without the copy-paste capabilities?
- [USEFUL BUT NOT URGENT] There's a few UI quirks in xournal's logic
that I think are very user-friendly and you should consider reproducing.
The two I noticed to be missing so far:
1. one can always create a new page simply by pressing the "next page"
button while on the last page. This is much easier when taking notes by
hand than having to go into the menus. You should consider it.
2. clicking inside a selection rectangle, even with the button that
would normally give me the pen, still moves the selection. In other
terms, "selection move" is not a feature of clicking with the selection
tool inside a selection, but rather a feature of clicking with *any*
tool inside a selection.
- Important: there's no dialog that pops up when destroying an unsaved
document (the equivalent of xournal's calls to "ok_to_close()" upon
quitting, opening a new file, etc.). This is a safety problem...
- [very minor but I mention it in case it sheds light on some other
issues]: when I draw a stroke, at the end of the process you of course
refresh the rectangle that contains it; this often causes the paper
rulings to be re-antialiased differently (so the blue lines on the paper
sometimes look sharp on most of the page but slightly more blurry near
where I just drew). This is probably an issue caused by shifting the
coordinates by a non-integer number of pixels that gets rounded to the
nearest integer somewhere).
- related but more important: you need to cache the cairo-rendered PDF
of the currently visible portion of the page currently being drawn on. I
have various PDF files where rendering a page by poppler takes at least
2 or 3 seconds (produced by PDF conversion from powerpoint, don't ask me
why they're so slow); in xournal this slows down only switching to a new
page or zooming, but in xournalpp this causes the interface to freeze
completely after each stroke drawn while poppler tries to re-render the
relevant rectangle of the pdf file. [Such PDF files are rare enough that
this isn't an issue for the alpha-version but will be an obstacle to a
general release]
Sorry to be pointing out all these things -- once again, overall you've
done an amazing job so far, and it looks to me that with just a bit more
testing / debugging, this'll make a great alpha or beta release!
Denis
On 02/12/2011 02:08 PM, Andreas Butti wrote:
> Hi Denis
>
> I finished now the eraser, it works now with every line.
>
> If the line (or a part of it) is to long (longer than the half of the
> eraser size) the line gets internally splitted up into 1/4th of the
> eraser size, so you can also delete a part of a long line without problem.
>
> With vector geometries I can find out which part has to be split up. If
> you release the eraser al unnecessary points will be removed, so that a
> straight line will only contain two points.
>
> Under normal circumstances this works good, if you have a lot of long
> lines, e.g. you "fill" a page with one stroke this is slow, but usually
> you don't do something like this, if you are writing or drawing you need
> more than one stroke...
>
> => For the moment I will say the eraser is finished, but has still
> potential to improve, but it needs a lot of work to do this, e.g. draw
> only a part of a stroke, but I'm not sure if this brings a lot, because
> the calculation is complicated.... A better Idea would may be a better
> caching, but this needs a lot of work also;-)
>
> Another problem I found out is that our undo / redo stack is not
> limited, I think we should ad a limit property, e.g. 100MByte... You can
> easy create a 100MB stack with the eraser if you are playing;-)
>
>
> But now why I'm writing: I ported the shape recognizer to Xournal++, but
> It's not correct working.
>
> I splitted the shape recognizer up into different classes, all classes
> are in src/control/shaprecognizer/...
>
> It works with circles correct, all as expected. It works with lines
> sometimes, but usually the line start is on the wrong position, so the
> line is to long. And poligons are not recognized at all, even there is
> this debug output:
>
>> ShapeReco:: Polygon, 4 edges:
>> ShapeReco:: 0-14 (M=65, det=0.0056)
>> ShapeReco:: 14-52 (M=104, det=0.0019)
>> ShapeReco:: 52-81 (M=73, det=0.0069)
>> ShapeReco:: 81-116 (M=96, det=0.0047)
>
> I would say he recognized my rectangle?
>
> I copied your code into classes, but I didn't change it, I had only to
> adapt the interface, because I don't use "double *" for points, I use an
> array of "Point" for handling (Point contains: double x and double y).
>
> If you have time can you may look into my code? Xournal++ is nearly
> finished, only two big points are open, stroke recognizer and PDF export.
>
> I think the stroke recognizer is nearly working, there is only a little
> missing / wrong...
>
> The PDF export is also working as long there is no image or embedded
> font (Poppler export every font as embedded font;-)) so I would say we
> can release the first Alpha if this points and some little changes are
> done, what do you think?
>
>
>
> Andreas
--
Denis Auroux
MIT Department of Mathematics aur...@math.mit.edu
(on leave) and
University of California, Berkeley aur...@math.berkeley.edu
Department of Mathematics Tel: 510-642-4367
817 Evans Hall # 3840 Fax: 510-642-8204
Berkeley, CA 94720-3840
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
