Announcement

Collapse
No announcement yet.

GNOME Shell Picks Up Performance Improvements For Extensions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • cynical
    replied
    Originally posted by jo-erlend View Post

    Good question. Sounds difficult to me. JS is still single-threaded, isn't it?
    Mutter is written in C, not JavaScript. And Gnome-Shell itself is also partly implemented in C, so the language is not the barrier.

    Originally posted by jacob
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?
    Way too disruptive. You can read a related proposal for "GNOME Shell 4" here, outlining the changes that need to be made.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by jacob View Post
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?
    Good question. Sounds difficult to me. JS is still single-threaded, isn't it?

    Leave a comment:


  • jacob
    replied
    Is the problem that all extensions run within the main UI thread being addressed, or is that too disruptive a change that will have to wait until GNOME 4?

    Leave a comment:


  • tildearrow
    replied
    Originally posted by Britoid View Post

    The extension system imho should just be removed or restricted to only a few areas (e.g. adding things on the top status menu).
    That'd make the desktop even less flexible, and after that I'm pretty sure many would move away from it...

    Leave a comment:


  • Britoid
    replied
    Originally posted by 144Hz View Post
    3.34.1 might end up eslint clean \o/ The extensions really need to up their CI game. How can they live with poor hosting on github? No wonder some extensions break when they miss out on Gitlab CI.

    https://gitlab.gnome.org/GNOME/gnome...e_requests/716
    The extension system imho should just be removed or restricted to only a few areas (e.g. adding things on the top status menu).

    Leave a comment:


  • treba
    replied
    Originally posted by 144Hz View Post
    3.34.1 might end up eslint clean \o/ The extensions really need to up their CI game. How can they live with poor hosting on github? No wonder some extensions break when they miss out on Gitlab CI.

    https://gitlab.gnome.org/GNOME/gnome...e_requests/716
    While Gitlab is surely great, you can have all sorts of external CI hooked up to github as well. Talking about travis-ci etc.

    Leave a comment:


  • Britoid
    replied
    Originally posted by treba View Post
    AFAIK, 3.35 has not been branched yet, so this is all still going into 3.34
    Possibly 3.34.1

    Leave a comment:


  • treba
    replied
    AFAIK, 3.35 has not been branched yet, so this is all still going into 3.34

    Leave a comment:


  • uid313
    replied
    Last time I tried to write a GNOME Shell extension, I used the gnome-shell-extension-tool, and it generated some ugly JavaScript code, it couldn't use modern JavaScript ES6 classes.
    Last edited by uid313; 12 September 2019, 10:22 AM.

    Leave a comment:


  • phoronix
    started a topic GNOME Shell Picks Up Performance Improvements For Extensions

    GNOME Shell Picks Up Performance Improvements For Extensions

    Phoronix: GNOME Shell Picks Up Performance Improvements For Extensions

    While days too late for squeezing into GNOME 3.34.0, the GNOME Shell has landed a one year old merge request providing various fixes and performance improvements to its extension system...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X