Paint tools and image creation

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Paint tools and image creation

Ben Rubinstein via use-livecode
Hi all,

We had an issue come into support about using the paint tools on a
grouped image - this has come up before (years ago, at least).

Basically, only the browser, pointer and help tools will recurse into
groups - the paint tools will not. This means that if you use the paint
tools over an image in a group, the grouped image will not get edited.
Instead, if there is not a top-level image one will be created and that
will be edited.

The question is - is this behavior something which should:

   1) Be considered a bug

   2) Be considered correct behavior

   3) Be considered an anomaly - i.e. something which is probably a bug,
but too many people rely on to change without some sort of compatibility
mechanism

I realize this is an edge case; however, I thought it worth asking to
see if anyone here relies on the fact that images in groups do not get
affected by paint tools; or whether it would be far better than if did!

Basically I'm trying to decide if it should be 'fixed' (assuming the
current behavior is considered erroneous!), and if so whether it would
be suitable for a maintenance release (it is, strictly speaking, a
change in behavior), or only for a development release.

The bug report is here:

http://quality.livecode.com/show_bug.cgi?id=20286

Any feedback gratefully received.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In my mind a paint tool is a 2 dimensional function. I can see using the paint tool in a window displaying a single object that was not a group, kind of like Microsoft Word does it. I cannot imagine trying to paint an object inside a group as though an artist could reach his paintbrush 3 dimensionally into his painting and touch up a bush that was behind a tree!

Now if someone wanted to see  the effect his pain modification has on the whole, then switching between an edit mode and a preview mode would be the way to do that, kind of like Adobe Illustrator used to do. You could even have a modifier key toggle it.

But I am reinventing the wheel here.

Bob S


> On Aug 22, 2017, at 07:43 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> Hi all,
>
> We had an issue come into support about using the paint tools on a grouped image - this has come up before (years ago, at least).
>
> Basically, only the browser, pointer and help tools will recurse into groups - the paint tools will not. This means that if you use the paint tools over an image in a group, the grouped image will not get edited. Instead, if there is not a top-level image one will be created and that will be edited.
>
> The question is - is this behavior something which should:
>
>  1) Be considered a bug
>
>  2) Be considered correct behavior
>
>  3) Be considered an anomaly - i.e. something which is probably a bug, but too many people rely on to change without some sort of compatibility mechanism
> <snip>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
When I created Ready Wrigley Activities, I had to jump through all kinds of hoops to be able to draw inside a group.

I think that drawing on a grouped image should be standard.

Sent from my iPhone

> On Aug 22, 2017, at 11:01 AM, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> In my mind a paint tool is a 2 dimensional function. I can see using the paint tool in a window displaying a single object that was not a group, kind of like Microsoft Word does it. I cannot imagine trying to paint an object inside a group as though an artist could reach his paintbrush 3 dimensionally into his painting and touch up a bush that was behind a tree!
>
> Now if someone wanted to see  the effect his pain modification has on the whole, then switching between an edit mode and a preview mode would be the way to do that, kind of like Adobe Illustrator used to do. You could even have a modifier key toggle it.
>
> But I am reinventing the wheel here.
>
> Bob S
>
>
>> On Aug 22, 2017, at 07:43 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>>
>> Hi all,
>>
>> We had an issue come into support about using the paint tools on a grouped image - this has come up before (years ago, at least).
>>
>> Basically, only the browser, pointer and help tools will recurse into groups - the paint tools will not. This means that if you use the paint tools over an image in a group, the grouped image will not get edited. Instead, if there is not a top-level image one will be created and that will be edited.
>>
>> The question is - is this behavior something which should:
>>
>> 1) Be considered a bug
>>
>> 2) Be considered correct behavior
>>
>> 3) Be considered an anomaly - i.e. something which is probably a bug, but too many people rely on to change without some sort of compatibility mechanism
>> <snip>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
Bob Sneidar wrote:

 > In my mind a paint tool is a 2 dimensional function. I can see using
 > the paint tool in a window displaying a single object that was not a
 > group, kind of like Microsoft Word does it. I cannot imagine trying to
 > paint an object inside a group as though an artist could reach his
 > paintbrush 3 dimensionally into his painting and touch up a bush that
 > was behind a tree!

