[Kde-hardware-devel] SolidBackendSelector API review

Ben Cooksley sourtooth at gmail.com
Wed Apr 8 13:28:41 CEST 2009


2009/4/8 Kevin Ottens <ervin at kde.org>:
> On Saturday 28 March 2009 04:21:25 Ben Cooksley wrote:
>> Visually, I propose using a approach similar to the widget used to
>> select the Phonon backend, with "Defer" / "Prefer" buttons at the
>> bottom of the list.
>
> And actually Phonon should be a target to porting to a new shared backend
> selector.
Sounds great, although these also have configuration attached to them.
I suppose that the KService method would allow retrieval of the
information needed to show this.

>
>> === Proposed specification ==
>>
>> SolidBackendSelector( QWidget *parent, QString type ) // type is the
>> backend type that is going to be configured
>
> If it ever reaches kdelibs, obviously the class name would need to be changed.
> Probably to a "KBackendSelector" or such.
>
>> Functions:
>> void saveConfiguration()
>> void defaultConfiguration()
>
> I guess that load()/save()/defaults() works better as it matches KCM linguo
> (and AFAIK this new class would be mainly used in KCMs).
I believe this is what was chosen when it was submitted to
reviewboard. ( Dario: Was that committed to playground? )

>
>> KIcon backendIcon()
>> QString backendName()
>> QString backendComment()
>> QString backendVersion()
>
> You can probably merge all of that in a single method which would be:
> KService::Ptr selectedBackend() const;
Sounds more sensible.

>
> This way the user of the class can query all the service information he needs,
> even some stuff which would be specific to him. With your proposed API you're
> limiting this ability.
>
>> Signals:
>> void selectionChanged()
void selectionChanged(bool change) maybe?

Where change would be true when it has changed from the originally
selected item.
>
> For this one you have to also carry some information to tell if it changed to
> the initial value or not. Again in the case of a KCM that's needed to know if
> we have to enable or not the Apply button. Use case is the following:
>  - I show the widget, we already have a backend X and it's selected, Apply is
> disabled
>  - User selects the backend Y, Apply is enabled
>  - User selects the backend X again, Apply should be disabled again.
> You can only do that if you memorize that X was the previously selected one,
> and provide the information to the outside.
>
> 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."
>
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
>

Cheers,
Ben Cooksley.


More information about the Kde-hardware-devel mailing list