Re: [dev] [dwm] Weird behavior of Java programs
On Mon, 9 Sep 2013 16:31:13 -0400 Louis-Guillaume Gagnon wrote: > Simple case of RTMF: the issue is explained in dwm's man page. You say it, it may be where I remembered it from in the first place. So I am corrupted by online manpages as well… signature.asc Description: PGP signature
Re: [dev] daemon for DWM
On Thu, 27 Jun 2013 02:51:46 +0200, Viola Zoltán wrote: Compile it with this command: g++ -funsigned-char -funsigned-bitfields -Wall -Wno-long-long -Wunused -Wextra -pedantic -lX11 kajjam.cpp -o kajjam Why g++? It works fine as gcc -Wall -Wextra -std=c99 -pedantic kajjam.c -o kajjam -lX11 Some other comments: Rather weird indentation style, I personally find it quit hard to read. Non-english comments. I think it's discouraged in an international community like this. Greetings, flo
[dev] C talk
Greetings list, I think about giving a short talk about C and why to use it on a small student event at my local university this weekend. Does anybody have pointers to some stuff like that? Thanks, flo
Re: [dev] smessage
Greetings list, On Thu, 23 Feb 2012 09:13:07 +0100, Michael Stummvoll wrote: An operation Mode without any Buttons where the Window closes itselfs after x seconds would be also great I think. Than somebody could use smessage also for displaying popup-infos whithin a desktop environment for example. As mentioned before, the closing timer should be implemented in a separate script, but how is the consensus about duplicating functionality? The button handling of original xmessage might be provided by Christoph's thingmenu, so is it reasonable to implement it again for smessage or should the functionality kept separated? -flo
Re: [dev] smessage
Hi Michael, On 23.02.2012 09:13, Michael Stummvoll wrote: > Also when i resize a window > (make it bigger) its not redrawn correctly for me. I've looked into this, but wasn't able to reproduce this. I've found and fixed another error, which occured when it is shrinked to a width below one character width + 2 * margins. The only way I can think of is that you use a font, which width is not 8. Since I've not yet figured out an elegant way how to determine the (average and/or actual) glyph width in X, it's hardcoded by now, so you can try to change the 8 at the end of the line smessage.c:458 to the width of your fixed font. If you use a proportinal font, I have no solution at the moment. -flo
Re: [dev] smessage
Hi Bartosz, On 23.02.2012 13:30, Bartosz Pranczke wrote: > I have a warning preventing this from compile. > > cc -Wall -Wextra -Werror -std=c99 -pedantic -I/usr/X11R6/include > -D_BSD_SOURCE -D_POSIX_C_SOURCE=2 -DNAME=\"smessage\" > -DVERSION=\"ALPHA\" -c smessage.c > smessage.c: In function ‘handlekey’: > smessage.c:568:2: error: ‘XKeycodeToKeysym’ is deprecated (declared at > /usr/include/X11/Xlib.h:1695) [-Werror=deprecated-declarations] Delete -Werror to make it compile anyway, but this warning is new to me. And honestly, I don't think it makes sense, since if the want you to use XKB, you won't be using Xlib anyway. But it clearly shows that i should make a release option in the makefile, which is not that picky. Out of couriousity, what system do you use? I hacked on slackware, where I didn't got that warning. -flo
Re: [dev] smessage
Hi Aurélien, On 23.02.2012 13:06, Aurélien Aptel wrote: > Nice code. Thanks. > If you want to replace xmessage, you should make text scrollable and selectable. Thats actually quite at the top on my to do list. -flo
Re: [dev] smessage
Hi Michael, On 23.02.2012 09:13, Michael Stummvoll wrote: > nice Tool, but you should make thinks like the font or colors > configurable (excluded in a config.h). personally I don't like nested includes much, but if it's general consent that it is the preferred way, I'll change it. At the moment, nesting is not necessary anyway. > Also when i resize a window > (make it bigger) its not redrawn correctly for me. The redrawing costed me a night and I thought it would work, but I'll look into it. I just are short an time at the moment. > An operation Mode without any Buttons where the Window closes itselfs > after x seconds would be also great I think. Than somebody could use > smessage also for displaying popup-infos whithin a desktop environment > for example. Thats a nice idea, I think it would be great with the (not yet implemented) function to force geometry. -flo
Re: [dev] regarding surf and cookie handling
Hello, On 22.02.2012 16:35, Troels Henriksen wrote: Yes, inotify would be the mechanism by which file changes are discovered, although it's not portable. I'm not certain what the Suckless Zeitgeist is on using Linux-only facilities. AFAIK there are some *BSD users who also use suckless tools. So don't let us become GNOMEy. -flo
Re: [dev] smessage
On Tue, 21 Feb 2012 11:55:20 +0100, Florian Limberger wrote: Greetings list, I have hacked up a simple xmessage replacement which looks neater, has dmenu-like handling and supports unicode. And I am obviously too tired to write mails. Code now attached. -flo smessage.tar.bz2 Description: BZip2 compressed data
[dev] smessage
Greetings list, I have hacked up a simple xmessage replacement which looks neater, has dmenu-like handling and supports unicode. Since this is my first real project, I appreciate serious criticism of the code. Thanks go out to Christoph Lohmann for svkb/thingmenu, which inspired various pieces of code. I do not consider the program finished yet, just grep for TODO to see what I mean. -flo
Re: [dev] One Border is Not Enough
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?
Re: [dev] One Border is Not Enough
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 colorscheme, for example my active border is #ff9900, which is very unlikely to be the background color of any window. And I think most dwm users manage mostly terminals, which all have the same background color. Greetings, flo
Re: [dev] [wmii] widgets with graphics?
On Thu, 22 Dec 2011 20:34:12 -0500, Kurt H Maier wrote: A one-letter prefix doesn't help you? b50% s70%? I don't even do that much. I used to just have it read, e.g., 50% 70% and I used my amazing pattern-recognition skills to discern that the battery life was mysteriously always first in that list! Now I let my battery LED turn orange to remind me to plug in (I can run a script in a terminal if I care about exact percentage) and I just report my current essid. I know what you are displaying, I use a slightly modified version of the status.sh script you posted once. Thanks though. I don't find cartoons more usable than information. I don't, along the same lines, give a shit what the rest of the world thinks. The rest of the world has chosen an interface. They're free to wallow in it while I use something more effective. I know you are an ignorant bastard and therefore I don't give a shit about your opinion of the rest of the world, but not everybody is like that and the mail was addressed at them.
Re: [dev] [wmii] widgets with graphics?
I just looked at the screenshot linked by the OP, and thats indeed wrong usage of icons, IMHO. I argued againts the wifi signal example, not for replacing descriptive names of applications with crappy logos without any expressivenes. How the fuck can a wolf represent an audio application? At least most people are trained to recognize the wifi antenna symbol or a battery, not least from using cellphones. Greetings, flo
Re: [dev] [wmii] widgets with graphics?
Hello, The general consensus is that sprinkling icons everywhere actually makes the interface far more complicated and distracting, and generally quite *bad*. While there *are* some exceptions where icons are more compact, they are rare. Consider the meter widgets people are obsessed with putting on their status bars to tell you, say, the quality of your wifi signal. In 12 horizontal pixels you can very comfortably fit in two digits, which would tell you the signal as a percentage. The same number of pixels would, as a meter, offer only an tenth of the information, and it would be far more difficult to distinguish 80% from 70%. Yes, text is quite a concise medium. then how do you distinguish the percentage of battery load and the percentage of wifi signal strength? Sometimes, I don't care if wifi signal quality is exactly 87% or 78%, It would suffice if I knew if it is over 25%, 50% or 75% ... Plus, I don't have to think about if I'm looking at my battery or my wifi status, thats something where pictures are a little bit better. If I denote the textual percentage with letters, it would cost me some pixels too, so I think thats a rather weak argument. But if you are paving the whole UI with icons, it gets confusing, but same applies to textual information, if you write a huge string with shitloads of information into your status bar, it would be confusing too. So I think, minimalism is the most important design goal, wether using icons or text to display information. But for a project like dwm, whose focus lies on a simple implementation, icons would be simply to complicated to include. By the way, I think the "general consensus" applies only to this mailing list, the rest of the world (sane or not) believes in some usability bonus. Greetings, flo
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, 22 Oct 2011 09:35:00 +0100, Connor Lane Smith wrote: [...] So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic "à la carte" (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. I know, Unix purists will rage about this added complexity. And it's true, it would be rather more complex. But in my opinion we ought to optimise for effectiveness of use by the user, not efficiency of execution by the machine: we should look at where we want to go and determine the simplest way of getting there, not succumb to nihilism because "it's simpler to stay where we are." [...] Are you talking about Windows PowerShell? It's even object oriented!111 SCNR flo
