Discussion:
Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
(too old to reply)
Alexander Ploumistos
2014-12-26 20:32:58 UTC
Permalink
I've been meaning to write this for a week, but I wanted to do some
research first. The more I read and thought on it, the issue became
broader, the subject line kept changing and this message starting looking
like an article. I will try to choose my words carefully; I do not intend
to offend anyone nor do I want to appear biased.

I hadn't used any graphical package manager on fedora for almost a decade
(yumex was the last one) because I had been burned too many times and I
don't trust them, but after doing a little work in the AppData area, I
thought I'd take a look at gnome-software. It is one of the most beautiful
UIs I have ever seen. It is elegant, simple yet functional, tidy, gorgeous
to look at and it manages to stand out from all the other "market" or
"store" applications. It incorporates some of the competition's best
features, while avoiding their pitfalls (try living with Ubuntu's software
center for a couple of days). I wholeheartedly agree with Richard Hughes in
that software centers compliant with the AppStream specification help
promote applications and are beneficial to both the users and the
developers.

About a week ago, while wondering why MATE applications do not appear in
gnome-software, Richard was kind enough to point to a blog post from
September 2013:

http://blogs.gnome.org/hughsie/2013/09/19/gnome-software-on-mate-and-xfce/

I thought that developers and users might find it useful, so to quote
*tl;dr:* If you want to run GNOME Software on MATE or XFCE you need to
set an environment variable like
GNOME_SOFTWARE_COMPATIBLE_PROJECTS=MATE,GNOME,XFCE
This might have gone unnoticed since then, but I think it is an issue worth
(re)visiting.

I can understand and defend the design choices that have been made;
allowing a user to mix and match packages from different DEs with different
aesthetics, compiled against different/incompatible libraries or having
three different applications appear as "Text Editor" or "Dictionary" would
lead to a sub-optimal user experience. From that standpoint it makes sense
to hide from the user packages tied to other DEs, especially if the same
functionality is provided by Gnome packages. Of course, a user might
install an application e.g. compiled against gtk2 and the result would be
the same.

I have not tested this much in other Fedora versions, only in F22 with
GNOME. There, the default value in org.gnome.software compatible-projects
is set to 'GNOME', 'KDE', 'XFCE'.
(see
https://mail.gnome.org/archives/commits-list/2013-November/msg00656.html)
I do not understand this particular choice to include some DEs and exclude
others. Why not enable or disable all of them? LXDE and MATE developers
might be prone to attribute this to malice. Personally, on almost every
machine I use, I have mixed packages from various sources - some due to
personal preference, others because they offer unique functions.

Then again, does gnome-software aspire to be a "universal" package manager
on Fedora? If it does, then why not offer packages from every DE and
metapackages for other environments? If gnome-software aims to be
novice-user-friendly, at least the latter should definitely be an option. Let's
not forget that Gnome is a modern desktop environment, that requires fairly
modern hardware to run on and that is not always available. Also, can
gnome-software be the distro-wide default package manager while adhering to
the HIG?

Allow me to digress a bit. Sometime in 2000, my professor told me that in
order to use some molecular modeling packages and to modify their FORTRAN
source code, I had to get linux, so after some searching, I went to a local
bookstore and bought SuSE 5.3 or 6.0, can't remember any more (on a 56k
analog modem at the time, downloading the iso or doing a network install
was out of the question). The box came with two massive manuals (and some
cute stickers) from which I learned the concept of the window manager or
desktop environment. The choices I had been given got me really excited
(almost as much as when I got my mouse wheel working) and after some weeks
of playing with each DE, I routinely switched from KDE to enlightenment or
to fvwm, according to the requirements of the task at hand, or just my
mood. For years I kept the habit of alternating between almost every
environment that was packaged for my distro, until I did not have the time
to keep up with every change, so I settled with GNOME (mostly). Then came
GNOME 3 and in the ensuing upheaval I gave every other DE another try.
These days I use GNOME on my workstation, MATE on a netbook I take with me
whenever I have field work (which sometimes literally means working in a
field) and on an ancient dual Athlon MP workstation. On some other systems
I manage or have lying around, I run E19, XFCE, MATE and GNOME.

I have converted many friends and acquaintances over to linux, but for the
past 2-3 years I don't think I have pointed anyone to anything but Ubuntu
and I feel some guilt about it. For a number of reasons I can't quite put
my finger on, Fedora does not "feel right" for newcomers. The upgrade
process, software management and support time-frame are certainly among
them. Most of these otherwise bright people have their IQ drop to the value
of its logarithm when they sit in front of a computer screen and they all
seem to suffer from a natural aversion towards the terminal and towards
RTFM. I'm sure you are all well aware of them. When you tell them to go to
fedoraproject.org and download the iso, you can be certain that a phone call
is imminent, asking for step-by-step instructions, even though everything
is well-documented. Explaining to them the difference between linux and
distribution is hard and if you start talking about spins, they lose you.
If they decide to search for a solution to an issue by themselves, they
have no problem executing any commands they may find in a blog post from
2005, ignoring all the error messages that inevitably come along and then
they will look genuinely surprised because something broke. Last week I
upgraded my old workstation to F21. It has a GeForce 6800 that whenever I
had used nouveau instead of nvidia's driver, seriously overheated and the
computer sounded like the vacuum cleaners of yore. After the upgrade, I
couldn't get to gdm, but entering MATE manually worked, so after a little
digging, I found out about an issue with mutter and nvidia's driver. I
tried a newer version of the driver from rpmfusion's build system, that
didn't work, so I switched to lightdm. Now imagine one of those people,
being faced with the same issue right after the adrenaline rush of
upgrading with fedup. Even I have kept my main system on F20 because I need
CUDA and I can't switch to OpenCL.

Many of these people however exhibited an excitement far greater than mine,
when after complaining about Unity for various reasons, I presented them
with the alternatives. They were happy to spend time trying out other DEs,
pointing out what felt right and what wrong. Some of them tried all of KDE,
Cinnamon, MATE, LXDE, XFCE, GNOME and Enlightenment, for weeks even, before
deciding what worked for them and their workflow. To my semi-surprise, some
of those on higher-spec machines ended up on GNOME, which I thought had a
steeper learning curve compared to most of the others (I still had to tell
them about hidden stuff like gnome-session-properties or to get
gnome-tweak-tool and look in extensions.gnome.org for extensions).

Having said all that, I hear a lot of people complaining about losing users
to Ubuntu, Mint and others, or why things like project Sputnik
<http://www.dell.com/learn/us/en/555/campaigns/xps-linux-laptop> don't
involve our community. The biggest issue here is which is the targeted user
base of Fedora, if there is one? And what are the use cases we want fedora
to cover? Can we have "Freedom" and be "First" and still cater to
everyone's needs?

Well, that's it.
Happy holidays everyone!
Ben Cotton
2014-12-26 21:45:00 UTC
Permalink
On Fri, Dec 26, 2014 at 3:32 PM, Alexander Ploumistos
<***@gmail.com> wrote:

This is a great post and there are a lot of points worthy of
discussion. I'm going to focus my reply on the ending (though there
are several threads that could spawn from this).
The biggest issue here is which is the targeted user base of Fedora, if
there is one? And what are the use cases we want fedora to cover?
Prior to Fedora 21, I'm not sure we could really claim to have a
targeted user base. The products (or whatever name we settle on, see
the council-discuss thread) are a great start to defining more
specific target audiences. They're still relatively broad, but I
expect that as they mature, we'll see that they better define what the
target is and we'll be better at understanding who is actually using
Fedora and for what.
Can we
have "Freedom" and be "First" and still cater to everyone's needs?
No, and that's okay. We could get rid of either of those and still not
cater to everyone's needs. The important thing is to meet the needs
we're trying to meet. I personally consider "first" to be the most
flexible of the foundations, in the sense that we could offer the
occasional release with longer support without compromising it. I
doubt we'll get a large share of the non-savvy user base in the same
way that Ubuntu did, but we don't have to.
--
Ben Cotton
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/c
Alexander Ploumistos
2014-12-27 13:57:00 UTC
Permalink
Post by Ben Cotton
This is a great post and there are a lot of points worthy of
discussion.
And I was certain people would dismiss it saying "someone had too much
eggnog this year"...
Post by Ben Cotton
Prior to Fedora 21, I'm not sure we could really claim to have a
targeted user base. The products (or whatever name we settle on, see
the council-discuss thread) are a great start to defining more
specific target audiences. They're still relatively broad, but I
expect that as they mature, we'll see that they better define what the
target is and we'll be better at understanding who is actually using
Fedora and for what.
Well, the cloud product is a bit narrow in scope, the server is broader and
the workstation is too broad. Yet still there are use cases that fall
somewhere in between. The council's idea about a survey sounds good, but if
it ever manages to get off the ground, implementing it will face a lot of
problems.
Post by Ben Cotton
Post by Alexander Ploumistos
Can we
have "Freedom" and be "First" and still cater to everyone's needs?
No, and that's okay. We could get rid of either of those and still not
cater to everyone's needs. The important thing is to meet the needs
we're trying to meet. I personally consider "first" to be the most
flexible of the foundations, in the sense that we could offer the
occasional release with longer support without compromising it. I
doubt we'll get a large share of the non-savvy user base in the same
way that Ubuntu did, but we don't have to.
Actually we do have a VLTS (Very Long Term Support) release, CentOS,
especially now that they've joined the family, but the connection is not
immediately apparent. On the other hand, a rolling release might be better
suited for the users who do not want to perform a clean install or full
upgrade every six months. However we couldn't supplant Ubuntu and remain
Fedora... In my view "First" is the defining characteristic of Fedora, but
it wouldn't matter without the other three. A couple of years ago, I tried
as an experiment to keep a Gentoo system on par with Fedora, installing
almost every keyworded package as soon as it became available, but I gave
up after a week; it was too much work for one person to keep track of
changed dependencies, upstream patches etc.. While Gentoo is still very
dear to me, there aren't enough people involved to do that kind of work and
bring it all together as a whole in a six month time frame.

As far as "Freedom" goes, there is a fine balance to be kept. It would be
nice to have tighter collaboration with hardware vendors, but not to the
point where they dictate what and when should be shipped (nVidia and AMD
come to mind). But seeing the same thread -"Black screen after upgrading to
Fxx"- resurrected every six months in the forum is getting tiring.

I know I'm sort of reinventing the wheel here and probably every single
point I have mentioned has been discussed before in a meeting, a particular
mailing list, a wiki page, a SIG, etc., but the truth is that there is a
daunting amount of bureaucracy and compartmentalization. To an outsider, or
even to Fedora members belonging to a specific group it seems like we're
flying on autopilot. There is also some difficulty for those who want to
get involved and it's equally difficult to contribute without stepping on
someone's toes. I've met people who wanted to contribute to Fedora, but
chose to work on upstream projects because they had a hard time trying to
grasp and fit in the organizational structure.
Adam Williamson
2014-12-27 21:53:31 UTC
Permalink
Post by Alexander Ploumistos
Actually we do have a VLTS (Very Long Term Support) release, CentOS,
especially now that they've joined the family, but the connection is
not immediately apparent.
CentOS is not a release of Fedora. It is a separate distribution which
has Fedora as its upstream.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:
Ian Malone
2014-12-30 00:36:46 UTC
Permalink
On 27 December 2014 at 21:53, Adam Williamson
Post by Adam Williamson
Post by Alexander Ploumistos
Actually we do have a VLTS (Very Long Term Support) release, CentOS,
especially now that they've joined the family, but the connection is
not immediately apparent.
CentOS is not a release of Fedora. It is a separate distribution which
has Fedora as its upstream.
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
upstream (so far as I am aware anyway).
--
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/c
Rahul Sundaram
2014-12-30 01:26:22 UTC
Permalink
Hi
Post by Ian Malone
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
upstream (so far as I am aware anyway).
That is incorrect. Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.

Rahul
Nico Kadel-Garcia
2014-12-30 02:31:31 UTC
Permalink
Post by Rahul Sundaram
Hi
Post by Ian Malone
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
upstream (so far as I am aware anyway).
That is incorrect. Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.
Rahul
CentOS is also "branded" in that it has trademarks, copyrights, and
other legal existence. The relation is fascinating, especially because
at least some of the CentOS developers are now Red Hat employees and
Red Hat is publishing their free software at https://git.centos.org/.
It's much like that when Red Hat used to publish its full binary
distributions up until Red Hat 9. Their efforts there, and especially
in funding and supporting Fedora development as a testbed for RHEL
projects, has been an extremely effective business model for free
software development.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Ian Malone
2014-12-30 13:09:11 UTC
Permalink
Post by Rahul Sundaram
Hi
Post by Ian Malone
Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
upstream (so far as I am aware anyway).
That is incorrect. Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
--
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Emmanuel Seyman
2014-12-30 13:13:11 UTC
Permalink
Post by Ian Malone
Post by Rahul Sundaram
That is incorrect. Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
This has always been the case. What made you think differently?

Emmanuel
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fe
Ian Malone
2014-12-30 18:53:34 UTC
Permalink
Post by Emmanuel Seyman
Post by Ian Malone
Post by Rahul Sundaram
That is incorrect. Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.
I stand corrected then. Anyone know when this changed?
This has always been the case. What made you think differently?
Thought I'd been told otherwise at some point in the past, but must
have been a misunderstanding. Had thought they weren't that closely
coupled, i.e. not direct forks, but looks like I was wrong.
--
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-
Richard Hughes
2014-12-27 22:26:03 UTC
Permalink
On 26 December 2014 at 20:32, Alexander Ploumistos
why not offer packages from every DE and metapackages for other environments?
I don't see how this addresses the multiple "Calculator" application
problem I clearly outlined in my original blog post. Offering choices
and configuration options in applications is not zero-cost, and people
more qualified and eloquent than me have written why.
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the
fine nuances of the design choices of different desktop environments.
Can gnome-software be the distro-wide default package manager while adhering to
the HIG?
It's the software application installer for GNOME, and GNOME just
happens to be our chosen desktop environment. I don't think you can
ask if GNOME software maybe isn't a suitable Fedora application
installer because it doesn't give equal priority to MATE (a hostile
fork of an old version of GNOME). GNOME Software even prioritizes
GNOME software when running under KDE, and I'd hope Apper does the
same for KDE apps on KDE.

I do suggest MATE ship their own software centre, or use
gnome-software and just set an session-wide environment variable like
I suggested a long time ago.

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Reindl Harald
2014-12-27 23:17:31 UTC
Permalink
Post by Richard Hughes
On 26 December 2014 at 20:32, Alexander Ploumistos
why not offer packages from every DE and metapackages for other environments?
I don't see how this addresses the multiple "Calculator" application
problem I clearly outlined in my original blog post. Offering choices
and configuration options in applications is not zero-cost, and people
more qualified and eloquent than me have written why.
having choices and options is the reason why people switch to Linux,
otherwise they can stay at OSX or Windows - protect people from having
choices is a bad attitude and frankly if that would have been
widespreaded around 2006 i would never became a Linux and network
professional
Post by Richard Hughes
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the
fine nuances of the design choices of different desktop environments.
if you hide anything you can they will stay novice users forever
Richard Hughes
2014-12-28 12:57:51 UTC
Permalink
Post by Reindl Harald
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Reindl Harald
2014-12-28 13:06:51 UTC
Permalink
Post by Richard Hughes
Post by Reindl Harald
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
you can't dictate as developer the reason why users are making their
decisions, you can ignore it, dislike it and what not, but you can't
change it
Orcan Ogetbil
2014-12-28 21:13:23 UTC
Permalink
Post by Richard Hughes
Post by Reindl Harald
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
Oh please, no need for provocation... I was silently following this
thread but I couldn't keep it that way after this post. There rant
collection on the site lists the prime symptoms of "Gnome disease" and
it is just too much for this mailing list.

I still think that Fedora should be the last place on earth to build
an OS based on acquiescence of users as illiterate idiots.

I still have hope. Please don't crush my dreams.

