Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread hiro
> I once envisioned a Plugin to directly go to "Print Views" of websites,
> since they tend to have considerably less suck on them.

I used to do the same thing, also I processed these pages with a few
scripts and htmlfmt. But then these clever web site operators stopped
serving specially cleansed pages and the "print" link is now generally
just a java script selecting an other CSS layout. So we are pretty
much left alone with a huge pile of junk in every html file today.

Also -- HTML embedded base64 encoded images every two or three lines
(for the 30 twitter symbols).
Fuck HTML5



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Paul Tan
cting an other CSS layout. So we are pretty
much left alone with a huge pile of junk in every html file today.

Also -- HTML embedded base64 encoded images every two or three lines
(for the 30 twitter symbols).
Fuck HTML5






Re: [dev] herbstluftwm

2011-11-02 Thread hiro
Yeah, lets all learn how to use all the X protocols.



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread stanio
* hiro <23h...@googlemail.com> [2011-11-02 10:11]:
> > I once envisioned a Plugin to directly go to "Print Views" of websites,
> > since they tend to have considerably less suck on them.
> 
> I used to do the same thing, also I processed these pages with a few
> scripts and htmlfmt.

Do you mean, you plug somehow a script in surf (or whatever), before it
renders the page? How?

Or you process them for offline reading, printing, etc., losing links?

I find myself very often spawn a w3m or lynx when I encounter lengthly
content worth reading, with one of those 3+ columns layout, without
print version, which, to make it more ridiculous, are defined with
static width of left and right columns, so that zooming just makes it
worse.

This doesn't help when there are meaningful images, e.g. formulas, in
the text, though.

cheers,
-- 
 stanio_



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread hiro
No. I try to use hget+sed+htmlfmt for Offline reading and synchronising,
but like you said images are no fun in text only formats. So ive also
played around with cleaned html in rss and mails, but stuff just doesnt
feel right.
Searching for solutions...
Am 02.11.2011 10:45 schrieb :

> * hiro <23h...@googlemail.com> [2011-11-02 10:11]:
> > > I once envisioned a Plugin to directly go to "Print Views" of websites,
> > > since they tend to have considerably less suck on them.
> >
> > I used to do the same thing, also I processed these pages with a few
> > scripts and htmlfmt.
>
> Do you mean, you plug somehow a script in surf (or whatever), before it
> renders the page? How?
>
> Or you process them for offline reading, printing, etc., losing links?
>
> I find myself very often spawn a w3m or lynx when I encounter lengthly
> content worth reading, with one of those 3+ columns layout, without
> print version, which, to make it more ridiculous, are defined with
> static width of left and right columns, so that zooming just makes it
> worse.
>
> This doesn't help when there are meaningful images, e.g. formulas, in
> the text, though.
>
> cheers,
> --
>  stanio_
>
>


Re: [dev] Re: [dwm] A general approach to master-slave layouts

2011-11-02 Thread lolilolicon
I believe every master-slave layout, i.e., layouts where mfact/nmaster
make sense, should own its own mfact/nmaster value, not to be disturbed
by other layouts.  As said before, `col' and `tile' for example just
can't share the same mfact and still both look good.

Consequently, I decided to update the patch so mfact and nmaster are now
monitor- and layout-specific.  This should make the master-slave layouts
play nice with each other and thus make the idea more complete.

Also, the nice thing about this approach is that the config.h interface
is left unchanged.  mfact and nmaster values of each layout are
initialized to the global value mfact and nmaster; the user can also
implement layouts that force rules on mfact and nmaster if desired.

diff -r 904e923827cb -r 983f8ffd9f7c config.def.h
--- a/config.def.h  Mon Oct 31 20:09:27 2011 +0100
+++ b/config.def.h  Wed Nov 02 20:15:22 2011 +0800
@@ -32,6 +32,8 @@
{ "[]=",  tile },/* first entry is default */
{ "><>",  NULL },/* no layout function means floating behavior 
*/
{ "[M]",  monocle },
+   { "TTT",  bstack },
+   { "|||",  col },
 };

 /* key definitions */
@@ -66,6 +68,8 @@
{ MODKEY,   XK_t,  setlayout,  {.v =
&layouts[0]} },
{ MODKEY,   XK_f,  setlayout,  {.v =
&layouts[1]} },
{ MODKEY,   XK_m,  setlayout,  {.v =
&layouts[2]} },
+   { MODKEY,   XK_s,  setlayout,  {.v =
&layouts[3]} },
+   { MODKEY,   XK_c,  setlayout,  {.v =
&layouts[4]} },
{ MODKEY,   XK_space,  setlayout,  {0} },
{ MODKEY|ShiftMask, XK_space,  togglefloating, {0} },
{ MODKEY,   XK_0,  view,   {.ui = ~0 } 
},
diff -r 904e923827cb -r 983f8ffd9f7c dwm.c
--- a/dwm.c Mon Oct 31 20:09:27 2011 +0100
+++ b/dwm.c Wed Nov 02 20:15:22 2011 +0800
@@ -122,26 +122,9 @@
void (*arrange)(Monitor *);
 } Layout;