It's common for applications to have content regions larger than the
window, accommodated with scrollbars.

In LiveCode, that requires a group.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
Mark Waddingham wrote:

 > Basically, only the browser, pointer and help tools will recurse into
 > groups - the paint tools will not....

...nor drawing tools or object tools (eg field or button).

Any opportunity here to generalize the solution to accommodate this?


tool property for groups/creating objects in groups interactively
http://quality.livecode.com/show_bug.cgi?id=623

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
I added a comment to the bug report, but based on the amount of feedback
so far (almost none) I'd say the change probably wouldn't affect many
people. Whether it's a point-release change or a dev-release change is
hard to say, but unless more people object I'd say it isn't a major
shift and it could be implemented in any release.

On 8/22/17 9:43 AM, Mark Waddingham via use-livecode wrote:

> Hi all,
>
> We had an issue come into support about using the paint tools on a
> grouped image - this has come up before (years ago, at least).
>
> Basically, only the browser, pointer and help tools will recurse into
> groups - the paint tools will not. This means that if you use the paint
> tools over an image in a group, the grouped image will not get edited.
> Instead, if there is not a top-level image one will be created and that
> will be edited.
>
> The question is - is this behavior something which should:
>
>    1) Be considered a bug
>
>    2) Be considered correct behavior
>
>    3) Be considered an anomaly - i.e. something which is probably a bug,
> but too many people rely on to change without some sort of compatibility
> mechanism
>
> I realize this is an edge case; however, I thought it worth asking to
> see if anyone here relies on the fact that images in groups do not get
> affected by paint tools; or whether it would be far better than if did!
>
> Basically I'm trying to decide if it should be 'fixed' (assuming the
> current behavior is considered erroneous!), and if so whether it would
> be suitable for a maintenance release (it is, strictly speaking, a
> change in behavior), or only for a development release.
>
> The bug report is here:
>
> http://quality.livecode.com/show_bug.cgi?id=20286
>
> Any feedback gratefully received.
>
> Warmest Regards,
>
> Mark.
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
If this were 3 years ago, I would be begging for this change. It does not affect me right now, though.

Sent from my iPhone

> On Aug 22, 2017, at 3:20 PM, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> I added a comment to the bug report, but based on the amount of feedback so far (almost none) I'd say the change probably wouldn't affect many people. Whether it's a point-release change or a dev-release change is hard to say, but unless more people object I'd say it isn't a major shift and it could be implemented in any release.
>
>> On 8/22/17 9:43 AM, Mark Waddingham via use-livecode wrote:
>> Hi all,
>> We had an issue come into support about using the paint tools on a grouped image - this has come up before (years ago, at least).
>> Basically, only the browser, pointer and help tools will recurse into groups - the paint tools will not. This means that if you use the paint tools over an image in a group, the grouped image will not get edited. Instead, if there is not a top-level image one will be created and that will be edited.
>> The question is - is this behavior something which should:
>>   1) Be considered a bug
>>   2) Be considered correct behavior
>>   3) Be considered an anomaly - i.e. something which is probably a bug, but too many people rely on to change without some sort of compatibility mechanism
>> I realize this is an edge case; however, I thought it worth asking to see if anyone here relies on the fact that images in groups do not get affected by paint tools; or whether it would be far better than if did!
>> Basically I'm trying to decide if it should be 'fixed' (assuming the current behavior is considered erroneous!), and if so whether it would be suitable for a maintenance release (it is, strictly speaking, a change in behavior), or only for a development release.
>> The bug report is here:
>> http://quality.livecode.com/show_bug.cgi?id=20286
>> Any feedback gratefully received.
>> Warmest Regards,
>> Mark.
>
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
This is important in our world. not sure if I follow exactly what the issues are, but I can tell you what users need.