Best,
Orcan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:/
Reindl Harald
2014-12-28 22:11:52 UTC
Permalink
Post by Orcan Ogetbil
Post by Richard Hughes
Post by Reindl Harald
having choices and options is the reason why people switch to Linux,
http://www.islinuxaboutchoice.com/
Oh please, no need for provocation... I was silently following this
thread but I couldn't keep it that way after this post. There rant
collection on the site lists the prime symptoms of "Gnome disease" and
it is just too much for this mailing list.
I still think that Fedora should be the last place on earth to build
an OS based on acquiescence of users as illiterate idiots.
I still have hope. Please don't crush my dreams
+1

and the page above is out of context crap beause it talks about
developer ressources while the "software center" architecst talk about
*hide* already existing software from users

WTF - just add a tab for "non so beautiful promoted but usefull and
present packages" and *first* stop to talk about using a terminal in a
hostile way all the time just because you don't realize that you *can
not* place any useful operatin in a nice graphical interface

trying to keep users away from a terminal is *hostile* and *user
unfriendly* because there are millions of operations you can do within
seconds in a terminal for decades and will never be able to do in any
graphical crap application

you want to hide all that capabilities from new users?
than don't pretend to design a unix like operating system
Alexander Ploumistos
2014-12-28 00:23:45 UTC
Permalink
Post by Richard Hughes
On 26 December 2014 at 20:32, Alexander Ploumistos
why not offer packages from every DE and metapackages for other
environments?
I don't see how this addresses the multiple "Calculator" application
problem I clearly outlined in my original blog post. Offering choices
and configuration options in applications is not zero-cost, and people
more qualified and eloquent than me have written why.
I noted that a little earlier, I was asking about the available packages if
the aim of gnome-software on fedora is to be the default graphical package
manager. And of course that beautiful interface comes at the cost of
choice. I can't remember on which distro I had this happen to me (perhaps
Mandrake?), I wanted to install k3b and krename and I got all of KDE,
including some games!

An interesting side-effect of having multiple packages with the same name:
I accidentally opened xfce's dictionary on my girlfriend's laptop, and I
saw that it had a speed reader! I had never used one before, so there was
some enthusiasm in the discovery. There could be a silver lining in that
cloud (though admittedly, having three of the basic apps is sometimes
frustrating, I don't know how she manages to find the right one every time).
Post by Richard Hughes
If gnome-software aims to be novice-user-friendly, at least the latter
should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the
fine nuances of the design choices of different desktop environments.
However they do understand when their system is sluggish, say with Unity,
or that this or that DE looks ugly, or is dysfunctional etc.. Using my
friends as lab rats showed me that much and I was happy when each of them
found the DE that worked best for them and their hardware. In light of
that, maybe it would be a reasonable idea to have metapackages for other
DEs in gnome-software with screenshots, descriptions and the occasional
warnings, so people like them won't need someone over their heads reciting
arcane incantations. Gnome's fallback mode is a shame, in that it's like
having the engine of a 2CV in a sports car chassis (or maybe the other way
around, I'm not sure).
Post by Richard Hughes
Can gnome-software be the distro-wide default package manager while
adhering to
the HIG?
It's the software application installer for GNOME, and GNOME just
happens to be our chosen desktop environment. I don't think you can
ask if GNOME software maybe isn't a suitable Fedora application
installer because it doesn't give equal priority to MATE (a hostile
fork of an old version of GNOME). GNOME Software even prioritizes
GNOME software when running under KDE, and I'd hope Apper does the
same for KDE apps on KDE.
I do suggest MATE ship their own software centre, or use
gnome-software and just set an session-wide environment variable like
I suggested a long time ago.
I don't mind if gnome-software favors GNOME apps, or if Apper does the
same. I have no interest in promoting any DE over another, I am only
partial to echo $SHELL returning bash and while I kept my distance at the
time of the fork, I am well aware of the harsh words that had been going
back and forth. I am not expecting either side to forgive and forget, but I
would like everyone to take the hostility down one notch (or even two, if
possible), at least on this neutral ground. Such animosity is saddening. In
retrospect, perhaps it was a mistake on my part to drag you into a
conversation with a developer from the other side and I would like to
apologize to you both for that. Should the need occur in the future, I will
just convey the gist to and fro and filter out any jabs or innuendos.

With that out of the way, the AppStream specification has certainly made it
possible for every DE to have an aesthetically satisfying software center.
But what about the rest of the distribution and how is a terminal-averse or
terminal-ignorant, new Fedora user supposed to install something like let's
say p7zip, which has no GUI? I don't know if Archive Manager pulls it in as
a dependency, but I think you can understand where I'm going with this
example. Should Fedora build another program as a package manager (or have
yumex installed by default) or do we say to our users that they should not
touch Fedora if they are not willing to type a few commands every now and
then - hence my other question about our targeted user base. I'm
comfortable with either option, I would just like to know which one it is.


Cheers
Michael Catanzaro
2014-12-28 02:15:48 UTC
Permalink
On Sat, Dec 27, 2014 at 6:23 PM, Alexander Ploumistos
Post by Alexander Ploumistos
I don't mind if gnome-software favors GNOME apps, or if Apper does
the same. I have no interest in promoting any DE over another, I am
only partial to echo $SHELL returning bash and while I kept my
distance at the time of the fork, I am well aware of the harsh words
that had been going back and forth. I am not expecting either side to
forgive and forget, but I would like everyone to take the hostility
down one notch (or even two, if possible), at least on this neutral
ground. Such animosity is saddening. In retrospect, perhaps it was a
mistake on my part to drag you into a conversation with a developer
from the other side and I would like to apologize to you both for
that. Should the need occur in the future, I will just convey the
gist to and fro and filter out any jabs or innuendos.
I think the use of the term "hostile fork" was more of a technical note
-- the MATE project disagrees with the direction of the GNOME project
and has forked it into something very different, with no intention of
future unification of the two projects -- than a comment on the tone of
either project. I've never seen any mudslinging from a MATE developer
directed at a GNOME, or vice versa. Things have been more or less
amicable between developers from the two communities.
Post by Alexander Ploumistos
With that out of the way, the AppStream specification has certainly
made it possible for every DE to have an aesthetically satisfying
software center. But what about the rest of the distribution and how
is a terminal-averse or terminal-ignorant, new Fedora user supposed
to install something like let's say p7zip, which has no GUI? I don't
know if Archive Manager pulls it in as a dependency, but I think you
can understand where I'm going with this example. Should Fedora build
another program as a package manager (or have yumex installed by
default) or do we say to our users that they should not touch Fedora
if they are not willing to type a few commands every now and then -
hence my other question about our targeted user base. I'm comfortable
with either option, I would just like to know which one it is.
This has been discussed at length on this list in the past, but not to
a satisfactory resolution for those who feel that typical users will
need to install packages.

* GNOME Software is not a package manager, and it is unlikely to become
a package manager. It's just for installing applications. In GNOME 3,
command line tools are not applications.
* The current operating theory is that "normal users" will never need
to install a package, and that exposing them to the package management
layer by including a graphical package manager would be unnecessarily
confusing. (Please accept my definition of "normal user" to be someone
who doesn't use the terminal. Yes, that's a massive oversimplification,
maybe not correct at all, and probably not representative of most
Fedora users. Yes, Workstation targets developers, but not exclusively,
and also developers who use fancy IDEs and who don't work with the
terminal. I just don't want this thread to degenerate into a discussion
of this lousy definition, since it's not important. What's important is
that we want Workstation to be excellent for users who never touch the
terminal.)
* p7zip, being a command-line tool, is something "normal users" should
never need. If Archive Manager needs it as a plugin, it can install it
with PackageKit if it's not detected, or it should be a dependency in
the RPM if Archive Manager doesn't support that. Hunting down a magic
package name to install is not an acceptable user experience, and not
something we should encourage or optimize for. Alternatively, it could
include an appdata file so that it's listed as an Archive Manager
plugin in GNOME Software, but I think that would be non-ideal in this
case, since users should never have to worry about having the right
packages installed to unzip an archive.
* But if we're wrong, and normal users really do need to install
packages, then we should probably include a graphical package manager
so that users can actually find packages. I submit that improving GNOME
Packages (aka gpk-application, the thing we installed by default until
F20), something that's already used by other distros (notably Debian),
would be a better use of our time than working on a Fedora-specific
solution like yumex. Especially considering that yum is not going to be
installed by default in F21.
* I have to install packages all the time, and I'd much rather use a
graphical package manager to find packages than to use yum or dnf. But
I'm a (relatively) experienced user and I know how to navigate a
graphical package manager. I expect that if a novice user were to open
a graphical packager manager, he would become very confused very
quickly, and we don't want any confusing software to be installed by
default.

The question is: is it more confusing for novice users to include a
graphical package manager by default, or to not include it? We're only
talking about novice users here: an experienced user can always take 20
seconds to install his preferred graphical package manager with GNOME
Software, so we don't care about what the experienced user wants for
himself.

Michael
Alexander Ploumistos
2014-12-28 17:08:13 UTC
Permalink
Post by Richard Hughes
GNOME PackageKit is still available (and maintained upstream) and is
what I use for installing things like mingw packages that I need for
development. Just type "Packages" into the dash and gnome-software
will install it for you :)
Oh, that was so nice! After typing the root password to install software, I
got another prompt with "The software is not from a trusted source". Is
that a rawhide issue?

How are user queries correlated to the package suggestions in the dash? I
do not always get what I would expect, e.g. when I type IDE, I get Anjuta,
Gnote and Rosegarden, with 3gp I get Frogr, Banshee, Xnoise and mpc yields
nothing.

And a third, irrelevant question: has the "hot corner" been disabled or is
it because I run f22 in a VM?
Post by Richard Hughes
* GNOME Software is not a package manager, and it is unlikely to become a
package manager.
I get that now, thank you.
Post by Richard Hughes
* p7zip, being a command-line tool, is something "normal users" should
never need. If Archive Manager needs it as a plugin, it can install it with
PackageKit if it's not detected, or it should be a dependency in the RPM if
Archive Manager doesn't support that. Hunting down a magic package name to
install is not an acceptable user experience, and not something we should
encourage or optimize for. Alternatively, it could include an appdata file
so that it's listed as an Archive Manager plugin in GNOME Software, but I
think that would be non-ideal in this case, since users should never have
to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a large
number of non-graphical programs installed by default, or that the various
applications will be compiled with every possible dependency, e.g. Archive
Manager will pull in every possible compression/decompression back end?
Post by Richard Hughes
* But if we're wrong, and normal users really do need to install packages,
then we should probably include a graphical package manager so that users
can actually find packages. I submit that improving GNOME Packages (aka
gpk-application, the thing we installed by default until F20), something
that's already used by other distros (notably Debian), would be a better
use of our time than working on a Fedora-specific solution like yumex.
Especially considering that yum is not going to be installed by default in
F21.
And that could lead to more confusion, at least from the "normal user"
perspective, having both a package manager and a software center...

I just checked and there is now a yumex version based on dnf.
Post by Richard Hughes
* I have to install packages all the time, and I'd much rather use a
graphical package manager to find packages than to use yum or dnf.
De gustibus non est disputandum. I find it easier to use yum, but when I
need to check a lot of similarly named packages to identify the one I want
or browse through a certain software category for programs, a graphical
package manager is faster and less fussy.
Post by Richard Hughes
The question is: is it more confusing for novice users to include a
graphical package manager by default, or to not include it? We're only
talking about novice users here: an experienced user can always take 20
seconds to install his preferred graphical package manager with GNOME
Software, so we don't care about what the experienced user wants for
himself.
This is not an easy question to answer. When I set up a computer for a
"normal user" I ask them what they want to do with it, so I configure
third-party repositories, install all the packages that offer the
functionality they expect, which usually includes several proprietary
applications and drivers as well. Finally I explain to them how package
management on linux differs to that of windows and how to use a graphical
package manager, searching either for the package name, or its definition
(e.g. audio editor) and what sort of packages they should download from
online sources (.deb/.rpm, x86_64/i686) when they aren't available in
distro repos. Depending on their computer literacy, sometimes I show them
how to install software from the terminal. Of the hundred or so linux
installations I've done for others in the last few years, only two users
stayed with my initial configuration and that is because they performed a
limited set of tasks.

With all the others, the results were mixed. Most (but certainly not all)
users have managed to install software successfully using package managers,
namely yumex, GNOME PackageKit, an old version of YaST, Synaptic and
Ubuntu's software center, but at times there was some confusion and
frustration. A small number of users have tried to install windows
executables and quite a few succeeded in doing that, because somehow WINE
got pulled in. An equally small number have installed packages for the
wrong architecture or for an older distro version. Then there were some
surprises, with people compiling programs from source or installing
commercial applications by following the vendor's instructions, but they
seem to be the exception. The overwhelming majority of users that had to
use the terminal to perform package management tasks because something
broke along the way, struggled with the concepts of commands, flags,
arguments and paths. They needed me to explicitly state where whitespace
and slashes should be inserted, even if they had been regularly using the
same or similar commands, albeit mostly via copy & paste. All of these
people had different backgrounds, skills and, interests, but I wouldn't
consider my sample representative.

I vaguely remember filling out a wizard-like questionnaire on the first run
of a distribution, that collected some hardware and user information. There
were questions like "Do you know what a window manager is?", "Do you
compile your own programs and if yes how often?", etc.. Perhaps we could
put together something similar to help us answer that sort of questions and
combine it with the council's survey proposal. I could help with that and I
could also reach out to some of my "test subjects".
Michael Catanzaro
2014-12-28 17:39:52 UTC
Permalink
On Sun, Dec 28, 2014 at 11:08 AM, Alexander Ploumistos
Post by Alexander Ploumistos
Post by Richard Hughes
GNOME PackageKit is still available (and maintained upstream) and is
what I use for installing things like mingw packages that I need for
development. Just type "Packages" into the dash and gnome-software
will install it for you :)
Oh, that was so nice! After typing the root password to install
software, I got another prompt with "The software is not from a
trusted source". Is that a rawhide issue?
Yes, all packages in rawhide are unsigned, so that warning is expected.
Don't use rawhide if you need your packages to not be malicious.

Note that the root password was only requested because the software was
unsigned -- if it was signed by Fedora, the installation would have
been seamless.
Post by Alexander Ploumistos
How are user queries correlated to the package suggestions in the
dash? I do not always get what I would expect, e.g. when I type IDE,
I get Anjuta, Gnote and Rosegarden, with 3gp I get Frogr, Banshee,
Xnoise and mpc yields nothing.
Sounds like a bug. When I type mpc I get Kid3-qt, Banshee, and Pogo.