-struct Monitor {
-   char ltsymbol[16];
-   float mfact;
-   int nmaster;
-   int num;
-   int by;   /* bar geometry */
-   int mx, my, mw, mh;   /* screen size */
-   int wx, wy, ww, wh;   /* window area  */
-   unsigned int seltags;
-   unsigned int sellt;
-   unsigned int tagset[2];
-   Bool showbar;
-   Bool topbar;
-   Client *clients;
-   Client *sel;
-   Client *stack;
-   Monitor *next;
-   Window barwin;
-   const Layout *lt[2];
-};
+typedef struct {
+   int x, y, w, h;
+} Rect;

 typedef struct {
const char *class;
@@ -153,18 +136,23 @@
 } Rule;

 /* function declarations */
+static void apply_mslts(Monitor *m, Bool hsplit,
+   void (*mltf)(Client **, Rect *, unsigned int),  /* master 
layout function */
+   void (*sltf)(Client **, Rect *, unsigned int)); /* slave layout 
function */
 static void applyrules(Client *c);
 static Bool applysizehints(Client *c, int *x, int *y, int *w, int *h,
Bool interact);
 static void arrange(Monitor *m);
 static void arrangemon(Monitor *m);
 static void attach(Client *c);
 static void attachstack(Client *c);
+static void bstack(Monitor *);
 static void buttonpress(XEvent *e);
 static void checkotherwm(void);
 static void cleanup(void);
 static void cleanupmon(Monitor *mon);
 static void clearurgent(Client *c);
 static void clientmessage(XEvent *e);
+static void col(Monitor *);
 static void configure(Client *c);
 static void configurenotify(XEvent *e);
 static void configurerequest(XEvent *e);
@@ -185,6 +173,7 @@
 static void focusmon(const Arg *arg);
 static void focusstack(const Arg *arg);
 static unsigned long getcolor(const char *colstr);
+static unsigned int getlayoutindex(const Layout *lt);
 static Bool getrootptr(int *x, int *y);
 static long getstate(Window w);
 static Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
@@ -194,6 +183,8 @@
 static void initfont(const char *fontstr);
 static void keypress(XEvent *e);
 static void killclient(const Arg *arg);
+static void lt_hstack(Client **c, Rect *r, unsigned int n);
+static void lt_vstack(Client **c, Rect *r, unsigned int n);
 static void manage(Window w, XWindowAttributes *wa);
 static void mappingnotify(XEvent *e);
 static void maprequest(XEvent *e);
@@ -281,11 +272,92 @@
 /* configuration, allows nested code to access above variables */
 #include "config.h"

