Re: [PATCH 14/23] texi2txt: add support for making cross-references in the document
On 04/06/2015 10:58 AM, Christophe CURIS wrote: The texinfo format provides 3 commands @ref, @xref and @pxref to make cross references to existing @nodes in the document; it also provides a command @anchor to place arbitrary targets for cross-reference. Because these will be handy for the Installation Manual that already does some references, this patch implements the 4 commands: - change the '@node' command, that did nothing, to now track potential reference points; - add the '@anchor' command to register a new target for x-ref; - implement the 3 '@*ref' commands with similar behaviour as the texinfo format states, with support for all arguments, generating a temporary @x##@ pattern for the line target; - generate a new file (*.xrf, a sed script) at the end with the replacement for x-ref patterns with the correct line number, and perform a few consistency checks; - during the final search-and-replace used to insert the Table of Content, include the x-ref replacement. The current script has some limitations: - because we cannot know in advance the target line number for the x-ref, we insert it with a constant size of 5 characters to avoid breaking the justification alignment when doing the replace; - there is a strict order to respect between @node and @chapter/@section, which is needed because we have to include a line offset to get it right when using the order given in the texinfo manual. There must be some GNU extensions in here somewhere, as I get the following error without gawk when running the script on Compilation.texi: Error: cross reference to undefined node/anchor ConfigureOptions found at line 227 Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 07/23] doc: changed section for man page of wdread to 1x for consistency
On 04/06/2015 10:57 AM, Christophe CURIS wrote: All the man pages for our tools that interact with Window Maker are placed in the 1x section, but the wdread page was an exception for no known reason. For consistency, this patch renames the file to the same 1x section. Thanks for these patches, Christophe! I'm wondering, though, if we should change all of the sections to 1 instead of 1x, as it appears deprecated. Not even X manpages use 1x any more. On my system, ls /usr/share/man/man1 | grep 1x returns only Window Maker-related manpages. Doug
Re: [PATCH 03/23] WINGs: mark the script 'get-wings-flags' as deprecated
Hi Christophe, On 04/06/2015 10:57 AM, Christophe CURIS wrote: --- a/doc/get-wings-flags.1 +++ b/doc/get-wings-flags.1 @@ -1,32 +1,32 @@ .TH get-wings-flags 1 22 March 2005 .SH NAME -\fBget-wings-flags\fR \- output libWINGs compile and linker flags +\fBget-wings-flags\fP \- output libWINGs compiler and linker flags (deprecated) .PP .SH SYNOPSIS -.B get-wings-flags \fR[ \fI\-\-cflags \fR] [ \fI\-\-ldflags \fR] -[ \fI\-\-libs \fR] -.PP +.B pkg-config +.R WINGs I'm getting the following warnings when I run man --warnings ./get-wings-flags.1 /dev/null: `R' is a string (producing the registered sign), not a macro. `R' is a string (producing the registered sign), not a macro. This is true for all the get-*-flags manpages. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 15/23] doc: convert INSTALL-WMAKER into a texinfo source processed by texi2txt
On 04/06/2015 10:58 AM, Christophe CURIS wrote: diff --git a/doc/build/Makefile.am b/doc/build/Makefile.am index 93e3e8b..c80394e 100644 --- a/doc/build/Makefile.am +++ b/doc/build/Makefile.am @@ -1,10 +1,20 @@ # The list of sources are distributed, but none are to be # installed along with Window Maker: EXTRA_DIST = Readme \ + Compilation.texi \ Translations.texi # How to re-generate automatically the top-level text files -all-local: $(top_srcdir)/README.i18n +all-local: $(top_srcdir)/INSTALL-WMAKER $(top_srcdir)/README.i18n + +$(top_srcdir)/INSTALL-WMAKER: $(srcdir)/Compilation.texi $(top_srcdir)/script/generate-txt-from-texi.sh + $(AM_V_GEN)if test ! -e $(top_srcdir)/INSTALL-WMAKER -o -w $(top_srcdir)/INSTALL-WMAKER ; then \ + $(top_srcdir)/script/generate-txt-from-texi.sh \ + $(srcdir)/Compilation.texi -o $(top_srcdir)/INSTALL-WMAKER \ + -Dversion=$(PACKAGE_VERSION) -e $(PACKAGE_BUGREPORT) ; \ + else \ + echo Warning: \$(top_srcdir)/INSTALL-WMAKER\ is not writeable, not regenerated ; \ + fi Would it be possible for this to run during make dist? Right now, the INSTALL-WMAKER in a make dist-generated tarball is the one generated by autogen.sh and lists git#next as its version (the default). But when Window Maker is built, a new INSTALL-WMAKER is generated with the version from configure.ac. This can cause problems, e.g., when building Debian packages where the source tree is expected to match the source tarball. There's no problem the first time, but the build fails on successive attempts. This is also a problem for README.i18n. Thanks! Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Bug: History, Auto complete and Command execution in Run dialog
On 02/12/2015 04:18 PM, Juan Giordana wrote: I still don't get the History/Auto complete feature if I use the Keyboard shortcuts preferences for setting the shortcut, but at least the Run dialog is working again. Thanks for reporting this! The keyboard shortcut was using the %a syntax, which doesn't support history and autocomplete, instead of %A, which does. I've just submitted a patch to fix this. Doug
Re: [dockapp] ALSA mixer
On 02/01/2015 09:15 AM, Roman Dobosz wrote: Eventually, I've decided to dust off my C skills and give a try to implement the mixer using wmsmixer as a base. You can find the resoult on bitbucket[2] or github[3]. Reviews and criticism are welcome :) Great, thanks for sharing! Just curious, why a fork instead of submitting patches for wmsmixer? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/1] wmmenu
On 01/22/2015 05:37 PM, Nerijus Baliunas wrote: The patches should probably be applied from FreeBSD, Gentoo, etc. I am attaching the quick patch which helps to compile on my system. Thanks. I'll try to take a look at it in the next few days. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH (whome)] Update wmnet on dockapps webpage.
From: Carlos R. Mafra [crma...@gmail.com] Sent: Sunday, January 11, 2015 7:49 AM To: wmaker-dev@lists.windowmaker.org Subject: Re: [PATCH (whome)] Update wmnet on dockapps webpage. Wow, you are fast. But I had to rebase the last commit, so the above reference is no longer valid. Next time I will be more careful, I had no idea you'd notice within a few minutes. I subscribe to the RSS feed via email so I don't miss any commits. :) I'll send a new patch here in a moment. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH (whome)] Update wmnet on dockapps webpage.
From: Torrance, Douglas [dtorra...@monmouthcollege.edu] Sent: Sunday, January 11, 2015 8:03 AM To: 'wmaker-dev@lists.windowmaker.org' Subject: RE: [PATCH (whome)] Update wmnet on dockapps webpage. From: Carlos R. Mafra [crma...@gmail.com] Sent: Sunday, January 11, 2015 7:49 AM To: wmaker-dev@lists.windowmaker.org Subject: Re: [PATCH (whome)] Update wmnet on dockapps webpage. Wow, you are fast. But I had to rebase the last commit, so the above reference is no longer valid. I'll send a new patch here in a moment. I think I may have snuck in the original patch right after your rebase, because the hash doesn't seem to have changed. The hash is visible at [1] in the urls for the snapshot links. They give c70d3fcb8cff5d407fd3a732e1342c779aee8678, which is the hash in my patch. Doug [1] http://repo.or.cz/w/dockapps.git/tree/HEAD:/wmnet -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH 3/4] WINGs: move declaration from WINGs.h into WUtil for consistency
From: Carlos R. Mafra [crma...@gmail.com] Sent: Monday, January 05, 2015 9:39 AM To: wmaker-dev@lists.windowmaker.org Subject: Re: [PATCH 3/4] WINGs: move declaration from WINGs.h into WUtil for consistency I suppose not too many programs use the library anyway. Do you know any? WPrefs? Ok, that was an easy one ;-) I don't think there are a lot of app left, but on the other hand the change would impact apps that use only WUtil, not WINGs, and that's probably even less... There's wdm, I've just realized. On Debian-based systems, a reverse dependency lookup on the library packages reveals two more: wmforecast (which I maintain and can easily update) and fookb-wmaker (which depends on WUtil but not WINGs). Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] WPrefs: add possibility to configure the size of the aperçu
Pardon the noise -- I neglected to commit before running git send-email. :\
Doug
From: Doug Torrance [douglas.a.torra...@gmail.com] on behalf of Doug Torrance
[dtorra...@monmouthcollege.edu]
Sent: Sunday, December 21, 2014 9:20 PM
To: wmaker-dev@lists.windowmaker.org
Cc: Christophe CURIS
Subject: [PATCH] WPrefs: add possibility to configure the size of the aperçu
From: Christophe CURIS christophe.cu...@free.fr
The Icon preference panel have been rearranged to include a slider which
controls the size of the Aperçu. This slider is also used to turn off the
feature, so the related checkbox have been removed from the Misc preference
panel, because it is more convenient to have the related settings at the
same place.
Signed-off-by: Christophe CURIS christophe.cu...@free.fr
---
WPrefs.app/Icons.c | 217 ++-
WPrefs.app/Preferences.c | 5 +-
WPrefs.app/po/nl.po | 4 +-
3 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/WPrefs.app/Icons.c b/WPrefs.app/Icons.c
index 0faaa5f..f50c36e 100644
--- a/WPrefs.app/Icons.c
+++ b/WPrefs.app/Icons.c
@@ -66,6 +66,10 @@ typedef struct _Panel {
WMFrame *posVF;
WMFrame *posV;
+ struct {
+ int width, height;
+ } icon_position;
+
WMButton *posB[wlengthof_nocheck(icon_position_dbvalue)];
WMFrame *animF;
@@ -76,12 +80,28 @@ typedef struct _Panel {
WMButton *omnB;
WMButton *sclB;
+ struct {
+ WMFrame *frame;
+ WMSlider *slider;
+ WMLabel *label;
+ } apercu;
+
WMFrame *sizeF;
WMPopUpButton *sizeP;
int iconPos;
} _Panel;
+/*
+ * Minimum size for an Apercu:
+ * This value is actually twice the size of the minimum icon size choosable.
+ * We set the slider min to taht number minus one, because when set to this
+ * value WPrefs will consider that the user wants the feature turned off.
+ */
+static const int apercu_minimum_size = 2 * 24 - 1;
+
+static const int apercu_maximum_size = 512;/* Arbitrary limit for the
slider */
+
#define ICON_FILE iconprefs
static void showIconLayout(WMWidget * widget, void *data)
@@ -111,21 +131,44 @@ static void showIconLayout(WMWidget * widget, void *data)
WMMoveWidget(panel-posV, 2, 2);
break;
case 2:
- WMMoveWidget(panel-posV, 95 - 2 - w, 2);
+ WMMoveWidget(panel-posV, panel-icon_position.width - 2 - w,
2);
break;
case 4:
- WMMoveWidget(panel-posV, 2, 70 - 2 - h);
+ WMMoveWidget(panel-posV, 2, panel-icon_position.height - 2 -
h);
break;
default:
- WMMoveWidget(panel-posV, 95 - 2 - w, 70 - 2 - h);
+ WMMoveWidget(panel-posV, panel-icon_position.width - 2 - w,
panel-icon_position.height - 2 - h);
break;
}
}
+static void apercu_slider_changed(WMWidget *w, void *data)
+{
+ _Panel *panel = (_Panel *) data;
+ char buffer[64];
+ int value;
+
+ /* Parameter is not used, but tell the compiler that it is ok */
+ (void) w;
+
+ value = WMGetSliderValue(panel-apercu.slider);
+
+ /* Round the value to a multiple of 8 because it makes the displayed
value look better */
+ value = ~7;
+
+ if (value = apercu_minimum_size)
+ sprintf(buffer, _(OFF));
+ else
+ sprintf(buffer, %i, value);
+
+ WMSetLabelText(panel-apercu.label, buffer);
+}
+
static void showData(_Panel * panel)
{
int i;
char *str;
+ Bool b;
WMSetButtonSelected(panel-arrB, GetBoolForKey(AutoArrangeIcons));
WMSetButtonSelected(panel-omnB, GetBoolForKey(StickyIcons));
@@ -154,6 +197,19 @@ static void showData(_Panel * panel)
i = 9;
WMSetPopUpButtonSelectedItem(panel-sizeP, i);
+ /* Apercu */
+ b = GetBoolForKey(MiniwindowApercuBalloons);
+ if (b) {
+ i = GetIntegerForKey(ApercuSize);
+ if (i = apercu_minimum_size)
+ i = apercu_minimum_size;
+ } else {
+ i = apercu_minimum_size;
+ }
+ WMSetSliderValue(panel-apercu.slider, i);
+ apercu_slider_changed(panel-apercu.slider, panel);
+
+ /* Animation */
str = GetStringForKey(IconificationStyle);
if (str != NULL) {
for (i = 0; i wlengthof(icon_animation); i++) {
@@ -174,50 +230,87 @@ static void showData(_Panel * panel)
static void createPanel(Panel * p)
{
_Panel *panel = (_Panel *) p;
+ WMScreen *scr;
WMColor *color;
int i;
char buf[16];
+ int swidth, sheight;
+ int width, height;
+ int startx, starty;
panel-box = WMCreateBox(panel-parent);
WMSetViewExpandsToParent(WMWidgetView(panel-box), 2, 2, 2, 2);
Re: [PATCH (dockapps)] Add wmcdplay information for dockapps webpage.
On Dec 18, 2014, at 11:46 PM, Yury Tarasievich yury.tarasiev...@gmail.com wrote: Doug, please explain to git noobs here, what do we do to get all these nice changes you make to dockapps? Is all this being put into wmaker's repo? Tarballs are available at http://windowmaker.org/dockapps/ :) -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
'O_NOFOLLOW' undeclared
The saga of getting the next branch to build on Ubuntu precise continues... Everything works fine now with autoconf 2.69, but I'm getting the following error later on: findfile.c: In function 'wcopy_file': findfile.c:437:37: error: 'O_NOFOLLOW' undeclared (first use in this function) findfile.c:437:37: note: each undeclared identifier is reported only once for each function it appears in This doesn't make much sense, as I check and O_NOFOLLOW definitely appears in fcntl.h. Any ideas? (The full build log is at [1].) Thanks! Doug [1] https://launchpadlibrarian.net/192744621/buildlog_ubuntu-precise-amd64.wmaker_0.95.6%2B20141215-0ppa20141208~ubuntu12.04.1_FAILEDTOBUILD.txt.gz -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH 1/1] configure: require a minimum version for Autoconf to avoid wrong generation
Thanks for figuring this out, Cristophe! Fortunately, I found another PPA which has backported autoconf 2.69 to precise [1], so I've added it as a dependency to mine. We'll see how the next automatic build goes! Doug [1] https://launchpad.net/~dns/+archive/ubuntu/gnu From: Christophe CURIS [christophe.cu...@free.fr] Sent: Monday, December 15, 2014 1:43 PM To: Window Maker Devel Subject: [PATCH 1/1] configure: require a minimum version for Autoconf to avoid wrong generation As found by Douglas Torrance, when the 'configure' script is generated using v2.68 of autoconf then it gets wrongly generated due to a regression in the handling of names in AS_VAR_PUSHDEF, and crashes with this kind of sibylline messages: checking CFLAGS for -Wtrampolines... ./configure: line 11916: wm_cv_c_check_compopt_Werror_trampolines=no, unknown: command not found This patch adds a check on autoconf version to ensure the problem will get caught as soon as possible. Signed-off-by: Christophe CURIS christophe.cu...@free.fr --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index c9ed50c..ad4bef6 100644 --- a/configure.ac +++ b/configure.ac @@ -8,7 +8,14 @@ dnl autoconf dnl libtoolize --force --automake dnl automake -a --gnu --include-deps dnl + + +dnl Due to a bug in Autoconf 2.68 (apparently a regression), we need at least +dnl version 2.68b which includes this patch: +dnl http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=2b0d95faef68d7ed7c08b0edb9ff1c38728376fa dnl +dnl Because the 2.69 was released only a few month later, let's just ask for it +AC_PREREQ([2.69]) AC_INIT(WindowMaker, 0.95.6, , WindowMaker, http://www.windowmaker.org/) -- 2.1.3 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: nanosleep configure check in Ubuntu precise
Thanks again for looking at this, Christophe!
I removed -DGLOBAL_DEFAULTS_SUBDIR from CFLAGS and there were no changes.
As requested, I've attached the diff between the non-working configure and a
working configure from Ubuntu 14.10.
It looks like that 6299as_VAR snuck in on this line (1097 in the diff):
CFLAGS=$CFLAGS $$as_VAR
(My apologies for top posting. My employer appears to have changed some
Exchange settings and I'm stuck using webmail...)
From: Christophe [christophe.cu...@free.fr]
Sent: Saturday, December 13, 2014 9:43 AM
To: wmaker-dev@lists.windowmaker.org
Subject: Re: nanosleep configure check in Ubuntu precise
- Douglas Torrance dtorra...@monmouthcollege.edu a écrit :
On 12/12/2014 06:31 PM, Christophe wrote:
Hi according to your log file, there are way more things that just that
which seems to not be properly detected. Would you happen to have the
config.log to share?
I was able to reproduce the failed build locally with pbuilder, and have
attached the config.log.
Thanks, it helps but also confuses a little bit more...
There is this, coming back too frequently:
command-line:0:25: warning: missing terminating character [enabled by
default]
command-line:0:25: error: missing terminating character [-Werror]
May you give a try without the -DGLOBAL_DEFAULTS_SUBDIR to see if it is only
a quoting issue? (on a side note, conceptually it should be in CPPFLAGS, but it
is clearly not the problem here).
There is, on the other end, also this kind of message later:
gcc: error: 6299as_VAR: No such file or directory
which looks legit, as the command line is reported to be:
configure:12999: gcc -c -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
-DGLOBAL_DEFAULTS_SUBDIR=\GNUstep/Defaults\ 6299as_VAR -pedantic -Werror
-Wno-deprecated -D_FORTIFY_SOURCE=2 -DNDEBUG conftest.c 5
It looks like the command line is being polluted somewhere in the process.
Could I suspect a problem of version with autotools? 2.68 does not sound that
old...
It could be interesting to make a diff between your usual 'configure' that
works and the one generated in this build process.
I would suggest also that instead of running 'autogen.sh' in your build
environment, you run instead 'make dist' in your usual dev environment and then
use that package for the build, if that is not opposite to Ubuntu's build
methods.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
--- configure-precise 2014-12-13 16:23:22.402348498 -0600
+++ configure-utopic 2014-12-13 16:32:58.175387006 -0600
@@ -1,11 +1,9 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.68 for WindowMaker 0.95.6+20141210.
+# Generated by GNU Autoconf 2.69 for WindowMaker 0.95.6+20141210.
#
#
-# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
-# 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-# Foundation, Inc.
+# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
#
#
# This configure script is free software; the Free Software Foundation
@@ -134,6 +132,31 @@ export LANGUAGE
# CDPATH.
(unset CDPATH) /dev/null 21 unset CDPATH
+# Use a proper internal environment variable to ensure we don't fall
+ # into an infinite loop, continuously re-executing ourselves.
+ if test x${_as_can_reexec} != xno test x$CONFIG_SHELL != x; then
+_as_can_reexec=no; export _as_can_reexec;
+# We cannot yet assume a decent shell, so we have to provide a
+# neutralization value for shells without unset; and this also
+# works around shells that cannot unset nonexistent variables.
+# Preserve -v and -x to the replacement shell.
+BASH_ENV=/dev/null
+ENV=/dev/null
+(unset BASH_ENV) /dev/null 21 unset BASH_ENV ENV
+case $- in #
+ *v*x* | *x*v* ) as_opts=-vx ;;
+ *v* ) as_opts=-v ;;
+ *x* ) as_opts=-x ;;
+ * ) as_opts= ;;
+esac
+exec $CONFIG_SHELL $as_opts $as_myself ${1+$@}
+# Admittedly, this is quite paranoid, since all the known shells bail
+# out after a failed `exec'.
+$as_echo $0: could not re-execute with $CONFIG_SHELL 2
+as_fn_exit 255
+ fi
+ # We don't want this to propagate to other subprocesses.
+ { _as_can_reexec=; unset _as_can_reexec;}
if test x$CONFIG_SHELL = x; then
as_bourne_compatible=if test -n \\${ZSH_VERSION+set}\ (emulate sh) /dev/null 21; then :
emulate sh
@@ -167,7 +190,8 @@ if ( set x; as_fn_ret_success y test
else
exitcode=1; echo positional parameters were not saved.
fi
-test x\$exitcode = x0 || exit 1
+test x\$exitcode = x0 || exit 1
+test -x / || exit 1
as_suggested= as_lineno_1=;as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested as_lineno_1a=\$LINENO
as_lineno_2=;as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested as_lineno_2a=\$LINENO
eval 'test \x\$as_lineno_1'\$as_run'\ != \x\$as_lineno_2'\$as_run'\
nanosleep configure check in Ubuntu precise
Commit ff8fc10 introduced a check in the configure script for the nanosleep function. I maintain a Launchpad ppa which automatically builds Window Maker packages from next for Ubuntu. Everything builds just fine, except for the Precise Pangolin (Ubuntu 12.04) package, which results in an error: configure: error: function 'nanosleep' not found, please report to wmaker-dev@lists.windowmaker.org The full build log is available at [1]. Any ideas on what might be happening? Thanks! Doug [1] https://launchpadlibrarian.net/192491416/buildlog_ubuntu-precise-amd64.wmaker_0.95.6%2B20141210-0ppa20141208~ubuntu12.04.1_FAILEDTOBUILD.txt.gz
Re: nanosleep configure check in Ubuntu precise
On 12/12/2014 06:31 PM, Christophe wrote: Hi according to your log file, there are way more things that just that which seems to not be properly detected. Would you happen to have the config.log to share? I was able to reproduce the failed build locally with pbuilder, and have attached the config.log. Doug This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by WindowMaker configure 0.95.6+20141210, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure --prefix=/usr --mandir=/usr/share/man --includedir=/usr/include --sysconfdir=/etc --datadir=/usr/share --with-nlsdir=/usr/share/locale --with-pixmapdir=/usr/include/X11/pixmaps --with-gnustepdir=/usr/share/lib/GNUstep/System --disable-locale --enable-modelock --enable-xinerama CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -DGLOBAL_DEFAULTS_SUBDIR=\GNUstep/Defaults\ CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro ## - ## ## Platform. ## ## - ## hostname = gloria uname -m = x86_64 uname -r = 3.16.0-24-generic uname -s = Linux uname -v = #32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin ## --- ## ## Core tests. ## ## --- ## configure:2479: checking for a BSD-compatible install configure:2547: result: /usr/bin/install -c configure:2558: checking whether build environment is sane configure:2608: result: yes configure:2749: checking for a thread-safe mkdir -p configure:2788: result: /bin/mkdir -p configure:2801: checking for gawk configure:2831: result: no configure:2801: checking for mawk configure:2817: found /usr/bin/mawk configure:2828: result: mawk configure:2839: checking whether make sets $(MAKE) configure:2861: result: yes configure:2890: checking whether make supports nested variables configure:2907: result: yes configure:3049: checking for gcc configure:3065: found /usr/bin/gcc configure:3076: result: gcc configure:3305: checking for C compiler version configure:3314: gcc --version 5 gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3325: $? = 0 configure:3314: gcc -v 5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) configure:3325: $? = 0 configure:3314: gcc -V 5 gcc: error: unrecognized option '-V' gcc: fatal error: no input files compilation terminated. configure:3325: $? = 4 configure:3314: gcc -qversion 5 gcc: error: unrecognized option '-qversion' gcc: fatal error: no input files compilation terminated. configure:3325: $? = 4 configure:3345: checking whether the C compiler works configure:3367: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -DGLOBAL_DEFAULTS_SUBDIR=\GNUstep/Defaults\ -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c 5 command-line:0:25: warning: missing terminating character [enabled by default] configure:3371: $? = 0 configure:3419: result: yes configure:3422: checking for C compiler default output file name configure:3424: result: a.out configure:3430: checking for suffix of executables configure:3437: gcc -o conftest -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -DGLOBAL_DEFAULTS_SUBDIR=\GNUstep/Defaults\ -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c 5 command-line:0:25:
Re: [PATCH] Keep mute state from getting out of sync with reality
On 12/04/2014 02:18 AM, Doug Torrance wrote: From: Robert Jacobs rnjac...@mit.edu --- AlsaMixer.app/AMixer/AChannel.cc | 3 +++ AlsaMixer.app/Mixer.cc | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) FYI, I received this patch as a pull request on my GitHub dockapps mirror: https://github.com/d-torrance/dockapps/pull/2 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
windowmaker.org and mod_rewrite?
Does anyone know if windowmaker.org is run on apache? If so, is mod_rewrite [1] enabled? If it is, or if it could be, I'd like to try and make some urls more intuitive, e.g., http://windowmaker.org/dockapps/wmclock instead of http://windowmaker.org/dockapps/?name=wmclock Thanks! Doug [1] http://httpd.apache.org/docs/current/mod/mod_rewrite.html
Re: Window Maker as the official window manager of the GNU operating system
On 11/23/2014 11:49 AM, kix wrote: On 21/11/2014 14:52, Torrance, Douglas wrote: Reading through the GNU Maintainer's guide, a lot of things seem optional. For example: We recommend using savannah.gnu.org for the source code repository for your package, but that’s not required. Although it would be easy enough to mirror the git repository, and it would finally provide a bug tracker! If you want this, just do it. If you need help, I could collaborate. Although I was initially on the pro-GNU side of things, I've lost all interest after Bruno's fork threat.
Re: Window Maker as the official window manager of the GNU operating system
On 11/21/2014 02:45 AM, Carlos R. Mafra wrote: I am the current maintainer, in the current 6-year-old setup. I don't want to change under the GNU umbrella and be bounded by its philosophy and way of doing things. I don't have time to learn all the needed stuff and change my ways of doing things. I'd say that if you want to use Window Maker, then use it. Is the GNU maintainer required to be the same person as the Window Maker maintainer? If Carlos doesn't have the time to do all these things but is still interested in this partnership happening, then perhaps someone else could. Reading through the GNU Maintainer's guide, a lot of things seem optional. For example: We recommend using savannah.gnu.org for the source code repository for your package, but that’s not required. Although it would be easy enough to mirror the git repository, and it would finally provide a bug tracker! The advertised bug-reporting email address should always be ‘bug-pack...@gnu.org’, to help show users that the program is a GNU package, but it is ok to set up that list to forward to another site if you prefer. We could just forward to this list, etc.
Re: Window Maker as the official window manager of the GNU operating system
Argh, somehow all my quotation formatting disappeared from this email. Let's try this again: On 11/21/2014 02:45 AM, Carlos R. Mafra wrote: I am the current maintainer, in the current 6-year-old setup. I don't want to change under the GNU umbrella and be bounded by its philosophy and way of doing things. I don't have time to learn all the needed stuff and change my ways of doing things. I'd say that if you want to use Window Maker, then use it. Is the GNU maintainer required to be the same person as the Window Maker maintainer? If Carlos doesn't have the time to do all these things but is still interested in this partnership happening, then perhaps someone else could. Reading through the GNU Maintainer's guide, a lot of things seem optional. For example: We recommend using savannah.gnu.org for the source code repository for your package, but that’s not required. Although it would be easy enough to mirror the git repository, and it would finally provide a bug tracker! The advertised bug-reporting email address should always be ‘bug-pack...@gnu.org’, to help show users that the program is a GNU package, but it is ok to set up that list to forward to another site if you prefer. We could just forward to this list, etc.
Re: Window Maker on FreshCode?
On 11/20/2014 03:58 AM, Andreas Tscharner wrote: Hello World, I wonder why WindowMaker is not on FreshCode? FreshCode is the successor of the well-known FreshMeat and later FreeCode platform. Because no one had submitted it yet. I just took a couple minutes and did it: http://freshcode.club/projects/wmaker It's freely editable, so feel free to change things.
Re: Window Maker as the official window manager of the GNU operating system
On 11/20/2014 02:14 PM, Bruno Félix Rezende Ribeiro wrote: Other important guidelines are that the program should support a GNU build system (Window Maker already does) and, ideally, have a manual written in GNU Texinfo. I actually started converting (and updating) the FAQ to Texinfo a few months ago. This might give me the impetus to finish. :)
Re: [PATCH 12/32] wmaker: minor fixes for the size of an aperçu
On 11/17/2014 08:34 AM, David Maciejak wrote:
Are you sure it's safe to change the test in that following code ?
- if (shortenTitle wPreferences.miniwin_title_balloon) {
+ if (shortenTitle != NULL) {
It looks like the wPreferences.miniwin_title_balloon check is redundant
now because of the following change:
if (wPreferences.miniwin_title_balloon) {
- shortenTitle = ShrinkString(font, title, width -
APERCU_BORDER);
+ shortenTitle = ShrinkString(font, title, width -
APERCU_BORDER * 2);
titleHeight = countLines(shortenTitle) * WMFontHeight(font)
+ 4;
height += titleHeight;
+ } else {
+ shortenTitle = NULL;
+ titleHeight = 0;
}
Doug
Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.6-54-g4a2e202a
It doesn't appear that patch 1/3 of my recent series fixing some
compiling issues with the WINGs examples [1] made it in to this last
update. Was this an oversight? I've attached the patch to this email.
Thanks!
Doug
[1] http://lists.windowmaker.org/dev/msg07388.html
On 11/02/2014 06:27 AM, crmafra wrote:
- Log -
http://repo.or.cz/w/wmaker-crm.git/commit/4a2e202af8c0d9872ea8a7a66aa0f0f72fc40db5
commit 4a2e202af8c0d9872ea8a7a66aa0f0f72fc40db5
Author: Doug Torrance dtorra...@monmouthcollege.edu
Date: Thu Oct 30 16:24:47 2014 -0500
WINGs: Avoid cast from pointer to integer of different size compiler
warnings.
diff --git a/WINGs/Examples/fontl.c b/WINGs/Examples/fontl.c
index 4f4eaabb..a440a22c 100644
--- a/WINGs/Examples/fontl.c
+++ b/WINGs/Examples/fontl.c
@@ -23,6 +23,7 @@
#include stdint.h
#include WINGs/WINGs.h
#include WINGs/WUtil.h
+#include inttypes.h
void wAbort()
{
@@ -35,7 +36,7 @@ void show(WMWidget * self, void *data)
void *d;
WMLabel *l = (WMLabel *) data;
d = WMGetHangedData(self);
- sprintf(buf, %i - 0x%x - 0%o, (int)d, (int)d, (int)d);
+ sprintf(buf, %PRIiPTR - 0x%PRIxPTR - 0%PRIoPTR, (intptr_t) d,
(intptr_t) d, (intptr_t) d);
WMSetLabelText(l, buf);
}
http://repo.or.cz/w/wmaker-crm.git/commit/a47f07cfc30e87fd9ed542ad940a6c46624a5703
commit a47f07cfc30e87fd9ed542ad940a6c46624a5703
Author: Doug Torrance dtorra...@monmouthcollege.edu
Date: Thu Oct 30 16:24:46 2014 -0500
WINGs: Fix unused parameter compiler warnings in examples.
diff --git a/WINGs/Examples/colorpick.c b/WINGs/Examples/colorpick.c
index 24daa2ce..3d6a2dc4 100644
--- a/WINGs/Examples/colorpick.c
+++ b/WINGs/Examples/colorpick.c
@@ -7,6 +7,7 @@ void showSelectedColor(void *self, void *cdata)
{
WMColorPanel *panel = (WMColorPanel *) self;
+ (void) cdata;
printf(Selected Color: %sn,
WMGetColorRGBDescription(WMGetColorPanelColor(panel)));
}
diff --git a/WINGs/Examples/fontl.c b/WINGs/Examples/fontl.c
index 6e08a90b..4f4eaabb 100644
--- a/WINGs/Examples/fontl.c
+++ b/WINGs/Examples/fontl.c
@@ -41,6 +41,8 @@ void show(WMWidget * self, void *data)
void quit(WMWidget * self, void *data)
{
+ (void) self;
+ (void) data;
exit(0);
}
diff --git a/WINGs/Examples/puzzle.c b/WINGs/Examples/puzzle.c
index 0c50b75b..ca1af101 100644
--- a/WINGs/Examples/puzzle.c
+++ b/WINGs/Examples/puzzle.c
@@ -155,6 +155,9 @@ static void resizeObserver(void *self, WMNotification *
notif)
WMSize size = WMGetViewSize(WMWidgetView(win));
int x, y;
+ (void) self;
+ (void) notif;
+
WinSize = size.width;
for (y = 0; y Size; y++) {
for (x = 0; x Size; x++) {
From 36318e1081c3780453fbebfafb9b9001d8154d8f Mon Sep 17 00:00:00 2001
From: Doug Torrance dtorra...@monmouthcollege.edu
Date: Thu, 30 Oct 2014 12:27:23 -0500
Subject: [PATCH 1/3] WINGs: Link examples against Xlib.
The font lister WINGs example program was failing to build because it uses
the XOpenDisplay() function from Xlib.
---
WINGs/Examples/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/WINGs/Examples/Makefile.am b/WINGs/Examples/Makefile.am
index 4ddaaf2..cfab01f 100644
--- a/WINGs/Examples/Makefile.am
+++ b/WINGs/Examples/Makefile.am
@@ -8,7 +8,7 @@ noinst_PROGRAMS = fontl puzzle colorpick
LDADD= $(top_builddir)/WINGs/libWINGs.la $(top_builddir)/wrlib/libwraster.la \
$(top_builddir)/WINGs/libWUtil.la \
- @XFTLIBS@ @INTLIBS@
+ @XFTLIBS@ @INTLIBS@ @XLIBS@
colorpick_DEPENDENCIES = $(top_builddir)/WINGs/libWINGs.la
--
1.9.1
Re: Fullscreen apps and dock
On 10/17/2014 05:54 AM, Miikka Veijonen wrote: Hi, When I set video player (VLC or mplayer) or browser (in YouTube for example) in fullscreen mode the dock won't disappear. It remains above the fullscreen video. I tried different video output modules (XV, X11, OGL etc.). The same thing happens with everyone of those. If you right click on the dock and go to Dock position, what is the selection? Selecting Keep on Top will produce the behavior you described. Doug
Re: [PATCH] wmaker: Add more directions for window snapping.
On 09/25/2014 03:58 PM, Doug Torrance wrote: This patch adds the ability to snap a window to the top, bottom, or any of the four corners of the screen. It uses three new helper functions, drawSnapFrame, getSnapDirection, and doSnap, to reduce code duplication and increase readability. It also updates NEWS to indicate the additional directions. --- NEWS | 4 +- src/moveres.c | 196 ++ 2 files changed, 145 insertions(+), 55 deletions(-) Ignore this patch. I forgot to squash it with a previous commit, so it probably won't apply. Revision sent. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 2/2] NEWS: Add note about dragging maximized windows.
On 09/24/2014 11:16 PM, Yury Tarasievich wrote: I'd change the wording to in desktop environments like GNOME, Cinnamon, and Unity. Sounds good. Revised patch sent.
Re: [PATCH 1/4] wmaker: Clear maximized flag of a maximized window when moved.
On 09/22/2014 04:13 AM, Iain Patterson wrote: Sounds good. We'd need to change the option heading. How about: Dragging a maximized window: - Like other windows - Window's unmaximized geometry will be restored - Window will be considered unmaximized - Window will not move Great ideas! I'll work on a revised patch soon. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
On 09/22/2014 12:29 PM, Haroldo Gambini Santos wrote: Hi Doug, Great Feature ! Just one comment which I think that it can be improved: Apparently right now it just does windo snapping in the right/left sides. It would be great if top/bottom maximization could be done too. In particular, since my current monitor is huge, I would also love having more options: topLeft, topRight, bottomLeft, bottomRight :) But at least bottom/top I think that are important. Cheers Haroldo Thanks! Those shouldn't be too hard too implement. I'll submit a new version soon. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/4] wmaker: Add window snapping feature.
On 09/21/2014 04:33 AM, BALATON Zoltan wrote: On Sat, 20 Sep 2014, Doug Torrance wrote: This patch adds the ability to snap a window to one side of the screen by dragging it to that side. It is enabled by setting WindowSnapping = YES in ~/GNUstep/Defaults/WindowMaker. Note that window snapping is automatically disabled if DontLinkWorkspaces = NO, as this feature also involves dragging a window to one side of the screen. How is this different from Edge resistance with Attract setting in Window Handling Preferences? The window snapping feature also resizes the window, maximizing it to the left or right half of the screen. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.
On 09/21/2014 04:55 AM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote: If a user moves a window which is currently maximized, the current behavior is to keep the window geometry and maximized status unchanged. This can lead to peculiar behavior. For example, suppose a user maximizes a window to the right half of the screen (either through the window menu, keyboard shortcut, or new snapping feature), then moves it, and then attempts maximize it to the right half of the screen again. Instead of the expected result, the window is unmaximized and returned to its original geometry. This patch changes the behavior by unmaximizing any maximized window which is moved. This is consistent with other desktop environments, e.g., GNOME, Unity, and Windows. I think it's even more peculiar to start moving a window and it suddenly changing its size. Fair enough. I just tested it to check the WTH effect, and it's big. I started to move a right-half maximized window and it changed to another size., it's a big surprise. Not at all what one expects when moving a window. When moving a window the user expects it to _move_, not change its size. As I mentioned in the patch, they might, as the proposed behavior is already standard in GNOME, Unity, Windows, and possibly others (that's all I tested). Perhaps I could still add it as a configurable option? The peculiar behavior you described is of second order compared to this. And the surprise effect is much smaller since the user is expecting the window size to change anyway. Perhaps you can change this behavior by clearing the memory of its past geometry when moving a window, that's is what causes the window to return to its original geometry. Sounds good. I'll play around with that and submit a new version. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.
On 09/21/2014 04:55 AM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote: If a user moves a window which is currently maximized, the current behavior is to keep the window geometry and maximized status unchanged. This can lead to peculiar behavior. For example, suppose a user maximizes a window to the right half of the screen (either through the window menu, keyboard shortcut, or new snapping feature), then moves it, and then attempts maximize it to the right half of the screen again. Instead of the expected result, the window is unmaximized and returned to its original geometry. This patch changes the behavior by unmaximizing any maximized window which is moved. This is consistent with other desktop environments, e.g., GNOME, Unity, and Windows. I think it's even more peculiar to start moving a window and it suddenly changing its size. Fair enough. I just tested it to check the WTH effect, and it's big. I started to move a right-half maximized window and it changed to another size., it's a big surprise. Not at all what one expects when moving a window. When moving a window the user expects it to _move_, not change its size. As I mentioned in the patch, they might, as the proposed behavior is already standard in GNOME, Unity, Windows, and possibly others (that's all I tested). Perhaps I could still add it as a configurable option? The peculiar behavior you described is of second order compared to this. And the surprise effect is much smaller since the user is expecting the window size to change anyway. Perhaps you can change this behavior by clearing the memory of its past geometry when moving a window, that's is what causes the window to return to its original geometry. Sounds good. I'll play around with that and submit a new version. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/4] wmaker: Clear maximized flag of a maximized window when moved.
On 09/21/2014 01:55 PM, Iain Patterson wrote: Quoth Doug Torrance, This patch changes the behavior by clearing the maximization flag when a maximized window is moved. Then, when a window is maximized and then moved, it can be maximized again without issues. [The old way] is explicitly done like that so you can move a maximised window around without losing the ability to restore its old size. Under the old(er) behaviour, which this patch would now restore, moving a maximised window even one pixel in any one direction was enough to cause wmaker to forget the original dimensions and make restoring to them impossible. I imagine that most people would ask but why would you want to do that? in response to the idea of moving a fully-maximised window around but consider that a Maximusized, half- or corner-maximised window is also maximised as far as wmaker is concerned, and moving them is more intuitively reasonable. In fact I fairly often find myself moving really maximised windows about as well. As an example, a particularly naughty website doesn't quite render in my (small) Firefox window. Maximise Firefox. Now I can see the content but I can't see the email underneath where a colleague was asking me to look at the page. Move Firefox about. Now I can see. Now I've finished. Hit the shortcut key and Firefox bounces back to the position and size it was before. On balance I found it less annoying and illogical to have moveable maximised windows than to have windows which could be maximimised and never restored. Thanks for pointing out the advantages of the current behavior. Perhaps a compromise would be allowing three possibilities: the current behavior (set as default), moving clearing the maximized flag, and moving restoring the original geometry. I'll work on a new patch soon. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/4] NEWS: Add notes about window snapping and unmaximize on move.
On 09/21/2014 05:30 PM, Carlos R. Mafra wrote: On Sun, 21 Sep 2014 at 8:36:54 -0500, Doug Torrance wrote: +Window snapping +--- + +You can now snap a window to one side of the screen by dragging it to that +side. It is enabled by setting WindowSnapping = YES in +~/GNUstep/Defaults/WindowMaker or selecting Enable window snapping under +Expert User Preferences in WPrefs.app. + You should add a description of what 'snap' is supposed to do (ie maximize left or right). It's not obvious to me at least that 'snap' has this meaning. +Note that window snapping is automatically disabled if DontLinkWorkspaces = +NO, as this feature also involves dragging a window to one side of the +screen. You should also mention that 'DontLinkWorkspaces' is the option 'Switch workspaces while dragging windows' in the Workspace tab of WPrefs.app. Otherwise you are not being too useful to a regular user who doesn't want to read the source code to find out where 'DontLinkWorkspaces' can be found or what it means (since the name is not intuitive). Thanks for the comments, Carlos! I'm sending a new patch, this time just with a revised note about window snapping, as I may be revising the unmaximize on move feature to include the current behavior as an option based on Iain's comments. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
On 09/22/2014 12:06 AM, Yury Tarasievich wrote: Wait, does this change the window size when move's in progress, too? Then it's not snapping at all, and the term used is very confusing. More precisely, it's something like half-maximise when edge is hit or half-fill when edge-snapped. Snap is only the intermediate result here, triggering the final result. The size of the window isn't changed until after the move is completed. While moving the window, only a transparent frame is shown showing the future position/geometry of the window if the user chooses to complete the snap. The term is borrowed from (gulp) Windows [1]. [1] http://windows.microsoft.com/en-us/windows7/products/features/snap
Re: Bug: weird dropdown list behavior with Firefox / Iceweasel
On 09/12/2014 02:14 AM, Jubatian wrote: Hi! I found a not too critical, but certainly annoying bug apparently residing in WindowMaker after several days of experimenting revealed. It is described in the attached BUGFORM, as provided in the WindowMaker source distribution. I wasn't able to reproduce the bug using the webpage in your tarball. However, I think I may have seen the bug before on other webpages. All of a sudden, dropdown menus in Firefox stop working. I've found that miniaturizing and then deminiaturizing the window fixes the problem. I'm not sure if this is even a Window Maker bug, as dropdown menus don't seem like something a window manager would handle. By the way I found the web address provided in the bugform, and an other found somewhere in the FAQ apparently dead, so hope this gets through. I really like this window manager, too bad it is so hard to send any feedback for it. I just submitted a patch to update the BUGFORM. The FAQ is really out of date. I submitted a proposal a few months ago to update it, and the work is ongoing. Doug -- Douglas A. Torrance, Ph.D. Visiting Assistant Professor Department of Mathematics and Computer Science Monmouth College
Re: Patches for wmmon
On 08/11/2014 06:02 AM, Rodolfo García Peñas (kix) wrote: 1. Change the CC compiler to gcc (wmmon-1.1%2B20120402.patch [2]) 2. Usage the llong, perhaps gcc specific [2] 3. Include a new file in the library wmgeneral. I think wmgeneral is a common library. Perhaps we should create a new library libwmgeneral in the dockapps repo and link/include the dockapps to them (see wmSMPmon, wmbiff, wmckgmail,wmitime, wmmon,...). I've had the same thought. It would make fixing bugs in wmgeneral much easier. For example, if you run a dockapp that uses wmgeneral with the -display option but don't specify which display, you get a segfault. There would be some work up front of linking each dockapp with the new library, but then we could just fix bugs in libwmgeneral. It looks like there's 11 dockapps in the repo now which use it: dtorrance@zella:~/src/dockapps/dockapps$ ls -d1 */wmgeneral wmbiff/wmgeneral wmckgmail/wmgeneral wmitime/wmgeneral wmkeys/wmgeneral wmmon/wmgeneral wmppp.app/wmgeneral wmsm.app/wmgeneral wmSMPmon/wmgeneral wmtime/wmgeneral wmtz/wmgeneral wmweather+/wmgeneral Doug -- Douglas A. Torrance, Ph.D. Visiting Assistant Professor Department of Mathematics and Computer Science Monmouth College
Re: [PATCH 0/3] Website update, including dockapps section
On 08/10/2014 03:02 PM, Carlos R. Mafra wrote: But apparently patch 3 didn't make it to the mailing list, can you send it directly to me (and try again to the mailing list)? I think it went through -- it's showing up on the website at least [1]. I also just sent it directly to you. Doug [1] http://lists.windowmaker.org/dev/msg06931.html -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Dockapps proposal
Hi everyone, A little over a year ago, there was some discussion about what to do in regards to the dockapps repo and hosting tarballs [1]. Most users either install their distribution's package or build the source directly from git, but package maintainers for the various distros need nice official tarballs to download. Some good ideas were thrown around, but nothing really happened. As I am the Debian maintainer for several of these dockapps, this is an issue that interests me. In the past, I've just created little Sourceforge projects for each one, but I don't really feel like that's a good solution. These things should stay centralized and under the control of the Window Maker team. I have a proposal. First, we tag every version of each dockapp in the repo. This was recently done for wmix-3.2. I've spent some time over the past few days doing all the legwork and figuring out which version goes with each commit. I've attached a script which will tag everything. (Note that the majority of packages have one corresponding tag -- the first commit in the repo.) Next, we add a dockapps section to windowmaker.org that serves as a frontend to the git repo. It would serve essentially the same purpose as dockapps.windowmaker.org did, but instead of hosting actual tarballs, it would link to snapshots from repo.or.cz for the corresponding tags. Note that I'm willing to do all of the work here. :) I've already coded the basic structure and copied descriptions, images, etc. from archive.org's copy of dockapps.windowmaker.org. You can see my work so far at [2]. It remains to write a script to get the correct sha1 for each tag and create the download links. What does everyone think? Thanks! Doug [1] http://lists.windowmaker.org/dev/thrd49.html#04770 [2] http://friedcheese.org/dockapps #!/bin/sh git tag AlsaMixer.app-0.1 f331064eae676b1352d91cc7db1ad87acea63975 git tag Temperature.app-1.5 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmMatrix-0.2 902e9790e62121a8053967c4571e5399b4526103 git tag wmSMPmon-3.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmacpi-1.34 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmacpiload-0.1.2 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmauda-0.8 cdd7c69452bbe065291ab2873c8bda4cc24fd6a0 git tag wmbatteries-0.1.3 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmbiff-0.4.27 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmbutton-0.6.1 6dcdbf0e6e33b5ba357605ff30d69fdde7c48bd7 git tag wmbutton-0.7.0 6f2ffca0e2251adf1366c7194ba99cf905965b2f git tag wmCalClock-1.25 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmcalendar-0.5.2 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmckgmail-1.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmcpuload-1.0.0 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmfemon-1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmfu-1.0 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmifinfo-0.06 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmifinfo-0.07 f93842608424e642687a97c836fea7c35df570d7 git tag wmifinfo-0.08 c2861235bcfa5d90f9df4d84f76325de4b42ad85 git tag wmifinfo-0.09 8d7e817de2a6e1c5a392e00159f1cdc48062adb7 git tag wmitime-0.3 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmix-3.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmkeys-0.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmmixer-1.5 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmmixer-1.6 02b63cb41c541d4e6722b579afc87027b226507b git tag wmmixer-1.7 e3ceda0456ddbbb5187d13541740e7eac6b3cc22 git tag wmmixer-alsa-0.6 665b8f777a20b46ca68c7d5880435ddb88614937 git tag wmmon-1.0b2 b603570f4a929feaf713ecc3bd03b8bab4e6cec8 git tag wmmon-1.2b1 e2363d30fce15e8d4b0bf19a7685c7e517e4e938 git tag wmmoonclock-1.27 c3ca024d89dbf7f8910f1f0e8fbc46a4a6434812 git tag wmmoonclock-1.28 38d60e97a11c94a756fb1a5cc7a3c7304776e29c git tag wmnet-1.06 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmnotify-1.0.0 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmpager-1.2 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmpower-0.4.3 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmppp.app-1.3.0 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmsm.app-0.2.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmsmixer-0.5.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmstickynotes-0.1 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmsupermon-1.2.2 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmtime-1.0b2 168a691c807e0096a843e418b21331f8a9bda771 git tag wmtime-1.1 2ca71dc4499a3d893b7da556de15b8a4006a0d88 git tag wmtv-0.6.5 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmtz-0.7 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmweather+-2.12 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmWeather-1.31 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmwifi-0.6 21625f40b5f71ecd4b9832836f1a89ef3bb20b74 git tag wmwlmon-1.0 21625f40b5f71ecd4b9832836f1a89ef3bb20b74
Re: Dockapps proposal
On 08/08/2014 11:15 AM, Carlos R. Mafra wrote: That's a really good idea. I've already pushed the tags from your script to the repository. Thanks, Carlos! -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: increase logo size
On 06/04/2014 10:47 PM, David Maciejak wrote: Increase the size to default 64x64, please test. --- WindowMaker/Icons/GNUstep.tiff | Bin 906 - 3014 bytes WindowMaker/Icons/GNUstep.xpm | 326 ++--- 2 files changed, 271 insertions(+), 55 deletions(-) Personally, I use GNUstep.tiff for my dock icon. It's too large at 64x64. Would it be possible to provide these icons in addition to, instead of in place of, the original files? Doug
Re: [PATCH] WPrefs: updates to FrameBorderColor/FrameSelectedBorderColor options
On 05/19/2014 08:03 AM, Carlos R. Mafra wrote: On Mon, 19 May 2014 at 14:07:45 +0200, Josip Deanovic wrote: On Monday 2014-05-19 13:58:07 Amadeusz Sławiński wrote: Click the button around the color. It should be in selected (white color) state for changes to work. I didn't know that such color chooser exists in WPrefs. I would have never imagined that the frame around the color box was a button. It's opening is not intuitive at all. Definitely. I think this should be a proper button. I just submitted a patch to fix this. It was an easy one-liner. :) Thanks Amadeusz!
Re: [PATCH] WPrefs: Add ability to edit FrameBorderColor/FrameSelectedBorderColor.
On 05/17/2014 02:07 AM, Doug Torrance wrote: As part of the process, some #defines were turned into enums. Also, the *_COL 1 *_COL is used when needed. This brings the code for colors in line with the code for textures, and allows us to use them as array indices to improve readability, e.g., colorOptions[MTITLE_COL] instead of colorOptions[3]. --- I think I accidentally deleted a line of the commit message somehow. It should read Also, the *_COL #defines (now an enum) were changed from bits to ints and 1 *_COL is used when needed, etc. Dpig -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: Add ability to edit FrameBorderColor/FrameSelectedBorderColor.
On 05/17/2014 08:52 AM, Amadeusz Sławiński wrote: On Sat, 17 May 2014 02:07:38 -0500 Doug Torrance dtorra...@monmouthcollege.edu wrote: ... +WMAddPopUpButtonItem(panel-colP, _(Frame Border Color)); +WMAddPopUpButtonItem(panel-colP, _(Selected Frame Border ... I would place them the other way around, selected one first and then unselected one, same order as focused/unfocused title. Also I wonder if Focused/Unfocused Window Frame Border Color wouldn't be better, unless it's this way due to lack of place, though Focused/Unfocused Frame Border Color (without 'Window') should fit fine. Selected and Focused are different things, though. Windows are selected when you click and drag a box around them, or choose Select from the titlebar menu. I suppose I may have confused matters by choosing the Focused window preview to display the selected frame border color, as the focused window usually has the regular frame border color. It just seemed the most natural choice, as often one would select the focused window. Doug
Re: [PATCH] WPrefs: Add ability to edit FrameBorderColor/FrameSelectedBorderColor.
On 05/17/2014 11:21 AM, Amadeusz Sławiński wrote: Ah, right... I don't use it that much, that's why I was confused. It may be even more confusing if one doesn't know, maybe Selected Windows Frame Border Color to hint that there may be multiple ones. Also the more I look 'Frame' and 'Border' seem redundant to me. Maybe adding separate color for focused windows would solve it better? While allowing for better theming (as focused windows titlebars tend to have other colors than unfocused ones.) Then it could be: Focused Windows Border Color Unfocused Windows Border Color Selected Windows Border Color (Would it be possible to make it show on both focused/unfocused then?) Good ideas! I'll see what I can do. Doug
Re: [PATCH] WPrefs: remove unfinished background tab from appearances panel code
On 05/16/2014 12:19 PM, Carlos R. Mafra wrote: Just a minor comment. Unless the patch is already in the master branch (which is not the case here) the commit sha1 is not a perennial reference. So I'd like to suggest that everybody referring to some commit to also write its description line. In this case it would be: see commit c2aca1a (WPrefs: Set workspace background). That not only makes the reference more robust, but also helps in creating the appropriate context in the patch description. In any case, don't need to resend this one. I'll edit it myself. Good to know. Thanks, Carlos! -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
State of the FAQ
Hi everyone, Currently, the FAQ distributed with the source is much less up-to-date than the FAQ on the webpage, which itself is also very out-of-date. I'm interested in working to remedy this, but I'd like to get some input so I have a better feel of what direction to take. There are lots of questions in the FAQ that likely wouldn't be frequently asked in 2014, e.g., How do I get Window Maker to use more than 16 colors on my SGI Indy Workstation? Should these kind of questions be removed entirely, or kept for historical purposes? My gut feeling is to get rid of them. If people want to read the old questions, there's git and archive.org. Also, it would be nice if the source and webpage FAQs were the same. One option that could work would be to use something like texinfo, where the main FAQ is written in some format that can be exported to plaintext for the source and html for the webpage. Maybe there's an even better solution? And of course, maybe there's some more questions/answers we could add to the FAQ. I'd appreciate any thoughts. Thanks! Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: Set workspace background
On 05/12/2014 12:37 PM, Carlos R. Mafra wrote: On Sun, 11 May 2014 at 23:05:43 -0500, Doug Torrance wrote: This patch enables users to set the workspace background (WorkspaceBack) in the Appearance Preferences section of WPrefs. It appears as a new item in the popup menu in the Texture tab, in the list of textures below, and a preview appears in the background of the preview panel on the left. --- WPrefs.app/Appearance.c | 73 + 1 file changed, 49 insertions(+), 24 deletions(-) Nice patch. But in case an image background is selected, how to specify whether it appears centered, tiled, etc? The nice thing about this patch is I didn't have to add a lot of stuff -- this was already available in WPrefs for dealing with the other textures. Click the Edit button, select Image Texture from the popup button, and there's a popup button in the lower right with the option for Tile, Scale, Center, or Maximize. I tried it now and the image was tiled, but I was expecting it to be centered... Tile is currently the default option for the popup button. Perhaps Center would be preferable? With wmsetbg this can be easily done, so I guess that if we have this option in WPrefs we should also be able to select this there. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] Basic WINGs theming
From: Christophe [mailto:christophe.cu...@free.fr] [snip] Thanks, Christophe! I really appreciate all the comments and ideas. I hope to submit a new version of the patch with lots of improvements in the next week or so. Doug
RE: [PATCH] Basic WINGs theming
-Original Message- From: Carlos R. Mafra [mailto:crma...@gmail.com] It's been only a day or two since the patch and I'm still thinking and hoping to read more convincing arguments. It would help if the patch included an entry in the NEWS file to teach people about it (including the color syntax). Otherwise I think only a handful of people will be aware of it (nevermind use it). I'll work on updating the patch to include a NEWS entry tonight. Ultimately, if this feature is accepted, I would like to make it configurable in WPrefs. Doug
RE: [PATCH] Basic WINGs theming
I'm not sure about whether this is a good idea. The default look is classic and I'd guess few people would ever want to change how wmaker looks like. For the classic look, a user just has to not touch the WMGLOBAL file. It's still the default. As the writer of the patch, I'm certainly one of the people who would like to change the look. :) The window manager itself is extremely customizable. I think it would be nice if the corresponding widgets were as well. (It's still nowhere near as powerful. There's no gradient or pixmap support, just solid colors.) Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: Default icons
-Original Message- From: Roman Dobosz [mailto:gry...@gmail.com] Sent: Monday, October 21, 2013 1:48 PM To: wmaker-...@lists.windowmaker.info Subject: Re: Default icons Please, do not remove ability to change the icon for particular program! Thanks to this feature users have possibility to set their icon of choice without using external programs like xseticon[1]. Just to avoid any confusion, I am not suggesting changing any of the current icon-related behavior. I am only suggesting changing/removing the default icons defined in WMWindowAttributes. Many of these icons are for legacy applications no longer in use in a modern system. Also, many of these icons aren't even included with Window Maker in the first place. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Default icons
I noticed a few things while looking at the default WMWindowAttributes. * Many of the icons don't ship with Window Maker (e.g., ColorGNU.xpm for Emacs), but instead are in the WindowMaker-extra tarball. (Similarly, the Debian default WMWindowAttributes, which has mostly different icons, references icons in the wmaker-data package, which is only suggested but not required by the main wmaker package.) * Many of the icons are for rarely used software in a modern system (e.g., Netscape). * The current version of Window Maker does a mostly great job of getting icons from applications, and so declaring icons in WMWindowAttributes seems unnecessary outside of things like the dock, clip, and drawers (unless the user wants an icon theme). At this point, leaving things the way they are seems to only be of interest for historic purposes. I'd like to make some changes, but I wanted to see how people felt about the issue before I started submitted patches. Thanks! Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH] Add Other maximization options to window menu.
On 10/15/2013 12:33 PM, Christophe wrote: Hi, May I suggest to take the opportunity to transform these #define into an enum? that would make the code easier to work with. I'll take a look at it. [...] +entry = wMenuAddCallback(menu, _(Other maximization options), NULL, NULL); +wMenuEntrySetCascade(menu, entry, makeMaximizeMenu(scr)); + On personal taste, I would suggest a shorter line Other maximization so it does not stand out too much in the menu compared to the other entries. That sounds good. I thought it was a little long myself, but couldn't think of anything shorter. Apart from these, I think it's a great idea to bring more visibility to these capabilities! Thanks! Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch for wmtime in dockapps repo, new Debian maintainer
On 09/22/2013 03:47 PM, Rodolfo García Peñas wrote:
Some time ago we agree to remove the debian directory in the dockapps.
The debian folder in wmaker is used to create the Debian package and
create the nightly build package. Cheers, kix
I've attached a patch to remove the debian directory from wmtime.
Thanks,
Doug
From daf841d56e621112c34eac0b905b6e2b35da8a39 Mon Sep 17 00:00:00 2001
From: Doug Torrance dtorra...@monmouthcollege.edu
Date: Sun, 22 Sep 2013 17:01:08 -0500
Subject: [PATCH] wmtime - Removed debian directory.
As per the policy of the dockapp git repository, the debian directory of wmtime has been removed.
---
wmtime/debian/changelog | 73 --
wmtime/debian/compat| 1 -
wmtime/debian/control | 21 ---
wmtime/debian/copyright | 29 ---
wmtime/debian/dirs | 1 -
wmtime/debian/examples | 1 -
wmtime/debian/manpages | 1 -
wmtime/debian/menu | 6
wmtime/debian/rules | 93 -
wmtime/debian/wmtimerc | 3 --
10 files changed, 229 deletions(-)
delete mode 100644 wmtime/debian/changelog
delete mode 100644 wmtime/debian/compat
delete mode 100644 wmtime/debian/control
delete mode 100644 wmtime/debian/copyright
delete mode 100644 wmtime/debian/dirs
delete mode 100644 wmtime/debian/examples
delete mode 100644 wmtime/debian/manpages
delete mode 100644 wmtime/debian/menu
delete mode 100755 wmtime/debian/rules
delete mode 100644 wmtime/debian/wmtimerc
diff --git a/wmtime/debian/changelog b/wmtime/debian/changelog
deleted file mode 100644
index f9682a9..000
--- a/wmtime/debian/changelog
+++ /dev/null
@@ -1,73 +0,0 @@
-wmtime (1.0b2-10) unstable; urgency=low
-
- * New maintainer. (Closes: #487135)
- * Checked the debian files against the latest standard. (Closes: Bug#379574)
- * Moved menu item to Applications/System/Monitoring.
- * Minor code corrections to avoid build warnings.
-
- -- Paul Harris harris...@gmail.com Tue, 15 Jul 2008 15:24:09 +0800
-
-wmtime (1.0b2-9) unstable; urgency=medium
-
- * Fixed build dependencies so we no longer depend on libxpm4-dev.
- * Quoted all strings in /usr/lib/menu/wmtime.
-
- -- Simon Law sfl...@debian.org Tue, 10 Aug 2004 21:15:53 -0400
-
-wmtime (1.0b2-8) unstable; urgency=low
-
- * Fixed more problems in wmtime.1
- * Add a Debian menu entry for WMTime.
-
- -- Simon Law sfl...@debian.org Wed, 26 Nov 2003 23:16:11 -0500
-
-wmtime (1.0b2-7) unstable; urgency=low
-
- * Corrected some usage information.
- * Fixed some problems in wmtime.1
-
- -- Simon Law sfl...@debian.org Thu, 13 Nov 2003 01:29:24 -0500
-
-wmtime (1.0b2-6) unstable; urgency=low
-
- * New maintainer.
- * Added a manual page for wmtime. It was inspired by Adriaan Peeters'
-work. (Closes: Bug#181684)
- * Added the -geometry option. (Closes: Bug#182278, Bug#212426)
- * Added the -noseconds option. (Closes: Bug#25438)
- * Fixed some buffer overflow problems.
-
- -- Simon Law sfl...@debian.org Thu, 09 Oct 2003 17:52:34 -0400
-
-wmtime (1.0b2-5) unstable; urgency=low
-
- * Forgot to update menu entry with new path (closes: #142461)
-
- -- Fredrik Hallenberg hal...@debian.org Fri, 12 Apr 2002 17:58:04 +0200
-
-wmtime (1.0b2-4) unstable; urgency=low
-
- * Install in /usr/bin instead of /usr/X11R6/bin (closes: #122023)
- * Recompile fixes dependencies (closes: #132386)
-
- -- Fredrik Hallenberg hal...@debian.org Thu, 11 Apr 2002 18:20:07 +0200
-
-wmtime (1.0b2-3) frozen unstable; urgency=low
-
- * Fixed monthname (NOV instead of NOW).
- * Added menu entry. (closes: #51996)
- * Bumped standards revision to 3.1.1.
-
- -- Fredrik Hallenberg hal...@debian.org Sun, 6 Feb 2000 21:01:55 +0100
-
-wmtime (1.0b2-2) unstable; urgency=low
-
- * WMTime didn't work properly with -digital flag. (closes: #31869)
-
- -- Fredrik Hallenberg hal...@debian.org Mon, 5 Jul 1999 09:32:59 +0200
-
-wmtime (1.0b2-1) unstable; urgency=low
-
- * Initial Release.
-
- -- Fredrik Hallenberg hal...@debian.org Wed, 15 Jul 1998 18:18:07 +0200
diff --git a/wmtime/debian/compat b/wmtime/debian/compat
deleted file mode 100644
index b8626c4..000
--- a/wmtime/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-4
diff --git a/wmtime/debian/control b/wmtime/debian/control
deleted file mode 100644
index 16498db..000
--- a/wmtime/debian/control
+++ /dev/null
@@ -1,21 +0,0 @@
-Source: wmtime
-Section: x11
-Priority: optional
-Maintainer: Paul Harris harris...@gmail.com
-Build-Depends: debhelper (= 7), libx11-dev, libxpm-dev, libxext-dev
-Standards-Version: 3.8.0
-
-Package: wmtime
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: Window Maker dockapp that displays the time and date
- WMTime displays the time and date and gives you some nice additional
- features too. It is intended for docking in Window Maker.
- .
- It currently provides:
- .
- * the time and date;
- * a realtime morphing interface (analog digital mode);
- *
