Annotation tools are broken in hardy

I tried to use Xournal today (05 FEB 2008) and experienced the same problems that is described for Hardy. I -- however -- an using GUSTY.

I didn't use it previously because my recent update to GUSTY was on FRI, 01 FEB 2008. Prior to that, I was using FEISTY and had no problem with it.

Also of note, the GUSTY upgrade did break the function of my Tablet PC Pen. I have not troubleshot the problem with the Pen due to time.

I am using xournal on hardy. It has problems (notably drawings are not smooth). I can't use the mouse but only the pen if I check "use xinput" and it has badly crashed for me during a test, allocating so much memory I had to reboot the machine. However, i don't have problem #1 and problem #3. As far as I can see, problem #2 could in fact be the option "Tools/Eraser Options/Delete Strokes".

Carsten, could you try moving out of the way your .xournal and see if this changes anything?

If these problems are also confirmed with gutsy, then these must be rare bugs that have been present since release 0.4.1.

Today I tried xournal again with "Use XInput" deactivated (following your suggestion above) and now most things seem to work almost as on Feisty/Gutsy, except that the drawings aren't smooth as you already noted.

I also checked against my Feisty installation of xournal (0.3.3) and there the "Use XInput" option is not enabled by default. In fact, the corresponding menu entry is grey/deactivated. Since I don't have a tablet PC I can't check whether it would work with the pen.

