Phonon core/ui split

Thursday, April 26. 2007

I am about to get rid of the core/ui split of the Phonon libraries. As you can see, a GUI application that only uses functionality from phononcore does not really benefit from the split:

objdump -T libphononcore.so|grep "\.text"|wc -l
617
objdump -T libphononui.so|grep "\.text"|wc -l
127

You might argue about the non-GUI apps that want to use Phonon. But seriously, what apps are those?

If you want to, you can still try to convince me that the split adds value. But you have to make some really good arguments to justify the added complexity on the frontend and backend sides and the added exported symbols that are necessary for it.

Posted by Matthias Kretz in Phonon at 15:31 | Comments (24) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

I think it would be best to keep the split, as there are some applications that could take advantage of Phonon, but yet not present a GUI.

For instance, I am working on a CD ripper that will have an interactive GUI mode and a command-line interface batch mode. The batch mode does not use a GUI, and it is possible to compile it without GUI support. Keeping Phonon split into core/GUI modules would allow me to utilize Phonon even for batch mode.

Furthermore, retaining the split would help to "keep you honest" in how you partition functionality. Think Model-View-Controller or "Document View" and you will know what I mean. Mixing core and GUI into a single module will blur the partitioning of functionality.

#1 Jason Voegele (Homepage) on 2007-04-26 16:04 (Reply)

You can still link against libphonon even if you don't show a GUI. The only downside is that you'll link against QtGui and all its dependencies. But that doesn't mean you need to have an X server running to use the application.

I see the advantage, of course, for console applications. But is it important enough to justify the added complexity?

The split actually doesn't help partitioning functionality it only makes the APIs harder to use. Because you can not, for instance, implement a QAbstractItemModel that provides a decoration (i.e. icon) without adding a hack that provides the icon if you link against phononui.

In short: for API design the split does not help, it makes it harder. To implement a backend the split makes it harder. All this added complexity shows up as additional (exported) symbols and more code == bigger libs.

#1.1 Matthias Kretz (Homepage) on 2007-04-26 16:28 (Reply)

Good for you man. This core/ui split is mostly for KDE stupid and merely "let's do it because we can!" crap.

Makes sense for Qt, but not for a Desktop Environment.

#2 Max Howell (Homepage) on 2007-04-26 16:54 (Reply)

Having a lightweight speech recognition daemon translating speech to dbus commands would be nice.

#3 Jos on 2007-04-26 16:58 (Reply)

Four words: Phonon-based GNOME apps. (Two more words: world supremacy!)

Seriously, do what you think is best.

Functional domain splits /do/ make it harder to design an API, as the evolution of the Qt API itself shows.

Admittedly, I'm not very much up to date on what in Phonon's design makes it hard to separate the UI part of the libs from the core; I tried hunting down more information on the Phonon Web site, but I could not find API docs there. You should make a post on the technical details of the issue!

That'd be a great look into the Phonon internals, which I'd sure be very interested in, and I'm probably not the only one.

I'd say, if at all in doubt about community approval, try to run the idea by one of the top dogs like aseigo; if their support doesn't reassure everyone, I don't know what will!

#4 S. on 2007-04-26 17:06 (Reply)

[quote]You should make a post on the technical details of the issue![/quote]

I would if I had more time. But kdelibs freeze is coming up really fast now.

#4.1 Matthias Kretz (Homepage) on 2007-04-26 21:22 (Reply)

You cheat with the objdump, no? Ie. shouldn't you add the symbols for QtUi too?
For kmplayer's plugin this would be a real pity as explained before.
Btw. I don't understand your example above of the icon. That's a gui thing, no?

#5 koos on 2007-04-26 19:42 (Reply)

Well that, of course, depends on your application whether you link against QtGui already or not. Almost all KDE apps do, so there's actually a gain in merging core and ui (because it's one lib less).

kmplayer's plugin would need phononui anyway for the video, no?

You can argue that a data model is really a non-UI thing (and QAbstractItemModel is in QtCore as well). So the model is available in phononcore. But I can and want to provide decorations for the items. That needs a hack in phononui to create a global object that creates the icons in a QVariant to be used by the model. That way the model is also full-featured for GUI applications.

#5.1 Matthias Kretz (Homepage) on 2007-04-26 21:30 (Reply)

Well I'm just happy that people won't be confused anymore by thinking they have a Xine backend compiled when its actually an audio-only backend.

#6 Ian Monroe (Homepage) on 2007-04-26 21:38 (Reply)

You seriously need to explain more which kinds of functionality are available to use from phonon in other apps in both cases to contrast them clearly. The information you give is just too little (given the lack of API information) for others who read this to form an opinion. Consequently, feedback here means nothing. Please post more on this!

#7 zahm on 2007-04-26 21:54 (Reply)