I know it searches the appdata file description and desktop file
keywords at least.
Post by Alexander Ploumistos
And a third, irrelevant question: has the "hot corner" been disabled
or is it because I run f22 in a VM?
It's because you're using a VM.
Post by Alexander Ploumistos
Post by Richard Hughes
* p7zip, being a command-line tool, is something "normal users"
should never need. If Archive Manager needs it as a plugin, it can
install it with PackageKit if it's not detected, or it should be a
dependency in the RPM if Archive Manager doesn't support that.
Hunting down a magic package name to install is not an acceptable
user experience, and not something we should encourage or optimize
for. Alternatively, it could include an appdata file so that it's
listed as an Archive Manager plugin in GNOME Software, but I think
that would be non-ideal in this case, since users should never have
to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a
large number of non-graphical programs installed by default, or that
the various applications will be compiled with every possible
dependency, e.g. Archive Manager will pull in every possible
compression/decompression back end?
No, I think it just means that applications should not be broken by
default. Apps have the choice of pulling in every possible
compression/decompression backend (good for commonly-used backends and
backends that require few dependencies), installing them on-demand with
PackageKit (the correct choice for uncommonly-needed backends, or
backends with a large dependency tree), or expecting the user to
magically figure out what package to install (always the wrong choice).
Post by Alexander Ploumistos
Post by Richard Hughes
* But if we're wrong, and normal users really do need to install
packages, then we should probably include a graphical package
manager so that users can actually find packages. I submit that
improving GNOME Packages (aka gpk-application, the thing we
installed by default until F20), something that's already used by
other distros (notably Debian), would be a better use of our time
than working on a Fedora-specific solution like yumex. Especially
considering that yum is not going to be installed by default in F21.
And that could lead to more confusion, at least from the "normal
user" perspective, having both a package manager and a software
center...
Yup. :( A good argument for not including GNOME Packages by default.
Post by Alexander Ploumistos
Post by Richard Hughes
The question is: is it more confusing for novice users to include a
graphical package manager by default, or to not include it? We're
only talking about novice users here: an experienced user can always
take 20 seconds to install his preferred graphical package manager
with GNOME Software, so we don't care about what the experienced
user wants for himself.
This is not an easy question to answer.
Yup. :(
Post by Alexander Ploumistos
When I set up a computer for a "normal user" I ask them what they
want to do with it, so I configure third-party repositories, install
all the packages that offer the functionality they expect, which
usually includes several proprietary applications and drivers as well.
I think that's past the line of what we can reasonably expect a novice
user to handle. Proprietary apps are always going to be tough to
install on Fedora, since they're not welcome in our software center.
And novices who install proprietary graphics drivers are quite likely
to wind up with a completely broken system. This is a hard problem.

Your closing story, which I won't quote, was helpful. I'd argue it
makes a good case for shielding the user from normal packages with
GNOME Software, but I don't have a good answer for what happens when
you really need to install a package that's not a graphical application
(when did your users need to do this?), nor for proprietary or
patent-encumbered software (which we probably need to accept will
always be difficult).
Post by Alexander Ploumistos
I vaguely remember filling out a wizard-like questionnaire on the
first run of a distribution, that collected some hardware and user
information. There were questions like "Do you know what a window
manager is?", "Do you compile your own programs and if yes how
often?", etc.. Perhaps we could put together something similar to
help us answer that sort of questions and combine it with the
council's survey proposal. I could help with that and I could also
reach out to some of my "test subjects".
Hm, this would help us understand our current users better. That's
valuable (no reason to not do it), but I don't think it's likely to
sway opinions -- we all have our own idea about the type of users we
should optimize for. I'd like to optimize for the hapless users in your
examples.

Whether we include a graphical package manager or not (and I suspect
the status quo will prevail), Fedora will still be great either way.
Michael Catanzaro
2014-12-28 17:46:09 UTC
Permalink
Post by Alexander Ploumistos
Post by Michael Catanzaro
* p7zip, being a command-line tool, is something "normal users"
should never need. If Archive Manager needs it as a plugin, it can
install it with PackageKit if it's not detected, or it should be a
dependency in the RPM if Archive Manager doesn't support that.
Hunting down a magic package name to install is not an acceptable
user experience, and not something we should encourage or optimize
for. Alternatively, it could include an appdata file so that it's
listed as an Archive Manager plugin in GNOME Software, but I think
that would be non-ideal in this case, since users should never have
to worry about having the right packages installed to unzip an archive.
So this means that a default Workstation installation should have a
large number of non-graphical programs installed by default, or that
the various applications will be compiled with every possible
dependency, e.g. Archive Manager will pull in every possible
compression/decompression back end?
One more note here: if you try to run a command line program that isn't
installed, PackageKit will search for it in all enabled repos, offer to
install it for you if found, and then run the command. It's really a
nice user experience, and it's what I use to install executables that I
don't have. This only helps for executables, of course, and it doesn't
help users who first attempt to find the package some other way.
Garry T. Williams
2014-12-28 21:45:58 UTC
Permalink
Post by Michael Catanzaro
One more note here: if you try to run a command line program that
isn't installed, PackageKit will search for it in all enabled repos,
offer to install it for you if found, and then run the command.
No real need when you can do:

$ sudo dnf install /usr/bin/missing-executable

(I erased PackageKit. :)
--
Garry T. Williams
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduc
Ralf Corsepius
2014-12-28 22:06:41 UTC
Permalink
Post by Michael Catanzaro
One more note here: if you try to run a command line program that isn't
installed, PackageKit will search for it in all enabled repos, offer to
install it for you if found, and then run the command. It's really a
nice user experience,
I respectfully disagree. I consider this to be an utterly harmful
feature, which could be enabled in a "noob-spin", but should be blocked
from being installed in any room any other spin.

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:/
Reindl Harald
2014-12-28 18:04:25 UTC
Permalink
Post by Michael Catanzaro
On Sun, Dec 28, 2014 at 11:08 AM, Alexander Ploumistos
Post by Alexander Ploumistos
How are user queries correlated to the package suggestions in the
dash? I do not always get what I would expect, e.g. when I type IDE, I
get Anjuta, Gnote and Rosegarden, with 3gp I get Frogr, Banshee,
Xnoise and mpc yields nothing.
Sounds like a bug. When I type mpc I get Kid3-qt, Banshee, and Pogo
but you have no clue what mpc is

A client for MPD, the Music Player Daemon. mpc connects to a MPD running
on a machine via a network.

http://www.musicpd.org/
https://koji.fedoraproject.org/koji/buildinfo?buildID=591118
Alexander Ploumistos
2014-12-28 19:10:00 UTC
Permalink
Post by Michael Catanzaro
I think that's past the line of what we can reasonably expect a novice
user to handle. Proprietary apps are always going to be tough to install on
Fedora, since they're not welcome in our software center. And novices who
install proprietary graphics drivers are quite likely to wind up with a
completely broken system. This is a hard problem.
Even the lazy developer will at least expect to be able to watch flash
videos and listen to mp3s. So they will have to deal with repositories and
packages. Many people I know agree with FSF's core values, but they feel
left out when they can't use what other people on other platforms are using.
Post by Michael Catanzaro
Your closing story, which I won't quote, was helpful. I'd argue it makes a
good case for shielding the user from normal packages with GNOME Software,
but I don't have a good answer for what happens when you really need to
install a package that's not a graphical application (when did your users
need to do this?), nor for proprietary or patent-encumbered software (which
we probably need to accept will always be difficult).
The most recent example I can think of, is the youtube-dl script.

When it comes to building from source, more often than not, it involves
programs like this:
http://www.cryst.chem.uu.nl/platon/pl002000.html
Post by Michael Catanzaro
but you have no clue what mpc is
A client for MPD, the Music Player Daemon. mpc connects to a MPD running
on a machine via a network.
http://www.musicpd.org/
https://koji.fedoraproject.org/koji/buildinfo?buildID=591118
Hmm, that's interesting. Although I was thinking of musepack audio files.
Alexander Ploumistos
2014-12-28 19:34:11 UTC
Permalink
Post by Alexander Ploumistos
Post by Michael Catanzaro
Your closing story, which I won't quote, was helpful. I'd argue it makes
a good case for shielding the user from normal packages with GNOME
Software, but I don't have a good answer for what happens when you really
need to install a package that's not a graphical application (when did your
users need to do this?), nor for proprietary or patent-encumbered software
(which we probably need to accept will always be difficult).
The most recent example I can think of, is the youtube-dl script.
This just in: A friend had to use alsamixer to unmute a channel that got
muted after an update and was not visible in sound settings.
Michael Catanzaro
2014-12-28 19:38:12 UTC
Permalink
On Sun, Dec 28, 2014 at 1:10 PM, Alexander Ploumistos
Post by Alexander Ploumistos
Post by Michael Catanzaro
I think that's past the line of what we can reasonably expect a
novice user to handle. Proprietary apps are always going to be tough
to install on Fedora, since they're not welcome in our software
center. And novices who install proprietary graphics drivers are
quite likely to wind up with a completely broken system. This is a
hard problem.
Even the lazy developer will at least expect to be able to watch
flash videos
The workflow we have in F21 is this:

* Firefox asks if you want to install the Flash plugin.
* Firefox takes you directly to Adobe's download page for Flash.
* The user magically knows to select YUM for Linux (YUM) and downloads
the provided RPM.
* The user magically knows that he can double-click on the RPM (what's
an RPM?) to open GNOME Software and install Flash.

I guess the magic leaps are somewhat unfortunate, but it's still easier
than dealing with packages, I hope.
Post by Alexander Ploumistos
and listen to mp3s.
This is more difficult, since we cannot even point users towards where
they might possibly find an MP3 codec. I don't think we can fix this
without a super PAC or some form of regime change.

The workflow we have in F21 is this:

* Rhythmbox/Totem/Music/whatever tells you that you need a new codec to
play the audio.
* The graphical codec search looks in all enabled repositories for the
proper plugin.
* It fails because it's broken.

The expected behavior is for it to link to a wiki page that hints at
the existence of rpmfusion, but we can't legally do more than that.
Now, if the user somehow does manage to find the rpmfusion web site,
download the repo RPM, and double click on it (and if codec installer
gets fixed), then the codec installer should automatically find and
install the codecs he needs when he tries to play the music, so no need
for the user to know about gstreamer1-plugins-asdf-fugly et. al. (Of
course, none of this works if you try to use random video players that
don't know about PackageKit.)

So the experience should be 100% graphical. Finding the right RPM to
enable the external repository on the Adobe or rpmfusion website is a
pain and we need to improve that, but once you've done that you just
double click on it and don't need to worry about packages. I think the
biggest step we could improve here is the rpmfusion web site. They
really need to replace their homepage with [1], and explain that Fedora
apps will find the codecs you need automatically, so that users don't
have to keep asking for help with this.

[1] http://rpmfusion.org/Configuration
Alexander Ploumistos
2014-12-28 20:18:28 UTC
Permalink
Post by Michael Catanzaro
* Firefox asks if you want to install the Flash plugin.
* Firefox takes you directly to Adobe's download page for Flash.
* The user magically knows to select YUM for Linux (YUM) and downloads the
provided RPM.
* The user magically knows that he can double-click on the RPM (what's an
RPM?) to open GNOME Software and install Flash.
I guess the magic leaps are somewhat unfortunate, but it's still easier
than dealing with packages, I hope.
Why not throw in the first run help screen a couple of mentions to yum and
rpm with big, bold letters? Yum is tasty and easy to remember!
Post by Michael Catanzaro
and listen to mp3s.
This is more difficult, since we cannot even point users towards where
they might possibly find an MP3 codec. I don't think we can fix this
without a super PAC or some form of regime change.
Someone should have pitched this idea to Colbert before the elections, now
it's too late...
Is it reasonable to expect that mp3 codecs and libraries will make it to
the main repos sometime in 2017?
Post by Michael Catanzaro
So the experience should be 100% graphical. Finding the right RPM to
enable the external repository on the Adobe or rpmfusion website is a pain
and we need to improve that, but once you've done that you just double
click on it and don't need to worry about packages. I think the biggest
step we could improve here is the rpmfusion web site. They really need to
replace their homepage with [1], and explain that Fedora apps will find the
codecs you need automatically, so that users don't have to keep asking for
help with this.
Or yet another first run screen...
Chris Murphy
2014-12-28 20:44:58 UTC
Permalink
Post by Michael Catanzaro
The question is: is it more confusing for novice users to include a
graphical package manager by default, or to not include it?
tl;dr Oh absolutely it's confusing as well as incredibly frustrating.
I think software installations should only happen through an
application installer (e.g. GNOME Software, or OS Xs' App Store); or
through drag and drop copy to install. That method of installation on
OS X (I think it's actually a NeXT inheritance, we didn't have this on
OS 9 and older) is fantastic as it uninstallation: drag and drop into
the trash, empty trash.

Superfluous anecdote:
The first time I ran GNOME Package years ago, you should have seen the
WTFITS expression on my face. And that reaction wasn't about the UI,
it was the hours long process of coming to grips with part of the
software sausage making factory. I was surprised that this wasn't
abstracted from me.

The natural explanation is that I was coming from Candy Land OS. But
neither OS X nor Windows have a package manager. OS X does have a
package installer that executes .mpkg and .pkg file installs, but
there's no listing of what's installed or what can be installed and no
concept of a repository. App Store can do those things but both App
Store and GNOME Software post-date my first experience with a
graphical package manager - which was, I'd have preferred getting
sick. At least that'd have lasted two or three days and I'd be done
with it. Package management is the gift that keeps on giving.

But insofaras this is what we're stuck with, I really like what
Software has done to the UX, even though I had no choice but to first
grok packages and package management before it came along. These days
I don't mind yum and actually kinda like dnf. But still my preference
would be to see packages obliterated from user domain for sure.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct
Richard Hughes
2014-12-28 13:02:08 UTC
Permalink
On 28 December 2014 at 00:23, Alexander Ploumistos
Post by Alexander Ploumistos
Should Fedora build another program as a package manager
GNOME PackageKit is still available (and maintained upstream) and is
what I use for installing things like mingw packages that I need for
development. Just type "Packages" into the dash and gnome-software
will install it for you :)

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Alec Leamas
2014-12-28 15:48:27 UTC
Permalink
Post by Richard Hughes
On 26 December 2014 at 20:32, Alexander Ploumistos
If gnome-software aims to be novice-user-friendly, at least the latter should definitely be an option.
I don't see the logic there, sorry. Novice users don't understand the
fine nuances of the design choices of different desktop environments.
Possibly. But isn't there quite a difference between the "novice user"
and the Fedora Workstation target user i. e., developers?

If so, it doesn't need to be bad - Gnome is is certainly not Fedora. But
wouldn't it raise questions about the Gnome Software application's role
in the workstation product?

Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Michael Catanzaro
2014-12-28 17:05:00 UTC
Permalink
Post by Alec Leamas
Possibly. But isn't there quite a difference between the "novice user"
and the Fedora Workstation target user i. e., developers?
Not necessarily. I wrote:

"Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal."

Fedora currently suffers from the impression that it is a complicated
OS for advanced users only, and that novices (including novice
developers) should use Ubuntu instead.
Alec Leamas
2014-12-28 20:42:07 UTC
Permalink
Post by Michael Catanzaro
Post by Alec Leamas
Possibly. But isn't there quite a difference between the "novice user"
and the Fedora Workstation target user i. e., developers?
"Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really
narrow group (?)
Post by Michael Catanzaro
Fedora currently suffers from the impression that it is a complicated OS
for advanced users only, and that novices (including novice developers)
should use Ubuntu instead.
I have full sympathy for this goal. Question is if it aligns with the
developer target for the workstation?
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
Michael Catanzaro
2014-12-28 23:58:16 UTC
Permalink
Post by Alec Leamas
Hm... developers which never touches the terminal?! Seems like a really
narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle. We even
had a GUI for git. (git was a great blessing.) If we needed to run a
script (which was rare), we would double click on it. I used a terminal
because I never bothered to learn the git GUI and because one of the
IDEs was terrible, but I'm legitimately uncertain if I ever saw anyone
else working with a terminal. We were using Windows. I think it was a
relatively typical workplace.

Power users will always be able to use the terminal to great effect,
but if most developers have to use it to get work done, that's a pretty
damning statement as to the quality of our developer experience.
Ralf Corsepius
2014-12-29 00:32:57 UTC
Permalink
Post by Michael Catanzaro
Post by Alec Leamas
Hm... developers which never touches the terminal?! Seems like a
really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle.
May-be it's my age which gradually going to show, but I would not call
these people "developers" but would call these folks "IDE-operators".

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org
Stephen John Smoogen
2014-12-29 03:28:34 UTC
Permalink
Post by Michael Catanzaro
Post by Alec Leamas
Hm... developers which never touches the terminal?! Seems like a
really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle.
Maybe it's my age which gradually going to show, but I would not call
these people "developers" but would call these folks "IDE-operators".
It is your age, and there has been nothing gradual about it.. Look the
world has moved a lot in the last 30 years, and we have gone past the point
where current developers are humouring us old folk for making jokes about
IDE-operators. It is not a joke as much as a "wow those people are
pathetic" in the same way when we were younger and wondered why "old"
people still wore double polyester flare bottom pants in the late 1980's.

The world has moved on... and Fedora is moving with it. I realize that a
lot of us grognards have been trying to keep Fedora the Unix of 1987 when
X11 was cool and NNTP was the way things got communicated. However its not
going to happen.. and we either are going to have to get out of the way of
the steamroller or get rolled over it.

Ralf
--
devel mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
Ralf Corsepius
2014-12-29 09:00:26 UTC
Permalink
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas
Hm... developers which never touches the terminal?! Seems like a
really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle.
Maybe it's my age which gradually going to show, but I would not
call these people "developers" but would call these folks
"IDE-operators".
It is your age, and there has been nothing gradual about it.. Look the
world has moved a lot in the last 30 years, and we have gone past the
point where current developers are humouring us old folk for making
jokes about IDE-operators.
I am well aware this is what these people believe in and what marketing
folks are spreading to hype their tools. To me IDEs are "just tools" -
Additional tools, additional to terminals and editors.

I.e. a Linux distro, which is not supporting terminals/editors as part
of a "developer oriented distro" has not done its homework. I'd even go
one step further: Developing under Red Hat's default desktop (Gnome3) is
impossible without an IDE.

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora C
Michael Catanzaro
2014-12-29 15:29:28 UTC
Permalink
Post by Ralf Corsepius
I.e. a Linux distro, which is not supporting terminals/editors as part
of a "developer oriented distro" has not done its homework.
We should support both terminal-oriented and IDE-oriented workflows.
Right now, we have a terminal that works fine, but our IDE story is
very poor.
Post by Ralf Corsepius
I'd even go
one step further: Developing under Red Hat's default desktop (Gnome3) is
impossible without an IDE.
Have you ever tried to develop an app for GNOME? The truth is the
complete opposite. Until about three days ago, my development
environment was gedit and gnome-terminal, not because I prefer
developing with a terminal, but because we have no non-terrible IDEs. I
recently started using gnome-builder, which is an IDE in the very early
stages of development. It's currently a gedit replacement -- I still
need gnome-terminal open to do anything -- but it looks very promising.

Ever tried to make a GUI program with Glade, our "IDE" for creating
user interfaces? It's too hard for me. I gave up and nowadays write XML
UI files by hand with a text editor. I'm pretty sure almost all GNOME
developers do the same.
Richard Hughes
2014-12-29 09:50:53 UTC
Permalink
we either are going to have to get out of the way of the
steamroller or get rolled over it.
...and the people trying to keep up are getting eggs thrown at them. I
know lots of Red Hat developers worn down by the low-level harassment
on this mailing list, so much so, that they just stop pushing the
boundaries and go work on something else cool, e.g. ChromeOS.

Linux isn't UNIX. The desktop doesn't revolve about command line tools
anymore. If you can't accept that, you probably need to change
industry. Sorry to be blunt.

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Co
Reindl Harald
2014-12-29 12:27:20 UTC
Permalink
Post by Richard Hughes
we either are going to have to get out of the way of the
steamroller or get rolled over it.
...and the people trying to keep up are getting eggs thrown at them. I
know lots of Red Hat developers worn down by the low-level harassment
on this mailing list, so much so, that they just stop pushing the
boundaries and go work on something else cool, e.g. ChromeOS.
Linux isn't UNIX. The desktop doesn't revolve about command line tools
anymore. If you can't accept that, you probably need to change
industry. Sorry to be blunt.
it does not need to revolve around - but a "software manager" *completly
ignoring* non-GUI apps is a broken by design crap

sorry to be blunt too and the attitude you show repeatly like in the
second paragraph is the reason for a lot of harassment on this list
because a lot of this "cool new developers" don't give a damn about
their existing userbase or about expierience of others and only try to
catch new users which i do not need to be honest because if that
attitude don't stop i sit in front of a MacOSX clone designed for idiots
not able to make their own decisions

*nobody needs* that users, your attitude should be handholding them
learning to make decisions on their own and what are you doing is the
opposite, frankly you sound sometimes like the users not rely on GUI
only are dumb in your eyes because they don't realize the beauty of a
GUI app
Alec Leamas
2014-12-29 12:33:25 UTC
Permalink
Post by Richard Hughes
we either are going to have to get out of the way of the
steamroller or get rolled over it.
[cut]
Post by Richard Hughes
Linux isn't UNIX. The desktop doesn't revolve about command line tools
anymore. If you can't accept that, you probably need to change
industry. Sorry to be blunt.
What's important is that we want Workstation to be excellent for users who
never touch the terminal.
Great. But what if the design decisions based on this leads to a system
which becomes needlessly complicated for other users, which also uses
CLI tools?

Frankly, I think it's easier to alienate current devs (some of which
using CLI tools) than to attract new ones. So, pushing this goal too
hard might have consequences.
Post by Richard Hughes
on 28 December 2014 at 00:23, Alexander Ploumistos
Should Fedora build another program as a package manager?
GNOME PackageKit is still available (and maintained upstream) and is
what I use for installing things like mingw packages that I need for
development.
This certainly works, but is it really a reasonable trade-off in a
developer context where things like compilers and interpreters are part
of the very core? What role does Gnome Software play here? How fruitful
is the idea to hide packages in this context?

