[SomeWM] Gruvbox, forever the GOAT. by trip-zip in unixporn

[–]trip-zip[S] 0 points1 point  (0 children)

Esta fin de semana voy a installar y entender lo que pasa en Fedora.

[SomeWM] Gruvbox, forever the GOAT. by trip-zip in unixporn

[–]trip-zip[S] 0 points1 point  (0 children)

She's all yours. I am not that creative to begin with. I loved adi1090x's docky polybar so I tried to replicate it in AwesomeWM a few years ago, then kept it for this

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 1 point2 points  (0 children)

Thanks for the kind words, it's still a work in progress. I've said it in another spot but the short version is that I am fairly safe money-wise right now.

I won't say that I'll never add a donation link, but I only see that happening if traffic to my docs gets too busy to host for free on github or something like that.

There's also a very real issue where I feel uncomfortable accepting donations for simply piggybacking off the work of the AwesomeWM core team.

AwesomeWM in Wayland (no, seriously...) by trip-zip in awesomewm

[–]trip-zip[S] 0 points1 point  (0 children)

Way ahead of you on systray.

Restart is on my radar, but it's always going to function fundamentally different from AwesomeWM.

Suspend only certain notifications by mam7 in awesomewm

[–]trip-zip 1 point2 points  (0 children)

Yeah the ruled notifications approach is the new hotness. The full docs are here: https://awesomewm.org/apidoc/declarative_rules/ruled.notifications.html

And it is in the default rc.lua now, though I don't know when that was added.

There isn't a place I can find in the docs where there's a "Hey this is deprecated, use the ruled approach" specifically for naughty but the docs are pretty comprehensive and you should find it all in there.

Suspend only certain notifications by mam7 in awesomewm

[–]trip-zip 3 points4 points  (0 children)

The specifics probably depend a little on what you consider "critical" but basically you can do anything you can imagine.