+struct Monitor {
+   char ltsymbol[16];
+   float mfact[LENGTH(layouts)];
+   int nmaster[LENGTH(layouts)];
+   int num;
+   int by;   /* bar geometry */
+   int mx, my, mw, mh;   /* screen size */
+   int wx, wy, ww, wh;   /* window area  */
+   unsigned int seltags;
+   unsigned int sellt;
+   unsigned int tagset[2];
+   Bool showbar;
+   Bool topbar;
+   Client *clients;
+   Client *sel;

[dev] [dmenu] weird arrows behaviour

2011-11-02 Thread Swiatoslaw Gal
Left (back) arrow works in dmenu well.  Right (forward) does not do anything.
Is it a bug or feature?

Cordially,
s.



Re: [dev] [dmenu] weird arrows behaviour

2011-11-02 Thread Manolo Martínez
On 11/02/11 at 01:52pm, Swiatoslaw Gal wrote:
> Left (back) arrow works in dmenu well.  Right (forward) does not do anything.
> Is it a bug or feature?
> 
It works here.
Manolo
-- 



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Bjartur Thorlacius
> * hiro <23h...@googlemail.com> [2011-11-02 10:11]:
> > > I once envisioned a Plugin to directly go to "Print Views" of
> > > websites,
> > > since they tend to have considerably less suck on them.
> >
I used to use mobile version of some websites, but as handheld
computer bloat up, so do websites. I honestly hope that HTML5 will
finally allow us to drop CSS support. The hope is weak.



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Andreas Krennmair

* Bjartur Thorlacius  [2011-11-02 16:00]:

* hiro <23h...@googlemail.com> [2011-11-02 10:11]:
> > I once envisioned a Plugin to directly go to "Print Views" of
> > websites,
> > since they tend to have considerably less suck on them.
>

I used to use mobile version of some websites, but as handheld
computer bloat up, so do websites. I honestly hope that HTML5 will
finally allow us to drop CSS support. The hope is weak.


On the contrary, HTML5 goes the way of bringing markup to a more abstract, 
semantic way (with a plethora of new tags such as ,  and 
many more), and for this semantic markup the layout is defined purely via CSS.


Another core concept that plays into this is "progressive enhancement", which 
states that the basic content can be downloaded and displayed in a simple yet 
readable manner by only presenting the content itself (w/o images, CSS, or 
JS), and that externally linked CSS and unobtrusive JavaScript "enhance" a 
page if they are supported and enabled in the web browser, but of course, the 
page/web application shall work correctly even without e.g. JavaScript enabled 
(or even supported).


-Andreas



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Kurt H Maier
On Wed, Nov 2, 2011 at 11:14 AM, Andreas Krennmair  wrote:
> Another core concept that plays into this is "progressive enhancement",
> which states that the basic content can be downloaded and displayed in a
> simple yet readable manner by only presenting the content itself (w/o
> images, CSS, or JS), and that externally linked CSS and unobtrusive
> JavaScript "enhance" a page if they are supported and enabled in the web
> browser, but of course, the page/web application shall work correctly even
> without e.g. JavaScript enabled (or even supported).

web idiots have been spouting such bullshit since the 'graceful
degradation' days of html4.  it's never come true, and it never will,
because the "standards" put forth are anything but.  what you are
talking about is the web version of "the check is in the mail" and
"it's not what it looks like"


-- 
# Kurt H Maier



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Andreas Krennmair

* Kurt H Maier  [2011-11-02 16:40]:

web idiots have been spouting such bullshit since the 'graceful
degradation' days of html4.  it's never come true, and it never will,
because the "standards" put forth are anything but.  what you are
talking about is the web version of "the check is in the mail" and
"it's not what it looks like"


I think you are mistaken. Graceful degradation is a different approach. 
And progressive enhancement has already become true. Much of the whole HTML5 
hype is BS, but it has been shown that it isn't too difficult to develop 
web applications that are functional on a vast range of clients, from lynx to 
smartphones and tablets to full-brown browsers.


-Andreas



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread stanio
* hiro <23h...@googlemail.com> [2011-11-02 13:21]:
> No. I try to use hget+sed+htmlfmt for Offline reading and synchronising,
> [..]
> Searching for solutions...

best compromise I found was w3m which has a decent way to spawn external
"browsers", which I misuse for flash or other evil stuff which I have to
deal with.

For pages which you are familiar with what content to expect where, it
is ok. For those you are not -- you may miss arbitrarily many
information, and that's not fun indeed. 

Luckily, I *am* familiar with the most pages I visit, and they don't
change much. This allows for non-interactive (what I meant by offline
before) browsing: I have shell aliases for scripts for dictionary querys
which cut some pages before and some after the *real* content, and it
works surprisingly well for years with some (e.g. leo.org), but need
quite often changes with others.

My point is, sometimes it is worth having several simple solutions on
page basis. While it is not that elegant, if you use them often, they
save you a lot of headaches.

-- 
 stanio_



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread stanio
* Bjartur Thorlacius  [2011-11-02 15:55]:
> I used to use mobile version of some websites, but as handheld
> computer bloat up, so do websites. 

Sadly yes. Another problem there is that they try to be smarter than the
client by offering some buttons to hide and show content, rather than
just showing everything. 

Print versions, where they exist, are the sanest solution in my
experience. Wikipedia is a nice example. I have a bookmark, which sends
me directly there. Not perfect though, because links point to
non-printable versions of the article. Shame.

-- 
 stanio_



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread stanio
* Andreas Krennmair  [2011-11-02 16:59]:
> * Kurt H Maier  [2011-11-02 16:40]:
> And progressive enhancement has already become true. Much
> of the whole HTML5 hype is BS, but it has been shown that it isn't
> too difficult to develop web applications that are functional on a
> vast range of clients, from lynx to smartphones and tablets to
> full-brown browsers.

developing sane web applications is possible for ages. If you put "from
lynx to full-blown browsers" into the definition of sane (which is
itself the only sane way) everithing is clear. Most folks don't seem to
think like that and trade usability and media support for bells and
whistles. 

