On the other things: the GUI we have (GNOME, for Fedora Workstation) has
really settled down in core design from how it was a few years ago,
more room for the polish you're looking for. (Despite the *superficial
appearance as a tablet interface*, GNOME is actually pretty awesome from
the keyboard, and I actually think of it as a keyboard-primary UI, at least
for how _I_ use it.
GNOME has made impressive technological leaps forward but the shell design
and desktop workflow model haven't advanced at the same pace. What if
Fedora Workstation had a unique desktop shell like Elementary OS and
Ubuntu's Unity? Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland. Sometimes superficial appearances are a much bigger factor than we
like to acknowledge in the success of platforms.
It's amazing that macOS a technologically backward platform has managed to
attract a large following among the engineering community because of it's
great desktop environment.
There's also iTerm2  and I would love to see GNOME Terminal have that
kind of look and feel and functionality.
On Fri, Oct 28, 2016 at 12:15 AM, Liam <liam.bulkley(a)gmail.com> wrote:
> On Wed, Oct 26, 2016, 12:54 PM
Chris Murphy <lists(a)colorremedies.com
>> On Mon, Oct 24, 2016 at 3:46 PM, Liam <liam.bulkley(a)gmail.com> wrote:
>> > Owen Taylor blogged about a few things that would
be of use here (at
>> > as far as GNOME apps go).
>> > This discusses some
perf tests run as part of CI.
>> I'd like to know, even if it's an informal
survey, what percent of
>> Fedora developers (and separately, users), are using a laptop. This
>> perf tests mention desktop hardware. Yesterday on #fedora-kernel I
>> learned upstream isn't doing much laptop testing. So at the moment it
>> sounds like to me a bulk of the laptop testing happens once something
>> goes in updates-testing.
>> It'd be neat if it were possible to cross
>> regressions with packages, and somehow opt into getting a slower
>> release of packages with a higher performance regression rate. Sort of
>> a performance regression trustworthiness measure.
>> Separate, but related, I think it's currently a
problem for rpm-ostree
>> which doesn't permit a decoupling between a current tree and the
>> kernel, for example. It's all or nothing. If there's a 4 month period
>> where I need to use an older or newer kernel than what's in the
>> current release ostree deployments, I can't do that using Fedora's
>> sources. I'd have to setup my own ostree server to get around it.
>> I'm really concerned about regressions where
laptops don't power off
>> or suspend when the lid is closed. This has come up before, I've read
>> about it on various lists, but only recently have I experienced it
>> myself. And I don't know how to get more resources for this but it
>> seems like to me the laptop and CPU manufacturer should have more
>> stake and resources in this than they do, and do more testing so
>> there's an early warning sign before someone ends up with a smoldering
>> backpack on an airplane.
> Yeah, I've mentioned that issue to you (well, more
about my laptop not
resuming than it going note7).
Btw, there's supposed to be a couple of trips that sounds very
if the package exceeds a certain temp. One is called prochot and the
is thermtrip. I'd expect the battery would also include some similar
features, as should the motherboard, but I've not found any reference to
>> > On the Firefox side
they've a page that addresses this issue and offer
> > solutions (at one point, perhaps they still do, they
>> > check for power use).
>> > I'll also mention that osx includes a panel,
in the system monitor
> > will last and blame apps based on energy use. In the same
app osx also
> > offers a sysprof-like tool that allows you to see what calls are
> > (since I'd imagine that it's using dtrace it may
offer a great deal
>> > than that but I've not dug into it).
>> Yea it's neat. It blames services too, not just
user visible programs.
>> If you run any web browser though, that will far and away exceed
>> almost anything else other than a compiling, rasterizing, or anything
> Yes, but it's something that would make it easier for
a user to quickly
narrow down problems. That was really my point (obviously poorly phrased).
It also might be useful to show the user CPU and package states
for the user, if need be, to something like ludicrous speed, or even PLAID,
when you'd normally expect lightspeed---whatever, just as long as it's
clear where on the scale they are) as that's a great way to determine how
well their system is doing since Joules are basically meaningless without
reference to their system's baseline (which their installation of Fedora
may never approach).
> desktop mailing list -- desktop(a)lists.fedoraproject.org
> To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org