Being rude about the paint tools

[richmond62]

In the light of the recent discovery of the inability to save a stack retain any paint tool activity I thought I'd get out my pick and shovel
and see what else might not be so good about the paint tools.
-

Screenshot 2024-04-24 at 16.05.23.png (60.37 KiB) Viewed 2125 times

[richmond62]

#1 The bucket fill.

I am running a comparison with the bucket fill tool in GIMP as that seems reasonable:
-

Screenshot 2024-04-24 at 16.09.46.png (71.48 KiB) Viewed 2124 times

-
With GIMP there is an extremely easy way to choose the fill colour.

As far as I can this is only possible in xTalk via the messageBox:
-

Screenshot 2024-04-24 at 16.13.48.png (128.06 KiB) Viewed 2122 times

-
AND, while brushColor might make sense for the brush tool, it doesn't make much sense for the bucket tool: surely 'bucketColor' can be implemented as a synonym for brushColor ?

Certainly digging out /Tools/Toolset/palettes/revcolorchooser.rev is a pain in the bum.
-

Screenshot 2024-04-24 at 16.21.35.png (94.47 KiB) Viewed 2121 times

-
It would be a good thing to have a Colour chooser button on the Tools palette as per GIMP.

[richmond62]

#2 The Polygon Tool

This draws geometric bitmapped primitives that cannot subsequently be altered.

These do NOT save in exactly the same way as things drawn with the brush or pen tool, or coloured with the bucket tool.
-

Screenshot 2024-04-24 at 16.26.04.png (55.2 KiB) Viewed 2117 times

[richmond62]

Now: here's a queer thing:
-

Screenshot 2024-04-24 at 16.40.35.png (42.3 KiB) Viewed 2117 times

-
The icon inside my red square elicits the Operating System's colour tools, and NOT the revcolorchooser.rev stack.
-

Screenshot 2024-04-24 at 16.31.03.png (183.25 KiB) Viewed 2117 times

-
In terms of Usability Theory this is ludicrous as end-users will expect the icons in the Paint Tools section of the Tools stack to give them access to tools, so this is horribly inconsistent: and how is an end-user going to associate a smaller paint bucket with colour selection palettes?

And why was the revcolorchooser.rev stack quite obviously buried?

[richmond62]

Similar considerations need to be addressed re the line tool colour chooser:
-

Screenshot 2024-04-24 at 16.48.57.png (178.43 KiB) Viewed 2112 times

[tperry2x]