-- 
 stanio_



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Kurt H Maier
On Wed, Nov 2, 2011 at 1:14 PM,   wrote:
> developing sane web applications is possible for ages. If you put "from
> lynx to full-blown browsers" into the definition of sane (which is
> itself the only sane way) everithing is clear. Most folks don't seem to
> think like that and trade usability and media support for bells and
> whistles.

the fact that such a trade is possible at all is proof of how
backwards and helpless web 'standards' are.

-- 
# Kurt H Maier



Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Stephen Paul Weber

Somebody claiming to be Kurt H Maier wrote:

web idiots have been spouting such bullshit since the 'graceful
degradation' days of html4.  it's never come true, and it never will,
because the "standards" put forth are anything but.  what you are
talking about is the web version of "the check is in the mail" and
"it's not what it looks like"


While there is great reason to be pessemistic, in the end the situation is 
no different than in any other maker/coder/creator field: the tools to make 
the web really quite good have been there for years, but most people writing 
the pages are not motivated to make them suck less than the average, and so 
keep producing terrible  nests, etc, making all the nice stuff we're 
supposed to have a lot less useful.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature


Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Bjartur Thorlacius
On Wed, 02 Nov 2011 15:14:39 -, Andreas Krennmair   
wrote:
On the contrary, HTML5 goes the way of bringing markup to a more  
abstract, semantic way (with a plethora of new tags such as ,  
 and many more), and for this semantic markup the layout is  
defined purely via CSS.


Or the user agent (aka your browser). Furthermore, this will allow you to  
customize layout by configuring your user agent. Read: layouts that suck  
less. HTML tables are completely uncustomizable.




Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Bjartur Thorlacius

On Wed, 02 Nov 2011 17:05:17 -,  wrote:

Print versions, where they exist, are the sanest solution in my
experience. Wikipedia is a nice example. I have a bookmark, which sends
me directly there. Not perfect though, because links point to
non-printable versions of the article. Shame.

In that case you need to include a statement of your preferring  
non-interactive (and generally simple and sane) representations of  
resources in your requests for articles (as an HTTP header). Try sending a  
mail to Wikimedia and the WHATWG or the HTML WG of W3C.


Your requests should something like:
GET /wiki/Ragnarök_(software) HTTP/1.0
Host: en.wikipedia.org
Accept-Language: en
Accept-media: not interactive

Add paged and monochrome per taste. Such proposal would probably be  
answered by blaming Mediawiki's use of omnimedia stylesheets, instead of  
providing a stylesheet for each medium, and lack of semantic markup that  
can be styled by user agents (that don't give a shit how Wikimedia staff  
thinks Wikipedia content should be laid out).




[dev] [dwm] bugfix for multi monitor setup

2011-11-02 Thread Brian L Angus
Hello and thanks for the wonder that is dwm.

Below is a patch for issues I have found with 2 monitors where one
monitor is below another.

The issue can be found when moving a floating window that fills the
entire available area from one monitor to another.  (This is with a
borderpx of 0)

thanks,
Brian


