fde101

His analogy still holds up. The white background emulates a typical white sheet of paper which is the standard in every professional image editing and painting software I have ever come across. Your suggestion is far from the norm and something you have to learn to accept. Illustrator actually behaves fairly similar to how the Affinity Suite does it by having a white background with only an empty layer available on startup. You can also toggle between the two modes and create brand new layers by drawing vectors, just like Designer and similar to Photo's Assistant. Photoshop does this differently by having a locked white filled layer, which is actually a bit limiting when you have to delete the background layer if you don't need it instead of just toggling between checkers and white. Either way, the background is white by default regardless of software.
Also, the layers that the Assistant creates are completely transparent until you put down paint on it. By your logic of "layer = paper", a newly created layer should be filled with white for it to count as a sheet of paper, since actual paper does not have transparent layers.

The pixel selection is largely independent of the existence of content.
 
No, it just means that anything which is there is transparent/invisible.  Creating a pixel layer in a document with a transparent background does not suddenly make the background opaque, so it really doesn't tell you anything about the state of the layers/objects within the document: the layers can have transparent content at that point and there is "something there" but you still can't see it.  The opaque or transparent background exists behind the layers, independently of them.
 
The one on the Color panel?  That works quite well with no content in the document as it can pick from anywhere on the screen, including other applications.
 
This is because the layer that exists is most likely completely transparent so you are seeing the "paper" through the layer.  If you don't want them to look the same, then simply paint something onto the layer.

The pixels are present in the document even if there are no layers to provide them with any content other than the background (either solid white or transparent), so yes they can be selected.
 
Sure there is...  the "empty" document is like a blank sheet of paper.  Even if you haven't applied any ink to it the "paper" is still there and can be either transparent or opaque.
 
That one also works for me even when there are no layers.  If the document is transparent it is selecting the background as a solid black color (that one might be a bug?), while if it is opaque it is selecting the white of the "paper".

For the marquee selection tools (as opposed, perhaps, to the Flood Select Tool (the magic wand)) it makes perfect sense.
A marquee selection is not a selection of pixels. It is a marked region of the document, independent of any layer. When you make use of the selection (copy, or delete, or apply some adjustment) your action is applied to whatever layer is selected and visible. But the marquee selection is not itself part of that layer, and you could make another layer active and the selection would apply to it, instead.
Because it is independent of any layer, you do not need any pixels to make a marquee selection.

The pixel selection is largely independent of the existence of content.
 
No, it just means that anything which is there is transparent/invisible.  Creating a pixel layer in a document with a transparent background does not suddenly make the background opaque, so it really doesn't tell you anything about the state of the layers/objects within the document: the layers can have transparent content at that point and there is "something there" but you still can't see it.  The opaque or transparent background exists behind the layers, independently of them.
 
The one on the Color panel?  That works quite well with no content in the document as it can pick from anywhere on the screen, including other applications.
 
This is because the layer that exists is most likely completely transparent so you are seeing the "paper" through the layer.  If you don't want them to look the same, then simply paint something onto the layer.

@Ushur,
You can do at least the first three already using the move tool after making your selection.
To set the rotation point, turn on the "Enable Transform Origin" button on the context toolbar, then drag it to where you want the rotation to anchor.  To use that same point to scale around, hold down the command key (on Mac - if you are using the other platform check the status bar for what key to use) while dragging one of the handles.
Depending on what you mean by distortion, if your selection is not an entire layer try Layer -> Duplicate Layer to make it into one, then try either the Mesh Warp Tool or the Perspective Tool; one of those might do what you want?

@Ushur,
You can do at least the first three already using the move tool after making your selection.
To set the rotation point, turn on the "Enable Transform Origin" button on the context toolbar, then drag it to where you want the rotation to anchor.  To use that same point to scale around, hold down the command key (on Mac - if you are using the other platform check the status bar for what key to use) while dragging one of the handles.
Depending on what you mean by distortion, if your selection is not an entire layer try Layer -> Duplicate Layer to make it into one, then try either the Mesh Warp Tool or the Perspective Tool; one of those might do what you want?

