fde101

Yes, and this gives you added flexibility. You can leave them attached (as I generally do) and still be able to place them where you need them within the constraints of attachment, which allows you to move the window of the application around to keep it out of the way of other applications, or you can spread everything out, placing different parts of the same program (or more commonly different documents) on different monitors as appropriate.

A number of users have requested the option of collapsing panels into icons like that, so that piece of this is essentially a duplicate request. As to the concept of the concept of eliminating the panels, that is inconsistent with a professional workflow. Studio panels are designed to stay accessible by default to provide immediate access to their content. I don't want to have to click icons on the sides of the screen every time I switch from a color to a text style - both should be in front of me and immediately available without the extra clicks, menu diving, switching tabs, etc. Granted that there are too many studio panels to keep ALL of them accessible at ALL times - but the idea is that we can set them up and switch them around to match them to the task at hand, laying out the screen to match a workflow in which we are actively involved. This is not possible with the iPad interface and is one of its limitations as compared to the desktop version at this time. With the desktop version we can use large, high-resolution displays to organize the panels for increased efficiency of the task we are performing. Note however that even now if you have several panels stacked on top of each other within a set, you can collapse a set of them by clicking on the tab to collapse them down to the tabs.

Data merge is for stuff that changes throughout the document. Global colors are for colors that are the same throughout the document. Completely different concept and purpose - though a color variable which could be impacted by merge is not a particularly bad idea, it would be a distinct concept from a global color, and questions such as how to map the use of the color to a particular merge record and what to display for the color when no merge record is present would then come into play...

This is a duplicate thread and should probably be closed?

Maybe as an option, but certainly not as a required feature, and ideally not as a default. Those who are taking color seriously will generally want to avoid as much color influence as possible from the area surrounding the image. Spectrally neutral pigment-free neutral gray paint which is designed for environments such as color grading studios can run $120/gallon (and needs to be paired with appropriate lighting to be fully effective). In environments like that, colored tabs like this would be a major problem, as they are even closer to the image being worked than is the paint on the walls. Serif already provides the option to make all the icons grayscale, which is likely an important factor for those environments also.

Rest assured there are many who find it bad, not necessarily all in the same ways, most of whom are not wearing themselves out writing online books to describe it in such exhaustive detail that the developers at Serif will probably never take the time to study it... ...though I am reminded of an old web site that is no longer maintained but is still around in a sort of "archival" status - not sure but I may have posted a link to this before: http://hallofshame.gp.co.at/shame.htm

If you were using physical media and tried to rest your hand on a wet painting you would paint your hand and smear the artwork. Resting your hand on a touch screen in particular is just flat out bad. Even without a user interface control there, if you are zoomed in enough artwork might be there instead and you could be changing it. That is not to say that the interface design of v2 on the iPad is actually good... it does have a number of relatively serious design flaws (the whole on-screen modifier key swivel thing in particular is just stupid for a touchscreen design)... but the crux of some of your complaints boil down to problems which are ultimately being caused by your own bad habits, possibly combined with Apple removing too much of the inactive rest/grip area surrounding the screen.

Try turning on the alignment handles in the Move tool (this can be found on the context toolbar). Make sure snapping is turned on. Then you will get additional handles surrounding selected objects which you can drag to align them to other objects: for this example, select the square and drag the center horizontal alignment handle (double-arrows left and right which display near the center of the square) until it snaps to a guideline at the center of the circle.

Why stop there? Layer FX properties too... Corner radius... Stroke thickness... How about reverse duplicates? If we are rotating four copies forward, add another four copies rotating/translating in the opposite direction?

You can select them in the Layers panel, but I agree, an option to select a locked object by holding a modifier while clicking on it (or perhaps by double-clicking on it) would be useful at times.

Wondering if there is a difference in how rendering intent is being handled? In the Affinity apps it is configurable in Preferences/Settings but in Pages I don't see an option for it so not sure what is being used there.

The original Mac operating system was single-tasking. The 128 KB of RAM in the original Macintosh simply wasn't enough to juggle a bunch of GUI-oriented applications at the same time. One application at a time. This resulted in user interfaces where the tools were right on the screen without any kind of window frame, such as in the original MacPaint: https://en.wikipedia.org/wiki/MacPaint#/media/File:MacpaintWP.png Notice that the entire screen is the application frame.

