Re: [dwm] musca wm

2009-05-16 Thread Mate Nagy
Greetings,
 Using a prefork or similar technique done by apache f.ex can really  
 accelerate such tasks, so a minimal vi editor with nice features can be 
 really achieved by delegating all such features to external apps or  
 libraries
 a minimal application with a dozen external modules, processes, pipes
to achieve the required functionality will be 10x slower and nastier
than if these things were built in.

 Modularization isn't a cure-all - it has a direct impact on
performance, user-friendliness, maintainability, and especially on
simplicity. It's also hard to get right.

 anecdote when I last used wmii a long time ago, a lot of
functionality was off the core. To listen for keybindings, you had
to interface with a virtual filesystem (because plan9 is automatically
cool, right?) - with a cli util that you had to start everytime to
read/write/touch a file. To drive the keybinding logic, you had to run a
complicated shell script (at least this was the default solution) that
read keyboard events through pipes and wrote back control commands,
everything through this vfs util.
 So to make me able to start a new terminal, you had to continuously run
at least 3 extra processes and a lot of code. How is this minimal or
suckless? No wonder a lot of us flocked to dwm...

 I believe in fast, simple, but powerful CLI interfaces rather than
programs pared down to bones. To be quite honest, I'd miss the color
functionality from ls, dpkg argument-expansion from my shell, or the
standard arguments from all the GNU software - if this means supporting
--version in true, so be it. I'm not running an embedded system, a 97k
ls doesn't hurt me too much.

 (I realize this is the same argument MS supporters use to validate the
existence of a multi-gigabyte Visual Studio etc, but let's be realistic
people, 97k ls in 2009 vs. Visual goddamn Studio.)

Best regards,
 Mate



Re: [dwm] musca wm

2009-05-15 Thread Mate Nagy
 I cannot understand GNU software. ls or cat source in GNU is scary,
 glibc is even worse. The old UNIX utilities or Plan9 ones have a
 simplicity which GNU lacks. I don't have anything against the GPL
 license, but I prefer less restrictive licenses. And, of course, I
 don't like rms.
 i don't know what's up with this newfangled popular hate for GNU
software. The GNU userland is a thousand times more comfortable and
usable than old unix, not least because some utils even have features
(imagine that), while the old unix tools were simplistic hackjobs.

 Minimalism is a good thing to consider while developing software, but
obsessing about it is no better than with anything else. I'm as annoyed
with huge monstrous software like OpenOffice or Gnome or even Firefox as
anyone, but wanting to take away the features of the CLI userland that
make it comfortable is mad. Would you use dash instead of zsh as an
everyday shell?

 At a risk of being boring, I'll say that the same argument can be made
about text editors: VIM is quite bloated and big, but it's better than
any small text editor; because text editing is one of those typical
tasks that cannot be comfortable without a million features that are in
no way related to each other. Even if someone writes a really small,
elegant, suckless editor core, it will be unusable until:
 - it gets encoding handling right (internal, file, terminal)
 - word wrapping (disabled, enabled, soft, hard...)
 - syntax highlighting and autoindent, for C, Python, Lisp...
 - all possible tab behaviors (soft, hard, half,...)
 - autocompletion, ctags integration
These are just the absolutely necessary basics, and if you implement
these, you already have a multi-ten-thousand line application.
Sucklessness goes through the window.
(Yes, there are people who make do with mcedit, but.. come on.)

 I say dwm (for example) is good because it's good, not because it's
suckless. The sucklessness is certainly part of its goodness, but not
all. If it was uncomfortable, would anyone use it? and it's still only
marginably usable with a multi-monitor configuration - proper handling of
this would require adding of this bloat everyone hates so much.

Best regards,
 Mate
PS. am not trolling :)



Re: [dwm] dwm's future

2009-04-26 Thread Mate Nagy
Hi all,
 I'm sure there is a severe risk of this piece being understood as
flamebait (this is not my intention).

 However, I strongly believe that the major problem of dwm currently is
