A better drawing app?

[brianinmaine]

1) I have the KUAL drawing extension:
https://www.mobileread.com/forums/sho...d.php?t=195050
- works OK, only have a thin pencil line the draw with.


2) I can kindof run http://mrdoob.com/projects/harmony/ in the Midori extension (see https://www.mobileread.com/forums/sho...d.php?t=185721)
- works, but not very well. shades and styles of brushes are real issue.
- I was not able to get the page to work with the default browser?

3) I tried running mtpaint from Debian with Xephyr: works, opens a default 640x480 canvas, might be worth further investigation if nothing better.

also from Debian with xephyr:
xpaint - no display on top of xephyr?
mypaint - can't get it to install?
pinta - messed up my apt-get stuff (won't be trying that again!).

As a side note I used twobob's excellent script:
https://www.mobileread.com/forums/sho...d.php?t=200017 to get the libs I needed. I did a debootstrap into a directory instead of an image and copied qemu-arm-static there so I could chroot there, then I copied all the kindle libs there to another directory and modified the script to grab what I needed.

I guess the question is:
What is the best way to continue? The harmony in Midori works a little, but mtpaint could probably be fixed up better. I'm thinking full screen without xephyr? Any hints or advice? Any other programs I can try?

[twobob]

http://packages.debian.org/wheezy/kolourpaint4 is a kde thing
as is http://packages.debian.org/wheezy/krita which might be too big

http://packages.debian.org/wheezy/mtpaint appears to have a few (at least one) floating toolbar - the naming conventions or DISPLAY=:1 may have caught you/xephyr out for showing it all on a smaller screen.

I think http://packages.debian.org/wheezy/rgbpaint is not a terrible place to start.

http://mtpaint.sourceforge.net/rgbpaint.html

[twobob]

https://code.google.com/p/ardesia/ perhaps.

[twobob]

So I got rgbpaint and ardesia to run. in a fashion. ardesia is a struggle with its floaty toolbars. and its demand for xcompmgr. but it is runnable. I cheated and checked with a debian.

I can probably bundle up rgbpaint now, still needs love.

and an exit strategy.
A power button cycle monitoring dbus strap-on is required.
doable. I could look at that.

Could be run native but the save stuff wouldn't work natively as-is though. problem. so not native without a bit of a recode.

wrapped in a Xephyr those issues all go away though obviously.
so yeah. nothing perfect yet but a few early lo-effort contenders.

rgbpaint in a xephyr pictured. could do with fullscreening too...

[brianinmaine]

Originally Posted by twobob

So I got rgbpaint and ardesia to run. in a fashion. ardesia is a struggle with its floaty toolbars. and its demand for xcompmgr. but it is runnable. I cheated and checked with a debian.

I can probably bundle up rgbpaint now, still needs love.

and an exit strategy.
A power button cycle monitoring dbus strap-on is required.
doable. I could look at that.

Could be run native but the save stuff wouldn't work natively as-is though. problem. so not native without a bit of a recode.

wrapped in a Xephyr those issues all go away though obviously.
so yeah. nothing perfect yet but a few early lo-effort contenders.

rgbpaint in a xephyr pictured. could do with fullscreening too...

Nicely done - had a busy weekend so I didn't get to try rgbpaint yet, I was just trying to see if anyone else had a better idea. Thanks for the ideas so far. I'd also like to see it fullscreen, not sure how to do that? I still never tried to compile anything for the Kindle... This would be a great time to learn, I'm sure!

[twobob]

okay I got rgbpaint fullscreen and much tidier.
using the unreleased "fronter" to patch around naming issues.

KCheckers also works well via this method.

[brianinmaine]

You are just too fast! Share please!

[twobob]

okay. Was just trying to check if this new "fronting" method works reliably enough to share it.

Will do then mate.

[twobob]

So the fronting method:

Well. it's not an exact science and doubtless someone will improve on that I have but:

In essence make a small patch to a loop-mounted COPY of one LUA file.
Restart window manager.

This provides a FAT based hook to do some window manipulation via scripts.

The patch file, an install process, the mounting process, the scripts, the binaries and the libs to all achieve this I now have.

It's a two pass solution - and not for any good reason.

First it will read over the name of the window being added (xdotool is a bit flaky here when it comes to generated subwindows so we need a second pass sometimes to ensure we get all the window names and their linked internal ID's)

Then we refactor that window name into something more conventional and re-inject the window back at the top of the stack.

The loop mount is just a fail-safe to prevent system corruption and will survive until the next major reboot. including surviving awesome restarts.

The installer process manages the mounting and can be safely run more than once.

I'll look to package up what I have.

The crux of all this is that you can from that point onward - Launch a window - With the WRONG naming convention - and have it handled by the native awesome installation.

Effectively paving the way for running a whole host of apps straight out of debian.
And removing the reliance on Xephyr.

It's far from perfect. and in some cases it is slow to recognise sub-windows. but it's what I got.

[twobob]

Kind of torn what to actually use the top ETCL menus for.

"Exit" is a given. "Application (focus)" seems helpful,, "Keyboard" might be handy, "Rotate screen" also nice to have, "Help messages" might be also useful.

I think I will change the "welcome message" to something more useful like screen rotation in the medium term. or someone else can...

There is a known issue where the native keyboard is BEHIND the layer that needs it. Opening the keyboard first actually bypasses this issue.

Bundled an OSD in the form of aosd_cat, also a top menu window decorator concept using ETCL (someone else's work re-used) and two demos so far.

The code to search for the secondary submenus is WAAAAY slow and needs refactoring. Like way slow. Like slow.

Will do some more tests but it's not far from workable.

[twobob]

Some screenies.

[brianinmaine]

Very impressive! My two favorite programs as demos! Can't wait to try these. I also like the fronter toolbar idea.

[twobob]

I'm struggling since ETCL just segfaults on the PW.

Either I could make this touch only or refactor the toolbar into something else.
undecided.

[brianinmaine]

Originally Posted by twobob

I'm struggling since ETCL just segfaults on the PW.

Either I could make this touch only or refactor the toolbar into something else.
undecided.

There is always a hope someone else with a paperwhite might be able to help with the segfaults?

For now you could release it touch only? It seems to me the toolbar is useful if only for the fact you CAN call up the keyboard when you want it (skipstone has a special button, but nobody wants to add a button for every program).

[twobob]

yeah. I've worked around it.
no ETCL for now on the paperwhite but you can exit via power button press.

removed etcl

Will think about creating something generic (Gtk?) that gives us a couple of nice overlay buttons? or to rethink the problem...

Either way. I'll try to tidy up and repack. It's still a bit of a mess.