Well Image edtor, but not a first grade RAW processor per se. - As fde101 IMO correctly stated here ...
... so it's more or less what PSE partly offers without the PSE Organizer and CameraRaw sidecar file handling etc. APh is here no real comparable replacement for Aperture, LR, C1, DxO, RawTherapee, Darktable ... and so on. Since it lacks certain RAW processor strength features like for example reusable sidecar files, DCP color profile support (important for target calibration support), customizable processing settings for bulk RAW conversions, teathered shooting support etc.

Of course there's nothing wrong with comparing to other programs, and nothing wrong with mentioning Adobe Illustrator (by name; no need to 'encode' it). That's not the issue.
The issue is that too many users effectively demand that something 'absolutely essential' (everyone's pet feature is the most 'absolutely essential deal-breaking omission that must be addressed right now, or else!') be implemented just like it is in Illustrator, under the assumption that just because Adobe dominates the market, Illustrator's treatment must be 'best'. It's often rather transparent that many of the most vehement demands come from people who seem to have little to no experience with anything else.
Generally speaking, Illustrator's interface is hideous; cumbersome, scattered, confused, inconsistent, redundant. In a word, very inelegant. It's not the program to emulate. We need to get over Illustrator so we can, at long last, get beyond Illustrator.
No. When one software company merely mimics another, that does not give us choice; we just get the same ol' same ol' conventional-wisdom approach and the 2D vector drawing segment continues to languish in its current functional mediocrity.
When customers (I don't like being referred to as a consumer; I'm a producer) win, is when they demand better and an attentive provider listens.
So sure; whenever we find ourselves missing something we depend upon, we should feel free to describe how it works in whatever program we're accustomed to for explanatory purposes. But we should put more effort into it than just that. Try thinking through what the feature really does, why it's important, and imagine how the desired functionality could be advanced rather than merely mimicked in "me, too" fashion.
JET

@Ushur,
You can do at least the first three already using the move tool after making your selection.
To set the rotation point, turn on the "Enable Transform Origin" button on the context toolbar, then drag it to where you want the rotation to anchor.  To use that same point to scale around, hold down the command key (on Mac - if you are using the other platform check the status bar for what key to use) while dragging one of the handles.
Depending on what you mean by distortion, if your selection is not an entire layer try Layer -> Duplicate Layer to make it into one, then try either the Mesh Warp Tool or the Perspective Tool; one of those might do what you want?

Apologies if this seems picky (or obvious), but to be clear, if you open and save a document in the beta version you might not be able to open it again in the released version after that due to a file format update. We do suggest you make copies of files you intend to open in the beta to avoid any accidents. :)

The best way to handle this is likely to "like" the post requesting the feature.  That provides a numeric tally of interest without cluttering the forum with useless "+1" posts that waste everyone's time.

Ho @Jeannette, welcome to the forums!
 
This is actually the only way to run the beta as it will not open unless it sees the released version installed.
They can be run side-by-side and do not share settings, but be warned that if you open a document in the beta version, you might not be able to open it again in the released version after that as it could be updated to the newer file format that the released version doesn't understand.

Perhaps the widget could represent the keypoints (colour stops) of the initial gradient in a manner like this?

 
This leaves unanswered what happens after additional colour stops are added, though 
I think this is an interesting discussion and I realize how hard it must be to create a good user interface...
d.

Hi @Lorox,
since you are asking. I support your suggestion, it seems to be logically to me. It didn't bother me too much so far.
Cheers,
d.