So I think 90% of this bug (at least #1 and #3) could be fixed by just not making "Use XInput" the default or somehow have this depend on whether xournal runs on a tablet PC or not. Just moving away .xournal does btw. not help on my installation.

What remains are the slightly square-edged drawings and the eraser problem. I can considerably improve on the latter by choosing "Tools/Eraser Options/Standard". "Delete Strokes" on the other hand leads to the very strange behaviour mentioned above under #2.

The Use XInput option did get the annotation tools working for me also. Unfortunately, I haven't been able to get my tablet functions working yet, but I assume that since they work with mouse, they will work with pen.

Respectfully,
Arick R. McNiel-Cho

----- Original Message ----
From: Carsten Schneemann <email address hidden>
To: <email address hidden>
Sent: Wednesday, February 20, 2008 1:49:39 PM
Subject: [Bug 184996] Re: Annotation tools are broken in hardy

Today
I
tried
xournal
again
with
"Use
XInput"
deactivated
(following
your
suggestion
above)
and
now
most
things
seem
to
work
almost
as
on
Feisty/Gutsy,
except
that
the
drawings
aren't
smooth
as
you
already
noted.

I
also
checked
against
my
Feisty
installation
of
xournal
(0.3.3)
and
there
the
"Use
XInput"
option
is
not
enabled
by
default.
In
fact,
the
corresponding
menu
entry
is
grey/deactivated.
Since
I
don't
have
a
tablet
PC
I
can't
check
whether
it
would
work
with
the
pen.

So
I
think
90%
of
this
bug
(at
least
#1
and
#3)
could
be
fixed
by
just
not
making
"Use
XInput"
the
default
or
somehow
have
this
depend
on
whether
xournal
runs
on
a
tablet
PC
or
not.
Just
moving
away
.xournal
does
btw.
not
help
on
my
installation.

What
remains
are
the
slightly
square-edged
drawings
and
the
eraser
problem.
I
can
considerably
improve
on
the
latter
by
choosing
"Tools/Eraser
Options/Standard".
"Delete
Strokes"
on
the
other
hand
leads
to
the
very
strange
behaviour
mentioned
above
under
#2.

--
Annotation
tools
are
broken
in
hardy
https://bugs.launchpad.net/bugs/184996
You
received
this
bug
notification
because
you
are
a
direct
subscriber
of
the
bug.

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Quoting from upstream, here is a patch that should solve remaining issues after one installs the fix suggested in Bug #195953. So please install new wacom tools locally as suggested by first post there, and test the following patch if you can. I can't do this until 7th of april which is too late because I have to travel in the meantime.

===
Here's a patch for xournal 0.4.1 which should fix the Xorg 7.3 XInput
issues (or at least most of them). (To recover subpixel resolution one
still needs to upgrade X.org and linuxwacom to the latest versions).

The patch affects src/xo-callbacks.c only. It's also included in the
sourceforge CVS for xournal.

If you could please test that the patch works for you, and provided it
does, also contact the Ubuntu package maintainer to ask them to include
it into the Hardy package, that would be great. Thanks a lot!

(To check: drawing with all combinations of XInput enabled/disabled,
"Discard core events" enabled/disabled, both with the mouse and with
the tablet pen, should produce acceptable results. With the tablet
pen, XInput enabled, and upgraded linuxwacom + X.org, the strokes should
be as smooth as in the older distributions (better resolution than that
of the screen).
===

When I try to draw anything, Xounal starts to consume more than 800 MB at once.
I am using Hardy amd64.

Can anyone confirm that? Might it be related to the above problem?

Why is 0.4.2.1 still not packaged in hardy?

Upstream verifies bug exists (and is fixed)

Hi Dennis,

xournal 0.4.2.1 was released on March 28th, placing it after the FeatureFreeze. As 0.4.2.1 contains significant new features, a FreezeException needed to be filed, and would likely not have been accepted, especially since a patch to address this bug is attached. The previous packager who cared for xournal was out of town and wouldn't be back in time to successfully refresh the xournal package before the Final Freeze.

I like xournal, and would like to see Ubuntu do better in the future. Would the attached patch be appropriate to fix this bug?

Yes, the patch that was posted above is the simplest way to fix the bug.

(Not sure if it fixes the memory consumption problem reported by bmhm on April 30 - I haven't encountered that one, but it may well be a side effect of the other bug on some systems).

It would also be good to package 0.4.2.1 if possible (if too late for Hardy, then for Intrepid).
Denis

Short message:

please find xournal 0.4.2.1 in toshiba-tablet ppa

https://edge.launchpad.net/~toshiba-tablet/+archive

Please test and report.

For the MOTUs out there: I attach a debian/watch file, you know what to do with it, it works like a charm. Also I will attach the debdiff but please don't ask me to do bureocracy like using REVU, I already stealed 30 minutes from my ph.d. thesis and it's enough.

Long message:

Denis: I agree with you that the bugfix cycle in ubuntu has gotten far away realistic limits, however, xournal is a "universe" package, meaning that the "MOTU" are responsible for them. The MOTU is a big, and a reasonably open team in which one can enter after a while cooperating with ubuntu. Their activity should be triggered by bug reports, however since there are too much bug reports it is triggered by various events, such as an user attaching a patch _and_ going to IRC bothering some MOTU. What this means in the end is that the true responsibility for small packages like xournal has been (at least, in the last two years) almost completely given to users. However, we also have debian maintainers, since syncs with debian unstable of the "universe" section happen before every release.

This is the case for xournal in hardy.

http://packages.debian.org/unstable/x11/xournal

xournal in sid is still at 0.4.1 version, that's the problem. Proper maintenance of the package in universe would mean 1) prepare package for new version, 2) signal to debian, 3) wait for the new package to enter sid, 4) port to ubuntu. In the past, I've seen new releases directly in ubuntu but I don't know what's the current attitude.

Said all this, I created the toshiba-tablet team in order to keep things up-to date. Please Denis, subscribe to that team, it will not cost you a cent but will bring you closer to the matter. And thanks for your impressing work. The new shape recognition in xournal kicks *ss, guaranteed :)

Vincenzo

Latest attachment is a patch.

This bug was fixed in the package xournal - 0.4.2.1-0ubuntu1

---------------
xournal (0.4.2.1-0ubuntu1) intrepid; urgency=low

  * New upstream release:
    - allow XInput and core events in reverse order, LP: #184996, #234240.
    - also fixes LP: #226942.

 -- Vincenzo Ciancia <email address hidden> Sun, 18 May 2008 00:15:35 +0200

Uploaded.

Vincenzo: I have modified a bit the changelog entry to close bugs, hope you don't mind. also, it's better if you attach the new diff.gz instead of a diff between the old and the new packages (for the next time).

If the package is still broken in Hardy, you can request an SRU (the smaller the patch is, the easier will be to get an approval).
Thanks for the work.

I updated intrepid today and this bug seems to have reappeared in version 0.4.2.1-0.1ubuntu1

I am using 0.4.2.1-0.1ubuntu1 on intrepid. I think I have the same error. The annotation tools do not seem to work, furthermore using them (i.e. drawing something) causes xournal to use up lots of processor. Launching xournal from the command line, the only output I get is

$ xournal

(xournal:7000): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

(xournal:7000): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated

I dont think this output is relevant to the bug but I don't really know.

I would really like to get xournal working on my home machine (intrepid + macbook) ... I have started to use it regularly at work when reading articles. I haven't yet tried the above listed patches which seem to be for hardy but will report back if I get anywhere.

Seems to me that the problem you are mentioning is bug #272316 which should be fixed in up-to-date intrepid (please doublecheck). Is it solved by upgrading libgnomecanvas?

Wait a second: if you are using xournal with a mouse try disabling "use xinput" before clicking and see if it helps.

I can confirm that disabling XInput makes it work perfectly. When I leave XInput turned on, it fails in a variety of ways (memory usage, cpu usage, or just not drawing anything).

(gnomecanvas 2.20.1.1-1ubuntu3, xournal 0.4.2.1-0.1ubuntu1)