Re: [dev] [dwm] [PATCH] Focus root window on startup
On Sat, Aug 31, 2013 at 02:11:26PM +0300, FRIGN wrote: > Am 8/31/13 1:37 PM, schrieb Markus Teich: > >I don't think this is a valid argumentation, since you could also turn it > >around and say: > >As lxdm works with most other window managers, it is the dwm-developers' > >job. > > > >Therefore i think it should be documented somewhere, who's job it is to > >focus the root window. > > > >--Markus > > > > > > It's the same question Mauro raised and he got a famous answer from > Linus[1] (Don't force me to bring up his words here again). > > It's a simple matter: What are you aiming your development at? Linux > Kernel developers are very keen on not breaking the userspace. > It's a bottom-up-system: Not the userspace adapts to quirks, the > Kernel space makes sure it provides a consistent, standardized > interface to run applications which have been built to comply with > those standards. > [...] I partially agree. As I said before the first question to ask ourselves is: Is there some specification (or any API documentation or whatever) that says whether to root window needs to be focussed on startup (if there are no other clients)? If there is, it clearly is a bug in either LXDM or dwm and should be fixed in the right place. If there isn't, it is probably better to fix this in LXDM since it's a good idea to provide a consistent interface and not do the very same setup in every window manager. However, note that the LXDM developers might argue that focussing stuff is the window managers' job and none of their business. This is a bit different than the discussion you linked. It is not a regression, not a change in behavior, not only a question of consistency -- it is about responsibility. Who is responsible for setting an initial focus? And I don't think there's a clear answer to that although I must confess that I'm not familiar with X and related things at all. Since it is only a one-line fix in dwm and this might end up in a lot of discussion, I personally think it is not worth the hassle. However, if someone feels strongly about it, feel free to do some research and start a discussion on that.
Re: [dev] [dwm] [PATCH] Focus root window on startup
On Tue, Aug 27, 2013 at 11:34:32AM +0200, Martti Kühne wrote:
> On Mon, Aug 26, 2013 at 10:09 PM, Lukas Fleischer
> wrote:
> > *bump*. Is this something that might be included in mainline?
> >
> >>
> >> diff --git a/dwm.c b/dwm.c
> >> index 6f716e9..1bbb4b3 100644
> >> --- a/dwm.c
> >> +++ b/dwm.c
> >> @@ -1542,6 +1542,7 @@ setup(void) {
> >> XChangeWindowAttributes(dpy, root, CWEventMask|CWCursor, &wa);
> >> XSelectInput(dpy, root, wa.event_mask);
> >> grabkeys();
> >> + focus(NULL);
> >> }
> >>
>
> You haven't made an addition for a line of code in dwm which didn't
> work before. That means there is no part in dwm that doesn't work
> withiut your addition, except being started by LXDM. That in turn...
> would be a bug in LXDM IMHO.
So the fact that this works with all other display managers (and when
not using a display manager at all) implies that it is a bug in LXDM?
That is simply not true. We cannot make conclusions based on that, just
like we cannot assume it's a bug in dwm because the very same bug has
been fixed in awesome a couple of months ago.
The real question we should be asking ourselves is: Can we rightfully
assume that the root windows is focussed when dwm is started and there
are no clients to manage?
If the answer is yes, drop this patch and I will fix the bug in LXDM. If
the answer is no, this should be included in mainline.
>
> cheers!
> mar77i
>
Re: [dev] [dwm] [PATCH] Focus root window on startup
On Sun, Aug 18, 2013 at 01:36:50PM +0200, Lukas Fleischer wrote:
> It seems like we did not ensure that the root window has the input focus
> when starting dwm without any clients. This led to several problems,
> such as dwm being unresponsive when started from LXDM, see
> https://bbs.archlinux.org/viewtopic.php?id=147693 for details.
>
> Fix this by setting the initial input focus in setup().
>
> Signed-off-by: Lukas Fleischer
> ---
> I am not entirely sure whether this is the right thing to do but it
> fixes the problems mentioned in the commit message for me.
>
> dwm.c | 1 +
> 1 file changed, 1 insertion(+)
*bump*. Is this something that might be included in mainline?
>
> diff --git a/dwm.c b/dwm.c
> index 6f716e9..1bbb4b3 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -1542,6 +1542,7 @@ setup(void) {
> XChangeWindowAttributes(dpy, root, CWEventMask|CWCursor, &wa);
> XSelectInput(dpy, root, wa.event_mask);
> grabkeys();
> + focus(NULL);
> }
>
> void
> --
> 1.8.4.rc2.477.g1da3ebd
>
>
[dev] [dwm] [PATCH] Focus root window on startup
It seems like we did not ensure that the root window has the input focus
when starting dwm without any clients. This led to several problems,
such as dwm being unresponsive when started from LXDM, see
https://bbs.archlinux.org/viewtopic.php?id=147693 for details.
Fix this by setting the initial input focus in setup().
Signed-off-by: Lukas Fleischer
---
I am not entirely sure whether this is the right thing to do but it
fixes the problems mentioned in the commit message for me.
dwm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dwm.c b/dwm.c
index 6f716e9..1bbb4b3 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1542,6 +1542,7 @@ setup(void) {
XChangeWindowAttributes(dpy, root, CWEventMask|CWCursor, &wa);
XSelectInput(dpy, root, wa.event_mask);
grabkeys();
+ focus(NULL);
}
void
--
1.8.4.rc2.477.g1da3ebd
Re: [dev] [PATCH] Changed the way title is set to support UTF-8.
On Fri, Feb 22, 2013 at 09:25:19PM +0400, Alexander Sedov wrote: > Fair enough. Looks like automatic sending via git has its downsides. You can use `git send-email --annotate HEAD^` and add a prefix to the subject. Or just change the "format.subjectprefix" configuration value to something like "st] [PATCH". > To clarify: it's for st. > > > 2013/2/22 Carlos Torres > > Next time why not mention the app the patch is for in the subject i.e. > [dev][dwm] that way its not ambiguous. > > --Carlos > > >
Re: [dev] [suckless] Migration to git
On Thu, Feb 14, 2013 at 01:01:03PM +1100, Sam Watkins wrote:
> > I've been working with git lately, trying to do some unusual things,
> > and I need to say this is one of the least suckless pieces of software
> > I've ever worked with. It's complex, obscure, inconsistent, quirky...
>
> > tell what you did
>
> Ok, here is one day in the life of messing about with git.
>
>
> Let's say you wanted to get rid of all history from a repo, just keep
> the current commit. Git lets us rewrite history, so this should be
> easy, right? Wrong. I won't tell you how long it took to find this
> weird technique:
>
> [...]
>
> But ordinary things are famously weird in git, also.
>
It's a one-liner:
$ git reset $(git commit-tree -m "foobar" HEAD^{tree})
Pretty fast:
git reset $(git commit-tree -m "foobar" HEAD^{tree}) 0.00s user 0.01s
system 70% cpu 0.009 total
`git gc` also works perfectly fine after running that.
Re: [dev] Re: [suckless] Migration to git
On Mon, Nov 26, 2012 at 03:59:11PM +0100, pancake wrote: > On 11/26/12 12:31, Christian Neukirchen wrote: > >pancake writes: > > > >>git is far more confusing than hg.. in fact sometimes i have to check > >>my notebook or manpages in order to do something in hg is plain easy. > >Do you have some concrete examples? Maybe it's just a matter of taste, > >but I find Git more logical to use than Mercurial. YMMD. > > > for example > > "hg reset" is the same as "git clean -fXd ; git checkout -f" git-reset(1). > > same for 'hg cat' or hg tags.. > > hg tags = for a in `git tag`; do git show-ref $a ; done `git show-ref --tags`.
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:52:57PM +, Connor Lane Smith wrote: > On 9 February 2012 22:44, Lukas Fleischer wrote: > > Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :) > > It'd probably be more like, > > > const char *s = (argc < 2) ? "y" : argv[1]; > > while(puts(s) != EOF); Agreed :) > > cls
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:19:55PM +, Connor Lane Smith wrote: > Do we really need multiple arguments for yes(1)? BSD doesn't. > > > while(puts(argv[1]) != EOF); Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :) > > cls
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote:
> malloc() in yes(1) is definitely overkill. I've attached a simple
> version.
Invoking malloc() once (resulting in O(1) additional time and space) is
overkill but using printf() in every iteration (which means firing up
the printf() parser over and over again) isn't? I think you're a tad off
base, sir...
There's only two ways to implement this properly:
* Build the string during program initialization and use puts() (or
something similar) to print that string over and over again.
* Call the output routine once for each token in each iteration. If we
use buffered streams, this shouldn't make much difference. We should
probably do some quick performance tests to be sure, though.
> #include
>
> int
> main(int argc, char **argv)
> {
> const char *y[] = {"","y"};
> int i;
>
> if(argc < 2)
> argv=y, argc=2;
>
> for(;;){
> for(i=1; i printf("%s%s\n", argv[i], (i==argc-1)?"":" ");
> }
> }
Re: [dev] [dwm] code cleanup
On Tue, Jul 26, 2011 at 11:16:30PM +0400, anonymous wrote: > Style fixes, removed > > missing = NULL; > > line. XCreateFontSet do it for you at the beginning of function [1]. > Added missing blank line, still 5 lines removed. > > dwm page [2] says "dwm is only a single binary, and its source code is > intended to never exceed 2000 SLOC". wc -l says there are 2077 lines > (2072 with patch). Some code should be removed or rewritten or dwm will > grow over 2100 lines soon. > The output `wc -l` is a bad measure for the actual SLOC. It counts comments, empty lines, wrapped lines etc. sloccount(1) says "dwm.c" from the 5.9 release tarball has 1836 SLOC which is fine. > [1] > http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libX11/src/FSWrap.c?rev=1.3 > [2] http://dwm.suckless.org/
Re: [dev] dmenu-4.4
On Wed, Jul 20, 2011 at 10:58:32AM +0100, Kai Hendry wrote: > On 20 July 2011 10:54, Nick wrote: > > wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig > > gpg --verify dmenu-0.4.tar.gz.sig > > is not that tricky. > > You've skipped over the part of how you exchange the public key, no? Just upload it to suckless.org and/or some key servers. > If it's not that tricky why doesn't Arch for example build it in to their > tools? pacman 4.0.0 will support package signatures and we'll sign all packages in the official repos ([core], [extra], [community]) soon. > > And btw gpg sucks big time. :)
Re: [dev] @bleidl, 26/03/11 19:41
On Tue, Mar 29, 2011 at 06:35:05PM +0200, pancake wrote: > [brl_normal]Bruce Leidl (@bleidl) > 26/03/11 19:41 > Dude patiently tries to explain to #Archlinux why no authentication for > packages is a huge problem. Ban hammer. bit.ly/hSZUR3 > http://www.toofishes.net/blog/real-story-behind-arch-linux-package-signing/
Re: [dev] backup windows
On Wed, Mar 09, 2011 at 07:44:36PM +, hiro wrote: > I currently use ftp to manually backup an important folder from the > windows laptop to my lunix file server. > This folder has gotten too big and complicated lately, so I'm > searching for a windows application to automate this. > It probably needn't sync, but push (one-way) at least the differences. > > I assume on linux most of you will say rsync sucks least, is that still right? > I don't feel great about using cygwin so I'd like to hear your opinions. What kind of files are in that directory? If it's source code and/or configuration files or maybe even some other kind of plain text files, you might want to consider using some VCS. Otherwise, I'd say that rsync is the way to go, yes.