Note that I have full respect for your goals. I use Gnome myself, and I
didn't find 3.0 to painful :) It's just that I don't really see how the
priorities for Gnome Software aligns with developer realities (while
they make perfect sense for other types of users)

That said, everything is fine if the Fedora Workstation target user is a
developer just using GUI tools. But I don't see this in the PRD.

Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-con
Luya Tshimbalanga
2014-12-30 19:57:01 UTC
Permalink
Post by Alec Leamas
This certainly works, but is it really a reasonable trade-off in a
developer context where things like compilers and interpreters are
part of the very core? What role does Gnome Software play here? How
fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data
(supposedly mandatory starting on Fedora 22) will be displayed on Gnome
Software. Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.
The recent inclusion of add-on on Gnome Software brings useful solution
like installing Eclipse and select add-on like Java Development Tools.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
Alec Leamas
2014-12-30 20:34:29 UTC
Permalink
Post by Luya Tshimbalanga
Post by Alec Leamas
This certainly works, but is it really a reasonable trade-off in a
developer context where things like compilers and interpreters are
part of the very core? What role does Gnome Software play here? How
fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data
(supposedly mandatory starting on Fedora 22) will be displayed on Gnome
Software.
Glade is neither a compiler nor an interpreter, it's an IDE.
Post by Luya Tshimbalanga
Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.

But the question then becomes if this is the proper thing to do for the
Workstation target user which is a developer. As such, she will in many
cases want to install things like gcc, different python stacks using
collections, text processing tools and so on. None of which with a GUI.
She will also sometimes be interested in multiple desktops for testing
etc., causing the "MATE apps not visible" problem.

Bottom line: isn't there is a mismatch between Gnome Software (GUI
applications only) and the idea of a developer using both CLI and GUI
tools? And if so, how should it be handled?


Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/co
Luya Tshimbalanga
2014-12-30 21:58:47 UTC
Permalink
Post by Alec Leamas
Post by Luya Tshimbalanga
This certainly works, but is it really a reasonable trade-off in a
developer context where things like compilers and interpreters are
part of the very core? What role does Gnome Software play here? How
fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data
(supposedly mandatory starting on Fedora 22) will be displayed on Gnome
Software.
Glade is neither a compiler nor an interpreter, it's an IDE.
My bad.
Post by Alec Leamas
Post by Luya Tshimbalanga
Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for
the Workstation target user which is a developer. As such, she will in
many cases want to install things like gcc, different python stacks
using collections, text processing tools and so on. None of which with
a GUI. She will also sometimes be interested in multiple desktops for
testing etc., causing the "MATE apps not visible" problem.
What about DevAssistant that comes with Fedora Workstation? Have you
tried it?
MATE apps not visible means they needed app-data included on their
.desktop files hence the pleas from Richard Hughes.
The case of multiple desktop installation reaches advanced use
territory meaning advanced tool like yumex.
Post by Alec Leamas
Bottom line: isn't there is a mismatch between Gnome Software (GUI
applications only) and the idea of a developer using both CLI and GUI
tools? And if so, how should it be handled?
No. Fedora Workstation already provided needed tools for CLI like Gnome
Terminal included by default.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-condu
Alec Leamas
2014-12-30 22:30:17 UTC
Permalink
Post by Luya Tshimbalanga
Post by Alec Leamas
Post by Luya Tshimbalanga
Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for
the Workstation target user which is a developer.
[cut]
Post by Luya Tshimbalanga
What about DevAssistant that comes with Fedora Workstation? Have you
tried it?
No, it doesn't seem to solve any problem for me (?). That said, while
such solutions certainly might be useful a generic installer application
represents some kind of foundation I think all developers will need,
sooner or later. Different devs, different ideas, different needs - not
all can be shrink-wrapped.
Post by Luya Tshimbalanga
MATE apps not visible means they needed app-data included on their
.desktop files hence the pleas from Richard Hughes.
The case of multiple desktop installation reaches advanced use
territory meaning advanced tool like yumex.
Still the same question: is there a mismatch between the GUI only Gnome
Software (GS) and the Workstation target user presumably using both CLI
and GUI tools + perhaps multiple desktops?

If you describe this as "advanced use", should we read this as if the
Workstation developer usecase is too advanced for GS?

And if the target usecase is too advanced for GS, what is then the role
for GS in the Workstation product?


Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct
Alec Leamas
2014-12-30 22:39:06 UTC
Permalink
Post by Luya Tshimbalanga
Post by Alec Leamas
Bottom line: isn't there is a mismatch between Gnome Software (GUI
applications only) and the idea of a developer using both CLI and GUI
tools? And if so, how should it be handled?
No. Fedora Workstation already provided needed tools for CLI like Gnome
Terminal included by default.
Again: this is not about Gnome (I'm an overall happy Gnome user). It's
about Gnome Software, the installer, and only that.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Chris Murphy
2014-12-30 23:31:52 UTC
Permalink
The Workstation PRD explicitly, more than once states developers of
all sorts are the primary target market. The special focus is for a
platform for application development.

I wonder two things:

a.) Should more developer tools be installed by default?

'dnf group list' shows the following items with "develop" in the group name:
C Development Tools and Libraries
D Development Tools and Libraries
Development Tools
RPM Development Tools
While 'dnf group list hidden' additional shows
Development and Creative Workstation
Development Libraries
GNOME Software Development
Java Development
[skipping KDE and Xfce specific items]
Legacy Software Development
LibreOffice Development
Perl Development
X Software Development



b.) Would it be helpful, friendlier, and better emphasize the special
focus, if these group install items mentioned above were exposed in
GNOME Software with an appropriate icon? GNOME Software is already
smart enough to lump OS updates as a single line item as if it were a
metapackage, when actually it's a collection of the current system
only related packages available for updating. So there's already a
UI/UX precedent for displaying non-applications within Software.


Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/cod
Richard Hughes
2014-12-31 15:25:39 UTC
Permalink
Post by Chris Murphy
b.) Would it be helpful, friendlier, and better emphasize the special
focus, if these group install items mentioned above were exposed in
GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire
comps tree" makes a lot of sense. We need translations, icons,
screenshots, and of course approval from the Fedora/GNOME designers.
Addons would be a logical place for this, although I think it probably
needs more design thought about how to handle these "non-application"
metagroupings. Installing a compiler is something that *something*
needs to handle, I'm just not sure if that should be gnome-software
itself or something that *uses* gnome-software to do the correct thing
and to handle updates.

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Alec Leamas
2015-01-02 10:02:18 UTC
Permalink
Post by Richard Hughes
Post by Chris Murphy
b.) Would it be helpful, friendlier, and better emphasize the special
focus, if these group install items mentioned above were exposed in
GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire
comps tree" makes a lot of sense.
Here is also questions whether this is the right thing to do, I guess
many packages, notably -devel ones, doesn't belong to a group. How
should these then be handled?

And from a user perspective, if you already *know* that you need to
install e.g., gcc or foo-devel first finding the proper group to
install seems a bit awkward.

Perhaps this path also might create pressure to include all sorts of
things into the groups, a "misuse" of the groups feature?

[cut]
Post by Richard Hughes
Installing a compiler is something that *something*
needs to handle, I'm just not sure if that should be gnome-software
itself or something that *uses* gnome-software to do the correct thing
and to handle updates.
Here is a some common ground, indeed. Seems that we agree on that
installing CLI stuff is something that should be handled in a
developer-oriented workstation (not that you have said something else,
but some others).

Now, in my mind installing/updating non-GUI software is not a
corner-case for a developer - it's probably the most common installation
done even when working with GUI tools. Because even so you need tools
such as compilers but also libraries/-devel packages. And often lot's of
them.

From this perspective, I guess that if gnome-software (g-s) upstream
defines installing CLI stuff as something which should be handled by
"something else", I cannot really see the point handling updates in g-s.
Rather, g-s would then become a nice add-on to browse and install GUI
applications.

In the end, isn't this one hand about if gnome-software's upstream is
willing to undertake the work to adapt also to the developer usecase?
And on the other, which tool the workstation group should use for
graphical software installations? Because as of now, gnome-software just
doesn't fit the workstation bill?

Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: ht
Richard Hughes
2015-01-02 10:42:10 UTC
Permalink
Here is a some common ground, indeed. Seems that we agree on that installing
CLI stuff is something that should be handled in a developer-oriented
workstation
If you're using gcc, you're using a terminal. We supply two command
line package managers (dnf, yum) which allow you to do this. If you're
using eclipse, then we already allow applications to install addons
for different use-cases (which can have deps like gcc),
Now, in my mind installing/updating non-GUI software is not a corner-case
for a developer - it's probably the most common installation done even when
working with GUI tools.
Citation needed.
From this perspective, I guess that if gnome-software (g-s) upstream defines
installing CLI stuff as something which should be handled by "something
else", I cannot really see the point handling updates in g-s.
I don't see how you've got to this logic at all.
In the end, isn't this one hand about if gnome-software's upstream is
willing to undertake the work to adapt also to the developer usecase?
No! GNOME Software is designed as an application installer for GNOME.
We're using gnome-software in Fedora workstation, but that doesn't
mean that the upstream application has to align with the workstation
PRD 100% or else it's "not suitable".
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably
spend about 10 minutes installing development packages (on the command
line) when setting up a new OS instance. I then spend a year or so of
installing or removing the odd application, and a few minutes every
week applying updates. I don't think GNOME Software is hugely useful
for installing low-level developer packages, which is fine. It doesn't
mean it's not a useful application.

Rather than talking in riddles in your emails, could you also please
suggest what needs to be done? Are you in favour of ripping out
gnome-software and installing yumex in the workstation image? Do you
have an alternate application proposal with design mockups?

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code o
Alec Leamas
2015-01-03 13:57:10 UTC
Permalink
Post by Richard Hughes
Because as of now, gnome-software just doesn't fit the workstation bill
I think you're misunderstanding what most developers do. We probably
spend about 10 minutes installing development packages (on the command
line) when setting up a new OS instance. I then spend a year or so of
installing or removing the odd application, and a few minutes every
week applying updates. I don't think GNOME Software is hugely useful
for installing low-level developer packages, which is fine. It doesn't
mean it's not a useful application.
I don't know if "most" developers works with more or less just one
toolchain and environment as you describe. At least "some" actually
works in a lot of projects, with different development packages and
sometimes also tools.

That said, what about describing the developer usecase as a project,
focusing on a user using both GUI and CLI tools?

- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.

Installing the toolchain seems like DevAssistant to me. Besides this, I
understand your position as if users are supposed to use yum/dnf except
for GUI development tools and their dependencies (?)

To my mind, forcing user to the prompt to this extent is less than
ideal. A GUI installer certainly has advantages even for an occasional
CLI user. And having to use different installers is a Bad Thing.
Post by Richard Hughes
Rather than talking in riddles in your emails, could you also please
suggest what needs to be done? Are you in favour of ripping out
gnome-software and installing yumex in the workstation image? Do you
have an alternate application proposal with design mockups?
At this point, I'm just trying to understand the usecase. Without that,
decisions like using yumex instead of gnome-software makes no sense, nor
does mock-ups. It's also a question to what extent upstream is willing
to support this usecase.

