Lukas Sommer


Radio Streamers Sep 08 2011
Score 85%
15 Dislikes


Qt Components May 15 2010
Score 52%
48 Dislikes


Qt Components May 15 2010
Score 50%
50 Dislikes


Development May 15 2010
Score 50%
50 Dislikes


Development May 15 2010
Score 54%
46 Dislikes
No supported products.
KStreamRipper Radio Streamers
Apr 01 2012
KStreamRipper Radio Streamers
Thanks :-)

It's nice to have also users from the GNOME side :-)

To respond your questions:

1.) About cairo-dock and closing/hiding dialogs: Frankly I didn't implement any behaviour for closing/hiding. This means that the dialog inherits the default behaviour of the "KConfigDialog" class. At least this is truth for the "general settings dialog" and the "stream settings dialog". As you report, this doesn't seem to be a good solution for cairo-dock. The "about" dialog (I suppose you mean this dialog when you say "help" dialog?) doesn't even has an implementation. It is automatically generated by the KDE framework, whichs copies the content from the general application information. I don't have any influance on the way this dialog is generated or closed. Well, I'm not sure, but it seems that this a problem of the interaction betweeen the cairo-dock framework and the KDE framework (or the Qt framework, which is the underlaying framework for KDE).

2.) About the tooltips/whatsthis: Also the tooltips and the "What's this" help are generated automatically by Qt from the information with which the widgets (buttons, sliders etc.) are created. I don't have any own implementation of this behaviour. Also in this case, it seems to be an interoperability. I supose it's somewhere between Qt and Unity. Qt tries to autodetect the desktop environment which is used and than tries to adopt it's appearance to the widget style and color scheme of this desktop environment. This works normally quite well. Here it seems to fail - eiter because Unity forces Qt to use a wrong color scheme of (IMHO more likly) because Qt doesn't detect correctly the color scheme of Unity. Anyway, it seems to be an interaction problem.

I'm sorry to not help you more. But this is a little bit "out of scope". And currently I'm quite busy with my job and don't have much time for programming. But thanks for your feedback.
Mar 31 2012
KStreamRipper Radio Streamers
Sep 08 2011
Oxygen Gtk QtCurve
Mar 17 2011
KStreamRipper Radio Streamers
Dec 20 2010
KStreamRipper Radio Streamers
Nov 24 2010
KStreamRipper Radio Streamers
Oct 02 2010
KStreamRipper Radio Streamers
> Hello, nice app!


> I have some suggestions:
> 1) Volumecontrol for the
> listening only would be
> nice.

That's a good idea. It's on our TODO list, but as I'm quiet busy now with other tasks, it will take some time. We will raise the priority of this feature, but it may take some months ...

> 2) The possibility to change
> the identification information
> global in the settings. So you
> haven't for every stream by hand.
> (all steams i added [from shoutcast]
> were refused to connect until i
> changed the identification
> information to 'winamp')

Yes, that's not working nice actually. However, we plan to try automatically (and silently) with some standard user agent strings (these that are present in the list in the configuration dialog) if a connection is refused. This would solve the problem for all streams that accept at least _one_ of the user agent strings in our current list. Would this be sufficient?

> 3) The possibility to listen
> streams without recording them
> actually.

Hm, I'm not sure with this one. From my point of view this is the task of a multimedia player. Which is your use case (= in which context, and doing which task, do you want to need this feature)?

> 4) The option to record only
> tracks which match with keywords.
> For example my keyword list
> contains the word 'Kanye west' so
> i could listen to my streams an
> only tracks which contains 'kanye
> west' would be recorded.

Yes, that would be fine. It will need a whole rewrite of all parts that do the storage (file saving ...). These parts are quite basic actually, but rewriting them could give more flexibility, implementing features like yours. I'm sorry, this is a huge task and probably will not be done in the next 2 years - we just don't have enough developers to do this.

Thanks for your opinion!
Sep 30 2010
KStreamRipper Radio Streamers
Aug 31 2010
KStreamRipper Radio Streamers
Aug 31 2010 Utilities
Jun 15 2010
KStreamRipper Radio Streamers
May 16 2010
KStreamRipper Radio Streamers
May 15 2010