With kmplayer current backends, I only pass a X window id for the video output. The QAplication is created with the no-gui boolean (except for mplayer of course). So no QtGui linkage in backends for kmplayer.
(Sometime ago we had this discussion whether phonon should use the backends in- or out-of-process and you decided on in-process. For a browser plugin I still find that unacceptable. Painfull that I can't use the phonon controlpanel, yes.)

I can't really comment on your model problems, but having a non-gui core that has not this functionality, one should use the gui-lib, would be okay with me.
I don't follow the QAbstractItemModel is in QtCore argument.

#8 koos on 2007-04-26 22:00 (Reply)

With Phonon the only way to show video on the screen is to create a VideoWidget. And that class is in phononui (for obvious reasons).

This was just an example of how the split gets in the way of the API design decisions. Of course the other option would have been to put the model class into phononui. But then it wouldn't have been possible for non-GUI applications to use the class.

Regarding the out-of-process backend, I'm playing with the idea of a proxy backend that gets loaded by Phonon and loads the real backend in a separate process and handles the communication between them...

#8.1 Matthias Kretz (Homepage) on 2007-04-26 22:18 (Reply)

Sorry on the threading mess ..

The poxy backend is indeed okay as well (I guess that would be something I have now, but with the phonon bonuses). But then isn't this something console users might won't, eg. dbus-send/-monitor should be rather easy (assuming the dbus will launch such a service).
Other than that, you're right on the QtGui then if video would need a QWidget anyhow.

#8.1.1 koos on 2007-04-26 22:38 (Reply)

Yes, console applications were the sole reason for phononcore. The question really is whether there will be many of those apps to justify the added complexity, slower startup time of applications using phononui. Perhaps exaggerated it comes down to the question: optimize for console apps or optimize for GUI apps.

#8.1.1.1 Matthias Kretz (Homepage) on 2007-04-27 14:24 (Reply)

I think as long as it is possible to make console-applications which use phonon and don't want to show ui and need no X Server _running_ it is no problem. The Qt package already depends on X on all distributions i know. So if Qt is installed, chances are high that X is also available. - So no real problem here. Go ahead and make the API cleaner and easier!

#9 Daniel Haas on 2007-04-27 10:05 (Reply)

Not to be rude, but being unable to separate functionality and UI without hacks sounds like you have deeper problems with your design. The example you mention should be easily handled by either encapsuling or inheritance, but I know too little of the actual problem to point to an actual solution.

That said, kdelibs freeze is really close, and not having phonon ready would be a shame. On the other hand, APIs really shouldn't be rushed.

#10 Esben Mose Hansen (Homepage) on 2007-04-27 12:36 (Reply)

This pretty much is my point. The good thing about making the UI and the backend seperate libs makes you think about the API.

And you get an added bonus since you suddenly have a real users of your core API - the UI lib. So you notice missing API or missing headers that should have been installed before you release it.

Other than that, it's just more work.

#10.1 Benjamin Otte on 2007-04-27 12:52 (Reply)

[quote]The good thing about making the UI and the backend seperate libs makes you think about the API.[/quote]
Do you mean core instead of backend here?

[quote]And you get an added bonus since you suddenly have a real users of your core API - the UI lib.[/quote]
Real users of my core API are the tests. The UI lib is really not a user of the core API it just adds GUI classes to the non-GUI classes.

[quote]So you notice missing API or missing headers that should have been installed before you release it.[/quote]
No you don't. Because the sources live in the same directory anyway. So you don't include installed headers but the original uninstalled ones. Which is rather important to be able to include the private headers.

#10.1.1 Matthias Kretz (Homepage) on 2007-04-27 14:47 (Reply)

> The UI lib is really not a user of the core API it just adds GUI classes to the
> non-GUI classes.

Ah, this might be where the misunderstanding comes from. If people here are thinking the way I do, they were probably imagining the GUI classes as /extending/ the core classes, like Qt 4 does. If they don't, then indeed the separation between the two is probably somewhat arbitrary.

Thank you for all the good work Matthias!

#10.1.1.1 S. on 2007-04-27 15:47 (Reply)

[quote]being unable to separate functionality and UI without hacks sounds like you have deeper problems with your design.[/quote]
It probably just means that the design is aiming for a lot of things with higher priority than the split of core/ui.

[quote]The example you mention should be easily handled by either encapsuling or inheritance, but I know too little of the actual problem to point to an actual solution.[/quote]
That would mean two different model classes which in essence accomplish the same except for the icon? I don't think that's intuitive.

#10.2 Matthias Kretz (Homepage) on 2007-04-27 14:42 (Reply)

What about non KDE based GUI apps? If you have phonon core seprate from the UI libary maby someone will create a WX TK or GTK based libary that talks to phonon core.

#11 Anonymous on 2007-04-30 11:41 (Reply)

Phonon links against QtCore anyway. So that might already be reason enough for many people to discard the idea of using Phonon (I don't agree with that view, though). Second, if you don't use phononui you'll have a hard time displaying the video.

#11.1 Matthias Kretz (Homepage) on 2007-04-30 15:43 (Reply)

Dose phonon without the GUI link against QtCore?

And as for displaying video without phononui, I was thinking that maby someone would make a replacement based on WXwidgets or GTK rather than QT, not much chance of that if the gui is built in.

#11.1.1 Anonymous on 2007-04-30 20:55 (Reply)

Yes, phononcore needs kdecore (which needs QtCore and QtDbus).

I don't think anybody will want to write a GTK replacement for phononui...

#11.1.1.1 Matthias Kretz (Homepage) on 2007-04-30 21:22 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: HTML-Tags will be converted to Entities. You can use [geshi lang=lang_name [,ln={y\|n}]][/lang] tags to embed source code snippets Standard emoticons like :-) and ;-) are converted to images.
	Remember Information? Subscribe to this entry