Miscellaneous Minor Issues

Sure. Just check and make sure theres not an existing one… I’ve seen this reported before - it might have on the “other” programs forums.

1 Like

Hi Grace,

I have to put my thinking cap back on for this one (that is I’ll have to go back and find / read some old posts) … this popped up in a discussion like 2 years ago, and if I recall it’s not related to the program per se, but rather one’s fonts settings. It a UNICODE thing. I looked at the pattern you posted and it displays the degree symbol fine on my Windows 10 laptop. You’re getting that extra A circumflex I’ll take a look tues eve and get back to you.

Screenshot (6)

Now that I figured out the Github build (test) failure for the new notch options, I’ll also take a look at issue # 2.

1 Like

Ahhaaaa… So it’s only me. Hmmm… I’ll have to research how to fix it. It’s doing it on my brand new laptop, too. Thank you for your assistance so far :slight_smile:

Hey Grace…Sorry I didn’t get a chance to look at th his last night, but it’s starting to come back to me. I downloaded the most recent Seamly2D build and it had the same issue with the deg symbol that you experienced, where when I use a build done on my machine it’s fine. It’s definitely something to do with the Unicode encoding. Not sure how (yet) how to get a correct build off of Github. One thing I need to check is if this happening everywhere the deg symbol is used, or if it’s just in the property browser dock window.

2 Likes

Thank you, @Douglas. You’re a star :grinning: I can’t download anything that I need to build at the moment. I had my laptop stolen & had to replace it :frowning: , so still setting everything up.

:frowning:

Anyhow, now that I’m home I was able to look at the issue again, and it’s all come back. The problem is that Github is encoding the source files as something other than UTF-8

I use the Atom editor and the files are set to UTF-8 encoding. Here you can see the string definition and it displays correctly:

UTF-8_1 UTF-8_2png

Switching the file encoding to ISO 8859-1 it throws the extra A char in.

ISO_1 ISO_2

I believe we need to figure out how to configure Githhub to use the source files as UTF-8 in the builds.

1 Like

soapBoxMode = ON

In more ways than one… this is another example of inconsistencies in the program that can at times be annoying if not confusing.

How so in this case? First off - 2 different tools do the same function. Secondly the tool tip(s) don’t match the “Tool Options” description - which in of itself is incorrect terminology as these are “Tool Properties” not tool options. For ex: A tool option is you have a choice to pick the hammer or a screw driver. Properties of the hammer could be that it has a wooden handle and a ball peen head. An option is a choice, a property is something you set.

Screenshot (7) Screenshot (8)

In the example Grace provided you can either use the “Point intersect arc & axis” or the “Point intersect curve & axis.” But if you notice in both cases the Tool Option says "Point intersection of curve and axis.

So is it a curve? An arc? An intersect? An Intersection? Not to mention is it a “Line type:” or “Type of line” or “Pen style:?”

Screenshot (11)

Screenshot (12)

And yes I’m aware that there’s a bug with the Pen style… um Line type combobox. in the Arc and other curve tool dialogs.

soapBoxMode = OFF

Anyhow… I’ll have a fix for the 0 - 180 degree issue and we’ll work on the inconsistencies in grammar & terminology.

2 Likes

Update on the Intersection point… It was a simple fix to correct the erratic behavior leading to being off by 180 deg.

Intersect

But testing the fix I discovered several other issues, one that I will correct, the other I’d like some feedback on how others would like to see the issue addressed. The first issue is that if the axis center point is outside the arc / circle or NOT intersecting a curve, the visualization wants to connect to the absolute zero point (center) of the scene. IMO the tool should not exit until either a point on the curve is created or esc is pressed to cancel the operation.

Intersect2

The other issue is that again if the axis center point is outside the arc / circle or the axis passes through a curve more than once, only the first intersection point is available.

Intersect1

Questions are:

  1. Is the current fix good enough for now?

  2. Should I come back to this issue at some point to add the option to select either point, like in the Point from tangent & circle tool ?

2 Likes

Hi @Douglas, once again I look upon all of this in awe. Thank you very much :star_struck:

IMO…

Yes, most definitely. Something that at least works is much better than something that doesn’t and does strange, unexplainable things (like whizzing off to absolute point Zero) when you’re only learning how to use the program.

