version 3.2.3
change README.md
change README.md
3.2.2
all to trunk
Initial commit
Add initial directories
4.3.3
removed src/safe_malloc.c
version 3.7.9
Color Picker and Plasma KDE
Back to the original issue: - the eyedropper button is not visible in all desktop environments - when visible, the behavior is erroneous - the eyedropper is not important for xsnow - Mark Capella has a solution, using QT - having QT next to GTK3 only for the eyedropper seems to me an exaggeration So, I leave the color button as it is. Expect a new version of xsnow within a few weeks or so.
Hi again, I implemented the fallensnow->flakes conversion when moving or resizing a window. Looks good. I also made the gui window non-resizable. The problem you mentioned with fallensnow staying fixed on the screen, I could not reproduce, even with your fxClock as test window. Did not try it in KDE though. Thanks for your input. Let me know if there are more issues. BTW: I put the new version on https://www.ratrabbit.nl/ratrabbit/xsnow/downloads/index.html
Hi! you did an impressive job on xsnow! I also love your fresh scenery pictures. You state that you corrected many realtime bugs. Can you name some that are present in xsnow-3.7.5? Using your code I could try to repair them in my version, despite my two left hands when coding for gtk and X11. About vintage: - xsnow-1.42 came with a copyright, prohibiting changing the code, apart from adapting to other environments. Rick Jansen and I agreed that I could develop xsnow provided that there is a 'vintage'...
In gnome, the 'eye dropper' works as expected. In KDE, the bug is probably related to https://bugs.kde.org/show_bug.cgi?id=456418
Sorry for late response, I missed this ticket. You are right, the 'eye dropper' fails to function. It selects black, but the snow color is not changed. Btw, in xfce, the 'eye dropper' is not shown. Thanks for mentioning, I'll have a look.
configure --disable-selfrep broken
4.3.2 bootstrapped
4.3.2
Uploaded version 3.7.8, problem should have been solved.
3.7.8
3.7.8
3.7.8 with correct configure.ac
3.7.8 po-files
3.7.8 fix type in ChangeLog
3.7.8
Ah, too bad... Forgot to test that flag. On a short vacation now, will repair in 10 days or so. Thanks for bringing up the issue and giving a solution. Regards, Willem On Sat, 3 Feb 2024, 17:16 Andrea Musuruane, musuruan@users.sourceforge.net wrote: Broken again in v3.7.7. It seems that removing the tab in line 86 solves the problem. [tickets:#14] configure --disable-selfrep broken Status: open Milestone: 1.0 Created: Tue Mar 21, 2023 03:07 PM UTC by Andrea Musuruane Last Updated: Wed Mar 29, 2023...
add config.guess config.sub
4.3.1
version 3.7.7
willem
3.7.6
version 4.3.0
3.7.5
Version 3.7.4 is now available, with repaired --disable-selfrep, see the ChangeLog.
3.7.4
Problem confirmed. Expect new version within a few days. On 21/03/2023 16.07, Andrea Musuruane wrote: [tickets:#14] configure --disable-selfrep broken Status: open Milestone: 1.0 Created: Tue Mar 21, 2023 03:07 PM UTC by Andrea Musuruane Last Updated: Tue Mar 21, 2023 03:07 PM UTC Owner: nobody In v3.7.1 disable-selfrep is broken. ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin...
3.7.1
3.7.1
3.7.1
4.2.6
4.2.5
4.2.5
4.2.5
3.6.0
3.6.0
Thanks for your comments, closing this ticket now.
Wrong geometry of transparent window with 2 displays
Thanks for your comments, closing this ticket now.
Thanks for your comments, closing this ticket now.
error: ‘gsl_interp_steffen’ undeclared
Thanks for your comments, closing this ticket now.
Uploaded version 3.6.0: a test has been incorporated which of the gsl_interp_* is available.
My guess is that your version of libgsl is somewhat too low. Can you try the following: In src/spline_interpol.h: comment out line 24, and remove the comment from line 26, so that it looks like: // steffen's method prevent overshoots: //#define SPLINE_INTERP gsl_interp_steffen // classic spline with overshoots: #define SPLINE_INTERP gsl_interp_cspline and then, run make; make install again, and let me know it that works?
Hi, thanks for testing. Things seem OK now, except that in pre23 the aurora has the tendency to disappear when you make it 100% wide. This has been solved in pre24, available at ratrabbit. It is about time to push a new version to sourceforge. If you have any suggestions for improvement, let me know. Thanks again, Willem On 11/28/22 23:01, Gin Kami wrote: With pre23 I am now seeing the correct resolution printed to the console for both the 2 & 3 monitor cases. I was able to test the monitor selection...
Hi, I think I found the culprit: a short time after xsnow has started, somebody changes the size of the snow window to the requested size. The starting size is too small. I observed this using Nvidia and KDE together. The Intel driver, which I normally use, does not show this behavior. Luckily, xsnow contains code to handle spontaneously changing window sizes, so the only thing I had to do was to print a message when the window size changes, apart for some trivia. The new version is on https://www.ratrabbit.nl/ratrabbit/xsnow/downloads/index.html,...
Hi, thanks for your message! The line Snowing in 0x3c00003: xsnow -1280+0 6400x1440 I find strange... In the mean time, I made a new version of xsnow, xinerama-aware. You find it on https://ratrabbit.nl/ratrabbit/xsnow/downloads/index.html Can you install that version and let me know how it behaves? Regards, Willem On 11/27/22 15:03, Gin Kami wrote: [tickets:#12] Wrong geometry of transparent window with 2 displays Status: open Milestone: 1.0 Created: Sun Nov 27, 2022 02:03 PM UTC by Gin Kami Last...
version 4.2.3
version 4.2.2
version 3.5.3
version 3.5.3
version 3.5.3
version 3.5.3
Minor changes in a few urls
correct url for ratrabbit/wsnow
4.2.1
3.5.2
version 3.5.1
0.98
willem
willem
willem
willem
ixpm.c: 2 * off by one error ?
Fixed in 3.5.0
3.5.0
3.5.0
3.5.0
You are right! Thanks for mentioning and pointing me to cppcheck. Will correct this in the next release.
4.2.0
3.4.4
allow to override build date
No message, good message ... Closing this ticket.
Thanks for the suggestions. I am using something like this am__tar='$${TAR-tar} --format=posix --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime --owner=0 --group=0 --numeric-owner --mtime="@1" --sort=name -chf - "$$tardir"' I get now reproducible builds, except when I use pbuilder to create a debian package. Could you have a look at my attempt (see configure.ac) and test it on your system? You find the new version (3.4.4~pre3) here: https://www.ratrabbit.nl/ratrabbit/xsnow/dow...
Thanks for mentioning the issues! The SOURCE_DATA_EPOCH thing: I will apply your patch. The necessity to use --disable-selfrep: the problem is caused by the time stamps in the tar ball created by 'make dist'. I will retar this tarball using the flags --atime-preserve and --mtime. I'll let you know when a new version is available. Willem
Improper indentation of OpenMP conditional compilation specification lines
I have a solution for you that does not involve changing findent itself: Create a script "myfindent": 1 2#!/bin/sh findent "$@" | sed 's/!\$\([ &]\)\( *\)/\2!$\1/' Given the following Fortran source: program q if(.true.) then !$ if(.true.) then !$ print *,'OMP', & !$ 'omp' !$ end if end if end program the following output is produced by "myfindent": program q if(.true.) then !$ if(.true.) then !$ print *,'OMP', & !$ 'omp' !$ end if end if end program (one could say that the handling of continuation...
Personally, I find the way findent handles !$ lines results in a better readable code than adding indent before !$. And I like to have the !$omp lines starting in column 1: these lines are not indented by findent. Your suggestion would entail the following to be done by findent: change a line like !$ continue into !$ continue and then, indent this line as a whole, also indent !$omp lines, whether they start in column 1 or not. This is not a trivial change, practice learned me that there always nasty...
You forgot the THEN after the first line, but adding that does not change the output. In the following I run findent with no flags. When I run your example, (with added THEN), I get this: if (condition) then !$omp parallel !$ num_threads = omp_get_num_threads() !$omp end parallel end if The 'num_threads line was already correctly indented, so we see no change there. I get no leading space in lines 2 and 4. Strange. Findent indents after the !$ sentinel, see the following example: program p if(.true.)...
Help with vim support
Issue with picom (Compositor)
No message, good message.
I found a better solution, which only affects xsnow, to be placed in your bspwmrc: bspc rule -a Xsnow state=floating border=off At least, this works on my system. Let me know if it works for you.
I guess, this is another bspwm thing, maybe the bswm community knows how to handle this.
I think I found something for bspwm: bspc config honor_size_hints true This gives me an xsnow, running in a transparent, click-through window spawning my two monitors. Ah, yes, and running with picom.
I think I found something for bspwm: bspc config honor_size_hints true This gives me an xsnow, running in a transparent, click-through window spawning my two monitors.