Neue Testversion 19.40b11

[photoken]

< and > keys: I see a pain point with this method. The user may not be certain which mode Photoline is currently in.

Not a problem. Even with its faults, the new behaviour implemented in the last beta showed that when the Layers panel has the focus the selected layer uses the layer selection colour. When the editing window has the focus the selected layer is highlighted, but not with the selection colour -- it's a gray colour. You can see that in the current beta with the old behaviour -- the selected layer is never highlighted with the selection colour because the Layers panel never has the input focus.

ESC key for visibility: just a bad idea. ESC is generally used to escape and/or cancel a current operation. Mapping visibility to that key defies common usage patterns for that key.

Yes, that's a good point, and I suspected as much. The backspace key could be used instead, or there are other available keys for that function. Still, for some reason, I kind of like the "Esc" key for that, but it's not that important.

I am beginning to understand why you like your own suggested layer workflow so much: I believe you mentioned before in other threads that you work predominantly with a trackpad, correct? It makes some sense within that workflow: keys and trackpad are all close together, and controlling the mouse cursor with a small trackpad such as yours is less precise (or at the very least slower to work with in a precise manner) than a mouse and graphics tablet.

Actually the workflow efficiency is just the opposite of what you think. Becaise the trackpad is right below the keyboard, my thumbs are always over it, so switching from using the keyboard to controlling the cursor as if using a mouse is nearly instantaneous. The opposite usage is also true -- because my fingers remain close to (or over) the keyboard, switching from moving the cursor with the trackpad to using the keyboard is very quick.

Precision control of the cursor is excellent (whether with the touchpad on my old computer or with the trackpad on my new Thinkpad) and has never been an issue. All the images I've posted in these forums for the past two years showing editing effects, whether as examples in the general discussion forums or as part of tutorials, or as samples have been done using the touchpad.

layers and the main view are integrated seamlessly, rather than fragmented into an artificial separation between the layers panel and the main view window.

You've correctly pointed out the fundamental difference between our opinions. My view is that the old Layers panel behaviour is needlessly limited as a consequence of its artificial integration with the editing window.

•You still (after me asking you twice now) have not demonstrated that your suggested workflow would be more efficient and faster than the current one. Yours still takes more key strokes. With a mouse-only approach yours also takes more clicks and often many more mouse actions.

Wrong. My suggestion reduces the number of key strokes for each navigation function to the absolute minimum -- one. When you state that keyboard shortcuts can now be defined for some of the layer navigation functions, those shortcuts involve two or three keys, and those keys are not nearly as efficiently concentrated in one area of the keyboard as my proposed key mappings are. So, my suggestion is definitely more efficient.

My suggestion changes nothing regarding the use of keys to perform editing in the main window. Only pressing the ">" and "<" keys are additional requirements.

My suggestion changes nothing regarding using the mouse for any purpose, whether for layer navigation or for image editing. However many mouse actions you are now using remain the same. Only pressing the ">" and "<" keys are additional requirements.

•And you have not given any rebuttal or response to my point that many users do NOT want to use keyboard shortcuts at all. How do we switch conveniently back to the main view without risking deselecting the layer(s) we just selected in the layer panel and without being forced to precisely click very specific small GUI areas, and/or panning and/or zooming out the main view? This is not important to you, it seems, since you do not work that way. But many people do. This must be addressed first and foremost!

On the contrary, switching conveniently back to the main editing window is very important to me, and I repeatedly agreed (in the previous beta discussion) with your observations about the problems with having to use the mouse to activate the main editing window as the previous beta forced us to do.

Simply hitting the ">" and "<" keys addresses those concerns, IMO, and certainly doesn't risk deselecting the layer.

If a user doesn't want to use the keyboard at all for layer navigation, they definitely would not be forced to do so; and whatever they're doing now, they can continue to do.

