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, with 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.
On Fri, Oct 28, 2016 at 12:15 AM, Liam <liam.bulkley@gmail.com> wrote:
>
> >
> >
>
>
> On Wed, Oct 26, 2016, 12:54 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> >
> >>
>> On Mon, Oct 24, 2016 at 3:46 PM, Liam <liam.bulkley@gmail.com> wrote:
>>
>> > Owen Taylor blogged about a few things that would be of use here (at least
>> > as far as GNOME apps go).
>> >
>> > https://blog.fishsoup.net/
>> >
>> > 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.
>>
>>
>> > https://blog.fishsoup.net/
>>
>> It'd be neat if it were possible to cross reference performance
>> 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 triggered if the package exceeds a certain temp. One is called prochot and the other 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 them.
>
>
> >
> >>
>>
>> > https://developer.mozilla.org/
>> >
>> > On the Firefox side they've a page that addresses this issue and offer a few
>> > solutions (at one point, perhaps they still do, they regularly ran tests to
>> > check for power use).
>> >
>> >
>> > I'll also mention that osx includes a panel, in the system monitor app, that
>> > 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 happening
>> > (since I'd imagine that it's using dtrace it may offer a great deal more
>> > 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
>> video.
>
> 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 (parsed 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@lists.fedoraproject.
> To unsubscribe send an email to desktop-leave@lists.
>