Search
483 results for “zirias”
-
@zirias you may like #LibertyEiffel then! It's compiled @wollman @rubenerd @dexter
-
-
One of the ways I help avoid failures with raidz1 is by replacing HDD when they get to around 5 years old, or they start showing errors. Also, monthly scrubs helps ensure that the drives are getting fully utilized regularly which helps keep things healthy/accelerate detection of failures.
-
I have one little piece of custom platform-specific code in #qXmoji.
Background is that #Qt's QFileSystemWatcher doesn't work correctly on #NFS (and probably other network filesystems). It uses some platform mechanism (e.g. inotify on #Linux, kqueue on #FreeBSD) internally, so exact behavior probably depends on the platform. On FreeBSD, it *seemed* to work, but only when the change to the file on NFS is done from the local machine. 🙄
Now regarding this code:
https://github.com/Zirias/qxmoji/blob/master/src/bin/qxmoji/nfsdetect.c
-- I still have doubts.▪ Should it check for other filesystems as well? Which ones?
▪ Will this construct checking for 'BSD4_4' in <sys/param.h> reliably detect every OS derived from 4.4BSD (assuming a POSIXy system that *has* sys/param.h)?
▪ Should it have implementations for *other* POSIXy systems than 4.4BSD-descendants and Linux?
▪ Why the hell is there no standard for checking the *filesystem* a file resides on? 🧐😁 -
#qXmoji v0.7 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.7
This brings several improvements, mainly in the build system, but the major change is support for localization, with translated Emoji names imported from #Unicode #CLDR. I added a German translation, see screenshot. Once again, I'd appreciate more translations, the process to translate is documented here:
https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.mdUpdated FreeBSD port:
https://people.freebsd.org/~zirias/patches/0001-x11-qxmoji-Add-new-port.patch -
#qXmoji is now completely translatable, and fully localized for 🇩🇪.
So, here comes a request for contributions 😁 (pretty please 🙃):
More languages would be nice! Therefore I documented the process to add them here:
https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.md -
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I now added a screenshot of #qXmoji on github. People need to see screenshots for some reason (I'm no exception) 😄
I wanted "default looks", so, disabled any #Qt theming and thought #fvwm3 with default config should be a very nice match for a tool targeting "plain #X11", and firing up a #Xephyr session, I was quite surprised how polished fvwm3's default config looks nowadays, even integrating #stalonetray when available 👍
I still prefer my custom config, but nevertheless, great job 🙂
-
#qXmoji v0.6 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.6
This brings a *lot* of improvements and fixes, the most relevant being immediate persistence of settings and watching the settings file for external changes. To make this feasible also for restoring the history, a lot of work went into generating static emoji data that can be used efficiently (e.g. containing a hash table to find an emoji quickly).
BTW, this even works on #NFS, so if you have your home shared and you're running qXmoji on two machines as the same user, the history will auto-update in both instances 🥳
-
#qXmoji v0.5 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.5This brings a *few* of the ideas I had:
🔹Add a "single instance" mode (configurable)
🔹Add a "tray icon" (configurable behavior)
🔹Add an "About" dialog
🔹Enforce using Qt's "xcb" platform
🔹Fix detaching on startup, add a flag (-d) to prevent itPretty usable as it is I hope ... although one could of course improve a lot (but have you heard of the 80-20-rule?) 🫣
Screenshot from #KDE this time, no particular reason, I'm still running #fvwm here 😎
-
Guess I *did* enter "shady areas" writing commit messages like this:
https://github.com/Zirias/qxmoji/commit/2a404cd195619265559f9cced21f89ce3d129f40
In theory, all #EWMH window managers should behave the same, I thought ... 😂🙈
-
Found a small bug, #xcb requests were synchronously checked, but this only works when calling the _checked() flavor of them ... 🙈
Fixed in #qXmoji v0.4
Also added a clear button to the search field, this seems somewhat useful 😉
-
🥳 #qXmoji v0.3 released 🍻🍕
Now there are the "basic" features you'd expect from an emoji keyboard:
✅ Search as you type
✅ Recently used -
#qXmoji v0.1 and v0.2 released 😎
Functionally the same (just clickable emojis in tabbed groups, display size and wait-time for restoring the X11 keyboard map configurable), but v0.2 has correct README info and build-fixes, so Qt tools are found without fiddling with make variables 🙈 so, use v0.2 😎
-
That's the thing that you're missing.
"full terminfo support" *is not* solely just providing the libraries, in the world that we live in, as there are things that do not need the libraries. It's actually not unreasonable to find independent implementations that *just* require the identical data files, which ironically are not part of the standard. Because the world can and does code to *them* not to (n)curses or even to libterminfo.
-
That's the thing that you're missing.
"full terminfo support" *is not* solely just providing the libraries, in the world that we live in, as there are things that do not need the libraries. It's actually not unreasonable to find independent implementations that *just* require the identical data files, which ironically are not part of the standard. Because the world can and does code to *them* not to (n)curses or even to libterminfo.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.