Changes/additions in AlsaMixer.app over Mixer.app were lacking a
copyright information and and license specifications. Add the missing
bits, using a SPDX-License-Identifier.
Documentation for the change follows.
---------------------------------------------------
From petr.hlavka@avast.com Wed May 2 10:57:44 2018
Delivery-date: Wed, 02 May 2018 08:57:44 +0000
Received: from muffat.debian.org ([209.87.16.33])
by vsrv21575.customer.vlinux.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.91)
(envelope-from <petr.hlavka@avast.com>)
id 1fDna2-0005LT-O4
for ametzler@bebt.de; Wed, 02 May 2018 08:57:44 +0000
Received: from mail-qk0-x235.google.com ([2607:f8b0:400d:c09::235])
by muffat.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.89)
(envelope-from <petr.hlavka@avast.com>)
id 1fDna0-0001VT-VK
for ametzler@bebt.de; Wed, 02 May 2018 08:57:41 +0000
Received: by mail-qk0-x235.google.com with SMTP id c70so10628010qkg.0
for <ametzler@debian.org>; Wed, 02 May 2018 01:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=avast.com; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=todeyYOMQgF5NFi+g8Ch3ff7DLqVyjdpO1jnkiSCnwQ=;
b=dTOhJ1+p5j29A0wiZExWtmDgNHdAYz4TBYldVuTScFHsdG2sEnQQJ0jhLcdJBZWtB/
f9zbg70xN2O++EiXmWzHO///LWZQVvmqxRfWe9e9NinQiftLvebLt0qhNDqGurm0XGuR
ElxIv7xaik7A76zuy4RiWLBQPJImsdbkj8w8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=todeyYOMQgF5NFi+g8Ch3ff7DLqVyjdpO1jnkiSCnwQ=;
b=QruIZh5tAR6Ob3A5x4497372oBuHE3qBVI4pMDCb11By/sgVj7VWrzFcEzBKa+sZak
J5y4nddBXL7usk4ULNYROXWym6dbjgcqqCX7nEdIQvze9FW7+bM/JMR+a69dxP2MFmVr
v2P9F0xCyiU8MLXlvMQqgwmTPuyNAQgHledmWGWFzBjbKgJb7LDwM7Hs3aU7fTyRJm+1
Ue4obJVABrLq398pXAlqupNDMb4F4Ss6/HcBxKhFKugxv5dRNCJFB0VPWl+/L/8qA6Dm
1rUSVtcpoLdD1Tv+wZY9+rnzR4WVj/u/0JPhWIiH4UK4oeq0cLLEiUlVx3z5ZW4/xnlb
cmmw==
X-Gm-Message-State: ALQs6tCW+VHY1vjrOxqi926/NtpVquOr/uyKzag66grdOQjv2d3QOHcx
ITgzzFb/gW/K1WQYcwUDIpKXhav0rQUGhXagXfLCYjezYz8=
X-Google-Smtp-Source: AB8JxZrk2YDpWABvmBchDvRP6pMGHcJOS47obZEdkq/pZa72T3z10UOShV65Z5FzTjgF7CmqxSk2hmMpKTIzLbef3mA=
X-Received: by 10.55.120.68 with SMTP id t65mr15084912qkc.56.1525251456867;
Wed, 02 May 2018 01:57:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.152.219 with HTTP; Wed, 2 May 2018 01:57:36 -0700 (PDT)
In-Reply-To: <20180430125042.GA1331@argenau.bebt.de>
References: <20180430125042.GA1331@argenau.bebt.de>
From: =?UTF-8?Q?Hl=C3=A1vka=2C_Petr?= <petr.hlavka@avast.com>
Date: Wed, 2 May 2018 10:57:36 +0200
Message-ID: <CACiAdzoA3hsfNG_5Xm-2wYJyZaEYH=xhK=8BrUq5YWVZRYncDg@mail.gmail.com>
Subject: Re: AlsaMixer.app - license?
To: Andreas Metzler <ametzler@debian.org>
Content-Type: multipart/alternative; boundary="94eb2c0a95da487efd056b354749"
Status: RO
X-Status: A
Content-Length: 3528
--94eb2c0a95da487efd056b354749
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Andreas,
yes, I'm the author of modification to original Mixer.app (AlsaMixer.app).
They should be licensed under the same license as Mixer.app, some info is
available in
http://repo.or.cz/dockapps.git/blob_plain/HEAD:/AlsaMixer.app/README ,
section Copyright.
Regards, Petr Hlavka.
On Mon, Apr 30, 2018 at 2:50 PM, Andreas Metzler <ametzler@debian.org>
wrote:
> Dear Mr Hl=C3=A1vka,
>
> I guess that you are the original author of AlsaMixer.app
> <https://www.dockapps.net/alsamixerapp>. If that is not case I am
> sorry for bothering you unnecessaly but would appreciate if you told
> me. - Thanks in advance
>
> On the other hand if you are the author it would be helpful if you could
> clarify the question of licensing. AlsaMixer.app is based on Mixer.app
> which is licensed under GNU General Public License version 2 or later.
> The modifications and additions for AlsaMixer.app only a carry a
> copyright info but no licensing info:
>
> Copyright
> --------------------------------------------------------------
> AlsaMixer.app, 2004, Petr Hlavka
> [...]
> // AChannel.cc, Petr Hlavka, 2004
>
> I guess that your contributions are also available under GPL v2 or
> later. Could you confirm this?
>
> Thanks in advance, kind Regards
>
> Andreas Metzler
>
--94eb2c0a95da487efd056b354749
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello Andreas,<div><br></div><div>yes, I'm the author =
of modification to original Mixer.app (AlsaMixer.app). They should be licen=
sed under the same license as Mixer.app, some info is available in=C2=A0<a =
href=3D"http://repo.or.cz/dockapps.git/blob_plain/HEAD:/AlsaMixer.app/READM=
E">http://repo.or.cz/dockapps.git/blob_plain/HEAD:/AlsaMixer.app/README</a>=
, section Copyright.</div><div><br></div><div>=C2=A0 Regards, Petr Hlavka.=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mo=
n, Apr 30, 2018 at 2:50 PM, Andreas Metzler <span dir=3D"ltr"><<a href=
=3D"mailto:ametzler@debian.org" target=3D"_blank">ametzler@debian.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Mr Hl=C3=A1vka,<br>
<br>
I guess that you are the original author of AlsaMixer.app<br>
<<a href=3D"https://www.dockapps.net/alsamixerapp" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.dockapps.net/<wbr>alsamixerapp</a>>. If that=
is not case I am <br>
sorry for bothering you unnecessaly but would appreciate if you told<br>
me. - Thanks in advance<br>
<br>
On the other hand if you are the author it would be helpful if you could<br=
>
clarify the question of licensing. AlsaMixer.app is based on Mixer.app<br>
which is licensed under GNU General Public License version 2 or later.<br>
The modifications and additions for AlsaMixer.app only a carry a<br>
copyright info but no licensing info:<br>
<br>
Copyright<br>
------------------------------<wbr>------------------------------<wbr>--<br=
>
AlsaMixer.app, 2004, Petr Hlavka<br>
[...]<br>
// AChannel.cc, Petr Hlavka, 2004<br>
<br>
I guess that your contributions are also available under GPL v2 or<br>
later. Could you confirm this?<br>
<br>
Thanks in advance, kind Regards<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Andreas Metzler<br>
</font></span></blockquote></div><br></div>
-removed unused functions and simplified the source code.
-change the main function, whereby the program starts as dockapp on
Fluxbox and Openbox.
-attach a html-page "wmcliphist.html", in what the menu items of the
program are shortly described.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Previously, a green hint line was drawn on the CPU window for each
multiple of 1. This meant as the load average approached 40 (the
height of the window), the window would gradually fill up entirely
with green.
To get around this, we switch to a yellow hint line for each
multiple of 10 once the load passes 10. And then a red hint line
for each multiple of 100 once the load passes 100.
This fixes Debian bug #894801, reported by Pedro Gimeno
<debian.bts@personal.formauri.es>.
The system load monitor displays green hint lines at every 100 units once
load average rises above 100.
Previously, the vertical position of these lines was computed before
each and every pixel was drawn. But since the horizontal position
isn't needed for this computation, we move it up a level to the
outer for loop.
Previously, we looped through the history and added 100 whenever we found
a larger value. This has a number of problems. In particular,
* We get a maximum possible value of 5500 (100 * the number of values in
the history). It is certainly possible to have a system load north of
this on modern systems.
* If the system load in history were to jump by more than 100 in a single
step, then we wouldn't be adding enough. For example, suppose the
system load in history is 175, and our height was previously computed
to be 200. Suppose the next value in history is 320. We would add
100 to get a new height of 300, which isn't sufficient to display the
320.
The fix is simple -- replace the if statement with a while loop, i.e.,
continue adding 100 until we get a height that fits our value.
Patch by David Johnson <davijoh3@cisco.com> to fix Debian bug #816872 [1]:
> wmbattery appears to have a memory leak. When invoked with "wmbattery -w 2"
> it is leaking approx 350KB/minute on my system. Eventually it runs out of
> memory and is killed by kernel.
...
> I've concluded libupower-glib is just super leaky. The below patch
> moves the upower API calls into a child process that doesn't exist for
> long to keep the leaks out of the main process.
> Tested against stretch versions, looks good.
[1] https://bugs.debian.org/816872
In addition to accounting for the various changes in the new version, we
also rename from the deprecated 1x section to just 1 and get the
current version number from autoconf.
Now that we use libdockapp's --windowed option to allow users to choose
whether to run fookb as a dockapp or as a normal windowed application at
runtime, the --enable-wmaker option compile time option did very little.
In particular, it used a config file in ~/GNUstep/Defaults and it printed
a warning message when users used large icon files.
We now use the ~/.fookb config file in all instances and always print the
warning message.
In addition to the obvious simplification to the code by removing all the
window creation stuff, this also allows us to let users pick whether they
want to run fookb as a dockapp or as a normal windowed application at
runtime using libdockapp's --windowed command line option. Previously,
this was done during build using configure's --enable-wmaker option.
Previously, we would try and read the width and height of images read from
an XPM file *before* doing any error handling to determine whether we
successfully read the file in the first place. If there had been an error,
then there would be a segfault.
libdockapp supports shaped dockapps with the DASetShape() function, but this
function requires as input a bitmap. Previously, there was no support for
creating such a bitmap from XBM data without using Xlib directly.
We add two functions, DAMakeShapeFromData(), which is a wrapper around
XCreateBitmapFromData and allows developers to #include XBM data, and
DAMakeShapeFromFile(), which is a wrapper around XReadBitmapfile and
lets developers specify the path to an XBM file.
Some dockapps may want to handle command line options themselves, so we
make this function optional.
Previously, if this function was skipped, then a segfault would result when
trying to access the _daContext global while first creating the dockapp
window.
Now we check if _daContext has been initialized first, and if not, we
initialize it.