That said, my gut feeling is that the balance between simplicity and
functionality is quite different for a "novice user" and a developer and
that this needs to be handled with different modes, views or so (if
gnome-software should handle it). Adding things like random CLI
applications, -devel packages etc. to the search result for a novice
user is just not an option, agreed. But IMHO a developer probably needs
it in some form.

Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Hedayat Vatankhah
2015-01-03 18:45:11 UTC
Permalink
<....>
That said, my gut feeling is that the balance between simplicity and
functionality is quite different for a "novice user" and a developer
and that this needs to be handled with different modes, views or so
(if gnome-software should handle it). Adding things like random CLI
applications, -devel packages etc. to the search result for a novice
user is just not an option, agreed. But IMHO a developer probably
needs it in some form.
Search results can be presented in groups (same as groups already used
in the main screen): Sound/Graphics/Fonts/Development Libraries/etc...

Usually, when a user search for some terms, he already know its
category. In fact, I think grouping search results is useful even in the
current state without any CLI tools or development libraries. It needs a
good UI design though. Maybe search results can be 'tagged' with their
category, and a list of categories (of the results) is presented
somewhere at the top/side so that the user can select one or some tags
so that only packages from those categories will be shown. Or, the UI
might ask the user (ouch, frowned upon!) some questions (if results were
scattered in many categories) so that it can fine tune the results.

Thanks,
Hedayat
Cheers!
--alec
Chris Murphy
2015-01-04 05:50:48 UTC
Permalink
Post by Richard Hughes
Post by Chris Murphy
b.) Would it be helpful, friendlier, and better emphasize the special
focus, if these group install items mentioned above were exposed in
GNOME Software with an appropriate icon?
We could do this right now, although I don't think "expose the entire
comps tree" makes a lot of sense. We need translations, icons,
screenshots, and of course approval from the Fedora/GNOME designers.
Addons would be a logical place for this, although I think it probably
needs more design thought about how to handle these "non-application"
metagroupings.
Sounds very reasonable.

Qualifying my position: I'm fairly comfortable with yum/dnf group
installs now, so this isn't a sticking point for me personally. This
really is the Workstation WG's turf to define what kind of UI/UX they
want to have for developers new to the platform. And I'm inclined to
think keeping developers (even CLI dominant ones) away from the
esoterics of platform packaging is a good thing. I don't know if
Software will instinctually be their go to for such a thing, so that's
also a question someone needs to answer.
Post by Richard Hughes
Installing a compiler is something that *something*
needs to handle, I'm just not sure if that should be gnome-software
itself or something that *uses* gnome-software to do the correct thing
and to handle updates.
Could maybe be in scope for Fedora dev assistant also.
http://fedoraproject.org/wiki/Features/DevelopersAssistant
"Make the development on Fedora easier for beginners."
"Try to install package containing setup for your favourite language."
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fed
Alexander Ploumistos
2014-12-30 22:45:43 UTC
Permalink
Post by Luya Tshimbalanga
MATE apps not visible means they needed app-data included on their
.desktop files hence the pleas from Richard Hughes.
Perhaps I couldn't get my thoughts in order when I started this thread, but
among the things I wrote was that although MATE apps now have AppData
files, they are not visible in gnome-software, because of the
GNOME_SOFTWARE_COMPATIBLE_PROJECTS environment variable.
Reindl Harald
2014-12-29 12:10:02 UTC
Permalink
Post by Stephen John Smoogen
It is your age, and there has been nothing gradual about it.. Look the
world has moved a lot in the last 30 years, and we have gone past the
point where current developers are humouring us old folk for making
jokes about IDE-operators
no, it is not the age

i bought my first PC in 1998, started with Visual Basic and after only
payling a little around with Linux the years before i switched in summer
2006 from Windows to Linux due setup a new working machine and don't use
dual-boot that time

you can't imagine how many things i did with the GUI to find out shell
commands are much more powerful and for the most things a 3 liner bash
script can replace the most GUI's

that's why i call it harmful try to hide the shell from users
Alexander Ploumistos
2014-12-29 13:52:31 UTC
Permalink
Post by Reindl Harald
that's why i call it harmful try to hide the shell from users
Well, to be fair nobody is trying to hide the shell and GNOME terminal has
received some love in the latest releases. Package suggestions in the
terminal can be useful for beginners and for advanced users, who don't want
to do the "yum whatprovides */foo" and "yum install bar" dance. It can't
stop you from dancing, though.

When I was 3 years old, I learned to type mechanically BRUN SABOTAGE (
http://en.wikipedia.org/wiki/Sabotage_%28video_game%29), later at school we
learned Logo, so I was conditioned from an early age to textual interfaces.
Then came System 6 and a few years later, windows 95. Until GNOME 3,
perhaps with the exception of Enlightenment, every "mainstream" DE was a
retake of that paradigm. Sure, with every iteration they became much more
functional and polished, but GNOME 3 was the first that pushed me out of my
comfort zone. I had to get acquainted with conky (yet another silver
lining) and up to the time that the first gnome extensions came out, I had
a little trouble getting things done. I got used to it though and with time
I came to appreciate it. Granted, it's certainly not suited for every
machine and perhaps not for every user, particularly those whose brains
have been hardwired with time to a certain modus operandi. It might also
need some tweaking to get it to one's taste, but that has always been the
case with every DE. Every new release brings huge improvements over the
last one and I'd say that from 3.6 onwards, there is nothing I miss from
version 2.

What amazes me, is that novice computer users find their way around GNOME's
UIs quite easily (more easily than I did anyway), which means that the
Human Interface Guidelines do work. People who had only used windows very
few times in the past, started getting things done in under an hour. Sure,
they didn't need to monitor the health of their RAID10 arrays, or the
processes that generate traffic on eth3, but that is absolutely possible as
well.

I still have a couple of minor complaints. The first is that there is a
chasm between the configuration options that are offered in the UI and
those in Gsettings, or between Tweak Tool and CSS/JavaScript, if you want
to tweak the UI itself. I think there is some room for something like an
"advanced view" in the Settings panel. The second is about the combination
of GNOME and Fedora, in that at times it feels like the interface pulls in
one direction and the underlying system pulls in the opposite. But this
constant change keeps one on one's toes and that's why we use Fedora, is it
not? Constantly crying wolf, only makes it harder to notice when the wolf
is actually on our doorstep.
Chris Murphy
2014-12-29 17:25:46 UTC
Permalink
Post by Michael Catanzaro
Post by Alec Leamas
Hm... developers which never touches the terminal?! Seems like a
really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle.
Maybe it's my age which gradually going to show, but I would not call
these people "developers" but would call these folks "IDE-operators".
It is your age, and there has been nothing gradual about it.. Look the world
has moved a lot in the last 30 years, and we have gone past the point where
current developers are humouring us old folk for making jokes about
IDE-operators. It is not a joke as much as a "wow those people are pathetic"
in the same way when we were younger and wondered why "old" people still
wore double polyester flare bottom pants in the late 1980's.
From 1984 to 2001 there was a rather popular platform that didn't have
a CLI. It wasn't hidden, it simply didn't exist. Its replacement has a
terminal application, but the developer CLI tools are an optional
installation, it remains predominately a GUI development environment.

So I don't think it's an age thing, but rather a lack of awareness of
the historical and current state of software development in the wider
world. Developers have been developing software without CLIs for a
long time.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: h
Alexander Ploumistos
2014-12-29 18:22:01 UTC
Permalink
Post by Chris Murphy
From 1984 to 2001 there was a rather popular platform that didn't have
a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2. It did have a cmd.exe.
Chris Murphy
2014-12-29 18:39:23 UTC
Permalink
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos
Post by Alexander Ploumistos
Post by Chris Murphy
From 1984 to 2001 there was a rather popular platform that didn't have
a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2.
Nope. Vastly more popular than OS/2.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Co
Reindl Harald
2014-12-29 18:47:26 UTC
Permalink
Post by Chris Murphy
On Mon, Dec 29, 2014 at 11:22 AM, Alexander Ploumistos
Post by Alexander Ploumistos
Post by Chris Murphy
From 1984 to 2001 there was a rather popular platform that didn't have
a CLI. It wasn't hidden, it simply didn't exist.
I take it you are referring to OS/2.
Nope. Vastly more popular than OS/2
besides that it makes people tired speaking in riddles the only reason i
am active in that thread is to notice that people should not make
differences between GUI/CLI and so not lower rate CLI apps

* there are users just browse the web, chat and read e-mail
* there are users doing a lot of things in a terminal
* there are users doing only sometimes things in a terminal

it always depends on the goal to achive for a task

well, and that is why there are tasks you *can * do 1000 times more
better in a terminal or in a 3-liner shell script with one or two params
and others where you are much faster using the GUI

this world is grey

hence everybody start using Linux should *know* there are terminal apps
and which ones and make his own decision if they fit the usecase and in
doubt be able to use both worlds

what makes me angry is "nobody should need to use a terminal"
that's not the point, a new user just needs to know the capabilities
don't hide them from these people because they are born too late

*show them* all the nice capabilities and don't hide half

if they donÀ't want to use them - fine!
but if they don't use them just they don't know about is a damage
Miloslav Trmač
2015-01-02 20:05:32 UTC
Permalink
----- Original Message -----
Post by Reindl Harald
well, and that is why there are tasks you *can * do 1000 times more
better in a terminal or in a 3-liner shell script with one or two params
and others where you are much faster using the GUI
this world is grey
hence everybody start using Linux should *know* there are terminal apps
and which ones and make his own decision if they fit the usecase and in
doubt be able to use both worlds
The way I view it, there are two fairly separate cases:

A) Application development (with a wide definition of an “application” as “teaching the system to do something new”, i.e. all the way from simple aliases and pipelines through 10-line shell scripts all the way to 10k-line shell or Perl script monsters).

Yes, these things can’t be done in our GUIs nearly as easily, but there _really are_ large groups of people who never will, don’t want to, or are perhaps even forbidden from, doing such things (consider cashiers or bank tellers). So it is quite reasonable to hide these capabilities until the user indicates some kind of interest in developing applications (where “indicates interest” today probably means a Google search, so we can get away with requiring one or two non-obvious but easy to do steps to get developer access).

Also note that the shell prompt is one of the worst application development environments still in wide use. Very weak and inconsistent programming language, no module system, minimal auto-completion/intelligence, no inline help, horrible debugging tools even compared to 1980s Turbo Pascal. It _should_ be possible to have a programming environment that is vastly easier to use than the shell prompt we have; but I have very little hope of this improving in the medium term.


B) Application usage, interacting with applications somebody else wrote.

Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.

So to get the best sofware system possible we should 1) actually write such better GUIs, and 2) tell people that such better GUIs are available.
Post by Reindl Harald
what makes me angry is "nobody should need to use a terminal"
“Nobody should need to use a terminal” is a case of 2) above [and partially a case of “shell is a horrible application development environment” from A)].


Note that "nobody should need to“ and “currently nobody needs to” are very different.

And there is a major difficulty: doing 2) before 1) is done can be counter-productive, counter-productivity or in the worst case just dishonest; but doing 1) without 2) is likely impossible if the CLI capabilities keep expanding faster than we can add GUI interfaces to the same capabilities. So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces.
Mirek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org
Reindl Harald
2015-01-03 03:47:48 UTC
Permalink
Here, GUIs _as a category_ (not necessarily the GUIs we are currently providing) should always be better than CLIs _as a category_ simply because the GUI can in the worst case just copy the CLI layout and behavior so it will not be worse than a CLI; and then there are all the graphics and mouse interactions and shadows and animation that a GUI can do but a CLI can’t.
no it can't

a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... >
newfile" is impossible because you *never* can build a GUI that is the
same way flexiable and still useable
And there is a major difficulty: doing 2) before 1) is done can be counter-productive, counter-productivity or in the worst case just dishonest; but doing 1) without 2) is likely impossible if the CLI capabilities keep expanding faster than we can add GUI interfaces to the same capabilities. So I can see a case for being vocal about “nobody should need to use a terminal” even now; but that case critically depends on the ability of the community to actually write the better non-terminal interfaces.
but you can't and won't use the GUI the same way on remote machines over
slow lines as you can use a CLI and hence smart, short and repeatable
tasks are done in shell-scripts because a "ssh ***@host
/usr/local/bin/task.sh" is done before you remote GUI even starts
Nico Kadel-Garcia
2015-01-03 07:37:50 UTC
Permalink
Post by Reindl Harald
Post by Miloslav Trmač
Here, GUIs _as a category_ (not necessarily the GUIs we are currently
providing) should always be better than CLIs _as a category_ simply because
the GUI can in the worst case just copy the CLI layout and behavior so it
will not be worse than a CLI; and then there are all the graphics and mouse
interactions and shadows and animation that a GUI can do but a CLI can’t.
no it can't
a gui for "grep file | grep -v x | grep -y | sort | uniq | awk... > newfile"
is impossible because you *never* can build a GUI that is the same way
flexiable and still useable
That *particular* widget has been done, with various search and regexp
widgets. But they tend to be done quite badly, with each deverloper
going "ooohhh, shiny!!!" and concentrating on feature addition and
showing off all the cool widgets. Kind of like Gnome, actually.

There's an old, fascinating essay about this by Eric Raymond, called
"The L:uxury of Ignorance", over 10 years ago. Gnome tools tend to
violate most of the guidelines, and the software installation tool
violates these in particular:

11. What does my software look like to a non-technical user who
has never seen it before?

And from the guidelines Eric included from a letter writer's submission:

* Can you gracefully and easily duplicate your tools and
configuration for a similar installation?
* Are there settings you can do from the command line or
hand-editing config files that cannot be done from the GUI?

In case you can't guess, those are postscript guidelines were written by me
Post by Reindl Harald
but you can't and won't use the GUI the same way on remote machines over
slow lines as you can use a CLI and hence smart, short and repeatable tasks
is done before you remote GUI even starts
The GUI's can be handy, especially because yum text output becaumes
difficult to script unnecessary header information and the erratic
newlines for long package names.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
Alexander Ploumistos
2014-12-29 19:52:08 UTC
Permalink
Post by Chris Murphy
Nope. Vastly more popular than OS/2.
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then
were much like feature phones are today. You got basic functionality in the
standard package with the very beautiful UI and if you wanted to do
anything other than draw in MacPaint or edit text files, you had to give $$
to Apple. So one could argue that the lack of a CLI (among other
developer/power user tools) was part feature, part marketing decision.
Chris Murphy
2014-12-29 21:01:38 UTC
Permalink
On Mon, Dec 29, 2014 at 12:52 PM, Alexander Ploumistos
Post by Chris Murphy
Nope. Vastly more popular than OS/2.
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then were
much like feature phones are today.
This is beside the point. However, even if feature phones had an
installable developer tools do you think you'd develop applications on
the feature phone? Could you develop a HyperCard or Photoshop 1.0 type
of application? And you think it'd be usable? And you think it'd be a
ground breaking, game changing set of applications that would create a
multi-billion dollar industry? No on all counts so it's not only
beside the point, the metaphor is wrong.
You got basic functionality in the
standard package with the very beautiful UI and if you wanted to do anything
other than draw in MacPaint or edit text files, you had to give $$ to Apple.
So one could argue that the lack of a CLI (among other developer/power user
tools) was part feature, part marketing decision.
None of that matters. The argument is that someone is only a developer
if they are using a platform with a CLI, specifically dominating the
process at a minimum, if not required to successfully develop
software. And a real developer would only ever choose such a platform.
And the cherry on this ridiculous hot fudge sundae, is that somehow
this perceived requirement might be changing due to one's age.

The first assertion is historically and linguistically wrong. The
second assertion is anachronistic, as that platform appeared 31 years
ago. I'd be surprised if the median age on this list is 31, so most
people on this list probably were in diapers at the time a
multi-billion dollar industry was being created by developers using a
CLI-less development environment.

