On 4/8/07, Quentin Mathé <[EMAIL PROTECTED]> wrote:
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?
Thanx for this information. I will take a look.
Regarding to OSX's implementation,
it is very similar to what I have in AZDock.
Each icon is actually a NSWindow.
The rearrangement of icon would need some work.
But a good thing is that it prevent one icon from messing another,
which is handy for AZDock handling GNUstep
and X window at the same time.
If each icon on service bar is controlled by its application,
the rearrangement is indeed an issue.
I think a good way is that the menlet is still loaded
by menu server (through ServerBarKit as option 2)
and the communication between menulet and its application
is through DO. Whether it works well through DO is the problem
of the application which provide the menulet.
An example of mine is an old volume control I had before.
At that time, I ask how efficient the DO on the maillist.
The answer I got and the implementation I have shows
that the DO can handles communication between
dragging on a NSSlider to an application which changes the volume.
It is about 10-20 distant notification per second.
> My current plan is to have a volume menulet
Would be nice. Don't forget to put the sound specific code in
SystemConfig framework.
I have an implementation of mixer in MultimediaKit
and an example in Developer/Examples/MixerExample.
All I need is a menulet to use this mixer in MultimediaKit.
I can put it in SystemConfig.
But does it make more sense in MultimediaKit ?
On the other hand, for regular users, we only need a mixer
for system volume and microphone volume.
For professional users, they are not going to use our mixer anyway.
So there is no problem to make the one in MultimediaKit simpler
and move it to SystemConfig.
> and probably another menulet
> for service menu as you tried before.
ok
I need to take a look at this first, though.
Yen-Ju
Cheers,
Quentin.
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
