Announcement

Collapse
No announcement yet.

GNOME Shell 4 Proposal Published To Be More Wayland-Focused

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

  • #31
    Originally posted by DanL View Post

    ...or they could just tell you that they're not planning on a rewrite and to quit spamming the bug tracker. In other words, "Patches welcome (or GTFO)."
    Seriously, if that's what you call "helpful", don't try to help.
    naw - am I not allowed to be funny?

    Comment


    • #32
      Originally posted by leipero View Post
      kmare First more drastic approach is probably the right way of doing things, maybe it is better to do it a bit slower but properly than fast solution that might introduce other problems in the future.
      I agree. I like the drastic approach, but it's not very user-friendly to break extensions, which is one of the main reasons to use GNOME Shell in the first place. At some point breakage is needed, but it's better to do it at, say, 4.6 or so to give devs some time to update their extensions. That way, users would be able to keep the majority of extensions.

      Comment


      • #33
        Originally posted by hrkristian View Post

        Uhm... Caffeine stops your screen from blanking in the first place, that's the point. I have a 5 minute time-out, and sometimes I want to set it to "never" without having to go into settings; enter Caffeine, one click on the status bar and I have achieved just that.
        Settings doesn't have to mean the Settings app or Tweak Tool. Something like Caffeine could be added to the status menu (the one on the upper right). Sure, that would be 2 clicks vs the one you mention, but it would still be a hell of a lot faster than going to Settings/TT.

        Comment


        • #34
          Originally posted by Holograph View Post
          Maybe they can make it less SystemD-focused while they're changing things.

          I'm serious, not trolling, for the record. Not a battle of SystemD being good or bad. Just a general "DE shouldn't require a specific init system" argument.
          Not to mention the display manager argument. I was told by Solus devs that GNOME Shell requires me to install and use GDM and by others that KDE works best when you install and use SDDM. Both turned out to be true. I don't like that, one should be able to choose their own display manager.

          Comment


          • #35
            Originally posted by yaneti View Post

            Might as well start a separate XWayland server for each legacy app, each a separate wayland client. If thats at all possible with XWayland. Maybe wasteful but if the objective is sandboxing...
            Only if they fix GNOME Shell's performance. It's already a problem, I wouldn't want it to become an even bigger problem when every XWayland app starts its own XWayland server. Sandboxing is great and I don't mind giving up a little bit of performance for it, but there are limits.

            Comment


            • #36
              Originally posted by boxie View Post
              am I not allowed to be funny?
              If you think you can pester the whole world into rewriting everything for native Wayland support (and there's no indication to suggest you were joking), that's not funny to me. Putting a smiley after your statement doesn't magically make it funny...

              Comment


              • #37
                Originally posted by DanL View Post
                If you're going to break extensions, maybe you should add the simpler and most popular extensions into the desktop. Just a thought..
                *cough* dash-to-panel *cough*

                Comment


                • #38
                  Originally posted by Vistaus View Post

                  I agree. I like the drastic approach, but it's not very user-friendly to break extensions, which is one of the main reasons to use GNOME Shell in the first place. At some point breakage is needed, but it's better to do it at, say, 4.6 or so to give devs some time to update their extensions. That way, users would be able to keep the majority of extensions.
                  Well, that's why we have alpha, beta and so on stages, why not using it? Building something from ground up and letting things "stay for now" only makes you lose focus and make inferior whatever you are building in my opinion. Modular approach seems logical even for DE's core functionality (if trade offs are not way too much), starting anything from the ground up is a gamble, so instead of moving "final product" to point release, core functionality have to be done in beta, so point releases could be focused on features and other stuff (as it is now in gnome 3). Who knows if in 4 years from now wayland will be fully adopted? It might be, but it is also possible that drivers and applications would not move "that fast" and we could still have problems with it. But I sort off doubt GNOME 4 could be developed in such a fast pace, so it makes sense to start for wayland and throw a dice and see what happens, adding X support should not be a big problem considering experience with GNOME 3, and core extensions (if GNOME 4 even use extensions) should be developed with GNOME 4 as an testing ground ofc.

                  Comment


                  • #39
                    One thing they should do better (if there is resources of course) is extension development documentation. There is too little and too poor documentation to even start developing them let alone to create something actually useful. I know that there are many extensions, but I find it painful to create my own since the APIs are so poorly documented.

                    Comment


                    • #40
                      One of the most disappointing aspects of GNOME 3 for me is that one faulty extension prevents the whole shell loading. Would any of these proposed changes prevent this being the case for GNOME 4, presuming it maintains a similar extensions system?

                      Somebody was asking about disabling screen locking under GNOME Shell? To do that I had to run:

                      gsettings set org.gnome.desktop.session idle-delay 0

                      Comment

                      Working...
                      X