not font handling (8bit ascii bitmap fonts are perfectly fine thank
you); not the status bar (it's great); instead, it's twofold:

1. Complete lack of proper xrandr and multi monitor support - this is
solved in multiple tiling wms, there's no reason other than lack of
interest or obscure ideology not to do this.

2. Handling of broken applications (reparenting). Not many tiling wms
get this right. I believe a good solution is to unconditionally reparent
all windows. This adds some code, but means no difference to the user
(the window frame can still be a single pixel border, if you like),
however it fixes all/most incompatibility problems in a single stroke.

NB. the added complexity of unconditional reparenting is massively
smaller than using pango (especially if you consider the dependencies);
the achieved improvement in perceived user experience is also arguably
much larger.

Regards,
 Mate



Re: [dwm] dwm's future

2009-04-26 Thread Mate Nagy
 ...that's from dwm 5.4.1, using xrandr --output DVI-0 --right-of
 DVI-1.  Problem solved.
 well obviously i had something more sophisticated in mind :)
 like, horribile dictu, displaying different tags or different layouts
on different monitors. or supporting more monitors than 2...

M.



Re: [dwm] Gvim size problem

2009-04-15 Thread Mate Nagy
 Just tried, does not help.
 in fact, this problem appears with xmonad as well, so it's probably
generic to all tiling wms; tiling wms are Doing It Wrong - probably
according to the text of the standards, but many apps don't respect
these standards.
 If Java doesn't work because it's a buggy POS, is one thing; but if
gvim or *xterm* of all things don't work, then that's another thing
entirely.

Best regards,
 Mate



Re: [dwm] Suckess Code Management

2009-03-12 Thread Mate Nagy
Window Manager = xmonad (for working twinview support)
Shell = zsh and bash (zsh is good but oh so slow...)
File Manager = shell/mc
Text Editor = vim
Calendar / Todo = nothing/cal/text files in svn
File search = locate/find/grep/ctags!!
SCM = svn
E-Mail = mutt
Music = mocp
Chat = irssi  bitlbee
Terminal = xterm for the win
Build = make
Debugger = the usual
Gaming = angband derivatives, but not too much

Regards,
 Mate



Re: [dwm] CLI color/font override patch

2009-02-24 Thread Mate Nagy
On Tue, Feb 24, 2009 at 02:05:21PM -0500, Jeremy Jay wrote:
 If you want to avoid the compile I'm sure it'd be
 just as easy to use a hex-editor on the strings.
 we should write something like Dehacked for dwm :D

Mate



Re: [dwm] What happened here?

2009-01-20 Thread Mate Nagy
Hiya,
 The website lists clarity as a feature. Clarity!
 As for only having to learn C code to edit the config, I know C
 reasonably well, but I get bad vibes from config.h, I think I'd rather
 try to learn Lua.
 do consider the alternatives - xmonad is a smashing tiling wm (using it
now for its good xinerama support), and the config file is in Haskell.
 Would you rather make the effort to understand C code and bitmasks, or
Haskell? :)

Regards,
 Mate



Re: [dwm] plan for dwm

2008-12-12 Thread Mate Nagy
Hiho,
On Fri, Dec 12, 2008 at 07:15:55PM +, Anselm R Garbe wrote:
 Hi,
 
 here is the plan:
 
 slock-1.1 will be released soon containing Ali's patch with some minor
 modifications.
 
 dwm-5.4 will also be released soon containing the transition patch
 with the proposed x property based status reporting, and Neale's spawn
 patch again, and possibly some other minor patches ;)
 
 After that 5.5 could contain a more advanced approach for multihead
 support (though I think I need to investigate further and experiment
 more into this direction, before agreeing on the final approach). It
 should also contain a cleaned up usage of the HEIGHT/WIDTH macros
 besides the reduction of the ugly 2 * c-bw occurrences throughout
 the code (I plan to move these border deductions to resize).
 
 Then there will be something else soon as well...
 
 Kind regards,
 --Anselm
 Just adding my support.
 I have described my views on the multihead issue, but any kind of real
support will be really welcome. Dwm is still the best wm for me from all
the choices..
 Keep up the good work :)

Mate



Re: [dwm] dwm and dualhead

