On 16 January 2012 01:27, Kurt H Maier wrote:
> On Sun, Jan 15, 2012 at 01:27:28PM +1100, Alex Hutton wrote:
>> It seems to me it might overly complicate things to build the issue
>> tracker into a mail system or into git.
>>
>> The core functionality of tracking issues can be implemented in a
>>
On 16/01/12 01:20 ;+0100, Eckehard Berns wrote:
The confnotify-tip.patch from my previous mail[1] should fix this
hopefully.
Yes, that seems to fix the floating issues - I can't comment on the
original SDL issues however as I have not experienced them.
--
Anthony Cox
> This seems to have broken my floating windows - if I have a floating
> XTerm and open a new XTerm (tiled), the floating XTerm ends up
> behind the tiled one and I can no longer raise the floating one
> above.
>
> Another thing which seems to have been lost is the "feature" of
> clicking a floati
On Sun, 15 Jan 2012 09:32:07 -0500, Kurt H Maier wrote:
your unwarranted sense of self-importance is astounding. you
wouldn't
happen to be an arch linux user, would you?
Do you now detest users more than gentoo users by now?
On 12/01/12 07:39 ;+0100, Anselm R Garbe wrote:
I applied your two patches to tip, this needs to be tested for side effects now.
This seems to have broken my floating windows - if I have a floating
XTerm and open a new XTerm (tiled), the floating XTerm ends up behind
the tiled one and I can n
On Sun, Jan 15, 2012 at 06:18:03PM +, Bjartur Thorlacius wrote:
> Should we not patch wmname?
>
As wmname is a hack for broken apps, they will probably break if you
try to fix it.
If you only need to set _NET_WM_NAME, you can also try
xprop -root -f _NET_WM_NAME 8s -set _NET_WM_NAME "LG3D"
hello list
I'm crafting a patch here since I use a lot of tag rules but I'm too lazy to
always switch tags. Maybe it's just another silly idea to automatically switch
tags when rules apply. Currently it works, but I plan on extending this feature
so that the new behavior can be switched on and off
Þann sun 15.jan 2012 18:09, skrifaði Andreas Amann:
The problem is that Ivan uses wmname to set _NET_WM_NAME to "LG3D".
Actually chromium does not care about _NET_WM_NAME. But "wmname" has a
dirty side effect, it sets the _NET_SUPPORTING_WM_CHECK property of the root
window to the window id of
On Sun, Jan 15, 2012 at 07:29:13AM +0100, Anselm R Garbe wrote:
> On 15 January 2012 07:27, Anselm R Garbe wrote:
> > On 15 January 2012 00:26, Ivan Kanakarakis wrote:
> >> On 15 January 2012 00:52, Andreas Amann wrote:
> >>> just to ask, do you happen to have the command "wmname LG3D" in your
>
On Sat, Jan 14, 2012 at 12:41:51PM +0100, Eckehard Berns wrote:
> If no problems show up I think this is a better way of dealing with the
> SDL problem.
>
> --
> Eckehard Berns
>
> diff -r 070112b7435f dwm.c
> --- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
> +++ b/dwm.c Sat Jan 14 12:34:59 2012
On Sun, 15 Jan 2012 14:07:09 +
Stephen Paul Weber wrote:
>
> While I agree that adding custom headers is likely to be a pain and
> make users come up with hacks, some headers are very well
> standardized. Most notably In-Reply-To and Message-ID. IMHO, and
> "id" for the bug should be the Me
On 15 January 2012 08:29, Anselm R Garbe wrote:
> On 15 January 2012 07:27, Anselm R Garbe wrote:
> > On 15 January 2012 00:26, Ivan Kanakarakis wrote:
> >> On 15 January 2012 00:52, Andreas Amann
> wrote:
> >>> just to ask, do you happen to have the command "wmname LG3D" in your
> >>> startup
On Sun, 15 Jan 2012 13:08:55 -, Connor Lane Smith
wrote:
Your work is so mission critical that mistaking window focus being
"very unlikely" is not enough? Well then, the only way to avoid such a
mistake is to maximise every window (i.e., monocle mode);
or more generally always placing the f
On Sun, Jan 15, 2012 at 01:29:59PM +0100, Bastien Dejean wrote:
>
> No: this is more likely a general design problem as stated in my
> original message. I don't want to choose my active border color based on
> some design flaw and "very unlikely" is not enough.
your unwarranted sense of self-impo
On Sun, Jan 15, 2012 at 01:15:10PM +0800, Kai Hendry wrote:
> I'm gone down the TODO list http://webconverger.org/todo/ and it's not
> "social" enough I dare say. You need commenting and +1 and all that
> crap nowadays, to keep interested.
if you need stupid games to keep people interested then th
On Sun, Jan 15, 2012 at 01:27:28PM +1100, Alex Hutton wrote:
> It seems to me it might overly complicate things to build the issue
> tracker into a mail system or into git.
>
> The core functionality of tracking issues can be implemented in a
> meta-language.
are you even listening to yourself?
On Sat, Jan 14, 2012 at 12:26:45PM +0100, Paul Onyschuk wrote:
> Maildir is a bit overkill in my opinion, just look at naming convention
> [1]. If you want to use "file per message" format, MH provides simpler
> solution (name of file is just a ID number e.g. 1, 2, 15 and so on).
really? that's
On Thu, Jan 12, 2012 at 07:39:53AM +0100, Anselm R Garbe wrote:
> I believe these two lines relate from an earlier algorithm that was
> used prior to the barwin restacking.
>
> I applied your two patches to tip, this needs to be tested for side effects
> now.
>
Well, currently wireshark is the
Somebody claiming to be Anselm R Garbe wrote:
On 12 January 2012 19:06, Anselm R Garbe wrote:
The reason I suggest to base the bug tracker "view" on a mail
archiving tool is simply because this problem hasn't been solved in an
acceptable way either (and we'd need a better system anyways).
Yes,
On Sun, Jan 15, 2012 at 11:55:34AM +0100, Bastien Dejean wrote:
> Solution: add a separation border between the window boundary and the
> focus border. The contrast between the separation border and the focus
> border should be high and constant.
Another pretty easily implemented approach would be
On Sun, 15 Jan 2012 13:27:28 +1100
Alex Hutton wrote:
>
> It seems to me it might overly complicate things to build the issue
> tracker into a mail system or into git.
>
> The core functionality of tracking issues can be implemented in a
> meta-language.
>
Static web generators (werc/ikiwiki et
On 15 January 2012 10:55, Bastien Dejean wrote:
> Solution: add a separation border between the window boundary and the
> focus border. The contrast between the separation border and the focus
> border should be high and constant.
This is only solvable in the general case by making dwm reparent,
> Afterwards all bug-related communication targets this email address. A
> suckless developer with the permission to amend the bug status could
> now send special commands to this address:
This is bullshit. An email address is no command line interface.
On 1/15/12, Bastien Dejean wrote:
> Florian Limberger:
>
>> This is more likely a problem of your colorscheme, for example my
>> active border is #ff9900, which is very unlikely to be the background
>> color of any window.
>
> No: this is more likely a general design problem as stated in my
> orig
Bastien Dejean writes:
> Bjartur Thorlacius:
>
>> Just draw the second border on the root window.
>
> Will it work with floating windows?
No.
--
\ Troels
/\ Henriksen
Florian Limberger:
> This is more likely a problem of your colorscheme, for example my
> active border is #ff9900, which is very unlikely to be the background
> color of any window.
No: this is more likely a general design problem as stated in my
original message. I don't want to choose my activ
Bjartur Thorlacius:
> Just draw the second border on the root window.
Will it work with floating windows?
--
b.d
(| |)
^ ^
Greetings.
Kai Hendry wrote:
> On 14 January 2012 00:28, Paul Onyschuk wrote:
>> Right now best interfaces for issue trackers are search engines (e.g.
>> Google "site:adress_of_bug_tracker interesting issue") and mail
>> archives (Gmane and so on) in my opinion.
>
> I don't think they are the "b
On Sun, 15 Jan 2012 12:02:01 -, Troels Henriksen
wrote:
"Bjartur Thorlacius" writes:
This could be implemented as a gap between windows in tile(). Just
offset windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is
probably more readable than the previous sentence.
You'd also ne
"Bjartur Thorlacius" writes:
> This could be implemented as a gap between windows in tile(). Just
> offset windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is
> probably more readable than the previous sentence.
You'd also need to construct a border pixmap rather than the current
sing
This could be implemented as a gap between windows in tile(). Just offset
windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is probably
more readable than the previous sentence.
--
-,Bjartur
Hello Bastien,
On Sun, 15 Jan 2012 11:55:34 +0100, Bastien Dejean wrote:
It might happen that the background color of the active window is
very
close to the color of the active border. In so, the active border
become
nearly invisible and useless.
This is more likely a problem of your colors
Hi,
There's a problem with the current single border logic of all the
minimal tiling X wm I'm aware of:
It might happen that the background color of the active window is very
close to the color of the active border. In so, the active border become
nearly invisible and useless.
Solution: add a se
33 matches
Mail list logo
