On Monday 29 June 2009 21:27:27 Matthias Clasen wrote:
Hey all,
we'd like to announce the 'Fit and Finish' initiative for Fedora,
http://fedoraproject.org/wiki/Fit_and_Finish
with the goal to improve the user experience of the Fedora desktop. We want to identify the small (and sometimes large) roadblocks that make everyday computer use harder than it needs to be, and try to fix them.
Does this apply only to so called "Fedora desktop" = Gnome or to Fedora Desktop - as desktop environments (KDE, LXDE, XFCE4)?
If only for Gnome, can we attend this effort either? Speaking in name of KDE SIG? It looks really interesting for me - avoid small bad user experience.
Jaroslav
'Fit and Finish' is meant to be complementary to the work of the Fedora QA team. They do a great job of ensuring the quality of all the new features that land in Fedora each cycle. But when features are developed and tested on their own, the overall experience of the system as a whole can sometimes end up a bit uneven and rough. 'Fit and Finish' will focus on improving the way our users experience Fedora.
To achieve this, we will hold regular test days, each of which will focus on use cases in a certain area. A few ideas for test day topics can be found on the 'Fit and Finish' page already. If you have ideas for other areas that could benefit from this kind of attention, please let us know.
Our first test day will focus on display configuration, and will be held on Tuesday, July 7, from 12:00 to 21:00 UTC (8am -> 5pm EDT), in the fedora-fit-and-finish irc channel on FreeNode. Please come and join us there !
Matthias Clasen for the Desktop team
Since the topic arouse, I'll take this opportunity to get some feedback from you guys.
I've been (very slowly) gathering some use cases, though I'd probably refer to them as common user activities here [1].
I'm planning on testing them out on my (hopefully) soon to be F11/KDE install
If you see any things missing there, I'd appreciate being told.
[1] http://pembo13.com/foss/desktop-use-cases
Here's is the biggest obstacle to a good user experience.
Stop trying to integrate or force integration of everything into everything. I've recently run into a nasty experience with wine and pulseaudio. Where at least with one application under wine if pulse is installed networking doesn't work and the application freezes. On top of it all the application freezes. And there is of yet, still no official support for pulse under wine.
Why should a soundserver interfere with networking?
One of thing us old redhat / kde users are very well aware of is that if you try to get one environment to work like another or use resources from another then everything becomes disfunctional. Let gnome behave like gnome, kde like kde, wine like wine etc.
Right now the defacto standard Linux soundserver is alsa. If alsa is installed, then that should be enough.
Please lets do what we can to not go the Redhat 8 route again. Please. It just doesn't work in Linux. Linux is not Windows
Thanks for Listening :)
Eli
Eli Wapniarski wrote:
Stop trying to integrate or force integration of everything into everything.
I disagree. It's important for components to work together.
And there is of yet, still no official support for pulse under wine.
But there is the WinePulse project which is what we're shipping. http://art.ified.ca/?page_id=40 If you encounter bugs with it, you need to report them.
And the reason upstream WINE refuses to merge the patch is because they want to rewrite the whole sound system and they don't want any new backends until that happens, no matter how important those new backends are. :-/ It has nothing to do with the quality of the backend.
Why should a soundserver interfere with networking?
I don't know. But there's certainly an explanation.
Right now the defacto standard Linux soundserver is alsa.
No, the de-facto standard is PulseAudio now. We aren't the only ones shipping it as the default, at least Ubuntu and Mandriva ship it too.
It's not possible to have apps only support hardware ALSA in a PulseAudio environment, they'll not work (because PulseAudio needs the sound device). The problem with WINE's ALSA backend is that it needs mmap and thus won't work with the PulseAudio ALSA plugin.
You can try the ESD backend (wine-esd), which uses PulseAudio's ESD compatibility layer (pulseaudio-esound-compat).
Please lets do what we can to not go the Redhat 8 route again. Please.
Do you have anything against Bluecurve? I still use it. :-)
Kevin Kofler
Question:
What if, instead of passing out Live CD images, you passed out virtual machine images?
These could be compact (at least around the range of a Live CD/DVD), but a little speedier (I personally find that even on my recent laptop, a virtual machine runs much smoother than a live CD booted system.)
Assuming this was integrated with an initiative on how to teach users to quickly install and setup the virtual machine, this would have the following advantages:
1. Current Fedora users could easily participate without modifying their system, and in a much more efficient manner than booting other systems.
2. Setup would be much easier -- perhaps the installation and removal of the images could be handled through a package. This would also mean that you could pass down updated images for Testers using the update system.
The only clear disadvantage would be that 1) no live Image for those who do not have a virtual machine manager (but since all Fedora users have access to KVM, surely that should be enough -- obviously the bulk of Fedora tests is Fedora users), and it would be more difficult to test sound and 3D, which are crippled in VMs. (No one would be doing Compiz QA with this).
But then again, a live CD itself can be too slow for rigorous multimedia or graphics experience testing. At least VMs allow potentially even easier distribution and management, and you could be a flagship use of Fedora's new VM capability.
On Tue, Jun 30, 2009 at 10:00 AM, Kevin Koflerkevin.kofler@chello.at wrote:
Eli Wapniarski wrote:
Stop trying to integrate or force integration of everything into everything.
I disagree. It's important for components to work together.
And there is of yet, still no official support for pulse under wine.
But there is the WinePulse project which is what we're shipping. http://art.ified.ca/?page_id=40 If you encounter bugs with it, you need to report them.
And the reason upstream WINE refuses to merge the patch is because they want to rewrite the whole sound system and they don't want any new backends until that happens, no matter how important those new backends are. :-/ It has nothing to do with the quality of the backend.
Why should a soundserver interfere with networking?
I don't know. But there's certainly an explanation.
Right now the defacto standard Linux soundserver is alsa.
No, the de-facto standard is PulseAudio now. We aren't the only ones shipping it as the default, at least Ubuntu and Mandriva ship it too.
It's not possible to have apps only support hardware ALSA in a PulseAudio environment, they'll not work (because PulseAudio needs the sound device). The problem with WINE's ALSA backend is that it needs mmap and thus won't work with the PulseAudio ALSA plugin.
You can try the ESD backend (wine-esd), which uses PulseAudio's ESD compatibility layer (pulseaudio-esound-compat).
Please lets do what we can to not go the Redhat 8 route again. Please.
Do you have anything against Bluecurve? I still use it. :-)
Kevin Kofler
fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
Jud Craft wrote:
What if, instead of passing out Live CD images, you passed out virtual machine images?
Bad idea. The live images are also the recommended method for installation. You can't do that with a VM image. And it's perfectly possible to boot the live image in a VM.
Kevin Kofler
Right, you can use Live images in a VM. But it would simplify the barrier to entry if the image was pre-made, and I can't see how the space requirement for downloading VM image would be much larger than a live image (even if it would grow once activated).
On Tue, Jun 30, 2009 at 10:50 AM, Kevin Koflerkevin.kofler@chello.at wrote:
Jud Craft wrote:
What if, instead of passing out Live CD images, you passed out virtual machine images?
Bad idea. The live images are also the recommended method for installation. You can't do that with a VM image. And it's perfectly possible to boot the live image in a VM.
Kevin Kofler
fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
2009/6/30 Jud Craft craftjml@gmail.com:
Right, you can use Live images in a VM. But it would simplify the barrier to entry if the image was pre-made, and I can't see how the space requirement for downloading VM image would be much larger than a live image (even if it would grow once activated).
I am not really convinced that running iso in a vm is any harder than a pre-made image. I haven't taken a look at the vms available in fedora itself but vms like VirtualBox are available for most x86 based operating systems booting off an iso in there is no harder than setting your computer to boot off a cd/dvd drive and if you can't do that then you wont have much hope of actually installing afterwards. Also if you download the iso then once you decide you like it you can still boot off it and install it on your actual machine without having to download the iso seperately.
On 06/30/2009 01:07 PM, Jud Craft wrote:
Right, you can use Live images in a VM. But it would simplify the barrier to entry if the image was pre-made, and I can't see how the space requirement for downloading VM image would be much larger than a live image (even if it would grow once activated).
OK, enlighten me... to me live images are pretty easy already.
How easy is it to make a distributable VM? And then, how to give that to others, to also use easily? I assume you're taking kvm here?
Compare and contrast that workflow to the status quo.
-- Rex
My mistake, pardon me.
I did not say it was easy "to make a VM image". I have no idea. However, I do think it is easy "to distribute a VM image". It's just a big file, like any other big file, right?
The current workflow -- for most power users -- involves distributing live images, downloading them, creating new virtual machines, and then running straight from the VM-Live image, or installing the live image to the VM and using that.
My proposed workflow -- for most power users -- would then involve distributing a VM image, downloading it, and opening it. Voila.
None of that "create VM" or "install live image" stuff. It is true that these steps would be for power users, each time -- but in my case, I think it at least reduces a bit of the work, since the inevitable "make a VM step" is already done.
I think I am not deluded in that distributing a big VM file is just as easy as distributing a big ISO file. But, I am not infallible. It was just a suggestion, I figured the novelty would be obvious. If indeed it is more onerous, then I apologize for derailing the discussion.
It might be more work up front for the Test Leader, since he'd have to make a VM, but somehow I figured that making a custom LiveCD spin was just as involved. (The abstract idea involved -- make a self-contained bootable linux-filesystem -- is the same in each case).
On Tue, Jun 30, 2009 at 1:28 PM, Rex Dieterrdieter@math.unl.edu wrote:
On 06/30/2009 01:07 PM, Jud Craft wrote:
Right, you can use Live images in a VM. But it would simplify the barrier to entry if the image was pre-made, and I can't see how the space requirement for downloading VM image would be much larger than a live image (even if it would grow once activated).
OK, enlighten me... to me live images are pretty easy already.
How easy is it to make a distributable VM? And then, how to give that to others, to also use easily? I assume you're taking kvm here?
Compare and contrast that workflow to the status quo.
-- Rex _______________________________________________ fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
Jud Craft wrote:
The current workflow -- for most power users -- involves distributing live images, downloading them, creating new virtual machines, and then running straight from the VM-Live image, or installing the live image to the VM and using that.
My proposed workflow -- for most power users -- would then involve distributing a VM image, downloading it, and opening it. Voila.
You make several wrong assumptions: 1. You assume that power users all use virtualization and will use it to try the software. 2. You assume that most of our users are power users. 3. You assume that people will not want to install the system on their actual hardware after trying it in virtualization. None of these assumptions are valid.
The thing is, in the real world, people need the live CD for various reasons: testing the image on actual hardware, installing it to their actual hardware etc. So we'd end up distributing BOTH a CD ISO and a VM image, which means: * twice the amount of space needed on mirrors and * people who use your VM image to try out Fedora will have to download it all over again to actually install it!
So I really don't see the benefit when you can just boot the CD ISO in your VM. You don't even need to create a VM image in the first place. QEMU boots fine with only "-cdrom foo.iso".
Kevin Kofler
On Tue, Jun 30, 2009 at 5:49 PM, Kevin Koflerkevin.kofler@chello.at wrote:
You make several wrong assumptions:
- You assume that power users all use virtualization and will use it to try
the software. 2. You assume that most of our users are power users. 3. You assume that people will not want to install the system on their actual hardware after trying it in virtualization. None of these assumptions are valid.
The thing is, in the real world, people need the live CD for various reasons: testing the image on actual hardware, installing it to their actual hardware etc. So we'd end up distributing BOTH a CD ISO and a VM image, which means:
- twice the amount of space needed on mirrors and
- people who use your VM image to try out Fedora will have to download it
all over again to actually install it!
So I really don't see the benefit when you can just boot the CD ISO in your VM. You don't even need to create a VM image in the first place. QEMU boots fine with only "-cdrom foo.iso".
+1
-Adam
Jud Craft wrote:
Question:
What if, instead of passing out Live CD images, you passed out virtual machine images?
You know, you can fire up a VM based on a live iso you know... :) (that's how I've done the last for test days I've participated in...)
-- Rex
On Tuesday 30 June 2009 18:00:03 Kevin Kofler wrote:
Eli Wapniarski wrote:
Stop trying to integrate or force integration of everything into everything.
I disagree. It's important for components to work together.
Yes it is. And if you want things to work together then write some kind of middle example of pulseaudio crippling the entire system and I know that you personally want to see the death of it, wine with pulseaduio does not work. Remove pulse flash sound in konqueror does not happen. Gnash is nowhere near ready.
And there is of yet, still no official support for pulse under wine.
But there is the WinePulse project which is what we're shipping. http://art.ified.ca/?page_id=40 If you encounter bugs with it, you need to report them.
I did.
And the reason upstream WINE refuses to merge the patch is because they want to rewrite the whole sound system and they don't want any new backends until that happens, no matter how important those new backends are. :-/ It has nothing to do with the quality of the backend.
Why should a soundserver interfere with networking?
I don't know. But there's certainly an explanation.
Right now the defacto standard Linux soundserver is alsa.
No, the de-facto standard is PulseAudio now. We aren't the only ones shipping it as the default, at least Ubuntu and Mandriva ship it too.
It's not possible to have apps only support hardware ALSA in a PulseAudio environment, they'll not work (because PulseAudio needs the sound device). The problem with WINE's ALSA backend is that it needs mmap and thus won't work with the PulseAudio ALSA plugin.
As pulseaduio does not work without breaking other things. Which means pulseaudio breaks the sound system. Because not everythnig uses it or can use currently.
You can try the ESD backend (wine-esd), which uses PulseAudio's ESD compatibility layer (pulseaudio-esound-compat).
Does not work
Please lets do what we can to not go the Redhat 8 route again. Please.
Do you have anything against Bluecurve? I still use it. :-)
Redhat 8 integrated the menu system for both kde and gnome. The menu system used was gnome. There was nothing you could do customize the kde menu. Gnome was cirppled, KDE was crippled. And the kde - redhat community was introduced to Rex Dieter as kde-redhat was born. The work that Rex tiresleslly devoted himself made KDE work in Redhat. Anything that smelled of Gnome / KDE integration was seperated out and recompiled to break it and leave KDE independant to allow kde to function as kde. It was a long road until reintigration with Fedora proper and a commitment that kde would continue to work as well. However, we have ssen more and more with network manager, packagekit, breakage in kde and it forced a backing away from the integration probably the same is true with gnome components for policy manager ( I have not even explored it). It would seem that the same is currently true for pulse audio.
Once size does not fit all in Linux (thankfully). It never has. It probably never will.
Eli
On Tuesday 30 June 2009 20:16:42 Eli Wapniarski wrote:
I disagree. It's important for components to work together.
Yes it is. And if you want things to work together then write some kind of middle example of pulseaudio crippling the entire system and I know that you personally want to see the death of it, wine with pulseaduio does not work. Remove pulse flash sound in konqueror does not happen. Gnash is nowhere near ready.
Let that be a lesson to you folks. Never write an email that requires thinking while rushing out the door. Sorry about the lack of coherence here.
Let me get my thoughts straight.
Yes it is important. So write some middleware that works, but don't have applications completely dependent on something that simply doesn't need to be there to run. From my standpoint (let me be clear here if it works for you great. All the power to you) pulseaudio is horribly buggy software with obvious promise, but not really ready for prime time.
Here is an example of how pulseaudio cripples my system. I run KDE and KDM. With pulseaudio installed in the system pulseaudio automatically runs in the background. With a MMORPG that I run under wine I can't connect to the network unless I completely kill pulseaudio. Phonon does not need pulseaudio to run so I remove pulseaudio except for the libraries otherwise I would be forced to uninstall half my computer and probably completely break it due unnecessary dependencies. Now I run Konqueror with nspluginwrapper and flash 32bit plugin because I'm running Fedora 11 x86_64 and the Beta 64 flash plugin crashes continuously. I go to youtube and guess what. No sound.
I know Kevin. Flash is proprietary, but Gnash is nowhere near ready for prime time and in Fedora once again depends on pulseaudio; including the Gnash-Kash plugin. And while video works with youtube. Once again. No sound. Why???? pulseaudio is not installed.
The is the definition of ARRRRGGGHH or Doh. Depending on your generation :).
Eli
On 06/30/2009 03:04 PM, Eli Wapniarski wrote:
On Tuesday 30 June 2009 20:16:42 Eli Wapniarski wrote:
I disagree. It's important for components to work together.
Yes it is. And if you want things to work together then write some kind of middle example of pulseaudio crippling
My first and last comment on this thread, and then I'd like to ask folks to just chill a bit.
FACT: There are a small (gladly) subset of systems, drivers, apps that, unfortunately, for one reason or another (I'm not assigning blame), that do not interoperate well with pulseaudio. Note, I am not assigning blame, and neither should you.
Want to read more?
My experience tells me that most of the "problems" are due to driver bugs or application bugs, not PA. Does removing PA workaround the problems? Sometimes, but that's not fixing the inherent issues.
Now, if folks have problems and are genuinely interested in *constructively* finding solutions, I'm all for that. TOTALLY. But drawing broad (and trollish) conclusions based on anecdotal evidence, please well, I don't know what. I'm at a loss. Just makes me sad. I know we all can do better than that.
-- Rex
On Tuesday 30 June 2009 23:25:44 Rex Dieter wrote:
On 06/30/2009 03:04 PM, Eli Wapniarski wrote:
On Tuesday 30 June 2009 20:16:42 Eli Wapniarski wrote:
I disagree. It's important for components to work together.
Yes it is. And if you want things to work together then write some kind of middle example of pulseaudio crippling
Last things first. Not attempting to troll or for people to start attacking each other really. If that's how this is being interpreted then I apologize. Just expressing frustration with software.
My first and last comment on this thread, and then I'd like to ask folks to just chill a bit.
FACT: There are a small (gladly) subset of systems, drivers, apps that, unfortunately, for one reason or another (I'm not assigning blame), that do not interoperate well with pulseaudio. Note, I am not assigning blame, and neither should you.
Want to read more?
My experience tells me that most of the "problems" are due to driver bugs or application bugs, not PA. Does removing PA workaround the problems? Sometimes, but that's not fixing the inherent issues.
Forgive me but I gotta ask... Are the drivers for the sound card in pulseaudio or the kernel or somewhere else?
Now, if folks have problems and are genuinely interested in *constructively* finding solutions, I'm all for that. TOTALLY. But drawing broad (and trollish) conclusions based on anecdotal evidence, please well, I don't know what. I'm at a loss. Just makes me sad. I know we all can do better than that.
I've already filed a bug report with the wine packagers. What else is there to do?
Eli
2009/6/30 Eli Wapniarski eli@orbsky.homelinux.org:
Forgive me but I gotta ask... Are the drivers for the sound card in pulseaudio or the kernel or somewhere else?
The drivers are in the kernel. The real issue is that a lot of drivers simply have bugs. pulseudio pushes the drivers quite hard in various ways and it is exposing bugs or deficiencies that weren't seen before (in the same way that kde exposed a lot of bugs in graphics drivers that weren't really an issue before). pulseaudio isn't without its bugs but a lot more bugs are attributed to it than are really justified. As for application compatibility it is largely a case of applications relying on implementation details of alsa which means that when the implementation changes (pulseaudion rather than alsa itself) it fails. Certainly applications like skype suffered for this reason for a long time.
There is also a problem that a lot of these drivers are being written by people who either don't have the sound card it's self or don't have the specs for how it works. The real problem with many of the drivers in the kernel (not just audio) at the moment is that they aren't being developed / maintained by the companies who make the hardware. For this to scale properly, the hardware vendors really ought to be maintaining their particular driver however I do believe the majority of drivers aren't done this way.
On Wed, Jul 1, 2009 at 7:48 AM, John5342john5342@googlemail.com wrote:
2009/6/30 Eli Wapniarski eli@orbsky.homelinux.org:
Forgive me but I gotta ask... Are the drivers for the sound card in pulseaudio or the kernel or somewhere else?
The drivers are in the kernel. The real issue is that a lot of drivers simply have bugs. pulseudio pushes the drivers quite hard in various ways and it is exposing bugs or deficiencies that weren't seen before (in the same way that kde exposed a lot of bugs in graphics drivers that weren't really an issue before). pulseaudio isn't without its bugs but a lot more bugs are attributed to it than are really justified. As for application compatibility it is largely a case of applications relying on implementation details of alsa which means that when the implementation changes (pulseaudion rather than alsa itself) it fails. Certainly applications like skype suffered for this reason for a long time.
-- There are 10 kinds of people in the world: Those who understand binary and those who don't... _______________________________________________ fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
On Tuesday 30 June 2009 23:25:44 Rex Dieter wrote:
FACT: There are a small (gladly) subset of systems, drivers, apps that, unfortunately, for one reason or another (I'm not assigning blame), that do not interoperate well with pulseaudio. Note, I am not assigning blame, and neither should you.
Actually... This is the core issue alot of the discussion that follows is indeed OT.
If anyone wants to help to try to do more triage with the bug I reported it can be found at:
https://bugzilla.redhat.com/show_bug.cgi?id=507589
(Not a promo - By the way... the game I mention in the bug report is a lovely MMORPG with some of the nicest graphics I've seen anywhere).
The key thought here is that are things like pulseaudio that mostly works but it does not work completely. My particular feeling is that in Fedora's enthusiasm (maybe over enthusiasm) to embrace the new stuff; and (indeed, that's why we're here at Fedora) we forget that it takes sometime for other projects to catch up and this in turn effects interoperablity which in turn has an impact on the user's experience. In the example being discussed wine and pulseaudio is one such example and with an impact on major subsystems such as wine.
Now... it has been noted that the wine project is actively rewriting their sound subsystem which will also be embracing pulseaudio, probably for the better. But in the meantime I've got this funny networking problem with the game where if pulseaudio is running the game simply does not connect to the games servers. pasuspend does not work. Killing pulseaudio is the only way I was able to get the game to connect to its servers. But doing that breaks other things and this impacts once again negatively on the users experience.
I guess what I'm trying to say is that one of the things that can be done to "raise the bar" is to try to be more certain that things work not just mostly works. If a project is alive and advancing then some accommodation should be made to ensure that it works; especially with major subsystems like wine. If the project seems to be dead, then well (maybe) it should be excluded.
Any additional thoughts are surely welcome. I leave the floor open and will keep my keyboard to myself from this point forward regarding this topic.
Eli
Seeing where things break is often the motivation that is needed in order to get things fixed. KDE and xorg is a good example. People in xorg new that certain functions in the graphics drivers were not working correctly but no one was using them so they don't become a priority. Pushing the boundaries exposes those weaker areas and makes the whole experience stronger for the whole community.
Also you mentioned wine is not compatible in this scenario but are there any free as in libre applications that developers can test this with? I personally don't have any proprietary applications that I would be able to test wine with.
Andrew
On Wed, Jul 1, 2009 at 2:35 PM, Eli Wapniarskieli@orbsky.homelinux.org wrote:
On Tuesday 30 June 2009 23:25:44 Rex Dieter wrote:
FACT: There are a small (gladly) subset of systems, drivers, apps that, unfortunately, for one reason or another (I'm not assigning blame), that do not interoperate well with pulseaudio. Note, I am not assigning blame, and neither should you.
Actually... This is the core issue alot of the discussion that follows is indeed OT.
If anyone wants to help to try to do more triage with the bug I reported it can be found at:
https://bugzilla.redhat.com/show_bug.cgi?id=507589
(Not a promo - By the way... the game I mention in the bug report is a lovely MMORPG with some of the nicest graphics I've seen anywhere).
The key thought here is that are things like pulseaudio that mostly works but it does not work completely. My particular feeling is that in Fedora's enthusiasm (maybe over enthusiasm) to embrace the new stuff; and (indeed, that's why we're here at Fedora) we forget that it takes sometime for other projects to catch up and this in turn effects interoperablity which in turn has an impact on the user's experience. In the example being discussed wine and pulseaudio is one such example and with an impact on major subsystems such as wine.
Now... it has been noted that the wine project is actively rewriting their sound subsystem which will also be embracing pulseaudio, probably for the better. But in the meantime I've got this funny networking problem with the game where if pulseaudio is running the game simply does not connect to the games servers. pasuspend does not work. Killing pulseaudio is the only way I was able to get the game to connect to its servers. But doing that breaks other things and this impacts once again negatively on the users experience.
I guess what I'm trying to say is that one of the things that can be done to "raise the bar" is to try to be more certain that things work not just mostly works. If a project is alive and advancing then some accommodation should be made to ensure that it works; especially with major subsystems like wine. If the project seems to be dead, then well (maybe) it should be excluded.
Any additional thoughts are surely welcome. I leave the floor open and will keep my keyboard to myself from this point forward regarding this topic.
Eli
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
On Wednesday 01 July 2009 10:13:59 Andrew Mason wrote:
Also you mentioned wine is not compatible in this scenario but are there any free as in libre applications that developers can test this with? I personally don't have any proprietary applications that I would be able to test wine with.
You could always download and install the game. It is free to play.
Eli
Eli Wapniarski wrote:
So, first of all, there's no evidence of the problem being networking and/or PulseAudio at all, it looks more like NVidia driver breakage.
Plus, you're also seeing this with other WINE sound drivers (you said in the bug report you tried the ALSA driver and here you tried the ESD driver), so it can't really be WinePulse's fault. If this is really networking, it may be something mundane like a TCP port conflict (i.e. PulseAudio's TCP server using the port your game wants to use).
Kevin Kofler
On Wednesday 01 July 2009 17:49:33 Kevin Kofler wrote:
Eli Wapniarski wrote:
So, first of all, there's no evidence of the problem being networking and/or PulseAudio at all, it looks more like NVidia driver breakage.
Actually no.... not yet. The dual screen problem seems to be a problem with opengl and xorg 1.6.1. Two things point to that. The problem I'm having and documented in the console output attached there is reference to problems with opengl. To further this there is a thread in this mailinglist documenting other opengl issues. Besides I've managed to work around the xorg and game crashes by confining the game to 1 of my 2 monitors. I know that Nvidia has been a favorite whipping boy of late. However, xorg has been bedeviled with problems with Xinerama issues and other issues with Twinview. The problems that have been reproted here plus my problem leads me to think an exploration of the possibility of some regression issues are in order. I know that xorg 1.5.3 is not 1.6.1, however everything worked wonderfully in Fedora 10 with the same drivers. So, there is no conclusive evidence that this is an Nvidia problem yet.
Regarding the networking issues as documented in the bug report its not that sound is not working. Its that I don't get to find out if sound is working or not. With pulseaudion (not wine-pulseaudio) running the game does not connect to the game servers. When I kill pulseaudio it does. No kidding as bizarre as it sounds that's whats happening.
Plus, you're also seeing this with other WINE sound drivers (you said in the bug report you tried the ALSA driver and here you tried the ESD driver), so it can't really be WinePulse's fault. If this is really networking, it may be something mundane like a TCP port conflict (i.e. PulseAudio's TCP server using the port your game wants to use).
No... I'm not seeing the networking issues with other drivers. However, I do not seem to be able to feed sound through any other driver including OSS with it enabled in modules.d. Now how do I configure PulseAudio's TCP server to use a different tcp port or can I or should I? I certainly wouldn't be able to change the port the game uses.
Thanks for helping me to look further into this.
Eli
On Wednesday 01 July 2009 20:19:08 Eli Wapniarski wrote:
No... I'm not seeing the networking issues with other drivers. However, I do not seem to be able to feed sound through any other driver including OSS with it enabled in modules.d. Now how do I configure PulseAudio's TCP server to use a different tcp port or can I or should I? I certainly wouldn't be able to change the port the game uses.
Thanks for helping me to look further into this.
Oh... I need to make a small correction. Sound does work when using the alsa driver in wine. But of course... with pulseaudio not running.
Eli
Eli Wapniarski wrote:
Here is an example of how pulseaudio cripples my system. I run KDE and KDM. With pulseaudio installed in the system pulseaudio automatically runs in the background. With a MMORPG that I run under wine I can't connect to the network unless I completely kill pulseaudio. Phonon does not need pulseaudio to run so I remove pulseaudio except for the libraries otherwise I would be forced to uninstall half my computer and probably completely break it due unnecessary dependencies. Now I run Konqueror with nspluginwrapper and flash 32bit plugin because I'm running Fedora 11 x86_64 and the Beta 64 flash plugin crashes continuously. I go to youtube and guess what. No sound.
Well, there are at least 2 possible causes: 1. the sound device is busy, so Flash can't open it. Guess what, that's what PulseAudio is for! 2. you uninstalled PulseAudio without uninstalling alsa-plugins-pulseaudio, so your ALSA apps are still trying to talk to PulseAudio. That won't work, of course.
There may be some other explanation.
Kevin Kofler
On Wednesday 01 July 2009 02:14:01 Kevin Kofler wrote:
- you uninstalled PulseAudio without uninstalling alsa-plugins-pulseaudio,
so your ALSA apps are still trying to talk to PulseAudio. That won't work, of course.
Nope
rpm -qa | grep pulse pulseaudio-libs-0.9.15-14.fc11.x86_64 pulseaudio-libs-glib2-0.9.15-14.fc11.x86_64 pulseaudio-libs-0.9.15-14.fc11.i586 wine-pulseaudio-1.1.23-1.fc11.i586
Eli
Eli Wapniarski wrote:
You can try the ESD backend (wine-esd), which uses PulseAudio's ESD compatibility layer (pulseaudio-esound-compat).
Does not work
It does work for me. I tested it with the Window$ version of TiEmu and sound worked just fine.
Redhat 8 integrated the menu system for both kde and gnome.
And it was about time they did that. Having only KDE apps show up in the KDE menu was really broken (and kappfinder was a lousy workaround). I don't miss the times where you had to register any application twice for it to show up in both desktops' menus. The shared freedesktop.org menu is what we have now. Nobody complains about it anymore.
There was nothing you could do customize the kde menu.
That's not true, kmenuedit was always shipped.
The work that Rex tiresleslly devoted himself made KDE work in Redhat. Anything that smelled of Gnome / KDE integration was seperated out and recompiled to break it and leave KDE independant to allow kde to function as kde. It was a long road until reintigration with Fedora proper and a commitment that kde would continue to work as well.
I've been using Than's packages until the merge, I've never had any real problems with them and there was no such "GNOME / KDE integration" which wasn't also upstream and in kde-redhat. I was also there when the merge happened, there wasn't any "GNOME / KDE integration" being removed. There were some default settings which differed among the 2 builds (I did a diff of the 2 versions of the settings and we discussed the changes, but they were nothing major, both package sets mostly used the upstream defaults), a few useful patches missing in one or the other package set and the occasional optional component enabled only in kde-redhat, but the major differences people kept talking about did not actually exist.
However, we have ssen more and more with network manager,
Should be fixed now (F9/F10/F11 updates, F12 Rawhide) with kde-plasma-networkmanagement. The actual issue there was lack of integration (forcing us to fallback to a GNOME component), not too much integration.
packagekit
Fixed in F9 updates and F10 (and everything newer) with kpackagekit. Once again, lack of integration forced the temporary use of a GNOME component (which replaced our older distro-specific and also GTK+-based tools, so this wasn't really a regression), the problem is now solved.
probably the same is true with gnome components for policy manager
You probably mean PolicyKit. We ship PolicyKit-kde in F11. There too, the GNOME component is no longer needed thanks to our integration work. (That said, we need to do more of this for F12 due to PolicyKit 1.)
It would seem that the same is currently true for pulse audio.
PulseAudio just works in KDE 4. Your issues with PulseAudio have nothing to do with KDE.
Kevin Kofler
On Wednesday 01 July 2009 02:10:36 Kevin Kofler wrote:
Redhat 8 integrated the menu system for both kde and gnome.
And it was about time they did that. Having only KDE apps show up in the KDE menu was really broken (and kappfinder was a lousy workaround). I don't miss the times where you had to register any application twice for it to show up in both desktops' menus. The shared freedesktop.org menu is what we have now. Nobody complains about it anymore.
There was nothing you could do customize the kde menu.
That's not true, kmenuedit was always shipped.
Shipped but did not work. Couldn't edit a thing until Rex showed up.
Eli
Eli Wapniarski wrote:
Shipped but did not work. Couldn't edit a thing until Rex showed up.
Hmmm, I do remember some pretty bad experiences with kmenuedit in the past, I ended up editing my menus in ~/.local by hand most of the time.
Kevin Kofler
Kevin Kofler wrote:
Eli Wapniarski wrote:
Shipped but did not work. Couldn't edit a thing until Rex showed up.
Hmmm, I do remember some pretty bad experiences with kmenuedit in the past, I ended up editing my menus in ~/.local by hand most of the time.
Yeah, there was some loosie-goosie XDG menu hackery going on back then, I recall. We got it sorted it eventually.
-- Rex
-
Adam Miller -
Andrew Mason -
Arthur Pemberton -
Eli Wapniarski -
Jaroslav Reznik -
John5342 -
Jud Craft -
Kevin Kofler -
Rex Dieter