« Clever Thing Of The Day | Main | Help test 1.4 rc2 candidates »
June 11, 2003
Firemonkey anyone?
The head of a monkey, the body of a monkey, and fire coming out of the nether regions of said body...
Or take seamonkey's established navigator UI and port it to the new toolkitthingy. With all the cool prefs the big boys like to play. And toolbar customization, which people seem to care about. And the modern theme, so we can act as if we care about backwards compatability.
Posted by doron at June 11, 2003 10:05 PM
Comments
Hope!
At least, I assume this is not only look, but also feel? Not only UI but also behaviour? (aka, will it also undo all the stupid decisions with regards to ctrl-enter behaviour in the location bar and whatnot? Have an integrated google search in the location bar?)
*blaaghs 'n gloats* or something... yeah...
Posted by: Sander at June 12, 2003 11:27 AM
The hope would be seamonkey UI on firebird, with the firebird toolkit changes. behaviour will probably be similar to seamonkey. Just need to get time to work on it and help :)
Posted by: Doron at June 12, 2003 1:48 PM
Yes. Yes. Yes. Grey Modern, "Preferences" on the "Edit" menu, and groupmarks that aren't stupid folders. Yes indeed, that'd be just fine.
What kind of help do you need? Not that I know much about the internal workings of the thing.
Would the firebird extensions need to be written specifically for Firemonkey?
The artwork could be interesting as well.
Posted by: bobo at June 12, 2003 6:03 PM
Yes, yes, yes.
Just as I was managing to convert a decent number of non-techie users to Mozilla, mozilla.org decides seamonkey is dead and firebird is the way to go.
So all those users have to learn a new UI. "Why are you changing my browser when I was finally getting used to Mozilla?" "This is mozilla!" "But it looks and works all different!"
Go firemonkey, go...
Posted by: Lor at June 25, 2003 2:07 AM
Other examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.
Posted by: Dionisius at January 25, 2004 12:09 AM
You Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.
Posted by: Randolph at January 25, 2004 12:09 AM
Other examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.
Posted by: Nathaniel at January 25, 2004 12:10 AM
Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.
Posted by: James at January 25, 2004 12:10 AM
Help! Did you include help tags in your applications? (I'd be lost without them.) Also, be sure to take extra time to develop your other help files. The Apple Help Viewer supports HTML, QuickTime, and also AppleScript. Take advantage of it! There isn't anything I hate more than going to the Help menu and finding there isn't any help.
Posted by: Anchor at January 25, 2004 12:10 AM
Drawers. Similar to Sheets, this is a "child" window that gives users access to items that do not always need to be present. But when do you use a drawer and when do you use a palette?
Posted by: Lewis at January 25, 2004 12:10 AM
Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.
Posted by: Maurice at January 25, 2004 12:11 AM
For my Paint application, I created a series of icons to simulate a rendering algorithm. While the application is performing this CPU-intensive task, you can always see the status of the document by the icon changing in the Dock.
Posted by: Harman at January 25, 2004 12:12 AM
Not quite as entertaining as Shrek, but Dock animation can be an important and useful function in your application. For example, Dock animation is a helpful way to indicate the status of your application.
Posted by: Bertram at January 25, 2004 12:12 AM
So far in these articles, I have only dipped a toe or two into Aqua's pool. I have covered basic aspects of building an Aqua-compliant application, including the building of photo-illustrative/3D application icons. Now it's time to address other components of our Mac OS X application.
Posted by: Court at January 25, 2004 12:13 AM