And also, yes. It would be nice to be able to choose either the 1st or the 2nd or even, perhaps, both in this instance. However, the “both” may not be deemed feasible.

:blush: Once again, thank you very much :smiling_face_with_three_hearts:

1 Like

Yay! I look forward to thwacking this fix’s tires!

What about if using a new .vit puts the axis center point outside of the arc/circle?

Compared to the physics-breaking experience of the primary problem, the rest of the related issues, though still issues, are not going to break someone’s pattern if they fail to look at it funny enough, & thus could probably wait for a subsequent update.

On the other hand, although I have not yet felt a need to get a point to the far side of a circle, I see that as it currently stands, doing so would require two (2) superfluous intermediary points, since the tool won’t work from a point on the arc. So I would agree that this probably needs addressed at some point.

1 Like

Good point… or should I say bad point. LOL

Yes there is that possibility Or there’s also the cases where the curve could be resized (see pic) or the axis angle is changed to a degree where there is no intersection point. That means as the pattern is re-parsed the intersection point can’t be created. If the point has no dependents there’s no problem, but if it has any dependents then “some” point has to be used or the program would likely crash… that’s why the “zero” point was probably a logical choice.

Intersect3

Will have to think on it a bit.

2 Likes

Here’s my solution so far… First is to limit the range of the intersect point to the curve when sweeping the axis - and not moving to the “origin” point when the axis moves off the curve. The effect is that the intersect point will at least be approximately set at one of the 2 tangent points. The second thing I did is to throw up a warning box if the geometry changes to cause the intersect point to no longer exist. The origin point will then be used. It’s a compromise I think we can live with. This is an example one of the pitfalls of the program - there’s no sensible way to automatically predict how objects may change in the future.

warning

2 Likes

Wow! That is beautiful how the node is anchored not to go beyond the facing part of the arc.

If I understand correctly, although point A7 could not be created as an intersection node, it still gets created, just at ‘point of origin’… Could something be written to this effect in the error message? Something like “Point A7 is now located near point A” - just to let people know where to look for point A7.

2 Likes

Nice!!!

My intuition tells me that it might be sufficiently handy to replacePoint intersect arc and axis&Point from arc and tangent” with a tool that would place a point along the arc a certain percentage of the way between the two edges. 0% & 100% would take over PfAaT, leaving all the other percentages for PIAaA. My judgement just tells me, “That’s not my case.”

:unicorn:

1 Like

Hi Grace… That could be done, although the origin (0, 0) isn’t always neccesarily near the draft piece basepoint A.

I think the main thing is the issue with a point erroneously flipping 180 deg will be fixed.

Edit: How’s this? Spruced up the warning text, added the footnote, and corrected the title bar to reflect what (tool) the warning was produced by, Also removed the superfluous “Seamly2D” in the title bar.

Screenshot (22)

1 Like

I don’t believe either of those tools needs to be replaced. The original intent of the intersect tool in Grace’s pattern makes sense, I just happened to find an odd case where it has odd behavior.

BTW, you can already use the point along curve tool to place a point somewhere between the 180 deg and 270 deg points… but you need to use the intersect tool first the create those points first. Again, the original issue of erratically being off by 180 deg is fixed.

2 Likes

Hi again And, once again, you’re a star :star_struck:

That’s perfect :slight_smile:, it’s just to let people know where to look for the point when it zips away out of the screen when one resizes a pattern or something.

2 Likes

Wow! @Douglas. I’ve just downloaded and installed the new release :slight_smile:

It’s wonderful!!! Thank you very much!.

:heartpulse: :heartpulse: :heartpulse:

@Grace, @Douglas,

when I go to seamly.net and download the latest linux appimage version, it gives me this (august 3 build) version. Screenshot_20200908_095156

and when I click on check for updates, first I get a message stating that no updates are available, then I get this error message. Screenshot_20200908_095344

Could you please let me know how to get the appimage version of this new release?

Thank you very much.

2 Likes

Hi Anna… I’m guessing this is the most recent stable version of the program.

I’m not a Linux user myself, but you could try getting the latest weekly build on Github here: Click the “assets” link and the app image should be there.

I’ll try taking a look at the warning the program is throwing.

2 Likes