nokse22 / ascii-draw Goto Github PK

Hi,
I don't know if I should post this as a feature request or as a bug.
The question is about opening files.
The program works very well, does very nice drawings and they can be saved.
But if we realize that the drawing must be improved?
I haven't see a way for opening a saved drawing.
It's very strange and it's really the first time I see such a behaviour.
So I ask you to create this feature which is to be able to open a previously saved drawing.
I think that would not be very complicated.
Thanks in advance,
Luis Vital

Cannot save drawing (if installed with snap):

Steps To Reproduce:

1. Install ascii-draw with snap
2. Create a picture
3. Press "Save" or "Save as"
4. You might also try to open a file
   Suspicion: Wrong configuration of the snap

Expected behaviour:

1. Application shows a file selection box if user clicks on Save, Save as or Open file
2. Application saves or reads the data

Screenshots if needed:
GLib-GIO-WARNING **: 08:03:37.156: Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)

or

Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)

System:

• App version: Nokse 0.2.0

Additional context:

Is your feature request related to a problem? Please describe.

Firstly I must say I adore this project and look forward to seeing where it is headed! I can see myself using this tool to mainly design figlet fonts to be used with Nerdfonts in a terminal, for terminal based art. It'd Be super helpful if I could easily define character palettes to pick characters, and easily swap between different palettes at will!

Describe the solution you'd like

Basically I envision something like a sub menu of the current character dialog, but one where I could select between different palettes that I've defined in a ~/.config/ascii-draw/character-palettes/ file. Somewhat related, but a separate feature would be the ability to define custom box/line styles in a similar manner. I didn't even think of this at first, but this all would likely require the ability to select the font that is being used on the canvas!

Describe alternatives you've considered

The main alternative is using an external notepad and copy/pasting single characters into ascii-draw, which is rather time consuming.

It's not usable on mobile devices. It needs to have a drag canvas tool, so you can still move the canvas, but only when it is selected.

Is your feature request related to a problem? Please describe.

The "problem" - if you can call it like that - is that currently it seems to be not possible to change a shape/object after it has been created. There is actually no notion of a collection of objects/shapes that can be changed at all, just the possibility to once add to the canvas like in a pixel drawing application. I would like to have it behave more like a vector drawing editor that knows about all the objects on the canvas and can change them at any time.

Describe the solution you'd like

• Know about the list of objects that have been created with all their parameters including z-Index and do the display on demand from this list, making sure that hidden features are not drawn. This also includes having the typical operations of bring to front/bring to back/lower/raise and the ability to select an object for changing at all.
• Have a native file format that saves this information so it is still there after save/load.
• ...I assume there is more to enabling such a feature set than these points mentioned.

Describe alternatives you've considered

• using a real vector graphics editor or diagram editor, but the selling point for ascii draw is that is exactly not such a complex beast.

As of current version: under the tab "block elements" there is a really convenient grouping of geometric "fills" that can be used to create a monochrome piece, with (for example) U2588 "Full block" for a fully "coloured in" grid character to contrast with an empty space and U258C "Left Half Block" or U2592 "Medium Shade" usable as a mid tone. I love this, but there's some room for improvement.

The problem is that the way these characters are currently presented in the user interface it's hard to feel confident identifying U2588 "Full Block" from U2587 "Lower Seven Eighths Block" at a glance. This means this wrong character can get selected, leading to frustration and having to correct a mistake repeatedly for something.

The solution I'd request is presenting tooltips with the Unicode spec description when mouseover-ing the items in the palletes. This would minimise the amount of attention to detail and effort needed to make a change applying to everything. If I select "Lower Seven Eights Block" instead of "Full Block" when there's a tooltip correctly telling me which is which then it is my own fault. Currently though it feels like a guessing game because I don't use ascii-draw daily and I haven't memorised which is which.

The current screenshots are a bit too tall, so they get very small in app store UIs. It's recommended to make the window no bigger than 1000x700 pixels, the current ones are close to 900 in height.

It also looks like they're not using the default font somehow, if I'm not mistaken it's an older version of Cantarell (IIRC unfortunately still shipped on some distros, e.g. Ubuntu) and the large text a11y setting seems to be on.

Since we're planning to use screenshots at larger sizes in curated banners and the like on Flathub in the future this stuff is becoming more important :)

Describe the bug:

Steps To Reproduce:

1. enable dark mode
2. draw something

Expected behaviour:
Light text in dark mode

Screenshots if needed:

System:

• App version: 0.3.0 (Snap package)

Additional context:
Ubuntu 23.10

Add an Russian translate (incomplete)
ru.zip

hi , great app but the proplem is that when using the mouse cursor to draw ,
it is drawing on the opposite side , such as drawing in the right of the page the ascii codes will appear in the left side, and its same for all directions it will draw to the opposite.
Note: my system language is English/Arabic , In case, it is related to the problem.

A dark mode (night mode) toggle.

• Implement a theme that is easy on the eyes for night owls and emo dudes.
• The theme can be activated through a settings dropdown, button, or shortcut key.
• BONUS: A system setting. Will set the theme based on the OS or DE. This is could be tricky.

Is your feature request related to a problem? Please describe.

I'd like to make colour ansi art for terminal applications.

Describe the solution you'd like

I'd like to be able to paint in foreground and background colours that use ansi escape sequences to render in a terminal. Something like a paint program for pixel art would be ideal. I believe applying foreground and background colours should not affect underlying text. but perhaps having four tools: "text", "foreground", "background", and "brush" where brush sets all three at once would be a good solution.

Describe alternatives you've considered