Best as I can tell real developers are adaptable and use tools that
are available, but also aren't shy about asking for and developing new
development tools. Hughsie wrote the most functional, most stable, 1.0
version application I've ever used, and faster than Matilda the Witch
could flick her wand. Oh but if he wasn't slovenly dependent on CLI
tools at the time, he wouldn't be a developer, he'd be an operator.
It's just so absurd as to defy belief, and yet he's having eggs thrown
at him? WTFsauce. This reads like a really bad comedy show where the
distinctly not funny comedian starts throwing tomatoes at the audience
for not laughing. Oh but he's not a real comedian, because he wasn't
on a stage.

There is such a thing as listening too much to a community that can
act like an anchor to innovation. I think the most active developers
wanting a stronger IDE need one more thing, and that's a better filter
so they can ignore the egg throwers. The real developers are those
who are actively getting things done, and are not defined by what
interface they're using.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of
Reindl Harald
2014-12-29 21:10:55 UTC
Permalink
The real developers are those who are actively getting things done,
and are not defined by what interface they're using.
yes, and that's why the real developers need to get aware of *all*
capabilities of their operating system and not got hidden useful apps
because their icon is not large enough or in a format with too less
colors or not enough screenshots provided upstream
Alexander Ploumistos
2014-12-30 00:58:36 UTC
Permalink
Post by Chris Murphy
Post by Alexander Ploumistos
OK, yes, my Macintosh Classic didn't have a cli. But the Macs back then
were
Post by Alexander Ploumistos
much like feature phones are today.
This is beside the point. However, even if feature phones had an
installable developer tools do you think you'd develop applications on
the feature phone? Could you develop a HyperCard or Photoshop 1.0 type
of application? And you think it'd be usable? And you think it'd be a
ground breaking, game changing set of applications that would create a
multi-billion dollar industry? No on all counts so it's not only
beside the point, the metaphor is wrong.
For a little over a decade, java-based and other apps for feature phones
generated billions for those involved, in either direct revenue or license
fees, until the smartphones started replacing the PDAs and becoming
mainstream. Much like closed-source feature phones, Apple kept control over
the hardware and the software of Macs, leaving little -if any- leeway for
users and developers. The Macs were great productivity machines in that
they had a good set of tools for specific tasks, a pleasant interface that
allowed easy access to those tasks and they rarely crashed on the job,
because Apple didn't have to worry about the software being glitch-free on
every conceivable hardware combo. Just like my KRZR is still great at
placing calls, sending texts and playing my tunes. My own coding skills are
completely irrelevant. On principle alone, I wouldn't choose to write
anything on such a platform (even if it had a cli from the very beginning).
Post by Chris Murphy
None of that matters. The argument is that someone is only a developer
if they are using a platform with a CLI, specifically dominating the
process at a minimum, if not required to successfully develop
software.
Not my argument. Someone who uses the terminal is in no way a better
developer than someone who works with a GUI. Coding and interfacing with
the machine are two very different things. However, a linux developer (as
in someone who develops programs to be run on linux systems, not a
developer in general who just happens to have his tools of choice running
on linux) who ignores the existence of shells is like an OS X developer who
has never used, well... OS X.
Post by Chris Murphy
I'd be surprised if the median age on this list is 31, so most
people on this list probably were in diapers at the time a
multi-billion dollar industry was being created by developers using a
CLI-less development environment.
What does the CLI-less-ness of Macs and their gazillion dollar industry
have to do with the rest of this discussion though? Windows have had a
cmd.exe (with its tremendous limitations) since time immemorial and several
years ago a "Power Shell" was added. Some users (and developers) know
they're there, most do not. Does that have anything to do with Microsoft's
dominance over the PC market? As for the age thing, I may have owned a IIe
and a Macintosh Classic, but over the years I've only come across five
people who happened to have used anything Apple made in that era -and I've
lived in seven cites in two different countries. Most computer users I knew
at the time were on Sinclairs, IBM and IBM-compatibles and later on Amiga
and Atari.

Exactly because Apple had set up a money barrier between users and
developers, a user would never get the chance to tinker with the internals
of their system, whereas on linux everyone is free to do as much or as
little as they please. Feel like checking if there is anything left from
that C class you took ages ago? Just install gcc and give it a shot. You
think you could automate some mundane, repetitive task you have to do every
now and then? Fire up vi (or emacs, nano, gedit, pluma, leafpad etc.) and
write a shell script and feed it to your always-present shell. You might
botch your system, but that's part of the learning process. In System 5, 6
and 7, there was an extra step in that process, which involved several
hundred $ changing hands. And yes, there wasn't a shell.
Post by Chris Murphy
Hughsie wrote the most functional, most stable, 1.0
version application I've ever used, and faster than Matilda the Witch
could flick her wand. Oh but if he wasn't slovenly dependent on CLI
tools at the time, he wouldn't be a developer, he'd be an operator.
It's just so absurd as to defy belief, and yet he's having eggs thrown
at him? WTFsauce. This reads like a really bad comedy show where the
distinctly not funny comedian starts throwing tomatoes at the audience
for not laughing. Oh but he's not a real comedian, because he wasn't
on a stage.
I have to agree with you here. I haven't had the pleasure of Ms Matilda's
acquaintance, but gnome-software is incredibly fast, especially given the
tasks it performs.
Also, things should never get personal and snarky comments are detrimental
to the discussion. If a real issue occurs that can't be amicably resolved
here or in bugzilla, there are community elected steering committees that
can take over.
Post by Chris Murphy
There is such a thing as listening too much to a community that can
act like an anchor to innovation.
Only a small subset of a much larger community is active on these lists.
Those who are vocal about an issue here or in the forum, are those who feel
affected by it in a good or mostly in a bad way. They do not necessarily
represent an equal proportion of the community. Perhaps regular or sporadic
surveys might help get some input from the non-vocal users. And let's not
forget that not everyone here has english as their mother tongue, so things
can and do get lost in translation.

The fact that I take from this thread and which keeps getting buried in the
avalanche of postings, is that there is an ongoing and good effort to
provide graphical means for users to install, configure and use Fedora on
their computers, without ever having to use a terminal because there is no
alternative. Those who enjoy using a terminal will still be able to perform
those same tasks without bothering with the UI elements. New users will
always have the opportunity to discover the awesomeness of a shell, but by
choice; not by need.
Chris Murphy
2014-12-30 06:17:58 UTC
Permalink
On Mon, Dec 29, 2014 at 5:58 PM, Alexander Ploumistos
What does the CLI-less-ness of Macs and their gazillion dollar industry have
to do with the rest of this discussion though?
None really. I was just pushing back against the idea platform CLIness
has anything to do with who is a developer vs IDE controller.
The fact that I take from this thread and which keeps getting buried in the
avalanche of postings, is that there is an ongoing and good effort to
provide graphical means for users to install, configure and use Fedora on
their computers, without ever having to use a terminal because there is no
alternative. Those who enjoy using a terminal will still be able to perform
those same tasks without bothering with the UI elements. New users will
always have the opportunity to discover the awesomeness of a shell, but by
choice; not by need.
I agree.

I'd still like to see a fedup + Software integration to make upgrades
a routine aspect of the Fedora lifecycle rather than a major and
seemingly risky event. Already, updating with Software is a completely
trustworthy, single button click, single reboot experience. That's not
at all the experience I had recently on Windows.

Fedora has a certain advantage with the fast development cycle, which
is that the upgrades aren't as big a leap in package versions as it is
between e.g. Ubuntu's LTS releases. So I don't see the cycle time
frame as inherently a problem, even for novices. Hardware OEM
projects, like Sputnik, gravitate toward Ubuntu because a 5 year
support model is familiar to them, and probably also that Canonical
offers pay for support.

More problematic, is Rawhide languishing during the intensive
refinement needed after branch, followed by the sigh of
exhaustion/relief, followed by the effort of a new wind up. I remain a
proponent of making beta higher quality so that more people are wiling
to test and find the major bugs before final is baked; and also to
make the testing time period between beta and final less frantic that
also risk late slips.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-condu
Orcan Ogetbil
2014-12-29 06:34:15 UTC
Permalink
On Sun, Dec 28, 2014 at 2:42 PM, Alec Leamas
Post by Alec Leamas
Hm... developers which never touches the terminal?! Seems like a
really narrow group (?)
Not really. At a previous workplace, we used two different IDEs for the
two programming languages we needed to work with, and wrote GUI apps to
handle whatever we might otherwise need a terminal to handle.
May-be it's my age which gradually going to show, but I would not call these
people "developers" but would call these folks "IDE-operators".
We have a number of such folks at work too. I guess no one held their
hands and showed them the power of the terminal before. Needless to
say, a few demonstrations is almost always sufficient for them to
realize what they have been missing and they usually change their
workflow and start using the terminal by their own will.

I believe the main reason for this is that Windows does not ship with
a decent terminal, and most of these folks grew up with Windows.
Hopefully, this will change.

Best,
Orcan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-condu
Peter Hutterer
2014-12-29 00:19:58 UTC
Permalink
Post by Alec Leamas
Post by Michael Catanzaro
Post by Alec Leamas
Possibly. But isn't there quite a difference between the "novice user"
and the Fedora Workstation target user i. e., developers?
"Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really
narrow group (?)
it's not as narrow as you may think, developers may use the terminal
selectively for some tasks and the GUI exclusively for others. That subset
isn't the same for all developers, so you end up having to provide all
features working well in the GUI.

e.g. I hardly ever use nautilus to handle fils, but I also hardly ever use
the terminal for any configuration, connecting to networks, firewall stuff,
etc. etc. I hardly ever use it to start non-terminal apps except for
eog/evince.

so even though I use the terminal heavily, I still would count myself in the
above group and I definitely need a good GUI around my terminals. And,
I want my desktop to be simple and get out of the way of what I actually
want to do.

Cheers,
Peter
Post by Alec Leamas
Post by Michael Catanzaro
Fedora currently suffers from the impression that it is a complicated OS
for advanced users only, and that novices (including novice developers)
should use Ubuntu instead.
I have full sympathy for this goal. Question is if it aligns with the
developer target for the workstation?
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-
Reindl Harald
2014-12-29 00:32:05 UTC
Permalink
Post by Peter Hutterer
Post by Alec Leamas
Post by Michael Catanzaro
Post by Alec Leamas
Possibly. But isn't there quite a difference between the "novice user"
and the Fedora Workstation target user i. e., developers?
"Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal."
Hm... developers which never touches the terminal?! Seems like a really
narrow group (?)
it's not as narrow as you may think, developers may use the terminal
selectively for some tasks and the GUI exclusively for others. That subset
isn't the same for all developers, so you end up having to provide all
features working well in the GUI.
exactly!

but not hide terminal apps and pretend nobody should have a need to use
them these day
Post by Peter Hutterer
e.g. I hardly ever use nautilus to handle fils, but I also hardly ever use
the terminal for any configuration, connecting to networks, firewall stuff,
etc. etc. I hardly ever use it to start non-terminal apps except for
eog/evince.
so even though I use the terminal heavily, I still would count myself in the
above group and I definitely need a good GUI around my terminals. And,
I want my desktop to be simple and get out of the way of what I actually
want to do.
exactly!

but that completly different to "a user should not need to know what a
terminal is or find terminal apps in the software center even if he
knows them by name for good reasons"
Hedayat Vatankhah
2015-01-02 00:21:48 UTC
Permalink
Post by Michael Catanzaro
Post by Alec Leamas
Possibly. But isn't there quite a difference between the "novice
user" and the Fedora Workstation target user i. e., developers?
"Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal."
Fedora currently suffers from the impression that it is a complicated
OS for advanced users only, and that novices (including novice
developers) should use Ubuntu instead.
Well, I was really surprised that developers are considered a target
audience here. GNOME Software *might* be considered good enough for
normal users, but its far from usable for a developer; even a developer
who don't want to touch the terminal. Actually, it is *terrible* for
such a developer. Why?

1. He search for "C++" and .... (I doubt that it tries to interpret it
as a regular expression or something. Probably it thinks that the user
is an idiot and removes "+" signs on behalf of him).
2. He has installed Eclipse + CDT and hopefully he can compile his C++
programs with GCC. Now, he learns about Clang and would like to try it.
3. He is using an x86_64 system, but he happen to need to compile his
program for 32bit systems. or even cross-compile for ARM.
4. He needs a networking library, or want to use Boost, or ....

GNOME Software is not that useful for a developer. As Rechard himself
said, he'll need a package manager anyway. So, If Workstation product
really targets developers, specially the ones who don't want to use
terminal, it MUST include a graphical package manager.

