12

Currently Device Notifier shows only removable devices (and does it very well )

But I think, that I could be extended to show now only removable devices, but also user selected directory(-ies).

Now I have to have 2 plasmoids: Quick launcher and Device Notifier (and they take a lot of my precious taskbar space ), but basically they do the same: gives direct access to directories removable or local.

E.g.
[php]
**********************
* My 1tb disk X *
* Super flash card X*
* *
* *
* *
* * <- This white space exits any way
* ------------------ * since Device Notifier has fixed
* Home * height.
* Stuff *
**********************

[/php]

UPDATE:

lacsilva wrote:What I would suggest is that the device notifier shows not only removable storage devices but also provide actions for all removable devices such as usb dvb devices, usb bluetooth devices, bluetooth devices in range, pcmcia cards, etc.

I agree with this part too

Okay, but that hasn't something to do with the Device Notifier I think. Should be something new like "Places" or something like that only with the look of Device Notifier.

The Device Notifier does not notify the user about new esata devices. I have external esata devices and unlike usb I have to manually find those devices and mount them.

That's a good idea, but as SebastianHRO already said, the resulting plasmoid should be called something like "Places".
Perhaps one could subdivide the contents of the plasmoid so that the upper part shows all pluggable devices and the lower part shows quicklinks to often used or user-specified directories.

I completely disagree, does it matter if i connect my harddisk with USB or ESATA? When I connect it via usb it is detected and I am prompted. When I connect it via esata there is no notification.
Is it a device ? Yes!
Is it a hard disk ? YES!
Should I be notified? YES!
AM I? NO!

Thats the problem.

NeoBrain wrote:That's a good idea, but as SebastianHRO already said, the resulting plasmoid should be called something like "Places".
Perhaps one could subdivide the contents of the plasmoid so that the upper part shows all pluggable devices and the lower part shows quicklinks to often used or user-specified directories.

You can already do this using a lancelot part applet.

"Device Notifier" is not the best name, but renaming plasmoid is the easiest part, I think

Still present "Device Notifier's" icon fits well

TheBlackCat wrote:You can already do this using a lancelot part applet.

Could you be more specific?
Basically I can do the same from menu louncher too, but the point is to have a quick access. Unless I haven't found something

Put the lancelot part (NOT the lancelot launcher) on your desktop, and the lancelot part on your desktop or panel. Drag the "removable", "fixed", and/or "places" modules from the computer section of the lancelot launcher to your lancelot part. Then drag the lancelot part to the panel or leave it on the desktop, whichever you prefer. Either way you will end up with just those items being immediately available, in an applet if it is on the desktop or in the form of a button if it is on a panel.

I actually wanted to write same post now. Thanks for the "search" on forum
Btw, lancelot does not handle cifs resources found in /etc/fstab (as media:/ in kde3 did).

Piotr

Seems real idea is to have a "Places" plasmoid. If "Places" where a location that could be done with a FolderView plasmoid.

An approach to this might to extend the concept somewhat to a simple, lightweight generalised "Publish / Subscribe" facility. There are a number of situations where a user might want some sort of notification of an occurence or event within the system. There are currently a number of examples of this -- e.g. notification of the arrival of an email, of an individual joining an IM chat or IRC channel, notification of attacment or removal of a removable device, etc.

All of these have a common structure: an event occurs, the user (or a piece of code acting on behalf of the user) is notified and initiates an appropriate action. The current approach requires that specific code be included in each process / procedure which generates an event and a (usually customised, single-function) client being created, configured and started to carry out the response function. it occurs to me that this is a perfect case for abstraction of the common behaviours into a "common service framework" availble to handle the "plumbing" for any of this case of use pattern.

The essential elements of this "service framework" would be:
1. A common, message-oriented transport (ala D-Bus);
2. A common message format -- header, payload, trailer to allow for rapid routing of the messages without the necessity for the producer to specify the routing (or specific destination for that matter) or for the "router" to decode the content of the message to apply routing rules;
3. A publish / subscribe engine which would:
a) receive requests (subscriptions) to receive specific messages or message types along with routing instructions (the name/identifier of a queue to receive the messages;
b) maintain a list of subscriptions;
c) maintain an input queue and receive messages representing event occurences from producers;
d) match the messages to the subscription requests and forward a copy of the message to each of the subscribers.

This is essentially a generalisation of the framework provided by D-bus, but because of differences it is probably not a replacement for D-bus because:
Routing of messages is subscriber-controlled rather than producer-controlled;
The publish/subscribe framework decouples producers from consumers - i.e. the producer has no certainty of specific recipients (or of any reciepients for that matter) - it is "fire & forget" and asynchronous;
While request-response sequences are possible, (i.e. producing a messge and subscribing to a message type which is its response), synchronous messaging, relible message delivery, etc would be likely to move this beyond the category of "simple & lightweight"

On the other hand, it provides a powerful and relatively simple framework for the type of behaviour outlined here. The developer of the responding "client" can decide what events it handles (possibly / probably allowing users to select these and the response behaviour by way of configuration) and the user could decide what combinations of events he wants handled by a given client and which/how many clients he/she wants active at a given time.

Simple utility libraries to provide functions / methods for generating event messages and dispatching them and for setting up and managing incoming queues and handling messages could make use of the facility very simple.

if plugging in drives via $WHATEVER hardware bus doesn't result in a notification, that's HAL's problem not Plasma.

What I would suggest is that the device notifier shows not only removable storage devices but also provide actions for all removable devices such as usb dvb devices, usb bluetooth devices, bluetooth devices in range, pcmcia cards, etc.