Good thing no one said ANYTHING about vertical surfaces.
So you think that macs are effectively going away. Because a flat Mac with a non vertical screen and no mouse input is a tablet.
Except Dell and HP, and we know how well they worked out. :p
100% I expect to see physical keyboards around for nearly forever, but I don’t figure OS XI will have mouse/cursor support. Maybe.
The mouse/Pointer is vastly more productive for text based operations than a finger. It's going nowhere. I would bet the next iPhone would be more likely named the iPhone 9 than that happening.
I remember that just after Steve came back, he had a press conference. He was asked how Apple would get large business back. His reply:
"The enterprise isn't our customer."
That was it. End of story.
But years later, with the iPhone, things changed. Business and government are standardizing on iOS, particularly iPhones. iPads have the large majority in business and government too, but recently, Android and Microsoft have been making some inroads, thus the deal with IBM. And likely, the Pro.
Yep!
WOT: In any of your woodworking, have you done anything with weathered wood? We just replaced our redwood fence and I kept all the non-pressure-treated boards. Most have weathered to a beautiful silvery-gray with high-low exposed grain, some knots.
I have tried resawing some, but can't seem to match the weathered patina with steel-wool vinegar, other home formulas, etc. I'm considering wiping on/off thinned latex paint ...
My daughter wants an out door potting bench, new kitchen table, storage crates, etc.
Any ideas on projects or techniques would be greatly appreciated.
I cannot make a determination on that because I know almost nothing about Adobe's programing. Who knows if they haven't already rewritten the apps recently? We are on the outside looking in. One thing I do know is that they don't use Xcode exclusively. They write most modules and functions directly in C++ and then import them because they want to retain as much cross platform compatibility as possible. People saying it is trivial to compile an app with a new target architecture is as easy as selecting it in Xcode, do not understand the extreme complexity of Adobe apps.
I'm certainly not trying to downplay the complexity of developing any software.
But how much is that complexity due to legacy code, cross-compatibility cruft, and pushing unnecessary, unneeded and unwanted features into (for example) PS like video editing?
In my original post I mention 2 developers that have teams that dwarf Adobe's, that have been able to write some amazing software in a short amount of time. All I'm asking is here is what exactly Adobe is doing with 13,500 employees to the benefit of it's users... now subscribers.
I occasionally send them bug reports and feedback and they always respond quickly asking for additional details. Recent example: I discovered that if you leave inDesign open for many days it will eventually cause the cursor to behave strangely like flickering or showing the wrong cursor. After I reported it, two different engineers contacted me for more details. Another issue again related to leaving inDesign open for many days, the eyedropper sample tool eventually stops sampling styles and only samples color. Both issues still exist, even in the latest version, but I'm hopeful they will be corrected in the next version which could drop at any time as they are constantly updating all their apps.
I'm rather surprised that you're noticing that these days... because I've recommended closing ID and documents when not in use, since CS3... for the same reasons that you're experiencing plus some. ID has always hung on to RAM and virtual drive space like a dog with his last bone. Note: even to this day it is wise to save often, and close out once in awhile per day. Also the *dirty-fast clipboard purge* is recommended when copying large documents and especially pictures in ID, IL or PS.
** After paste, copy something small and/or not pixel-based if possible like text.
Since they switched to CC I find they are far more effective in making updates and improvements.
I disagree for the main reason that it goes against what Adobe was saying is the main benefit of CC subs: continuous update for features and functions. When in reality they're still doing "point" updates like they used to do and just by another name. Also, now instead of CC7 or 8... we get CC2014 and CC2015 with point updates in between. Technically, I really did think as many did, that Adobe had managed to separate the functions from the core, so that adding functions and features wouldn't break it. This I see was (is?) literally speaking, a pipe dream.
The one thing that I believe is going to happen (is happening), is that iOS versions of Adobe's software are going to receive the most attention, and at sometime in the very near future will take care of 90% of small team's and individuals creative tasks... better, easier and more efficiently than CC on the desktop. CC desktop will be there for big teams to pull in and piece together workflows and industry-specific processes such as: asset collation/archiving, digital-print workflows, CMYK conversion for traditional press, etc. Naturally with specific pipeline workflows for film production and web publishing doing the same.
The days of everyone collaborating in a team surrounded be monster Macs... or even docked MBP/MBA's is coming to an end quite similar to the old-style publishing workflows that we replaced 30 years ago. IMHO....:smokey:
I'm rather surprised that you're noticing that these days... because I've recommended closing ID and documents when not in use, since CS3... for the same reasons that you're experiencing plus some. ID has always hung on to RAM and virtual drive space like a dog with his last bone. Note: even to this day it is wise to save often, and close out once in awhile per day.
I'm not proactive about managing the system memory or virtual drive space. If something is acting up I'll close it and restart it, but usually I don't have too many problems so I just leave everything open and running. That way when I get in the office, I just pick up where I left off. I'm usually working on ten or more documents in various states of completion during the day. They go out for review and come back with edits constantly. It is inefficient to go find them and reopen them each time. I rarely close inDesign except if I get the cursor issue. I almost never close Ps or Ai. Same with Dw, Safari and Textmate. They are always open 24/7 even when I'm out of the office for months at a time as I access them remotely when necessary.
I'm not proactive about managing the system memory or virtual drive space. If something is acting up I'll close it and restart it, but usually I don't have too many problems so I just leave everything open and running. That way when I get in the office, I just pick up where I left off. I'm usually working on ten or more documents in various states of completion during the day. They go out for review and come back with edits constantly. It is inefficient to go find them and reopen them each time. I rarely close inDesign except if I get the cursor issue.
Tip: desktop aliases to documents and folders are your friend. Also i couldn't live without Default Folder.
Italicized: Wow! You sure we don't know each other? You sound just like a couple of my bigger clients that always have reasons why my above tip(s) don't work. Just sayin'...:p
I almost never close Ps or Ai. Same with Dw, Safari and Textmate. They are always open 24/7 even when I'm out of the office for months at a time as I access them remotely when necessary.
Both PS and AI seem to release memory better... however larger projects (I do packaging when not IT support with "involved" composites in PS and IL) can eat up unnecessary RAM when not being actively used. That dirty clipboard purge trick also does wonders.
Textmate: never a problem, but I prefer Sublime and am starting to warm up to Adobe's new Brackets .
Safari: again no problem, but since you have an Internet connection anyway, I've experienced no problems using history or "open on my Mac" tabs, even when closed.
DW: your shocking me in your "all in Adobe" usage... especially here. We/I killed that cludge many versions ago, never to be uttered in public or downloaded again. So tell me: is it good, better, and why do you use it?
Tip: desktop aliases to documents and folders are your friend. Also i couldn't live without Default Folder.
Italicized: Wow! You sure we don't know each other? You sound just like a couple of my bigger clients that always have reasons why my above tip(s) don't work. Just sayin'...
I do not experience any memory issues, maybe because I have 32GB of RAM.
You have your way of working and I have mine. Last thing I want is a default folder. We have maybe 50K documents and more than 100K assets so they have to be organized in a very methodical way.
Anyway, I don't want a bunch of alias icons on my desktop. I keep my desktop clear most of the time. I have to be very careful when opening files because they have extremely long ISO style names that are very similar with only a small difference in the file name which is almost always truncated in both the list view and the icon view. I don't want to risk accidentally opening a different version of a document from an alias, so once I have it open I leave it open because I know I'm going to be editing it a dozen times in one day. Plus these are often huge 100+ page documents with hundreds of images. They take a while to open, especially from a network drive.
Thanks for the advice but I'm comfortable working as I described.
That is silly; it’s the 10th iPhone, after all. ;)
So you believe the iMac with touch as a primary input is not going to be vertical but still will not be as big as it is now but not a tablet. That's nuts.
DW: your shocking me in your "all in Adobe" usage... especially here. We/I killed that cludge many versions ago, never to be uttered in public or downloaded again. So tell me: is it good, better, and why do you use it?
Dw works fine for me. What are your complaints with it? I have Coda and Transit also and tried them as a test but I manage dozens of websites and they are all saved in Dw sites so unless I want to spend a couple days reconfiguring them in some new app and learn new software, Dw is just easier for me. I guess I'm just used to it. It has really good searching tools and the code indenting and coloring is great. I don't use the design view because all our sites are dynamic php with databases.
But that's been explained more than once in this thread.
No, it hasn't been EXPLAINED even once in this thread. What's happened is that a couple of people just say it can be done without any explainations as to how that would happen. There is just the assumption that developers would do it. I explained why they wouldn't.
WOT: In any of your woodworking, have you done anything with weathered wood? We just replaced our redwood fence and I kept all the non-pressure-treated boards. Most have weathered to a beautiful silvery-gray with high-low exposed grain, some knots.
I have tried resawing some, but can't seem to match the weathered patina with steel-wool vinegar, other home formulas, etc. I'm considering wiping on/off thinned latex paint ...
My daughter wants an out door potting bench, new kitchen table, storage crates, etc.
Any ideas on projects or techniques would be greatly appreciated.
TIA
You can simulate real weathered wood with various treatments. But I've never seen a real match. Real weathered wood isn't a chemical treatment. It's a leaching out of pigment, and an oxidized surface. But the oxidation takes place over time, and can't be duplicated in any short treatment time. Even if you were to get lucky, and make a match, that match wouldn't match under different lighting, and would diverge over time.
Unfortunately, it's an all or nothing kind of thing.
No, it hasn't been EXPLAINED even once in this thread. What's happened is that a couple of people just say it can be done without any explainations as to how that would happen. There is just the assumption that developers would do it. I explained why they wouldn't.
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
so will bitcode allow Apple to "merge" iOS & Mac App stores so that we have Universal Apps across iOS and OSX devices?
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
so will bitcode allow Apple to "merge" iOS & Mac App stores so that we have Universal Apps across iOS and OSX devices?
Likely, BitCode, alone, won't make apps Universal. The UI needs to be tailored to Touch/Press, Mouse KB, Voice, gestures -- depending on the target devices. StoryBoards in Xcode are a beginning -- where multiple UIs can be provided with a single app.
For this thread, a MacBook Air with either an x86 or ARM processor -- the UI would be mouse/kb. Given that, the apps could be universal.
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
Oh please. You know less than you pretend to know. You can recompile a small app, but try that with a complex piece of software, and you have a lot of work before you. The easy thing to say always seems to be that it's an easy compile away. Your "explanation" is junk.
Oh please. You know less than you pretend to know. You can recompile a small app, but try that with a complex piece of software, and you have a lot of work before you. The easy thing to say always seems to be that it's an easy compile away. Your "explanation" is junk.
It doesn't matter how complex the code is if it can be compiled by the compiler to the proper assembly (with or without the intervening bit code) it will work. That applies to properly written apps with two lines of code or 2 billion.
Likely, BitCode, alone, won't make apps Universal. The UI needs to be tailored to Touch/Press, Mouse KB, Voice, gestures -- depending on the target devices. StoryBoards in Xcode are a beginning -- where multiple UIs can be provided with a single app.
For this thread, a MacBook Air with either an x86 or ARM processor -- the UI would be mouse/kb. Given that, the apps could be universal.
Yes. The apps won't be universal in the iOS = OS X because the SDKs are different. If you write an app in Xcode for Mac OS X using the standard SDK then it will work as a Mac app with a recompile if Apple port the SDK to arm. If that didn't work Apples own apps wouldn't work.
It doesn't matter how complex the code is if it can be compiled by the compiler to the proper assembly (with or without the intervening bit code) it will work. That applies to properly written apps with two lines of code or 2 billion.
No, it doesn't. Large apps need work after a recompile. If you'real saying that Xcode is perfect, and that it does absolutely everything for a developer, then you're wrong. Just read the developer forums, and all of the problems they have. Apple themselves say that a developer will need to look their software over and fix a number of problems. They know it can't be done.
Comments
So you think that macs are effectively going away. Because a flat Mac with a non vertical screen and no mouse input is a tablet.
The mouse/Pointer is vastly more productive for text based operations than a finger. It's going nowhere. I would bet the next iPhone would be more likely named the iPhone 9 than that happening.
Yep!
WOT: In any of your woodworking, have you done anything with weathered wood? We just replaced our redwood fence and I kept all the non-pressure-treated boards. Most have weathered to a beautiful silvery-gray with high-low exposed grain, some knots.
I have tried resawing some, but can't seem to match the weathered patina with steel-wool vinegar, other home formulas, etc. I'm considering wiping on/off thinned latex paint ...
My daughter wants an out door potting bench, new kitchen table, storage crates, etc.
Any ideas on projects or techniques would be greatly appreciated.
TIA
But how much is that complexity due to legacy code, cross-compatibility cruft, and pushing unnecessary, unneeded and unwanted features into (for example) PS like video editing?
In my original post I mention 2 developers that have teams that dwarf Adobe's, that have been able to write some amazing software in a short amount of time. All I'm asking is here is what exactly Adobe is doing with 13,500 employees to the benefit of it's users... now subscribers.
I'm rather surprised that you're noticing that these days... because I've recommended closing ID and documents when not in use, since CS3... for the same reasons that you're experiencing plus some. ID has always hung on to RAM and virtual drive space like a dog with his last bone. Note: even to this day it is wise to save often, and close out once in awhile per day. Also the *dirty-fast clipboard purge* is recommended when copying large documents and especially pictures in ID, IL or PS.
** After paste, copy something small and/or not pixel-based if possible like text.
I disagree for the main reason that it goes against what Adobe was saying is the main benefit of CC subs: continuous update for features and functions. When in reality they're still doing "point" updates like they used to do and just by another name. Also, now instead of CC7 or 8... we get CC2014 and CC2015 with point updates in between. Technically, I really did think as many did, that Adobe had managed to separate the functions from the core, so that adding functions and features wouldn't break it. This I see was (is?) literally speaking, a pipe dream.
The one thing that I believe is going to happen (is happening), is that iOS versions of Adobe's software are going to receive the most attention, and at sometime in the very near future will take care of 90% of small team's and individuals creative tasks... better, easier and more efficiently than CC on the desktop. CC desktop will be there for big teams to pull in and piece together workflows and industry-specific processes such as: asset collation/archiving, digital-print workflows, CMYK conversion for traditional press, etc. Naturally with specific pipeline workflows for film production and web publishing doing the same.
The days of everyone collaborating in a team surrounded be monster Macs... or even docked MBP/MBA's is coming to an end quite similar to the old-style publishing workflows that we replaced 30 years ago. IMHO....:smokey:
I'm rather surprised that you're noticing that these days... because I've recommended closing ID and documents when not in use, since CS3... for the same reasons that you're experiencing plus some. ID has always hung on to RAM and virtual drive space like a dog with his last bone. Note: even to this day it is wise to save often, and close out once in awhile per day.
I'm not proactive about managing the system memory or virtual drive space. If something is acting up I'll close it and restart it, but usually I don't have too many problems so I just leave everything open and running. That way when I get in the office, I just pick up where I left off. I'm usually working on ten or more documents in various states of completion during the day. They go out for review and come back with edits constantly. It is inefficient to go find them and reopen them each time. I rarely close inDesign except if I get the cursor issue. I almost never close Ps or Ai. Same with Dw, Safari and Textmate. They are always open 24/7 even when I'm out of the office for months at a time as I access them remotely when necessary.
I feel like Abbot. Or maybe Costello.
Yeah, a range of 27” to 42” “tablets”; sure.
[citation needed]
[citation needed]
That is silly; it’s the 10th iPhone, after all.
Tip: desktop aliases to documents and folders are your friend. Also i couldn't live without Default Folder.
Italicized: Wow! You sure we don't know each other? You sound just like a couple of my bigger clients that always have reasons why my above tip(s) don't work. Just sayin'...:p
Both PS and AI seem to release memory better... however larger projects (I do packaging when not IT support with "involved" composites in PS and IL) can eat up unnecessary RAM when not being actively used. That dirty clipboard purge trick also does wonders.
Textmate: never a problem, but I prefer Sublime and am starting to warm up to Adobe's new Brackets .
Safari: again no problem, but since you have an Internet connection anyway, I've experienced no problems using history or "open on my Mac" tabs, even when closed.
DW: your shocking me in your "all in Adobe" usage... especially here. We/I killed that cludge many versions ago, never to be uttered in public or downloaded again. So tell me: is it good, better, and why do you use it?
Tip: desktop aliases to documents and folders are your friend. Also i couldn't live without Default Folder.
Italicized: Wow! You sure we don't know each other? You sound just like a couple of my bigger clients that always have reasons why my above tip(s) don't work. Just sayin'...
I do not experience any memory issues, maybe because I have 32GB of RAM.
You have your way of working and I have mine. Last thing I want is a default folder. We have maybe 50K documents and more than 100K assets so they have to be organized in a very methodical way.
Anyway, I don't want a bunch of alias icons on my desktop. I keep my desktop clear most of the time. I have to be very careful when opening files because they have extremely long ISO style names that are very similar with only a small difference in the file name which is almost always truncated in both the list view and the icon view. I don't want to risk accidentally opening a different version of a document from an alias, so once I have it open I leave it open because I know I'm going to be editing it a dozen times in one day. Plus these are often huge 100+ page documents with hundreds of images. They take a while to open, especially from a network drive.
Thanks for the advice but I'm comfortable working as I described.
So you believe the iMac with touch as a primary input is not going to be vertical but still will not be as big as it is now but not a tablet. That's nuts.
DW: your shocking me in your "all in Adobe" usage... especially here. We/I killed that cludge many versions ago, never to be uttered in public or downloaded again. So tell me: is it good, better, and why do you use it?
Dw works fine for me. What are your complaints with it? I have Coda and Transit also and tried them as a test but I manage dozens of websites and they are all saved in Dw sites so unless I want to spend a couple days reconfiguring them in some new app and learn new software, Dw is just easier for me. I guess I'm just used to it. It has really good searching tools and the code indenting and coloring is great. I don't use the design view because all our sites are dynamic php with databases.
Yep.
Bigger, really.
Definitionally, yes.
That’s the definition of words.
No, it hasn't been EXPLAINED even once in this thread. What's happened is that a couple of people just say it can be done without any explainations as to how that would happen. There is just the assumption that developers would do it. I explained why they wouldn't.
You can simulate real weathered wood with various treatments. But I've never seen a real match. Real weathered wood isn't a chemical treatment. It's a leaching out of pigment, and an oxidized surface. But the oxidation takes place over time, and can't be duplicated in any short treatment time. Even if you were to get lucky, and make a match, that match wouldn't match under different lighting, and would diverge over time.
Unfortunately, it's an all or nothing kind of thing.
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
It has been explained but you apparently don't have the technical chops to understand the explanation.
What was explained is this.
1) to recompile a swift or objective c app* running now on Intel to work on Arm takes a recompile. That's it. You can also produce fat binaries that work on both.
2) Apple is introducing bit code uploads. These are apps that compile down to an intermediate language that the App Store can then compile to binaries that work on different architectures.
* actually anything that compiles on llvm and runs should work. Did you ever see the simulator work on OS X? That's an Intel compiled binary, a Mac app running code written for the iPhone. To make libraries or frameworks work across both iOS and OSX requires using lipo which can merge different architectures into one binary. But even that simple process will be moot when everything is bit code
so will bitcode allow Apple to "merge" iOS & Mac App stores so that we have Universal Apps across iOS and OSX devices?
Likely, BitCode, alone, won't make apps Universal. The UI needs to be tailored to Touch/Press, Mouse KB, Voice, gestures -- depending on the target devices. StoryBoards in Xcode are a beginning -- where multiple UIs can be provided with a single app.
For this thread, a MacBook Air with either an x86 or ARM processor -- the UI would be mouse/kb. Given that, the apps could be universal.
Oh please. You know less than you pretend to know. You can recompile a small app, but try that with a complex piece of software, and you have a lot of work before you. The easy thing to say always seems to be that it's an easy compile away. Your "explanation" is junk.
It doesn't matter how complex the code is if it can be compiled by the compiler to the proper assembly (with or without the intervening bit code) it will work. That applies to properly written apps with two lines of code or 2 billion.
Yes. The apps won't be universal in the iOS = OS X because the SDKs are different. If you write an app in Xcode for Mac OS X using the standard SDK then it will work as a Mac app with a recompile if Apple port the SDK to arm. If that didn't work Apples own apps wouldn't work.
No, it doesn't. Large apps need work after a recompile. If you'real saying that Xcode is perfect, and that it does absolutely everything for a developer, then you're wrong. Just read the developer forums, and all of the problems they have. Apple themselves say that a developer will need to look their software over and fix a number of problems. They know it can't be done.