DarkClown

Todays: Workflow and WINDOWS (putting all my critics in one thread seems to overtax you - since 90% gets lost) - if you resize (zoom in/zoom out) the content of an undocked window can you please resize the window accordingly. (if the resulting content is smaller than the workspace of the screen, adapt the window accordingly, if the content is larger, maximize the window frame with scrollbars) - If you zoom a view too 100% the position of the content seems to be "random". Please instead center the content and resize the window accordingly! (I know you can do it since you do it with the "fit window" view as well) - having all windows floating a new document should start in floating mode as well - when selecting "float all" the content of all windows should be centered and not randomly put somewhere over the screen - (one is happy to find the content at all). Window size should be adapted to content. - One should be able to drag and drop a layer from one document into another document (not just with CTRL+c CTRL+v). Additionally: when trying to drag and drop the user gets the impression It would work based on the way the cursor changes when you drag a layer into another document - but in fact nothing happens. - ESC still does not cancel essential operation e.g. cropping Most of these bullet points have been mentioned many years ago even though they are absolutely crucial workflow topics. And we are not talking complicated additional features and rocket science - we are talking absolutely BASICS! You just simply ignore them. People that seriously try to work with the software are not of interest for you guys - what upsets me. I keep bringing them up every 6 month what seems to be a complete waste of time. I would roughly guess that AP takes up 30%-40% additional mouse-movements, keystrokes and actions to get to the same results as PS does JUST and purely due to your extremely poor workflow and handling issues. And we all know that time is money. Cheers, Timo

Have been for a couple of years by now ... Don't worry ... I'll keep annoying you guys with them and you'll keep ignoring them ... works out pretty well ... Cheers, Timo

It seems like all the files I worked on and closed without saving generate a "recovery file" what AP desperately wants to open on restart ... this drives me nuts since I tend to save my work but experiment with documents further on ... so I'll close them without saving the last steps and AP keeps bothering me on restart with wantig to open "recovery files" from theses documents ... Am I doing something wrong? How do I turn this of? A recovery file ist nice when the program has crashed ... but not each time I close a document without saving it!

As far as I'm aware I'm not using any clipboard manager ... (but as you can see it's not "crashing" either)

Hm, on my Win7 system I don't get a crash still the program behaves extremely strange when playing with the suggested commands. Try to reproduce this

I know someone will hate me for this... 1) WORKFLOW (I know everyone gives a shit at that) !!!!!!! See here: 2) Suggestions (Ok, based on V. 209 - but many things still valid):

Hmm, ETA is not that important from my point of view ... our job is to cause awareness - if that is given Serif will put it into their schedule - and I guess we can be sure they will if it's a major feature that was wrecked in development (by no means meant in a bad way - that can happen!). The layer topic is something that annoys me a lot more ... selling the "no-layer-at-startup policy" as "by design" and than starting to build heaps of workarounds that people can work with this ridiculous "design" feature gives me the impression that it will NOT change ... Frankly it's OK to try something new ... but it shows real size when you can admit that the first approach was a nonstarter. But it doesn't look like that ... so I presume we will have to live with this "by design" concept ... and as well deal with the fact that not ALL assistant functions, implemented to overcome the weaknesses of the design, will be put in place (since they had been pointed out 1.5 years ago already!) ... wait, did I say ETA is not important? :-) And no ... I won't mention "workflow" again ... I will not ... not again ... bummer ... sorry

Ohh, another "no bug, but feature" :-) Thx! I'm curious ...

Hi Gabe, what did you find (and even more important) What did you log? :-) Cheers, Timo :-)

Nice ... did not realize that before!

Hi Mark, thanks for getting back to me on that one. And no, the effect occurred in my case when the "View" tool (hand) was selected. And it seems even when I use the "view" tool for just moving the picture smoothly from one side of the window to another I don't get a smooth movement but a constantly interrupted "shaking" movement - could be related to a redraw as well. It seems like the picture goes back to a spot it has been before and than tries to keep up with the mousepointer ... And as I said - at least with my screen capture program (active presenter) the effect does not appear any more when I start it (It must change something in the environment).

