Neue Testversion 17.90b4

[Juan]

I guess this is a bit beyond Google translate … and sorry for not taking English speaking forum members into consideration.

Don´t worry my friend , sometimes Google helps but it wasn´t the case now I guess.

The problem for me is: if you snap to the document top, then to the left side, say, then the automatic guide at the top disappears immediately once the side guide catches the layer. In this way, you get some additional optical feedback that the layer has snapped in. But if you drag the layer from the left side to a "normal" (manually created) guide line, then the guide on the left document side keeps fading, even if the layer has already snapped to the "normal" guide. (When trying the new guides, with many automatic guides around, I even got the impression that manually created guides didn't work.)

Weird I don´t have that behavior here, I added a custom guide and followed your steps, you can watch it here: http://youtu.be/63UjE308HR8

What I noticed is that no matter if a layer is hidden the guide preview still reads that layer, I guess if you hide a layer the guides should ignore it.

Not quite what I wrote — I was thinking about switching different types of guides on and off separately, because if you have lots of small layers, you have snapping lines everywhere in the document, even if you only want to align to ordinary guides and/or document borders. So there would be four different kinds of guides: (1) manually created ones (2) document borders (3) layer borders (4) vector lines.

Great idea, I add my vote on this.

Cheers
juan

[Ashcraaft]

Ich habe unter OS-X 10.6.8 Probleme beim Öffnen von Dokumenten via Kontextmenü "Öffnen mit…"
Wenn ich hierüber Dateien öffne erscheint auf dem Bildschirm der Dialog "Umrissliste" aber die Bilder öffnen sich nicht.

Getestet und nachvollziehbar auf smb-Server sowie lokal, vom Schreibtisch mit den Formaten TIF, PSD

[bkh]

Weird I don´t have that behavior here, I added a custom guide and followed your steps, you can watch it here: http://youtu.be/63UjE308HR8

Thanks for trying. I can't spot it on your video, either. But this is because the previous guide has faded by the time you hit the next one. Maybe guides fade a bit faster on Win than on the Mac, or they become too hard to see on the video. I first noticed the effect when the guideline and some automatic guides happened to be close together so they didn't have enough time to fade when I moved from one to the other.

What I noticed is that no matter if a layer is hidden the guide preview still reads that layer, I guess if you hide a layer the guides should ignore it.

Definitely.

Cheers

Burkhard.

[JulianZI]

Vielen Dank für die Verbesserungen, inbs. das Seiten speichern und die dynamischen Hilfslinien.

Vielleicht sollte das Einrasten mit "Shift" einfach die neue Funktion temporär aktivieren, anstatt des alten Ausrichten an Objekten.

Ich finde es gut, dass das Einrasten an Hilfslinien das Einrasten am Raster überschreibt.

[bkh]

Vielleicht sollte das Einrasten mit "Shift" einfach die neue Funktion temporär aktivieren, anstatt des alten Ausrichten an Objekten.

Shift (wie auch alle anderen Modifier) ist bei den meisten Werkzeugen leider schon belegt.

Ich finde es gut, dass das Einrasten an Hilfslinien das Einrasten am Raster überschreibt.

Bei mir funktioniert das Einrasten am Gitter nach wie vor gleichzeitig mit den Hilfslinien. Finde ich auch gut so (ansonsten kann man ja das Gitter abschalten). Beim Einrasten am Gitter habe ich übrigens auch den Effekt, dass die automatischen Hilfslinien beim Einrasten am Gitter nicht sofort verschwinden.

L.G.

Burkhard.

[JulianZI]

Vielleicht sollte das Einrasten mit "Shift" einfach die neue Funktion temporär aktivieren, anstatt des alten Ausrichten an Objekten.

Shift (wie auch alle anderen Modifier) ist bei den meisten Werkzeugen leider schon belegt.

Shift aktiviert ja bereits eine Einrastfunktion - diese verhält sich anders als die dynamischen Hilfslinien, was sie meines Erachtens nun redundant macht.

[bkh]

Shift aktiviert ja bereits eine Einrastfunktion - diese verhält sich anders als die dynamischen Hilfslinien, was sie meines Erachtens nun redundant macht.

Mit Shift kann ich eine Ebene gezielt horizontal/vertikal/diagonal verschieben bzw. proportional aufzuziehen/zu skalieren. Das geht mit den dynamischen Hilfslinien nicht.

L.G.

Burkhard.

[Ashcraaft]

Ich habe unter OS-X 10.6.8 Probleme beim Öffnen von Dokumenten via Kontextmenü "Öffnen mit…"
Wenn ich hierüber Dateien öffne erscheint auf dem Bildschirm der Dialog "Umrissliste" aber die Bilder öffnen sich nicht.

Getestet und nachvollziehbar auf smb-Server sowie lokal, vom Schreibtisch mit den Formaten TIF, PSD

Ist das Problem auch auf anderen Macs nachvollziehbar?

[frankenstein]

Ist das Problem auch auf anderen Macs nachvollziehbar?

Ja, wurde hier weiter oben schon beschrieben. Tritt nicht nur beim Öffnen via Kontextmenü auf.

[bkh]

Wenn die Anzeige von Gitter bzw. Hilfslinien aus ist, wäre es schön, wenn beim Einrasten an Gitter oder Hilfslinien auch diese Hilfslinien aufleuchten würden, ähnlich wie die dynamischen Hilfslinien.

L.G.

Burkhard.

[bkh]

Ich wollte aus gegebenem Anlass nochmal an die Probleme mit dem Graumixer erinnern (http://www.pl32.com/forum3/viewtopic.php?f=2&t=3219) — die Farbbeispiele und die Regler passen einfach nicht zusammen.

L.G.

Burkhard.

[Herbert123]

Inconsistencies regarding vector points edit tool:
- holding down the <alt> key to drag a handle activates the alignment snapping, which makes it very difficult to place them properly since they snap to just about anything.
- holding down the <ALT> key and dragging a vector point leaves the two curve handles behind in their original position. Having this option is nice, but I want to snap points while dragging with the two curve handles repositioning as well - as it stands it is either moving the vector point without snapping and the curve handles move too, OR snap the vector point to other objects (which is great!) BUT leaving the curve handles behind in their original position, which is silly in most cases.

Another quirky behaviour is when I drag one of the handles without holding down <ALT>: the curve handles align. I expect these not to automatically align (in 99% of all cases you want the curve handles to remain broken). Together with the alignment snapping that is activated while holding down <ALT> it creates a awkward situation: either bear the snapping, or have the curve handles align.

Double-clicking a curve point will open the dialog with an option to uncheck curve handle alignment, but I feel this option should be OFF by default, not ON. Especially with the new alignment snapping!

And btw: "Move helper points synchron" should be translated as "keep curve handles aligned". And this option should be turned OFF by default - or at least: once a curve is converted to a non-aligned one, it should remain non-aligned, unless specifically told to be aligned again.

Am I making any sense? Perhaps I should upload a small movie that explains these issues better.

[bkh]

Inconsistencies regarding vector points edit tool:
- holding down the <alt> key to drag a handle activates the alignment snapping, which makes it very difficult to place them properly since they snap to just about anything.
- holding down the <ALT> key and dragging a vector point leaves the two curve handles behind in their original position. Having this option is nice, but I want to snap points while dragging with the two curve handles repositioning as well - as it stands it is either moving the vector point without snapping and the curve handles move too, OR snap the vector point to other objects (which is great!) BUT leaving the curve handles behind in their original position, which is silly in most cases.

These are known problems, but of course with the introduction of dynamic guides this is getting worse …

One obvious way out could be to distinguish between Alt being pressed when clicking on the curve point and holding Alt while dragging. (This distinction is used elsewhere in PL, but in general, I don't really think it's very user friendly.) So clicking on a control point with Alt key pressed lets you move the control point independently of the other, and if you release the Alt key while dragging, you go back to the standard snapping behaviour.

Another quirky behaviour is when I drag one of the handles without holding down <ALT>: the curve handles align. I expect these not to automatically align (in 99% of all cases you want the curve handles to remain broken). Together with the alignment snapping that is activated while holding down <ALT> it creates a awkward situation: either bear the snapping, or have the curve handles align.

I wholly agree. Once the curve isn't smooth any more, moving one curve handle shouldn't move the other handle any more. (Probably this is a bit more difficult to implement because this means that curve points have to remember whether the curve is supposed to be smooth in that point.) Maybe the Shift key can be used to re-align the corresponding control point to go back to a smooth curve if required.

Double-clicking a curve point will open the dialog with an option to uncheck curve handle alignment, but I feel this option should be OFF by default, not ON. Especially with the new alignment snapping!

As far as I can see, this option just determines whether control points move in the same way as the curve point when you enter new coordinates. If you switch this option off, the behaviour is like dragging the curve point with the Alt key pressed (control points stay in place).

And btw: "Move helper points synchron" should be translated as "keep curve handles aligned".

Maybe "Also move control points" would be even more to the point.

Btw., I noticed that when holding Shift, I can't move both control points to one side of the curve point — as soon as I move one point to the other side, the other flips over.

Cheers

Burkhard.

[Martin Huber]

- holding down the <alt> key to drag a handle activates the alignment snapping, (…).
- holding down the <ALT> key and dragging a vector point (...)

These are known problems, but of course with the introduction of dynamic guides this is getting worse …

One obvious way out could be to distinguish between Alt being pressed when clicking on the curve point and holding Alt while dragging. (This distinction is used elsewhere in PL, but in general, I don't really think it's very user friendly.) (…)

I also think, it's not user friendly. But what could we do instead? Don't allow toggling alignment in the vector editor? That would be inconsistent behavior. Or disable temporary toggling at all?

Another quirky behaviour is when I drag one of the handles without holding down <ALT>: the curve handles align. I expect these not to automatically align (in 99% of all cases you want the curve handles to remain broken). Together with the alignment snapping that is activated while holding down <ALT> it creates a awkward situation: either bear the snapping, or have the curve handles align.

I wholly agree. Once the curve isn't smooth any more, moving one curve handle shouldn't move the other handle any more. (...) Maybe the Shift key can be used to re-align the corresponding control point to go back to a smooth curve if required.

Shift can't be used, because Shift is used for constraining the dragged point to moving along its current direction. In my opinion Alt is the correct key. This way Alt is used for unaligning and for aligning.

Double-clicking a curve point will open the dialog with an option to uncheck curve handle alignment, but I feel this option should be OFF by default, not ON. Especially with the new alignment snapping!

As far as I can see, this option just determines whether control points move in the same way as the curve point when you enter new coordinates. (…)

Yes, that's the way it works.

And btw: "Move helper points synchron" should be translated as "keep curve handles aligned".

Maybe "Also move control points" would be even more to the point.

"Move helper points synchron" should be "Move helper points synchronously". In my opinion "keep curve handles aligned" is incorrect.

I don't really care, whether it is "Also move curve handles" or "Also move control points" or … So if you can agree on a text, I don't mind changing the current one.

Btw., I noticed that when holding Shift, I can't move both control points to one side of the curve point — as soon as I move one point to the other side, the other flips over.

I don't see the problem. Currently PhotoLine is aligning the control points, so the other one flips over. If you don't want that, you have to additionally hold Alt.

Martin

[bkh]

- holding down the <alt> key to drag a handle activates the alignment snapping,

One obvious way out could be to distinguish between Alt being pressed when clicking on the curve point and holding Alt while dragging. (This distinction is used elsewhere in PL, but in general, I don't really think it's very user friendly.) (…)

I also think, it's not user friendly. But what could we do instead? Don't allow toggling alignment in the vector editor? That would be inconsistent behavior. Or disable temporary toggling at all?

To me, temporary toggling alignment is really important, both in the vector editor and elsewhere. Disabling toggling for control points might be an option (but would still be inconsistent). Personally, I could do without the possibility to move a point while leaving the control points fixed.

I've had a look at Inkscape. The solution there is to introduce three curve point tools for setting the point's status:
1) Corner points: control points can be moved individually (like Alt in PL)
2) Smooth points: control points are in opposite directions from curve point (normal behaviour in PL)
3) symmetric points: like smooth points, but control points also have the same distance (like Cmd in PL)
(There's also fourth kind which provides automatic control points.)

So, as suggested for PL by Herbert123, the curve points in Inkscape remember if control points can be moved individually or if there is some constraint.

Btw., I noticed that when holding Shift, I can't move both control points to one side of the curve point — as soon as I move one point to the other side, the other flips over.

I don't see the problem. Currently PhotoLine is aligning the control points, so the other one flips over. If you don't want that, you have to additionally hold Alt.

Thanks, didn't really come to my mind that I should use Alt togehter with Shift — but of course, this makes a lot of sense.

Cheers

Burkhard.