[surf] line of approach [was: [dev] [surf] download images?]
2010/5/17 pancake : > Copy URL doesn't works for images I'm open for patches to copy a pictures URI. I think, I will strip down things in surf. I have to reconsider the event system. It's a bit ugly and inconsistent atm. Also the cookie problem is on display. I need the netscape cookies.txt format to be compatible to third party tools like curl or wget. On the other hand I need an extra field to differ between session and non-session cookies in this file. This is a problem and I got no satisfying solution to this atm. The normal case is to not safe sessioncookies to cookie.txt at all. This is the reason why sessiontime exists. surf sets a value of time() + sessiontime for session cookies to write them to the file. This makes the cookies accessable to other sessions of surf and scripts using this file. Way to go is to remove more complexity from surf. downloading is one of the features which never worked well and can easily be moved into a script.
Re: [dev] stali and static surf binary
On 16 May 2010 02:09, Ersin Akinci wrote: > You're correct, my intentions are quite different and have nothing at all to > do with performance concerns. I'm trying to manifest a certain aesthetic > vision: I like the act of downloading static binaries and deleting them > without worrying about dependencies, complicated directory structures, etc. > stali's web page also implies that the goal isn't just completely focused on > performance, especially when you read the proposed directory structure > (i.e., "/proc: linux stuff"). > > Heh, yeah dillo would work, but really dillo isn't a solution. It's > admirable for what it is, but I need a full-featured, statically linked > browser. I figured that if anyone would know how to do that it would be the > stali dev(s). No idea if it's being actively maintained or not. I'll share the state I've got soon. In my impression the real pain is GNU autoconf and libtool that never really work to produce static libs instead of shared libs + shared stubs. Hence my approach is ignoring all existing build systems and writing mkfile's from scratch based on example runs of the configure toolchain (like in WebKit I run the normal process to get DerivedSources first) and then running mk on all source files I determined which results in a static libWebKit.a that contains everything. If also all dependencies have been build similarly you will get quite far, though you will also need dlopen support unfortunately in case of WebKit; at least for plugins, but of course you can link that in from a static eglibc and hope it will be supported in a similar fashion. The absolute hardcore solution would be hacking dlopen to be a dummy and link all plugins into libWebKit.a that you are going to use (then you need some binary magic though in renaming NP entrypoints for each plugin and dealing with those in dlsym). Cheers, Anselm
Re: [dev] stali and static surf binary
On 16 May 2010 01:08, anonymous wrote: > On Sat, May 15, 2010 at 05:11:48PM -0400, Ersin Akinci wrote: >> Thus, dynamic libraries would still be used, but at least they would >> be duplicated, independent, and isolated for each program that needed it. > > What problem you are trying to solve? You want to make binaries > independent from environment so you can get your directory with > program and it's libraries and run on every Linux machine? I think > main goal of stali is to get rid of complex dynamic library loader and > make loading faster. Looks like you are trying to use static linking > for different purpose. > > If it is too hard to compile these complex web browser engines, it is > possible to switch to Netsurf or Dillo. Dillo uses FLTK, it is > developed for static linking from the start. Browser engine is > internal so there is no problem. These browsers are not so functional > as WebKit-based browsers like surf but they are more simple in fact. > > BTW there are no commits to stali repository recently, it is developed > privately or it is not developed now? It is stalled currently, but I will have some more time soon. I'm still quite busy at my day job unfortunately. Cheers, Anselm
[dev] Re: [surf] line of approach
"Enno Boland (Gottox)" writes: > 2010/5/17 pancake : >> Copy URL doesn't works for images > I'm open for patches to copy a pictures URI. I think, I will strip > down things in surf. I have to reconsider the event system. It's a bit > ugly and inconsistent atm. > > [snip] > > Way to go is to remove more complexity from surf. downloading is one > of the features which never worked well and can easily be moved into a > script. Moving more things into external scripts is a good idea in my opinion, but that does seem to imply having an actual extensible event system. The question is whether to make it as fully fledged as Uzbl (which can be a bit complex), or to define a simpler set with less flexibility. Of course, perhaps surf's idea of passing information via X properties makes it possible to grow an event system without making it complex at all. -- \ Troels /\ Henriksen
Re: [dev] stali and static surf binary
On Sat, May 15, 2010 at 09:09:09PM -0400, Ersin Akinci wrote: >You're correct, my intentions are quite different and have nothing at all >to do with performance concerns. I'm trying to manifest a certain >aesthetic vision: I like the act of downloading static binaries and >deleting them without worrying about dependencies, complicated directory >structures, etc. stali's web page also implies that the goal isn't just >completely focused on performance, especially when you read the proposed >directory structure (i.e., "/proc: linux stuff"). Slightly of topic with this, but I've tried to run statifier on the surf binary (from my archlinux virtual machine) to generate a psuedo statically linked blob, it sort of works if the target distro that you intend to run the binary on is using a new enough glibc. I ran into all sorts of backward compatibility issues with threading when I tried to run the psuedo statically linked blob on a rhel5 like system (older glibc's) it's not really static linking that I tried but its close to some of your goals i think. anyway the blob i got was about 80megs in size when it was outputted from statifier. jimmy -- Jimmy Tang Trinity Centre for High Performance Computing, Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. http://www.tchpc.tcd.ie/ pgpv7Yclj98nU.pgp Description: PGP signature
Re: [surf] line of approach [was: [dev] [surf] download images?]
On Mon, May 17, 2010 at 09:40:01AM +0200, Enno Boland (Gottox) wrote:
>
> 2010/5/17 pancake :
> > Copy URL doesn't works for images
> I'm open for patches to copy a pictures URI. I think, I will strip
> down things in surf.
Here is a possibility, i just removed the context menu
and a few lines to get rid of warnings at compile
and got the gtk menu with a "copy img link" entry.
I'm not a coder and that was done with a hammer, but it works.
I guess you have good reasons to have your own context menu,
but the default gtk one with the underlined letters
is keyboard friendlier to me as one just need to hit
the underlined letter to select an entry.
diff -up surf/config.def.h surf_img_link/config.def.h
--- surf/config.def.h 2010-05-17 09:23:49.0 +0200
+++ surf_img_link/config.def.h 2010-05-17 10:11:24.0 +0200
@@ -19,6 +19,7 @@ static Key keys[] = {
{ MODKEY|GDK_SHIFT_MASK,GDK_r, reload, { .b = TRUE } },
{ MODKEY, GDK_r, reload, { .b = FALSE } },
{ MODKEY|GDK_SHIFT_MASK,GDK_p, print, { 0 } },
+{ MODKEY, GDK_d, download, { 0 } },
{ MODKEY, GDK_p, clipboard, { .b = TRUE } },
{ MODKEY, GDK_y, clipboard, { .b = FALSE } },
{ MODKEY|GDK_SHIFT_MASK,GDK_j, zoom, { .i = -1 } },
@@ -35,14 +36,3 @@ static Key keys[] = {
{ MODKEY, GDK_n, find, { .b = TRUE } },
{ MODKEY|GDK_SHIFT_MASK,GDK_n, find, { .b = FALSE } },
};
-
-static Item items[] = {
-{ "Back", navigate, { .i = -1 } },
-{ "Forward",navigate, { .i = +1 } },
-{ "New Window", newwindow, { .v = NULL } },
-{ "Reload", reload,{ .b = FALSE } },
-{ "Stop", stop, { 0 } },
-{ "Paste URI", clipboard, { .b = TRUE } },
-{ "Copy URI", clipboard, { .b = FALSE } },
-{ "Download", download, { 0 } },
-};
diff -up surf/surf.c surf_img_link/surf.c
--- surf/surf.c 2010-05-17 09:23:49.0 +0200
+++ surf_img_link/surf.c 2010-05-17 10:12:22.0 +0200
@@ -68,7 +68,6 @@ static gboolean loadimage = 1, plugin =
static char *buildpath(const char *path);
static void cleanup(void);
static void clipboard(Client *c, const Arg *arg);
-static void context(WebKitWebView *v, GtkMenu *m, Client *c);
static char *copystr(char **str, const char *src);
static WebKitWebView *createwindow(WebKitWebView *v, WebKitWebFrame *f, Client *c);
static gboolean decidedownload(WebKitWebView *v, WebKitWebFrame *f, WebKitNetworkRequest *r, gchar *m, WebKitWebPolicyDecision *p, Client *c);
@@ -85,7 +84,6 @@ static const char *getcookies(SoupURI *u
static char *geturi(Client *c);
void gotheaders(SoupMessage *msg, gpointer user_data);
static gboolean initdownload(WebKitWebView *v, WebKitDownload *o, Client *c);
-static void itemclick(GtkMenuItem *mi, Client *c);
static gboolean keypress(GtkWidget *w, GdkEventKey *ev, Client *c);
static void linkhover(WebKitWebView *v, const char* t, const char* l, Client *c);
static void loadstatuschange(WebKitWebView *view, GParamSpec *pspec, Client *c);
@@ -173,22 +171,6 @@ clipboard(Client *c, const Arg *arg) {
gtk_clipboard_set_text(gtk_clipboard_get(GDK_SELECTION_PRIMARY), c->linkhover ? c->linkhover : geturi(c), -1);
}
-void
-context(WebKitWebView *v, GtkMenu *m, Client *c) {
- int i;
- GtkContainer *parent;
-
- gtk_widget_hide_all(GTK_WIDGET(m));
- gtk_widget_show(GTK_WIDGET(m));
- for(i = 0; i < LENGTH(items); i++) {
- parent = GTK_CONTAINER(gtk_widget_get_parent(c->items[i]));
- if(parent)
- gtk_container_remove(parent, c->items[i]);
- gtk_menu_shell_append(GTK_MENU_SHELL(m), c->items[i]);
- gtk_widget_show(c->items[i]);
- }
-}
-
char *
copystr(char **str, const char *src) {
char *tmp;
@@ -231,7 +213,6 @@ decidewindow(WebKitWebView *view, WebKit
void
destroyclient(Client *c) {
- int i;
Client *p;
gtk_widget_destroy(c->indicator);
@@ -239,9 +220,6 @@ destroyclient(Client *c) {
gtk_widget_destroy(c->scroll);
gtk_widget_destroy(c->vbox);
gtk_widget_destroy(c->win);
- for(i = 0; i < LENGTH(items); i++)
- gtk_widget_destroy(c->items[i]);
- free(c->items);
for(p = clients; p && p->next != c; p = p->next);
if(p)
@@ -388,17 +366,6 @@ initdownload(WebKitWebView *view, WebKit
return TRUE;
}
-void
-itemclick(GtkMenuItem *mi, Client *c) {
- int i;
- const char *label;
-
- label = gtk_menu_item_get_label(mi);
- for(i = 0; i < LENGTH(items); i++)
- if(!strcmp(items[i].label, label))
- items[i].func(c, &(items[i].arg));
-}
-
gboolean
keypress(GtkWidget* w, GdkEventKey *ev, Client *c) {
guint i;
@@ -475,7 +442,6 @@ navigate(Client *c, const Arg *arg) {
Client *
newclient(void) {
- int i;
Client *c;
WebKitWebSettings *settings;
WebKitWebFrame *frame;
@@ -509,16 +475,6 @@ newclient(void) {
g_signal_connect(G_OBJECT(c->win), "key-press-event", G_CALLBACK(keypress), c);
g_signal_connect(G_OBJECT(c->wi
[surf] line of approach [was: [dev] [surf] download images?]
On 5/17/10, julien steinhauser wrote: > > I guess you have good reasons to have your own context menu, > but the default gtk one with the underlined letters > is keyboard friendlier to me as one just need to hit > the underlined letter to select an entry. I've been wondering about the context menu too, because usually when you right click in a GTK text area there is a sub-menu to choose which GTK input method you'd like to use. I think that it's in the context menus by default in GTK..? Anyhow, sometimes I need to switch to VIQR (Vietnamese) input just to type a quick message, and then I go back to the default input method. It would be nice if that input method submenu was visible in the context menus in surf. - John
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/15/10, anonymous wrote: > On Fri, May 14, 2010 at 08:02:57PM +, Bjartur Thorlacius wrote: >> > 1. good tools should have a way to define easily keyboard shortcuts. >> True. It's quite irritating that some tools use the arrow keys for >> scrolling, >> others use hjkl (which doesn't make sense on all keyboards) and one >> has to configure each seperately to use the keybindings you like. >> > 1.1. Preferably good tools should have at least one predefined set of >> > shortcuts that is compatible with vimi >> I don't think imitiating vim is a good idea. When in a windowing system >> at least it would be nice if apps grabbed all keys they wanted >> (e.g. text boxes could grab all printing characters) but all other keys >> would >> bubble up (as I think they already do in X) but if they reach the root >> window >> they could be rethrown in the original window, but as some other >> user-defined >> keys. For example if one presses when focused on an image >> inside web page, it would bubble through e.g. xloadimage, surf, tabbed, >> root >> and then root would look it up and see that should be rethrown as >> which would bubble through xloadimage to surf which would scroll >> down. But I doubt it's possible in X (or does XEmbed allow for this?). > > Mostly agree, but chaning X is nearly impossible. Currently it is > possible to use modifiers for this. Alt (and A-C, A-S-C, A-S) for > window manager, Ctrl (and S-C) for special actions in programs, > everything else (with Shift or not) for typing. If we don't have > plugins, embedded windows and other things like that, there are only > two classes: > > 1. Window manager > 2. Windows. 3. User shortcuts > So it is easy to determine who should react to keypress: > > 1. If Alt is pressed then it is for window manager. > 2. If Ctrl is pressed then it is for focused window. > 3. In other case it is for focused widget (letters types text, return > presses buttons etc.). And if super is pressed; some keypress handler. > Super and other modifiers are for for user, he can use it as Compose > key, for switching layout etc. Is it possible to have some program seperate from the WM that receives all keystrokes starting with super (and maybe Alt to)? Or is wmiirc+wmiiloop already a program that does exactly that (independantly from WMII)? > What I don't like in current suckless programs is hjkl keybindings. > They are designed only for one layout. I think it is better to use > some kind of mnemonics like ^f for forward, ^b for backward, ^n for > next, ^p for previous etc. Something like this is used in Lynx, Dillo > (f for forward), most GNU programs (readline, emacs for example), > ratpoison, screen, tmux and many others. These keybindings are > independent from layout so you can use Dvorak layout or any other > layout that sucks less than current default created for typewriters > (which AFAIK was created to slow down typists, but I am not really > sure if it is not a myth; anyway it was not carefully designed to make > typing faster). I'm OK with hjkl as long as it's configurable. AFAIK one can't xmodmap hjkl to e.g. asdf or jklæ (as that would ck lash with typing of hjkl). Wouldn't it suffice to xmodmap ^h ^j ^k ^l to the arrow keys? And maybe ^n and ^p to pageUp and pageDown. Then when I toggle Ctrl-mode hjkl (or whatever keys I xmodmapped to arrows) will do what's expected. I think this is possible both under X and in the Linux VTs. If I knew how to do this, I could use a modular interface to Nano! -- kv, - Bjartur
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, 17 May 2010 12:22:52 + Bjartur Thorlacius wrote: > Is it possible to have some program seperate from the WM that receives > all keystrokes starting with super (and maybe Alt to)? It is possible to have a program bind specific keystrokes; you probably won't be able to capture all keystrokes with a given set of modifiers (look up GrabKey in proto.pdf in the X.org hardcopy documentation). > Or is wmiirc+wmiiloop already a program that does exactly that > (independantly from WMII)? I think those only talk to WMII's 9P file server, not to the X server. Robert Ransom
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 12:22:52PM +, Bjartur Thorlacius wrote: > > 1. Window manager > > 2. Windows. >3. User shortcuts What you mean by user shortcuts? To create shortcut you can configure your window manager. So user shortcuts start with Alt. User should make sure that his shortcuts don't overlap with default shortcuts of window manager. Some kind of standard should be created only for programs, so their *default* shortcuts don't overlap.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/17/10, anonymous wrote: > What you mean by user shortcuts? To create shortcut you can configure > your window manager. So user shortcuts start with Alt. User should > make sure that his shortcuts don't overlap with default shortcuts of > window manager. Some kind of standard should be created only for > programs, so their *default* shortcuts don't overlap. I just felt that it was weird that the program that draws borders around my windows is also a keyboard shortcut handler/dispatcher/whatever.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Sun, May 16, 2010 at 04:25:45AM +0400, anonymous wrote:
> Also removing Alt keybindings will simplify dmenu code: there will be
> only one switch instead of two, one "default" branch instead of two,
> less manipulation with masks and everytihing else related.
>
Patch (-7 loc) attached. BTW can someone explain where Alt-g and
Alt-G originated from?
Even if it will not be applied, line 430
default: return;
should be changed to
default:
return;
to follow common style (lines 383-384).
diff -r 545ec6141dc4 dmenu.c
--- a/dmenu.c Wed May 05 11:42:39 2010 +0100
+++ b/dmenu.c Mon May 17 17:43:33 2010 +0400
@@ -15,7 +15,6 @@
#endif
/* macros */
-#define CLEANMASK(mask) (mask & ~(numlockmask | LockMask))
#define INRECT(X,Y,RX,RY,RW,RH) ((X) >= (RX) && (X) < (RX) + (RW) && (Y) >=
(RY) && (Y) < (RY) + (RH))
#define MIN(a, b) ((a) < (b) ? (a) : (b))
#define MAX(a, b) ((a) > (b) ? (a) : (b))
@@ -386,6 +385,10 @@
case XK_A:
ksym = XK_Home;
break;
+ case XK_b:
+ case XK_B:
+ ksym = XK_Left;
+ break;
case XK_c:
case XK_C:
ksym = XK_Escape;
@@ -394,6 +397,10 @@
case XK_E:
ksym = XK_End;
break;
+ case XK_f:
+ case XK_F:
+ ksym = XK_Right;
+ break;
case XK_h:
case XK_H:
ksym = XK_BackSpace;
@@ -406,6 +413,14 @@
case XK_J:
ksym = XK_Return;
break;
+ case XK_n:
+ case XK_N:
+ ksym = XK_Next;
+ break;
+ case XK_p:
+ case XK_P:
+ ksym = XK_Prior;
+ break;
case XK_u:
case XK_U:
memmove(text, text + cursor, sizeof text - cursor + 1);
@@ -423,30 +438,8 @@
match(text);
}
break;
- }
- }
- if(CLEANMASK(e->state) & Mod1Mask) {
- switch(ksym) {
- default: return;
- case XK_h:
- ksym = XK_Left;
- break;
- case XK_l:
- ksym = XK_Right;
- break;
- case XK_j:
- ksym = XK_Next;
- break;
- case XK_k:
- ksym = XK_Prior;
- break;
- case XK_g:
- ksym = XK_Home;
- break;
- case XK_G:
- ksym = XK_End;
- break;
- case XK_p:
+ case XK_y:
+ case XK_Y:
{
FILE *fp;
char *s;
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 01:39:38PM +, Bjartur Thorlacius wrote: > On 5/17/10, anonymous wrote: > > What you mean by user shortcuts? To create shortcut you can configure > > your window manager. So user shortcuts start with Alt. User should > > make sure that his shortcuts don't overlap with default shortcuts of > > window manager. Some kind of standard should be created only for > > programs, so their *default* shortcuts don't overlap. > I just felt that it was weird that the program that draws borders around my > windows is also a keyboard shortcut handler/dispatcher/whatever. Now dwm draws statusbar for you (if you use dwm). It also runs dmenu and st/urxvt/xterm too. Most of global user keybindings just run commands so it is ok if these keybindings will be window manager keybindings. Or if you disagree, then keybindings that run dmenu and terminal emulator should be removed from dwm code and placed somewhere else. But I think it will just make things more complex.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 9:39 AM, Bjartur Thorlacius wrote: > I just felt that it was weird that the program that draws borders around my > windows is also a keyboard shortcut handler/dispatcher/whatever. dwm, as the program that sits between you and other programs, already has to intercept everything not destined for another client. since there's already an interface to intercept keys globally, it makes sense to use it for all global key-commands. there's nothing really stopping you from installing speckeysd though. -- # Kurt H Maier
Re: [dev][dmenu] filter files with grep but print corresponding urls?
Thank you, I can now search with grep (although not incrementally) and I can display something different than what is returned. I think I may need to extend (or simplify) dmenu to allow for search with an arbitrary tool recieving input and returning output from/to dmenu. I can't think of the most idiomatic/elegant way to do this. Would it be good to pass named pipes as arguments? On Sun, May 9, 2010 at 9:06 AM, Hiltjo Posthuma wrote: > On Sat, May 8, 2010 at 9:50 PM, Andreas Wagner > wrote: >> >> Hello, >> >> I am writing some shell scripts for an uzbl bookmarker with full text >> search of webpages bookmarked. It wgets the html and takes the md5sum >> (of the page), the url and the title and puts them, space separated in >> a file. The downloaded page's filename is changed to the md5sum. >> >> I was trying a way to do the full text search of the pages with an >> arbitrary tool such as grep but display the corresponding titles+urls >> of the pages in the dmenu. >> >> Is this currently possible with dmenu? >> >> Thanks, >> Andreas > > I was trying to do something similar and I wrote a patch to make dmenu > output the index of the item instead of the text. The patch adds a "-n" > option to toggle making it output an index instead of the text, also you > must select the exact item (it doesnt output the input text). Patch added as > attachment. I hope you find it useful. >
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/17/10, Kurt H Maier wrote: > On Mon, May 17, 2010 at 9:39 AM, Bjartur Thorlacius > wrote: >> I just felt that it was weird that the program that draws borders around >> my >> windows is also a keyboard shortcut handler/dispatcher/whatever. > > Now dwm draws statusbar for you (if you use dwm). It also runs dmenu > and st/urxvt/xterm too. Most of global user keybindings just run > commands so it is ok if these keybindings will be window manager > keybindings. I run WMII, but the situation is similiar there. But why is the statusbar the same program? So it doesn't get focused? That should be possible with some sort of window property, right? > Or if you disagree, then keybindings that run dmenu and terminal > emulator should be removed from dwm code and placed somewhere else. > But I think it will just make things more complex. Possibly so, yes. > dwm, as the program that sits between you and other programs, already > has to intercept everything not destined for another client. since > there's already an interface to intercept keys globally, it makes > sense to use it for all global key-commands. there's nothing really > stopping you from installing speckeysd though. Does it have to intercept all keystrokes anyway? Even if I run another program to handle keyboard shortcuts? As wmii can be controled through 9P, and wm keybindings in wmiirc do indeed just call wmiir, it's possible to dispatch /all/ shortcuts externally, even ones to resize windows and start terminal emulators. speckeysd fits the role,
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 02:40:25PM +, Bjartur Thorlacius wrote: > On 5/17/10, Kurt H Maier wrote: > > On Mon, May 17, 2010 at 9:39 AM, Bjartur Thorlacius > > wrote: > >> I just felt that it was weird that the program that draws borders around > >> my > >> windows is also a keyboard shortcut handler/dispatcher/whatever. > > > > Now dwm draws statusbar for you (if you use dwm). It also runs dmenu > > and st/urxvt/xterm too. Most of global user keybindings just run > > commands so it is ok if these keybindings will be window manager > > keybindings. > I run WMII, but the situation is similiar there. But why is the statusbar > the same program? So it doesn't get focused? That should be possible > with some sort of window property, right? Yes, it is possible. Maybe it is because dwm uses tags (something like virtual desktops, but you can select more than one at one time) and common statusbars (and WM standards) don't support them. There is http://hg.suckless.org/2wm/ repository. It is dwm with no tags and statusbar. There are some notes about "sbar" in changelog, probably it is something like statusbar. If the only problem is tags, maybe replace them with more common "virtual desktops"? If you look at screenshots [http://dwm.suckless.org/screenshots/], there is only one tag selected on each desktop - tags are used as virtual desktops.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 11:20 AM, anonymous wrote: > If the only problem is tags, maybe replace them with more common > "virtual desktops"? If you look at screenshots > [http://dwm.suckless.org/screenshots/], there is only one tag selected > on each desktop - tags are used as virtual desktops. If you're doing one tag at a time, something like 2wm or matchbox is fine. I use the multiple-tags features of dwm extensively, and to the best of my knowledge suckless.org is the only place to get that sort of functionality. -- # Kurt H Maier
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Mon, May 17, 2010 at 11:29:24AM -0400, Kurt H Maier wrote: > On Mon, May 17, 2010 at 11:20 AM, anonymous wrote: > > If the only problem is tags, maybe replace them with more common > > "virtual desktops"? ?If you look at screenshots > > [http://dwm.suckless.org/screenshots/], there is only one tag selected > > on each desktop - tags are used as virtual desktops. > > If you're doing one tag at a time, something like 2wm or matchbox is > fine. I use the multiple-tags features of dwm extensively, and to the > best of my knowledge suckless.org is the only place to get that sort > of functionality. I believe this can also be done in OpenBSD's cwm using groups, but cwm isn't tiling. Also, I think xmonad has some contrib packages to support window tagging, but they work in addition to workspaces instead of replacing them.
Re: [dev] surf patch: bind keystrokes to snippets of Javascript
Troels Henriksen writes:
> Sean Whitton writes:
>
>> Hi,
>>
>> On Tue, May 11, 2010 at 02:13:01PM +0100, Sean Whitton wrote:
>>> On Tue, May 11, 2010 at 11:10:04AM +0200, Troels Henriksen wrote:
>>> > The attached patch lets you bind keys to small lines of Javascript to
>>> > run.
>>> >
>>> > The intent is that the usual ~/.surf/script.js defines various methods,
>>> > which are then run by the bindings. This is much cleaner than having
>>> > script.js create its own event listeners for keybindings going outside
>>> > surf's own system.
>>>
>>> This works brilliantly - thank you. If anyone was wondering how to add
>>> keybindings to your config file, this is what I have in config.h for
>>> hinting (that works):
>>>
>>> { 0,GDK_f, eval, { .v = (char *[]){
>>> "hintMode()", NULL } } },
>>> { 0,GDK_F, eval, { .v = (char *[]){
>>> "hintMode(true)", NULL } } },
>>> { 0,GDK_Escape, eval, { .v = (char *[]){
>>> "removeHints()", NULL } } },
>>>
>>> ... and just comment out the line document.addEventListener all the way
>>> down to the end of the hinting script in script.js.
>>
>> Don't comment any JavaScript out; this breaks the binding of the numbers
>> to actually use the hints. Sorry.
>
> You can remove some of the Javascript. This is the modified
> script.js I use for hint mode (it also has a minor optimisation in the
> tagging loop).
Here is a further improved link hinting script, which positions the
hints better when the element is broken across lines, and prevents
recursive invocations of hintMode(). (Sorry for not attaching it, but
my nearby sucky mailserver won't permit me to send .js-files).
/* Based on chromium plugin code, adapted by Nibble<@gmail.com> and
* further refined by Troels Henriksen */
var hint_num_str = '';
var hint_elems = [];
var hint_enabled = false;
var hint_new_win = false;
var hintsheet;
function hintMode(new_win){
if (!hint_enabled) {
hint_enabled = true;
hint_new_win = new_win;
setHints();
document.addEventListener('keydown', hintHandler, false);
hint_num_str = '';
}
}
function hintHandler(e){
e.preventDefault(); //Stop Default Event
var pressedKey = get_key(e);
if (pressedKey == 'Enter') {
if (hint_num_str == '')
hint_num_str = '1';
judgeHintNum(Number(hint_num_str));
} else if (/[0-9]/.test(pressedKey) == false) {
removeHints();
} else {
hint_num_str += pressedKey;
var hint_num = Number(hint_num_str);
if (hint_num * 10 > hint_elems.length + 1) {
judgeHintNum(hint_num);
} else {
var hint_elem = hint_elems[hint_num - 1];
if (hint_elem != undefined && hint_elem.tagName.toLowerCase() ==
'a') {
setHighlight(hint_elem, true);
}
}
}
}
function setHighlight(elem, is_active) {
if (is_active) {
var active_elem =
document.body.querySelector('a[highlight=hint_active]');
if (active_elem != undefined)
active_elem.setAttribute('highlight', 'hint_elem');
elem.setAttribute('highlight', 'hint_active');
} else {
elem.setAttribute('highlight', 'hint_elem');
}
}
function setHintRules() {
if (!hintsheet) {
var ss = document.createElement('style');
ss.type = 'text/css';
ss.rel = 'stylesheet';
ss.media = 'screen';
ss.title = 'hintSheet';
document.getElementsByTagName("head")[0].appendChild(ss);
// This cannot be the best way.
for (var i=0; i < document.styleSheets.length; i++) {
if (document.styleSheets[i].title == 'hintSheet') {
hintsheet = document.styleSheets[i];
break;
}
}
}
hintsheet.insertRule('a[highlight=hint_elem] {background-color: yellow}',
0);
hintsheet.insertRule('a[highlight=hint_active] {background-color: lime}',
0);
}
function deleteHintRules() {
hintsheet.deleteRule(0);
hintsheet.deleteRule(0);
}
function judgeHintNum(hint_num) {
var hint_elem = hint_elems[hint_num - 1];
if (hint_elem != undefined) {
execSelect(hint_elem);
} else {
removeHints();
}
}
function execSelect(elem) {
var tag_name = elem.tagName.toLowerCase();
var type = elem.type ? elem.type.toLowerCase() : "";
if (tag_name == 'a' && elem.href != '') {
setHighlight(elem, true);
// TODO: ajax,
if (hint_new_win) {
window.open(elem.href);
} else {
location.href=elem.href;
}
} else if (tag_name == 'input' && (type == "submit" || type == "button" ||
type == "reset")) {
elem.click();
} else if (tag_name == 'input' && (type == "radio" || type == "checkbox")) {
// TODO: toggle checkbox
elem.checked = !elem.checked;
} else if (tag_name == 'input' || tag_