So, to sum up, my suggestion is a more convenient and efficient way to navigate the layers list. Being able to use the up and down arrows to move the layer selection is something I wish I could do with every image I work with. It's a convenience we already have in the Color list and the Blend Mode list, and we should also have that convenience in the layer list.

The cost for gaining the benefits of my suggestion is having to hit the ">" and "<" keys when necessary. How much time does that take? 0.02 second? I'm willing to do that to get the benefits of a real layer navigation tool that's so intuitive to use because it uses the same keys everyone is used to using for navigating other lists in other Windows applications.

[Herbert123]

Not a problem. Even with its faults, the new behaviour implemented in the last beta showed that when the Layers panel has the focus the selected layer uses the layer selection colour. When the editing window has the focus the selected layer is highlighted, but not with the selection colour -- it's a gray colour. You can see that in the current beta with the old behaviour -- the selected layer is never highlighted with the selection colour because the Layers panel never has the input focus.

I disagree - it is problematic, because the user needs to keep track of one more visual clue. I and others already mentioned it was confusing to work with. It takes more time again to figure out which mode is active: layers? Main view? This was and is not an issue before and in the latest beta.

Actually the workflow efficiency is just the opposite of what you think. Becaise the trackpad is right below the keyboard, my thumbs are always over it, so switching from using the keyboard to controlling the cursor as if using a mouse is nearly instantaneous. The opposite usage is also true -- because my fingers remain close to (or over) the keyboard, switching from moving the cursor with the trackpad to using the keyboard is very quick.

Precision control of the cursor is excellent (whether with the touchpad on my old computer or with the trackpad on my new Thinkpad) and has never been an issue. All the images I've posted in these forums for the past two years showing editing effects, whether as examples in the general discussion forums or as part of tutorials, or as samples have been done using the touchpad.

...all of which supports my view that the fragmented views approach would serve quite well when used with a trackpad only machine, I have no doubt of that. When used with a wacom tablet, for example, it would be far less efficient.

layers and the main view are integrated seamlessly, rather than fragmented into an artificial separation between the layers panel and the main view window.

You've correctly pointed out the fundamental difference between our opinions. My view is that the old Layers panel behaviour is needlessly limited as a consequence of its artificial integration with the editing window.

Are you saying we should go against the industry standard? Adobe spent many years, and a boatload of money on getting the workflow right. If anything, professional users enjoy the smooth workflow in Adobe's products. Would it be wise to go against this, and come up with a workflow which is, in my opinion and others here, less efficient (see below) and smooth?

•You still (after me asking you twice now) have not demonstrated that your suggested workflow would be more efficient and faster than the current one. Yours still takes more key strokes. With a mouse-only approach yours also takes more clicks and often many more mouse actions.

Wrong. My suggestion reduces the number of key strokes for each navigation function to the absolute minimum -- one. When you state that keyboard shortcuts can now be defined for some of the layer navigation functions, those shortcuts involve two or three keys, and those keys are not nearly as efficiently concentrated in one area of the keyboard as my proposed key mappings are. So, my suggestion is definitely more efficient.

My suggestion changes nothing regarding the use of keys to perform editing in the main window. Only pressing the ">" and "<" keys are additional requirements.

My suggestion changes nothing regarding using the mouse for any purpose, whether for layer navigation or for image editing. However many mouse actions you are now using remain the same. Only pressing the ">" and "<" keys are additional requirements.

No, I have to correct you here: we can already map the current functions to singular keys - except the arrow keys (which can be mapped with a modifier key). Your workflow dictates the use of an additional two key presses, NO MATTER WHAT. You can keep stating that your workflow is more efficient, but until your workflow can be controlled without those two additional key presses, it will STILL take those two additional key strokes to switch.

•And you have not given any rebuttal or response to my point that many users do NOT want to use keyboard shortcuts at all. How do we switch conveniently back to the main view without risking deselecting the layer(s) we just selected in the layer panel and without being forced to precisely click very specific small GUI areas, and/or panning and/or zooming out the main view? This must be addressed first and foremost!

