Re: [dev] [dwm] 2000 SLOC
On 11/3/11, Andrew Hills wrote: > Nothing you do to a web standard will ever keep a designer from using an > image to display text content except disallowing the transfer of images. > However poetic your statement, disabling embedding of images will suffice. was probably the first great anti-feature proposed by a commercial browser vendor, implemented by the same vendor and used by authors before the committee got to standardizing a better alternative.
Re: [dev] [dwm] 2000 SLOC
[2011-10-31 10:11] Anselm R Garbe > On 31 October 2011 10:01, Martin Kopta wrote: > > Are there any explicit rules which project must follow in order to be part > > of suckless? What is the line in here? > > I'm working on such guidelines. The main aspects are: I wonder why we actually do need such guidelines. We don't have masses of projects to filter. We can simply continue including what we (i.e. eventually Anselm) consider worthwhile and remove what we consider not suiting. That makes everthing easier and also we keep our flexibility. (As we agree that wmii should go, just remove it. Its fans had long enough time to move the contents.) Generally, I think, that one success factor in the (early) development of dwm had been that Anselm just did what he thought was good for himself. This can be done similarily for suckless.org. Anselm has shown that he goes for rough consensus. Instead of adding manifests, we better have real content and let that speak. > 1. Relevance/Elitism: the project must be relevant in the context of > suckless.org's target audience, it must target expert > users/developers/administrators and _not_ typical end users. Why? Are there too many projects in which only few people are interested? > 3. Quality: the project must aim to be a quality finished product once > exceeding the 1.0 version number and be maintained afterwards. Someone already pointed it out. It actually were suckless projects that did intentionally not care about the meaning of version numbers. And about quality: Who of us mainly cares about quality? We care about hackable code! That's important. > Unmaintained projects will be removed after a grace period of one > year. Rules, rules, rules ... > 5. Exclusivity: the project must be unique, i.e. it should not solve a > problem that is solved by another suckless.org project. Why not? I suggest to drop the idea of having such a set of rules. We have the expression of our code and we have a common sense within the suckless community. What else is the Unix philosophy? meillo
Re: [dev] [dwm] 2000 SLOC
On 4 November 2011 09:40, markus schnalke wrote: > Someone already pointed it out. It actually were suckless projects > that did intentionally not care about the meaning of version numbers. I agree. I don't even see why we don't just drop the first dot and have dwm-60, dmenu-45. > And about quality: Who of us mainly cares about quality? We care about > hackable code! That's important. I do. As always, it's about trade-offs. I try to make my software as high a quality as possible without sacrificing too much clarity. Besides, the ultimate hackable code is an empty file. cls
Re: [dev] [dwm] 2000 SLOC
+--- markus schnalke ---+ > I wonder why we actually do need such guidelines. We don't have masses > of projects to filter. We can simply continue including what we (i.e. > eventually Anselm) consider worthwhile and remove what we consider not > suiting. That makes everything easier and also we keep our flexibility. > (As we agree that wmii should go, just remove it. Its fans had long > enough time to move the contents.) > > Generally, I think, that one success factor in the (early) development > of dwm had been that Anselm just did what he thought was good for > himself. This can be done similarly for suckless.org. Anselm has > shown that he goes for rough consensus. > > Instead of adding manifests, we better have real content and let that > speak. sounds good, but don't forget, that usually it helps people to get their ideals straight by formulating them - lets say manifest not guidelines. what the community defines as suckless is not completely reflected in what you name content. i think that there are to few suckless projects for that. <...> > > Unmaintained projects will be removed after a grace period of one > > year. > > Rules, rules, rules ... <...> > I suggest to drop the idea of having such a set of rules. We have the > expression of our code and we have a common sense within the suckless > community. What else is the Unix philosophy? i agree with your suggestion.
Re: [dev] [dwm] 2000 SLOC
Anselm is scared to piss of the "community" so he needs everyone to agree with his rules and ideas beforehand. Typical social behaviorism I guess.
Re: [dev] [surf] downloads
On 2011-11-03 16:30, Peter John Hartman wrote:
>
> Second of all, and instead, it just prints to stdout (a) the fact that the
> Download has started, together with the filename, and (b) the fact that it
> has finished/cancelled/errored, together with the filename.
Not much more to add a progress bar to that patch.
Patrick
diff -urN surf-tip/surf.c surf-dl/surf.c
--- surf-tip/surf.c 2011-11-04 22:21:52.077749801 +0800
+++ surf-dl/surf.c 2011-11-04 23:35:55.630343708 +0800
@@ -42,6 +42,15 @@
gboolean zoomed;
} Client;
+typedef struct Download {
+ WebKitDownload *download;
+ Client *client;
+ gboolean is_done;
+ char *filename;
+ char *filename_partial;
+ struct Download *next;
+} Download;
+
typedef struct {
char *label;
void (*func)(Client *c, const Arg *arg);
@@ -58,6 +67,7 @@
static Display *dpy;
static Atom atoms[AtomLast];
static Client *clients = NULL;
+static Download *downloads = NULL;
static GdkNativeWindow embed = 0;
static gboolean showxid = FALSE;
static char winid[64];
@@ -340,14 +350,82 @@
soup_cookies_free(l);
}
+int
+downloadstatus(WebKitDownload *download, GParamSpec *pspec, gpointer
user_data) {
+ WebKitDownloadStatus status;
+ Download *d;
+
+ for (d = downloads; d != NULL && d->download != download ; d = d->next )
+ ;
+ if (d == NULL)
+ return fprintf(stderr, "lost download?\n"), -1;
+
+ g_object_get(download, "status", &status, NULL);
+
+ switch(status) {
+ case WEBKIT_DOWNLOAD_STATUS_CREATED:
+ d->client->progress = 0;
+ update(d->client);
+ break;
+ case WEBKIT_DOWNLOAD_STATUS_STARTED:
+ case WEBKIT_DOWNLOAD_STATUS_ERROR:
+ case WEBKIT_DOWNLOAD_STATUS_CANCELLED:
+ break; /* these are irrelevant */
+ case WEBKIT_DOWNLOAD_STATUS_FINISHED: {
+ unlink(d->filename);
+ rename(d->filename_partial, d->filename);
+ g_free(d->filename_partial);
+ g_free(d->filename);
+ d->is_done = TRUE;
+ d->client->progress = 100;
+ update(d->client);
+ }
+ }
+ return 0;
+}
+
+void
+downloadprogress(WebKitDownload *download, GParamSpec *pspec, gpointer
user_data) {
+ Download *d;
+ gdouble progress;
+
+ g_object_get(download, "progress", &progress, NULL);
+ for (d = downloads; d != NULL && d->download != download ; d = d->next )
+ ;
+ if (d == NULL)
+ return;
+ if ( (d->client->progress = (int)(progress * 100)) == 0)
+ d->client->progress = 1;
+ update(d->client);
+}
+
gboolean
initdownload(WebKitWebView *view, WebKitDownload *o, Client *c) {
- Arg arg;
+ char *f;
+ Download *d;
- updatewinid(c);
- arg = (Arg)DOWNLOAD((char *)webkit_download_get_uri(o));
- spawn(c, &arg);
- return FALSE;
+ if (!(d = malloc(sizeof(Download
+ die("Cannot malloc!\n");
+ d->next = downloads;
+ d->client = c;
+ d->download = o;
+ d->is_done = FALSE;
+ downloads = d;
+ d->client->progress = 1;
+ update(d->client);
+ g_signal_connect(o, "notify::status", G_CALLBACK(downloadstatus), NULL);
+ g_signal_connect(o, "notify::progress", G_CALLBACK(downloadprogress),
NULL);
+ d->filename = g_strconcat(downloaddir, "/",
+ (char *)webkit_download_get_suggested_filename(o), NULL
+ );
+ d->filename_partial = g_strconcat(d->filename, ".part", NULL);
+ unlink(d->filename_partial);
+
+ f = g_strconcat("file://", d->filename_partial, NULL);
+ webkit_download_set_destination_uri(o, f);
+ webkit_download_start(o);
+ g_free(f);
+ return TRUE;
}
gboolean
Re: [dev] [dwm] bugfix for multi monitor setup
Hi Brian,
thanks for your patch. I would like to test it.
Can you resend it as attachment that is created using
cd dwm/
hg diff > dwm_two_monitor_fix.patch
Thanks in advance,
Anselm
On 2 November 2011 22:19, Brian L Angus wrote:
> 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
On 4 November 2011 10:40, markus schnalke wrote: > [2011-10-31 10:11] Anselm R Garbe >> On 31 October 2011 10:01, Martin Kopta wrote: >> > Are there any explicit rules which project must follow in order to be part >> > of suckless? What is the line in here? >> >> I'm working on such guidelines. The main aspects are: > > I wonder why we actually do need such guidelines. We don't have masses > of projects to filter. We can simply continue including what we (i.e. The guidelines I outlined are not meant to be strong rules. There were just an email attempt to describe some of the motives of suckless.org from my perspective. HTH, Anselm
Re: [dev] [dwm] 2000 SLOC
On 4 November 2011 11:50, Connor Lane Smith wrote: > On 4 November 2011 09:40, markus schnalke wrote: >> Someone already pointed it out. It actually were suckless projects >> that did intentionally not care about the meaning of version numbers. > > I agree. I don't even see why we don't just drop the first dot and > have dwm-60, dmenu-45. I explained this already. I want to keep this version scheme just for the sake of conservatism. We don't need to change the versioning scheme every two years like others (I did it before dwm times quite often). But once a versioning scheme is in place, we stick to it. Cheers, Anselm
Re: [dev] [dwm] 2000 SLOC
On 4 November 2011 12:24, hiro <23h...@googlemail.com> wrote: > Anselm is scared to piss of the "community" so he needs everyone to > agree with his rules and ideas beforehand. Typical social behaviorism > I guess. I just want to be fair to the small crowd of remaining wmii users to have a smooth relocation. Everything will be accomplished until mid of December. Cheers, Anselm
Re: [dev] [surf] downloads
Quoth Peter John Hartman: > One thing that *rumor* has it surf can't handle are fancy-schmancy > downloads, for instance, I'm told RapidShare fails[1]. More testing has shown that this is actually a lie (sorry about that). I have definitely seen failures in the past with downloading, but would really like to come up with at least one example of a download that doesn't work with surf + a recent webkit before we think about patching. I'll look myself, but if anyone else finds one, please let us know. I think you'll have the best luck on crappy rapidshare/megaupload kind of places. So look for the dodgiest stuff you can find, and see if vanilla surf screws up anywhere. pgpjF1FH7m13M.pgp Description: PGP signature
Re: [dev] [dwm] 2000 SLOC
> I just want to be fair to the small crowd of remaining wmii users to > have a smooth relocation. Everything will be accomplished until mid of > December. Thanks. Not many of us depend on the web site anyway, but new users should have the freedom to find it.
Re: [dev] [dwm] bugfix for multi monitor setup
Here you go...
On Fri, Nov 04, 2011 at 06:43:59PM +0100, Anselm R Garbe wrote:
> Hi Brian,
>
> thanks for your patch. I would like to test it.
>
> Can you resend it as attachment that is created using
>
> cd dwm/
> hg diff > dwm_two_monitor_fix.patch
>
> Thanks in advance,
> Anselm
>
> On 2 November 2011 22:19, Brian L Angus wrote:
> > 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);
> >
> >
> >
diff -r 1228e3d45d25 dwm.c
--- a/dwm.c Wed Nov 02 12:01:28 2011 +
+++ b/dwm.c Fri Nov 04 12:56:00 2011 -0600
@@ -340,14 +340,14 @@
*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;
@@ -1146,7 +1146,7 @@
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;
}
