Le 8 avr. 07 à 18:24, Yen-Ju Chen a écrit :
It depends on the plan for ServicesBarKit. First, people can use it to write menulet. There is no problem at all. Second is the organization of menulets, we can have three options: 1. let menu server organize it, including drag-and-drop. 2. we can have a single "service space" attach to menu server and all the menulets are subview of this "service space", like what EtoileWildMenu does with menus. So this "service space" are responsible for menulets organization and menu server only need to put "service space" on it. 3. We can even make this "service space" an application so that it will not share events with menu server. It might be handy in some cases. We just need to make this "service space" the same background as menu server.While option 1 seems to be easier, option 2 or 3 may be a better choice for future.
The current implementation uses option 2, ServicesBarKit is both a framework and a menulet loaded into EtoileMenuServer. ServicesBarKit menulet is special because of its ability to load other menulets into its own menulet area. This area is a custom toolbar view so you should be able to rearrange and customize the menulet items inside it.
We may replace the toolbar view for now because there is an issue with it: no way to modify the toolbar height. It means all items are displayed with labels in the menu bar (because 'label only display mode' is the only toolbar mode that uses a height small enough).
ServicesBarKit API is based on NSStatusItem and NSStatusBar from Cocoa. NSStatusItem and NSStatusBar are used by applications which wants to create temporary system-wide extra menus in Mac OS X. When such applications exits, any extra menus they created just disappear. That's why I created two superclasses SBServicesBarItem and SBServicesBar which aim to be more versatile (their name sounds less specific too). NSStatusItem and NSStatusBar would almost be empty subclasses.
If ServicesBarKit-based menulets are packaged in bundles and loaded directly by the menu server, we shouldn't encounter a lot of complexity. However in case ServicesBarKit API is used in an application context, this involves we should return proxies for NSStatusItem instances and I'm not really sure developers won't encounter issues with all that messaging over DO (with potential encoding and application termination issues too). On Mac OS X, all status menu items created by an application are in fact small windows sticked on top of the menu bar. This hack isn't really nice I think though. For example it prevents rearranging these items whereas you can rearrage system-wide menu extra items.
What's your take on this?
My current plan is to have a volume menulet
Would be nice. Don't forget to put the sound specific code in SystemConfig framework.
and probably another menulet for service menu as you tried before.
ok Cheers, Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