2008-12-11 Thread Mate Nagy
Hiho,
On Thu, Dec 11, 2008 at 09:39:19AM +0100, yy wrote:
 on this list and, if somebody finds a great _general_ solution (which
 seems difficult, but I would be love to be wrong), I'm sure Anselm
 would be glad to include it in the official release.
 Just my 2cts,
 I don't see anything difficult about this. In fact, awesome generally
gets this right. This is what I want from dwm:

 - handle each xrandr screen separately
including all data structures, so different layout, client set,
tagging, etc.
 - draw statusbar everywhere (from the same input text)
 - have a key-bindable function for:
- changing between screens
- move window to another screen
 - do something semi-intelligent when a screen with clients goes away,
e.g. put clients in previous/next screen oslt.

 Basically, it should behave as multiple separate dwms, except that
clients can be sent from screen to screen and all dwms have the same
configuration.

 Speculation: in this configuration, especially when changing between
screens, moving the mouse pointer to the location of the focus might be
more important/desirable. This might be a compile-time option or patch..

Mate



Re: [dwm] dwm and dualhead

2008-12-11 Thread Mate Nagy
On Thu, Dec 11, 2008 at 09:52:45AM +, Anselm R Garbe wrote:
 - have a dwm environment on each Xinerama screen (like multiple dwm's
 in classic multihead setups) as suggested by Mate
   - the problem was, it didn't felt right because it added another
 navigation layer on top of dwm, to basically navigate through screens
 and to move clients between screens, the conclusion was, if you really
 want this, run multiple instances of dwm with a classic multihead
 setup
 I use all my systems like this, where I can. The point is, that you
often *can't* do this any more, because bad driver support; also, not
being able to move windows between screens sucks sometimes.
 I would still prefer this solution.
 The extra navigation layer means next screen key and move client
to next screen key... not all that much. I would hazard that a majority
of multi-monitor users still use two monitors (laptop + external
monitor).
 - make layout algorithms use more screens (keep the bar at a specific
 main screen)
   - the problem was, that it doesn't scale well, most layout
 algorithms aren't designed for multihead setups, esp. if the screens
 have different geometries
 I don't see how this would be usable.. also, depending on automatic
tiling, clients jumping between screens would be a very confusing. The
previous approach keeps clients on the same screen until explicit wish
from the user.
 IMHO considering multi-monitor layout algorithms is just muddying
the issue and is not worth doing in practice.
 - split the tags into n distinct tagsets (1 for each screen) and use
 the existing tagging concept for focussing/moving clients between
 different screens using tagging, display the status bar on the screen
 with the focussed client (or some arbitrary fallback if there are no
 clients)
   - I think that was my favorit approach, so the main drawback was
 that it made dwm significantly more complex and that there needs to be
 some kind of setup option which tells which tag belongs to which
 screen, so the intermediate approach was having a tag struct with a
 screen index - but hell taht sucked
 I see this as basically the same as the first approach, differing only
in implementation details. I personally think just moving out all those
cute global variables into a screen struct, and passing a pointer
around, would be much more correct and elegant than hacking the tags.
 This solution also breaks when you assign a client to multiple screens.
 - use the screen with the pointer as default screen where the bar is
 presented and the layout algorithms happen, use all other screens for
 floating clients
   - this is the current approach
 Again personally, I really really don't like this :) It seems that if
we're stuck to using floating windows, then using a conventional window
manager with good xrandr support is more comfortable (my fallback
recently was the xfce wm for this - it was decent).
 Also, the main question remains, how many multihead users are there?
 The main argument for the last approach was, if there are only 10% of
 multihead users, why should all single head/laptop users suffer from
 the unnecessary complexity? dwm's current Xinerama support isn't worse
 than the Xinerama support in any major desktop environment, but it is
 not very smart compared to other tiling WMs.
 I would expect a lot of programmers use multihead.. and dwm isn't
precisely for the lowest common denominator user, is it.

Mate



Re: [dwm] dwm and dualhead

2008-12-10 Thread Mate Nagy
Hiho,
On Wed, Dec 10, 2008 at 06:05:23PM +0100, Johannes Wegener wrote:
 Hi,
 is there anybody who has experience with dwm and dualhead setups? I
 tried to use dwm with a xrandr dualhead but it seemed quite useless becouse I
 could just drag floating windows into the second screen. Xinerama seems
 people on this list seemed to have convinced themselves that this is a
