unaccessability

[Ian Malone]

On 10 November 2013 20:55, Michael Schwendt <mschwendt at gmail.com> 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.

>
>> Should non-gui packages be excluded from automatic updates because the
>> tool used to manage that is graphical?

> without affecting LibreOffice.  A "System Updates" tool that handles all
> updates of installed low-level "packages" could be a completely different
> piece of software.
>

>> Should firewall management be only possible at the CLI?
>
> No. And firewall-config is a GUI.
> I don't understand why you've asked that question.
>
>> 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.

> What I don't like is the situation that somebody uses a graphical tool to
> install "software", and the installed stuff doesn't show up anywhere in
> the graphical desktop user interface (such as a menu system), but is only
> listed as installed. That's the "WTF?" scenario, where the user needs to
> be an expert to figure out that the installed thing is CLI-only (or not
> even "executable" at all) and something that cannot be "used" from within
> the desktop UI.
> If an "application installer" will be able to install arbitrary
> "packages", I would welcome a very obvious distinction in the UI,
> a special interface for specific types of components and "add-ons".
> Not old-school ambiguous "categories". What I don't like is a graphical
> "package tool" that tries to handle the 40,000 "packages" by sorting them
> into categories. And the user is confronted with many thousands of "lib"
> packages, for example, which are no "applications" (no "programs" to
> use). A developer (or a sysadmin) has different requirements.

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). I can only see that
*increasing* confusion as you're creating a distinction based on
whether a package contains graphical tools or not. And to work out
where you want to install something from will depend on whether it's
an application, a tool or a library. And so someone who has started
with the system for a while and finds they want to install a library
or command line tool now has to learn a new tool to do it with.
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.

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.

-- 
imalone
http://ibmalone.blogspot.co.uk