As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login?
Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components.
If a new desktop is setup with kde, it must have konqueror as the browser and kmail as the mail client. These are designed to work nicely together.
In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop.
Neal Becker wrote:
As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login?
Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components.
If a new desktop is setup with kde, it must have konqueror as the browser and kmail as the mail client. These are designed to work nicely together.
In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop.
What you are describing is the symptom of a larger issue that different set of packages could use more attention that it current receives. This is something that we fix by merging core,extras and legacy and let everyone interested work on all of Fedora. See more details at http://fedoraproject.org/wiki/FedoraSummit
Rahul
Neal Becker wrote:
In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop.
kmail, knode, konq are all there on my box in the "Internet" menu, unless you're talking about something else... ?
-- Rex
On Friday 17 November 2006 14:49, Rex Dieter wrote:
Neal Becker wrote:
In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop.
kmail, knode, konq are all there on my box in the "Internet" menu, unless you're talking about something else... ?
I imagine that he is talking about the default apps shortcuts in the panel.
On 11/18/06, Neal Becker ndbecker2@gmail.com wrote:
As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login?
Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components.
If a new desktop is setup with kde, it must have konqueror as the browser and kmail as the mail client. These are designed to work nicely together.
In my experience, most new linux users (as most new users on other OSs) never bother to customize their menus and tool bars. I see my friends desktops have kde as window manager, but never heard of kmail, knode, konq because fedora by default doesn't show them on their menus and desktop.
Let it go dude. Trust me. I know what you mean. But I also know that it is going to be months before this changes. I think it will....in time.
Peace
On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote:
As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login?
Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components.
If a new desktop is setup with kde, it must have konqueror as the browser
The browser one is funny. I know MANY people who will be upset if it's not firefox, period. That has nothing to do with being pro, neutral or against KDE, but simple expectation that Firefox is the flag ship open source thing for many people (they met it first on Windows and started to take open source more serious, now they look at linux), and they expect it to be there at least as integrated as the Windows Firefox is.
Firefox also isn't the gnome default browser, but still I think Fedora does the right thing to overrule BOTH desktops and give people what they want.
fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven:
On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote:
As a long time kde and fedora fan, I'd like to promote the idea of making kde a 1st class part of fedora. What does this mean, you ask? Can't the new user select kde at login?
Yes, they can. But their desktop is setup with icons and menus that are missing vital kde components.
If a new desktop is setup with kde, it must have konqueror as the browser
The browser one is funny. I know MANY people who will be upset if it's not firefox, period. That has nothing to do with being pro, neutral or against KDE, but simple expectation that Firefox is the flag ship open source thing for many people (they met it first on Windows and started to take open source more serious, now they look at linux), and they expect it to be there at least as integrated as the Windows Firefox is.
Firefox also isn't the gnome default browser, but still I think Fedora does the right thing to overrule BOTH desktops and give people what they want.
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop. I strongly disagree with the argument that people move to Fedora thanks to Firefox since I see no hard evidence for that claim and there are advantages to be had by going for maximal integration.
So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen.
- David
On Fri, 2006-11-17 at 17:04 +0100, David Nielsen wrote:
fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven:
On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote:
If a new desktop is setup with kde, it must have konqueror as the browser
Firefox also isn't the gnome default browser, but still I think Fedora does the right thing to overrule BOTH desktops and give people what they want.
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop. I strongly disagree with the argument that people move to Fedora thanks to Firefox since I see no hard evidence for that claim and there are advantages to be had by going for maximal integration.
So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen.
This might make a good candidate for firstboot - during firstboot the person installing the system could choose the default apps that newly created users would get.
Jeff
fre, 17 11 2006 kl. 10:11 -0600, skrev Jeffrey C. Ollie:
On Fri, 2006-11-17 at 17:04 +0100, David Nielsen wrote:
fre, 17 11 2006 kl. 16:52 +0100, skrev Arjan van de Ven:
On Fri, 2006-11-17 at 06:37 -0500, Neal Becker wrote:
If a new desktop is setup with kde, it must have konqueror as the browser
Firefox also isn't the gnome default browser, but still I think Fedora does the right thing to overrule BOTH desktops and give people what they want.
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop. I strongly disagree with the argument that people move to Fedora thanks to Firefox since I see no hard evidence for that claim and there are advantages to be had by going for maximal integration.
So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen.
This might make a good candidate for firstboot - during firstboot the person installing the system could choose the default apps that newly created users would get.
Dear heavens no.. One of the strengths of the Fedora desktop is it's predefined standards. If you like me want a different set of applications there's the customize now/later option during install.
- David
David Nielsen wrote:
So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen.
This might make a good candidate for firstboot - during firstboot the person installing the system could choose the default apps that newly created users would get.
Dear heavens no.. One of the strengths of the Fedora desktop is it's predefined standards. If you like me want a different set of applications there's the customize now/later option during install.
Besides, choosing a web browser and a MUA is a per-user action; It doesn't belong to firstboot, which is a system-wide thing.
On Fri, 2006-11-17 at 23:41 +0100, Bernardo Innocenti wrote:
David Nielsen wrote:
So I could definitely see why many KDE users would feel the same way about Konqi. Luckily this one of those things that will naturally resolve itself once Core and Extras gets merged, if the community by then wants KDE to have Konqi as the default then that will happen.
This might make a good candidate for firstboot - during firstboot the person installing the system could choose the default apps that newly created users would get.
Dear heavens no.. One of the strengths of the Fedora desktop is it's predefined standards. If you like me want a different set of applications there's the customize now/later option during install.
Besides, choosing a web browser and a MUA is a per-user action; It doesn't belong to firstboot, which is a system-wide thing.
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Jeff
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet.
On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote:
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet.
Correct me if I'm wrong, but AFAICT, there aren't any means to setup a "machine-wide" or "network-wide" defaults?
Ralf
On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote:
On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote:
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet.
Correct me if I'm wrong, but AFAICT, there aren't any means to setup a "machine-wide" or "network-wide" defaults?
The preferred applications capplet stores its values in gconf. gconf does have system-wide defaults, and you can set them with gconftool-2.
On 11/18/06, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote:
On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote:
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet.
Correct me if I'm wrong, but AFAICT, there aren't any means to setup a "machine-wide" or "network-wide" defaults?
The preferred applications capplet stores its values in gconf. gconf does have system-wide defaults, and you can set them with gconftool-2.
Does KDE touch Gconf? I'd hate to believe a Gnome speicifc solution is beign suggest in a thread abotu KDE.
On Sat, 2006-11-18 at 00:45 -0500, Matthias Clasen wrote:
On Sat, 2006-11-18 at 06:27 +0100, Ralf Corsepius wrote:
On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote:
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis. Try the "Preferred Applications" capplet.
Correct me if I'm wrong, but AFAICT, there aren't any means to setup a "machine-wide" or "network-wide" defaults?
The preferred applications capplet stores its values in gconf. gconf does have system-wide defaults, and you can set them with gconftool-2.
Or you can use Sabayon[1][2] to administer GNOME desktop settings across multiple user accounts.
Keith.
[1] http://www.gnome.org/projects/sabayon/ [2] http://fedoraproject.org/extras/6/i386/repodata/repoview/sabayon-0-2.12.4-4....
On Sat, 2006-11-18 at 00:23 -0500, Matthias Clasen wrote:
On Fri, 2006-11-17 at 23:15 -0600, Jeffrey C. Ollie wrote:
In firstboot, you would be setting the system-wide default. Users would be able to change their browser on an individual basis.
Surprise, users are already able to change their browser on an individual basis.
Yes, I should have said, users would *still* be able to change their browser on an individual basis.
Jeff
David Nielsen <david <at> lovesunix.net> writes:
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop.
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin Kofler
On 11/17/06, Kevin Kofler kevin.kofler@chello.at wrote:
David Nielsen <david <at> lovesunix.net> writes:
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop.
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin Kofler
I only use Firefox on my Fedora install to check Gmail (these mailing lists) - I use Seamonkey the rest of the time.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin Kofler
Be gentle, moving "firefox" to "Extras" would already be a great thing ;)
Joachim Frieben wrote:
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin KoflerBe gentle, moving "firefox" to "Extras" would already be a great thing ;)
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit. If you want to seriously suggest changing the default, write up more solid proposals that has just more than personal preferences in it and start a new thread.
Rahul
On Friday 17 November 2006 16:32, Rahul Sundaram wrote:
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit.
Please remember that this is just proposed, and by no means set in stone.
On Fri, 2006-11-17 at 16:46 -0500, Jesse Keating wrote:
On Friday 17 November 2006 16:32, Rahul Sundaram wrote:
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit.
Please remember that this is just proposed, and by no means set in stone.
It is a very good idea though, so fairly likely to go ahead.
We have realised that having 'second class citizens' in Fedora doesn't make much sense and doesn't work very well. Having a separate build and release process for Fedora Extras was never particularly workable -- combining Core and Extras is obviously the right thing to do.
Now, where else could we apply that same hard-earned knowledge?
Rahul Sundaram wrote:
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit. Rahul
Indeed, I didn't get that memo. The site you linked to didn't so much describe the merger between Core and Extras as much as it did simply hint at at. I would very much appreciate it if you could point us to where we can find information on what this will all mean, and how it will work out.
Tyler Larson wrote:
Rahul Sundaram wrote:
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit. Rahul
Indeed, I didn't get that memo. The site you linked to didn't so much describe the merger between Core and Extras as much as it did simply hint at at. I would very much appreciate it if you could point us to where we can find information on what this will all mean, and how it will work out.
There are links in that page. You probably missed that.
http://fedoraproject.org/wiki/FedoraSummit/OpeningCore http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess
Rahul
so just to be clear fedora is indeed combining core and extras?
On 11/17/06, Rahul Sundaram sundaram@fedoraproject.org wrote:
Tyler Larson wrote:
Rahul Sundaram wrote:
If you havent received the memo yet, there is no core/extras/legacy starting from the next release. http://fedoraproject.org/wiki/FedoraSummit. Rahul
Indeed, I didn't get that memo. The site you linked to didn't so much describe the merger between Core and Extras as much as it did simply hint at at. I would very much appreciate it if you could point us to where we can find information on what this will all mean, and how it will work out.
There are links in that page. You probably missed that.
http://fedoraproject.org/wiki/FedoraSummit/OpeningCore http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess
Rahul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Saturday 18 November 2006 02:19, nick stumpos wrote:
so just to be clear fedora is indeed combining core and extras?
That is our intent. We still need to get approval from folks like the Fedora Extras leaders, the Fedora Legacy leaders, Red Hat engineering management, etc...
...... Original Message ....... On Sat, 18 Nov 2006 10:11:13 -0500 "Jesse Keating" jkeating@redhat.com wrote:
On Saturday 18 November 2006 02:19, nick stumpos wrote:
so just to be clear fedora is indeed combining core and extras?
That is our intent. We still need to get approval from folks like the
Fedora
Extras leaders, the Fedora Legacy leaders, Red Hat engineering management, etc...
So far each RHEL version has had a corresponding FC version that was extremely close in initially shipped package versions. For example:
RHL7.2 - RHEL2.1 FC1 - RHEL3 FC3 - RHEL4 FC6 - RHEL5 (?)
Will this new Fedora development model change this? ___ Dax Kelson Sent with my Treo (please pardon any brevity)
On Saturday 18 November 2006 10:50, Dax Kelson wrote:
Will this new Fedora development model change this?
Most likely no. We're still planning on sticking to the 6 month cycle, and RHEL could pick up a release and run with it. Whether or not RHEL uses the exact binaries is up for discussion, but most likely not, just the same srpms. Some of the software in Core may not find any real community users, some stuff that is RHEL only, and may not be carried forward, but it may, we're really not sure until we move everything and see how things shake out.
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote:
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
I think at some point the "CD" needs to shrink down; it's an online world after all, and 5 cd's is just "too much" for people to look up against.
In addition to making "the cd set" smaller, another option is to make groups of packages and then have special cds for them like
fedora-base (1 or 2 cds with basic OS) fedora-server (all "server only" things such as apache) fedora-gnome (the gnome desktop packages) fedora-kde (the kde desktop packages) fedora-openoffice (the lot of openoffice.org)
that way if you don't use kde (or gnome) you don't need to download&burn that CD. Same for openoffice... or you can elect to get that part of the upgrade via the network
I like the idea of separate fedora-server, fedora-gnome and fedora-kde CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus:
* fedora-gnome = basic OS + Gnome + main essential applications * fedora-kde = basic OS + KDE + main essential applications * fedora-server = basic OS + server packages * fedora-extras = other popular packages and applications * fedora-devel = All the development libraries and applications that most users never install
That way a user can set up a working os with as little as 1 cd.
Keith.
On 20/11/06, Arjan van de Ven arjan@fenrus.demon.nl wrote:
On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote:
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
I think at some point the "CD" needs to shrink down; it's an online world after all, and 5 cd's is just "too much" for people to look up against.
In addition to making "the cd set" smaller, another option is to make groups of packages and then have special cds for them like
fedora-base (1 or 2 cds with basic OS) fedora-server (all "server only" things such as apache) fedora-gnome (the gnome desktop packages) fedora-kde (the kde desktop packages) fedora-openoffice (the lot of openoffice.org)
that way if you don't use kde (or gnome) you don't need to download&burn that CD. Same for openoffice... or you can elect to get that part of the upgrade via the network
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Nov 20, 2006 at 01:21:11PM +0000, Keith G wrote:
I like the idea of separate fedora-server, fedora-gnome and fedora-kde CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus:
openoffice.org takes up almost 700mb by itself.
(You want "essential", try abiword at 7MB and gnumeric at 12MB.)
On Mon, 20 Nov 2006, Matthew Miller wrote:
On Mon, Nov 20, 2006 at 01:21:11PM +0000, Keith G wrote:
I like the idea of separate fedora-server, fedora-gnome and fedora-kde CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus:
openoffice.org takes up almost 700mb by itself.
(You want "essential", try abiword at 7MB and gnumeric at 12MB.)
But how do you deal with .PPT? I haven't found a reasonable way yet..
On Tue, Nov 21, 2006 at 02:47:03PM +0200, Pekka Savola wrote:
CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus:
openoffice.org takes up almost 700mb by itself. (You want "essential", try abiword at 7MB and gnumeric at 12MB.)
But how do you deal with .PPT? I haven't found a reasonable way yet..
Thank goodness that doesn't rank as "essential" for me.
I like the idea of separate fedora-server, fedora-gnome and fedora-kde CDs, although I think main essential applications like openoffice and firefox should be on the main CD. I think it would be better to split the CDs thus:
- fedora-gnome = basic OS + Gnome + main essential applications
- fedora-kde = basic OS + KDE + main essential applications
- fedora-server = basic OS + server packages
- fedora-extras = other popular packages and applications
- fedora-devel = All the development libraries and applications that
most users never install
That way a user can set up a working os with as little as 1 cd.
openoffice.org takes up almost 700mb by itself.
(You want "essential", try abiword at 7MB and gnumeric at 12MB.)
According to the OpenOffice.org download page, the linux version of 2.2.13 is 120MB. That's not including the SDK and such, but most users wouldn't need that anyway. So the 'normal' OpenOffice installation could easily be included as one of the main essential applications on the fedora-gnome and fedora-kde CDs as stated above.
I think this is the best course of action, and I know it's technically possible, because its similar to what Ubuntu does with their two distros: * Ubuntu = basic OS + gnome + essential apps (incl. openoffice) = 1 CD * Kubuntu = basic OS + KDE + essential apps (incl. openoffice) = 1CD
Keith.
Once upon a time, Arjan van de Ven arjan@fenrus.demon.nl said:
On Mon, 2006-11-20 at 12:56 +0000, Keith G wrote:
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
I think at some point the "CD" needs to shrink down; it's an online world after all, and 5 cd's is just "too much" for people to look up against.
The problem is that it is _not_ an online world for a lot of people. I've got a friend that lives in a broadband-challenged area; his only option for anything faster than dialup is satellite, and that doesn't help with Fedora (since they cap downloads).
Right now, Extras is "second class" for that kind of user, because they just can't get to it and install much. The ability to spin ISOs for Extras will help, but the problem with custom spins is distribution. Unless there are "official" ISOs, they can't easily be mirrored or torrented.
It would still be nice to see a release-day snapshot of Extras in ISO format (or even move Extras to a release and update directory structure like Core).
Keith G wrote:
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
See http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess
Rahul
On Monday 20 November 2006 07:56, Keith G wrote:
How will future decisions be made on which packages constitute the official release (included in the release CDs and DVD)?
Probably a function of the release team, with input from various SIGs and RH Engineering management, with final approval by the board perhaps? Note that there is plenty of opportunity for community input in this stack.</wildarseguess>
On Fri, 2006-11-17 at 18:04 +0000, Kevin Kofler wrote:
David Nielsen <david <at> lovesunix.net> writes:
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop.
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin Kofler
Because konq is -years- behind firefox when it comes to supporting non-English sites and has superior extensions. Nothing stops you from configuring -your- installation as -you- like it. Screwing -my- setup just because -you're- too lazy to waste 2 minutes on customization is absurd.
- Gilboa
On Sat, 2006-11-18 at 21:20 +0200, Gilboa Davara wrote:
On Fri, 2006-11-17 at 18:04 +0000, Kevin Kofler wrote:
David Nielsen <david <at> lovesunix.net> writes:
Funny as a GNOME user, the first thing I do is replace Firefox with Epiphany as it integrates better with my desktop.
And as a KDE user, I do the same with Konqueror. Heck, why not drop Firefox altogether (considering all that trademark crap) and default GNOME to Epiphany (built against xulrunner - firefox-devel is only a temporary hack anyway) and KDE to Konqueror?
Kevin KoflerBecause konq is -years- behind firefox when it comes to supporting non-English sites and has superior extensions. Nothing stops you from configuring -your- installation as -you- like it. Screwing -my- setup just because -you're- too lazy to waste 2 minutes on customization is absurd.
- Gilboa
FYI, I use KDE as main DE. (But I use non-KDE applications when they suite my needs - OO, Evolution, Firefox, Gimp, gvim, etc)
- Gilboa
Arjan van de Ven wrote:
The browser one is funny. I know MANY people who will be upset if it's not firefox, period. That has nothing to do with being pro, neutral or against KDE, but simple expectation that Firefox is the flag ship open source thing for many people (they met it first on Windows and started to take open source more serious, now they look at linux), and they expect it to be there at least as integrated as the Windows Firefox is.
<flamebait> Of course it's just a matter of opinions, but am I the only one considering Firefox (or Thunderbird, and even OpenOffice...) very bad examples of how to design a good open source program? </flamebait>
<trolling> The fact that these applications originated as proprietary software is still very recognizable today. They still are very monolithic in nature, built on their own custom portability and GUI frameworks. They make heavy use of binary or opaque file formats for storing settings and other metadata. And they generally (ab)use threading, or custom plugin, upgrade, and installation systems. </trolling>
<disclaimer> I use all these apps daily, but I still feel somewhat uncomfortable with them. Just my 2 cents. </disclaimer>
Bernardo Innocenti wrote:
Nice troll, but there's a point that can be made out of it:
The fact that these applications originated as proprietary software is still very recognizable today.
What's recognizable is that they're user-oriented instead of developer oriented.
They still are very monolithic in nature,
Users like one interface to handle all their needs. Developers | want | to | connect | orthogonal > tools.
built on their own custom portability and GUI frameworks.
Most users don't use GTK (and where most of these apps are deployed, GTK would be considered a custom portability framework).
They make heavy use of binary or opaque file formats for storing settings and other metadata.
Users want to configure using a gui. That means a program reads and writes the configuration, so a binary format makes sense. Developers like to vi/emacs the configuration file; most developer-oriented programs never write their configuration file.
And they generally (ab)use threading,
Users want the program to be responsive. Developers want purity of design.
or custom plugin, upgrade, and installation systems.
To reach actual users (not developers) you need more than rpm and yum.
On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote:
Users want to configure using a gui.
That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because:
- it's easier to find a file in a specific place than to find the configuration-application-of-the-day
- it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up.
- you can google using its contents
- you often have useful comments in them, where the GUI equivalent requires a number of manipulations to access
- you can grep a bunch of files to help finding where is the configuration concerning <x>
- it's way easier to talk about it in email
- you don't need to leave the keyboard for all your configuration and you can see all the configuration options on one screen
Of course, that breaks down if your "text" file is actually computer-oriented xml crap with a randomly generated name hidden 3 levels down in a dot-directory.
Debutant users don't want to configure, period. Advanced users want efficiency. Efficient GUI configuration tools are extremely rare.
OG.
Olivier Galibert wrote:
On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote:
Users want to configure using a gui.
That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because:
How many of these users are IT workers or computer enthusiasts?
- it's easier to find a file in a specific place than to find the configuration-application-of-the-day
It's only easier for developers. Users know how to open Tools|Options. They have no idea where the config file sits.
- it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up.
If the configuration file is of any size at all (postfix, apache) you have to read a huge text file to find something.
If the configuration file omits some of the options, you have to read the manual page.
- you can google using its contents
Shouldn't you try the application's help first?
- you often have useful comments in them, where the GUI equivalent requires a number of manipulations to access
Context-sensitive help?
- you can grep a bunch of files to help finding where is the configuration concerning <x>
I'm a user. What's grep again?
- it's way easier to talk about it in email
Especially for developers who dislike html mail. Users don't want to talk about options, they want to change them.
- you don't need to leave the keyboard for all your configuration and
A good GUI will allow you to do everything through the keyboard (yes, I've used one that does).
you can see all the configuration options on one screen
Again, assuming a short file, in which case the options dialog will be short as well.
Of course, that breaks down if your "text" file is actually computer-oriented xml crap with a randomly generated name hidden 3 levels down in a dot-directory.
In that case it's probably designed for machine writing. Hopefully there's a GUI for it.
Debutant users don't want to configure, period. Advanced users want efficiency. Efficient GUI configuration tools are extremely rare.
Efficieny for configuration? Do you measure it in configs/sec?
A configuration task is usually one for which you don't know all the details, since it is rare. In that case the most efficient interface is one that has visible hierarchical grouping so you can learn your way through it.
An example: Thunderbird's Edit|Preferences|Display, "Plain Text Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js mail.wrap_long_lines (it isn't there, you have to google for it or look in Thunderbird's config editor)
[yes, it's easier to type in an email. but you'd get unwrapped text much. much sooner with the GUI]
For system administrators and developers, text files are fine. For normal users, let them have their GUI.
Le samedi 18 novembre 2006 à 13:11 +0200, Avi Kivity a écrit :
Olivier Galibert wrote:
On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote:
Users want to configure using a gui.
That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because:
How many of these users are IT workers or computer enthusiasts?
Yea, right, ever tried to explain a GUI procedure to someone over 40 (aggravating factor : over the telephone) ? They don't know what right-click is, they don't know conventions, they get hopelessly confused by renamed menu entries or new themes that change icons they're used to. GUI power is massively overrated (even when it's designed properly in the first place, which is the exception, especially for big proprietary offerings)
(and that's not musch easier for younger people)
Nobody but computer enthusiasts has the time to browse all the app menus and screens to find the place where the developper moved the magic button designed to help him not writing a text file
- it's easier to find a file in a specific place than to find the configuration-application-of-the-day
It's only easier for developers. Users know how to open Tools|Options.
1. No they don't 2. when they do they recoil in horror before the mass of badly qualified checkboxes
They have no idea where the config file sits.
Unlike the GUI, the config file location is usually stable. They can note it down. Mapping a GUI route OTOH is a disaster
- it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up.
If the configuration file is of any size at all (postfix, apache) you have to read a huge text file to find something.
And usually you have the text explanation right next to the config option. With examples even. You don't realise what a godsend it is after the 3-word explanation you have next to a gui checkbox
If the configuration file omits some of the options, you have to read the manual page.
Hint : do you actually think people grok GUIs without manuals or helpful power users to explain them what the heck the convoluted label language means ?
- you can google using its contents
Shouldn't you try the application's help first?
ROTFL you're hopeless
- you often have useful comments in them, where the GUI equivalent requires a number of manipulations to access
Context-sensitive help?
Right-click, what's a right click ? What's a right-clickable object ? Why do you think apple gets by with a single button mouse ?
- it's way easier to talk about it in email
Especially for developers who dislike html mail. Users don't want to talk about options, they want to change them.
No. Users don't want to talk about options period. They don't want to change them be it in the config file or in the GUI
An example: Thunderbird's Edit|Preferences|Display, "Plain Text Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js mail.wrap_long_lines (it isn't there, you have to google for it or look in Thunderbird's config editor)
[yes, it's easier to type in an email. but you'd get unwrapped text much. much sooner with the GUI]
That's remain to be proven. Comparing speed once users have learnt the GUI is cheating.
For system administrators and developers, text files are fine. For normal users, let them have their GUI.
If only it was their GUI and not some monstruosity designed to show of everything is GUI-accessible…
Nicolas Mailhot wrote:
That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because:
How many of these users are IT workers or computer enthusiasts?
Yea, right, ever tried to explain a GUI procedure to someone over 40 (aggravating factor : over the telephone) ? They don't know what right-click is,
That's their first week on the computer, right? But they've already mastered vi.
they don't know conventions, they get hopelessly confused by renamed menu entries or new themes that change icons they're used to.
Sure, an application upgrade can be confusing. But at least the applications can be upgraded. With configuration files, it's impossible (try to imagine a user diffing /etc/blah.conf with /etc/blah.conf.rpmnew to get their machine to work).
(and it seems you're advocating that applications should never change rather than they should use config files).
GUI power is massively overrated (even when it's designed properly in the first place, which is the exception, especially for big proprietary offerings)
(and that's not musch easier for younger people)
Nobody but computer enthusiasts has the time to browse all the app menus and screens to find the place where the developper moved the magic button designed to help him not writing a text file
Please try to watch some real users. They can get by with menus just fine.
- it's easier to find a file in a specific place than to find the configuration-application-of-the-day
It's only easier for developers. Users know how to open Tools|Options.
- No they don't
- when they do they recoil in horror before the mass of badly qualified
checkboxes
Sigh. A badly designed UI is certainly worse than a good UI. A configuration file is a badly designed UI.
They have no idea where the config file sits.
Unlike the GUI, the config file location is usually stable.
Where is it? My file browser doesn't show it.
It doesn't matter if its stable if I can't find it.
They can note it down. Mapping a GUI route OTOH is a disaster
Screenshot.
- it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up.
If the configuration file is of any size at all (postfix, apache) you have to read a huge text file to find something.
And usually you have the text explanation right next to the config option. With examples even. You don't realise what a godsend it is after the 3-word explanation you have next to a gui checkbox
Again you seem to think that a voyage into the application's design is more suitable for the user's attention span than clicking '[x] Beep when new mail arrives'.
If the configuration file omits some of the options, you have to read the manual page.
Hint : do you actually think people grok GUIs without manuals or helpful power users to explain them what the heck the convoluted label language means ?
Convoluted label language is no different than config_file_keys. If the UI is bad, fix it.
- you can google using its contents
Shouldn't you try the application's help first?
ROTFL you're hopeless
You mean, googling a database of all web pages, including other versions of the same program, other programs, to find a poor user that experienced the same desire as you and went to the trouble of posting to a mailing list is better than consulting an authoritative text that comes with the application?
If so, hopelessness is indeed in order. For desktop Linux.
- you often have useful comments in them, where the GUI equivalent requires a number of manipulations to access
Context-sensitive help?
Right-click, what's a right click ? What's a right-clickable object ?
You seem to be against GUIs in general, not just for configuration.
People do know how to right click (or do the equivalent on Apple).
Why do you think apple gets by with a single button mouse ?
The option key?
- it's way easier to talk about it in email
Especially for developers who dislike html mail. Users don't want to talk about options, they want to change them.
No. Users don't want to talk about options period. They don't want to change them be it in the config file or in the GUI
How do I add an e-mail account? The beep on a new mail message is annoying, can I disable it? All my friends have kittens on their desktop background. I want one too!
Users want different things. That's why there are configuration options.
An example: Thunderbird's Edit|Preferences|Display, "Plain Text Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js mail.wrap_long_lines (it isn't there, you have to google for it or look in Thunderbird's config editor)
[yes, it's easier to type in an email. but you'd get unwrapped text much. much sooner with the GUI]
That's remain to be proven. Comparing speed once users have learnt the GUI is cheating.
With a GUI, you need a basic skill set (navigating menus) and no more. With a configuration file, you need a lot more knowledge and time.
For system administrators and developers, text files are fine. For normal users, let them have their GUI.
If only it was their GUI and not some monstruosity designed to show of everything is GUI-accessible…
I don't understand this remark.
Le dimanche 19 novembre 2006 à 10:53 +0200, Avi Kivity a écrit :
Nicolas Mailhot wrote:
That's a common misconception. Lots of users are perfectly ok with text configuration files, and even often like them more, because:
How many of these users are IT workers or computer enthusiasts?
Yea, right, ever tried to explain a GUI procedure to someone over 40 (aggravating factor : over the telephone) ? They don't know what right-click is,
That's their first week on the computer, right? But they've already mastered vi.
They can use gedit which is actually not too difficult to explain compared to some "user-oriented" monstruosities
they don't know conventions, they get hopelessly confused by renamed menu entries or new themes that change icons they're used to.
Sure, an application upgrade can be confusing. But at least the applications can be upgraded.
Very often the "GUI applications can be upgraded" means old settings are 100% lost. They even provide registry cleaners in case the upograde process forgot to kill some settings.
(and it seems you're advocating that applications should never change rather than they should use config files).
No, I'm saying being GUI is *not* the magical bullet you're saying it is. Like the rest of the software it can be massively abused, and in fact when a proprietary offering abuses threading and other plumbing aspects it ususally abuses the GUI too.
GUI power is massively overrated (even when it's designed properly in the first place, which is the exception, especially for big proprietary offerings)
(and that's not musch easier for younger people)
Nobody but computer enthusiasts has the time to browse all the app menus and screens to find the place where the developper moved the magic button designed to help him not writing a text file
Please try to watch some real users. They can get by with menus just fine.
Thank you but no. I've done enough helpdesk (both familial and professional) in my life not to need another confirmation.
- it's easier to find a file in a specific place than to find the configuration-application-of-the-day
It's only easier for developers. Users know how to open Tools|Options.
- No they don't
- when they do they recoil in horror before the mass of badly qualified
checkboxes
Sigh. A badly designed UI is certainly worse than a good UI. A configuration file is a badly designed UI.
Again, you're generalising a manichean "GUI is good" "config files is bad" without providing any supporting evidence.
They have no idea where the config file sits.
Unlike the GUI, the config file location is usually stable.
Where is it? My file browser doesn't show it.
google is your friend
It doesn't matter if its stable if I can't find it.
They can note it down. Mapping a GUI route OTOH is a disaster
Screenshot.
ROTFL # 2
It requires : 1. you have the very same app version as the user, with the same locale and theme settings 2. that you mount a screencast-film to explain every change
It's not practical (and despite what you may seem to think yes I've already done it and it was massively time consuming, needed to be updated every release, and was not practical but for 1-2 core settings)
- it's easier to find what you want in it, especially when your setup is nonstandard in any slight way. Things hidden in the new tab of the day which appears only when you click on allow advanced in a dialog box coming from a menu can be quite frustrating. In other words, the interface part of a text configuration file is much harder to fuck up.
If the configuration file is of any size at all (postfix, apache) you have to read a huge text file to find something.
And usually you have the text explanation right next to the config option. With examples even. You don't realise what a godsend it is after the 3-word explanation you have next to a gui checkbox
Again you seem to think that a voyage into the application's design is more suitable for the user's attention span than clicking '[x] Beep when new mail arrives'.
And again you seem to think checkboxes are logically labelled or logically placed. Very often a GUI settings *requires* you to understand the application design to find it/set it correctly. You really need to sit with a basic non-computer-oriented user someday to understand the *mass* of assumptions that make a GUI setting useable.
(And I'm not adding localisation by people with zero idea of what the app does to the mix)
If the configuration file omits some of the options, you have to read the manual page.
Hint : do you actually think people grok GUIs without manuals or helpful power users to explain them what the heck the convoluted label language means ?
Convoluted label language is no different than config_file_keys. If the UI is bad, fix it.
The difference being that GUI real-estate is scarse, so you get a condensed convoluted and confused langage and settings placed hasaphardly because there was no dedicated tab/section for them and they were regrouped on the screen with some space left.
- you can google using its contents
Shouldn't you try the application's help first?
ROTFL you're hopeless
You mean, googling a database of all web pages, including other versions of the same program, other programs, to find a poor user that experienced the same desire as you and went to the trouble of posting to a mailing list is better than consulting an authoritative text that comes with the application?
If so, hopelessness is indeed in order. For desktop Linux.
It's the same for desktop windows.
I've never encountered one person actively using application help. Even some who "did" find one answer there once upon a time only use it at last resort when googling fails.
Application help is a need-to-have thing required in the function matrix corps use before buying software, but the way it's structured makes it rather useless (and no I've got no magic bullet either)
You seem to be against GUIs in general, not just for configuration. People do know how to right click (or do the equivalent on Apple).
I'm not against GUI. I love GUI. I use GUI every day. But there is a difference between being for GUI and stating that because it's GUI it's user-friendly and because it's not it's user-unfriendly.
A GUI can be good or bad. Most GUI programs have the same strengths and weaknesses. A common GUI weakness is configuration settings. Another is the help system. That does not mean for other everyday operations the GUI is not a good choice. Just that on average, users choose not to use the GUI config or help system because on average it's hopelessly botched.
Especially for developers who dislike html mail. Users don't want to talk about options, they want to change them.
No. Users don't want to talk about options period. They don't want to change them be it in the config file or in the GUI
How do I add an e-mail account? The beep on a new mail message is annoying, can I disable it?
You cope with it, you ask a friend, you ask helpdesk, you google for it and when all is lost you may wander in the config menu or the help system.
All my friends have kittens on their desktop background. I want one too!
Ever noticed the "put picture on background" shortcut is duplicated everywhere because users could not find it in the central "logical" place ? Do you actually think it's possible to duplicate every setting twenty times in the hope users will find it ?
Users want different things. That's why there are configuration options.
For power users to use or helpdesk to set corp-wide. The existence of GUI settings do not imply their wide use, in fact every single user study points users do not use them, or only for 1-2 apps they can't avoid.
An example: Thunderbird's Edit|Preferences|Display, "Plain Text Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js mail.wrap_long_lines (it isn't there, you have to google for it or look in Thunderbird's config editor)
[yes, it's easier to type in an email. but you'd get unwrapped text much. much sooner with the GUI]
That's remain to be proven. Comparing speed once users have learnt the GUI is cheating.
With a GUI, you need a basic skill set (navigating menus) and no more.
This basic skill set is les basic than you seem to think
With a configuration file, you need a lot more knowledge and time.
Again I disagree so that's your opinion against mine without any hard fact between.
For system administrators and developers, text files are fine. For normal users, let them have their GUI.
If only it was their GUI and not some monstruosity designed to show of everything is GUI-accessible…
I don't understand this remark.
Then you don't understand average users.
Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le dimanche 19 novembre 2006 à 10:53 +0200, Avi Kivity a écrit :
Nicolas Mailhot wrote:
[...]
I've never encountered one person actively using application help. Even some who "did" find one answer there once upon a time only use it at last resort when googling fails.
That is because the application help is usually completely unsearchable (or you want to search for "change background color" while it is documented under "reconfigure wallpaper" or "define theme", or it has a list of functions and you want to know how to compute something specific). "Help" is (as anyone who as taught somewhen) first about understanding what the user wants, finding out what their misconceptions are, and then pointing them in the right direction. As long as AI remains as primitive as it is today, you'll at best get Clippy.
Application help is a need-to-have thing required in the function matrix corps use before buying software, but the way it's structured makes it rather useless (and no I've got no magic bullet either)
Problem is that it requires /thousands/ of different organizations, each tailored for a morass of different tasks.
[...]
A GUI can be good or bad. Most GUI programs have the same strengths and weaknesses. A common GUI weakness is configuration settings. Another is the help system. That does not mean for other everyday operations the GUI is not a good choice. Just that on average, users choose not to use the GUI config or help system because on average it's hopelessly botched.
GUIs are usually easier to learn and use for simple tasks, for complex tasks they are hopeless. And the help system for CLI is usually also very bad, but CLI user expectations are normally lower.
lør, 18 11 2006 kl. 11:48 +0100, skrev Olivier Galibert:
On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote:
Users want to configure using a gui.
That displays the fallacy that users want to configure stuff.
They might want the option to tune an application but generally users just want applications to work and will as a rule rather live with a suboptimal default configuration for their soecific job than dig through options and confusing tools/dialogs.
The lesson we have to take away from this is to strive for good default but remain configurable through a nice uniform interface. This is exactly why gconf is so cool, translatable decriptor strings explain what every key does for the user who likes to tweak the more exoteric parts of their applications and the rest get a nice clean interface with good defaults and the bare essencesial options.
Please don't assume that users _want_ to configure, it's not an end goal, it's a means to get work done.
- David Nielsen
David Nielsen wrote:
lør, 18 11 2006 kl. 11:48 +0100, skrev Olivier Galibert:
On Sat, Nov 18, 2006 at 08:37:16AM +0200, Avi Kivity wrote:
Users want to configure using a gui.
That displays the fallacy that users want to configure stuff.
Users don't want to configure. But they do have habits and preferences. Some like bigger fonts, others like animation. Some want (*gasp*) to change their wallpaper. I've been known to enter my name and email address into my mailer.
An unconfigurable application will probably be suitable for one user (its developer).
They might want the option to tune an application but generally users just want applications to work and will as a rule rather live with a suboptimal default configuration for their soecific job than dig through options and confusing tools/dialogs.
The lesson we have to take away from this is to strive for good default but remain configurable through a nice uniform interface. This is exactly why gconf is so cool, translatable decriptor strings explain what every key does for the user who likes to tweak the more exoteric parts of their applications and the rest get a nice clean interface with good defaults and the bare essencesial options.
gconftool is way better than configuration files (and you raise a good point -- localization -- that is missing from good old config files).
However an application specific UI can (and should) be much better organized than gconf.
Please don't assume that users _want_ to configure, it's not an end goal, it's a means to get work done.
That was my point exactly. Putting things in configuration files _prevents_ users from getting that work done. Putting things in gconf is better, but still user-unfriendly (open an external application, find the root of the configured application's tree, start hacking things in a generic interface rather than one tailored to the task).
Le samedi 18 novembre 2006 à 08:37 +0200, Avi Kivity a écrit :
Bernardo Innocenti wrote:
Nice troll, but there's a point that can be made out of it:
The fact that these applications originated as proprietary software is still very recognizable today.
What's recognizable is that they're user-oriented instead of developer oriented.
No, what's recognizable is they're PHB-oriented, PHB asked for a single tool, PHB got delivered a single tool, even at the cost of tying vastly different pieces of code with bandaids
They still are very monolithic in nature,
Users like one interface to handle all their needs. Developers | want | to | connect | orthogonal > tools.
In my experience users are quite happy with several interfaces as long as they're consistent and not overlapping. It's developers that insist on making private copies and forks of uncounted libs, then slap an "unifying" GUI over the mess (in a FLOSS context they get reminded of proper practices by distributions which hate having to ship and qualify multiple versions of the same thing; in a proprietary context they're given free run).
The "users like one interface" is a myth, firefox succeeded because it broke the old mozilla in multiple interfaces, and before that moz was eating the netscape-branded version which had welded yet more stuff in the single interface.
built on their own custom portability and GUI frameworks.
Most users don't use GTK
That's why using one-of-a-kind proprietary framework is better ? One of the clearest and most appreciated changes in OO.o 2 was to expose native widgets to users instead of the old SO thing. Mac users BTW complain because they were forgotten in this change.
They make heavy use of binary or opaque file formats for storing settings and other metadata.
Users want to configure using a gui. That means a program reads and writes the configuration, so a binary format makes sense.
There are many ways to have program-writeable text format (netscape/mozilla to name a big GUI app has been doing it for as long as I can remember), so again it's not a user wish but programming laziness the proprietary context allowed
And they generally (ab)use threading,
Users want the program to be responsive. Developers want purity of design.
Yeah, right, that's why every "liberated" program is described as a pig compared to the FLOSS alternatives. Hint : purity of design translates in perf wins, hacks translate in microbenchmark wins for the first version (and then no one dares updating them for the next ones so all the clever ugly code rots)
or custom plugin, upgrade, and installation systems.
To reach actual users (not developers) you need more than rpm and yum.
Wrong. The percentage of users willing to go the specific update route is vanishingly small, only enthousiasts are willing to spend the time learning an update system per app.
Developers will want source tarballs
Enthousiasts will want a way to update everything on their system to the latest bling, and are willing to jump through hoops and custom updaters for this.
Everyone else (99% of users) just want the stuff to be pre-installed and transparently updated with the rest of the system using the system tools. For all its faults windows update showed pretty conclusively even in the windows world the power of a single unified update service.
Regards,
Avi Kivity wrote:
The fact that these applications originated as proprietary software is still very recognizable today.
What's recognizable is that they're user-oriented instead of developer oriented. [...]
I can hardly disagree with all your arguments. After all, the programs I've been whining about are top-rated killer applications, and very appreciated in the Windows world too.
As you pointed out, maybe my perspective is not user-oriented, because I'm actually a developer (or should I say a mature UNIX diehard?) with distinct habits and usage patterns.
To us UNIX geeks, a good text editor is a much better configuration tool than any dialog box exactly because it's orthogonal with the application and provides powerful tools such as search, infinite undo and the ability to keep copies of different configurations etc.
When we, the minority, choose an application for our own *personal* use, we don't care about the rest of the world and shouldn't need to. If an application design is unable to satisfy both the needs of regular users and people with "special requirements" like us, we are left behind.
As Spok told us, the needs of the many outweigh the needs of the few, but many of us have been using Linux and other UNIX flavours because they were designed by our ancestors with our unusual behavioral patterns in mind.
Where should we turn to if the usability of our platform gets compromised for the sake of a few billion lusers? ;-)
I believe most linux advocates would agree that one of linux main strengths is choice. But, user's don't really have choice if they don't know they have choice.
I don't want to remove firefox. Firefox is great. I just believe we need a more effective way to alert new users that they have a choice.
On 11/18/06, Neal Becker ndbecker2@gmail.com wrote:
I believe most linux advocates would agree that one of linux main strengths is choice. But, user's don't really have choice if they don't know they have choice.
If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice.
Frankly...I think there need to be a 'Dr. Fedora. type app which help a users make (or ignore) the many choices which are available to them.
Arthur Pemberton <pemboa <at> gmail.com> writes:
If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice.
I must say I hate that too. This stuff belongs into the GenericName field, not the Name field. Of course, this means GNOME would have to be fixed to display both Name and GenericName as KDE has done for years. (And KDE allows you to configure it, so if you want just the name or just the GenericName, you can have that.)
Kevin Kofler
On Sat, 2006-11-18 at 16:17 +0000, Kevin Kofler wrote:
Arthur Pemberton <pemboa <at> gmail.com> writes:
If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice.
I must say I hate that too. This stuff belongs into the GenericName field, not the Name field. Of course, this means GNOME would have to be fixed to display both Name and GenericName as KDE has done for years. (And KDE allows you to configure it, so if you want just the name or just the GenericName, you can have that.)
This also bothers me greatly. If GNOME was fixed to use both names (or set to use the GenericName for RHEL and Name for Fedora) should we start using "Firefox" rather than "Web browser"?
Richard.
lør, 18 11 2006 kl. 16:38 +0000, skrev Richard Hughes:
On Sat, 2006-11-18 at 16:17 +0000, Kevin Kofler wrote:
Arthur Pemberton <pemboa <at> gmail.com> writes:
If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice.
I must say I hate that too. This stuff belongs into the GenericName field, not the Name field. Of course, this means GNOME would have to be fixed to display both Name and GenericName as KDE has done for years. (And KDE allows you to configure it, so if you want just the name or just the GenericName, you can have that.)
This also bothers me greatly. If GNOME was fixed to use both names (or set to use the GenericName for RHEL and Name for Fedora) should we start using "Firefox" rather than "Web browser"?
I'd strongly object to using Name over GenericName just because we are Fedora. It has a significant discoverablity advantage for users to use GenericName which we would be throwing out.
Users who want to change their application setup should also have the option to change the naming scheme, maybe in a TweakUI type thing or as part of the menu configuration/editing.
. David Nielsen
Kevin Kofler wrote:
Arthur Pemberton <pemboa <at> gmail.com> writes:
If you don't believe the quoted statement install Windows......you can install several other browsers, text editors, media players etc.....but if the link to the 'default' browser says Internet (or in the case of gaim, 'Instant Messenger') then a large percentage of users will _not_ benifit from having a choice.
I must say I hate that too. This stuff belongs into the GenericName field, not the Name field. Of course, this means GNOME would have to be fixed to display both Name and GenericName as KDE has done for years. (And KDE allows you to configure it, so if you want just the name or just the GenericName, you can have that.)
Amen to that. As a matter of fact, I plan on bringing .desktop file issues (like properly following the spec and respecting Name vs GenericName) to the Fedora Packaging committee to get such nonsense stopped.
-- Rex
On 11/17/06, Neal Becker ndbecker2@gmail.com wrote:
I believe most linux advocates would agree that one of linux main strengths is choice. But, user's don't really have choice if they don't know they have choice.
I don't want to remove firefox. Firefox is great. I just believe we need a more effective way to alert new users that they have a choice.
Effective.. sure we'd all like a pony. Uninformed choice is no better and in many cases worse than no choicee. First and foremost informed choices require the individuals to care. How do you make new users care, if they have not in fact experiencecd the pros and cons of each software choice for themselves? It's a catch-22. You can't pack enough information into the installer or into firstboot to help new users make informed choices. This is the role of detailed documentation... and you sure as hell aren't going to get new users to read through 4 pages of a detailed comparison of just the available browser advantages at install time.
At best you can do is attempt to make them aware that Fedora contains multple application choicees across a wide array of functionality and ask them to explore the packagespace after install time.
If the default is a bad choice for new users, there is no garuntee that any other choice you could give new users at install time would lead to consistently better experiences on average, because such choices at install time are inherently uninformed unless users have previous knowledge. And if they have previous knowledge as to what applications they prefer.. they don't need install time walk-throughs.
If you want to fight about changing the default applications, feel free. But to pack a series of nagware like dialogs into the installer or into firstboot to enforce that users make a series of inherently uninformed choices is not going to make anything better for anyone. You might as well just write in a randomizing function so every user gets a random set of default apps.
In fact.. from a testing point of view.. a random set of default apps would make for good testing coverage during pre-release testing.
-jef"best is the enemy of good"spaleta
-
Arjan van de Ven -
Arthur Pemberton -
Avi Kivity -
Bernardo Innocenti -
Chris Adams -
David Nielsen -
David Woodhouse -
Dax Kelson -
Gilboa Davara -
Horst H. von Brand -
Jef Spaleta -
Jeffrey Ollie -
Jesse Keating -
Joachim Frieben -
Keith G -
Keith Sharp -
Kevin Kofler -
Laurent Rineau -
Matthew Miller -
Matthias Clasen -
Neal Becker -
nick stumpos -
Nicolas Mailhot -
Olivier Galibert -
Pekka Savola -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
Richard Hughes -
Tyler Larson