But first of all, the paint tools seem to be badly broken here in 8.1.6

if I draw an oval it , appears but selects the entire card rect as the enclosing rect/container instead of the actual oval itself.
Attempting bring the area  "down" to edge of the Oval, only causes it to shrink

Test was going to be: make two separate oval objects on the card, group and test the paint bucket, I can't even do that today.

But here goes with our requirements:

if I have a coloring book and we have a mouse, an apple and a car. inside the frame/card/coloring area.

in terms of handling the whole UX from the back end, I most certainly would want to be able to treat these with commands that talk to a group.

hide grp "coloringImage "

or  (progressively reveals elements)

show img 3 of grp "coloringImage"

Then,  from the "front user end" when the little girl chooses a color and the bucket tool, and wants to dump the color "pink" into the mouse's body (closed path bit map b/w outline)  We need that to work, just like that. It fills the mouse only, and has no awareness of the containing group. In fact I can't even imagine a use case where you would want paint tools to address the whole canvas containing the group.

Disclaimer: I don't follow well, perhaps this is the way it works, but can't test today because appears broken in 8.1.6

BR




 

On 8/22/17, 5:13 AM, "use-livecode on behalf of Jonathan Lynch via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    I think that drawing on a grouped image should be standard.
   
   

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
On 8/22/17 6:02 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> the paint tools seem to be badly broken here in 8.1.6
>
> if I draw an oval it , appears but selects the entire card rect as the enclosing rect/container instead of the actual oval itself.
> Attempting bring the area  "down" to edge of the Oval, only causes it to shrink

This is normal behavior, it's always been that way. If you click with a
paint tool where there is no existing image, a new image is
automatically created to the size of the card. If you want a smaller
image, drag it out first and then use the paint tools inside it.

If you want to crop an image that is too large, hold down the command
key while dragging an edge. The image will be cropped to the new size,
or if you drag it larger, more space is added.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
On 2017-08-22 20:31, Richard Gaskin via use-livecode wrote:
> Mark Waddingham wrote:
>
>> Basically, only the browser, pointer and help tools will recurse into
>> groups - the paint tools will not....
>
> ...nor drawing tools or object tools (eg field or button).

Well that's a slightly different case here - although perhaps it
explains why things are as they are.

There is explicit code which stops tools doing anything inside groups -
only the group ever receives 'mouse focus' when in one of the
drawing/object/painting tools. It *does not* recurse into children.

Thinking about it, this does make some sense; although when combined
with the 'auto-create an image if no top-level one exists', things start
to make slightly less sense.

Of course, one option (which is actually quite obvious - I think it
would work) would be to allow a tool property on images. It seems
slightly crazy that (essentially), if you switch to a paint tool you can
edit any non-referenced top-level image! Surely any app would want some
control over that (outside of the IDE, perhaps)...

> Any opportunity here to generalize the solution to accommodate this?

> tool property for groups/creating objects in groups interactively
> http://quality.livecode.com/show_bug.cgi?id=623

I think that is a slightly different case to this.

Indeed, it is orthogonal to tool of image - the tool of a group could be
any tool which manipulates objects (including creation), as a group
contains objects; the tool of an image could be any tool which
manipulates pixels, as an image is a collection of pixels.