On the contrary, switching conveniently back to the main editing window is very important to me, and I repeatedly agreed (in the previous beta discussion) with your observations about the problems with having to use the mouse to activate the main editing window as the previous beta forced us to do.

Simply hitting the ">" and "<" keys addresses those concerns, IMO, and certainly doesn't risk deselecting the layer.

If a user doesn't want to use the keyboard at all for layer navigation, they definitely would not be forced to do so; and whatever they're doing now, they can continue to do.

We are opening a whole new can of worms with your fragmented approach, because a new method must be figured out to activate the view in a mouse-only workflow. This was very problematic in the previous version. One solution would be to click in the main view to activate it first, and then continue to work with elements. A solution like that will be very frustrating, however. and break the workflow.

Basically, the only efficient method for a mouse/Wacom user would be to use those < > keys. That is unacceptable. I work with a Wacom all the time, and often my other hand is away from the keyboard. Nor do I want to be forced to activate the main view and/or layer panel with an additional action - it breaks the workflow.

So, to sum up, my suggestion is a more convenient and efficient way to navigate the layers list.

The cost for gaining the benefits of my suggestion is having to hit the ">" and "<" keys when necessary. How much time does that take? 0.02 second? I'm willing to do that to get the benefits of a real layer navigation tool that's so intuitive to use because it uses the same keys everyone is used to using for navigating other lists in other Windows applications.

In your opinion, of course. Based on the number of key strokes, and for mouse and Wacom users, it still takes more work to perform the same actions - which you also mention. Your 0.02 seconds only works for someone who works with their hands very close to the keyboard (such as a trackpad). Then it definitely starts to make more sense - but for me it would break the workflow. And others here have mentioned similar experiences in the previous beta thread - which is the reason the Hubers decided to backtrack on that workflow change.

...AAAnyway.... We are running in circles you and me.
I do understand and respect your point of view, and I would think that both workflows could be accommodated within Photoline with a simple preference switch.

If one is to be decided on, I prefer the industry standard approach. And the thing is: most users work with the mouse to select things in layer panels, not the keyboard. Switching to the keyboard just takes too much time. Unless the users wish to move things in very precise steps: their first action is to use the arrow keys. Introducing two different modes of operation would only confuse things. And I base this on 17 years of extensive teaching experience in the field. By far the most users will work with a mouse, not with a trackpad, given the choice.

Therefore, the workflow that works best for the majority ought to be implemented, rather than one that relies on the keyboard to work best.

I am also of the opinion that the current keyboard shortcuts and commands to navigate layers can be improved.

[photoken]

Not a problem. Even with its faults, the new behaviour implemented in the last beta showed that when the Layers panel has the focus the selected layer uses the layer selection colour. When the editing window has the focus the selected layer is highlighted, but not with the selection colour -- it's a gray colour. You can see that in the current beta with the old behaviour -- the selected layer is never highlighted with the selection colour because the Layers panel never has the input focus.

I disagree - it is problematic, because the user needs to keep track of one more visual clue.

Not really problematic -- the selection is either brightly coloured or gray. One can either glance at the Layers panel or realize the colour difference in one's peripheral vision. That's really not onerous....

Are you saying we should go against the industry standard?

Well, there's really no such thing as an industry standard for this. Some programs use the new behaviour, some use the old. CorelDraw's popularity certainly hasn't suffered because it allows using the keyboard to navigate its layers.

Your workflow dictates the use of an additional two key presses, NO MATTER WHAT.

Actually, if you want to exclusively use the mouse for layer navigation, it only requires one key press -- the "<" key, because clicking with the mouse in the Layers panel to select a layer automatically gives the focus to the Layers panel, as it does now.

Basically, the only efficient method for a mouse/Wacom user would be to use those < > keys.

