Andy05
-
Posts
575 -
Joined
-
Last visited
Posts posted by Andy05
-
-
24 minutes ago, Jowday said:
[...] Vector brushes are not vector. [...]
Seriously, this is the among the most ridiculous issues I have with designer as a replacement for any other (more or less major) vector based program on the market. A vector program with vector brushes, which are rendered as pixels? Serif, you really can't see the contradiction in this (yet continuing this path for years now)? But I bet, they'll just add some more fancy features for the next versions instead, which look great for showcasing all of their great tools and features.
I really want to switch over to Affinity software for almost all or my work. And it's working for far more than half of the jobs already. But sometimes one really has to question Serif's common sense or understanding of the (semi)professional market when it's about improving some their apps' features.
- Dazmondo77, bananayoshimoto, CLC and 2 others
-
3
-
2
-
4 hours ago, duncancreamer said:
I would like to think that this would be a great feature for Affinity! It would be the only app out there that could do this - as far as I know.
Corel Draw can crop open curves by using boolean functions with closed objects. I can't remember for how many years already.
-
I don't know if you couldn't read and understand my text or if you just didn't want to.
15 minutes ago, thomaso said:If an app in its version 1 or 2 does not offer a specific feature then it still can offer it "in version, 3, 4, or whatever". Or 10, 11 etc., without "massive problems" at any time on this way.
That's the point. "Let's do it later", is exactly the wrong thinking. As there will always be "bigger" things which one would want to add first, in version 2 as well as in version 2000. If it's possible "without massive problems" at any time - why not making "at any time" as soon as possible?
I said that ignoring small things for the sake of constantly adding new fancy stuff (which a customisable toolbar is NOT for obvious reasons) instead in order to attract new buyers can break a business' neck. As proven by countless examples out there throughout all sectors of all industries. A lot of big players' businesses went down the hill because they focused too much on adding new products/features/ideas/whatever whilst ignoring to maintain and improve existing stuff.A small amount of the things on a roadmap should be reserved for improvements/extending of small things. Again, I never said, that the toolbar should be the most important thing for the apps' roadmap. But it should be on the list nonetheless (and not just under "maybe, some time in the future").
I also never said, that Affinity will fail because they don't add a print icon (or a better costomisable toolbar). Neither did I say they constantly ignore all small request, because that'd be nonsense. But browsing through the forums should give you also a hint of a lot of common things which they haven't implemented for years as they've rather been working on other, "bigger" things, which sound better in advertising their products.
Latter is not a bad thing per se, but one has to find a balance in order to stay successful long term. That's all. And constantly arguing in this topic solely with "Wow! Hold a second! It needs work to do such (small) things!" is the wrong approach.
-
51 minutes ago, thomaso said:
Hm? – Do you mean if a requested print button will not get implemented then the app will never get an update in the future, neither with bug fixes nor with any other feature? What if Serif simply prefers to do bigger things first than "all those tiny tasks" of a print button?
It's not about a print button alone anymore. Not for ages. It's about a customisable toolbar. Since obviously quite some fear about the massive workload such industry standard feature might take, for heaven's sake, just make 5 or 10 user defined buttons, name them "A", "B", "C"... or "0", "1", "2"... and let them assignable with whatever 10 functions a user needs most.
If Serifs just continues to "strife to do bigger things", they'll have a massive problem in version 3, 4 or whatever, if they have countless things which they missed do to until then. Fortunately, they are not going that route.
Continuously adding new, fancy features is awesome, if you want to sell quickly. But that's also what's broken a lot of businesses' necks on the long run (that applies to all sectors, not just design/print/artsy programs).
-
And if all those tiny tasks already could overwhelm the Affinty staff (as you're trying to sell it to us here), there's not much future for this apps.
Hence, I rather like to think of some more competent people working for Affinty who could implement this kind of extension to existing code without panicking about breaking the whole program (or your lovely Mac)...
-
42 minutes ago, R C-R said:
FWIW, I also did some ML programming in the early 80's, although for a different CPU family. [...]
And yet, you're continuing with your arguments about how tricky implementing this request would be? That's kinda ridiculous. Seriously.
-
9 hours ago, R C-R said:
Yes, the code already exists. But there are no existing links to any of the new png files that would be required because those files do not yet exist, nor would they be automatically created simply by adding the files to the resources folder.
Oh, REALLY? Wow, you're trying to explain programming to someone who used to program machine codes (partially by just coding in hexadecimal numbers) in the early 80s for Z80 applications and games, my dear!
-
*sigh* You forgot to mention that Affinity surely has to hire 40 people to create 40 different icons... Seriously, did you ever create anything UI related in your life? I don't think so. Otherwise you'd have known better that creating icons in different colour schemes and sizes don't require 40 individual processes for creation.
1 hour ago, R C-R said:it must also be programmed to display the correct 'disabled' version
No. Or do you get the same icons now in all your scenarios? You can ignore it as often as you want, but I'll tell you again: That code for a customisable toolbar already exists. The links already exist. The translations already exist (i. e. in menus). The only thing to do is connecting this already existing stuff with - admittedly, new to create - icons. (Which any average gifted designer could finish within 1-2 workdays - in all resolutions and colour schemes.)
1 hour ago, R C-R said:adding a few dozen items to the customizable toolbar list could easily raise that number into the thousands.
Time to give up, someone comes with arguments of the 80ies ("WOAH! THOUSANDS OF FILES! HAAALP!"). I'm not living in the holy times when floppy discs have been status quo anymore.
If you feel better: You won, I'm out. As you'll just continue to discuss with arguments which apply to new massive features but not for small adjustments to existing ones. And I really don't want to waste more time on this pointless discussion as we won't find a consensus as long as you think the the developers are incapable of connecting existing links and text with icons properly or as long as you're worried about thousands of tiny files on your device(s).
My previous advice is gold now: Never upgrade your current Affinity apps, you might fall into the trap of getting more files, more features and - who knows? - a full customisable toolbar one day! -
12 hours ago, R C-R said:
Yes there is, but adding dozens of new icon buttons to it means each of those icons in all their forms [... more elaboration of how difficult and how much workload are needed got deleted ...]
Ok, now I got you ! You obviously never worked in a business or for a client with more than 3-5 employees. As otherwise you wouldn't just post such a nonsense when talking about developing such applications als Affinity does.
-
5 hours ago, R C-R said:
I know that a huge part of developing really good software is deciding what not add to it
Your whole comment is rather pointless in this discussion as there is already a customisable toolbar available in the app. It just lacks more options. And if you deem those as "bloatware" or if devs can't add a couple of dozens of icons and links for it without performance or stability issues, they have way more problems than a non-customisable toolbar.
Honestly, do you really think, that extending the options for the current customisable toolbar could cause performance or stability issues? Or are you just trying to argue for the sake of arguing? As that's how it appears to me by now. If former applies, I highly recommend that you keep your current stable versions of the apps and ignore all future upgrades. As the devs might have added more bloatware and tons of exploitable new features to them!
On a more serious note - your argumentation is right, if this would be a completely new feature request. And I agree with most of what you said for such. But neither of your arguments is valid in this thread's discussion.
-
Just now, R C-R said:
After all, if they add an icon to open the print dialog window because some users would like that, then how could they justify not doing the same for any of dozens of other items some users might also want to add to it?
Exactly my point! Most, if not all, functions which can have a keyboard shortcut assigned to it, should have an icon which could get added to the toolbar. The basic program routines for that already exist. The whole "print" issue is just an example.
3 minutes ago, R C-R said:If they did that then I think a lot of users would start complaining that it was too difficult to scroll through all of them to find the ones they wanted & start requesting enhancements like a search field or even a completely different UI. They also would need to design all the new icons (which at least for the Mac versions could be as many as 4 or more for each of them, two each for the light & dark UI, 1x & 2x sizes for retina & non-retina Macs, & maybe some monochrome ones as well).
So it is not as if this would be a trivial task, nor precisely because people are different would any of these things make everybody happy. It is just the nature of the beast.
That's what's part of developing a good software, you know? Not just adding new fancy stuff which looks good for showcasing in ads, but also improving existing functions. Customisable toolbars are standard in quite a lot of programs for a reason.
I don't know how much effort Affinity puts into research and QA. But one of my clients was developing software. I witnessed a plethora of independent tests in the sector which showed that a (fully) customisable toolbar is something users want rather than a ready-made one, limited by the developers decision for what they deem as important for a user's workflow. Hence, apps with toolbars usually allow the user to decide.
-
1 minute ago, GarryP said:
and it’s also movable if you uncheck Lock Children.
Initially, I thought about a similar idea as you. But that was something I missed for full functionality. Slowly digging deeper in some functions and options as I started using Affinity just recently. Thanks!
-
You could just clip it into a rectangle. Dave Vector posted a very good guide in these fora for this:
-
51 minutes ago, R C-R said:
No, all I am saying is opening the print dialog window to print a document is not something routinely done anywhere near as often as accessing the other items available on the toolbar. So that one extra click or tap is not going to add up to a significant amount of lost time over the course of a workday.
Seriously? Your argumentation is getting more and more ridiculous now. How often - honestly - are you fiddling with the Assistant Manager in your daily workflow? In case you didn't know (as one usually use that one once in a blue moon, more likely even only once after installing the app): the Assistant Manager has its place in the toolbar - per standard! How often are you using the liquify persona in your daily workflow? Or Auto Levels etc.? Following your argumentation, one has to deem that one more important and more often to be used than printing something. I don't think so.
It's not about the couple of seconds I might save. Because, again, you wouldn't need ANY toolbar when following that route. Keyboard shortcuts and menu items would just serve the same purpose. What's the current toolbar good for, if it's not for saving a couple of extra clicks or taps per day?52 minutes ago, R C-R said:Consider also that the toolbar can display only a limited number of items before it is not wide enough to display the ones on the right without clicking/tapping on the ⨠ icon to display a list of the remaining ones. So even if the available screen width to display the toolbar is extremely large, which for many users it never will be, some of its items will always require an extra click/tap to access them, particularly if the option to display both names & icons is in use.
No-one requested for having all options available simultanously as clickable icons in a toolbar. I for one removed some of the standard icons as I don't need them. Hence I think it's probably a good idea letting the user decide, which icons he wants (or needs) and which he doesn't. Wait! What? That function already exist? Exactly! It DOES exist already. So, why not adding the option for other useful things, too? Like, let's say, "print"?
56 minutes ago, R C-R said:I think this is why the developers decided to limit the number of items that can be added to the toolbar, excluding among others an item to open the print dialog window, which itself uses a lot of screen space.
The Assistant manager opens a pop-up window, the mask icon, the alignment icon and the snapping icon open drop down fields - latter covering quite some space to. What was your argument again?
Again, I'm fine with that the developers decided to limit the amount of icons in a toolbar. But why are they restricting the customisation of it to anyone's liking beyond the initially available icons? I'm repeating myself here as well, but there's an option to assign keyboard shortcuts and the toolbar already is customisable to some degree. So it doesn't require new programming routines to implement more icons/functions for a better customisable toolbar.
Point is, people are different. So are their workflows. I, for once, never use Auto Levels/Contract etc. But I switch the grids on/off pretty often. An icon for that would be more useful for me. For others it's printing... The developers might have a different workflow in mind. I. e. they might not have to print out proofs/concepts every so often, so that could be one reason for why they don't add "print" as direct access from the toolbar - because they simply rarely print something. That doesn't make such option obsolete, does it?
-
If you don't want to break down the "a" to curves and create two halves out of them, I'd go the "easy" (lazy) way:
Use two "a"s. One in black and one in the brownish colour. Then mask the black one so you get its left half only. Place that curve on top of the brown "a"'s layer.
-
6 hours ago, R C-R said:
If you just mean a toolbar icon that opens the print dialog window, can't you use the pen & tablet to access that from the menu? It is only one extra tap, right?
... as it would be for using alligments, snapping on/off, etc. etc.
Yes, it's just one click. As it is for other functions which are currently available on the toolbar. Your argument against a print icon as "it's just one tap" is basically an argument against almost all of the icons in the toolbar - all of them are just one tap away in some menus. So, basically - why having a toolbar at all?
And I was not talking about an "instant 2 print" option. Though, this might be useful for most basic users as well, as the vast majority of print outs is using the same settings - at least in the non professional environment. -
Actually, putting away the tablet from my lap, then taking my keyboard from the desk for pressing some shortcuts (and still having to deal with the print dialog from the menu) takes multiple longer than clicking on "OK" in the print dialog with the pen. The print dialog would open either way. It's two "taps"/click/key press regardless whether you open it by icon/pen, mouse or keyboard.
But then again, why did Affinity implement ANY keyboard shortcut for the printing dialog AT ALL? Why are there icons for "Auto adjust", "liquify persona" in AP? They could also just be an item in the main menu, couldn't they? I mean, c'mon, how many seconds do you save by using those instead of using a menu over a workday?
An icon for printing being just one example. Others might want other icons in the toolbar, because they need it quite often. It's not like the program isn't usable without a more customisable toolbar. But if it'd be more convenient, why not?
There's a function to edit/assign shortcuts to the menu items already. There's a function to customise the toolbar to a degree already. It's not like some dramatic coding would be required for combining existing functions in order to have a more customisable toolbar.
-
On 5/4/2020 at 10:38 AM, Joachim_L said:
[...] Is there a specific reason that you don't like Ctrl+P? You can re-map the shortcut perhaps to F12. A bit faster than Ctrl+P.
Yes, CTRL+P or even F12 isn't as convenient as clicking on an icon, i. e. when working with a graphic tablet and a pen.
-
Do you have any Affinity app running (maximized) when you plug in your monitor?
On my system (Win10), the affinity apps seem to freeze, if they are running in full screen when adding another monitor. Also, if you drag them maximized from one Monitor onto another (Moving the app in windowed mode, works fine, tho).
-
No, multiple layers have nothing to to with multichannel files. More importantly, layers are not even supported in multichannel mode IIRC.
Multichannel images have 256 levels of grey per channel and are used for special print jobs (or, in this case to simulate the colour separation for printing).
That said, unfortunately I cannot answer the OP's question regarding importing/exporting multichannel files between Adobe and Affinity Apps either. -
There are (paid and free) online services, which - depending on the source - can do a fairly well job with colourising b/w images. Make a b/w conversion of the image (also: adjust the reds for this) and upload it.
Quick'n'dirty example, made by https://colourise.sg/ -
😄 Which is what I suggested to do in my first post already...
1 hour ago, Andy05 said:In your case, I guess the inner cover pages are blank? So, you'd have to add them (insert one page after the first page and another before the last page of your document - leave them empty).
-
Maybe MS publisher adds blank pages to the cover's back automatically when printing. I don't never worked with that program, so that's just a guess.
But as I stated above, it's not possible to print a booklet with 6 pages. The page count has to be a multiple of 4.There are plenty of information about booklets, reader spreads, printer spreads and imposition in the web, i. e. here:
https://www.formaxprinting.com/blog/2016/11/booklet-layout-how-to-arrange-the-pages-of-a-saddle-stitched-booklet/
-
12 hours ago, Rick Haberman said:
Publisher wants to print the front and back covers on two separate pages.
Are you sure about that? As that's not common (and doesn't make much sense either) unless there are some extremely special tasks required (i. e. special coatings). But even then, printing services usually need both pages (first and last) being lay out as one sheet.
A standard booklet can't have 6 pages. It's always a multiple of 4. In your case, I guess the inner cover pages are blank? So, you'd have to add them (insert one page after the first page and another before the last page of your document - leave them empty).In most cases it's better to send a PDF (with the correct amount of pages) and let the printing service deal with arranging the imposition.
Feature Request - Mode to preserve original objects after boolean operation
in Feedback for Affinity Designer V1 on Desktop
Posted · Edited by Andy05
edited wrong wording
I second the OP's suggestion. It's not that rare that you want to use an object for more than just a single boolean operation. Yes, you can do a workaround by duplicating it. But it kinda scares me that this forums seems to turn into some kind of "I have a workaround for that"-forum. Isn't an application meant to support your workflow without using tons of workarounds?