following default install instructions - cloning repo and installing via pip or setup.py, durdraw doesnt start. no issues on install, both methods report install good.

username@My-MacBook-Pro durdraw % durdraw
Traceback (most recent call last):
  File "/opt/homebrew/bin/durdraw", line 33, in <module>
    sys.exit(load_entry_point('durdraw==0.17.2', 'console_scripts', 'durdraw')())
  File "/opt/homebrew/lib/python3.10/site-packages/durdraw-0.17.2-py3.10.egg/durdraw/main.py", line 72, in main
    app = AppState()    # to store run-time preferences from CLI, environment stuff, etc.
  File "/opt/homebrew/lib/python3.10/site-packages/durdraw-0.17.2-py3.10.egg/durdraw/durdraw_appstate.py", line 31, in __init__
    if curses.has_extended_color_support(): # Requires Ncures 6
NameError: name 'curses' is not defined

macos, python 3.10.9, pip 22.3.1

i confirmed curses does exist. is it because durdraw_appstate.py does not import curses? my python kind of sucks - sorry.

sorry for the big QA push here xD

you accidentally introduced a bug for linux users. on install i get

FileNotFoundError: [Errno 2] No such file or directory: 'README.md'

just need to rename readme.md to README.md :)

thanks

There is an annoying bug with the mouse button getting stuck.

To reproduce:
1: Go into a mode where you can click and hold down to do something, like Draw, Erase or Color.
2: Click down on the mouse somewhere in the canvas, and drag the mouse cursor outside of your terminal window.
3: Let go of the mouse button while the cursor is outside of the terminal.
4: Move the mouse cursor back into the terminal window.

Durdraw will still think the mouse button is held down. You can reset this with a single click or double click, usually, and avoid the issue completely by avoiding dragging the cursor outside of the window with the mouse button held down.

This has to do with the (probably dumb) way that Durdraw interacts with Ncurses' mouse functions in /durdraw/durdraw_ui_curses.py, and stores the mouse state.

Here is a link to the appropriate section in a commit, in the monster mainLoop() method:
https://github.com/cmang/durdraw/blob/32e601901477cf6ba25accb7cb09b3dffa5348ba/durdraw/durdraw_ui_curses.py#L1917C37-L1917C37

Any help would be appreciated!

I'm trying to write a converter from .dur to .ddw (DarkDraw), and it looks like the specification for colorMap has the x/y coordinates reversed from the actual format.

From durformat.md:

Each element of the colorMap should coordinate with a corresponding line and column in the contents. For example, colorMap[2][3] should describe the foreground and background color for the character at contents[2][3], which is the character at Line 2, Column 3 of the given frame.

This makes sense to me and is what I expected, but looking at e.g. indyz-linuxfire.dur, there are 80 elements in colorMap, which corresponds to the width instead of the height.

Durdraw 0.15 actually worked alright in Windows (in Command Prompt, Windows Terminal, etc) with windows-ncurses installed, but the latest build (0.17.2) has issues.

The issue seems to have started when I started using curses panels. Curses.panel.move() returns ERR. I haven't investigated too deeply, but some possible theories are that the Windows curses clone does not fully implement panels, or maybe that it needs a bit more care with the order things are done in. It would be nice if someone would help track down and fix the Windows issues.

On macOS Sonoma, MacBook Pro, M1, in iTerm2 Build 3.4.23, clicking anywhere within the iTerm window results in the following exception:

Traceback (most recent call last):
File "durdraw/./start-durdraw", line 11, in <module> main.main()
File "durdraw/durdraw/main.py", line 242, in main ui.mainLoop()
File "durdraw/durdraw/durdraw_ui_curses.py", line 2032, in mainLoop
  elif mouseState & curses.BUTTON1_PRESSED or mouseState & curses.BUTTON4_PRESSED or mouseState & curses.BUTTON5_PRESSED:
AttributeError: module 'curses' has no attribute 'BUTTON5_PRESSED'

Other potentially useful details. I'm using the trackpad, doing nothing particularly fancy.

This project is really cool though! I hope to see the project continue to progress, and awesome work so far. Thanks for your contributions. 🙌

ive been struggling to get the extended ansi chars to work on a 2021 mbp terminal.app. ive tweaked all the dials and buttons in the profile but no luck yet. hoping someone else maybe has a tip?

thanks

I would like for someone who has experience maintaining Homebrew packages, to maintain one for Durdraw.

I can pay you in ASCII Art and compliments.

Thank you.

Using the tool with docker run to avoid installing python locally would be welcome.

Could be also OS independent in that way.

Convenient for terminal environment.

Is there any option to remap these keys? They just don't work whatsoever. Or maybe there is an option to pick a character and use it as a draw character?