A mouse/Wacom user would only need to use the "<" key. I might be wrong, but I think that key can be mapped to an action on the Wacom tablet.

As a matter of fact, the developers (who are much more clever about these things than I am) could probably find an area in the editing window to click on to get the focus. Maybe the surround, maybe the scrollbar slider. In that case, mouse/Wacom users wouldn't even have to deal with the "<" key....

...AAAnyway.... We are running in circles you and me.

I agree. I think that, by now, we've both been able to thoroughly explain our opinions. (Probably waaaaay too thoroughly for the lurkers in this forum. ) I do want to say that I appreciate your holding my feet to the fire about this. It really made me focus on the details of my suggestion (as well as the overall principle) and ensure that I had accounted for potential problems.

I absolutely agree that anyone wanting to continue navigating the layers list with a mouse/Wacom would have to switch the input focus to the editing window when they want to work in it. That's the only change they would notice. If the "<" key is used, that 0.02 seconds to press the key is not onerous, nor is it a destroyer of "workflow", IMO. I'm willing to accept that for the sake of getting nice layer navigation options in the Layers panel.

The other thing I want to add is that, although my suggestion sure sounds good in theory, it certainly needs to be tested in practice. That's what a beta release is for, I'm thinking.

[Falaffel]

Hy,

and it will take much more time of the Hubers to read all of this. At this time we could have an improved and optimized Patch-Tool and a Radial Filter Tool.
Looking forward to V20 this tools and optimizations will be better arguments for potentially new users, which will bring money, and I think earning money is one of the main reasons for making and developing PL.

[Martin Huber]

Dieses Verhalten beobachte ich schon längere Zeit, und es tritt sowohl bei der Mehrfachkonvertierung als auch beim Speichern einzelner Dateien auf, wenn Dateien gleichen Namens im Zielverzeichnis bereits existieren. Bei der Mehrfachkonvertierung kann man zusehen, wie die überschriebenen Dateien (übrigens immer noch ohne Nachfrage!) im Finder verschwinden und nur mehr mittels "unsichtbare anzeigen" sichtbar gemacht werden können. Verwendbar sind sie trotzdem nicht, da sie aus anderen Programmen nicht auswählbar sind.

Einzige Abhilfe, die ich gefunden habe: alle Dateien im Zielverzeichnis löschen und danach Datei speichern bzw. Mehrfachkonvertierung durchführen. Kann allerdings nicht wirklich eine Dauerlösung sein...

Ich kann das Problem hier unter 10.11.1 auch nicht nachvollziehen. Ich habe da jetzt noch eine Sicherheitsabfrage reingesetzt, aber ich glaube nicht, dass das was bringt.

Ich habe nicht herausgefunden, welches Attribut dabei gesetzt wird, das die Datei(en) unsichtbar macht.

Soweit ich weiß, kann man den "Unsichtbar"-Status von Dateien über die Oberfläche gar nicht ändern, sondern nur über Terminalbefehle.
Und Dateien, deren Name mit "." beginnt, sind implizit unsichtbar.

Ansonsten sind Burkhards Fragen/Hinweise noch sinnvoll, dass du das überprüfst.

Martin

[okapi]

Danke Burkhard, danke Martin,

eure Hinweise haben mir geholfen, dass ich das Problem eingrenzen konnte. Die Erzeugung von "unsichtbaren" Dateien beim Überschreiben tritt offenbar nur auf, wenn vom Mac auf ein externes, NTFS-formatiertes Laufwerk geschrieben wird (ich habe das mit FAT-formatierten Laufwerken noch nicht getestet). Um die Speicherkapazität des MacBook nicht zu strapazieren, arbeite ich gern auf einer externen NTFS-Festplatte. Um auf NTFS schreiben zu können, nutze ich die Software "Paragon NTFS for Mac".

