Re: [kde-freebsd] KDE4/Qt4 porting efforts?
Hi, Actually there is a back-end based on ffmpeg for phonon : http://websvn.kde.org/branches/work/avkode/ It's the result of a last year summer of code. And about the choice of xine, it was the back-end which worked the better for the most people. It can be easily change in the future if someone come up with a better back-end. And as for phonon, well, most KDE-based multimedia players are allready having multiple backend support, so phonon is mostly share the infrastructure between them instead of reinventing the wheel over and over. -- Cyrille Berger ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
Re: [kde-freebsd] KDE4/Qt4 porting efforts?
On Tuesday 08 January 2008 10:01:13 Adriaan de Groot wrote: On Sunday 06 January 2008, Danny Pansters wrote: IMHO both xine and gstreamer were piss-poor choices for the a/v backend, they should have built their own infrastructure around ffmpeg instead which in any event is the *real* a/v engine that eventually gets used, would have left the multimedia backend framework basically up to themselves, possibly manpower shortage was the main reason for this? Manpower, and the desire *not* to write a mm backend, but only the 80% solution (common functionality, no specialized needs) KDE API for the majority of KDE applications. It's always been a stated goal of the KDE4 MM framework *not* to impinge on the space where people who know what they're doing and who have specific needs to do MM with ffmpeg. Ah, and arts has left a bad taste in the mouth. Ok, I can understand that, but still, now you have two wrappers wrapping wrappers... :) I think one major reason was (aside of perhaps -- mistakingly? -- embracing gstreamer early on) that xinelib was already known and used (and now it's sort of the safety net when gstreamer doean't work). Correct? Don't make it good choices though. I don't want to argue over this, but I think a (somewhat educated) opinion is never a bad thing, and having looked at and worked with ffmpeg over the past few weeks, I have to say that xine-lib is very limited for a library (add to that GPL licenses on header files). I very quickly gravitated to the real thing, ffmpeg (also the only MM library that has more modern mpeg2 support than the bolted-on-mpeg2dec that once was the selling point of xine). One merely has to look at performance. And really, if I -- with my almost nonexistant C knowledge -- can turn ffplay into a small viewer library for my application in a few days, I have the feeling that it has been shunned perhaps a little too fast. As for gstreamer... I haven't used it but it looks interesting, though likely overengineered. And let's face it, it's a gnome thing, and one with an unstable API. I'm sure that with gnome/totem and the fluendo plugin$ it'll work well. But for KDE? Oh yeah, arts. Arts. Our dear lil arts :) Talk about overengineered :) PulseAudio is where it's going to be happening now I reckon, and that's probably good (if only because it hopefully strongly discourages ALASA-only code). The MM points (xine/gst vs ffmpeg) are moot, I know. But they can still be made. BTW, I really appreciate that harsh criticism can be voiced over such things without a knee-jerk you just hate us, go away! reaction. Cheers, Dan ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
Re: [kde-freebsd] KDE4/Qt4 porting efforts?
On Tuesday 08 January 2008 09:48:14 Adriaan de Groot wrote: of dialog boxes. I have not fixed that one yet. support, libs, pimlibs all build out-of-the-box on FreeBSD-6. I've just discovered that FBSD-6 doesn't It will NOT build out-of-the-box if people have qt3 installed, trust me. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
Re: [kde-freebsd] KDE4/Qt4 porting efforts?
On Saturday 05 January 2008 09:42:41 Shane Bell wrote: On Sat, 05 Jan 2008 09:42 am Adriaan de Groot wrote: On Friday 04 January 2008 20:54, Mikhail Teterin wrote: How is the subject coming along? It seems, some new things like strigi are required for kdelibs-4 -- but I don't see a port of that in the tree yet... Would you like it added? All the things in kdesupport should have ports created. Since they depend only on Qt4 (and possibly other things) this should be fairly straightforward. Bear in mind that their build systems are CMake-based. I'm not sure there's any infrastructure for CMake-based ports yet. I've got a port for strigi here that's about 90% complete, but I've been waiting for a couple things, namely: - The next release of strigi, because it will make OPTIONS handling in the port a lot more neater/easier. - Updated Qt4 in ports. bombs on qt from ports(iirc something to do with moc), works fine with svn qt-copy though. I also made a simple bsd.cmake.mk a few months back. Never tested it out though, so ill have look it and make it available when I'm done. shane. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd I never found the time and/or inspiration to persue it further, but I created a few kitchen sink type ports for kdesupport4, kdelibs4, kdebase4, kdepimlibs4 back in September. It compiled and I could start the desktop but (as Adriaan has also blogged about and somewhat worked around) knotify4 barfed really bad. sidenote type='related though' IMHO both xine and gstreamer were piss-poor choices for the a/v backend, they should have built their own infrastructure around ffmpeg instead which in any event is the *real* a/v engine that eventually gets used, would have left the multimedia backend framework basically up to themselves, possibly manpower shortage was the main reason for this? I think eventually I'm going to try and make kbtv(2) a backend for the capture stuff (somewhat like v4l). /sidenote While these preliminary ports won't work as-is now, there's probably a lot of useful info, and they contain many REINPLACE_CMD lines that are for peaceful qt3/qt4 co-existance (both installed in /usr/local). Most of those will probably still be applicable and they really should go upstream (most linux distros had qt3/kde3 under /opt, so they don't see any of those qt4 vs qt3 problems). So FWIW, they're at http://freebsd.ricin.com/kde4ports_sept2007.tbz You should extract it in your PORTSDIR. I'm pretty sure it can at least save some people some time. A good bsd.cmake.mk would be very useful I think (CC and CFLAGS might need some looking into). Cmake is quite awesome, if used correctly. It has many features that are functionally the same as our ports infrastructure. It's not another autohell. But I can't say that I fully grasp all of its features and possibilities, and what's mostly needed I think is for someone to define some set of best/recommended practices. A bsd.cmake.mk is the perfect place for that. I admit to have daydreamed a little over a cports concept. It really is that useful and flexible. Cheers, and happy new year Dan ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
Re: [kde-freebsd] KDE4/Qt4 porting efforts?
On Friday 04 January 2008 20:54, Mikhail Teterin wrote: Given that Qt4 claims to have Qt3-compatibility, maybe, it is a good idea to switch KDE3 to Qt4 for the time being, so as to avoid upgrading both pieces at once? Claims and has a complete source-compatible infrastructure are two very different things, unfortunately. Among other things, many container classes have changed fundamentally, lots of widgets have vanished. It's a fairly simple to port compatibility, not a drop-in replacement. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