Hi dominik,
as to your question (sorry for answering somewhat belatedly): making the bounding box invisible while dragging the selected object works perfectly for me, too.
However, when the object which I'm working on is stationary and I just want to change some of its attributes – like, say, fiddle around with its stroke width or with a gradient or an effect that's been assigned to it – the bounding box with its blue lines and other marks becomes really obtrusive and it's sometimes hard to judge the effects of what I'm doing to the object in an unhindered way. This is especially true if that object is rather small but you have to see it in context with other elements around it (thus limiting the zoom factor used and leaving that object rather small on screen).
And while working on that object, I'll just HAVE to move the mouse (or pen) which immediately makes the bounding box become visible again...
As to your other remark:
I have Publisher and I checked what you wrote – it is exactly like you say (in InDesign it's just the same – and for good reason), BUT:
in "Preview Mode" everything that's not printing is hidden (as expected) EXCEPT for a selected object's bounding box! So we're back to the original problem...
In Illustrator, however, you have exactly what I'd really like Designer (and, for that, Publisher) to have:
in the "View" ("Ansicht") menu you can toggle between "Hide Corners" ("Ecken ausblenden") and "Show Corners" ("Ecken einblenden") which actually applies to selected objects. This way you can work on an object which then just shows "live" the changes you're making to it but doesn't show any markers showing that it's actually selected at the moment (but which you, of course, know at the time) – this way you're getting a true and unhindered preview!
Seems simple enough to me and I do hope the guys at Serif won't find it too hard to implement in the future...

They are base styles which provide something for other styles to build on.  You would use them to set up common style information to be used across a family of styles, then create other styles based on them which override specific characteristics of the base style.
You can do the same thing with other types of styles, but those would show up in the lists on the context toolbar (for example) in addition to the Text Styles panel.
Group styles only show up in the Text Styles panel and cannot be directly applied to text.
 
In short, the only real difference between the types of styles is what they can be applied to:
Group styles - can't be applied to anything Paragraph styles - are applied to entire paragraphs Character styles - are applied to text within a paragraph (which may not be the entire paragraph)  
Additionally, paragraph formatting options are not available when editing a character style (as they would not be applicable).
 
Each style inherits from any style it is "based on" all the way up the hierarchy until the special "[No Style]" of the appropriate type is reached.
 
The selected character style for a range of text overrides what is in the paragraph style applied to the paragraph containing that text.  Local formatting (if any) overrides both.
 
Exactly one paragraph style can be applied to a paragraph at any given time, and exactly one character style can be applied to any particular character at any given time, though either one might be the special "[No Style]" (which acts more or less like a style which does not derive from anything else and cannot be edited).

-3
 
There, it only took me one post to get ahead of your two :-)

The problem is that this is a lie as soon as it is printed on the page.

In some ways this will depend on the nature of how your styles are structured and the complexity of the document's design, however.
Since you can inherit from non-group styles as well, you could just as easily (in your example) placed all of the information in the "Normal" paragraph style then based the "First" and "Last" styles on that.  They could have inherited those properties from the Normal style and just changed the indent / decorations as needed so that you could have made your adjustments in the Normal style and the others would have followed suit.
 
I do think that your use of the group style makes the breakdown a bit more clear however, and particularly if this structure is being used in combination with other styles in a more complex set is likely worthwhile.

To put some context around this, one of the highest-performing Android tablets out there right now is the Galaxy Tab S6, which has a roughly $650 price tag (Wi-Fi 128 GB model) and an OpenCL score of 2299.
The 6th gen iPad (Wi-Fi 128 GB model) - not even the iPad pro - has a Metal score of 2793 (its equivalent to the OpenCL score for Android) and a price tag of $429.
Granted that the multicore (CPU) score on the Tab is 2468 compared to 1405 for the iPad, but from what I gather the Affinity apps on the iPad depend much more heavily on the Metal performance (which would translate to OpenCL on the Android tablets) than on the CPU performance - and an iPad pro (granted a fair bit pricier) has a multicore CPU score of 4604 with a Metal score of 9149, neatly trouncing both of them on all counts.
 
