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
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
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
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
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
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,
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
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
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
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
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:
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/
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)
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
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
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:
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
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
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
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
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
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
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:
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
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
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,
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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]
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
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.
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(-)
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
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,
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
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'
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.
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
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,
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
-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
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
-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
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,
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);
+
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
57 matches
Mail list logo