Im using Kitty 0.31.0-1 (xterm-kitty) on Arch Linux. None of the F1-F12 keys work and the draw/erase/color modes dont register click up or down, it instead just draws/erases/colors wherever the mouse is dragged regardless of whether the mouse is clicked or not. Really cool project btw!

i wanted to let you know about http://sid.ethz.ch/debian/durdraw/ :)

how to run this on windows 10?

burt.zip

when i run durdraw burt (the file attached above), durdraw crashes with the following traceback:

Traceback (most recent call last):
  File "/usr/bin/durdraw", line 33, in <module>
    sys.exit(load_entry_point('durdraw==0.21.1', 'console_scripts', 'durdraw')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/durdraw/main.py", line 220, in main
    ui.refresh()
  File "/usr/lib/python3.11/site-packages/durdraw/durdraw_ui_curses.py", line 2822, in refresh
    self.addstr(linenum, colnum, str(line[colnum]), curses.color_pair(cursesColorPair))
  File "/usr/lib/python3.11/site-packages/durdraw/durdraw_ui_curses.py", line 359, in addstr
    self.stdscr.addstr(y, x, str, attr)
ValueError: embedded null character

durdraw --version
0.21.1

durdraw 0.11 opens it okay.

Hi, love durdraw! This is fantastic. However, I am noticing an issue when I try running the example durdraw -p examples/*.dur.

After the initial doge ascii loads and the animation plays for a bit, if I press any keyboard button or mouse button or try to scroll the mouse, I get the following error:

Traceback (most recent call last):
File "/Users/<me>/Library/Python/3.9/bin/durdraw", line 8, in <module>
   sys.exit(main))
File "/Users/<me>/Library/Python/3.9/lib/python/site-packages/durdraw/main.py", line 220, in main
  ui.startPlaying()
File "/Users/<me>/Library/Python/3.9/lib/python/site-packages/durdraw/durdraw_ui_curses.py", line 944, in startPlaying
  elif mouseState & curses.BUTTON5_PRESSED:    # wheel down
AttributeError: module 'curses' has no attribute BUTTON5_PRESSED'

Thanks!

I am considering changing Durdraw's licensing to a more widely used license, with the goal of simplifying any potential license considerations during redistribution (for distro packages, bundling, etc), or any other usage.

Currently Durdraw uses the ISC license. I am considering changing Durdraw to use one of the following licenses:

BSD, possibly the 3-clause License
MIT License - Everyone loves it. I know I do.

Any thoughts or considerations, from users or packagers, contributors, etc? Is this even an issue at all?

There is an interesting discussion on ISC vs MIT here.

Thanks!

Hi

I would like to request tutorial/manual
I'm a beginner and have no idea how to use it. I use windows 10

Background colors only work in 16 color mode, and do not work in 256 color mode. This is because Python curses is unable to set color pairs past 256 pairs. This is enough pairs for all of the 16 FG and 16 BG color combinations, but not 256 FG and 256 BG color combinations.

Python has a method, curses.has_extended_color_support(), which is supposed to return True if more than 256 color pairs are supported. In this case, using Python 3.10, 3.11, and (I think) 3.12, the method returns True in macOS and the Linux systems I've tried. Even if the Python builds are compiled against Ncurses 5... which is a problem, because extended color pairs only work with the Ncurses 6 ABI.

So, when you try to set or use color pairs past 256, they do not work. No errors are returned. But they seem to wrap back around to write or read from color pair 1. For example, trying to read color pair 257 instead reads pair 1, pair 258 instead reads pair 2, etc. Writing pair 257 either overwrites pair 1, or seems to disappear into /dev/null. I think this is a bug in Python's extended color support.

I have seen this behavior in macOS and Linux systems. Python bug report #91132 seems to hint at the cause, which is that Python for macOS is compiled against Ncurses 5.9. This implies that it's using the Ncuress 5 ABI, which means that curses.has_extended_color_support() should be False, even though it isn't. (Python bug?)

I can think of 3 possible ways to fix this:

1: Only generate the color pairs that are needed, and hope the user never needs more than 256 pairs. This is not great, though, because Durdraw displays the entire 256 color palette on the screen at once. This means that all 256 color pairs are already in use. As an artist, I like seeing the entire palette at once and don't want to trade away that feature. So I am not crazy about this idea. (It might work nicely for RGB colors, though.)

2: Use a Python build that actually works with extended color pairs. I have not been able to get my hands on one yet, but this is the direction I have been leaning. We can wait for OS vendors and Python core developers to dsitribute Python binaries compiled correctly against the Ncurses 6 ABI, and fix the bugs with extended color pair reporting. This would be nice, but we don't seem to be there yet.

3: Steer away from using Ncurses all together for generating color escape codes. They might be able to be injected with puts() or something, but this breaks ncurses convention and may break across different ncurses versions. Or, ncurses might be replaced with another library completely. This would be a lot of work with refactoring and rewriting Durdraw code. It might also break some portability. I don't like this option, either. :)