Regards,
Hedayat
Luya Tshimbalanga
2015-01-02 20:25:49 UTC
Permalink
Post by Hedayat Vatankhah
Well, I was really surprised that developers are considered a target
audience here. GNOME Software *might* be considered good enough for
normal users, but its far from usable for a developer; even a
developer who don't want to touch the terminal. Actually, it is
*terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end
applications only.
Post by Hedayat Vatankhah
1. He search for "C++" and .... (I doubt that it tries to interpret it
as a regular expression or something. Probably it thinks that the user
is an idiot and removes "+" signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is
designed for that purpose.
Post by Hedayat Vatankhah
2. He has installed Eclipse + CDT and hopefully he can compile his C++
programs with GCC. Now, he learns about Clang and would like to try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That is
very much an request of enhancement for IDEs installation in Gnome Software.
Post by Hedayat Vatankhah
GNOME Software is not that useful for a developer. As Rechard himself
said, he'll need a package manager anyway. So, If Workstation product
really targets developers, specially the ones who don't want to use
terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which
does not help. Gnome Software is actually useful once the add-ons
functionality is fully expanded on applications. Works need to be done
allowing a seamless integration.
--
Luya Tshimbalanga
Graphic & Web Designer
E: ***@fedoraproject.org
W: http://www.coolest-storm.net
Hedayat Vatankhah
2015-01-02 21:15:58 UTC
Permalink
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
Well, I was really surprised that developers are considered a target
audience here. GNOME Software *might* be considered good enough for
normal users, but its far from usable for a developer; even a
developer who don't want to touch the terminal. Actually, it is
*terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end
applications only.
Probably true, but it already includes fonts and input sources. So,
someone has felt that 'front-end applications only' is too narrow. Now,
where you can draw the line?
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
1. He search for "C++" and .... (I doubt that it tries to interpret
it as a regular expression or something. Probably it thinks that the
user is an idiot and removes "+" signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is
designed for that purpose.
Did you try that? The problem with searching for "C++" is that it will
list almost all applications (probably it searches for "C"). So it has
nothing to do with DevAssistant.
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
2. He has installed Eclipse + CDT and hopefully he can compile his
C++ programs with GCC. Now, he learns about Clang and would like to
try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That
is very much an request of enhancement for IDEs installation in Gnome
Software.
So, every IDE should have a 'clang' addon? and also a gcc addon? At
least, if 'shared' add-ons are available things will be much easier.

I wonder why people want to split developers into two categories:
GUI-only and Terminal-only? Why there couldn't be a "GUI as much as
possible developer"? Such a developer will prefer to install autotools
and clang/gcc using a GUI application, then open a terminal and run
"./configure && make && sudo make install" in shell? Why do people think
that a developer which wants (actually, since currently there are no(?)
GUI ways to do configure, make and make install, he is forced) to use
terminal should be 'punished' to use command line for installing the
tools he need?

(Well, hopefully in future there will be a tool (DevAssistant?) which
can help you to configure, compile and install a package from source.
Then, it can have gcc/clang/... compilers as its addons too; so it's
become more practical to have GUI-only developers who don't need to
install a compiler directly).
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
GNOME Software is not that useful for a developer. As Rechard himself
said, he'll need a package manager anyway. So, If Workstation product
really targets developers, specially the ones who don't want to use
terminal, it MUST include a graphical package manager.
There are developers unaware of the concept of package manager which
does not help. Gnome Software is actually useful once the add-ons
functionality is fully expanded on applications. Works need to be done
allowing a seamless integration.
Add-ons cannot cover development libraries, unless every library is an
add-on for all IDEs!

Regards,
Hedayat
Post by Luya Tshimbalanga
--
Luya Tshimbalanga
Graphic & Web Designer
W:http://www.coolest-storm.net
Luya Tshimbalanga
2015-01-03 01:29:14 UTC
Permalink
Post by Hedayat Vatankhah
Probably true, but it already includes fonts and input sources. So,
someone has felt that 'front-end applications only' is too narrow.
Now, where you can draw the line?
I exaggerated.
Post by Hedayat Vatankhah
Did you try that? The problem with searching for "C++" is that it will
list almost all applications (probably it searches for "C"). So it has
nothing to do with DevAssistant.
I just searched "C++" resulting a freeze of Gnome Software due to
handling of "++" character. That is a bug I already submitted
https://bugzilla.redhat.com/show_bug.cgi?id=1178199
Normally, Gnome Software should list DevAssistant on the first list as I
have no problem typing python or ruby keyword on the search field.
Post by Hedayat Vatankhah
So, every IDE should have a 'clang' addon? and also a gcc addon? At
least, if 'shared' add-ons are available things will be much easier.
In this case, why not?
Post by Hedayat Vatankhah
GUI-only and Terminal-only? Why there couldn't be a "GUI as much as
possible developer"? Such a developer will prefer to install autotools
and clang/gcc using a GUI application, then open a terminal and run
"./configure && make && sudo make install" in shell? Why do people
think that a developer which wants (actually, since currently there
are no(?) GUI ways to do configure, make and make install, he is
forced) to use terminal should be 'punished' to use command line for
installing the tools he need?
They were attempt of create a frontend for that purpose and most of them
were poorly implemented. Take a look of how Microsoft and Apple do their
development. it is a matter of finding a better way of implementing the
tool.
Post by Hedayat Vatankhah
(Well, hopefully in future there will be a tool (DevAssistant?) which
can help you to configure, compile and install a package from source.
Then, it can have gcc/clang/... compilers as its addons too; so it's
become more practical to have GUI-only developers who don't need to
install a compiler directly).
DevAssistant is a start. Next step will be adding packaging guideline
and other stuff. It takes time but it can be done.
Post by Hedayat Vatankhah
Add-ons cannot cover development libraries, unless every library is an
add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development
applications, the software should suggest installing the missing
library. If Gnome Video is able to prompt uses to install missing
component, then why shouldn't be possible for IDE application to do the
same?
Granted I don't know well the functionality but the logic is application
should detect and suggest adding the missing function.
--
Luya Tshimbalanga
Graphic & Web Designer
E: ***@fedoraproject.org
W: http://www.coolest-storm.net
Hedayat Vatankhah
2015-01-03 19:26:47 UTC
Permalink
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
Probably true, but it already includes fonts and input sources. So,
someone has felt that 'front-end applications only' is too narrow.
Now, where you can draw the line?
I exaggerated.
Post by Hedayat Vatankhah
Did you try that? The problem with searching for "C++" is that it
will list almost all applications (probably it searches for "C"). So
it has nothing to do with DevAssistant.
I just searched "C++" resulting a freeze of Gnome Software due to
handling of "++" character. That is a bug I already submitted
https://bugzilla.redhat.com/show_bug.cgi?id=1178199
Normally, Gnome Software should list DevAssistant on the first list as
I have no problem typing python or ruby keyword on the search field.
Thanks for filling the bug. :P I was thinking when I'll report it.
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
So, every IDE should have a 'clang' addon? and also a gcc addon? At
least, if 'shared' add-ons are available things will be much easier.
In this case, why not?
I was actually suggesting a solution which could fit in the current
design. I'm not against the latter (while I still prefer having them as
independent applications, in case you really don't need an IDE. However,
if it is also available as a DevAssistent add-on, it'd be good; but
actually I'm mis-using DevAssistant as 'Development Tools' category!)
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
GUI-only and Terminal-only? Why there couldn't be a "GUI as much as
possible developer"? Such a developer will prefer to install
autotools and clang/gcc using a GUI application, then open a terminal
and run "./configure && make && sudo make install" in shell? Why do
people think that a developer which wants (actually, since currently
there are no(?) GUI ways to do configure, make and make install, he
is forced) to use terminal should be 'punished' to use command line
for installing the tools he need?
They were attempt of create a frontend for that purpose and most of
them were poorly implemented. Take a look of how Microsoft and Apple
do their development. it is a matter of finding a better way of
implementing the tool.
If you mean finding a replacement for autotools, I disagree. While
having better ways is great (and actually, there are many 'autotools
replacements' and some of them are GUI friendly. A good example is
CMake), but there is a fact that there are many packages using autotools.
I don't know how Apple does it (but I think I remember some of my
friends actually being *forced* to use command line to install an
auto-tools based library), but I wonder if you know about a 'better way'
Microsoft provides. As far as I know, installing and using third-party
development libraries under Windows is nearly Terrible. And, the last
time I tried to use Boost under Windows it certainly needed using
command line to use boost build system. I used several other libraries
under Windows, none of them provided any *good* means for installation
and usage. Most importantly, Windows doesn't (or at least, didn't!) have
any Software Center like tools at all. So, there are no means in Windows
for finding and installing development libraries; and hence it can't be
better or worse than ours!
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
(Well, hopefully in future there will be a tool (DevAssistant?) which
can help you to configure, compile and install a package from source.
Then, it can have gcc/clang/... compilers as its addons too; so it's
become more practical to have GUI-only developers who don't need to
install a compiler directly).
DevAssistant is a start. Next step will be adding packaging guideline
and other stuff. It takes time but it can be done.
Post by Hedayat Vatankhah
Add-ons cannot cover development libraries, unless every library is
an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development
applications, the software should suggest installing the missing
library. If Gnome Video is able to prompt uses to install missing
component, then why shouldn't be possible for IDE application to do
the same?
Granted I don't know well the functionality but the logic is
application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job
is very easy: a video has a special format, and there are specific
plugins to enable playing that. However, assume that I need an XML
library for C++:
1. How can I tell the IDE that I need an XML library?
2. What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what
should I use already, and want to see what is available out there?

To me, it seems like implementing a special purpose software manager
inside IDE with almost all functionality GNOME Software provides. As I
said in another post, user reviews/rating for development libraries
(like what GNOME Software provides for applications) can be really
helpful when a developer wants to choose a library for a specific purpose.

Regards,
Hedayat
Post by Luya Tshimbalanga
--
Luya Tshimbalanga
Graphic & Web Designer
W:http://www.coolest-storm.net
Alec Leamas
2015-01-03 20:19:30 UTC
Permalink
Post by Hedayat Vatankhah
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
Add-ons cannot cover development libraries, unless every library is
an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development
applications, the software should suggest installing the missing
library. If Gnome Video is able to prompt uses to install missing
component, then why shouldn't be possible for IDE application to do
the same?
Granted I don't know well the functionality but the logic is
application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job
is very easy: a video has a special format, and there are specific
plugins to enable playing that. However, assume that I need an XML
1. How can I tell the IDE that I need an XML library?
2. What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what
should I use already, and want to see what is available out there?
To me, it seems like implementing a special purpose software manager
inside IDE with almost all functionality GNOME Software provides. As I
said in another post, user reviews/rating for development libraries
(like what GNOME Software provides for applications) can be really
helpful when a developer wants to choose a library for a specific purpose.
In other words: there is a difference between the toolchain and project
dependencies.

The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed
using IDE dependencies, DevAssistant and similar setups reflecting
general tool-set dependencies, agreed.

OTOH, the dependencies for a specific project cannot really be handled
this way. Such libraries are specific for the code you build, not the
tools. Making them dependencies of e. g., eclipse just doesn't make any
sense.


Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedora
Aleksandar Kurtakov
2015-01-04 08:01:48 UTC
Permalink
----- Original Message -----
Sent: Saturday, January 3, 2015 10:19:30 PM
Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Post by Hedayat Vatankhah
Post by Luya Tshimbalanga
Post by Hedayat Vatankhah
Add-ons cannot cover development libraries, unless every library is
an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development
applications, the software should suggest installing the missing
library. If Gnome Video is able to prompt uses to install missing
component, then why shouldn't be possible for IDE application to do
the same?
Granted I don't know well the functionality but the logic is
application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job
is very easy: a video has a special format, and there are specific
plugins to enable playing that. However, assume that I need an XML
1. How can I tell the IDE that I need an XML library?
2. What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what
should I use already, and want to see what is available out there?
To me, it seems like implementing a special purpose software manager
inside IDE with almost all functionality GNOME Software provides. As I
said in another post, user reviews/rating for development libraries
(like what GNOME Software provides for applications) can be really
helpful when a developer wants to choose a library for a specific purpose.
In other words: there is a difference between the toolchain and project
dependencies.
The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed
using IDE dependencies, DevAssistant and similar setups reflecting
general tool-set dependencies, agreed.
OTOH, the dependencies for a specific project cannot really be handled
this way. Such libraries are specific for the code you build, not the
tools. Making them dependencies of e. g., eclipse just doesn't make any
sense.
Yeah, it doesn't make sense to make dependencies of eclipse but usually when something is missing it's not that hard to find what to install programatically. Pointing again to the video for eclipse https://rgrunber.fedorapeople.org/eclipse_packagekit_2.ogv . I remember something about Anjuta being able to do something similar but can't find it now. Of course this can not cover every "creative" build environment but such approach works well for video codecs so it's not impossible.


Alexander Kurtakov
Red Hat Eclipse team
Cheers!
--alec
--
devel mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/
Aleksandar Kurtakov
2015-01-04 07:55:17 UTC
Permalink
----- Original Message -----
Sent: Friday, January 2, 2015 11:15:58 PM
Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Well, I was really surprised that developers are considered a target audience
here. GNOME Software *might* be considered good enough for normal users, but
its far from usable for a developer; even a developer who don't want to
touch the terminal. Actually, it is *terrible* for such a developer. Why?
From what I understand, Gnome Software is intended for front-end applications
only.
Probably true, but it already includes fonts and input sources. So, someone
has felt that 'front-end applications only' is too narrow. Now, where you
can draw the line?
1. He search for "C++" and .... (I doubt that it tries to interpret it as a
regular expression or something. Probably it thinks that the user is an
idiot and removes "+" signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is
designed for that purpose.
Did you try that? The problem with searching for "C++" is that it will list
almost all applications (probably it searches for "C"). So it has nothing to
do with DevAssistant.
2. He has installed Eclipse + CDT and hopefully he can compile his C++
programs with GCC. Now, he learns about Clang and would like to try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That is very
much an request of enhancement for IDEs installation in Gnome Software.
So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if
'shared' add-ons are available things will be much easier.
I wonder why people want to split developers into two categories: GUI-only
and Terminal-only? Why there couldn't be a "GUI as much as possible
developer"? Such a developer will prefer to install autotools and clang/gcc
using a GUI application, then open a terminal and run "./configure && make
&& sudo make install" in shell? Why do people think that a developer which
wants (actually, since currently there are no(?) GUI ways to do configure,
make and make install, he is forced) to use terminal should be 'punished' to
use command line for installing the tools he need?
(Well, hopefully in future there will be a tool (DevAssistant?) which can
help you to configure, compile and install a package from source. Then, it
can have gcc/clang/... compilers as its addons too; so it's become more
practical to have GUI-only developers who don't need to install a compiler
directly).
GNOME Software is not that useful for a developer. As Rechard himself said,
he'll need a package manager anyway. So, If Workstation product really
targets developers, specially the ones who don't want to use terminal, it
MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not
help. Gnome Software is actually useful once the add-ons functionality is
fully expanded on applications. Works need to be done allowing a seamless
integration.
Add-ons cannot cover development libraries, unless every library is an add-on
for all IDEs!
It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv


Alexander Kurtakov
Red Hat Eclipse team
Regards,
Hedayat
--
Luya Tshimbalanga
Graphic & Web Designer
--
devel mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
Hedayat Vatankhah
2015-01-05 03:26:20 UTC
Permalink
Post by Miloslav Trmač
----- Original Message -----
Sent: Friday, January 2, 2015 11:15:58 PM
Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
<...>
GNOME Software is not that useful for a developer. As Rechard himself said,
he'll need a package manager anyway. So, If Workstation product really
targets developers, specially the ones who don't want to use terminal, it
MUST include a graphical package manager.
There are developers unaware of the concept of package manager which does not
help. Gnome Software is actually useful once the add-ons functionality is
fully expanded on applications. Works need to be done allowing a seamless
integration.
Add-ons cannot cover development libraries, unless every library is an add-on
for all IDEs!
It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv
It's great, but it is not address my concerns, because:
1) If its going to be the only method for installing -devel packages, it
should always work: it should be able to install a missing library or
header file (consider a makefile only project). Also, not everybody uses
correct package name in their configure script, some people use
corresponding Debian package name (with a lib prefix and even sometimes
full debian package name: libfoo-dev); so partial/non-exact matching
should be also implemented.

2) More importantly, it doesn't address my main concern at all: what if
I want to create a new project, and I'm looking for a good XML library,
or would like to see what Fedora has to offer in this area? Even if I've
found a great library in Internet, I should create a test in my
configure/cmake checks for that library and see if PK will find it. It
doesn't look like a user friendly way to search for a development
library! It's a workaround around a missing UI.

Looking for development libraries, see their ranking and even reading
user's reviews is all completely useful for a developer, which aligns
perfectly with what Software offers for applications.

Regards,
Hedayat
Post by Miloslav Trmač
Alexander Kurtakov
Red Hat Eclipse team
Richard Hughes
2014-12-29 15:18:04 UTC
Permalink
wouldn't it raise questions about the Gnome Software application's role in
the workstation product?
I don't think it does, no. I'm a Red Hat employee, a Fedora user, but
also a GNOME developer. I'm not terribly keen pushing the tenet of
"GNOME Software doesn't show MATE applications when running in GNOME"
to "GNOME Software isn't suitable for Fedora Workstation".

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Co
Alec Leamas
2014-12-29 15:48:01 UTC
Permalink
Post by Richard Hughes
wouldn't it raise questions about the Gnome Software application's role in
the workstation product?
I don't think it does, no. I'm a Red Hat employee, a Fedora user, but
also a GNOME developer. I'm not terribly keen pushing the tenet of
"GNOME Software doesn't show MATE applications when running in GNOME"
to "GNOME Software isn't suitable for Fedora Workstation".
Fair enough. But to me, adding "GNOME Software (GS) also cannot install
compilers, interpreters and other CLI tools" creates a more problematic
situation.

And even the MATE applications issue is actually *very* different when
evaluated in a developer context. A developer is both more likely to be
interested in using multiple desktops (testing) and also probably more
capable of handling the complexity required.

Is GS intended to be a one size fits all solution for both "novice
users" and the workstation target developer user? If so, I cannot
really see how this could be handled reasonably unless there is explicit
support for the different roles e. g., some kind of modes or so.

And if walking this path, the Workstation default mode would be the one
corresponding to a developer, right?

Cheers!

--alec
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org
Ralf Corsepius
2014-12-30 12:07:58 UTC
Permalink
Post by Alec Leamas
Fair enough. But to me, adding "GNOME Software (GS) also cannot install
compilers, interpreters and other CLI tools" creates a more problematic
situation.
To me, "Fedora Workstation" w/ Gnome is an incarnation of GnomeOS - An
OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming
at competing with Android/WinRT, MetroUI and iOS.
Post by Alec Leamas
Is GS intended to be a one size fits all solution for both "novice
users" and the workstation target developer user?
I don't know if it's aimed at being a "one size fits all" solution. To
me, it's a matter of fact, that in general, there can never ever be such
a thing as a "one-size fits all" solution anywhere.
Post by Alec Leamas
And if walking this path, the Workstation default mode would be the one
corresponding to a developer, right?
Define "Workstation". I don't know which audience the people, who
implemented it, were aiming at - It definitely wasn't my use-case scenario.

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org
Alec Leamas
2014-12-30 12:20:03 UTC
Permalink
Post by Ralf Corsepius
Post by Alec Leamas
And if walking this path, the Workstation default mode would be the one
corresponding to a developer, right?
Define "Workstation". I don't know which audience the people, who
implemented it, were aiming at - It definitely wasn't my use-case scenario.
The only definition I'm aware of is [1].