Not sure if there are other colour encodings relevant to text files, not everyone is going to be making graphics for colour terminals. there are also 256 colour terminal escape sequences, but I like the way the 16 colour escape sequences get themed in terminal emulators.

Additional context

here are a list of color codes with their colors and what they set the color for.
https://gist.github.com/Prakasaka/219fe5695beeb4d6311583e79933a009

Describe the bug:

Ascii-draw saves palette to /var/data

This will cause the program fail to start outside flatpak (and snap?), because /var isn't typically writable.

Steps To Reproduce:

1. Launch the program outside of flatpak
2. See the program fail to launch because it attempted to create /var/data which doesn't exist
3. Remove those lines
4. The program kind of works but autosaving (?) doesn't

Expected behaviour:
Save to ${XDG_DATA_HOME}/ascii-draw and fallback to ${HOME}/.local/share/ascii-draw if that environment variable isn't set.

See XDG Base Directory Specification

• App version: 0.3.0

Additional context:
You can close this issue if you don't want to support for package managers other than flatpak. I'll go with my workaround.

Describe the bug:
The canvas and "Styles" toolbox items have very low visibility and are almost invisible.

Steps To Reproduce:

1. Open ASCII Draw
2. Select some drawing tool, e.g. rectangle
3. Draw a rectangle on canvas

Expected behaviour:

• Symbols on canvas are expected to be visible after drawing
• Styles toolbox items are expected to be visible

Screenshots if needed:
https://imgur.com/a/0upNqpe

System:

• App version: 0.2.0
• Operating system: Fedora Linux 37

Additional context:
Light Gnome UI style

Currently, the manifest uses the GNOME stable runtimes:

I propose to use the master runtime from GNOME Nightly, as it comes with the latest updates from GTK and libadwaita. You'll be able to port to and test the latest widgets before the next stable runtime comes out.

Describe the bug:

Steps To Reproduce:

1. Set Gnome's display scaling to a non-integer scale (I was able to reproduce this with 125% and 150% scaling set in Gnome's settings.
2. draw a horizontal line in ASCII Draw
3. As the line gets longer, the end point of the line becomes more distant from the mouse cursor position, making it difficult to draw using the mouse.

Expected behaviour:

The endpoint of the line tracks the mouse cursor closely (allowing for the character grid), as it does at 100% display scaling

Screenshots if needed:
(at 125%)

System:

• App version: 0.2.0 (from Flathub)
• Gnome 44 (Wayland session)

Additional context:
Fractional scaling may not be available by default, but can be enabled in Wayland using this command:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Describe the bug:

The ASCII Draw Dark mode isn't as good as it could be:

• The dark/light shadow that's applied looks fine in light mode, but looks off in the dark mode.
• The background doesn't play well with the ASCII text.

There's also another affect it has on my eyes and perception of the app that I can't really describe.... something to do with contrast. It's causing me to have a headache. Making the background in the dark mode be less bright would help.

We would need to sort out the white shadow around the drawing area somehow too.

Steps To Reproduce:
Switch ASCII Draw to Dark Mode.

Expected behaviour:

The dark mode would look as "good" as the light mode.

Screenshots if needed:

Is your feature request related to a problem? Please describe.
No big problem! I've used ASCII Draw on a project of mine and it has been really useful to create my interfaces.

Example:

My only pet peeve is, despite the name, there is no ASCII-only palette. Extended Latin actually is extended ASCII, and the characters are in order, so once I figured it out I was ok, but it took me a while. Because I use ASCII-only for a fallback mode of my project, I had to redo a bunch of art.

Describe the solution you'd like

I would like, before the other palettes, an ASCII-only palette (specifically a the printable chars 36-126 that are widely accepted everywhere). This is basically a split of your Extended Latin palette in 2 parts. I also not sure the DEL char (127) should be accessible that way, as I have used it thinking it was just space before.

Describe alternatives you've considered

I can just let everyone figure out how your app works and hope they get it!

Additional context

That's it, I think. Great job 👍

Describe the bug:

The application does not use mono font.

Steps To Reproduce:

1. Install
2. Draw anything

Expected behaviour:

Screenshots if needed:

System:

• App version: 0.3.0
• OS: Fedora Linux 40
• PackageMgr: flatpak

Additional context:
Source Code Pro is set as mono font in GNOME Tweaks

Describe the bug:

Steps To Reproduce:

1. Select a character for the freehand brush
2. Use the picker tool and select an empty pixel
3. Go back to freehand brush and observe the previous character is still highlighted as selected but is not the active character and you have to switch to a different character first to fix it.

Expected behaviour:
Character selection dialogs are updated appropriately when the picker tool is used.

Screenshots if needed:
Screencast from 2024-01-27 23-37-38.webm

System:

• App version: 0.2.0 from FlatHub

Additional context: Debian 12 Bookworm

Is your feature request related to a problem? Please describe.

Sometimes I have to reposition parts of the drawing, and that currently requires copying the text to another editor, editing and copying it back.

Describe the solution you'd like

A "select" tool which could select a rectangular area. Dragging the selected area would move it, and clicking outside would start a new selection.

Describe alternatives you've considered

• Using an external editor, which is cumbersome
• In some cases just resizing the canvas would help, but it only "moves" the content left or up

Additional context

My specific use case is UML diagrams, where it is nice to arrange class boxes so the relation is more clear.

Is your feature request related to a problem? Please describe.
A redo function would be useful for things like reverting accidental undos.

Describe the solution you'd like
A redo button and a keyboard shortcut (Ctrl+Shift+Z)

Would it be possible to have this packaged into something that can be installed with pip?