Hi Denis > A quick response: > >> Sorry Denis, everybody else. I have been quiet because I have been >> traveling and I have been using a macAir during these last weeks (in >> part due to its battery life, in part due to my X220 thinkpad having its >> battery dying--i hate how lenovo kills batteries while they are still >> useful). I might never buy a lenovo again.. we'll see... > > I'm pretty happy with my Yoga so far, even though it took time to get > used to the touch/pen interaction and to the lack of separate buttons > for the trackpoint.
I decided to install ubuntu 14.04 over the weekend... trying to get used to gnome-shell in the process :) I do like the x220 but I have to say, the weight of the new laptops make them very attractive are you using linux on the yoga? > >> I have been using the "hand as touchscreen" feature for a long time in >> Windows and I love it. It makes the interface much more natural (you >> write with one hand, scroll with the other). > > I'm also now addicted to "Pen disables touch". It's a lifesaver for me > -- no more inadvertent scrolling while I'm about to write. The only > slight adjustment needed was to learn to keep the pen close enough to > the screen so that the proximity isn't lost. I am not sure how well it > works in Windows, but I think the wacom driver does send proximity info > to GTK so it should also work there. (However on my Yoga when the pen is > in proximity windows already disables the touchscreen). > Ok, this I don't understand. Wacom disables touch the moment that the pen is within approximately 2-3 cm from the screen. what does this feature do that the Wacom driver does not? by the way, >> Ok, tested... one major bug that creates a crash. When you select the >> new device the code crashes because you try to free a non-allocated >> string (DEFAULT_DEVICE_FOR_TOUCH). This is a simple fix for that: >> >> diff --git a/src/xo-file.c b/src/xo-file.c >> index 59288bf..63d698c 100644 >> --- a/src/xo-file.c >> +++ b/src/xo-file.c >> @@ -1526,7 +1526,7 @@ void init_config_default(void) >> ui.poppler_force_cairo = FALSE; >> ui.touch_as_handtool = FALSE; >> ui.pen_disables_touch = FALSE; >> - ui.device_for_touch = DEFAULT_DEVICE_FOR_TOUCH; >> + ui.device_for_touch = g_strdup(DEFAULT_DEVICE_FOR_TOUCH); > > Oh! thanks for catching this very stupid bug. It didn't hit me because I > already had the appropriate line in my config file and so for me > ui.device_for_touch was an allocated copy of the string in my config file. > > [freeze at end of text edition in Windows] >> i have hit by it to the point that I don't use it. We need to check the >> code. I suspect that it is a function that is expected to return a value >> (potentially an error) and that is not being checked. I'll take a look >> too. > > I am alas still not able to reproduce the problem consistently. I > wondered at some point if it was one of the freetype/fontconfig/... > libraries trying to create a cache of all windows fonts in its own > format, and taking forever to do so; but now that it's been done on my > system things work smoothly. (That would be under the assumption that > what happens is a very lengthy freeze for a few minutes rather than an > actual infinite loop). However I haven't been able to locate any file > that could contain such a cache, so that's probably not the explanation. > (Also note that between the time that I had the problem and the time > that I no longer had it, I installed Office 2010 and Adobe InDesign, > both of which bring lots of font stuff with them; not sure why that > would have fixed the issue however). > mmm, let me try it... in the TP2 the CPU is very slow, and it wants to kill Xournal. I'll try to make it run for few minutes and see what happens. I read the code last night and I could not see anything wrong with it (it is fairly straightforward). >>> Another bug I'd like to figure out is the drawing area being >>> unresponsive to touch/mouse/... after drawing with the pen with xinput >>> enabled (and the wacom driver), until one clicks somewhere outside of >>> the drawing area. (There seem to be other variants of this >> >> I know what creates this (it is indeed a bug, but it is also the way you >> set the canvas at startup, if I remember correctly, I have to check my >> notes, since I spent some time tracking it). I'll have to look at the >> code, but one of the flags in it creates it. > > This one should be fixed in the current cvs/git. I'll check it. > >> but there is one that really annoys me and I haven't been able to figure >> out: text boxes that are "saved" as PDF are not readable in OS X, but >> text boxes that are "printed" to PDF work. it is argued that it is a OS >> X bug, but we if we can work-around it... > > I've been thinking of having another PDF production path that relies on > poppler, cairo, etc. (borrowing code from the Print feature instead of > the by-hand "Export to PDF" which is increasingly problematic on some > system), and a config option to decide which one "Export to PDF" tries > to use preferentially. (Print to a PDF doesn't seem to be enabled by > default in Win32, and anyway has the problem that it makes all pages the > same size as that set in the virtual printer). > I think this would very good. --dmg ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
