i want i chat AV 3 to have webcore rendered chat windows(adium), file sharing(setting a directory that is always shared), voice chat with windows AIM 5.5, VoIP built in (you need a .mac account for this feature), ability to broadcast what your iSight is seeing through your Avatar, much more customizable buddy list ala Adium, different themes that go along with the new OS themes, and support for more than 2 way videoconferencing. At least 3 way would be really cool, but i'm hoping its scalable up to like 5, depending on the power of the machines and the bandwidth.
This would end the IM battle on all platforms. All would bow to ichat.
I want the Put Away command to come back. I recently worked on a project in Mac OS 9 and all the old habits came right back to me. I took all the files that I needed put them on the desktop so they would be at the root level of Open/Save dialogue boxes. When I finished the project, I simply hit command y and all the files went right back to where they were. This was a great feature and I can only assume that it's demise was due to the poor metadata implementation in the Finder.
Actually, I used to want this back too, until I realized that there was a reason I did exactly what you did - I wanted fast, easy, temporary access to a certain set of files, and I wanted to be able to *not* change their actual position on the disk.
There are at least two mechanisms for that staring you in the face: Dock, and Finder Sidebar.
Also, you can Cmd-opt drag those files to the Desktop, and get aliases which can be trashed at a whim. Or you can put them in the Finder toolbar.
Now, the one place I *do* miss Put Away is when I've trashed something and later want to undo it.
And no, it hasn't anything to do with poor metadata in the Finder, it's just not implemented is all. It's got squat all to do with metadata.
yeah I can see that it could be used as a serious tool, and that's why it should be improved, but not by making it make noises, remove the transitions and make it less tacky!
Expose NEEDS the animation, here is what it would be without:
* Much better intergration between iCal, Mail and my documents in the Finder
Quote:
Originally posted by Kickaha
How? This keeps coming up, but no one seems to be able to give an example of what they mean.
Check the Office 2004 demo at http://www.microsoft.com/mac/default...office2004demo. That's one attempt at addressing the shortcoming of the unorganised approach that current apps have in dealing with multiple projects. Though I'm sure Apple could pull this off in a better way.
* Speed. I use a late 20th century PC-laptop running XP. And sure enough, it is faster in many things compared to my brand new Powerbook.
* Loads of new slick animations - to turn the head of at least some PC users.
Quote:
Originally posted by Kickaha
Ummm... you want more eye candy, but complain that XP is faster? Which do you really want? Pick one.
Even if OS X was stipped clean of all its GUI effects - it would still be slower than XP. Although you have half a point, clearly the animations and so forth can not be blamed for this. Rather it's the kernel in XP handling graphics directly and other arcitectural differences (I lack the knowledge even to begin explaining this!) that one should blame.
sometimes i think i'd like apple to just let an OS settle into developer circles for a while. i mean, panther's rock solid... until you start installing other companies' stuff into it. is it possible for an OS to update TOO frequently? couldn't small developers who don't have the people-power to keep up with the changes, especially if they are significant, kinda whither away?
then again, i'm not a developer, so maybe this is what they want/like.
In theory at least, developers's projects should be able to either just inherit the changes made in these OS updates automatically in their code, or be able to update their apps with a trivial amount of work, and the system changes shouldn't affect the apps' stability and such. It probalby depends on what the project API is (namely Cocoa for the former scenario AFAIK) and how well the devloper structures their application. Adobe and other big developers seem to struggle the most with this because of both the sheer amount of code they deal with and probably just because of long-term wear and tear on the code base: so-called legacy code. On the other hand, apps like Create and OmniGraffle move up the OS ladder with very little fret. When you get one of these major OS updates, it's like getting a fairly major update for all your Cocoa apps as well. It's probably possible with Carbon too if done right, or else the idea is to get Carbon there eventually so CoreFoundation can act as the singular API rahter than dealing with this whole Carbon/Cocoa issue.
Check the Office 2004 demo at http://www.microsoft.com/mac/default...office2004demo. That's one attempt at addressing the shortcoming of the unorganised approach that current apps have in dealing with multiple projects. Though I'm sure Apple could pull this off in a better way.
Much, much, MUCH better...
The Office 2004 projects does exactly one thing extremely well... lock you even *further* into MS products.
All that's needed for a project bundler is to have (wait for it...) metadata. Just a touch. A widdle tiny teensy bit. Just one field really... "Projects that I'm involved in" Then a 'project app' just becomes a way of managing that tag, and making sure that the appropriate application (what*EVER* that application that the *user* chose is) gets the appropriate document and is brought forward on command. That's all that much-ballyhooed project manager is, really. It's not that big a deal.
FWIW, I do something similar with folders for projects now, with aliases. I have my dissertation that's literally several thousand files, only a handful of which I'm working on at any given moment, so I have folders on a per-*task* basis, with aliases to the necessary files inside. Want to work on task Foo? Open folder Foo, Cmd-A, Cmd-O, done. It's a trivial tying, to be sure, but it provides much the same basic thing.
Even if OS X was stipped clean of all its GUI effects - it would still be slower than XP. Although you have half a point, clearly the animations and so forth can not be blamed for this. Rather it's the kernel in XP handling graphics directly and other arcitectural differences (I lack the knowledge even to begin explaining this!) that one should blame.
You're right... you should blame XP having graphics in the kernel for Blue Screens of Death. :P
MacOS X is simply *doing more*, and doing it *all the time*. When Longhorn ships (*snort*), with Avalon, the Quartz Extreme clone, *then* we'll see if there's anything to be said about relative performance. Right now, comparing the graphics architectures is like comparing the bookkeeper for a small mom and pop operation (XP) to an accountant for a large corporation (MacOS X). One is simply doing more.
And you missed my point, actually... it was that you were asking for more eye candy, *and* more speed. You can never have both, no matter how efficient the graphics architecture is... more work is simply more work.
In theory at least, developers's projects should be able to either just inherit the changes made in these OS updates automatically in their code, or be able to update their apps with a trivial amount of work, and the system changes shouldn't affect the apps' stability and such. It probalby depends on what the project API is (namely Cocoa for the former scenario AFAIK) and how well the devloper structures their application. Adobe and other big developers seem to struggle the most with this because of both the sheer amount of code they deal with and probably just because of long-term wear and tear on the code base: so-called legacy code. On the other hand, apps like Create and OmniGraffle move up the OS ladder with very little fret. When you get one of these major OS updates, it's like getting a fairly major update for all your Cocoa apps as well. It's probably possible with Carbon too if done right, or else the idea is to get Carbon there eventually so CoreFoundation can act as the singular API rahter than dealing with this whole Carbon/Cocoa issue.
Bingo.
Anyone notice their Cocoa applications all getting a nice boost in the text field arena with 10.3? New features and such? Without downloading a new version? That's the way it's supposed to work. Carbon *can* be programmed to do this, but it's a bit more of a pain, so many developers don't, the silly gits.
Cocoa and Carbon will eventually be merged under the covers, but until then we'll continue to see this sort of game of 'what API was used for this app'?
FWIW, I do something similar with folders for projects now, with aliases. I have my dissertation that's literally several thousand files, only a handful of which I'm working on at any given moment, so I have folders on a per-*task* basis, with aliases to the necessary files inside. Want to work on task Foo? Open folder Foo, Cmd-A, Cmd-O, done. It's a trivial tying, to be sure, but it provides much the same basic thing.
Although this method is great for files it does nothing to integrate emails, contacts, or calendar events into the process. Being able to open Project.app and not only have all the files associated, but emails, people involved in the project, and meetings you've held (tied back into notes and audio recordings) and are going to hold all within a simple interface.
It doesn't make much sense when it's only a person or two on a project, but I would love this sort of Project.app when I work on large undertakings.
Build X11 in to the Finder better, like Classic. Make X11 application launch from the Finder. Make X11 applications Aqua-fied.
Edit: Better yet. A Linux compatibility layer.
Er... it does all of that now, re: X11, except for Aquafication, and given the crappy nature of X11 GUI elements in general, I doubt it'll ever happen.
The Linux compatibility is already 90% there... what do you see as 'missing'?
Although this method is great for files it does nothing to integrate emails, contacts, or calendar events into the process. Being able to open Project.app and not only have all the files associated, but emails, people involved in the project, and meetings you've held (tied back into notes and audio recordings) and are going to hold all within a simple interface.
It doesn't make much sense when it's only a person or two on a project, but I would love this sort of Project.app when I work on large undertakings.
I agree, but it's not that hard to have a project app tell Mail 'open this folder for project X that I have active at the moment', or iCal 'select this calendar and hide all others for project X that I have active at the moment', ditto for AddressBook.
Heck, if you wanted to get all funky with it, it'd be trivial to have the iCal and AB info pop up in one unified UI, the APIs are there already... Mail is getting there, and if it were an entire (set of) folder(s) that were associated, that'd be pretty easy to pull into one UI as well.
Apple's been putting this sort of infrastructure in place for their own data, and increasingly making it obvious that they want to do so for *all* datatypes at the file level via metadata.
I agree, but it's not that hard to have a project app tell Mail 'open this folder for project X that I have active at the moment', or iCal 'select this calendar and hide all others for project X that I have active at the moment', ditto for AddressBook.
Heck, if you wanted to get all funky with it, it'd be trivial to have the iCal and AB info pop up in one unified UI, the APIs are there already... Mail is getting there, and if it were an entire (set of) folder(s) that were associated, that'd be pretty easy to pull into one UI as well.
Apple's been putting this sort of infrastructure in place for their own data, and increasingly making it obvious that they want to do so for *all* datatypes at the file level via metadata.
Regarding Exposé, I think some people (like me) will never use/like it. My right hand never leaves the mouse except for typing, the left hand has the thumb sitting constantly near the space bar and the cmd key, and it's perfect for me to leave the thumb there and use my middle finger to move quickly from Tab to H or vice versa. I constantly hide and switch between apps, basically moving just one finger, and I'm happy this way. I don't use it, but it doesn't get in my way either; fine for me!
Serious stuff: the Finder and everything else that's already been said about metadata. And FTP too!
GUI consistency, please, I beg you Steve, one GUI to bind them all...
OS X still has huge stability issues, Carbon apps are still able to lock everything up, but worse than this is the mess that surely lies with kernel/usb drivers. I have an iBook G4 and I carry it around all the time, plugging and unplugging loads of USB devices in different places and configurations. Well, after a while things can start to get ugly, leading to Kernel panics. I can reproduce this behavior whenever I want (not that I want it often, to be honest ), and using just kbd, mouse and harman/kardon sound sticks. This bug is here since 10.1, albeit over time it became less evident. But still, that's how I discovered the new panic in panther! Maybe these drivers that load and unload themselves don't clean up memory very well?
Strictly related to stability issues, I'd like a key combination to either kill every GUI process (rude) and revert back to a text only login console, or simply switch to one leaving the rest intact like on linux: most of the time (excluding the panics) it's just the GUI that's locked, probably only in the frontmost app. It'd be nice to be able to kill it without bringing down other apps in the background or risking damaging your drive's contents!
And for chrissake, I'd love to be able to have real smart playlists in iTunes, like say, this artist OR that other AND both 4 stars or better. Is it that difficult?
These are the things that really bug me, and the last two don't seem too difficult to implement...
Comments
This would end the IM battle on all platforms. All would bow to ichat.
Too bad its not going to happen
Originally posted by HOM
I want the Put Away command to come back. I recently worked on a project in Mac OS 9 and all the old habits came right back to me. I took all the files that I needed put them on the desktop so they would be at the root level of Open/Save dialogue boxes. When I finished the project, I simply hit command y and all the files went right back to where they were. This was a great feature and I can only assume that it's demise was due to the poor metadata implementation in the Finder.
Actually, I used to want this back too, until I realized that there was a reason I did exactly what you did - I wanted fast, easy, temporary access to a certain set of files, and I wanted to be able to *not* change their actual position on the disk.
There are at least two mechanisms for that staring you in the face: Dock, and Finder Sidebar.
Also, you can Cmd-opt drag those files to the Desktop, and get aliases which can be trashed at a whim. Or you can put them in the Finder toolbar.
Now, the one place I *do* miss Put Away is when I've trashed something and later want to undo it.
And no, it hasn't anything to do with poor metadata in the Finder, it's just not implemented is all. It's got squat all to do with metadata.
Originally posted by MacCrazy
yeah I can see that it could be used as a serious tool, and that's why it should be improved, but not by making it make noises, remove the transitions and make it less tacky!
Expose NEEDS the animation, here is what it would be without:
http://www.onlinetoolsteam.com/Windo...r/MoreInfo.asp
winexpose is a little app that tries and fails to emulate this element of the mac expereiance
Originally posted by richardb
* Much better intergration between iCal, Mail and my documents in the Finder
Originally posted by Kickaha
How? This keeps coming up, but no one seems to be able to give an example of what they mean.
Check the Office 2004 demo at http://www.microsoft.com/mac/default...office2004demo. That's one attempt at addressing the shortcoming of the unorganised approach that current apps have in dealing with multiple projects. Though I'm sure Apple could pull this off in a better way.
* Speed. I use a late 20th century PC-laptop running XP. And sure enough, it is faster in many things compared to my brand new Powerbook.
* Loads of new slick animations - to turn the head of at least some PC users.
Originally posted by Kickaha
Ummm... you want more eye candy, but complain that XP is faster? Which do you really want? Pick one.
Even if OS X was stipped clean of all its GUI effects - it would still be slower than XP. Although you have half a point, clearly the animations and so forth can not be blamed for this. Rather it's the kernel in XP handling graphics directly and other arcitectural differences (I lack the knowledge even to begin explaining this!) that one should blame.
Originally posted by richardb
* Speed. I use a late 20th century PC-laptop running XP. And sure enough, it is faster in many things compared to my brand new Powerbook.
Originally posted by a_greer
if you have a new aluminum PB you dont want, I will gladly trade you a 5 year old pc notebook for it
On a second thought - no thanks.
then again, i'm not a developer, so maybe this is what they want/like.
Originally posted by richardb
Check the Office 2004 demo at http://www.microsoft.com/mac/default...office2004demo. That's one attempt at addressing the shortcoming of the unorganised approach that current apps have in dealing with multiple projects. Though I'm sure Apple could pull this off in a better way.
Much, much, MUCH better...
The Office 2004 projects does exactly one thing extremely well... lock you even *further* into MS products.
All that's needed for a project bundler is to have (wait for it...) metadata. Just a touch. A widdle tiny teensy bit. Just one field really... "Projects that I'm involved in" Then a 'project app' just becomes a way of managing that tag, and making sure that the appropriate application (what*EVER* that application that the *user* chose is) gets the appropriate document and is brought forward on command. That's all that much-ballyhooed project manager is, really. It's not that big a deal.
FWIW, I do something similar with folders for projects now, with aliases. I have my dissertation that's literally several thousand files, only a handful of which I'm working on at any given moment, so I have folders on a per-*task* basis, with aliases to the necessary files inside. Want to work on task Foo? Open folder Foo, Cmd-A, Cmd-O, done. It's a trivial tying, to be sure, but it provides much the same basic thing.
Originally posted by richardb
Even if OS X was stipped clean of all its GUI effects - it would still be slower than XP. Although you have half a point, clearly the animations and so forth can not be blamed for this. Rather it's the kernel in XP handling graphics directly and other arcitectural differences (I lack the knowledge even to begin explaining this!) that one should blame.
You're right... you should blame XP having graphics in the kernel for Blue Screens of Death. :P
MacOS X is simply *doing more*, and doing it *all the time*. When Longhorn ships (*snort*), with Avalon, the Quartz Extreme clone, *then* we'll see if there's anything to be said about relative performance. Right now, comparing the graphics architectures is like comparing the bookkeeper for a small mom and pop operation (XP) to an accountant for a large corporation (MacOS X). One is simply doing more.
And you missed my point, actually... it was that you were asking for more eye candy, *and* more speed. You can never have both, no matter how efficient the graphics architecture is... more work is simply more work.
Originally posted by BuonRotto
In theory at least, developers's projects should be able to either just inherit the changes made in these OS updates automatically in their code, or be able to update their apps with a trivial amount of work, and the system changes shouldn't affect the apps' stability and such. It probalby depends on what the project API is (namely Cocoa for the former scenario AFAIK) and how well the devloper structures their application. Adobe and other big developers seem to struggle the most with this because of both the sheer amount of code they deal with and probably just because of long-term wear and tear on the code base: so-called legacy code. On the other hand, apps like Create and OmniGraffle move up the OS ladder with very little fret. When you get one of these major OS updates, it's like getting a fairly major update for all your Cocoa apps as well. It's probably possible with Carbon too if done right, or else the idea is to get Carbon there eventually so CoreFoundation can act as the singular API rahter than dealing with this whole Carbon/Cocoa issue.
Bingo.
Anyone notice their Cocoa applications all getting a nice boost in the text field arena with 10.3? New features and such? Without downloading a new version? That's the way it's supposed to work. Carbon *can* be programmed to do this, but it's a bit more of a pain, so many developers don't, the silly gits.
Cocoa and Carbon will eventually be merged under the covers, but until then we'll continue to see this sort of game of 'what API was used for this app'?
Originally posted by Kickaha
FWIW, I do something similar with folders for projects now, with aliases. I have my dissertation that's literally several thousand files, only a handful of which I'm working on at any given moment, so I have folders on a per-*task* basis, with aliases to the necessary files inside. Want to work on task Foo? Open folder Foo, Cmd-A, Cmd-O, done. It's a trivial tying, to be sure, but it provides much the same basic thing.
Although this method is great for files it does nothing to integrate emails, contacts, or calendar events into the process. Being able to open Project.app and not only have all the files associated, but emails, people involved in the project, and meetings you've held (tied back into notes and audio recordings) and are going to hold all within a simple interface.
It doesn't make much sense when it's only a person or two on a project, but I would love this sort of Project.app when I work on large undertakings.
Edit: Better yet. A Linux compatibility layer.
Originally posted by fahlman
Build X11 in to the Finder better, like Classic. Make X11 application launch from the Finder. Make X11 applications Aqua-fied.
Edit: Better yet. A Linux compatibility layer.
Er... it does all of that now, re: X11, except for Aquafication, and given the crappy nature of X11 GUI elements in general, I doubt it'll ever happen.
The Linux compatibility is already 90% there... what do you see as 'missing'?
Originally posted by HOM
Although this method is great for files it does nothing to integrate emails, contacts, or calendar events into the process. Being able to open Project.app and not only have all the files associated, but emails, people involved in the project, and meetings you've held (tied back into notes and audio recordings) and are going to hold all within a simple interface.
It doesn't make much sense when it's only a person or two on a project, but I would love this sort of Project.app when I work on large undertakings.
I agree, but it's not that hard to have a project app tell Mail 'open this folder for project X that I have active at the moment', or iCal 'select this calendar and hide all others for project X that I have active at the moment', ditto for AddressBook.
Heck, if you wanted to get all funky with it, it'd be trivial to have the iCal and AB info pop up in one unified UI, the APIs are there already... Mail is getting there, and if it were an entire (set of) folder(s) that were associated, that'd be pretty easy to pull into one UI as well.
Apple's been putting this sort of infrastructure in place for their own data, and increasingly making it obvious that they want to do so for *all* datatypes at the file level via metadata.
Originally posted by Kickaha
I agree, but it's not that hard to have a project app tell Mail 'open this folder for project X that I have active at the moment', or iCal 'select this calendar and hide all others for project X that I have active at the moment', ditto for AddressBook.
Heck, if you wanted to get all funky with it, it'd be trivial to have the iCal and AB info pop up in one unified UI, the APIs are there already... Mail is getting there, and if it were an entire (set of) folder(s) that were associated, that'd be pretty easy to pull into one UI as well.
Apple's been putting this sort of infrastructure in place for their own data, and increasingly making it obvious that they want to do so for *all* datatypes at the file level via metadata.
I'll give you $20 if you make this happen.
I'll give you $20 if you make this happen.
http://www.crm4mac.com/index.html
View the movies to grok the .app
Originally posted by cowerd
http://www.crm4mac.com/index.html
View the movies to grok the .app
Now where's my $20?
Serious stuff: the Finder and everything else that's already been said about metadata. And FTP too!
GUI consistency, please, I beg you Steve, one GUI to bind them all...
OS X still has huge stability issues, Carbon apps are still able to lock everything up, but worse than this is the mess that surely lies with kernel/usb drivers. I have an iBook G4 and I carry it around all the time, plugging and unplugging loads of USB devices in different places and configurations. Well, after a while things can start to get ugly, leading to Kernel panics. I can reproduce this behavior whenever I want (not that I want it often, to be honest
Strictly related to stability issues, I'd like a key combination to either kill every GUI process (rude) and revert back to a text only login console, or simply switch to one leaving the rest intact like on linux: most of the time (excluding the panics) it's just the GUI that's locked, probably only in the frontmost app. It'd be nice to be able to kill it without bringing down other apps in the background or risking damaging your drive's contents!
And for chrissake, I'd love to be able to have real smart playlists in iTunes, like say, this artist OR that other AND both 4 stars or better. Is it that difficult?
These are the things that really bug me, and the last two don't seem too difficult to implement...
ZoSo
[EDIT: tried to clarify some thoughts]