[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [PATCH + FEATURE] Automatic notification of hotplugged devices
From:       Kévin_Ottens <ervin () ipsquad ! net>
Date:       2005-05-14 16:16:37
Message-ID: 200505141816.37387.ervin () ipsquad ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le Samedi 14 Mai 2005 00:12, Edwin Schepers a écrit :
> For me, this is a minor issue that can easily be made configurable.

Depends, you won't show the same amount of informations in a passive popup.

> My bigger problem is that (when using another kded module) is that users
> are saddled up with a program which takes resources, startup time, desktop
> space for something they're maybe never to use (or seldom). Can you address
> this issue ?

Well, I'm not sure the overhead is really critical if you use a kdedmodule. 
But, the maintainability advantages are real : separation of concerns.

> Thought from a 1.5hour car trip :
> We now have the HAL daemon sending signals, catched by the kdedmodule. Now
> we need another program which catches signals from the kdedmodule ?

Or even simpler something listing media:/ (it's already done by the 
mediaapplet in kicker for example).

> I think it is not intrusive to extend the functionality of the Media
> Manager with some notification. Even when that means that the notification
> has to be made at some more points ( However I'm not sure if I use
> cdpolling when I already use HAL).

I prefer seeing the notification completely separated. But, if it has too many 
technical drawbacks I'm not against extending the mediamanager (of course). 
My only concern was the way it has been done, by putting the notification 
code in the backend themselves. Jérôme proposals are the way to go if we 
extend the mediamanager itself.

> When kdedmodule receives a signal (i'll call the medianotifier now 
> mediahandler):

Which kdedmodule? I suppose you're talking about the one managing 
notifications (now called mediahandler).

> 1. if mediahandler is not started then
>      start mediahandler

Well, it has to be started in order to be connected to the signal...

> 2. send out a DCOP signal about a new device
>
> When the mediahandler gets started:
> 1. It gets started in the systray

Well, I imagine some people will scream : another thing randomly thrown in the 
systray!!! =)

> 2. It starts listening for signals.

Ok, or listening to media:/ (and then possibly another URL...)

> 3. When it receives a signal, it notifies the user (according to the user's
> configuration).

Ok.

> From the systray, the configuration can be accessed (just like kdeautorun)
> and devices can be "safely removed". (Also mediahandler can be exited of
> course)

Well, if it lies in the systray, why not...

> I hope you can agree with this.

I'm not too confident about the "systray" part... Having something completely 
controled by a kcm looks better to me. Which tends to make your point about 
resources moot since it could be disabled (of course it means we're not 
writing a process eating up all your memory =) )

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]