good thing to do in any way or form. (It's not.)
 no more supported by xorg 7.4 and the intel driver.
 I just ran into this about a week ago. Dammit.
 So my question are do you plan to put xrandr support into dwm? or has
 anybody a hack/workaround for that problem?
 It's called 'awesome', a fork of dwm that has proper xrandr support...
and drops every other advantage of dwm, has completely ridiculous
dependencies (including nonstandard make), theme support and ugly
graphics all over the place.

Mate



Re: [dwm] dwm and dualhead

2008-12-10 Thread Mate Nagy
Hiho,
On Wed, Dec 10, 2008 at 05:37:14PM +, Anselm R Garbe wrote:
 2008/12/10 Johannes Wegener [EMAIL PROTECTED]:
  Hi,
  is there anybody who has experience with dwm and dualhead setups? I
  tried to use dwm with a xrandr dualhead but it seemed quite useless becouse 
  I
  could just drag floating windows into the second screen. Xinerama seems
  no more supported by xorg 7.4 and the intel driver.
 
  So my question are do you plan to put xrandr support into dwm? or has
  anybody a hack/workaround for that problem?
 
 Seems that XRandR support in dwm is becoming a requirement soon, 
 unfortunately.
 well, yes :) - but at least for me, Xinerama not being supported by
xorg 7.4 and the intel driver didn't mean dropped support - it means
that in dual screen configurations, X craps itself with copious kernel
output. I didn't think that this might be intentional.. since the intel
driver could never be called stable.

 In shared FB mode, it works - with severely disabled acceleration,
which touches the other recently mentioned issue with window movement
(unprocessed motion events piled up in the buffer). Incidentally,
grabbing the server didn't solve this for me - even moving around the
static window bitmap was too slow... I inserted a hack that throws out
surplus motion events before processing the last one, and this works.

 The lesson I learnt from this: I will never buy a laptop with integrated
intel graphics again.

Mate



Re: [dwm] dwm and dualhead

2008-12-10 Thread Mate Nagy
On Wed, Dec 10, 2008 at 06:36:12PM +, Anselm R Garbe wrote:
   The lesson I learnt from this: I will never buy a laptop with integrated
  intel graphics again.
 
 Which laptop model is to blame? ;)
 Lenovo 3000 V100. Especially painful is that otherwise I love this one
- great keyboard, good screen, light weight, good form factor, etc.

(There is still no linux support for the webcam and the fingerprint
reader, but I don't care about those...)

Mate



Re: [dwm] dwm-5.3

2008-12-04 Thread Mate Nagy
Greetings,
 option which allows to set use server grabs during mouse based
 resizals/movements.
 now i'm using a computer where this is again an issue, except much more
so, and not only with GL windows (big shared framebuffer mode with intel
945gm). I tried hacking server grabs into dwm 5.2 myself previously, but
that didn't help (even without redrawing, the repositioning of the
window is slow enough).
 However, ignoring all MotionNotifys until the last one in the queue
does help (using XCheckMaskEvent).
 Strangely, this doesn't seem to be such an issue with resizing; only
window moving is (very) slow.

Mate



Re: [dwm] OT : suckless foreign function interface

2008-11-14 Thread Mate Nagy
Greetings,
 1. Generate small C programs and call them via system() inside the
 scheme interpreter.
 well, if speed is a non-issue...
 ...
 how about dlopen/dlsym? that's pretty simple and rather usual. Callable
C functions should export a standard API (like the builtins in your
interpreter?), you designate an initialization function that registers
these in the namespace, and you're set.

 As for writing a custom ffi, how about looking at libffi or gnu
lightning instead?

Regards,
 Mate



Re: [dwm] slowness in moving windows OR vlc/mplayer crash

