cmang / durdraw Goto Github PK

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.

Using alt+c to select colors in 16-color mode only seems to work if the canvas height is smaller than the terminal viewing area, and the 8x2 palette is visible on the lower right. Not sure if this is intentional or not.

I'm on Ubuntu, using the dev branch.

First issue I've submitted on github; apologies if there is some kind of protocol I should be following.

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!

Thanks for a great piece of software!

I think a switch for adding a delay before exiting when playing a file would be nice. My usecase is I use durdraw -p to play a file when I log into my machine, and by default that waits for key input before proceeding (which is suboptimal), and -x 1 causes the file to display but immediately disappear again. Adding something like --delay together with -p (which would wait either X seconds or until a key is pressed before continuing) would be pretty nice.

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. 🙌

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/ :)

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

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 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.

Just had the need to modify some ancient ASCII art for my consoles, and found Durdraw which seems to be the man for the job. But I've hit a serious problem: when you load a random ASCII file, the width is hardcoded to 80 columns, and it is not possible to override this via commandline options (-W / -m), which ends garbling any ASCII file wider than 80 columns (like the ones I'm trying to edit).

Right now, to achieve my goal I had to hack the sources (forcing default_width=120 as a test in loadFromFile at durdraw_ui_curses.py, and also uncommenting "width = max(width, maxWidth)" on durdraw_ansiparse.py seems to be the safest way to do this - everything else I tried ended with errors or enforcing 80 columns anyway), but the ideal solution would be to obey -W/-m when loading ASCII files.

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.

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. :)

how to run this on windows 10?

That's what I see when I try to select "Box-drawing characters":

When I try to type:

Had to kill the process by closing the terminal tab.

That's what I see in command history after:

Most recent:

user@fedora:~/Documents$ 64;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M64;58;39M64;58;39M64;58;39M64;58;39M64;58;39M64;58;39M64;59;22M64;59;22M64;59;22M64;59;22M64;59;22M64;59;22M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M0;58;40M0;32;30m0;54;40M0;49;25m0;57;40M0;34;28m0;57;40M0;57;40m0;57;40M0;57;40m0;54;40M0;54;40m0;54;40M0;54;40m64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M0;88;19M0;88;19m0;30;19Ms0;30;19mtrtr

Second most recent:

user@fedora:~/Documents$ 64;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M65;114;33M64;58;39M64;58;39M64;58;39M64;58;39M64;58;39M64;58;39M64;59;22M64;59;22M64;59;22M64;59;22M64;59;22M64;59;22M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M64;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M65;75;13M0;58;40M0;32;30m0;54;40M0;49;25m0;57;40M0;34;28m0;57;40M0;57;40m0;57;40M0;57;40m0;54;40M0;54;40m0;54;40M0;54;40m64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;76;16M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M64;109;28M0;88;19M0;88;19m

Third is my real command.

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.

Just happened upon this. Pretty sure it's just a typo, and no idea how significant it is, but I thought you might want to know about it. Durdraw crashed (I think while I was changing colors. Not 100%; it was abrupt.) and printed an error message to the console notifying me that 'selt' is not defined in durdraw_ui_curses.py. :

Hi

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

Certain 256-color ANSI files have incorrect colors when loaded in Durdraw. (not sure what they have in common; it just happens consistently with certain files but not with others). Sometimes, the image can be saved with the wonky colors but still has correct colors when viewed via cat, and sometimes, some (but not all) of the colors will be broken, and I will have to re-color parts of the image every time I make any edit. Sorry this isn't more specific or thorough; I don't have any frame of reference for what's happening here, and I can't reproduce it consistently. Hopefully this image explains itself better than I can.

Both images are the same file with no edits. The one on the left is viewed with cat, and the one on the right is in Durdraw. It's not in the screenshot, but if I save the right-hand image in Durdraw and then open the new version with cat, the cape will still be red, but the green meter/symbol in the upper right will be blue and white.

I'm using the dev branch, updated within the last day. Running Ubuntu 22.04 LTS.

I've attached the file in case it provides any insight.

gc42069.ans.zip

I discovered recently that edits made while an animation is playing are applied to all frames in the playback range, which is super convenient! (Though, I do not believe this is mentioned anywhere in the documentation.)

Adding and removing columns works this way, as does removing lines, but I cannot seem to add a line while an animation is playing, neither with esc+/ nor with alt+/.

I can achieve the desired outcome by cutting/pasting across all frames in range when the affected area is the same in all frames, but this can be a bear if I need to shift an entire animation downward or create more space at the top of the image.

Thanks!

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 was working on a design concept on a 120 characters-wide canvas.

I decided to save the file in ANSI for better compatibility with other software.

I wasn't expecting it to overwrite the old file because of different extentions but it looks like they are the same type (binary).

When I open it that's what I see:

Opening with -W 120 doesn't help.

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.

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.

I like to "zoom in" on my terminal emulator to display/screenshot text art the largest possible setting. For still images, I can do this with the cat command, but .dur animations must be viewed in Durdraw, which cannot be viewed in a terminal narrower than Durdraw's interface. It would be neat if i could make the image larger when started in viewer mode, since the interface is never visible. Provided it's not more trouble than it's worth to implement, of course.

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!