1/2)" in the window menu, and I'd
like to also use the keys F1/2/3 and 1/2/3 to move the window to
the corresponding page. At the moment this is not possible.
In other words: A typeahead search wouldn't solve this problem.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
eaner or more natural way to define hotkeys, possibly
recuycling the syntax of the "Key" command?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
h code line, relevant
variables etc.)?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Apr 15, 2013 at 09:12:26PM +0100, Thomas Adam wrote:
> On Mon, Apr 15, 2013 at 09:12:48PM +0100, Dominik Vogt wrote:
> > On Mon, Apr 15, 2013 at 07:44:10PM +0100, Thomas Adam wrote:
> > > On 14 April 2013 09:57, Dominik Vogt wrote:
> > > > On Sun, Apr 1
On Mon, Apr 15, 2013 at 07:44:10PM +0100, Thomas Adam wrote:
> On 14 April 2013 09:57, Dominik Vogt wrote:
> > On Sun, Apr 14, 2013 at 03:41:48AM -0500, c...@math.uh.edu wrote:
> >> CVSROOT: /home/cvs/fvwm
> >> Module name: fvwm
> >> Changes by: domivog
variable warnings in modules (write only).
Same story as the warning fixes in the fvwm core, but for the
modules this time.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
should have). So please keep
your eyes open for strange things happening with the button
background in FvwmIconMan.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
ize.xml
> fvwm : move_resize.c
>
> Log message:
> * New option "forget" to the maximize command.
That's a local change I've had lying on my disk for years.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
is commit. I've fixed many of the warnings like this:
int n_unused;
...
n = sprintf(...);
(void)n;
I'm not sure that every compiler supports "(void)n;", so some
feedback from non-gcc compilers would be useful.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
nothing was really broken in the NEWS file, but my xemacs NEWS
hilighting mode broke with the indentation.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
ght even make Dominik happy.
;-)
I love asciidoc. It's a tool for hard core programmers that are
forced to write documentation.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Apr 17, 2011 at 06:24:37PM +0100, Thomas Adam wrote:
> On Sun, Apr 17, 2011 at 07:09:15PM +0200, Dominik Vogt wrote:
> > * The topic branches should usually belong to only one developer.
> > The owner of a topic branch is responsible for keeping it in
> > sync with
On Sun, Apr 17, 2011 at 07:09:15PM +0200, Dominik Vogt wrote:
> 1. Make sure that the release branch is an ancestor of the
>devel branch.
> 2. Check out the devel branch and set a temporary tag.
> $ git checkout devel
> $ git tag foo
> 3. Che
On Sun, Apr 17, 2011 at 05:45:51PM +0100, Thomas Adam wrote:
> On Sun, Apr 17, 2011 at 06:40:37PM +0200, Dominik Vogt wrote:
> You and I have both got patches in tig, ISTR. :)
Yes, I remember that. :-)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
e you can publish your work, you have
to update your working tree ("cvs up") and fix the merge
conflicts. Only a working tree that is up to date can be
published. The same can be done with git, although it's not
enforced, by using git-cherry-pick or git-am rather than
git-merge.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
og is
obsolete. A well maintained git history contains all the
information of the ChangeLog. Tools like tig make it very easy to
look for any information in the commit tree.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
the git repository is created on
the same machine as the cvs repository.
--> A subdirectory .git with the git repository is created
(including a working tree). From that point you can switch to git
commands to create a bare repository.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sat, Apr 16, 2011 at 02:03:18PM -0500, Jason L Tibbitts III wrote:
> Did I mention how much I dislike CVS? We really need to have a
> discussion about moving to git.
I'm all for git. CVS feels so *old* when you have gotten used to
git.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
MapRequest event. This can
also happen when a window is recaptured, so
exc->x.etrigger->xmaprequest.window would point to random data.
Overall this problem requires more thinking in depth. I'd go for
approach (2) if we can prevent that old problem with an orphan
frame window left over from repeated MapRequest and UnmapNotify
events and just wait if an endless loop of mapping/unmapping ever
happens again.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
e work. Thanks for the bug report though.
Also, it's not so simple to change. Windows can have any geometry
while being maximized. It does not suffice to simply call
"maximize" when leaving fullscreen state, and that geometry would
have to be restored.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sat, Oct 09, 2010 at 01:40:29PM +0100, Thomas Adam wrote:
> On Sat, Oct 09, 2010 at 02:28:11PM +0200, Dominik Vogt wrote:
> > The attached patch mostly fixes the problem. However, there is one
> > thing left to think about:
>
> Ah -- you're too fast for me. :) I&#
ar some more opinions.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Index: events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.567
diff -u -u -r1.567 events.c
--- events.c 4 Jan 2010 12:00:38 - 1.567
+
On Sat, Oct 09, 2010 at 05:58:59AM +0100, Thomas Adam wrote:
> On Sat, Oct 09, 2010 at 01:15:16AM +0200, Dominik Vogt wrote:
> > 1. I have 3x2 pages.
> > 2. A seamonky download window is on page (0, 1). (One of the
> >individual download windows, not the big list of
It
looks like the resize code thinks the left border of the real
window is the left border of the window shade.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
bout the geometry of the
given Xinerama screen.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
e process and issue a new
> unstable 2.5.29 release.
>
> What do others think?
What about the problems with the Geometry window during mone and
resize operations that a user reported. That needs to be
investigated.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Feb 22, 2010 at 02:24:16PM +, Thomas Adam wrote:
> On 22 February 2010 14:09, Dominik Vogt wrote:
> >
> > This did not happen before the code change (which does not mean
> > the new behaviour is necessarily a bad thing - it is just
> > different in some si
Window is moved to the layer from the style
This did not happen before the code change (which does not mean
the new behaviour is necessarily a bad thing - it is just
different in some situations, and possibly in a surprising way).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
new features, and I think adding tests is a good thing.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
resizing a window with aspect ratio, such as
> Mplayer.
Which version of gcc is that? I had some trouble with gcc
optimization recently in another project. There's probably an
option to disable the offending optimization.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote:
> On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt wrote:
> > On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote:
> > [snip]
> >> > 1. Key polling
> >> >
> >> > I'm not c
On Mon, Mar 16, 2009 at 03:55:59PM +, Mikhael Goikhman wrote:
> On 16 Mar 2009 00:52:27 +0100, Dominik Vogt wrote:
> > > > I don't know, I couldn't make it run anyway. Too many dependencies ;-)
> > > > It looks like it's impossible to install fvwm
}
>
> if (*px + self.width >=
> - Scr.MyDisplayWidth - fw->snap_proximity &&
> - *px + self.width < Scr.MyDisplayWidth)
> + screen_width - fw->snap_proximity &&
> + *px + self.width < screen_width)
> {
> - nxl = Scr.MyDisplayWidth - self.width;
> + nxl = screen_width - self.width;
> }
> }
> dist = abs(*px);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
that's preference.
> FvwmProxy does honor WindowListSkip, meaning it presumes that you
> don't want proxies where you don't want something on a window list.
> I'm single page, multi desk (as I understand the terms), so I don't
> have a good grip on issues with scrolling desktops but if regular
> windows work, proxies should be fine.
A desktop is a big area made of one or more pages e.g. 3x2. A
page is always the size of the screen. The currently visible area
of the screen is called the viewport and usually shows a complete
page, but may be scrolled smoothly.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Mar 15, 2009 at 07:00:05PM +, Mikhael Goikhman wrote:
> On 15 Mar 2009 00:34:16 +0100, Dominik Vogt wrote:
[snip]
> > > To be interactive the module should both listen to fvwm and to the input
> > > (mouse, keyboard) in the same event loop. Don't you agree?
&
I've moved this discussion to a separate thread.
> jpwe...@imonk.com wrote:
> On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote:
> > On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote:
> > > On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik
On Sun, Mar 15, 2009 at 12:34:16AM +0100, Dominik Vogt wrote:
> > FvwmGtkDebug is really not simple to reimplement without gtk.
>
> I don't know, I make it run anyway.
^^^
couldn't
> Too many dependencies ;-)
> It looks like it&
On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote:
> On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote:
> > On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote:
> >
> > * FvwmProxy: unfinished and unmaintained
>
> Please
On Sat, Mar 14, 2009 at 08:23:57PM +, Mikhael Goikhman wrote:
> This is a long post, since I tried to reply to all comments. This is
> pretty important to me.
>
> On 14 Mar 2009 11:22:22 +0100, Dominik Vogt wrote:
[snip]
> > As far as I remeber:
> >
> > * de
On Sat, Mar 14, 2009 at 11:13:21AM +, Thomas Adam wrote:
> 2009/3/14 Dominik Vogt :
> But this is almost "thrust" upon existing developers. Dominik, you
> obviously fall into this category: could you fix something in perllib
> or FvwmTabs if it broke?
No, I co
On Sat, Mar 14, 2009 at 11:13:21AM +, Thomas Adam wrote:
> 2009/3/14 Dominik Vogt :
> > * html documentation
> >
> > Became a part of fvwm because people spent a lot of work on it.
> > It is *the* top 1 reason why I don't write features anymore:
>
On Sat, Mar 14, 2009 at 07:32:19AM +, Mikhael Goikhman wrote:
> On 14 Mar 2009 00:15:03 +0100, Dominik Vogt wrote:
[snip]
> > * deb generation: unmaintained
> > * rpm generation: unmaintained
> > * html documentation: unmaintained
> > * perllib: unmaintain
e options, not to decrease them.
I think we should do quite the opposite.
> As someone who is responsible for this subdirectory I will speak with
> Manoj directly, and we will come to the solution (just not today).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
id of this dependency?
>
> We should be removing that directory entirely from FVWM to be honest.
Fine with me.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
t; index c44dbbb..4c1efbf 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,10 @@
> +2009-03-01 David Fries
> + * fvwm/virtual.c (HandlePaging):
> + move no page detect check, it wasn't being hit
> + * fvwm/move_resize.c (__move_loop):
> + transfor
On Sat, Feb 28, 2009 at 12:28:11AM +, Thomas Adam wrote:
> Hello --
>
> 2009/2/27 Dominik Vogt :
> > On Tue, Feb 24, 2009 at 09:49:00PM +, Thomas Adam wrote:
[snip]
> I've spent about the last three hours looking through the Jitterbug
> (which is a disaster in us
even if that means cutting our ideas short as a result.
We really weren't this far away from 2.6 on our last attempt.
Well, I didn't look into most of the bug reports for years now.
It's hard to tell sor me how stable 2.5.27 really is. You time
would definitely not be waset if you to update the todo-2.6 file
as a first step.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Feb 23, 2009 at 09:21:03PM +, Thomas Adam wrote:
> 2009/2/23 Dominik Vogt :
> - I can't say I like the magic numbers in the malloc line:
:-P
I couldn't think of anything better, and I think the previous
allocation was too small.
> allmods = safemalloc(sizeof(ta
hat I remember
> that function doing last. ;)
To see the full diff, type
$ cd modules/FvwmButtons
$ cvs diff -r 1.39 -r 1.40 button.c
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
y analysis could
> be flawed, but it seems odd that "old" is not a volatile int, but
> nothing is seemingly assigned to it.
>
> Dominik?
Uuh, I accidentally removed this line when fixing the compiler
warning.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Feb 22, 2009 at 10:14:28PM +, Thomas Adam wrote:
> 2009/2/22 Dominik Vogt :
> > We should make the print_bindings patch stable first. When we're
> > confident the patch is good, I can make the release on the fly.
>
> Absolutely ---
> is there anything ou
On Sun, Feb 22, 2009 at 12:24:14AM +, Thomas Adam wrote:
> 2009/2/22 Thomas Adam :
> > 2009/2/21 Thomas Adam :
> >> Hi --
> >>
> >> 2009/2/21 Dominik Vogt :
> >>> I've applied the patch after some modifications so that it's not
On Sun, Feb 22, 2009 at 09:36:25PM +, Thomas Adam wrote:
> 2009/2/22 Dominik Vogt :
> >> Log message:
> >> Fix compilation without libstroke for print_bindings.
> >>
> >> Added ifdefs around the stroke code for printing out stroke bindings, as
> &g
OKE_CODE. I'll commit a fix.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Feb 22, 2009 at 12:24:14AM +, Thomas Adam wrote:
> 2009/2/22 Thomas Adam :
> > 2009/2/21 Thomas Adam :
> >> Hi --
> >>
> >> 2009/2/21 Dominik Vogt :
> >>> I've applied the patch after some modifications so that it's not
On Sat, Feb 21, 2009 at 10:25:43PM +, Thomas Adam wrote:
> Hi --
>
> 2009/2/21 Dominik Vogt :
> > I've applied the patch after some modifications so that it's not
> > necessary to copy window names etc. But the code in charmap.c
> > needs some proof re
I've applied the patch after some modifications so that it's not
necessary to copy window names etc. But the code in charmap.c
needs some proof reading. I'm really not sur the memory
management is correct.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
gs up. Changes in behaviour should be discussed in
advance anyway.
Any other opinions?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Feb 15, 2009 at 11:11:03PM +, Thomas Adam wrote:
> 2009/2/15 Dominik Vogt :
> > I don't understand how putting a "return" after the
> > "if (!FD_ISSET(...))" fixes your problem as the code that is
> > executed inside the if block should
(...))" fixes your problem as the code that is
executed inside the if block should always complete without
waiting.
--
I think you either running some bad module that crashes or hangs
at random times, or a module that tries to send a synchronous
command as a reaction to some fvwm message occuring about at the
same time as the messages. The log message should tell you which
module was killed.
To get a hold on the problem, I suggest you try to find out which
messages fvwm and the module exchange. (Do we have some module
message debugging code?).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
t; I would argue such a check is redundant, since the freeze happens as
> soon as I start to resize a window, which is stupid since nothing has
> gone wrong at the point. Indeed, a simple "return;" at the beginning
> of the blocks alleviates the issue -- is this check even relevant?
Do you have a reliable way to reproduce the problem? I've never
seen it myself.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Tue, Feb 10, 2009 at 09:24:54PM +0100, Jesús Guerrero wrote:
> Today I noticed an error in a date. At least that's what
> the context seems to suggest since it's a 2006 in between
> a lot of 2008's.
>
> Patch attached.
Applied.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sun, Feb 08, 2009 at 05:55:51PM +, Thomas Adam wrote:
> 2009/2/8 Dominik Vogt :
[sniiip]
> >> + int modmask = mask;
> >
> > Please don't declare variables in the middle of a block. This
> > does not compile with oplder compilers.
>
> I didn&
On Sat, Feb 07, 2009 at 08:27:54PM +, Thomas Adam wrote:
> 2009/2/7 Dominik Vogt :
> > On Fri, Feb 06, 2009 at 09:35:30AM +, Thomas Adam wrote:
> >> 2009/2/6 Dominik Vogt :
> >> > On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
> >>
standardised, but some distributions use the latter, whilst some
> use the former, and vice-versa, so just check for both and be done
> with it.
Applied.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
e->key));
> + memset (c, '\0', sizeof(c));
> +
> + strcpy(c, (char *)&table->key);
> + *c = toupper(*c);
> +
> + if (modmask & table->value)
> + {
> + modmask |= table->value;
> + strcat(allmods, c);
> + }
> + modmask &= ~table->value;
> + free(c);
> + }
> + return allmods;
> +}
> Index: libs/charmap.h
> ===
> RCS file: /home/cvs/fvwm/fvwm/libs/charmap.h,v
> retrieving revision 1.1
> diff -u -r1.1 charmap.h
> --- libs/charmap.h5 Jul 2003 01:37:47 - 1.1
> +++ libs/charmap.h8 Feb 2009 02:28:19 -
> @@ -27,4 +27,6 @@
> int *ret, const char *string, charmap_t *table, char *errstring);
> char charmap_mask_to_char(int mask, charmap_t *table);
>
> +char *charmap_table_to_string(int mask, charmap_t *table);
> +
> #endif /* CHARMAP_H */
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Fri, Feb 06, 2009 at 09:35:30AM +, Thomas Adam wrote:
> 2009/2/6 Dominik Vogt :
> > On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
> >> 2009/1/26 Thomas Adam :
> > I was planning to look into the patch on saturday evening (GMT) or
> > maybe earli
or
maybe earlier.
> Is it worth, whilst I am looking at the code, to deprecate
> StartsOnDesk, seeing as StartsOnPage has this functionality anyway,
Has it? Can you give an example?
> or
> is this still too a risque thing to do?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Jan 26, 2009 at 10:06:07AM +, Thomas Adam wrote:
> 2009/1/26 Dominik Vogt :
> > On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote:
> >> 2009/1/22 Thomas Adam :
> >> I've also deprecated StartsOnPage/Desk/Screen in favour of:
> >
> >
On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote:
> 2009/1/22 Thomas Adam :
> > 2009/1/22 Dominik Vogt :
> >> On Thu, Jan 22, 2009 at 09:01:44AM +, Thomas Adam wrote:
> >>> 2009/1/22 Dominik Vogt :
> >>> > Style Foo MapFooFunc
> >&
On Thu, Jan 22, 2009 at 09:01:44AM +, Thomas Adam wrote:
> 2009/1/22 Dominik Vogt :
> > Style Foo MapFooFunc
> > AddToFunc MapFooFunc
> > + I MoveToPage 1 1
> > + I Iconify true
> >
> > This way, it would even be possible to get these stupid Open
>
fvwm/fvwm/fvwm/style.h,v
> retrieving revision 1.89
> diff -u -r1.89 style.h
> --- fvwm/style.h 17 Nov 2007 11:47:57 - 1.89
> +++ fvwm/style.h 19 Jan 2009 06:26:15 -
> @@ -19,6 +19,8 @@
> ((sf)->do_start_lowered)
> #define SDO_START_SHADED(sf) \
> ((sf)->do_start_shaded)
> +#define SDO_START_MAXIMIZED(sf) \
> + ((sf)->do_start_maximized)
> #define SHAS_BORDER_WIDTH(sf) \
> ((sf)->has_border_width)
> #define SHAS_COLOR_BACK(sf) \
> @@ -657,6 +659,10 @@
> ((s).pl_position_string)
> #define SSET_PLACEMENT_POSITION_STRING(s,x) \
> ((s).pl_position_string = (x))
> +#define SGET_START_MAXIMIZED_STRING(s) \
> + ((s).start_maximized_string)
> +#define SSET_START_MAXIMIZED_STRING(s,x) \
> + ((s).start_maximized_string = (x))
>
> /* function prototypes */
> void lookup_style(FvwmWindow *fw, window_style *styles);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
* fvwm/ewmh_events.c (ewmh_WMStateMaxHoriz): Having either
> + _NET_WM_STATE_MAXIMIZED_HORIZ or _NET_WM_STATE_MAXIMIZED_HORZ
> + should be enough to make the window horizontally maximized.
> +
> 2008-11-29 Domi
> or
>
>perl -e '$SIG{PIPE}="IGNORE"; exec("xterm -e tcsh")'
>
> and then
>
> man gcc
>
> from the xterm. The first line gives a properly working shell, the
> second one a shell that is as broken as it would be if started by fvwm
> via 'Exec xterm'.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Thu, Nov 27, 2008 at 09:13:22AM +, Thomas Adam wrote:
> 2008/11/27 Mikhael Goikhman <[EMAIL PROTECTED]>:
> > On 26 Nov 2008 19:00:53 +0100, Dominik Vogt wrote:
> >>
> >> This isn't really helpful. Why not simply print the while command
> >> l
On Wed, Nov 26, 2008 at 06:28:07PM +, Thomas Adam wrote:
> 2008/11/26 Dominik Vogt <[EMAIL PROTECTED]>:
> > On Tue, Nov 25, 2008 at 11:58:47PM +, Thomas Adam wrote:
> >> I've (perhaps crudely) implemented an option to BugOpts called
> >> TraceCo
ther have
"TraceFunctions" that prints *everything*.
--
The patch had some whitespace issues that I cleaned up in the
attached new patch:
* long lines (> 80 characters)
* identation by spaces instead of tabs
* trailing whites
red when matching a
> + style line. Given $[w.visiblename] is mostly interesting when applying
> + style, make it match before the actual window name is.
Er, what? I don't understand the sentence.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
overlooked?
No, I'm just too busy to look into the patch. I'll do that sooner
or later.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sat, Oct 04, 2008 at 08:23:53PM +0100, Thomas Adam wrote:
> 2008/10/3 Thomas Adam <[EMAIL PROTECTED]>:
> > 2008/10/2 Thomas Adam <[EMAIL PROTECTED]>:
> >> 2008/10/2 Dominik Vogt <[EMAIL PROTECTED]>:
> >>> On Tue, Sep 30, 2008 at 07:01:56PM +010
break anything for me.
This particular problem could be solved by adding $[w.visible_name].
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Wed, Aug 20, 2008 at 11:12:06PM +0200, Harald Dunkel wrote:
> Dominik Vogt wrote:
> >On Mon, Aug 18, 2008 at 07:59:28PM +0200, Harald Dunkel wrote:
> >>I've got a problem with fvwm on Linux (current snapshot as well
> >>as fvwm-2.5.24):
> >>
> >>
; #7 0x00427464 in dispatch_event (e=0x7fffa516db90) at events.c:4042
> #8 0x00427bc5 in HandleEvents () at events.c:4086
> #9 0x00449b5d in main (argc=, argv= optimized out>) at fvwm.c:2563
>
>
> This was generated using the snapshot of today (20080818). Distro
> is Debian (amd64) on a Core2 Duo.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
aspect ratio.
>
> I consider this a bug, instead upon restart FVWM should honour placing
> MPlayer in fullscreen mode if it was already in this state before FVWM
> was restarted.
Should be fixed now. Can you try it again, please?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
ich is always 0.
Viktor, if you *always* compile with
make CFLAGS="-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror"
gcc will catch these errors for you because is insists on using
parentheses in this case.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
D_AUTO)
>
> is this a bug?
Yes, I'll fix that.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
this patch since you first posted it, and I'm still
unsure what it is good for. *If* we add more options to configure
separators it would be better to do it in a more general way.
Perhaps similar to the horizontal item layout or by introducing
some kind of separator style or whatever. But that is overkill in
my eyes.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
e of them.
Basically, adding flexibility to fvwm is good, but I'm reluctant
to apply such a large patch just because the developers of *one*
application are misunderstanding the ICCCM2.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
int i;
> ewmh_atom *list = ewmh_atom_wm_state;
> @@ -499,7 +499,7 @@ int ewmh_WMState(EWMH_CMD_ARGS)
> while(list->name != NULL)
> {
> has_hint = 0;
> - for(i = 0; i < (size / (sizeof(Atom))); i++)
> + for(i = 0; i < (size / (sizeof(*val))); i++)
> {
> if (list->atom == val[i])
> {
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
NULL
> };
> s = trimleft(s);
> @@ -1628,6 +1629,9 @@
> }
> break;
>
> + case 27 : /* top */
> + b->flags.b_Top = 1;
> + break;
> /* --- --- */
> default:
> t = seekright(&s);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
width = 352, max_height = 126
^^^^^^
The window has requested a minimum size of 353 pixels and a
maximum size of 352 pixels. As the message above says, this is
not fvwm's problem and can only be fixed in the application
itself.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Mon, Mar 17, 2008 at 01:27:22PM +0100, Jesús Guerrero wrote:
> On Fri, 14 Mar 2008 18:27:57 +0100
> Dominik Vogt <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Mar 14, 2008 at 06:15:36PM +0100, Dominik Vogt wrote:
> > > On Wed, Mar 12, 2008 at 01:31:14AM +0100, Jesús Gu
nks from fullscreen to 99%x97% of the
screen.
> I consider this a bug, instead upon restart FVWM should honour placing
> MPlayer in fullscreen mode if it was already in this state before FVWM
> was restarted.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Fri, Mar 14, 2008 at 06:15:36PM +0100, Dominik Vogt wrote:
> On Wed, Mar 12, 2008 at 01:31:14AM +0100, Jesús Guerrero wrote:
> > I attach an updated version of the patch, with test cases, docs, Changelog
> > and NEWS included. I hope everything is correct. If not, just let me
re multiple ChangeLog files. If you change
something, in directory fvwm/x/y, you should look for a ChangeLog
file in y first, then in x and finally in fvwm and use that. If
you press "ctrl-x 4 a" in emacs, it looks for the proper file and
adds an entry to it for you.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Tue, Mar 11, 2008 at 09:37:30PM +0100, Jesús Guerrero wrote:
> On Tue, 11 Mar 2008 21:11:23 +0100
> Dominik Vogt <[EMAIL PROTECTED]> wrote:
> By the way, above you said that you couldn't add functionality like this
> a couple of years ago. Can you comment a few words on t
On Tue, Mar 11, 2008 at 06:36:24PM +0100, Jesús Guerrero wrote:
> On Tue, 11 Mar 2008 16:03:37 +0100
> Dominik Vogt <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > See comments below.
>
> Thanks for the extensive comments. I think it's all sorted now.
> Most of t
yMenu [EMAIL PROTECTED]@
> AddToMenu [EMAIL PROTECTED]@ "Bar" DestroyMenu [EMAIL PROTECTED]@
> AddToMenu TestMenu@@some_image@@ "Baz" DestroyMenu [EMAIL PROTECTED]@
> Menu [EMAIL PROTECTED]@
> Menu [EMAIL PROTECTED]@
>
>
> In the above test cases some_image may be replaced with an existing image,
> but that is not required for the bug to be reproduced.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Tue, Mar 11, 2008 at 04:49:32PM +0100, Jesús Guerrero wrote:
> On Tue, 11 Mar 2008 16:10:42 +0100
> Dominik Vogt <[EMAIL PROTECTED]> wrote:
>
> > > MAX_VERTICAL_SPACING and MIN_VERTICAL_SPACING are not defined in
> > > the patch. Anyway, MIN_VERT
On Tue, Mar 11, 2008 at 04:03:37PM +0100, Dominik Vogt wrote:
[snip]
> > +static void parse_vertical_margins_line(
> > + char *args, signed char *top, signed char *bottom,
> > + signed char top_default, signed char bottom_default)
> > +{
> > +
301 - 400 of 650 matches
Mail list logo