2008-09-09 Thread Mate Nagy
Greetings,
 I really need the redraw to manage gimp windows, sometimes I just have
 to see what they are doing to know the size I want, I have the same
 problem with image viewers, openoffice, etc, but if the server grab
 solution is simpler I won't matter maintaining a patch for that, maybe
 a patch where you can define in rules if you want incremental resizes
 for a given window class or something...
 BTW, I think 5.2 will be a great release (and I haven't had any
 problems with mplayer so far).
 
 Greets,
 I know it's bloat, but maybe there could be a toggle setting between
the present mechanism and xor-rectangles.

Regards,
 Mate



Re: [dwm] Asustek EEE PC 1000 Atom 1GB 40G SSD Linux Black

2008-09-05 Thread Mate Nagy
Greetings,
On Fri, Sep 05, 2008 at 10:28:28AM +0100, Anselm R Garbe wrote:
 What do people think about such an EEE PC as low budget option to run
 dwm on? Any experiences already if the screen is big enough for daily
 work? I had an opportunity yesterday to try one, and I must admit I'm
 keen to order one. The keyboard and keys have surprisingly proper
 size.
 I have been using dwm on my eee for like 9 months. It's not a
possibility as such, but a necessity to make the eee usable at all
(fishing around with a conventional wm with that touchpad is hell).
I use the monocle layout.

 The keyboard is pretty good, but the screen is rather small for daily
work imho. I have done some programming on the eee when I had to, but I
wouldn't take it instead of my 24 tft and unicomp buckling spring
keyboard...

 The builtin linux is usable on the short run, but kind of annoying if
you really want to use it. Debian 4.0 stable distros work with apt,
kinda (it will break the builtin firefox, you have to use iceweasel
instead).

 If you're willing to give up the quick boot time, I'd recommend
installing your own OS. This will also gain you quite a lot of extra
storage space, since the builtin xandros has its default image on a big
partition, and stores user stuff and changes by unionfs.. With this,
it's possible to quickly reset the factory configuration (by the F9
bootup menu), but you can't remove packages (kde trash) to gain space.

Regards,
 Mate



[dwm] window move lag

2008-09-05 Thread Mate Nagy
Hulloh,
 let's say that I have a number of floating windows running complicated
OpenGL applications. When I move them around (by mod+mouse1 drag),
moving the window each step takes some time. This time is larger than
the frequency at which dwm gets mousemotions, thus the movement lags
behind the mouse.
 This is rather annoying :) (It also applies to resizing.)
 Would it be easily possible to skip superfluous mousemotions when
they're received in one bunch?
 The lag effect is noticable for me when I run two concurrent floating
glxgears instances (otherwise, the 'complicated application' is the
FlightGear flight sim in my case).

Regards,
 Mate



Re: [dwm] window move lag

2008-09-05 Thread Mate Nagy
 Actually, I quite like the old styled XOR-outline method. I may not be
 as pretty, but it's definitely useful for various applications that take
 ages to resize their windows.
 I also like the XOR outline. I even think it's prettier ;)

Mate



Re: [dwm] what about 'st'?

2008-09-05 Thread Mate Nagy
 My display looked like a farmland some time ago. I just had key
 bindings in dwm to open xterms with a given background color in a
 given screen window.
 
 It looked like this:
 http://y-i-y-u-s.deviantart.com/art/dwm-4-4-1-65928966
 This is the most horrifying thing I have ever seen.



 Awesome.


Mate



Re: [dwm] Coding styles

2008-07-31 Thread Mate Nagy
On Thu, Jul 31, 2008 at 01:37:22PM +0200, pancake wrote:
 I wrote a random list of tips for coding (mostly in C)
 
 http://news.nopcode.org/miau/wk/BadCoding
 
 If you have some ideas/missing tips i'm open for discussion :)
 I mostly agree with everything, except with your bizarre anger against
C99/gcc extension features that make C seem it wasn't as retarded and
low-level as it actually is.
 IMHO:
 - nested functions? very good, use them (they can help a lot by moving
your programming into a slightly functional direction, supporting code
reuse)
 - nested braces for localizing scope? good, use them
   (with the exception that they sometimes tend to make you write longer
functions instead of separating code to multiple smaller functions,
which would be better)

 (ideally, everybody should use something modern instead of C (like
Haskell (which I don't actually really know, so don't attack me :)),
 but that's not going to happen. Oh, and Lisp, of course. This is 2008,
people, there are plenty of languages that can be compiled to be fast,
and actually have *features*. Like generics, type systems, macro
systems, omg.
 Btw, we are recently looking into Kaya (kayalang.org). It's yet very
young, but looks quite promising.)

