While at FUDCon back in Dec, it occurred to me to come up with 1. some specs and requirements to use as objective criteria when it comes to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications: 1. It's inevitably a FAQ about "why did you include app <foo> instead of <bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to: 1. packagekit frontend/integration 2. networkmanager frontend 3. bluetooth device support 4. phonon backend 5. anything else you can think of...
Thanks.
-- Rex
Rex Dieter wrote:
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
- networkmanager frontend
- bluetooth device support
- phonon backend
- anything else you can think of...
I don't know, as a day-to-day home computer user, what I can suggest that might be useful, but, off the top of my head:
1. packagekit: I did not particularly like the one version a while back that relied on smart. It never worked. Then there was another version, which appeared to be the same program (very confusing) that integrated into the system-settings. Neither did anything. What I find missing in all of these package managers is the ability to explore the repositories. Package management is not simply about updating installed software, but also about perusing the repo and discovering other programs one might like to install. Way back in kde2 or kde3, there used to be such a program (I don't recall if it was an apt frontend, or what it was) that allowed one to click on every available program and be shown a description of the program, all of the files it provided and all of the dependencies required. This type of package management is sorely lacking. One should be able to find packages, not just in groups, like games, development, etc., but also individually. Yes, the list would be many thousands long, but when you don't know what it is called, you don't know what it does and you don't even know that it exists until you spot it, how can you search for it? RPMfusion at least offers repoview, but fedoraproject no longer does (or if it does, it is impossible to view, because you are always automatically directed to some mirror site that doesn't implement it).
2. networkmanager: the gnome icon in the system tray works splendidly here. Does absolutely everything have to be duplicated? But, if it does, then I would think it should be, at a minimum, as functional as the current system. I like it in the system tray, as having a plasmoid for this uses up too much space on the panel.
3. bluetooth: I have never had any bluetooth devices, so it would be hard to comment, but they should be automatically detected both when they are present and when they get out of range/are removed. I definitely dislike any kind of system that allows only root to mount/unmount or attach and remove devices. If I plug a device in, then I should be able to use it. It's my computer!
4. phonon: I prefer xine, but ultimately what is important is that it be able to play any file I encounter.
5. ? This is always the hardest question. I am sure I have a gripe somewhere, but it evades me. I think we could take that as meaning that things are really very good ;-) Reading some other comments might jog my memory. No set-up and just works are important to me in every aspect of computer use (although I do highly value the intricate set-up capabilities of kde, when I feel like customizing to get it just so).
I hope this helps.
On 01/18/2010 11:07 AM, Petrus de Calguarium wrote:
Rex Dieter wrote:
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
- networkmanager frontend
- bluetooth device support
- phonon backend
- anything else you can think of...
I don't know, as a day-to-day home computer user, what I can suggest that might be useful, but, off the top of my head:
- packagekit: I did not particularly like the one version a while back that relied
on smart.
:) don't confuse kdeadmin-kpackage (what you describe) with kpackagekit. They happen to share a lot of letters in their names, but that's about it.
-- Rex
Petrus de Calguarium wrote:
Rex Dieter wrote:
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
- networkmanager frontend
- bluetooth device support
- phonon backend
- anything else you can think of...
I don't know, as a day-to-day home computer user, what I can suggest that might be useful, but, off the top of my head:
- packagekit: I did not particularly like the one version a while back that relied
on smart. It never worked. Then there was another version, which appeared to be the same program (very confusing) that integrated into the system-settings. Neither did anything. What I find missing in all of these package managers is the ability to explore the repositories. Package management is not simply about updating installed software, but also about perusing the repo and discovering other programs one might like to install. Way back in kde2 or kde3, there used to be such a program (I don't recall if it was an apt frontend, or what it was) that allowed one to click on every available program and be shown a description of the program, all of the files it provided and all of the dependencies required. This type of package management is sorely lacking. One should be able to find packages, not just in groups, like games, development, etc., but also individually. Yes, the list would be many thousands long, but when you don't know what it is called, you don't know what it does and you don't even know that it exists until you spot it, how can you search for it?
Smart does all that. Its predecessor was Synaptic. I've used them since ~FC3.
RPMfusion at least offers repoview, but fedoraproject no longer does (or if
it does, it is impossible to view, because you are always automatically directed to some mirror site that doesn't implement it).
- networkmanager: the gnome icon in the system tray works splendidly here. Does
absolutely everything have to be duplicated? But, if it does, then I would think it should be, at a minimum, as functional as the current system. I like it in the system tray, as having a plasmoid for this uses up too much space on the panel.
- bluetooth: I have never had any bluetooth devices, so it would be hard to
comment, but they should be automatically detected both when they are present and when they get out of range/are removed. I definitely dislike any kind of system that allows only root to mount/unmount or attach and remove devices. If I plug a device in, then I should be able to use it. It's my computer!
- phonon: I prefer xine, but ultimately what is important is that it be able to
play any file I encounter.
- ? This is always the hardest question. I am sure I have a gripe somewhere, but
it evades me. I think we could take that as meaning that things are really very good ;-) Reading some other comments might jog my memory. No set-up and just works are important to me in every aspect of computer use (although I do highly value the intricate set-up capabilities of kde, when I feel like customizing to get it just so).
I hope this helps.
Petrus de Calguarium wrote:
- packagekit: I did not particularly like the one version a while back
that relied on smart. It never worked.
That was KPackage, not KPackageKit. Completely different program.
What I find missing in all of these package managers is the ability to explore the repositories.
Well, KPackageKit allows you to do searches. What's missing is getting a list of all packages. The groups it offers are not exhaustive (as they come from comps, then are modified at PackageKit level, but in any case they don't cover everything in the repo). But I don't think gnome-packagekit allows that either and I don't think there are any alternatives being considered at this time. (IMHO gnome-packagekit is not an option.)
- networkmanager: the gnome icon in the system tray works splendidly
here. Does absolutely everything have to be duplicated? But, if it does, then I would think it should be, at a minimum, as functional as the current system. I like it in the system tray, as having a plasmoid for this uses up too much space on the panel.
The current KNM is a systray icon and it is fully functional AFAICT. It just works for me. I don't see why we'd continue shipping NM-gnome. That was just a temporary workaround when KNM wasn't working properly yet.
I think we should keep in mind that we are a *KDE* spin, we shouldn't pollute the spin with GNOME apps unless there's really no KDE option. If the KDE app is not good enough, we need to get the KDE app improved, not ship the GNOME one. I'd see switching back from a KDE app to a GNOME one as a regression.
A big issue is that if we work on integrating the GNOME apps into the KDE spin, we end up doing things like removing OnlyShowIn/NotShowIn which in turn makes life a PITA for those folks who really want the KDE option. E.g. if we enable gnome-packagekit in KDE (which it currently is not), then people can't use KPackageKit properly anymore unless they either remove gnome-packagekit (which can break dependencies depending on what they have installed, and is also not an option on a multi-user system with GNOME users) or manually edit its .desktop file (which gets clobbered on gnome- packagekit updates and which also breaks DeltaRPMs for gnome-packagekit, so it's not something we should encourage). We already had that problem when we wanted to offer KPackageKit for F9, we couldn't make it the default due to this issue. (IIRC, rpm -e gnome-packagekit is what I did on my F9 systems to solve the problem. But as I explained, it's not an option for everyone.) So we'd be doing a big disservice to the people (like me) who want to run a pure KDE. (I'm fine with using GNOME/GTK+ apps where they are the only (or the only Free as in speech, e.g. I'll take Ekiga over Skype any day!) option, but not where there is a functional KDE app which integrates much better available. Especially system-related services like package management and Bluetooth really need an application which works together with the rest of the desktop. For example, gnome-bluetooth tries to use things like gio/gvfs, which is not appropriate in KDE.)
Kevin Kofler
Kevin Kofler wrote:
A big issue is that if we work on integrating the GNOME apps into the KDE spin, we end up doing things like removing OnlyShowIn/NotShowIn which in turn makes life a PITA for those folks who really want the KDE option. E.g. if we enable gnome-packagekit in KDE (which it currently is not), then people can't use KPackageKit properly anymore unless they either remove gnome-packagekit (which can break dependencies depending on what they have installed, and is also not an option on a multi-user system with GNOME users) or manually edit its .desktop file (which gets clobbered on gnome- packagekit updates and which also breaks DeltaRPMs for gnome-packagekit, so it's not something we should encourage). We already had that problem when we wanted to offer KPackageKit for F9, we couldn't make it the default due to this issue. (IIRC, rpm -e gnome-packagekit is what I did on my F9 systems to solve the problem. But as I explained, it's not an option for everyone.) So we'd be doing a big disservice to the people (like me) who want to run a pure KDE. (I'm fine with using GNOME/GTK+ apps where they are the only (or the only Free as in speech, e.g. I'll take Ekiga over Skype any day!) option, but not where there is a functional KDE app which integrates much better available. Especially system-related services like package management and Bluetooth really need an application which works together with the rest of the desktop. For example, gnome-bluetooth tries to use things like gio/gvfs, which is not appropriate in KDE.)
You raise an interesting scenario that I had never considered:
I also like the idea of having a pure KDE system. Now, were I to achieve that on my system, what would happen if I were to create a second user account for myself and use only Gnome apps? Would that be possible on the same computer? You kind of went into that above, but I got a bit tangled in it all. Could you elucidate?
Petrus de Calguarium wrote:
You raise an interesting scenario that I had never considered:
I also like the idea of having a pure KDE system. Now, were I to achieve that on my system, what would happen if I were to create a second user account for myself and use only Gnome apps? Would that be possible on the same computer? You kind of went into that above, but I got a bit tangled in it all. Could you elucidate?
Well, if we keep the setup where KDE services like KPackageKit get started in KDE and GNOME services like gnome-packagekit get started in GNOME, it'll work fine. (E.g. it should be working fine at this time.) If we start running GNOME stuff in KDE when it's installed (because we decide the KDE app is "not good enough" to be the default), then we have a problem.
Another issue is D-Bus activation when several implementations of the same service exist, e.g. for the PackageKit service which is called for on-demand installation of fonts, printer drivers etc., but that issue is not related to the default apps discussion and needs to be addressed separately (probably in D-Bus).
Kevin Kofler
Kevin Kofler wrote:
Well, if we keep the setup where KDE services like KPackageKit get started in KDE and GNOME services like gnome-packagekit get started in GNOME, it'll work fine.
Ok, that makes sense. I am glad that this works. I am not actually a gnome user or fan, but while KDE was going through some rough growing pains earlier last year, I sometimes had to resort to Gnome for a day or two (luckily no longer :).
Another issue is D-Bus activation when several implementations of the same service exist, e.g. for the PackageKit service which is called for on-demand installation of fonts, printer drivers etc., but that issue is not related to the default apps discussion and needs to be addressed separately (probably in D-Bus).
Well, you've gotten a bit deep for me here, but I guess this means that it should work, in theory, even from a D-BUS perspective, and if it doesn't yet, it will down the road.
Now, I got to thinking again:
Would I have to create a second user account for myself to keep this all separate, or would it be sufficient for me to simply log in to KDE one time, then into Gnome another time, using only one user account and having KDM take care of the difference?
On Mon, Jan 18, 2010 at 7:11 AM, Rex Dieter rdieter@math.unl.edu wrote:
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
no opinion, skipping
- networkmanager frontend
no opinion, skipping
- bluetooth device support
KBluetoot just barely works, gnome-bluetooth had the usual dep. tree problem, but it at least works
- phonon backend
no opinion, skipping
- anything else you can think of...
Not sure if this is a good place to ask: but I would really like to see fpaste in the default KDE spin. It's value/size ratio is very high in my opinion
On 01/18/2010 09:11 AM, Rex Dieter wrote:
While at FUDCon back in Dec, it occurred to me to come up with
- some specs and requirements to use as objective criteria when it comes
to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications:
- It's inevitably a FAQ about "why did you include app<foo> instead of
<bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
No comment, use yum.
- networkmanager frontend
I like knetworkmanager
- bluetooth device support
No comment.
- phonon backend
Xine backend has always worked well for me.
- anything else you can think of...
Thanks.
-- Rex
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 01/18/2010 12:40 PM, Patrick Boutilier wrote:
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
No comment, use yum.
- networkmanager frontend
I like knetworkmanager
To be clear (and sorry if I wasn't), I'm not soliciting app suggestions. We're not at that stage yet. What we want is a list of requirements for said apps. Once we have that, then we can do testing, and solicit feedback for specific features to be able to objectively compare candidate apps to see which ones can best server our needs.
(hint: obviously, we'll give a slight nod to stuff being qt/kde based... integration/usability has to count for something).
-- Rex
On Mon, 2010-01-18 at 07:11 -0600, Rex Dieter wrote:
While at FUDCon back in Dec, it occurred to me to come up with
- some specs and requirements to use as objective criteria when it comes
to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications:
- It's inevitably a FAQ about "why did you include app <foo> instead of
<bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
I had a lot of issues with kpackagekit hanging / reporting a successful installation while back-end is stilling downloading, etc. How much love is getting from upstream?
- networkmanager frontend
I found the gnome-networkmanager worked better for me. Somehow the interface worked better. (HID wise.) However, I've yet to install F12 on a laptop, so I can't really comment on the latest knetworkmanager front-end.
- bluetooth device support
Given the lack of love kbluetooth is getting from upstream, I'd ship gnome-bluetooth instead.
- phonon backend
I had better luck with xine. Though, no idea if it means anything to anyone else. (I've got 3 sound cards...)
P.S. Kudos for a getting a reliable pulse integration!
- anything else you can think of...
Map activity to each virt.desktop by default? (Should more-or-less work out of the box by 4.4GA.)
- Gilboa
On Mon, 2010-01-18 at 20:57 +0200, Gilboa Davara wrote:
- anything else you can think of...
Map activity to each virt.desktop by default? (Should more-or-less work out of the box by 4.4GA.)
- Gilboa
One last thing. Working GTK integration out of the box. I'd love to stop mocking around with ~/.gtkrc-2.0 just to get GTK applications (firefox, evolution) looking like native KDE applications. (gtk-qt-engine never really worked reliably for me, same goes for qtcurve-gtk...)
- Gilboa
Gilboa Davara wrote:
I had a lot of issues with kpackagekit hanging / reporting a successful installation while back-end is stilling downloading, etc. How much love is getting from upstream?
The current brokenness is getting sorted out, e.g. there are fixes for the kded4 crashes.
I found the gnome-networkmanager worked better for me. Somehow the interface worked better. (HID wise.) However, I've yet to install F12 on a laptop, so I can't really comment on the latest knetworkmanager front-end.
If what you used was the plasmoid then, well, the current KNM is completely different.
It also fixes the missing features from older KNM snapshots. I really don't see why we'd continue shipping NM-gnome in a KDE spin. KNM just works these days. (I'm using it in F12 with no issues.)
Given the lack of love kbluetooth is getting from upstream, I'd ship gnome-bluetooth instead.
We don't have room on the live CD for that. IMHO it's either kbluetooth or no Bluetooth support at all.
Kevin Kofler
On Monday 18 January 2010 13:11:38 Rex Dieter wrote:
While at FUDCon back in Dec, it occurred to me to come up with
- some specs and requirements to use as objective criteria when it comes
to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications:
- It's inevitably a FAQ about "why did you include app <foo> instead of
<bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
Have rarely used it, but it seems OK.
- networkmanager frontend
I have not been able to see anything useful there for a long time. Currently it tells me that my network is unavailable, although I'm working on-line quite happily.
I would like to see available networks, wired and wireless, and statistics about my actual connection - particularly speed and wireless signal strength. Some time ago I tried wicd with Mandriva, and that was the best front-end I've seen.
- bluetooth device support
No experience of it.
- phonon backend
The xine backend worked perfectly for me under F11, but is broken under F12 + KDE 4.3.90. Consequently I have several sound problems. #Note to self - search bugzilla.
I would like to see the UI showing available devices, and an indication of which device is being used. Related, I think - I would like KMix to show my channels again, instead of simply Internal Audio Analog Stereo, as it does at present.
- anything else you can think of...
Most things seem to be fine, thanks.
Anne
On Monday 18 January 2010 07:11:38 am Rex Dieter wrote:
While at FUDCon back in Dec, it occurred to me to come up with
- some specs and requirements to use as objective criteria when it comes
to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications:
- It's inevitably a FAQ about "why did you include app <foo> instead of
<bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
not randomly crashing
- networkmanager frontend
working openvpn/vpnc support
- bluetooth device support
working pairing to all devices. right now to to pair a bluetooth headset i have to log into gnome. pair then log back into kde. it works fine once paired.
- phonon backend
- anything else you can think of...
On Monday 18 January 2010 14:11:38 Rex Dieter wrote:
While at FUDCon back in Dec, it occurred to me to come up with
- some specs and requirements to use as objective criteria when it comes
to choices about default applications in fedora-kde. 2. general wishlist/todo items to make better
https://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
In general, these are items that are doable in the F13-development timeframe.
I have a couple of ulterior motives when it comes to requirements and default applications:
- It's inevitably a FAQ about "why did you include app <foo> instead of
<bar>?" 2. I'm disgruntled about a couple of our current default choices (*cough* kbluetooth, kpackagekit *cough*), and would like to explore other possibilities
So, please comment on what you consider to be core requirements when it comes to:
- packagekit frontend/integration
1. Information about it's usage/solving problems (aka '(K)Packagekit Handbook'); 2. where package x is coming from (from what repo); 3. an option to add/remove repo's; 4. some sort of 'advanced option' where I can enter 'low level options' for yum per session. (e.g. --skip-broken); ...
- networkmanager frontend
1. Information about it's usage/solving problems (aka '(K)NetworkManager Handbook');
- bluetooth device support
- phonon backend
1. There is a handbook but ... :-)
- anything else you can think of...
Information about configuration options per application (see discussion on the mailing list 'List of kde configuration options available?')
Martin Kho
Thanks.
-- Rex
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
[sorry for the misthreaded message, due to the all-too-common "Gmane doesn't show messages sent to the new address" issue]
Anne Wilson wrote:
I would like to see the UI showing available devices, and an indication of which device is being used. Related, I think - I would like KMix to show my channels again, instead of simply Internal Audio Analog Stereo, as it does at present.
export KMIX_PULSEAUDIO_DISABLE=1 somewhere in your startup scripts.
Sadly, KMix doesn't support showing both ALSA and PA items at the same time, and PA doesn't want to offer all those ALSA controls. :-( (I wonder if it would be possible to write a PA module which gets PA to offer them. But Lennart won't like that, I guess.)
Kevin Kofler
On Tuesday 19 January 2010 07:12:31 Kevin Kofler wrote:
[sorry for the misthreaded message, due to the all-too-common "Gmane doesn't show messages sent to the new address" issue]
Anne Wilson wrote:
I would like to see the UI showing available devices, and an indication of which device is being used. Related, I think - I would like KMix to show my channels again, instead of simply Internal Audio Analog Stereo, as it does at present.
export KMIX_PULSEAUDIO_DISABLE=1 somewhere in your startup scripts.
Sadly, KMix doesn't support showing both ALSA and PA items at the same time, and PA doesn't want to offer all those ALSA controls. :-( (I wonder if it would be possible to write a PA module which gets PA to offer them. But Lennart won't like that, I guess.)
Hear, hear... I had to use gmixer to get my sound system to work properly on 2 installations. And I think that that's more sad.
Eli
On Tuesday 19 January 2010 05:12:31 Kevin Kofler wrote:
[sorry for the misthreaded message, due to the all-too-common "Gmane doesn't show messages sent to the new address" issue]
Anne Wilson wrote:
I would like to see the UI showing available devices, and an indication of which device is being used. Related, I think - I would like KMix to show my channels again, instead of simply Internal Audio Analog Stereo, as it does at present.
export KMIX_PULSEAUDIO_DISABLE=1 somewhere in your startup scripts.
If that's the only way, I'll do it, but I'm reluctant. PA has so much promise.
Sadly, KMix doesn't support showing both ALSA and PA items at the same time, and PA doesn't want to offer all those ALSA controls. :-( (I wonder if it would be possible to write a PA module which gets PA to offer them. But Lennart won't like that, I guess.)
In versions earlier than this I occasionally got 'PA not working, falling back to Intel....' type messages, but everything worked, so I don't know what changed recently. Colin Guthrie's work does sound promising.
http://colin.guthr.ie/2010/01/mix-it-up/ http://colin.guthr.ie/2010/01/mix-it-some-more/
Anne
-
Anne Wilson -
Arthur Pemberton -
Dennis Gilmore -
Eli Wapniarski -
Gilboa Davara -
John Pilkington -
Kevin Kofler -
Martin Kho -
Patrick Boutilier -
Petrus de Calguarium -
Rex Dieter