Sneak peeks for 1.7

[VFXTobias]

Forgive me if I missed this.  I didn't see it when I scoured over the thread.  Are we getting improvements on the pen and brush tools that will allow us to draw constrained paths, eg shift-drag in direction, as opposed to the current shift-click a second point option?  The former is a bit more useful in most situations and requires fewer steps to a result. 

[A_B_C]

It's not uncommon to want to replicate the angles and lengths of curve handles across multiple nodes. But snapping curve handles to the grid is a crude way of accomplishing that.

Ben will probably implement it as a local snapping option. I'm one of those who think this is actually quite useful for some types of projects.

When you prepare glyphs for a font development application like FontLab in Affinity Designer, the option of snapping handles to the grid is necessary. Theoretically, certain font formats will allow fractional coordinates for nodes and handles, but for reasons of compatibility, applications like FontLab will round coordinates to integers on font export by default. In order to achieve maximum control over the glyph contours you can expect in your font file, it certainly makes sense to work in integer space at least from a certain point in your design process on. And then you must have the option of snapping handles to the grid. I know, there may be much more illustrators than type designers out there, but personally, I would not consider glyph design an edge case for a vector drawing application. 

[Mithferion]

Well, you learn something new every day.

Best regards!

[Tourmaline]

On 6/8/2018 at 6:06 PM, A_B_C said:

It's not uncommon to want to replicate the angles and lengths of curve handles across multiple nodes. But snapping curve handles to the grid is a crude way of accomplishing that.

Ben will probably implement it as a local snapping option. I'm one of those who think this is actually quite useful for some types of projects.

When you prepare glyphs for a font development application like FontLab in Affinity Designer, the option of snapping handles to the grid is necessary. Theoretically, certain font formats will allow fractional coordinates for nodes and handles, but for reasons of compatibility, applications like FontLab will round coordinates to integers on font export by default. In order to achieve maximum control over the glyph contours you can expect in your font file, it certainly makes sense to work in integer space at least from a certain point in your design process on. And then you must have the option of snapping handles to the grid. I know, there may be much more illustrators than type designers out there, but personally, I would not consider glyph design an edge case for a vector drawing application. 

Vector packages are heavely used for font design, so Affinity designer is no exception.

[FT_SG]

On 6/8/2018 at 5:30 PM, FT_SG said:

Wow, developer collaborating with user community, that's great.

Many ask for features and enhancements, etc...

I have 2 humble ask:

1. Improve speed in both raw processing and adjustments preview refresh...Seems like the program is taking lots of CPU & Memory resources relative to other similar programs

2. Reduces the size of the Afphoto document file, its massive a few edits and it can be much bigger than the raw file from 50 MP raw file...storage is cheap these days but still not a good use of resources and make backup much more time-consuming...many other programs sidecar file are way smaller

If I may add to the above 2 items which are pretty fundamental...

1. To have a cataloging feature...so that editing photos taken can be much easier, to first cull the photos, rate, etc then move to develop, edit, export...

i am trying out the trial version and just tried to do it with my shooting session...it is a pain to manage....have to switch back and forth to move files to folders that will keep for develop, etc...not a natural workflow and a waste of storage and time consuming.

if Affinity photo can speed up the performance, reduces the file size and have a cataloging feature, it will be a winner, those very specific and more nitty gritty features are niche, and nice to have. think of the larger community...feature sets are pretty rich already, from layers, stacking, Color channels, markings, selection tools....but with slow speed, large files that take much undue time to backup edits and lack of cataloging features just make it few notches behind....without these few fundamentals will not be adopted as full fledge system like adobe and captureone etc....I believe affinity photo has the features and functions covers (90%) but seriously lack what I mentioned.

[Ben]

On 6/8/2018 at 5:06 PM, A_B_C said:

It's not uncommon to want to replicate the angles and lengths of curve handles across multiple nodes. But snapping curve handles to the grid is a crude way of accomplishing that.

Ben will probably implement it as a local snapping option. I'm one of those who think this is actually quite useful for some types of projects.