Regards,
 Mate



Re: [dwm] suckless wiki gopher

2008-07-31 Thread Mate Nagy
hiya,
 A while ago there was some talk about making the wiki available in 
 gopherspace.
 I made a quick mockup: gopher://schot.a-eskwadraat.nl/1/suckless
 The idea is pretty simple: No conversion to html and embed the index.md page 
 in
 the gophermenu (yes, 'i' itemtype abuse).   
 very nice

-Mate



Re: [dwm] Being not so elitist

2008-07-29 Thread Mate Nagy
Greetings,
   This keeps its userbase small and elitist. No novices asking stupid
   questions.
 i wholeheartedly support these words.
 Please discuss about removing, or altering that.
 The reason is, that I met people who thought, that the dwm-/suckless-
 community is arrogant. They refered to these sentences.
 fuck 'em

Regards,
 Mate



Re: [dwm] Being not so elitist

2008-07-29 Thread Mate Nagy
Hello,
 We are publishing a software for the masses: we make it available and
 have a website for it, a mailing list, a wiki, and a mercurial
 repository.
 There is nothing elitist about that.
 The fact that we have to modify the source to customise the product is
 IMHO, you're staggeringly wrong, good sir.
 I think dwm doesn't make *sense* if you can't edit the source and paste
together your favorite layouts/config to create your own personalized
WM. dwm can't ever be a packaged product ready for mass consumption - if
it is, it will be a different window manager, and we'll have to abandon
it and move on. Then a few years later someone will reinvent the wheel
and say let's finally write a minimalist WM!
 Without a configuration GUI, window decorations, pagers and whizbang,
dwm is irrevocably elitist, and at least I would like it to stay that
way.

Regards,
 Mate



Re: [dwm] Being not so elitist

2008-07-29 Thread Mate Nagy
 I would like to propose adding xft support and gnome systray support to dwm.
 And also sound effects.
 Neat idea. Also, someone could write a config editor that patched the
binary (like what Dehacked did to the old DOS DOOM).

M.



Re: [dwm] dwm-5.1 / dmenu-3.8 / sic-1.0 / slock-0.9 / sselp-0.2

2008-07-29 Thread Mate Nagy
Hello,
 Just because I'm curious: Am I the only one using readline (shell, etc.)
 with Emacs key bindings and am therefore always remapping/deleting some
 default dwm key bindings?
 
 Or is everyone using readline in vi mode?
 we're using Mod4 as modkey.

M.



Re: [dwm] Status text clock patch

2008-07-10 Thread Mate Nagy
Hulloh,
On Thu, Jul 10, 2008 at 06:35:03PM +0300, John Mpanos wrote:
 After some digging around i figured what to do to draw text in the
 status area, so i wrote a simple clock using threads. I can't
 understand though why the clock doesn't get updated sometimes even
 though i call drawbar() directly from the thread run method...
 Any help would be appreciated, and also how could i do the same
 without using threads?
 so, why exactly aren't you using an external program feeding in data?
 (The shell repeatedly calling date might be slow, but a .c printing the
date through the pipe won't be significantly slower...)

Mate



Re: [dwm] snapping bugs with multiple screens

2008-05-05 Thread Mate Nagy
On Mon, May 05, 2008 at 09:06:54PM +0200, Antoni Grzymala wrote:
 I've found running separate dwm instances on subdisplays entirely
 sufficient for my multihead needs. I don't even have time and will to
 try and comprehend all the new DEFGEOM stuff (and neither I see a
 reason).
 
 Hence I vote -1 for all post 1122 releases.

agree completely (not using +1 notation to avoid confusion).

I'm still using two/more instances of 4.7 everywhere. Imho, the only
clean way of directly supporting multihead would be to put everything
currently in globals into a struct, and run multiple instances of the WM
in separate data structures, with a few well-defined crossing points
(such as: move client to the list of another screen)

Regards,
 Mate