Re: [dwm] Need a small image resize program
On 6/14/08, markus schnalke <[EMAIL PROTECTED]> wrote: > After I stepped over GD-lib (which has less dependencies, but still > provides ready-to-use functions), I started to write a tool with it. > See: http://prog.marmaro.de/resize-gd > gd is _not_ a small lib and --probably it's just me but-- i have some prejudice against "and is now maintained by [..] under the umbrella of PHP.net" (i've yet to see nice code from them) also gd only does very simple resampling (!= image resize) imlib2 of enlightment (mentioned earlier) is smaller, faster with nicer code (at least the simple scaling part) (actually i'd rather use imagemagick than a hack on top of gd)
Re: [dwm] dmenu directory test
On (14/06/08 16:20), James Turner wrote: > To: dynamic window manager > From: James Turner <[EMAIL PROTECTED]> > Subject: Re: [dwm] dmenu directory test > > On Sat, Jun 14, 2008 at 10:16:03PM +0200, Peter Hartlich wrote: > > Hi, > > > > > [...] I was wondering if it would make sense to add a test in dmenu_path > > > to make sure the directory actually exists before trying to cd into it? > > > > If you're bothered about cd printing an error message, you could just add > > 2>/dev/null to the cd line. > > > > Regards, > > Peter > > Doesn't it make more sense to do a test, then just redirect error > output? That cd itself is sort of test. -Ph -- Premysl "Anydot" Hruby, http://www.redrum.cz/
Re: [dwm] dmenu directory test
> Doesn't it make more sense to do a test, then just redirect error > output? That creates a race condition (the directory could be deleted between test and cd). Note that the rest of the code is only run if cd was successful. Also, test may be an external program. Regards, Peter
Re: [dwm] dmenu directory test
On Sat, Jun 14, 2008 at 10:16:03PM +0200, Peter Hartlich wrote: > Hi, > > > [...] I was wondering if it would make sense to add a test in dmenu_path > > to make sure the directory actually exists before trying to cd into it? > > If you're bothered about cd printing an error message, you could just add > 2>/dev/null to the cd line. > > Regards, > Peter Doesn't it make more sense to do a test, then just redirect error output? -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] dmenu directory test
Hi, > [...] I was wondering if it would make sense to add a test in dmenu_path > to make sure the directory actually exists before trying to cd into it? If you're bothered about cd printing an error message, you could just add 2>/dev/null to the cd line. Regards, Peter
[dwm] dmenu directory test
I just cloned the latest tip for dwm and dmenu. I'm happy to report everything is working great for me. On that note, I was wondering if it would make sense to add a test in dmenu_path to make sure the directory actually exists before trying to cd into it? I know I have $HOME/bin in my $PATH, but on my current machine I don't have that directory created. Attached is a simple tweak to dmenu_path to test if the directory exists. Thanks. -- James Turner BSD Group Consulting http://www.bsdgroup.org --- dmenu_path Sat Jun 14 15:24:14 2008 +++ dmenu_path Sat Jun 14 15:25:27 2008 @@ -14,6 +14,7 @@ if ! uptodate then for dir in $PATH do + test -d "$dir" && cd "$dir" && for file in * do
Re: [dwm] click to focus no longer works
On Sat, Jun 14, 2008 at 06:31:31PM +0200, yy wrote:
> 2008/6/14 Johannes Hofmann <[EMAIL PROTECTED]>:
> > Hi,
> >
> > with current tip (118ea4f4f554) it seems no longer possible to focus
> > a client by clicking it with the left mouse button.
> > To reproduce move the mouse over the stack, focus the main window
> > using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not
> > possible to focus the window under the mouse by clicking on it.
> >
> > Regards,
> > Johannes
> >
> >
>
> It's true, this is something I changed in my dwm after sending the
> patch to the list (I didn't know it was going to be applied). This (in
> buttonpress()) will do the trick:
>
> else if((c = getclient(ev->window))) {
> click = ClkClientWin;
> focus(c);
> }
>
Yes, that fixes it. Thanks!
Johannes
Re: [dwm] click to focus no longer works
2008/6/14 Johannes Hofmann <[EMAIL PROTECTED]>:
> Hi,
>
> with current tip (118ea4f4f554) it seems no longer possible to focus
> a client by clicking it with the left mouse button.
> To reproduce move the mouse over the stack, focus the main window
> using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not
> possible to focus the window under the mouse by clicking on it.
>
> Regards,
> Johannes
>
>
It's true, this is something I changed in my dwm after sending the
patch to the list (I didn't know it was going to be applied). This (in
buttonpress()) will do the trick:
else if((c = getclient(ev->window))) {
click = ClkClientWin;
focus(c);
}
--
- yiyus || JGL .
Re: [dwm] Need a small image resize program
On Fri, 13 Jun 2008 10:43:46 +0200 markus schnalke <[EMAIL PROTECTED]> wrote: > Hoi community, > > I feel the need for a image resize program that matches the > Unix and suckless philosophy. > Currently I'm using ImageMagick, which is just fine, if it is already > installed. But I was shocked, when I had to install it on a clean > system: I has that many dependencies! > The only thing I wanted was a program to resize images and I had to > install about 80 megabyte! > > Does anyone know a small program that can resize JPEG and PNG images? > > > meillo I'm not sure if this fits the suckless philosophy but why not use Python and the PIL(Python Imaging Library). Since python is installed as standard in almost all distributions all you have to do is include the Python Image Library modules in the same directory as your code. http://www.pythonware.com/products/pil/
Re: [dwm] feature freeze, please test
2008/6/14 Anselm R. Garbe <[EMAIL PROTECTED]>:
> On Sat, Jun 14, 2008 at 03:12:38PM +0200, yy wrote:
>> 2008/6/14 yy <[EMAIL PROTECTED]>:
>> > About the mouse warping issue we have discussed in #dwm, forget it, I
>> > can get the desired behavior with a little config.h modifications.
>> > I add:
>> >
>> > void
>> > warptosel(const Arg *arg) {
>> >if(sel)
>> >XWarpPointer(dpy, None, sel->win, 0, 0, 0, 0, 0, 0);
>> > }
>> >
>> > and then, in buttons definitions:
>> >
>> >{ ClkWinTitle, 0, Button1,warptosel,
>> >{0} },
>> >{ ClkWinTitle, 0, Button1,movemouse,
>> > {0} },
>> >{ ClkWinTitle, 0, Button3,
>> > resizemouse,{0} },
>> >{ ClkWinTitle, 0, Button4,focusstack,
>> > {.i = -1 } },
>> >{ ClkWinTitle, 0, Button5,focusstack,
>> > {.i = +1 } },
>> >
>> > and that's all. So I'd suggest to not touch dwm.c any more, and this
>> > message will stay here as a reference for other people if they are
>> > interested.
>> >
>>
>> I have reverted the ButtonPressMask in the root win and added
>>
>> else
>> click = ClkWinTitle;
>>
>> after the last else if in buttonpress, if you add this to the config.h
>> modifications in my previous message managing windows in the floating
>> layout is really comfortable, just click in the root window. I think
>> further thinking is needed before getting rid of root click events
>> (though this solution is not definitive, it still has the problem of
>> window borders treated like the root win...). What do other people
>> think about this?
>
> The only thing I dislike is the reuse of ClkWinTitle for the
> root window -- if we want to do that, we need to re-introduce
> ClkRootWin.
>
I agree, but I just want to use the same clicks. If it is implemented
in hg tip it should be with ClkRootWin. I just found an useful use for
it and it was the fastest way of trying it.
> Also, is the warp really necessary or shouldn't the handling be
> the same as in resizemouse?
>
If you always warp the pointer in movemouse to a corner, you won't be
able to move windows offscreen in two sides of the monitor, which
could annoy some people (it doesn't matter me). And anyway, using
another function somebody could call it in focus key/mouse
definitions. Maybe it could use the int arg with an Enum to choose a
window corner or the center, but I'm not sure that's necessary...
> Kind regards,
> --
> Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
>
>
See you,
--
- yiyus || JGL .
Re: [dwm] feature freeze, please test
Anselm, I just tried out the dwm current hg tip, with the recently posted kbmvresize.patch and prevnexttag.diff patches applied. I had to apply the kbmvresize patch by hand but that was simple enough. All appears to be working well on my box. The more I get to know dwm, the better I like it. Since the early 1.xx kernel days I've been primarily a Linux console user. I usually only switch to X windows for internet browsing, graphic/movie file viewing, etc. Since discovering dwm I've been using X more and the console less. I'm typing this e-mail via Alpine running in an urxvt terminal window. Many thanks for such a wonderful window manager Kevin http://www.RawFedDogs.net http://www.WacoAgilityGroup.org Bruceville, TX Si hoc legere scis nimium eruditionis habes. Longum iter est per praecepta, breve et efficax per exempla!!!
[dwm] click to focus no longer works
Hi, with current tip (118ea4f4f554) it seems no longer possible to focus a client by clicking it with the left mouse button. To reproduce move the mouse over the stack, focus the main window using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not possible to focus the window under the mouse by clicking on it. Regards, Johannes
Re: [dwm] Need a small image resize program
David Tweed <[EMAIL PROTECTED]> wrote: > > You don't say what kind of resizing you're doing and the constraints: > are you doing something like a generating thumbnails on-line so the > quality constraints aren't that high but you want it to be fast, or > trying to blow up images to fit the screen or something else? good idea ;-) The background is, that I search for an ImageMagick alternative for a webgallery generator I wrote. So it's about resizing from some megapixels to 800x600 similar. And also creating thumbnails. But it should become a generic program for resizing pictures, so in all cases it should work fine. (Although I dont focus on very high quality ... there is ImageMagick for that purpose.) Thanks for all hints I received! Espacially Thomas for the code ... I'll have a look at it. After I stepped over GD-lib (which has less dependencies, but still provides ready-to-use functions), I started to write a tool with it. See: http://prog.marmaro.de/resize-gd meillo signature.asc Description: Digital signature
Re: [dwm] move to lower tab, hide status bar and map the arrow keys
* Oren Golan <[EMAIL PROTECTED]> [080614 17:24]: > > 4. > the default keys to switch between tabs are alt+#. > these are the same keys used by firefox to switch between tabs. > how do you solve it? > I use Alt+F#, they're close to # on my laptop keyboard. -- Alexander Polakov | http://rootshell.be/~polachok/
Re: [dwm] feature freeze, please test
On Sat, Jun 14, 2008 at 03:12:38PM +0200, yy wrote:
> 2008/6/14 yy <[EMAIL PROTECTED]>:
> > About the mouse warping issue we have discussed in #dwm, forget it, I
> > can get the desired behavior with a little config.h modifications.
> > I add:
> >
> > void
> > warptosel(const Arg *arg) {
> >if(sel)
> >XWarpPointer(dpy, None, sel->win, 0, 0, 0, 0, 0, 0);
> > }
> >
> > and then, in buttons definitions:
> >
> >{ ClkWinTitle, 0, Button1,warptosel,
> > {0} },
> >{ ClkWinTitle, 0, Button1,movemouse,
> >{0} },
> >{ ClkWinTitle, 0, Button3,resizemouse,
> >{0} },
> >{ ClkWinTitle, 0, Button4,focusstack,
> > {.i = -1 } },
> >{ ClkWinTitle, 0, Button5,focusstack,
> > {.i = +1 } },
> >
> > and that's all. So I'd suggest to not touch dwm.c any more, and this
> > message will stay here as a reference for other people if they are
> > interested.
> >
>
> I have reverted the ButtonPressMask in the root win and added
>
> else
> click = ClkWinTitle;
>
> after the last else if in buttonpress, if you add this to the config.h
> modifications in my previous message managing windows in the floating
> layout is really comfortable, just click in the root window. I think
> further thinking is needed before getting rid of root click events
> (though this solution is not definitive, it still has the problem of
> window borders treated like the root win...). What do other people
> think about this?
The only thing I dislike is the reuse of ClkWinTitle for the
root window -- if we want to do that, we need to re-introduce
ClkRootWin.
Also, is the warp really necessary or shouldn't the handling be
the same as in resizemouse?
Kind regards,
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] feature freeze, please test
2008/6/14 yy <[EMAIL PROTECTED]>:
> About the mouse warping issue we have discussed in #dwm, forget it, I
> can get the desired behavior with a little config.h modifications.
> I add:
>
> void
> warptosel(const Arg *arg) {
>if(sel)
>XWarpPointer(dpy, None, sel->win, 0, 0, 0, 0, 0, 0);
> }
>
> and then, in buttons definitions:
>
>{ ClkWinTitle, 0, Button1,warptosel,
> {0} },
>{ ClkWinTitle, 0, Button1,movemouse,
> {0} },
>{ ClkWinTitle, 0, Button3,resizemouse,
> {0} },
>{ ClkWinTitle, 0, Button4,focusstack,
> {.i = -1 } },
>{ ClkWinTitle, 0, Button5,focusstack,
> {.i = +1 } },
>
> and that's all. So I'd suggest to not touch dwm.c any more, and this
> message will stay here as a reference for other people if they are
> interested.
>
I have reverted the ButtonPressMask in the root win and added
else
click = ClkWinTitle;
after the last else if in buttonpress, if you add this to the config.h
modifications in my previous message managing windows in the floating
layout is really comfortable, just click in the root window. I think
further thinking is needed before getting rid of root click events
(though this solution is not definitive, it still has the problem of
window borders treated like the root win...). What do other people
think about this?
--
- yiyus || JGL .
Re: [dwm] feature freeze, please test
About the mouse warping issue we have discussed in #dwm, forget it, I
can get the desired behavior with a little config.h modifications.
I add:
void
warptosel(const Arg *arg) {
if(sel)
XWarpPointer(dpy, None, sel->win, 0, 0, 0, 0, 0, 0);
}
and then, in buttons definitions:
{ ClkWinTitle, 0, Button1,warptosel,
{0} },
{ ClkWinTitle, 0, Button1,movemouse,
{0} },
{ ClkWinTitle, 0, Button3,resizemouse,
{0} },
{ ClkWinTitle, 0, Button4,focusstack,
{.i = -1 } },
{ ClkWinTitle, 0, Button5,focusstack,
{.i = +1 } },
and that's all. So I'd suggest to not touch dwm.c any more, and this
message will stay here as a reference for other people if they are
interested.
greets,
--
- yiyus || JGL .
[dwm] feature freeze, please test
Hi there,
I consider the current states of dwm hg tip and dmenu hg tip as
finished for the next release.
I contrast to my previous decision to postpone several patches
which have been supplied during the last weeks for after
dwm-5.0, I decided to integrate them now, just before dwm-5.0,
in order to minimize changes to config.h after the 5.0 release.
Thus, the current hg tip contains the following major changes:
1. The argument type for key- and button-handlers is a union
called Arg, which looks as follows:
typedef union {
int i;
uint ui;
float f;
void *v;
} Arg;
This enforces type-safety at compile time, but also provides the
flexibility to supply auxilliary arguments using the v-field.
2. The previous color/font definitions are const char[]
declarations now. Note, that in dmenu's config.h they are const
char * however, because there the pointer might change if
colors/fonts are overridden by program arguments.
3. The syntax to spawn has changed, if you prefer the old
behavior, config.def.h contains a SHCMD macro to supply the old
behavior.
4. A new Button type has been introduced which encapsulates the
mouse handling in dwm in a very similiar fashing as the Key type
does. See config.def.h for details. Thanks to yiyus for his
contribution!
5. dwm-5.0 support Xinerama in a very basic way, it basically
uses the Xinerama screen indexed by xidx only, however the
floating layout allows to use the whole real estate provided by
the X display -- so in multihead setups dwm can be used in a
floating fashion, whereas the biggest screen should be used for
the tiled layout.
6. The tags are addressed using bit-fields now, which has been
discussed earlier already. See the mailinglist archives for
details.
7. The bar is toggleable again.
8. There is a new maximize meta-layout which can be
enabled/disabled using Mod1-m.
In contrast to previous releases of dwm and dmenu, the 5.0 and
3.7 series will be major simplifications. I got rid of the
DEFGEOM and pseudo-multihead-layout overengineering from dwm-4.8
and dwm-4.9, so 5.0 feels more like 4.7, but provides
considerably major improvements.
Please report any bugs. If there aren't any major bugs, I will
release both, dmenu and dwm around mid of next week.
Kind regards,
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] move to lower tab, hide status bar and map the arrow keys
On Sat, Jun 14, 2008 at 12:11:23AM -0700, Oren Golan wrote:
> I just installed dwm after trying awesome and xmonad and I love it!
> 4 questions:
>
> 1.
> I added a method for 'next tab' and it works:
> nexttag(const char *arg) {
> unsigned int i, j;
>
> memcpy(prevtags, seltags, sizeof seltags);
> for (i = 0; i < LENGTH(tags); i++) {
> if (seltags[i])
> j = (i + 1) % LENGTH(tags);
> seltags[i] = False;
> }
> seltags[j] = True;
> arrange();
> }
>
> now i am trying to add a prevtag method.
> i replaced the (i + 1) with (i - 1) but it's not working correctly-
> when i am in tab 0 it jumps to tab 4 instead of tab 9.
>
> someone in irc told me that since i is unsigned i get underflow.
> what do u think?
Well, I recommend you adapting to hg tip, besides some minor
changes it represents 5.0 already, which I'm going to release
soon.
So my answer is mainly related to hg tip, not to the above
(4.7?) version you are talking about. However your observation
of
j = (0 - 1) % 9 = 3
is correct, because (unsigned int)-1 is the biggest unsigned
integer which can be represented in 32bits, so
j = 4294967295 % 9 = 3
So in a prevtag solution it should be
if(seltags[i])
j = (i == 0) ? (LENGTH(tags) - 1) : (i - 1) % LENGTH(tags);
However, as I told, in hg tip the solution would look like the
attached patch.
> 2.
> how can I hide the status bar? (like mod+b in awesome)
Mod1-b in hg tip.
> 3.
> how do i map the arrow keys? is it something like this?
> { MODKEY, XK_left, prevtag, NULL }
See attached patch for the hg tip representation.
> 4.
> the default keys to switch between tabs are alt+#.
> these are the same keys used by firefox to switch between tabs.
> how do you solve it?
Wether using the mouse in firefox or just using a different
MODKEY, like Mod4Mask for the windows key.
Kind regards,
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
diff -r e121660425a0 config.def.h
--- a/config.def.h Sat Jun 14 10:38:18 2008 +0100
+++ b/config.def.h Sat Jun 14 10:41:32 2008 +0100
@@ -51,8 +51,31 @@ static const char *dmenucmd[] = { "dmenu
static const char *dmenucmd[] = { "dmenu_run", "-fn", font, "-nb", normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor, NULL };
static const char *termcmd[] = { "uxterm", NULL };
+
+static void
+prevtag(const Arg *arg) {
+ uint i;
+ Arg a;
+
+ for(i = 0; i < LENGTH(tags) && !(tagset[seltags] & (1 << i)); i++);
+ a.ui = 1 << (i == 0 ? LENGTH(tags) - 1 : i - 1);
+ view(&a);
+}
+
+static void
+nexttag(const Arg *arg) {
+ uint i;
+ Arg a;
+
+ for(i = 0; i < LENGTH(tags) && !(tagset[seltags] & (1 << i)); i++);
+ a.ui = 1 << (i == LENGTH(tags) - 1 ? 0 : i + 1);
+ view(&a);
+}
+
static Key keys[] = {
/* modifier keyfunctionargument */
+ { MODKEY, XK_Left, prevtag,{0} },
+ { MODKEY, XK_Right, nexttag,{0} },
{ MODKEY, XK_p, spawn, {.v = dmenucmd } },
{ MODKEY|ShiftMask, XK_Return, spawn, {.v = termcmd } },
{ MODKEY, XK_b, togglebar, {0} },
Re: [dwm] move to lower tab, hide status bar and map the arrow keys
Retarded
Regards,
-MoD-
On Jun 14, 2008, at 0:11, "Oren Golan" <[EMAIL PROTECTED]> wrote:
I just installed dwm after trying awesome and xmonad and I love it!
4 questions:
1.
I added a method for 'next tab' and it works:
nexttag(const char *arg) {
unsigned int i, j;
memcpy(prevtags, seltags, sizeof seltags);
for (i = 0; i < LENGTH(tags); i++) {
if (seltags[i])
j = (i + 1) % LENGTH(tags);
seltags[i] = False;
}
seltags[j] = True;
arrange();
}
now i am trying to add a prevtag method.
i replaced the (i + 1) with (i - 1) but it's not working correctly-
when i am in tab 0 it jumps to tab 4 instead of tab 9.
someone in irc told me that since i is unsigned i get underflow.
what do u think?
2.
how can I hide the status bar? (like mod+b in awesome)
3.
how do i map the arrow keys? is it something like this?
{ MODKEY, XK_left, prevtag, NULL }
4.
the default keys to switch between tabs are alt+#.
these are the same keys used by firefox to switch between tabs.
how do you solve it?
thanks!
[dwm] move to lower tab, hide status bar and map the arrow keys
I just installed dwm after trying awesome and xmonad and I love it!
4 questions:
1.
I added a method for 'next tab' and it works:
nexttag(const char *arg) {
unsigned int i, j;
memcpy(prevtags, seltags, sizeof seltags);
for (i = 0; i < LENGTH(tags); i++) {
if (seltags[i])
j = (i + 1) % LENGTH(tags);
seltags[i] = False;
}
seltags[j] = True;
arrange();
}
now i am trying to add a prevtag method.
i replaced the (i + 1) with (i - 1) but it's not working correctly-
when i am in tab 0 it jumps to tab 4 instead of tab 9.
someone in irc told me that since i is unsigned i get underflow.
what do u think?
2.
how can I hide the status bar? (like mod+b in awesome)
3.
how do i map the arrow keys? is it something like this?
{ MODKEY, XK_left, prevtag, NULL }
4.
the default keys to switch between tabs are alt+#.
these are the same keys used by firefox to switch between tabs.
how do you solve it?
thanks!