When you prepare glyphs for a font development application like FontLab in Affinity Designer, the option of snapping handles to the grid is necessary. Theoretically, certain font formats will allow fractional coordinates for nodes and handles, but for reasons of compatibility, applications like FontLab will round coordinates to integers on font export by default. In order to achieve maximum control over the glyph contours you can expect in your font file, it certainly makes sense to work in integer space at least from a certain point in your design process on. And then you must have the option of snapping handles to the grid. I know, there may be much more illustrators than type designers out there, but personally, I would not consider glyph design an edge case for a vector drawing application. 

I'm guessing that the grid pitch you'd use for this approach would be quite tight/small? Essentially giving you something similar to snap to pixel, but in your own units?

 

The use case presented early on showed a very coarse grid - that did't leave much control artistically speaking.  As I've said before, if people present a real use case to justify a feature, then I'm more likely to find ways to make it happen.  Wanting snap to grid where the grid is 10% pitch of the design size, that just seemed counter-productive and very restrictive from an artistic point of view.  Of course, you will be able to do that now, if that's really what you need. *ahem*

[MEB]

Snapping handles (and nodes) to the grid can be useful for basically anything that belongs to some sort of design "system": signaletic/signage design, icon/ui design or glyphs on a font all depend on an underlying grid structure to give them consistency/coherence. The grid may not be visible but the reference points it provides both for the nodes and handles of the objects that compose the set helps to strengthen/unify the elements and make them part of the same family/all sharing particular traits (helping shaping curves, angles, dimensions/scale etc precisely). Unless we could constraint both handle angles and their lengths to a specific (configurable) size/metric for this same purpose there's no other quick way than using a grid and snapping both handles and nodes to it. This is particularly important when we are building several elements that must share a very specific set of characteristics.
It works a bit like layout grids for publications - we don't see them (and they work at a different scale/level when compared to the grids for icon/fonts etc) - but the principle is the same: the "rhythm", sense of organisation/hierarchy they "impose" on the elements help to strengthen the layout and give it coherence on all spreads/pages.

[A_B_C]

Basically, these are the official suggestions for importing artwork from a vector drawing application to FontLab or Glyphs:

http://help.fontlab.com/fontlab-vi/Importing-Artwork/#step-one

https://glyphsapp.com/tutorials/importing-from-illustrator

So regarding the particular use case I had in mind, you are right, Ben. I should have probably said we would need the option of snapping handles to whole pixels (or points) when we follow the approach suggested by the support documents listed above. But in a more general sense, I would subscribe to what Miguel said in the follow-up post. 

[Ben]

And, to end the discussion, I'll just say that 1.7 will let you snap curve handles to grid, geometry, anything you want... it will be an option, to allow snapping handles to happen the same as snapping nodes, so it can be turned on for those that require the feature.

This will be separate to the constraining features I demoed earlier showing constraining of handles directions and snapping lengths.  the two features will live together, but you can use one or both.

 

[AuthorAuthor]

Thanks for that, Ben. It will surely be useful in my work. The vector programs I've used to date allow snapping of nodes, but not their handles, to other objects.

 

My Best,

 

Gary

[A_B_C]

Thank you, Ben! 

[JET_Affinity]

On ‎6‎/‎8‎/‎2018 at 9:36 AM, VFXTobias said:

Are we getting improvements on the pen and brush tools that will allow us to draw constrained paths, eg shift-drag in direction, as opposed to the current shift-click a second point option?

When the Pen Tool is active, you can put it in "straight line mode" by clicking the straight path button in the options bar at the top of the window. That makes the Pen act much like the separate Line Tool in Illustrator. (Someone had to point it out to me, too.)

JET

[AuthorAuthor]

Hi Jet and thanks for the info. Just a stray question here from a keyboard combo kinda guy.
Would holding Ctrl/Cmd while using the pen get rid of the need to move your pointing device up to a toolbar to change the pen's properties?

I'm not quite following, with a superbly engineered existing program why context menu options aren't specific to a tool, and why Ctrl and Alt/Opt don't serve an "extended" purpose.