Index: dwm.c
===
--- dwm.c
+++ dwm.c
@@ -338,18 +338,18 @@
*x = 0;
if(*y + *h + 2 * c->bw < 0)
*y = 0;
}
else {
-   if(*x > m->mx + m->mw)
-   *x = m->mx + m->mw - WIDTH(c);
-   if(*y > m->my + m->mh)
-   *y = m->my + m->mh - HEIGHT(c);
-   if(*x + *w + 2 * c->bw < m->mx)
-   *x = m->mx;
-   if(*y + *h + 2 * c->bw < m->my)
-   *y = m->my;
+   if(*x >= m->wx + m->ww)
+   *x = m->wx + m->ww - WIDTH(c);
+   if(*y >= m->wy + m->wh)
+   *y = m->wy + m->wh - HEIGHT(c);
+   if(*x + *w + 2 * c->bw <= m->wx)
+   *x = m->wx;
+   if(*y + *h + 2 * c->bw <= m->wy)
+   *y = m->wy;
}
if(*h < bh)
*h = bh;
if(*w < bh)
*w = bh;
@@ -1144,11 +1144,11 @@
c->x = c->mon->mx + c->mon->mw - WIDTH(c);
if(c->y + HEIGHT(c) > c->mon->my + c->mon->mh)
c->y = c->mon->my + c->mon->mh - HEIGHT(c);
c->x = MAX(c->x, c->mon->mx);
/* only fix client y-offset, if the client center might cover 
the bar */
-   c->y = MAX(c->y, ((c->mon->by == 0) && (c->x + (c->w / 2) >= 
c->mon->wx)
+   c->y = MAX(c->y, ((c->mon->by == c->mon->my) && (c->x + (c->w / 
2) >= c->mon->wx)
   && (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? 
bh : c->mon->my);
c->bw = borderpx;
}
wc.border_width = c->bw;
XConfigureWindow(dpy, w, CWBorderWidth, &wc);




Re: [dev] [dwm] 2000 SLOC

2011-11-02 Thread Kurt H Maier
On Wed, Nov 2, 2011 at 4:28 PM, Bjartur Thorlacius  wrote:
> Or the user agent (aka your browser). Furthermore, this will allow you to
> customize layout by configuring your user agent. Read: layouts that suck
> less. HTML tables are completely uncustomizable.

No it won't, because people will continue to use , ,
and everything else exactly the way they use  now.  Web designers
are basically graphics people, and they couldn't possibly give less of
a fuck how the user wants things laid out.  And they never will.
They'll continue to do user-agent-based dispatch and present
completely different versions of shit to different clients, in the
interest of controlling as much of the display as possible, and when
faced with a client that doesn't want their bullshit, you'll get a
broken site.  As usual.


-- 
# Kurt H Maier



[dev] wmii + ruby 1.9.3 = no power woes!

2011-11-02 Thread Suraj N. Kurapati
Hello,

For those who were weary of my Ruby wmiirc[1]'s power consumption,
I am happy to announce that the latest Ruby 1.9.3-p0 stable release
has solved Ruby's problem of causing excessive CPU wakeups-from-idle
which would drain your laptop battery much sooner than you'd expect.

On my ASUS UL30A-A2 laptop running Arch Linux, powertop[2] shows
that Ruby 1.9.3-p0 causes around 2 CPU wakeups-from-idle per second.

Top causes for wakeups:
  28.8% ( 47.0)   [hda_intel] 
  14.6% ( 23.9)   [kernel scheduler] Load balancing tick
  11.9% ( 19.4)   [ath9k] 
  11.8% ( 19.3)   kworker/0:0
   8.0% ( 13.1)   [kernel core] hrtimer_start (tick_sched_timer)
   6.1% ( 10.0)   kworker/u:3
   3.1% (  5.0)   syndaemon
   2.8% (  4.6)   [acpi] 
   2.5% (  4.0)   [kernel core] usb_hcd_poll_rh_status (rh_timer_func)
   1.5% (  2.5)   wmii
   1.3% (  2.1)   liferea
   1.2% (  2.0)   kworker/u:2
   1.2% (  1.9)   ruby
   1.0% (  1.7)   X
   0.7% (  1.2)   ario
   0.6% (  1.0)   [kernel core] tpt_trig_timer (tpt_trig_timer)
   0.6% (  1.0)   ntpd
   0.3% (  0.5)   [ahci] 
   0.3% (  0.5)   watchdog/0

So leave your power woes behind and enjoy wmii with Ruby today! :-)

[1]: https://github.com/sunaku/wmiirc#readme
[2]: http://www.lesswatts.org/projects/powertop/

-- 
I have often regretted my speech, never my silence.
-- Publilius Syrus


signature.asc
Description: PGP signature


Re: [dev] wmii + ruby 1.9.3 = no power woes!

2011-11-02 Thread Kurt H Maier
Anselm,

Any word on a timetable for disowning wmii?  This is a four-hundred
line configuration that requires a 1600-line library, not to mention
an entire extra programming language.

To manage x11 windows.

-- 
# Kurt H Maier



Re: [dev] wmii + ruby 1.9.3 = no power woes!

2011-11-02 Thread Brad Ediger
On Wed, Nov 2, 2011 at 7:49 PM, Suraj N. Kurapati  wrote:
> Hello,
>
> For those who were weary of my Ruby wmiirc[1]'s power consumption,
> I am happy to announce that the latest Ruby 1.9.3-p0 stable release
> has solved Ruby's problem of causing excessive CPU wakeups-from-idle

Indeed it has. I had been looking for a solution for this; thanks for the tip!

-be



Re: [dev] wmii + ruby 1.9.3 = no power woes!

2011-11-02 Thread Jeffrey 'jf' Lim
On Thu, Nov 3, 2011 at 9:23 AM, Kurt H Maier  wrote:

> Anselm,
>
> Any word on a timetable for disowning wmii?  This is a four-hundred
> line configuration that requires a 1600-line library, not to mention
> an entire extra programming language.
>
> To manage x11 windows.
>
>
what does that even mean? wmii *requires* ruby? Never heard of that.

-jf


--
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."
--Richard Stallman

"It's so hard to write a graphics driver that open-sourcing it would not
help."
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228