unaccessability

[Michael Schwendt]

On Sun, 10 Nov 2013 21:56:57 +0000, Ian Malone wrote:

> On 10 November 2013 20:55, Michael Schwendt wrote:
> > On Sun, 10 Nov 2013 18:02:46 +0000, Ian Malone wrote:
> >
> >> You are arguing that system management should only be possible through
> >> a GUI where the affected components are themselves graphical.
> >
> > No, not at all.
> >
> >> Please take some time to reflect on how ridiculous that is.
> >
> > http://fedoraproject.org/code-of-conduct
> 
> The dreaded code of conduct! I'm being horrible to you! I take it all back!
> Hang on: "When we disagree, we try to understand why." That's what I asked.

Calling something "ridiculous" and requesting me to ask myself is not
helpful if you really are interest in discussing something.

> >> I'm looking at the software management menu
> >> in KDE right now and on my system there are 26 entries listed in the
> >> servers management section, since these are non-graphical should they
> >> be dropped?
> >
> > I don't understand why you've asked that question.
> > It seems to me you may have misunderstood something _completely_.
> >
> 
> You're the one that keeps saying you don't understand...
> I'll try again. And then I'll give up, because I know how futile it is
> to argue when the other side is has already decided how things must
> be.

Not "must be", but just how I would like them to be. I'm open to other
solutions.
We cannot discuss KDE, because I don't know much about KDE or its
"software management menu". Items found in it should not be dropped,
but displayed with improved usability.

In general, if a graphical tool offers access to "packages" that include
CLI programs or contents other than graphical applications, this should be
made very clear. As another example, I would prefer it if a CLI tool like
"fortune-mod" were not part of a crowded category like "Games and
Entertainment". And perhaps searchable "tags" will be the only way to
solve the problem, or else there would be an inflation of categories.

Even an old terminal based ASCII-art dungeon exploring game may have its
target group (even if it may be only a niche market), but I think it
should either be tagged appropriately or displayed in a different section,
especially if after installation it cannot be started from a desktop menu
or overview of installed applications.

> What you are saying here is that if we want a graphical package
> manager it must be separate to an 'application manger' for 'normal'
> users (you've used the word 'software', which until today I thought
> meant anything that ran on a computer).

It need _not_ be a separate tool. It can be the same tool, if it doesn't
mix different types of programs (GUI vs. CLI) or packages. Or *if* it mixes
different types of programs, it will be very obvious about that. The only
target group should not be "expert users" (who, for example, know that
they've installed an IRC client to be run within a terminal and how to do
that.)

> I agree with your final paragraph, I don't see why it should be a
> problem to simply distinguish in the package manager what the type of
> package is. It's got a desktop file, it's probably an application, it
> doesn't, it's probably not.

Good.

> Finally, to return to auto-launching of programs on install. I don't
> think it's helpful. This is the only time the user ever interacts with
> the software in that way. Afterwards they're left to figure out on
> their own where it is.
 
I would consider it very helpful, if there were some sort of "Wizard" at
the end of the installation that would be explicit about what has been
installed. It could display a Help page about running CLI tools, about
where to find the Theme settings for an installed Themes Package, about
where to toggle an added service that can be configured via the desktop
GUI.