Nun könnte man sagen, das Problem hätte mit dieser Software zu tun und nicht mit PhotoLine. Allerdings tritt es mit einer anderen Bildbearbeitungssoftware für Mac, z.B. Affinity Photo nicht auf. Im Test wurden die gleichen Dateien auf das gleiche Laufwerk wie erwartet überschrieben und wurden dadurch nicht unsichtbar.

Ich denke daher schon, dass das ein Problem ist, das PhotoLine betrifft. Vielleicht arbeitet niemand hier im Forum mit einem Mac auf einem externen, NTFS-formatierten Laufwerk. Wenngleich es so exotisch nicht ist, ein externes Laufwerk einzusetzen, auf dem im Bedarfsfall auch große Dateien (2GB+) gespeichert werden können und das gleichermaßen von Windows wie von Mac gelesen und beschrieben werden kann.

LG
Michael

[Herbert123]

I noticed that SVG patterns are imported as bitmap patterns. I think this is caused by the fact that Photoline does not support vector-based patterns, and always converts vector patterns to a bitmap and displays the bitmap version only.

I would love to see proper support for vector based patterns in Photoline (and vector based object support for the stamp tool).

When an imported SVG pattern is saved as a PDF or SVG, the patterns look quite bad and pixelated. It feel it is time that Photoline supported proper vector patterns, because the output is problematic both for print and web.

[bkh]

Danke Burkhard, danke Martin,

eure Hinweise haben mir geholfen, dass ich das Problem eingrenzen konnte. Die Erzeugung von "unsichtbaren" Dateien beim Überschreiben tritt offenbar nur auf, wenn vom Mac auf ein externes, NTFS-formatiertes Laufwerk geschrieben wird (ich habe das mit FAT-formatierten Laufwerken noch nicht getestet). Um die Speicherkapazität des MacBook nicht zu strapazieren, arbeite ich gern auf einer externen NTFS-Festplatte. Um auf NTFS schreiben zu können, nutze ich die Software "Paragon NTFS for Mac".

OK, das erklärt schon mal, warum das Problem normalerweise nicht auftritt.

FAT16 und FAT32 und ExFAT habe ich getestet, da tritt das Problem nicht auf. Evtl. wäre ExFAT eine Alternative, dort können Dateien auch fast beliebig groß werden und wird auch bei OS X direkt unterstützt.

Nun könnte man sagen, das Problem hätte mit dieser Software zu tun und nicht mit PhotoLine. Allerdings tritt es mit einer anderen Bildbearbeitungssoftware für Mac, z.B. Affinity Photo nicht auf. Im Test wurden die gleichen Dateien auf das gleiche Laufwerk wie erwartet überschrieben und wurden dadurch nicht unsichtbar.

Könnte mit der Art zusammenhängen, wie PL die Dateien schreibt – wenn der Dateiname schon vorhanden ist, wird erst eine temporäre Datei angelegt, die mit einem Punkt anfängt (und damit unsichtbar ist). Erst wenn die Datei erfolgreich gespeichert ist, wird die ursprüngliche Datei gelöscht und die temporäre Datei umbenannt. Evtl. wird sie bei NTFS dann nicht automatisch wieder sichtbar. Andere Programme löschen möglicherweise die alte Datei zuerst und das Problem tritt nicht auf.

L.G.

Burkhard.

[photoken]

I would love to see proper support for vector based patterns in Photoline

I agree.

Having vector patterns is important when drawing maps, materials cross sections, etc. There are many geological and geographical symbols available as vector patterns in Adobe Illustrator format that would be great to use, allowing maps to be scaled without ruining their symbols.

[Herbert123]

Agreed - especially for more technical illustrations vector patterns are indispensable.

SVG import of patterns is a real issue right now: they do import (but not patterns inside patterns, btw), and when I save the same SVG, the pattern is converted to a bitmap version. That is quite problematic.

Test it for yourself: open the svg file in the zip archive, and open it.

Correct version:

correct.jpg

PL version (which is converted to a bitmap pattern):

incorrect.jpg