I thought the problem was gone but it still seems to be there. If I just move the cursor over a picture without even pressing a mousebutton the window (including content and window scales at the side) randomly but frequently does a complete redraw. This is independent how far the movements are. It can happen between 5 times a second to every 5 seconds - unpredictably. This of course results in constant flickering of the window when you work with it. First I thought it was related to my wacom tablet but it happens with the mouse as well. I tried to record it with a screen capture program but all the time screen capture is running it does not happen at all. The redraw does not affect the AP program elements e.g. toolbar or even floating panels over the window itself. Cheers, Timo

Can you explain in a little more detail what you mean?

Don't worry - This is not the only problem with the gradient tool - it basically is completely wrecked (for a long time already) ... try to insert new color stops and move them Adding to the problem: AP does not automatically come up with an empty layer (this is - as I was told - "By Design". What surely makes a lot of sense since many people use AP to work completely without any layer /sarcasm_off) ... For many other operation the problems caused by this "designed feature" can be overcome by telling AP to automatically add a layer. Regretfully this does not work for the fill feature (meaning also not for the gradient tool). So if you forgot to add a new layer but edited a complex gradient structure nothing happens - but adding a new layer NOW makes the gradient tool forget everything you entered before ... such an amazing professional workflow

Is "Bigger Thumbnails" a setting you can adjust somewhere? (I'm struggling with the thumbnail size for quite a while)

Hmm, works fine for me ... must have been your specific installation ...

The attached video shows the completely unacceptable delay in screen redraw. You see a larger TIFF file in the background and a small jpg (1200x800px) on top of it. No other file open no other program running. The only thing I do is resizing (at the beginning) and than moving the smaller top picture. You may realize that while I'm just moving the pic a resize of the picture is performed by AP without me even releasing the mouse during moving - so I have to resize afterwards to get the picture back to screen size. All the artifacts and delays when resizing and moving are original performance on my system. Of course it will be easy to blame it on my system but no other program (e.g. Lightroom, PS, CaptureOne) shows performance like that on my system. Maybe other people don't experience these kind of substantial problems or they don't care - but for me this makes AP unusable for daily work. Delay.avi

I checked with the beta and the same pictures. It's still not "impressive" but there is a significant improvement in the behavior - so it seems something has been done in the beta to overcome the problem but I do see quite some space for improvement!

Well, the problem is not that I used a brush or anything else ... I did use the "Move" tool and just moved the top picture (or later resized it) ... but while "Moving" it as well did a resize (I did not release the mousebutton) .... And of course the overall performance is a complete no-go. Here are my Performance settings (and turning of "Use precise clippings" does not change anything in terms of performance!):

Latest Beta 243: When dragging and dropping an external jpg from the explorer into an open document in AP the program crashes reproducable without any error message (no recovery file as well). Timo

Well, it might be related to some kind of JPG setting Samsung uses ... and when you open it with a different App and save it again obviously the according other jpg interpretation is written what causes less problems. Interestingly AP doesn't have that problem in the stable version.

Thx for confirming!

I cross-checked again ... and indeed it does not crash with every picture. The problem seems to be related to the picture I drag onto the already open picture ... does not seem to have problems with other programs - but gets AP to crash ... I attached it here so you or a moderator may test it yourself 20190204_162641.zip

Sorry, my mistake. It was just a typo. I am testing the latest version .243!

This bug is found in both the current as well as the beta version of AD: When you draw a shape, change the pressure values of the stroke (just drag one point of the pressure curve to 0), go to (brush) properties in the same dialog and now the "size variance" initial value is always 0. (Should be 100 after you changed a point of the pressure curve to 0) In AP the brush brush property box inside the stroke parameter box is completely useless since no parameter can be edited except the "Texture" button "Set Texture" ... but setting a texture has no effect. Cheers, Timo