Cheers!

--alec

[1]: http://fedoraproject.org/wiki/Workstation/Workstation_PRD
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraprojec
Reindl Harald
2014-12-30 12:26:18 UTC
Permalink
Post by Ralf Corsepius
Post by Alec Leamas
Is GS intended to be a one size fits all solution for both "novice
users" and the workstation target developer user?
I don't know if it's aimed at being a "one size fits all" solution. To
me, it's a matter of fact, that in general, there can never ever be such
a thing as a "one-size fits all" solution anywhere.
it can and it is known as KDE because KDE is highly configureable but
you do not need to configure much to start - but you have the
capabilities to adopt the UI to your personal workflow

also GNOME tries to make a interface for a desktop as well as for
tablets - KDE developers, especially in context Plasma5 realized that
this is only a compromise for all usecases

the idea is that the UI knows if it runs on a tablet or you connected a
docking station with a 27" screen and appears differently
_______________________________________

http://linux-beta.slashdot.org/story/14/07/16/1355218/kde-releases-plasma-5

Plasma 5.0 improves support for high-DPI displays and ships a converged
shell, able to switch between user experiences for different target devices
Luya Tshimbalanga
2014-12-30 19:37:14 UTC
Permalink
Post by Ralf Corsepius
Post by Alec Leamas
Fair enough. But to me, adding "GNOME Software (GS) also cannot install
compilers, interpreters and other CLI tools" creates a more problematic
situation.
To me, "Fedora Workstation" w/ Gnome is an incarnation of GnomeOS - An
OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming
at competing with Android/WinRT, MetroUI and iOS.
Only valid with default setting from Live Media. Listed OS above are
primarily designed from mobile device in mind with "GnomeOS" is simply a
general purpose combining elements from mobile desktop environments and
notably Apple OS X.
--
*Luya Tshimbalanga*
Fedora Design Team
Design Suite spin maintainer
Rave it
2014-12-31 12:43:00 UTC
Permalink
Am Wed, 31 Dec 2014 11:25:58 +0000
Message: 3
Date: Tue, 30 Dec 2014 13:58:47 -0800
To: Development discussions related to Fedora
Subject: Re: Ramblings and questions regarding Fedora, but stemming
from gnome-software and desktop environments
Content-Type: text/plain; charset=UTF-8; format=flowed
Post by Alec Leamas
Post by Luya Tshimbalanga
This certainly works, but is it really a reasonable trade-off in a
developer context where things like compilers and interpreters are
part of the very core? What role does Gnome Software play here? How
fruitful is the idea to hide packages in this context?
Compiler and interpreters i.e.Glade having GUI and implements app-data
(supposedly mandatory starting on Fedora 22) will be displayed on Gnome
Software.
Glade is neither a compiler nor an interpreter, it's an IDE.
My bad.
Post by Alec Leamas
Post by Luya Tshimbalanga
Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.
Agreed. And I can see some usecases where this makes a lot of sense.
But the question then becomes if this is the proper thing to do for
the Workstation target user which is a developer. As such, she will in
many cases want to install things like gcc, different python stacks
using collections, text processing tools and so on. None of which with
a GUI. She will also sometimes be interested in multiple desktops for
testing etc., causing the "MATE apps not visible" problem.
What about DevAssistant that comes with Fedora Workstation? Have you
tried it?
MATE apps not visible means they needed app-data included on their
.desktop files hence the pleas from Richard Hughes.
This is all done since some months in upstream and will land in fedora with mate-1.10 soon.
But i don't think that mate devs are very happy and motivated to do more because of the restricted
gsettings defaults of gnome-software.
[rave at fedora-21 ~]$ gsettings get org.gnome.software compatible-projects
['GNOME', 'KDE', 'XFCE']

In general mate desktop don't need such a software because outside from fedora most other major distros don't use gnome as default desktop.
And for fedora mate use yumex and for f22 we will use yumex-dnf.

Wolfgang
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Gary Scarborough
2015-01-03 20:56:55 UTC
Permalink
Sorry this is a bit late but I had a few thoughts on what I have read in
this thread:

Is workstation being aimed at new users or developers? And is the goal the
same for Gnome? If Gnome is aiming to cater to new users, then is it the
right primary DE for fedora? There seems to be a misalignment here.

I have spent most of the last 15 years working for one of the largest
computing colleges in the country. I can guarantee you that the vast
majority of our students learned to program in a terminal. It may not be
the preferred environment once they become professionals, but it shouldn't
intimidate them by any means. So if workstation is aimed at developers,
why are we worried about them encountering the terminal when using the OS?

Instead of hiding the CLI from new users, why not simply give them the
option of avoiding it? Instead of only showing gui apps, why not show all
with packages being tagged as either cli or gui. Then the user can decide
whether or not they want to install the package.

A package manager that can show ALL packages should be installed by default
in Gnome on Fedora. This isn't a distro that only ships a single DE.
Kevin Fenzi
2015-01-03 21:09:11 UTC
Permalink
On Sat, 3 Jan 2015 15:56:55 -0500
Post by Gary Scarborough
Sorry this is a bit late but I had a few thoughts on what I have read
Is workstation being aimed at new users or developers? And is the
goal the same for Gnome? If Gnome is aiming to cater to new users,
then is it the right primary DE for fedora? There seems to be a
misalignment here.
I don't speak for Gnome or the Workstation group, but no. I don't
either of those groups are targeting 'new users'
Post by Gary Scarborough
I have spent most of the last 15 years working for one of the largest
computing colleges in the country. I can guarantee you that the vast
majority of our students learned to program in a terminal. It may
not be the preferred environment once they become professionals, but
it shouldn't intimidate them by any means. So if workstation is
aimed at developers, why are we worried about them encountering the
terminal when using the OS?
I'm not personally worried about that, and I think lots of other folks
aren't either.
Post by Gary Scarborough
Instead of hiding the CLI from new users, why not simply give them the
option of avoiding it? Instead of only showing gui apps, why not
show all with packages being tagged as either cli or gui. Then the
user can decide whether or not they want to install the package.
Well, the current state of things is that the GUI software manager
shows only GUI apps and users need to use a cli software manager to
install and manage cli apps. I'm not sure there's advantage to showing
cli apps in the GUI software manager.
Post by Gary Scarborough
A package manager that can show ALL packages should be installed by
default in Gnome on Fedora. This isn't a distro that only ships a
single DE.
Yum or dnf meets this need as far as I can tell.

kevin
Hedayat Vatankhah
2015-01-03 21:24:30 UTC
Permalink
Post by Kevin Fenzi
On Sat, 3 Jan 2015 15:56:55 -0500
<...>
Post by Gary Scarborough
Instead of hiding the CLI from new users, why not simply give them the
option of avoiding it? Instead of only showing gui apps, why not
show all with packages being tagged as either cli or gui. Then the
user can decide whether or not they want to install the package.
Well, the current state of things is that the GUI software manager
shows only GUI apps and users need to use a cli software manager to
install and manage cli apps. I'm not sure there's advantage to showing
cli apps in the GUI software manager.
It has advantage for a user who prefers GUI, but sometimes needs to
install and use a CLI application. Such a user, which can easily include
many GNU/Linux new users who might happen to need to use a specific CLI
application, might know about the cli application usage (e.g. using a
app specific manual) but doesn't know anything about dnf/yum, and is not
interested to learn them. Does anybody really think that there should be
any relation between the UI of your package manager and the UI of the
packages you install with it? If so, maybe dnf/yum should be also unable
to install GUI apps. :P

Hedayat
Richard Hughes
2015-01-03 21:12:08 UTC
Permalink
Post by Gary Scarborough
Is workstation being aimed at new users or developers?
I don't think people fit clearly in these simplistic groups. I'm an
experienced GNOME developer, but I've never used C# before.
Post by Gary Scarborough
A package manager that can show ALL packages should be installed by default in Gnome on Fedora.
I've had about a decade trying to help here. Designing an application
manager is hard. Making an application "jack of all trades" makes it
"master of none". I tried to mix packages and application concept in
gnome-packagekit over the last few years, but it made for a poor
package manager experience and a poor application management
experience. So much so, now that gnome-software exists and is being
used for application management and system updates, I've ripped out
all the application stuff from gnome-packagekit returning it to a 100%
package-centric view.

If you type "package" into the dash the fist entry is "GNOME Packages"
which is the install/remove tool from gnome-packagekit. You can
install it with three clicks. I don't think it makes sense to install
it by default.

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.or
Michael Catanzaro
2015-01-03 23:20:19 UTC
Permalink
Post by Richard Hughes
If you type "package" into the dash the fist entry is "GNOME Packages"
which is the install/remove tool from gnome-packagekit. You can
install it with three clicks. I don't think it makes sense to install
it by default.
We may have been too aggressive in removing it. I think we could
include it by default if it had a first-run dialog that briefly
explains what a package is, and that package management is an advanced
tool for system administrators. Maybe with a link that launches GNOME
Software.

Alternatively, we could leave it uninstalled by default, and add a
"cross-reference" to it from GNOME Software's first-run dialog, or
simply by making it a featured app. Just throwing out ideas here....
Rahul Sundaram
2015-01-04 02:45:11 UTC
Permalink
Hi
We may have been too aggressive in removing it. I think we could include
it by default if it had a first-run dialog that briefly explains what a
package is, and that package management is an advanced tool for system
administrators. Maybe with a link that launches GNOME Software.
Another alternative would be for GNOME Software to show packages perhaps
optionally and deprioritize packages in the listing which don't fit GNOME
Software's criteria for an "Application". Excluding all packages just
causes confusion and has become a FAQ as of late in users list, Ask Fedora
etc.

Rahul
Richard Hughes
2015-01-04 13:46:19 UTC
Permalink
Post by Rahul Sundaram
Another alternative would be for GNOME Software to show packages perhaps
optionally and deprioritize packages in the listing
We're not filtering out packages that don't qualify as applications.
GNOME Software only searches the AppStream metadata (just the
pre-prepared things that qualify as applications) and then manually
matches up any desktop files that exist locally to packages using
PackageKit.

Richard
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://f
Rahul Sundaram
2015-01-04 16:57:58 UTC
Permalink
Hi
Post by Richard Hughes
We're not filtering out packages that don't qualify as applications.
GNOME Software only searches the AppStream metadata
Yes. My suggestion was to change that

Rahul
Chris Murphy
2015-01-05 02:43:51 UTC
Permalink
Post by Rahul Sundaram
Hi
Post by Richard Hughes
We're not filtering out packages that don't qualify as applications.
GNOME Software only searches the AppStream metadata
Yes. My suggestion was to change that
How? What does this look like?

Call me clueless, but I think that totally defeats the major points
behind Software. It's an opt-in application, that shouldn't change or
it's going to make it ugly, incoherent, and pointless. The UX is
intentionally designed to show applications, not packages. And
certainly not conflate both by showing both side by side.

But to wholesale revert back to showing a pile of packages – no
thanks. There's already an application that does this, it's GNOME
Packages or use yum/dnf.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
Rahul Sundaram
2015-01-05 03:15:36 UTC
Permalink
Hi
Post by Chris Murphy
There's already an application that does this, it's GNOME
Packages or use yum/dnf.
If this was the answer, there wouldn't be so many repeated discussions
about it. Users don't differentiate between say htop and geany as much as
the designers seem to have assumed. They treat them both as essentially
"applications". However it doesn't fit the definition that GNOME Software
has and ends up being not included. There are also users who love the
ratings and additional metadata that GNOME Software brings and they
wouldn't get any of that with GNOME Packages or yum. dnf search is even
more limiting since it doesn't offer even the rudimentary filtering by name
that yum offers. GNOME Packages also is not included by default. In
other words, GNOME Software solves a problem very well but unfortunately
doesn't solve the problems that the target audience has that much.

Rahul
Chris Murphy
2015-01-05 05:18:13 UTC
Permalink
Hi
Post by Chris Murphy
There's already an application that does this, it's GNOME
Packages or use yum/dnf.
If this was the answer, there wouldn't be so many repeated discussions about
it. Users don't differentiate between say htop and geany as much as the
designers seem to have assumed. They treat them both as essentially
"applications". However it doesn't fit the definition that GNOME Software
has and ends up being not included. There are also users who love the
ratings and additional metadata that GNOME Software brings and they
wouldn't get any of that with GNOME Packages or yum. dnf search is even more
limiting since it doesn't offer even the rudimentary filtering by name that
yum offers. GNOME Packages also is not included by default. In other
words, GNOME Software solves a problem very well but unfortunately doesn't
solve the problems that the target audience has that much.
I don't think the solution is merging the GNOME Software and Packages
UI's into one nutty experience.

So what exactly is the problem the target audience has? They want
GNOME Packages to be included again by default so they have both an
application GUI installer, and a packages GUI installer? That doesn't
seem unreasonable on the face of it. I think that's the idea presently
being floated.
--
Chris Murphy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
Kevin Kofler
2015-01-04 23:46:29 UTC
Permalink
Post by Gary Scarborough
Is workstation being aimed at new users or developers? And is the goal
the same for Gnome? If Gnome is aiming to cater to new users, then is it
the right primary DE for fedora? There seems to be a misalignment here.
I've been pointing out that misalignment from day 1. Nobody seems to care.

IMHO, developers are much better served with the KDE Spin:
* Plasma is more configurable and more adapted to the power users that
developers inevitably are,
* Apper (the package management GUI installed by default on the KDE spin)
does not hide development packages the way GNOME Software (the package
management GUI installed by default on the Workstation product) does,
* Qt and kdelibs / KDE Frameworks are a better development platform than
GTK+ (and yes, I've used both),
* KDevelop is a better IDE than anything GNOME has to offer.

The choice of GNOME as a desktop environment completely contradicts the
claimed target of "developers".

Kevin Kofler
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://
Rich Mattes
2015-01-05 02:46:49 UTC
Permalink
Post by Kevin Kofler
Post by Gary Scarborough
Is workstation being aimed at new users or developers? And is the goal
the same for Gnome? If Gnome is aiming to cater to new users, then is it
the right primary DE for fedora? There seems to be a misalignment here.
I've been pointing out that misalignment from day 1. Nobody seems to care.
* Plasma is more configurable and more adapted to the power users that
developers inevitably are,
* Apper (the package management GUI installed by default on the KDE spin)
does not hide development packages the way GNOME Software (the package
management GUI installed by default on the Workstation product) does,
* Qt and kdelibs / KDE Frameworks are a better development platform than
GTK+ (and yes, I've used both),
* KDevelop is a better IDE than anything GNOME has to offer.
The choice of GNOME as a desktop environment completely contradicts the
claimed target of "developers".
Kevin Kofler
The Workstation product is generally aimed at developers as per the
Target Audience section of the Workstation PRD[1], and the Workstation
working group decided on GNOME as the desktop to use to accomplish the
goals laid out in the PRD. Although the Workstation PRD sets out a lot
of developer-centric goals, the choice of GNOME as the default desktop
and the discussion around the not-so-devleoper-centric GNOME Software
app and other GNOME features make it seem like the Workstation product
is kind of awkwardly straddling the line between a shiny new
developer-centric "Workstation" product and the old "Desktop" default
GNOME-based spin (whose goals are not really enumerated in the PRD.) In
that light I can see how it may look like the choice of GNOME for the
Workstation product seem contradictory.

Are there any plans to promote the KDE spin to a product? Reading the
Workstation PRD and taking into account their choice of GNOME as the
default environment, it looks like there are wide open "Average User,"
"Power User," and "Cross-Platform Development (via Qt)" target audiences
that a new KDE-based "Fedora Desktop" or similar product could easily
cater to.

Rich

[1] https://fedoraproject.org/wiki/Workstation/Workstation_PRD
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-o
Continue reading on narkive:
Loading...