worm is my own window manager: Worm - a floating, tag based window manager - #51 by codic12
I’d absolutely be honored to have it as a CE for EndeavourOS. I’ve opened this thread for discussion of this planned CE, which I hope to start with today. Here are some components I am thinking of right now:
I hope we can get it done in time for the next release!
I’m a Gnome user myself, but I’m fond of plenty of other desktop environments as well. I know there is a plethora of DE’s out there and no shortage of window managers for that matter either. With that said, I think as long as you have feature-parity with other similar window managers you’re off to a good start. As long as you are able to stand out of the pack in a different and meaningful way from other window managers and are also able to maintain and update your window manager accordingly (fixing bugs, adding requested features, improving code, etc), I think your WormWM could be a worthy addition to consider in the future. For some of that though it’s too early to tell and your WM is still very new, but nonetheless I’ve followed your progress so far and you are off to a really good start.
My only concern is your first attempt, the code got abandoned rather quickly, so I could see some hesitance there in adoption, but I’m sure there were logical reasons for that. As long as you can guarantee to a certain degree that it will be actively developed and maintained, I could easily see quite a few window manager users being quite happy with your WormWM. I’m not a WM type of user myself, but regardless of my environment of choice, I fully hope you succeed in your undertaking. Just keep at it, be aware of burn out, seek help whenever you need it, and always remember why you started it in the first place so you never truly lose sight of your goals.
Thanks, appreciate the reply!
There were, and I don’t plan for it to happen again; it was basically a “first try” at writing something decent that other people could use, and the codebase grew to be pretty crappy eventually over time so I decided to rewrite it with my new experience. I do plan to maintain it, as I’m using it every day as a daily driver.
I think it’s important that while this is a community edition, it’s also a gift to the community. So, you should also make it some how you want it as well with consideration from the community.
I personally like both pcmanfm and thunar. . . if I had to choose for a wm - I prefer pcmanfm though. Why? I dunno. I always feel like Thunar makes it more “taken from xfce” than “supposed to be in worm” . . .
It’s hard to explain.
Good point, thanks! I think I may hold a vote; those were just tentative first ideas.
Btw, one concern I have with this is that worm isn’t in the Arch repositories. To the core devs: would it be possible to package it in the endeavour repositories?
Is this the previous iteration? Why not replace it with the new one?
As for a CE, I think it’d be wonderful, assuming you’re planning to maintain it. The more the better, as long as the standard holds up and including it doesn’t add too much work for the EnOS devs.
As for the application choices, I think maintaining an EnOS standard is the best choice. I’m not entirely sure, but I think most of the others use xfce terminal and Thunar.
Yes, that would make sense, although I don’t know if installing packages from the AUR is OK for a CE to do. @moson is the maintainer of the package, so they’d have to update it.
Agree with these points!
I’ll have a look to update the PKGBUILD for the AUR package.
Could you add a license as well?
Verifying dependencies for worm@0.1.0
Prompt: No local packages.json found, download it from internet? [y/N]
Answer: y
Downloading Official package list
Success Package list downloaded.
Installing x11@any version
Downloading https://github.com/nim-lang/x11 using git
Verifying dependencies for x11@1.1
Installing x11@1.1
Success: x11 installed successfully.
Building worm/wormc using c backend
Building worm/worm using c backend
/home/moson/.cache/nim/worm_r/@mworm.nim.c: In function ‘getProperty__9aiI5srh3lf4yinTF7HA9aGQ’:
/home/moson/.cache/nim/worm_r/@mworm.nim.c:3022:26: error: incompatible types when assigning to type ‘tyObject_Option__hcmjwL9c5ECYpHnVevXHwEQ’ from type ‘tyObject_Option__9bcZreTqxpOXg5u4xcKsUEw’
3022 | result = colontmpD__2;
| ^~~~~~~~~~~~
/home/moson/.cache/nim/worm_r/@mworm.nim.c: In function ‘handleUnmapNotify__IBNx9c2pqwde9cI9bE9afvcRpw’:
/home/moson/.cache/nim/worm_r/@mworm.nim.c:4423:27: error: incompatible types when assigning to type ‘tyObject_Option__hcmjwL9c5ECYpHnVevXHwEQ’ from type ‘tyObject_Option__9bcZreTqxpOXg5u4xcKsUEw’
4423 | (*self).focused = T12_;
| ^~~~
/home/moson/.cache/nim/worm_r/@mworm.nim.c: In function ‘handleDestroyNotify__UtpRh9a9bdEb3vV3vfdWHAsw’:
/home/moson/.cache/nim/worm_r/@mworm.nim.c:4509:27: error: incompatible types when assigning to type ‘tyObject_Option__hcmjwL9c5ECYpHnVevXHwEQ’ from type ‘tyObject_Option__9bcZreTqxpOXg5u4xcKsUEw’
4509 | (*self).focused = T12_;
| ^~~~
Error: execution of an external compiler program 'gcc -c -w -fmax-errors=3 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -O3 -fno-strict-aliasing -fno-ident -I/usr/lib/nim -I/home/moson/build/worm/src -o /home/moson/.cache/nim/worm_r/@mworm.nim.c.o /home/moson/.cache/nim/worm_r/@mworm.nim.c' failed with exit code: 1
Tip: 35 messages have been suppressed, use --verbose to show them.
Error: Build failed for package: worm
... Execution failed with exit code 1
... Command: /usr/bin/nim c --colors:on --noNimblePath -d:release --gc:arc -d:NimblePkgVersion=0.1.0 --path:/home/moson/.nimble/pkgs/x11-1.1 --hints:off -o:/home/moson/build/worm/worm /home/moson/build/worm/src/worm.nim
I’ve installed nim (1.4.8-1) and nimble (1:0.13.1-1) from the Arch repo’s…
edit
It seems to need at least Nim 1.6.0 to build successfully.
I have a working PKGBUILD for it which makes use of “choosenim” AUR package.
I’ll probably update it later on the AUR. To be discussed (in the other worm specific thread I’d say) → Can it be made compatible with 1.4.8 instead maybe. Or offer a “worm-bin” package with pre-compiled binaries…
This be my biggest concern tbh. I’ve got more abandoned projects than I can count - and sometimes I’ve regretted making a show when I start a project, only to disappoint people when I abandon it.
I’m not questioning your capability ofc, but these two things for sure I’ll expect if Worm WM gets into EnOS:
Kinda ironical this is coming from a person whose ratio of completed to abandoned projects is about 1:40, but you get the idea.
PS.
I bet you will. You work while I chat. 
Edit : When is the Assembly rewrite of Worm coming out?
I am not sure that will work. It is a netinstall and the packages are installed using pacman.
It won’t ordinarily. For it to work the package would have to be added to the EndeavourOS repository and maintained. It has been done before for example inxi but it’s up to the guys like joe Manuel and Bryan as to whether or not it happens. 
Thanks for updating the PKGBUILD!
Yeah, will look into that soon. not sure why it doesn’t compile actually
Is it possible to just pull it straight from git then?
Not without custom coding. Basically, all the packages need to be in a repo.
Yeah, I feel the simplest solution is to get it added to the repository, but not sure what the proceedure is for that…
Got it. I was just spitballing.
Procedure? Convince Manuel 
PS. Installing from AUR straight in Calamares will get messy, and someone - most probably Joe and Manuel - will have to maintain that. Could get decent amount of extra work, which I’m personally not in favor of.
Btw @moson, I’ve fixed compilation to work with 1.4.8, so you can switch to the repo version now 
@manuel would it be possible to add worm to the repositories in order for the CE to work?
I have no objections to adding it to the repos. If it is already in AUR, it is also possible for us to build packages from AUR into our repo, like we have done with certain AUR packages.
Let’s hear what @joekamprad and @Bryanpwo think about it.