[speirsfr]

So, what do we all think? Will 10.1 see the end of the (admittedly unsupported, ultra-hacked-up) dockling API, removed in favour of System Menus?

Docklings give you some quite rich visual feedback with that 128x128 icon, but to be honest I only use the two - battery power and my own <A HREF="http://www.speirs.org">RSIDock</a>.

What do we think? Is Apple restoring App/File/Folder purity to the dock?

Oh yeah, and there's the Application Dock Menus feature coming soon too....

Fraz

[Lolo from Paris]

I don't think Docklings will disappear...Some docklings were useless (mostly Apple/System ones) but some are great and very useful.

I do think docklings API will still be there.

Systems menus aren't a good solution because you can't have a lot o f menus in the upper right corner...

So, maybe it's only a temporary solution and perhaps we will see the OS 9 control strip back later ?

IMO Applications icons in the Dock should do the same as the docklings, iTunes, Audion and apps docklings are a stupid idea, it should be in the app dock icon menu.

[Porfiry2001]

The impression I got was that docklings could become system menus, should the user so wish it, but they still can act as docklings.

[NSNewbie]

I think the only things that are going on that menu bar are the one's Jobs showed. Not entirely coincidental when you consider those were probably the most frequently used control strip features. Hoepfully, they'll make room for say a maximum of 6 items, and give users some choice about which six items go there (down the road).

That said, I don't think Docklings will go away ; they can be used for other kinds of utilities and applications. Does anyone know if the new Carbon SDK (1.4b) supports Docklings (or Control Panels) yet? Any major bugs get squashed?

[Angus_D]

I'm sure I read somewhere that Apple has stated that they're going to open up the System Menu API. With the Dock Menu API, we should see a lot of Docklings going away (like the annoyingly useful but space-taking iTunes dockling).