Then save it, and PL saves a bitmap version in the SVG, destroying the file's intent.

[photoken]

open the svg file in the zip archive, and open it.

Once again, although it displayed correctly in IE11, AI CS5 and CDR X5 both did even worse with the SVG image:

AI pattern.png

Did you create that image yourself? If so, I'd be real curious to see what would happen if you saved the original vector drawing as a PDF....

[Martin Huber]

Könnte mit der Art zusammenhängen, wie PL die Dateien schreibt – wenn der Dateiname schon vorhanden ist, wird erst eine temporäre Datei angelegt, die mit einem Punkt anfängt (und damit unsichtbar ist). Erst wenn die Datei erfolgreich gespeichert ist, wird die ursprüngliche Datei gelöscht und die temporäre Datei umbenannt. Evtl. wird sie bei NTFS dann nicht automatisch wieder sichtbar.

In einem anderen Forum habe ich genau diese Theorie über Paragon NTFS gelesen: Wird eine Datei mit "." am Anfang erzeugt, setzt es diese Datei ausdrücklich auf "versteckt". Und wenn die Datei dann den endgültigen Namen bekommt, wird der "versteckt"-Status beibehalten. Das würde das Verhalten erklären (und wäre ein Fehler bei Paragon NTFS), aber es ist - wie gesagt - nur eine Theorie.

Andere Programme löschen möglicherweise die alte Datei zuerst und das Problem tritt nicht auf.

Das ist eher unüblich, weil man dann im Fehlerfall die Originaldatei verlieren würde. Außerdem findet der Austausch zwischen der Originaldatei und der neuen Datei über eine OS X-Systemroutine statt, die OS X-Metadaten beibehält und OS X davon informiert, dass die Datei aktualisiert wurde.

Martin

[bkh]

Andere Programme löschen möglicherweise die alte Datei zuerst und das Problem tritt nicht auf.

Das ist eher unüblich, weil man dann im Fehlerfall die Originaldatei verlieren würde. Außerdem findet der Austausch zwischen der Originaldatei und der neuen Datei über eine OS X-Systemroutine statt, die OS X-Metadaten beibehält und OS X davon informiert, dass die Datei aktualisiert wurde.

Das war auch nicht als Vorschlag für PL gedacht – so, wie PL das macht, sollte es auch sein. Mir fällt gerade ein: Nikons ViewNX zumindest erzeugt sichtbare temporäre Dateien. Damit würde das Problem wohl nicht mehr auftreten, man sieht kurzzeitig Dateien mit komischen Namen im Ordner. Es ist halt die Frage, welche Bedeutung NTFS unter OS X hat (bei Windows selbst tritt das Problem wohl nicht auf?)

L.G.

Burkhard.

[Martin Huber]

Mir fällt gerade ein: Nikons ViewNX zumindest erzeugt sichtbare temporäre Dateien. Damit würde das Problem wohl nicht mehr auftreten, man sieht kurzzeitig Dateien mit komischen Namen im Ordner.

Das haben wir früher auch gemacht. Das hatte aber den Nachteil, dass wir sporadisch Fehler beim Schreiben hatten, weil Spotlight und Konsorten die Datei lockten und dann der Austausch nicht funktionierte. Vielleicht hat OS X das Problem mittlerweile intern behoben, aber solche Probleme tauchen bei neuen Betriebssystem-Version gerne wieder mal auf.

Es ist halt die Frage, welche Bedeutung NTFS unter OS X hat (bei Windows selbst tritt das Problem wohl nicht auf?)

Nein, da gibt es das Problem nicht. Unter Windows sind Dateien mit einem "." am Anfang auch nicht versteckt. Das ist ein UNIX-Ding.

Martin

[Herbert123]

I am experiencing all sorts of display issues with layer masks. Anyone else?

It happens when I work with a bitmap background layer in 16 bit per channel. No problems when working in either 8bit or 32bit per channel.