On Tue, Oct 22, 2013 at 3:23 AM, Jens Staal wrote:
> On Monday 21 October 2013 14:43:16 Carlos Torres wrote:
>> so then...on a separate topic is stali meant to be a distro that sucks
>> at being extensible?
>> or is it meant to be a distro thats simple, lean and yet extensible.
>
> If I understood
On Monday 21 October 2013 14:43:16 Carlos Torres wrote:
> On Mon, Oct 21, 2013 at 1:15 PM, hiro <23h...@gmail.com> wrote:
> > Yeah, tinycore's biggest failure is that it's too difficult to find
> > the right man pages of certain packages.
>
> I knew tinycore wouldn't have docs included, they say s
On Mon, Oct 21, 2013 at 1:15 PM, hiro <23h...@gmail.com> wrote:
> Yeah, tinycore's biggest failure is that it's too difficult to find
> the right man pages of certain packages.
I knew tinycore wouldn't have docs included, they say so in the website,
heck when i create a tcz for my self, i strip th
Yeah, tinycore's biggest failure is that it's too difficult to find
the right man pages of certain packages.
On 10/21/13, Carlos Torres wrote:
> On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote:
>> then simply don't use pure 64bit, why did you think that was a good idea?
>
> when i
On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote:
> then simply don't use pure 64bit, why did you think that was a good idea?
when i hopped on the pure 64 band wagon i "assumed" that the x86 packages
would have been rebuilt for pure 64 eventually... that was a big mistake on my
part.
On 2013-10-21 16:28, koneu wrote:
> On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote:
> > I hope it scared you away from webkit also.
>
> Compared to Gecko (XUL, lol!), the only other web engine as popular as
> WebKit, WebKit is a blessing, especially WebCore. I think only Hubbub beats
>
On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote:
> I hope it scared you away from webkit also.
Compared to Gecko (XUL, lol!), the only other web engine as popular as WebKit,
WebKit is a blessing, especially WebCore. I think only Hubbub beats it in speed.
Maybe it's time surf switched t
On 10/20/13, Carlos Torres wrote:
> On Tue, Aug 13, 2013 at 6:24 PM, Carlos Torres
> wrote:
>> Glad you changed your mind on Android core.
>> Consider looking at tinycorelinux; it too is very simple. simpler than
>> crux.
>
> hmm, after tooling around with tinycorelinux, i think its use
> does
On Tue, Aug 13, 2013 at 6:24 PM, Carlos Torres wrote:
> Glad you changed your mind on Android core.
> Consider looking at tinycorelinux; it too is very simple. simpler than crux.
hmm, after tooling around with tinycorelinux, i think its use
doesn't make sense
as a day-to-day distro. it would
On Tue, Aug 13, 2013 at 1:21 PM, Anselm R Garbe wrote:
> Actually I gave up on the android core now and am looking at crux 3.0
> now.
Glad you changed your mind on Android core.
Consider looking at tinycorelinux; it too is very simple. simpler than crux.
Thanks,
--Carlos
On 17 November 2012 20:50, Kurt H Maier wrote:
> crux linux might have some useful approaches. I don't understand the
> decision to use android crap like bionic when musl has come so far so
> quickly.
Actually I gave up on the android core now and am looking at crux 3.0
now. I like the fact that
On 25 November 2012 19:30, clamiax wrote:
> Why don't provide an external lib, like libdraw, which provide an
> interactive bar which read/write data from/to somewhere and share it between
> dwm, tabbed, dmenu, etc. etc.?
An external bar would require an interface with all of the apps you
listed.
Why don't provide an external lib, like libdraw, which provide an
interactive bar which read/write data from/to somewhere and share it
between dwm, tabbed, dmenu, etc. etc.?
2012/11/25 Anselm R Garbe
> On 25 November 2012 15:26, KarlOskar Rikås wrote:
> > I would like the bar to stay, but I'll
On 11/25/2012 06:22 PM, Anselm R Garbe wrote:
As I said, the bar will stay (default), but there will be a compile
time option to not compile it in.
Best regards,
Anselm
Perfect!
--
Barbu Paul - Gheorghe
Common sense is not so common - Voltaire
Visit My GitHub profile to see my open-source pr
On 25 November 2012 15:26, KarlOskar Rikås wrote:
> I would like the bar to stay, but I'll be fine to have the mouse support
> removed.
As I said, the bar will stay (default), but there will be a compile
time option to not compile it in.
Best regards,
Anselm
On 2012-11-25, at 16:39, Noah Birnel wrote:
> I use dwm to manage 10-15 simultaneous RDP sessions. Since RDP eats all
> keystrokes, the mouse is the only way to switch between them. No mouse = I
> need a different WM.
Assuming you are using rdesktop as RDP client, try option -K to allow window
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
Yes. No.
I use dwm to manage 10-15 simultaneous RDP sessions. Since RDP eats all
keystrokes, the mouse is the only way to sw
I would like the bar to stay, but I'll be fine to have the mouse support
removed.
Thanks klr
On 17 November 2012 20:50, Kurt H Maier wrote:
> crux linux might have some useful approaches. I don't understand the
> decision to use android crap like bionic when musl has come so far so
> quickly.
I think crux is one of the cleanest distros and some aspects of it are
indeed a good starting p
On Thu, Nov 22, 2012 at 10:46:15AM +0100, sta...@cs.tu-berlin.de wrote:
> Either me or you misunderstood the other one.
The point is, you can configure borders or not in the dwm program already -
no need to make major changes to it.
Sam
* Sam Watkins [2012-11-22 04:58]:
> On Wed, Nov 21, 2012 at 12:45:35PM +0100, sta...@cs.tu-berlin.de wrote:
> > - borders are useful
means yes to borders
> configuration
>
> border-width: 0
means no borders.
>
> problem solved
how???
Either me or you misunderstood the other one.
cheers
--s
On Wed, Nov 21, 2012 at 12:45:35PM +0100, sta...@cs.tu-berlin.de wrote:
> - borders are useful
configuration
border-width: 0
problem solved
Borders are not drawn by dwm, the border width is a part of the window
configuration dwm tells
the X server to use on each window. The *only* drawing performed by dwm is the
bar. Getting rid
of the bar would also mean that the status string does not have to pass through
dwm as it would
rather be
- borders are useful
- the information in the bar is quite useful, too. Don't mind if it is
provided separately. But isn't it too much ofa hassle to interface it
with dwm then?
- never used mouse in the bar, and don't plan to.
cheers
--s_
On 121117 2053, Ruben Mikkonen wrote:
> Hi,
>
> However, why would dwm need draw{.h,c} if there were no bar? Window
> borders? They're imo somewhat useless: a) If a window is a terminal
> window, then you easily see from the cursor if it's active. b) Otherwise
> you most likely need the mouse anyw
Anselm R Garbe writes:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
FWIW:
I've used it on occasion. But I can certainly live without it, using the keys
combination it is fine.
> I barely use the mouse for the dwm bar and would
Errata: I meant logind. It's really difficult to remember anything but
the d in the end, as the distribution now uses everythingd...
On 11/19/2012 03:53 AM, 7...@mail.com wrote:
I do *TOTALLY* agree. (one could cote netcfg in addition to systemd
and profiled and...)
If you want the complete l
I do *TOTALLY* agree. (one could cote netcfg in addition to systemd and
profiled and...)
If you want the complete list, go to http://archlinux.org/news it's faster.
7heo.
On 11/18/2012 09:56 AM, clamiax wrote:
I do not want to get involved in one of the usual useless discussions about
how muc
söndagen den 18 november 2012 07.42.52 skrev Strake:
> One may use stacking bind mounts rather than symlinks. I know no
> decent such fs in Linux kernel space, as aufsn and unionfs seem
> cumbersome, but it ought to not be too difficult in user space, as 9p
> server.
This is indeed a really cool
I rewrote stow in guile about 10 years ago when I did my gnu/hurd distro it was
much more maintainable and short.. Not because of perl, but gnu. But well.. I
dont think this is going to give anything good to the discussion.
I use arch nowadays but im sure it will not be my next prefered distro w
On 2012-11-18 at 11:04:31
Kurt H Maier wrote:
> On Sun, Nov 18, 2012 at 07:00:23AM +0100, Jens Staal wrote:
> > For me, this is a nicer solution than for example pacman to keep
> > track on which files that belong to which package (no fragile
> > databases needed). I am also happy to report that
Dnia 18 listopada 2012 17:04 Kurt H Maier napisał(a):
> When I discovered wayland required mesa, I cited it as the biggest
> problem wayland had. Now it has other problems, but mesa still really
> sucks. Not only does it depend on libudev, it has a build-time dep on
> libxml2 (unsure if that is
On Sun, Nov 18, 2012 at 07:00:23AM +0100, Jens Staal wrote:
> For me, this is a nicer solution than for example pacman to keep track on
> which files that belong to which package (no fragile databases needed). I am
> also happy to report that dmenu/dwm works nicely on Sabotage (however, it
> see
On 18/11/2012, Bjartur Thorlacius wrote:
> GNU Stow also.
Oh, yeah, that's what we need: more perl.
Jens Staal wrote:
> I agree with this. As an example distribution, Sabotage does things pretty
> well. One detail that I like a lot (but it sort of depends on your stance on
> symlinks) is the way applications usually are placed in it:
> Each application gets its own directory under /opt and then
On Sun, Nov 18, 2012 at 11:10 AM, Felix Janda wrote:
> On 11/18/12 at 07:00am, Jens Staal wrote:
>> Each application gets its own directory under /opt and then installed files
>> get symlinks in / (the file system hierarchy is stali-inspired with
>> everything
>> in root and usr just pointing bac
On 11/18/12 at 07:00am, Jens Staal wrote:
> I agree with this. As an example distribution, Sabotage does things pretty
> well. One detail that I like a lot (but it sort of depends on your stance on
> symlinks) is the way applications usually are placed in it:
>
> Each application gets its own di
On 18 November 2012 07:00, Jens Staal wrote:
> lördagen den 17 november 2012 14.50.23 skrev Kurt H Maier:
>> On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
>> > sta.li
>> > --
>> > To me archlinux was a good distro until a couple of years ago.
>> > Nowadays it seems to be ver
I do not want to get involved in one of the usual useless discussions about
how much something sucks. As for me, I have never been able to install
Archlinux without having to use a custom kernel, which is unacceptable for
a serious linux distro. The system is often unstable, the community is
rather
lördagen den 17 november 2012 14.50.23 skrev Kurt H Maier:
> On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
> > sta.li
> > --
> > To me archlinux was a good distro until a couple of years ago.
> > Nowadays it seems to be very en vogue and thus has degraded quite
> > significan
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used ins
On 11/17/12, Anselm R Garbe wrote:
> Ok, I've heard enough.
>
> The built-in bar stays as is, but I will organize its code in a way,
> that dwm can be compiled without the bar.
>
> Best regards,
> -Anselm
>
>
sounds like a very useful thing, I can betatest if you like.
I use the mouse quite a bit to switch tags when working with virtual
machines and RDP sessions that fill my screen, less the bar. Bringing
mouse support in via patch wouldn't be a big deal.
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
tablets are used to read pdfs, and tablets do not have keyboards.
however, while i didn't quite parse your whole pr
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
>
> sta.li
> --
> To me archlinux was a good distro until a couple of years ago.
> Nowadays it seems to be very en vogue and thus has degraded quite
> significantly in terms of simplicity. I'm not aware of any distro that
> would
Greetings.
On Sat, 17 Nov 2012 20:26:09 +0100 Manolo Martínez
wrote:
> On 11/17/12 at 01:15pm, Newton Smartt wrote:
> > What's wrong with Arch?
>
> systemd is probably frowned upon around here.
People proposing systemd are likely pedophiles or terrorists. The only
difference to tor users is
For whatever it's worth (which is not much since I don't contribute much of
anything to this community anyway), I hardly touch the mouse and wouldn't
even notice if mouse functionality was removed from the bar. I do like
having the bar managed by DWM though. The fewer external programs I have
to
On 11/17/12 at 01:15pm, Newton Smartt wrote:
> What's wrong with Arch?
systemd is probably frowned upon around here.
What's wrong with Arch?
On Sat, Nov 17, 2012 at 1:11 PM, clamiax wrote:
> 2012/11/17 Anselm R Garbe
>
>> Hi there,
>>
> Hi.
>
>
>> I'm back in the game ;)
>>
> Welcome back!
>
>
>> (i) First I plan a new dwm release with the introduction of draw{.h,c}
>> or libdraw. The idea is to abstract all
2012/11/17 Anselm R Garbe
> Hi there,
>
Hi.
> I'm back in the game ;)
>
Welcome back!
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface
Ok, I've heard enough.
The built-in bar stays as is, but I will organize its code in a way,
that dwm can be compiled without the bar.
Best regards,
-Anselm
On Sat, Nov 17, 2012 at 1:29 PM, Manolo Martínez
wrote:
> If this is something like a poll, I concur: no mouse, yes bar.
This is also my feeling. I never use the mouse on the bar, but unless
sbar will be able to display those handy little boxes over the tags,
I'd rather keep what dwm has currentl
Anselm R Garbe wrote:
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> rig
Hi,
On Sat, 17 Nov 2012, Anselm R Garbe wrote:
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functiona
you know what, i take beck what i said about a couple of things:
1) while separating out common drawing functionality in to a librady
is appealing.
i don't think all suckless apps should be depending on an external
source. they're
all independent right now. and i've only incrementally started usi
On 11/17/12 at 01:57pm, Jamie Bragg wrote:
> I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I
> would kind of miss the dwm bar if it went away, simply because I'd have to
> find another solution.
>
If this is something like a poll, I concur: no mouse, yes bar.
M
Hi,
* Anselm R Garbe [2012-11-17 18:22]:
> I'm back in the game ;)
wb :)
[...]
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like s
On 17 November 2012 18:58, Christoph Lohmann <2...@r-36.net> wrote:
> On Sat, 17 Nov 2012 18:58:22 +0100 Anselm R Garbe wrote:
> I’m all for draw.{h,c}. Otherwise the complexity of dependency handling
> will need to be added to all of the packages using libdraw. There might
> be a tendency of
Good to hear you're back
On Sat, Nov 17, 2012 at 12:20 PM, Anselm R Garbe wrote:
>
> Hi there,
>
> I'm back in the game ;)
>
> Here is my master plan:
>
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft
Hi,
The mouse functionnality in dwm bar could become a patch, no more
mainline. I don't use it often, but when I do it's to launch a 9menu.
I concur with Nick about the bar, I need it and I trust the dwm one.
It's good to hear from you
Xavier
Le 18:20:03 le 17 nov. 2012 , Anselm R Garbe a écri
Greetings.
On Sat, 17 Nov 2012 18:58:22 +0100 Anselm R Garbe wrote:
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> us
On 17 November 2012 18:57, Jamie Bragg wrote:
> I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I
> would kind of miss the dwm bar if it went away, simply because I'd have to
> find another solution.
To be clear, of course I would implement sbar instead which could be
us
I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I
would kind of miss the dwm bar if it went away, simply because I'd have to
find another solution.
Jamie
On 17 Nov 2012 13:42, "Nick" wrote:
> Quoth Anselm R Garbe:
> > -> is there anyone who uses the mouse functionality
Quoth Anselm R Garbe:
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
I do use it sometimes, but could live without it. No strong
preferences.
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altog
Hi there,
I'm back in the game ;)
Here is my master plan:
dwm
---
(i) First I plan a new dwm release with the introduction of draw{.h,c}
or libdraw. The idea is to abstract all the PCF/Xft cruft away from
the dwm implementation and to define a clean draw.h interface to be
used instead. This shou
65 matches
Mail list logo