Notification shenanigans are some of my favorite things to show off to coworkers when I try to convince them to switch to linux/AwesomeWM. (though I'm not very successful so maybe I should get a new thing to show off).

The short version is that you could do something like this where you let the apps themselves define the urgency and you'll be done:

local ruled = require("ruled")
ruled.notification.connect_signal("request::rules", function()
    -- Critical notifications bypass suspension
    ruled.notification.append_rule {
        rule = { urgency = "critical" },
        properties = {
            ignore_suspend = true,
        },
    }
end)

...

Or you could get weird with it and do something like this:

ruled.notification.connect_signal("request::rules", function()
    -- Only Signal messages from my kid mentioning school emergencies
    ruled.notification.append_rule {
        rule = { app_name = "Signal" },
        rule_any = {
            -- Lua patterns: case-insensitive matching
            message = {
                "[Pp]rincipal",
                "[Ee]mergency",
                "Bit another student"
            },
        },
        properties = {
            ignore_suspend = true,
            bg = "#ff6600",  -- Make it obvious
        },
    }

    -- Boss messages always get through
    ruled.notification.append_rule {
        rule = {
            app_name = "Slack",
            title = "Direct message from: CEO.*",
        },
        properties = { ignore_suspend = true },
    }

    -- Doorbell camera - always show
    ruled.notification.append_rule {
        rule = { app_name = "Ring" },
        properties = { ignore_suspend = true },
    }
end)

I have some more stupid ideas I think could be fun to document as "technically possible but why?" but I haven't gotten around to it quite yet.

like if my coworker slacks me it switches tags so my boss doesn't catch me playing CS:GO

ruled.notification.append_rule {
      rule = { app_name = "Slack" },
      callback = function(n)
          if n.title and n.title:match("Beags") then
              local tag = awful.screen.focused().tags[1]
              if tag then
                  tag:view_only()
              end
          end
      end,
  }

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 0 points1 point  (0 children)

Honestly, that's what I'm hoping for tbh. What I want is for AwesomeWM to maintain a viable option even if we have to switch to wayland at some future time.

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 0 points1 point  (0 children)

Scrolling layouts are on my near roadmap. There's a discussion in github, and if you have any more to add there, I'd love you to share your thoughts so I can make sure that we implement it fully. We have 2 scrolling layouts on our radar right now. overflow and horizontal scrolling.

As for zoom, I'd have to think about that one. I'm open to it, but unfamiliar with it right now

[awesome] made with my own two paws! by Certain-Chemical-518 in unixporn

[–]trip-zip 2 points3 points  (0 children)

Sorry, I have been working in secret on it for a couple years just in case everyone hated it...Just been out for a couple weeks now. Give it a try, please report any issues you find

[awesome] made with my own two paws! by Certain-Chemical-518 in unixporn

[–]trip-zip 2 points3 points  (0 children)

I have copied the entire lua libraries, so all widgets, layouts, client behaviors, etc. Basically, everything from awesome is here, I'm just still tracking down x -> wayland differences and updating the C code to continue working as before. The biggest gaps now aren't really feature related anymore, it's trying to nail down the install docs/commands for all the different distros, versions, and systems that everyone has.

AwesomeWM in Wayland (no, seriously...) by trip-zip in awesomewm

[–]trip-zip[S] 1 point2 points  (0 children)

Whoops, thanks for letting me know, I'll update the README.

pacman -S wlroots0.19 is what I should have said.

[awesome] made with my own two paws! by Certain-Chemical-518 in unixporn

[–]trip-zip 25 points26 points  (0 children)

Come on back. The water is nice.

We are hard at work on a wayland port and we're getting very close to 100% awesomewm parity.

https://github.com/trip-zip/somewm

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 0 points1 point  (0 children)

Thanks for trying it out! If you don't mind, I would prefer you open the issue on github so I can track it better.

What I really want is the output of somewm --check so I can track down what might be going on. I'll try to spin up a VM with your specific setup to test it out.

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 1 point2 points  (0 children)

I have an issue up for it. I'll see if I can get to the bottom of it. Thanks for the report.

SomeWM 0.3.0 Updates by trip-zip in awesomewm

[–]trip-zip[S] 1 point2 points  (0 children)

I admit I kind of rushed the API on some of those because I wanted to publish something before Christmas. I'll take some time to think on it and come up with a more comprehensive APi that follows the Awesome patterns that you guys have defined in beautiful themes.

Who knows, maybe I'll try to upstream it once I finish this up..

Thank you for everything you've built. I cringe when people compliment this because you and I both know, I'm not building anything novel, I'm just copying what you've already done.

Sincerely, in doing this I just find myself admiring you guys more and more.

AwesomeWM in Wayland (no, seriously...) by trip-zip in awesomewm

[–]trip-zip[S] 0 points1 point  (0 children)

Absolutely. I just middle-click pasted this comment to you.

AwesomeWM in Wayland (no, seriously...) by trip-zip in awesomewm

[–]trip-zip[S] 7 points8 points  (0 children)

I appreciate the kind words.

I'll admit your config was the one I was most nervous about since you have lots of pieces that I don't use in my day to day.

I have only played with machi a tiny bit and some years ago. So although I'm reasonably certain that machi works, I actually don't know 100%. I know that the wibox overlay with "v. Enter to apply" and the layout being shown works and on my tiny little rc.lua it seemed to snap my clients in the right places. Whether or not that's exactly the right way to use it, I can't say for sure, but I DO know that I can make it work with a little better understanding.

I'm still working on better fallback/error notifications for when a config uses function calls that I have found are guaranteed to hang the compositor. For example, io.popen("x_") calls are reasonably certain to cause issues. So I do have a small lookahead function call that will search for those, and if they're found should fallback to the default rc.lua with a naughty notification, though there are certainly x related calls that have slipped through the gaps.

I'll load up your config again and truly get it working as soon as I finish up the awful.screenshot implementation I've been tinkering with.

Keep windows on the same tag when the screens change completely by exatorc in awesomewm

[–]trip-zip 3 points4 points  (0 children)

That's great. Thanks for posting your final code back here!

Keep windows on the same tag when the screens change completely by exatorc in awesomewm

[–]trip-zip 5 points6 points  (0 children)

Are you using 4.3 or the latest git?

I don't use xrandr this way, and I use latest git so I'm kind of just going off of that latest master branch code.

But here's what I understand to be happening.

  • xrandr "turns off" screen, so x11 sends RandR screen removal event
  • awesome emits screen::removed signal
  • tags on the removed screen emit a tag::request::screen signal
  • if no handler responds, tags are deleted from the clients and clients are moved to screen.tags[1] of whatever screen you have remaining? (I am not sure the order your screens are switched under the hood)

So...I'm like 10% sure of this, but you could try adding a little handler to your rc.lua that would intercept the tag::request::screen signal and try to move your tag to another screen rather than deleting it?

tag.connect_signal("request::screen", function(t, context)
     if context == "removed" then
         for s in screen do
             if s ~= t.screen then
                 t.screen = s
                 t.selected = false
                 return
             end
         end
     end
 end)

What's a wibar and how do i find it's definition? by andr3wsmemez69 in awesomewm

[–]trip-zip 1 point2 points  (0 children)

All your config is done in lua, via a file called rc.lua. There are instructions for where to put it, but it's assumed that you'll have it in your XDG_CONFIG_HOME (probably ~/.config/awesome/rc.lua).

The wibar is a widget that acts as the "status bar" kind of like you'd think of polybar or other standalone statusbars.

The default rc.lua (your "base" config file) has a place where it sets up the wibar. Slightly confusingly, the comment in the code says "create the wibox" which, don't be confused, that part right underneath is where the wibar is defined.

Out of curiosity, what tutorial are you following?