I think these are both bad ideas. There are plenty of "design for dummies" apps out there already, no point in Serif wasting their time on another. A separate "easy mode" is bad for the reasons @MikeTO outlined, along with others. Personally I think the Layer menu could be split into two: one with the actual "layer" properties such as group/ungroup, hide, arrange/align, etc., and one with the more "graphical object" properties, such as Convert to Curves, Expand Stroke and the like, but I'm at a loss as to what to name the split-off menu - calling it "Graphical Object" or even just "Object" doesn't quite feel right.

The Table Formats panel works quite well for quickly formatting an entire table. The problem here is that the OP has a specific use case in which formatting needs to be applied differently to specific cells of the table which do not match the calculable patterns which can be used in defining those table formats. I agree that there is not currently a good solution for applying styles selectively to arbitrary cells.

If whoever wrote the posts you are searching for did not know the correct terms (or the same incorrect terms as you do for that matter) you will wind up with a similar problem.

Yes, that is how that software works, and yes, that is a limitation of such programs. A benefit, on the other hand, is that most such applications provide ways to repeat the adjustments/edits against other photos, so if you have a bunch of photos that were taken at the same time in the same place, you can make your adjustments to one of them, then apply those adjustments in bulk to the others as appropriate, and the adjustments are still just slider values and the like so you can still tweak them per photo if needed. The solution to the proprietary nature of the tracked edits is obviously to export the photos in their completed formats once you are happy with them and need to use them outside of the application in which you performed those adjustments/edits.

There are numerous options out there for this already; just a few examples: Capture One DxO PhotoLab On1 Photo RAW DarkTable RAW Therapee Luminar Neo

Just to point it out, if you have Publisher and are not using artboards you can do this for a top-level layer by moving its content to a master page and placing the master on the page that originally contained the content. Not ideal, not practical, and not usable under all conditions, but it is something sometimes anyway.

One factor is that the dimmed text of the layer type is not responding at all to the UI contrast/brightness settings. The undimmed text of layers that are named does respond, and the background responds slightly to the "UI Brightness" control, but the range of that control is a bit too limiting to get the dimmed layer type text to a reasonable point. I would argue that the fact that the text does not respond to those settings is probably best treated as a bug. The general lack of contrast/readability for that text may not be a bug, but it is clearly a design flaw. If you hover over the layer preview / icon you get a tooltip with the same text that is being displayed, except that it is actually quite reasonable to read - but you shouldn't really need to do that. I agree that there should really be some improvements in this area.

These standards are established by the underlying operating system when there is a graphical interface. A macOS application should follow macOS standards for fonts and for icon sizes. A Windows application should follow Windows standards for fonts and for icon sizes. Match the platform, match other applications on the platform. It makes sense that design applications would differ from others when it comes to color, as the use of neutral colors surrounding the workpiece is essential to avoid distorting the perception of the colors in the design itself, but there is zero value in failing to adhere to documented and established conventions of the platform when it comes to things like font and icon size. Laptop users do this somewhat frequently. For example, I carry one between home and the office for my "day job" and at the office I have a second monitor on my desk that I use, while when working at home I only use the one built-in to the laptop. I could easily arrange for a second monitor to use at home as well, but it would not be the same monitor I have at the office...

If they are different to the point that this can impact them, they should be working on solving this problem too. (And yes, I know that won't actually happen any time soon - but that doesn't change the fact that it is the ideal).

One is for stroke, one for fill. The point of it is that if they are separated from each other, then you are no longer switching between the two, eliminated the extra click needed when doing that. If you are no longer switching, then the application won't know which one to apply that "none" swatch to unless there is a separate one for each. Bingo. That s the point I was trying to make earlier. If an application provides independent controls for this and ignores the ones provided by the OS, it is in effect ignoring the user's preferences (as established within the controls provided by the OS), and even if it operates as on "offset" from those preferences, it is still no longer matching up with other applications on the system, which is generally a bad thing.

Accepting entry of international and accented characters would probably work too, but that doesn't seem to be supported at the moment either.

That depends on what you are optimizing for. For a smaller display as was typical in the early days of PhotoShop and other similar software, and is still typical when working on a laptop, the existing design is better. For a modern desktop as most more serious users would be working on, his suggestion for example 1 eliminates a click to switch between the outline and the fill. With the traditional/existing design, if the fill is selected, you need to click on the outline in order to make it active, then you can click again to change the color, use the separate button to remove the color, etc... with this suggested redesign the implication is that both fill and stroke are immediately accessible without that extra click to switch between them. It uses slightly more screen real-estate but can save time as a result, and with larger monitors as are more common now, the use of extra space should not be an issue for quite as many users. I could see adopting this when there is enough room for it to fit on the screen, and falling back on the existing approach when there is not.