Well, you are right - it did come across as rude, or a bit abrupt anyway.
To answer your question, no - I don't know why this was changed.
(It wasn't me).
Wasn't this the same thing that Paul only mentioned a couple of days ago?

Anyway, this is where it's calling the 'Answer Color' and giving you the system colour picker:
(In the revTools stack).

here.png (9.45 KiB) Viewed 2112 times

If I switch it back to use the old rev stack for getting the colour, (which isn't too hard), the first thing I'm greeted with is this error in that stack:

error.png (6.74 KiB) Viewed 2112 times

But, stepping through that error - I can do a bit of work and get that to work thus if you wish?

scrn.png (207.28 KiB) Viewed 2112 times

Personally, I don't know what's wrong with the system colour selector (?), but I wouldn't have mine set to 'crayon mode', but that's just personal preference.
In fact, I don't think many people use 'Crayon Mode' as there was this bug with it for a long time.

col-sel.png (36.36 KiB) Viewed 2112 times

We can change the colour selector icons to whatever you want too... all you have to do is ask (nicely)

icons.png (79.89 KiB) Viewed 2072 times

[richmond62]

Well, you are right - it did come across as rude, or a bit abrupt anyway.

Well, I don't think you need to feel that, as all that I have pointed out has been inherited from "our ancestors".

I would be extremely surprised if, all of a sudden, you started empathising with "our ancestors".

And, as it was in continuation of the earlier 'discovery' re the brush tool, I don't see why it was abrupt.

As I had a free 30 minutes I thought it was about time someone took a vaguely critical look at the paint tools.

Personally, I don't know what's wrong with the system colour selector

I don't either: BUT I do think the way one accesses them is both bad and counter-intuitive: especially as end-users have become used to the sort of thing I exhibited in GIMP for a very long time (It was 'there' in ClarisWorks 1 way back in 1993).

[tperry2x]

#2 The Polygon Tool
This draws geometric bitmapped primitives that cannot subsequently be altered.

Well, yeah - they are bitmaps. They aren't vector shapes with points. This is how the engine is set to draw them.

[richmond62]

Well, yeah - they are bitmaps.

That was NOT meant as a criticism, that was meant as a description.

[richmond62]

The Paint Tools look to me like a half-cock job which have been sidelined for donkey's ages.

I was always led to believe that IF you had introduced a feature into your 'thingy' you either had to keep it up to par with the rest of your 'hingy' or explain why you were removing it.

I have a feature in my Devawriter for people who have a problem matching up Devanagari characters with their QWERTY keyboards:
-

Screenshot 2024-04-24 at 18.05.04.png (666.09 KiB) Viewed 2092 times

-
See that blue thing 'F7' on the right, about halfway down.
-

Screenshot 2024-04-24 at 18.05.24.png (789.58 KiB) Viewed 2091 times

-
Being a slack, lazy slob I let that slide, so at a certain point someone calling that thing up ended with half the overlays under the Devanagari glyphs: forgot about it, and had you asked me about it, I would have laughed and said, "Oh, come one, who is going to use that?"

Blow me down: as soon as I released the version with the cock-up, I got a Prof. somewhere "out there" getting on my case.

So, now, any time I do an upgrade, feature addition, or whatever, that's an hour extra checking the 50 input tables to check that overlay, well, erm, overlays everything.

[tperry2x]

I was always led to believe that IF you had introduced a feature into your 'thingy' yiou either had to keep it up to par with the rest of your 'hingy' or explain why you were removing it.

Like much of the IDE, I'm discovering what's broken only when I stumble upon it. It's not through willful neglect by me (I would have changed these things sooner if I'd known they were broken sooner), if that makes sense.

[richmond62]

It's not through willful neglect by me

Well, I, for one, am the last person to accuse you of neglect of any sort.

I do feel that you apologise far, far too much for things which you cannot be held responsible for.

"Our ancestors" left a lot of broken toys lying around on the theory that nobody would notice: and they are difficult to notice unless you make a conscious effort to go looking for them.

(I would have changed these things sooner if I'd known they were broken sooner), if that makes sense

That makes perfect sense.

My mind has become increasingly poisonous re "broken toys" as I remember when, about 25 years ago, I twisted my ankle on a LEGO brick one of my children had left on the floor: and I now have a feeling that if one does not hunt right through the code some people might end up with twisted ankles.

[FourthWorld]

"Our ancestors" left a lot of broken toys lying around on the theory that nobody would notice: and they are difficult to notice unless you make a conscious effort to go looking for them.

I agree that it was a conscious choice, but would phrase it differently to more accurately reflect the scope of priorities:

"Our ancestors recognized that the graphics tools needed for all layout have grown to become a superset of paint capabilities only needed in a subset of apps. But rather than depreciate the paint tools, they've left them in place as a courtesy to the ever-smaller number of projects still using them."

Most projects today still use image objects, but by importing them from files made in purpose-built apps like GIMP, Krita, Photoshop, etc. This separation of concerns allows each app dev team to dedicate their resources to what the app is focused on doing for the user. It would make no better business sense for LC to attempt to recreate GIMP than it would for GIMP to attempt to become a software development system.

For those apps seeking to deliver a way for users to create graphics, the drawing tools offer much more today than the paint tools ever did. And being drawing tools, every element can be revised, something paint tools can't offer.

If raster output is needed, after enjoying the breadth and flexibility of the drawing tools, the group of drawn objects can be easily saved out as png, jpg, gif, or even bpm in a one-liner using the export command.

Beyond a handful of basics for tidying their use (show stopper fixes only), I wouldn't recommend putting much time into paint tools.

[tperry2x]

My mind has become increasingly poisonous re "broken toys" as I remember when, about 25 years ago, I twisted my ankle on a LEGO brick one of my children had left on the floor: and I now have a feeling that if one does not hunt right through the code some people might end up with twisted ankles.

In that case, here's some more lego bricks I've just twisted my ankle on
Although I can't pretend to be amused about all these bugs, and I'm not going to go blaming anyone for them, I think we don't need to say any more than the fact that they exist. A picture paints a thousand words (pun intended)

A video tells you all you need to know. Draw your own conclusions (okay, I'll stop now)

If it exists in the IDE, my aim is to ultimately fix it. I'll put in as much time as I see fit as I want to see OXT (and xTalk - the open source language variant) be as functional as we can make it.

Much like Paul with his variant I'd guess, I'm only doing it because I'm interested in it and I think it can be a far better IDE than it is.

[richmond62]

FourthWorld is very good at providing excuses for people who should be providing their own explanations about their shortcomings.

[FourthWorld]

FourthWorld is very good at providing excuses for people who should be providing their own explanations about their shortcomings.

One man's "excuse" is another's "explanation". Why is your conjecture about their decisions more valid than any other?

You and I evaluate business decisions differently. As a business owner, my habit is to view things from a perspective focused on ROI. You're entitled to employ your own priorities of course, but please understand that others have equal entitlement to express their own views.

And why would you expect them to take time away from the work they're asked to do to scour the web for discussions like this in forums about products they're not involved with? It would seem more productive to encourage them to stay focused on the many other development tasks you want them to do that they're currently working on.

[tperry2x]

I've found where the bug is with these menus (as shown on my video above), and have commented this so I can come back to it tomorrow. I'm well on my way to sorting it out though and having fully working paint tools. (I kind of like the retro aesthetic effects they create). Anyway...

In the meantime, could I ask someone arty to come up with better foreground and background colour select pngs than these please:

hmm.png (11.04 KiB) Viewed 2027 times

(They get coloured with an overlay, showing the background / foreground colour) - multiply colour effect on the palette.

I attach the icons I'm currently using on that pic above, and I feel they are in need of improvement.

icons.zip

(5.69 KiB) Downloaded 118 times

I'd be very appreciative of any better offerings on those.
Edit: Don't worry, done it now.

[OpenXTalkPaul]

Well, you are right - it did come across as rude, or a bit abrupt anyway.
To answer your question, no - I don't know why this was changed.
(It wasn't me).
Wasn't this the same thing that Paul only mentioned a couple of days ago?

Yes that's exactly the sort of thing I was referring to:

the tools palette had a couple different controller pop-up menus, for example the color selector was a grid of block, and there was a rounded corner radius selector that has since disappeared when

The color selecting in the Tools previously used that revColorChooser stack (BTW, the MetaCard version was a bit more elaborate), and there was another version in v7 that simply had a chooser as small set of basic primary color blocks.
The System Color dialog method is OK with me, but as a graphic artist I think it would be more useful to have a selector that is a circle with center point that can be slid around over top of a image of color spectrum, with current choice reflected in a solid block (does that make sense)?
Similar to this:

Screenshot 2024-04-24 at 9.12.54 PM.png (58.82 KiB) Viewed 2015 times

When I started to try to make more icons more "symbolic" / 1-color, I made those icons just be squares (you know, like just about every other image editing app ever has had them). When I do that part of Tools-palette redo, I'm going to have it be click-toggle button that switches from foreColor (stroke color) to backColor (fill color) selection, in one icon as seen in screenshot.

I also want to bring back that corner radius selector that I mentioned was in v7 Tools.

Personally I don't like most of the icons that represent the paint tools or graphics tools, they made them so tiny to understandably try to save space, that some of them you can't really even make out what they are supposed to be (good thing there's 'tool-tips'). My solution this is to make it a tabbed palette where paint or graphics icons are on their own pages with have plenty of space to work with, you shouldn't need to pixel paint AND create UI objects simultaneously, so there's no reason these should be lumped together as far as I can tell (and in fact these are currently in separate groups with divider line)

[OpenXTalkPaul]

Being drawing tools, every element can be revised, something paint tools can't offer.

Not exactly true, in fact there is a handler to 'Edit Image in Editor" that works with raster images embedded in a stack.
I know what you mean, but what you really meant is "vector drawings are resolution independent" and are (normally) created where every element is a separate objects (which isn't always desireable), but they do still need to be rendered as pixels on screen (preferably with nice anti-aliased edges).

Beyond a handful of basics for tidying their use (show stopper fixes only), I wouldn't recommend putting much time into paint tools.

I feel I need to defend pixel-based images here. Pixel images can be created on separate layers and be composited together. Pixel images can have alpha channels / pixels with variable levels of opactity! They're great for some quick prototyping to make a quick rough sketch of icons not yet created. Pixel images and the ability to create them programmatically and manipulate their pixel data and swap their color palettes out with a different set of colors, or pass pixels back and forth between an pixel based filters API (like the Blur external for example, or my AppleImages Extension), which allows for creating animation sequences, can be quite visually impressive, and is generally great fun!

Graphics drawing objects are great too, but you can't display a photograph with them. Both have their uses. I'm not saying OXT should try to match InkScape or GIMP features... although...

In fact I DO think there should be MORE graphics and imaging capabilities! Because we ain't got no business model here! I'm doing the 'HYPER MEDIA" IDE. I'm planning on including in the IDE that early version of color SVG support that was done as a widget. Why? Because you can paste in lines of regular readable SVG XML tags, like for creating circles, rounded rectangles, etc. I was thinking there could be a handler that translates graphics controls objects into matching SVG shapes placed into an instance of that widget. I already have a similar handler for converting to effective polygon points and then to SVG path strings.

[richmond62]

And what chance SVG export?