I fear that these two parts of code are quite distinct, however, so it
isn't a case of do one and get the other free... The image one is
probably quite straight-forward (although, I could well be wrong); the
group one (judging by the code I delved into y'day) not so
straight-forward!

Warmest Regards,

Mark.

P.S. This idea might also give a much better way to do the 'editMode' of
graphics - i.e. a tool property which determines the mouse interactions
within the graphic. I wish I had seen that potential pattern years ago
when we added editMode...

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
On 2017-08-23 12:04, Mark Waddingham via use-livecode wrote:
> I fear that these two parts of code are quite distinct, however, so it
> isn't a case of do one and get the other free... The image one is
> probably quite straight-forward (although, I could well be wrong); the
> group one (judging by the code I delved into y'day) not so
> straight-forward!

Indeed it turns out that an image tool property is quite
straight-forward - well, up to the point of figuring out what the exact
interactions with the global tool are (and how it should behave in an
IDE context):

http://quality.livecode.com/show_bug.cgi?id=20286

This is just an 'experiment' at the moment - but it shows some promise I
think.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
As an aside, I stumbled across the editMode property when I tried to use it as a property of a stack to store edit/view/search for a form/card. No bueno.

Bob S


> On Aug 23, 2017, at 03:04 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> P.S. This idea might also give a much better way to do the 'editMode' of graphics - i.e. a tool property which determines the mouse interactions within the graphic. I wish I had seen that potential pattern years ago when we added editMode...
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Paint tools and image creation

Ben Rubinstein via use-livecode
In reply to this post by Ben Rubinstein via use-livecode
Mark Waddingham wrote:

 > On 2017-08-22 20:31, Richard Gaskin via use-livecode wrote:
 >> Any opportunity here to generalize the solution to accommodate this?
 >
 >> tool property for groups/creating objects in groups interactively
 >> http://quality.livecode.com/show_bug.cgi?id=623
 >
 > I think that is a slightly different case to this.

Indeed it is.  Just brainstorming.

 > I fear that these two parts of code are quite distinct, however, so
 > it isn't a case of do one and get the other free... The image one is
 > probably quite straight-forward (although, I could well be wrong);
 > the group one (judging by the code I delved into y'day) not so
 > straight-forward!

Unfortunate.  I hadn't expected something more generalized could be
"free", but it seemed worth exploring.

In LiveCode (with the exception of the "sometimes rules" of images), the
tool is a global property. In SuperCard, the tool is a property of the
window (the equivalent in LC of a stack).

SC also had scrollbars as properties of a window, and combined with a
local tool mode it made creating custom drawing environments super-easy.

SC shipped with a example app called SampleDraw, which illustrated a
number of useful concepts like document management, anchor window
architecture (what LC folks often call "splash screen" pattern), and
other essentials for crafting good apps.

Even more fun was that it also showed off some nice tricks with
polygons, including a Transform option which took two selected polys and
created a user-determined number of polys in between in which each
successive one was slightly more like the end one.  Illustrator had that
feature, as did SuperPaint (where the algo came from; the SP and SC
teams shared a lot of staff), and while it wasn't particularly useful
for many things it was hella fun.

SampleDraw wasn't quite SuperPaint, but it was far beyond both MacDraw
and MacPaint, a useful and fun app that provided an end-to-end example
of a common category of program done with simple, readable script.

Indeed, it was the thing that got me most excited about xTalks.

Ken Ray and I discussed making a SampleDraw app for LC off and on for a
while, and having scrolling groups in LC rather than being limited to
scrolling only the entire window seemed like it might offer some
satisfying opportunities to make a SampleDraw-like app even better, with
a View pane at the bottom of the window, and tools and other controls in
a toolbar across the top.

But it turns out to be a LOT more work in LC than in SC.  LC does many
great things far beyond what I used to enjoy in SC, but making custom
drawing environments is one particular use-case where it's possible but
only with significantly more effort.  Maybe just an unrealistic
expectation on my part; I suppose it would not be reasonable to expect
any single tool to be best at all things.

My hope here was that it may have been worth taking a fresh look at the
challenge of maybe allowing tools to be local rather than global, more
like SC's window-specific property but in a form more fitting for LC and
more flexible than LC by having the tool mode be local to a group's
interior.

I can understand the challenges here.  Just thought I'd ask.

In fact, for the sake of tidiness I wouldn't mind if that old feature
request were retired if it can't be acted on.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode