Refresh on resize only

[xuv]

Thanks for this great piece of software. I got interested in it following @n8willis presentation of it at #LGM2014 last week (so you know ;) ).

So I've compiled it and when I open a new file, I have to resize the window to actually see it. If I load another file after that, a resize or a scroll has to be performed to see the new drawing.

Thanks again for this excellent work. If I can be of any help, please ask. Although, I'm not a C coder, I can send you some WPI files if you want to study them.

[roelj]

Thanks for your interest. I didn't know it was being presented on the LGM.. :) What distribution (and which version) are you using? (If I can reproduce the behavior it's easier to fix it, and test it in future versions).

I have a couple of exams next week, so an actual fix could take a week or two.

[xuv]

Well, @n8willis did praise your piece of software. The video of it will come online sometime I guess. :)

Here's the output of uname -a: Linux localhost 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux It's actually the Crunchbang distro, which should not be different than Debian stable, I guess.

No worries about the fix. This "bug report" is more a way to get in touch with you and thank you for your work. It's also to tell you there is a community using it and that we are very interested about your progress in the development of this tool. :)

[roelj]

Well, thank you! It's motivating to see people use it. I'm installng CrunchBang to test it.

If there's any new feature you want to see, I will try my best to implement it.

Is there anything I can do to improve the communication between the people using it and myself? I suppose this could benefit the software.

[roelj]

The fix was easier than I thought it would be. This should now be resolved. Please let me know whether it works for you too.

[xuv]

Wow. Already a fix :) Great.

Well, @n8willis, who I hope is being poked by all these mentions, knows some other users, I guess.

About the features, what is on your todo list is good for me. Especially the 'online-mode'. That would be awesome. But I would definitly go for a command-line 'convert' feature with some options. So I could batch convert all my drawings to svg for example.

And about communication, I don't know. Github issues seems to work fine for me. :)

[xuv]

About the fix. Just works great.

[roelj]

Great! This is a response I received from a Wacom employee regarding "online-mode": "Thanks for the information. Unfortunately I have no details about the data format in Online mode. As there is no special driver installed, I think this works with mouse data and does not include pressure information. I will see, if I can get some info from the colleages."

Are you aware of the command-line options so far? You can combine command-line options to change the behavior (try --help for the details) and use --convert-directory= to convert all WPI files in a directory.

[n8willis]

Heh heh; yes, being poked. For the record it was really a lightning talk -- I mentioned some other aspects of using the device that I've picked up along the way, too. Fun to see that the hardware is usable for more people than I had thought.....

[roelj]

@n8willis Would you be interested in working together to either improve InklingReader or continue with your Python program? If it helps, I could write documentation for the code structure I've used so far so it'll be easier to hack on my code..

[xuv]

@roelj Thanks for the tip for the command-line. I had not taken the time yet to explore this feature. And so my batch wish is answered. :)

What I really like in your command-line todo list is the fact that we could get rid of the pressure data and just keep a simple stroke. This is a must for me.

Just thinking out loud also, this pressure data could maybe be increased or decreased by a user defined factor. Wondering if that would be possible.

Yet another maybe stupid question (and this bug report is turning into a huge thread), but is there "time" data in the WPI file in any way ? I mean, does the file has a record of some sort of "stroke speed" ?

@n8willis Your presentation convinced me to buy one of these tools. :) My artistic research lately involves "drawing machines". So your lightning talk struck a cord. :)

[roelj]

@xuv About non-pressured output: That won't be a lot of work, I'll get on it soon.

About the factor for pressure, right now it's already a variable in the code (which is set to a constant factor), so making it adjustable won't be much work either. I'll try to get onto this at the same time as the non-pressured output.

About timing data.. as far as I know this is not stored. There still is some data left that we don't know what it is or represents. But honestly, I don't think the data represents timestamps or anything related to the speed of drawing. The data is linear in the sense that whatever is written first with the pen, is written first in the file (therefore "playback" of strokes is possible).

[MeraX]

@roelj I'm not lost, but I have no time at the moment to further contribute code.

Non-pressure output and adjustable pressure output are almost the same: just set the constant STROKE_WIDTH_FACTOR to zero do deactivate the pressure-stroke-width function and set STROKE_WIDTH_FACTOR to any thing else for vary the width.

I made a new issue about the timing data: https://github.com/roelj/inklingreader/issues/8

[roelj]

@MeraX Good to see you here again! The only difference is that non-pressured strokes don't have to be rectangles (we don't need to draw a line backwards).

[MeraX]

Yes, thats what changes, when STROKE_WIDTH_FACTOR == 0 (or not !=):

The path object gets filling:none instead of stroke:none and there is no backwards drawn line. There are two

if (STROKE_WIDTH_FACTOR != 0)

for this in svg.c

[roelj]

@MeraX Great! Sorry I didn't remember the exact code in there.

EDIT: Ehm, I can't find STROKE_WIDTH_FACTOR or the checks.

[MeraX]

Oh sorry, I made this change two months ago in my local repository without pushing it back online. I'm sorry. Git and Github is relatively new to me.

[roelj]

I'm halfway there to apply the change myself in a similar way. I'm only thinking about keeping it modular and fairly loosely coupled so it can be easily extended with other features in the future.

[roelj]

Thank you @MeraX. I've made it configurable now. Setting --pressure-factor=0 will disable pressure data. The default is --pressure-factor=1.0.

[MeraX]

your welcome, thank you! can we close this issue?

[roelj]

All issues inside this topic seem to be either fixed or handled in a separate issue thread.

So I'm closing it indeed. For further discussion, feel free to open a specific issue instead.