I doubt CarbonLib will ever have native support for writing docklings -- the API is C so you can call it from within Carbon code (the class from Stepwise is only a wrapper library, some proper code is part of Space, http://space.sourceforge.net . As for Control Panels, if you mean System Preferences, then they will almost certainly be Cocoa when (if) the API is made public (I seem to remember Eric Peyton suggesting that it will become public sometime in the future).

The impression I got was that docklings could become system menus, should the user so wish it, but they still can act as docklings.

I do not think that this is the case.

[sadie]

What would be useful is if non-running programs could still act as docklings, and pop up menus. Potentially even more useful is the menus for documents - be they dock menus or popup menus in the finder. A program could stick all sorts of useful items in those menus. But again, it would need to keep working dynamically even when the program wasn't running.

This would likely need some extra parts in the .app packages. Any hope of this? Or is this beyond the ken of even the hallowed ranks of NeXT?

[nonhuman]

I really don't like the System Menus at all from what I've seen of them. It just seems weird to me to have a whole menu dedicated to volume and an other whole menu dedicated to display options. And don't get me started on that tiny little "analog" clock menu... It just seems to me that if you put a menu in the system menu bar it should be a full blown menu, the idea of getting a volume slider, and just a volume slider, to pop out of the menu bar just seems really strange to me. Maybe it's just the fact that it's new and different that makes it seem bad (I hated the dock at first, but now I like it), but I have always thought that the the menu bar is for big, important, versatile things that are meant to be used often. I use functions from the file menu all the time, but once I set my volume and resolution I usually don't change them. The control strip approach was great in my opinion because it was in-obtrusive while steal being easily usable from any Application, and it's positioning at the bottom of screen—and it's retractability—makes it seem less important (which it is) than the menu bar.

Originally posted by sadie:
<STRONG>What would be useful is if non-running programs could still act as docklings, and pop up menus. Potentially even more useful is the menus for documents - be they dock menus or popup menus in the finder. A program could stick all sorts of useful items in those menus. But again, it would need to keep working dynamically even when the program wasn't running.

This would likely need some extra parts in the .app packages. Any hope of this? Or is this beyond the ken of even the hallowed ranks of NeXT?</STRONG>

I think this is a really great idea BTW...

[BlackGriffen]

Originally posted by nonhuman:
[QB]I really don't like the System Menus at all from what I've seen of them. It just seems weird to me to have a whole menu dedicated to volume and an other whole menu dedicated to display options. And don't get me started on that tiny little "analog" clock menu... It just seems to me that if you put a menu in the system menu bar it should be a full blown menu, the idea of getting a volume slider, and just a volume slider, to pop out of the menu bar just seems really strange to me. Maybe it's just the fact that it's new and different that makes it seem bad (I hated the dock at first, but now I like it), but I have always thought that the the menu bar is for big, important, versatile things that are meant to be used often. I use functions from the file menu all the time, but once I set my volume and resolution I usually don't change them. The control strip approach was great in my opinion because it was in-obtrusive while steal being easily usable from any Application, and it's positioning at the bottom of screen—and it's retractability—makes it seem less important (which it is) than the menu bar.

What if Apple stuck the control stip inside the menu? Consider this: a small tab to the left of the clock that, when clicked on, expands left like the control strip did (as far as possible not to overlap, or as far as the user set, maybe even let it lie over the menus). This strip would have all the functionality of the stip, could be left open, and will save screen real estate.

Also, I think that the application icons as docklings in a wonderful idea. Perhaps incorporate a dockling in to the bundle that is used as the app icon whether the app is open or not?

BlackGriffen

Edit: I need to quit freakin' posting in the middle of the night; I called menus windows .

[ 07-28-2001: Message edited by: BlackGriffen ]

[BlackGriffen]

Here's what I sent to Apple on the System Menus bit:
"One complaint I have about making things like system volume a permanent menue are that I don't use it often enough to justify a menu, but when I want it I want quick access. The system menus are a solution to the second half, but not the first. Why not make the space between the clock and last menu the home of a revamped control strip. Users can hide the small square menues when they don't need them, and expand it when they do. The can even manually expand it to cover menus. The strip must never do that automatically if the user just clicks to open it, though (too disruptive). Things I would put in a menu like this immediately:
The keyboard select menu,
monitor depth,
resolution,
battery level,
sound,
Energy saver stuff (hard "drive sleep now"-like functions)
PPP
Remote login/sharing
In short: everything the control strip used to have and then some. Everything that shouldn't be in the dock because:
it isn't worth the screen real estate,
it doesn't require dynamic updates that require dock sized icons,
it isn't used frequently enough to justify always open, but frequenly enough (and in a simple enough fasion) to make the time requirements of launching system annoying.
To change this strip I would reccomend against using the tear off strategy in the dock and tool bar (where they simply click and move). It adds a time delay, and because of the small size, makes it easier to accidentally remove an item than in the dock. Instead the strip will need a preference panel. Have a folder in /Library/ to cantain .strip modules for the strip to use, and let the user edit the strip using drag and drop in the preference panel."

And here is what I sent on the dockling bit (paraphrased):

"Add the ability to put docklings in .app packages. What I mean by this is that whenever the dock loads a .app (or .app alias) it will check for a dockling to load in the icon's stead. It should be fairly simple, like an xml setting:
&lt;DOCK PROXY&gt;Contents/iTunes.dock&lt;/DOCK PROXY&gt;
This way you can implement menus in the dock with relative simplicity, and even have access to a bit of the app when it hasn't been launched yet (if the author adds it)."

Great ideas here, guys .

BlackGriffen

[Subzero Diesel949]

Hmmm touchy subject. One one hand the new system menus look like an after-thought in the menu bar. I would rather have the keyboard-controls take care of that. On the other, the docklings take up space in the Dock and often have repetitive functions that can be done with the app itself (for example the Audion and iTunes docklings). Other docklings rock, such as Massinova (for you trancers out there).

I would prefer that control-clicking on the icons in the Dock bring up dockling-like options.

[bewebste]

I think that docklings have good potential, but there are some things that just don't exist in the API which limit their usefulness. For instance, there's no way to drag and drop something onto a dockling. They can provide useful functionality, including pretty good visual feedback, without the overhead of a full-blown app.

The redundant app/dockling pairing is definitely silly, and it appears that Apple is allowing apps to add custom items to their menus. One good idea that I've heard before would be to allow users to add their own menu items, perhaps having an item invoke an Applescript. Apps could actually implement their own items via Applescripts, and the user would be able to customize their dock in that way. You could also throw in shell script support for the UNIX-savvy.

I don't think docklings will be going away, and I think for some things the system menus provide a better interface, especially since they take up less space.