I'm not presumptuous enough to suggest a design, but CorelDRAW and other design programs make extensive use of keyboard shortcuts, so they can clutter the toolbars with other stuff :).
Love to see the Best of the Best in the new version.

 

My Best,

 

Gary

[VFXTobias]

Thank you JET.  That was helpful.  I share the same thoughts as Author on this one.  It appears we can't set a shortcut to this.  Also, this functionality isn't present for the brush tool.  I'm sure you guys must hear this at nauseam but for those of us out here in the wild doing concept work and boards for commercial/film projects, we need to have this functionality.  It's a matter of workflow efficiency, quality consistency, and rapid prototyping.  Much of the work we'll do is with the brush tool so having the functionality that you pointed out in the pen tool BUT with the ability to bind a shortcut key to it would really complete your task in terms of developing for usability.   It's one those "small" things that has a major impact on using Affinity vs. the other folks.

[AuthorAuthor]

To wax anal here a little (?), I read the Microsoft Guide to Interface Design, 246 B.C., and one of the mantras was, "Do not let the UI get in thne way of the user's creative process."
Adobe Systems violates both the letter and the spirit of this, with "proxy boxes" all over the place. Dear Adobe Systems: It's called a graphical interface. We're supposed to drag and move live in the document window, not an interruptive dialog or proxy box.

 

Why don't you just send the user to a command line?

 

 

Seriously, Affinity shall continue winning awards as long as you avoid the pitfalls of those who've gone before you.

 

TIA for listening,

 

Gary

 

 

[hpetty]

On 6/6/2018 at 1:06 PM, RobertShatty said:

Every Animation Studio use Python in their Pipeline. JavaScript is not standard in animation pipeline.

GIMP has Python Fu, which opens a door to do more complex stuff, plus python has huge number of libraries.

I hope Affinity will give support for Python API. Thank you