When you look at the more "affordable" Android tablets (since your concern seems to be with the price of the iPad), the numbers look much worse for Android: the $330 Asus Zenpad 3S 10 has a multicore score of 762 and no OpenCL support at all apparently (as the score is marked "N/A"), while the $450 Galaxy Tab S4 shows a multicore score of 1489 and an OpenCL score of 1743.
In short, by the time you have something comparable to the performance of the iPad in the form of an Android tablet, you are actually paying more for the Android tablet than for the iPad.  If you are hoping for an Affinity version for Android in an attempt to save money compared to the iPad, you either won't be happy with the performance or will need to invest in a tablet that will wind up costing more than the iPad would have anyway.

To put some context around this, one of the highest-performing Android tablets out there right now is the Galaxy Tab S6, which has a roughly $650 price tag (Wi-Fi 128 GB model) and an OpenCL score of 2299.
The 6th gen iPad (Wi-Fi 128 GB model) - not even the iPad pro - has a Metal score of 2793 (its equivalent to the OpenCL score for Android) and a price tag of $429.
Granted that the multicore (CPU) score on the Tab is 2468 compared to 1405 for the iPad, but from what I gather the Affinity apps on the iPad depend much more heavily on the Metal performance (which would translate to OpenCL on the Android tablets) than on the CPU performance - and an iPad pro (granted a fair bit pricier) has a multicore CPU score of 4604 with a Metal score of 9149, neatly trouncing both of them on all counts.
 
When you look at the more "affordable" Android tablets (since your concern seems to be with the price of the iPad), the numbers look much worse for Android: the $330 Asus Zenpad 3S 10 has a multicore score of 762 and no OpenCL support at all apparently (as the score is marked "N/A"), while the $450 Galaxy Tab S4 shows a multicore score of 1489 and an OpenCL score of 1743.
In short, by the time you have something comparable to the performance of the iPad in the form of an Android tablet, you are actually paying more for the Android tablet than for the iPad.  If you are hoping for an Affinity version for Android in an attempt to save money compared to the iPad, you either won't be happy with the performance or will need to invest in a tablet that will wind up costing more than the iPad would have anyway.

To put some context around this, one of the highest-performing Android tablets out there right now is the Galaxy Tab S6, which has a roughly $650 price tag (Wi-Fi 128 GB model) and an OpenCL score of 2299.
The 6th gen iPad (Wi-Fi 128 GB model) - not even the iPad pro - has a Metal score of 2793 (its equivalent to the OpenCL score for Android) and a price tag of $429.
Granted that the multicore (CPU) score on the Tab is 2468 compared to 1405 for the iPad, but from what I gather the Affinity apps on the iPad depend much more heavily on the Metal performance (which would translate to OpenCL on the Android tablets) than on the CPU performance - and an iPad pro (granted a fair bit pricier) has a multicore CPU score of 4604 with a Metal score of 9149, neatly trouncing both of them on all counts.
 
When you look at the more "affordable" Android tablets (since your concern seems to be with the price of the iPad), the numbers look much worse for Android: the $330 Asus Zenpad 3S 10 has a multicore score of 762 and no OpenCL support at all apparently (as the score is marked "N/A"), while the $450 Galaxy Tab S4 shows a multicore score of 1489 and an OpenCL score of 1743.
In short, by the time you have something comparable to the performance of the iPad in the form of an Android tablet, you are actually paying more for the Android tablet than for the iPad.  If you are hoping for an Affinity version for Android in an attempt to save money compared to the iPad, you either won't be happy with the performance or will need to invest in a tablet that will wind up costing more than the iPad would have anyway.

This would most likely be a feature of Designer rather than of Photo, and indeed has been requested there already.  It may be some time before this happens, however.  Serif has indicated in other threads that while they have had tracing features in past software they are not happy with their accuracy and are planning on doing something much better for Designer, though that means it will take more time to achieve.

Yes, in Designer there is actually an option to switch between the two modes (pixelating the preview or scaling it to show it sharply) but Photo is locked on the pixelated view, very likely for the reason suggested here.  This has come up numerous times on the forum.