The company I work for has actually been looking into moving to Affinity from Photoshop for other reasons...but if there was a Python API, I'm almost certain they would switch. We aren't an animation studio but we are in the 3D industry and as said above most 3D industry related software (Maya, 3ds Max, Nuke, Blender, and others) use Python as their API language. It comes with so much more functionality through its standard libraries over a variety of subjects and has a HUGE community. Using Python would make Tool Dev almost seamless in these industries (as well as others I'm sure).

This would also set Affinity apart from Photoshop, which uses JavaScript. It's worth at least seriously considering. Python is being used by these huge software companies like AutoDesk and The Foundry for a reason. I'm guessing they didn't just pick it out of a hat.

[paristo]

On 6/8/2018 at 4:36 PM, VFXTobias said:

Forgive me if I missed this.  I didn't see it when I scoured over the thread.  Are we getting improvements on the pen and brush tools that will allow us to draw constrained paths, eg shift-drag in direction, as opposed to the current shift-click a second point option?  The former is a bit more useful in most situations and requires fewer steps to a result. 

That former is impossible to really do. 

Reason is why the Shift+Click is used is because you will define the direction from starting point and so on get correct angle. With Shift+Draw your hand is not so accurate to draw a line to exactly correct position after few pixels when starting to draw, so automatic angle detection would throw you always off many degrees, most often even 5-15 degree so you would end up drawing a line again and again and again to get it right. That leads instant frustration.

The answer for that would be the virtual ruler, what the shift+click really is (or could be) First click couple times to end / start of the points and then draw the line with your tool to control the pressure etc.

 

 

[paristo]

On 6/12/2018 at 6:19 PM, AuthorAuthor said:

To wax anal here a little (?), I read the Microsoft Guide to Interface Design, 246 B.C., and one of the mantras was, "Do not let the UI get in thne way of the user's creative process."
Adobe Systems violates both the letter and the spirit of this, with "proxy boxes" all over the place.

Why don't you just send the user to a command line?

[paristo]

Just now, paristo said:

On 6/12/2018 at 6:19 PM, AuthorAuthor said:

To wax anal here a little (?), I read the Microsoft Guide to Interface Design, 246 B.C., and one of the mantras was, "Do not let the UI get in thne way of the user's creative process."
Adobe Systems violates both the letter and the spirit of this, with "proxy boxes" all over the place.

Why don't you just send the user to a command line?

Couldn't get the quote box right and reply anymore so write here second. 

 

Adobe products does break many of the HIG rules, but so does Microsoft as well. They actually did a very few very good implementations, but it is actually accident as these things has been researched already at 70's how graphical user interfaces should be done. 

Like Microsoft got the Windows Phone correct by placing the actions to bottom of screen, not to top. The top part worked when screens were 2.8-3.5" but not since going to 4" or above.

What I would like to see in Affinity Photo is option to spawn the dialogs under the mouse cursor or to specific position so I can predict and move the mouse there. But Affinity has many lot better than many Adobe  implementations. But some are just requiring too many routes to do. Like how to fill a selected area with a color? With GIMP it is simply that you drag and drop the color from your color palette/wheel on the selection. To get in affinity photo "Selected color as transparent" really requires to google it how it is done, while with GIMP it is "Color > Color to Transparency". But when GIMP requires to know the workflow how to do a given effect by knowing the order and filters etc, with Affinity and Photoshop it is often predone process by click-be-done, but if you want to have the control, you need to do how GIMP does it.

 

Oh, and I would take commandline for many many tasks anyday. 

[filip89]

On 2/16/2018 at 11:28 AM, Ben said:

Childish...?

I know this is a small part of what you plan to achieve and I don't mean to imply that it should be a priority but to be honest that was also my first impression of the UI as well. It's not necessarily the colors but the way they are executed. Some have too much details,  outdated or are plain confusing. The colors don't follow a particular palette and lack consistency. Even the toolbar ones like 'breaking points' and 'join' etc. seem out of context. The persona icons also could use some work on context and execution. Not sure what market you aim at but it does make an impression.

The iPad version of Photo seems a lot better IMO.

Anyway, I use your software from time to time for personal projects and prefer some of the features and workflow over other design software. Glad you guys are stepping forward and won the Microsoft developing award. 

[JET_Affinity]

The biggest problem I had at first exposure was yet another "trendy" blacked-out treatment adopted by far too many graphics programs (including Adobe's) a few years ago, which is about as dumb for serious graphics work as it is for the pirate dress-up "biker" segment of motorcycling. Thankfully, Serif provided a retrieve from that hopefully short-lived fad in response to user demand.

There are no doubt as many opinions about the graphical design of the interface as there are designers. Personally, I'd love to see a seriously-capable drawing program designed to look seriously down-to-business, with emphasis on clean, unobtrusive functional clarity devoid of distracting gratuitous eye candy.  But mainstream drawing programs are designed to look "friendly" and "inviting" to casual hobbyists and "technically capable" to professional users at the same time. The balance of wide appeal is a narrow tightrope.

Overall, the Affinity design compares pretty well against current competitors in the same segment, and there are plenty of far more "childishly" confusing offenders even in "higher end" software (ever worked with Solidworks, for example? Great program, but hideously garish runaway icon-crazy interface.)

So I don't have any huge problem with Affinity's graphic design, but for one element: The "cogs" preview icons of the Style palette. Because they are large and randomly colorful (both consequences of their purpose), they disproportionally dominate the presentation when the program is first launched, and more than any other single element do give an initial "kid stuff" impression that's out-of-sync with the rest of the interface and belies the sophistication level of the program.

JET

[filip89]

9 minutes ago, JET_Affinity said:

yet another "trendy" blacked-out treatment adopted by far too many graphics programs

If you're referring to toolbox, menu backgrounds both Affinity and Adobe have options to switch lo light or dark frames. 

I agree with this:

12 minutes ago, JET_Affinity said:

emphasis on clean, unobtrusive functional clarity devoid of distracting gratuitous eye candy

Although Adobe fixed this too a while back with CC. Too many colors in UI is distracting and the BW option in Affinity makes the icons lose focus because they have too much going on. 

[GhostlyCat]

On 6/13/2018 at 8:01 PM, hpetty said:

The company I work for has actually been looking into moving to Affinity from Photoshop for other reasons...but if there was a Python API, I'm almost certain they would switch. We aren't an animation studio but we are in the 3D industry and as said above most 3D industry related software (Maya, 3ds Max, Nuke, Blender, and others) use Python as their API language. It comes with so much more functionality through its standard libraries over a variety of subjects and has a HUGE community. Using Python would make Tool Dev almost seamless in these industries (as well as others I'm sure).

This would also set Affinity apart from Photoshop, which uses JavaScript. It's worth at least seriously considering. Python is being used by these huge software companies like AutoDesk and The Foundry for a reason. I'm guessing they didn't just pick it out of a hat.

Hm... but Affinity Photo is not particularly oriented to 3D and animation as far as I can tell. Photoshop using JavaScript is actually more a reason to use that - because a lot of _image editing_ scripters are used to that. I‘m frontend designer (using Affinity Photo and Designer) and software developer for web and mobile apps. Python doesn’t play any role in that sector - JavaScript is booming though.

Another thing: JavaScript generally is booming enormously in the last years. It’s growing hugely in the dev sector and starting with ES2015 has a impressively growing feature set every other year (there is a standards process for that with all the big vendors participating: TC39). There are features like async/await, typed arrays for performance, shared memory & atomics, WebAssembly and so much more.

There even are more heavily big vendor maintained JS engines - all of them suitable to be embedded on Desktop and mobile platforms. JavaScriptCore even would be the natural thing to use on Mac and iOS.

I understand the Python has some user base in the 3D sector because some of the key players there decided on Python... well... many years ago. But 2018 is not 2008 - the dev sector has changed a lot and I can only stress that it would be a very crude decision to ignore JavaScript as a scripting engine as of today.

[SrPx]

Python is used with Django for web development.... We are not mentioning one booming language and a forgotten in the shadows one. The case is more about two heavily trendy right now, with different scopes and syntax styles. And is quite a complete language, widely used too (salaries above JS, BTW. Although the offer (number of jobs) is much larger in quantity for JS). But yep, JS in front-end is booming. Python is very much used in AI stuff, machine learning, and well, a lot of startups choose Python to build about anything. Specially additional tools/plugins, even if for handling a faster library to do the performance critical stuff (well, much like would be here, I guess). Krita uses python for its plugins system. Blender has been doing so since a very long time. Also, Python reads almost like plain English. Is a known fact that people find it very easy to learn....   I think both are good choices... (but the developers might have much more important and specific reasons to make the choice)

[AuthorAuthor]

On 6/15/2018 at 3:48 AM, paristo said:

Oh, and I would take commandline for many many tasks anyday. 

I was kidding. Before Windows, I had my share of command line work, and DOS programs that attempted to create a GUI. I use a command line today to play Zork, and that's about it.

My point, though, Paristo, is that a program, one can call intuitive—to varying degrees of success—I believe depends on how easy you make it to immerse the artist in the UI. To me, a proxy box popping up is not only interruption, but also wakes me out of a sort of "dream state" I've been in, ignoring real and virtual stuff around me and just concentrating on my task.

 

And 100% agreed that there are many "offenders" in the Good UI arena, including Microsoft. I just picked on Adobe Systems because I think they get lazy once in a while, resting on their laurels and reality that they're a market leader. It happens.

Sometimes, but not always, I can accept the reality that some programs, Illustrator in particular, demand idiosyncratic moves on the user's part. That is, non-intuitive gestures and key combos that once the user has memorized, make the program more accessible. This is relative, of course. But it also explains why person X doesn't "get", for example Illustrator, and dismisses it as a tool. While person Y has "met the program half-way", and works like lightning through it, bedazzling on-lookers.

• More than anything else, I'd like to see keyboard customization, extensive customization, available in a future build.
• Real, inspired use of options on the right-click context menu.
• Use of keyboard Ctrl, Alt, Shift in combination with the mouse wheel. To constrain motion, to add to a selection while defining the selection…if the mouse wheel is only for zooming and scrolling, then it's being wasted as an input thing the rest of the time.

 I really, really love the way this entire line of software is heading. Many, many thanks for including Windows in your user base. Please continue to keep it fast, tight, and open for revisions based on artist input.

One Happy Camper,

Gary