[dev] [wmii] wmii9menu and xinerama
Hi, I recently adapted my wmiirc_local such that when I right-click on a tagname in the statusbar, I get a wmii9menu with the names of the clients in that tag. When I attach my secondary screen left of the primary, half of the wmii9menu window is displayed on the secondary screen. Can this be avoided in some way, i.e. can I have the whole wmii9menu window on one of the screens? It is particularly annoying since my secondary screen has a lower resolution than the primary, thus part of the wmii9menu is hidden below the lower border of the screen. Thanks for the great work, James
[dev] [surf] next release
Hi! I'm going to release 0.3 this or next week, depending on how much time I can investigate. Please recheck tip and give feedback, as there are some bigger changes. * persistant/concurrent cookies are working (hopefully) * removing urlbar/searchbar and using dmenu instead * if the window is shrinked below a defined size, the zoom factor is automaticly decreased. This is usefull on small screens and tiling window manager. * searching works from an XProperty now. ToDo for 0.3 release: * get downloads working again. regards Enno
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 09:33:32AM +0200, Thomas Dean wrote: I recently adapted my wmiirc_local such that when I right-click on a tagname in the statusbar, I get a wmii9menu with the names of the clients in that tag. When I attach my secondary screen left of the primary, half of the wmii9menu window is displayed on the secondary screen. Can this be avoided in some way, i.e. can I have the whole wmii9menu window on one of the screens? It is particularly annoying since my secondary screen has a lower resolution than the primary, thus part of the wmii9menu is hidden below the lower border of the screen. Sure, please file an issue. -- Kris Maglione Deleted code is debugged code. --Jeff Sickel
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > Sure, please file an issue. Hmm, I need a Google account for that? ... No! :-) James
Re: [dev] [surf] next release
On 21-10-2009 10:14:45, Enno Boland (Gottox) wrote: > Hi! > > I'm going to release 0.3 this or next week, depending on how much time > I can investigate. Please recheck tip and give feedback, as there are > some bigger changes. > > * persistant/concurrent cookies are working (hopefully) > * removing urlbar/searchbar and using dmenu instead > * if the window is shrinked below a defined size, the zoom factor is > automaticly decreased. This is usefull on small screens and tiling > window manager. > * searching works from an XProperty now. > > ToDo for 0.3 release: > * get downloads working again. > > regards > Enno Hello, Sounds fine, but what was the reason to include dmenu instead of just GtkEntries? Are there some plans to put bookmarks inside dmenu choices, or you just don't like GtkStuff? What made you make this decision? Just curious. Regards, Ted -- === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [dev] [surf] next release
I dunno, but dmenu lacks edition/pasting, the only reason i can imagine to use dmenu is to autocomplete from bookmarked or visited urls. I didn't tried it yet, but I'm curious about if its better or worse way to enter urls. Tadeusz Sośnierz wrote: On 21-10-2009 10:14:45, Enno Boland (Gottox) wrote: Hi! I'm going to release 0.3 this or next week, depending on how much time I can investigate. Please recheck tip and give feedback, as there are some bigger changes. * persistant/concurrent cookies are working (hopefully) * removing urlbar/searchbar and using dmenu instead * if the window is shrinked below a defined size, the zoom factor is automaticly decreased. This is usefull on small screens and tiling window manager. * searching works from an XProperty now. ToDo for 0.3 release: * get downloads working again. regards Enno Hello, Sounds fine, but what was the reason to include dmenu instead of just GtkEntries? Are there some plans to put bookmarks inside dmenu choices, or you just don't like GtkStuff? What made you make this decision? Just curious. Regards, Ted
Re: [dev] [surf] next release
2009/10/21 pancake : > I dunno, but dmenu lacks edition/pasting, the only reason i can imagine > to use dmenu is to autocomplete from bookmarked or visited urls. I didn't > tried it yet, but I'm curious about if its better or worse way to enter > urls. I think it's a good decision to use dmenu. This allows automatically caching the url entered and present it the next time. If this decision remains stable in surf, I'm willing to accept the vertical menu patch in vanilla dmenu. Kind regards, Anselm
Re: [dev] [surf] next release
On 21-10-2009 11:19:42, Anselm R Garbe wrote: > 2009/10/21 pancake : > > I dunno, but dmenu lacks edition/pasting, the only reason i can imagine > > to use dmenu is to autocomplete from bookmarked or visited urls. I didn't > > tried it yet, but I'm curious about if its better or worse way to enter > > urls. > > I think it's a good decision to use dmenu. This allows automatically > caching the url entered and present it the next time. > If this decision remains stable in surf, I'm willing to accept the > vertical menu patch in vanilla dmenu. > Well, in 0.2, using GtkEntry it was alredy working like this: while visiting surf.suckless.org, pressing C-g you had 'http://surf.suckless.org' in the entry field, ready to copy/paste/edit/whatever. Of course you can use dmenu to keep the cache of more than one url, but I'm sure it can be also done via GtkEntryCompletion or how is it called. Also, I doubt if piping this urls from surf to dmenu and vice versa will be even faster and lighter than GtkEntry. Atm I don't see one reason to use dmenu this way. What is more, the searchbar. In 0.2, you opened it, typed 'surf', pressed enter, but the 'surf' remained there, so you just pressed enter once again, no need to open a search bar and type it once again. Still if there are really some good reasons for using dmenu instead of GtkEntry, I'd likely hear them. Regards, Ted -- === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
[dev] [surf] gtk hints patch
on dwm's tiled layout, surf window's dimensions do not obey dwm rules, because gtk hints are missing.here is patch to add them. L. hints-patch.diff Description: Binary data
Re: [dev] [surf] gtk hints patch
This is a reversed patch. Next time use unified diff format please. (diff -u) Or just 'hg diff'. This is not a hard patch..but next time try to send the patch in a correct way. Lorenzo Bolla wrote: on dwm's tiled layout, surf window's dimensions do not obey dwm rules, because gtk hints are missing. here is patch to add them. L.
Re: [dev] [surf] gtk hints patch
sorry, I was too quick to type diffthanks, L. On Wed, Oct 21, 2009 at 11:42 AM, pancake wrote: > This is a reversed patch. Next time use unified diff format please. (diff > -u) > > Or just 'hg diff'. > > This is not a hard patch..but next time try to send the patch in a correct > way. > > > Lorenzo Bolla wrote: > >> on dwm's tiled layout, surf window's dimensions do not obey dwm rules, >> because gtk hints are missing. >> here is patch to add them. >> L. >> > > >
Re: [dev] [surf] next release
On Wed, Oct 21, 2009 at 10:14:45AM +0200, Enno Boland (Gottox) wrote: > > Hi! > > I'm going to release 0.3 this or next week, depending on how much time > I can investigate. Please recheck tip and give feedback, as there are > some bigger changes. > > * persistant/concurrent cookies are working (hopefully) > * removing urlbar/searchbar and using dmenu instead > * if the window is shrinked below a defined size, the zoom factor is > automaticly decreased. This is usefull on small screens and tiling > window manager. > * searching works from an XProperty now. > > ToDo for 0.3 release: > * get downloads working again. > > regards > Enno > Hello! About the downloads, I believe that most users have to move downloaded files from ~/.surf/dl before doing anything with them. What about externalize the downloading task to a simple script which make you choose the destination first? It could simplify surf's code? Right-clicking on the link and copy it is the preminaliry task of the user. The script named cdd for "choose download directory" depends only on wget and on suckless tools (and sort if you like) In this script lsd is suckless lsx with S_ISDIR instead of S_ISREG on line 28 You just stop directory navigation and start the download with escape. I apologize for my scripting style... #!/bin/sh dir=`lsd $PWD | sort | dmenu -p $PWD` [ -z $dir ] if [ $? = 1 ]; then cd $dir && cdd ; else wget --user-agent=usetheoneyoulike `sselp` fi attached an lsd tarball lsd.tar.gz Description: Binary data
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 11:19:42 +0100 Anselm R Garbe wrote: > If this decision remains stable in surf, I'm willing to accept the > vertical menu patch in vanilla dmenu. that would be awesome <3 Dieter PS: uzbl also relies on dmenu with vertical patch and that probably won't change
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 10:44:25AM +0200, Thomas Dean wrote: > On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > > Sure, please file an issue. > > Hmm, I need a Google account for that? ... No! :-) Okay, I did it anyway... but why google? :-( James
Re: [dev] [surf] next release
Hi, Two brief notes. (1) * removing urlbar/searchbar and using dmenu instead I'm not sure if this is so attractive, since dmenu does not support x paste (without a patch) and one always finds oneself (or at least I do) cutting and pasting into the searchbar. The ultimate solution, it seems to me, is to have dmenu support x paste in vanilla. This strikes me as superior to an "in-surf" solution (which uses GtkWhatever) for a number of reasons. (a) It keeps the code simple (on the surf side that is; dmenu will need to change). (b) Other web-based activities (smart prefixes in particular) could benefit from a dmenu + x paste. For example, I have a surf-googlesearch.sh script which runs dmenu after parsing my user input from dmenu. It would be nice to x paste into the dmenu rather than typing out a given google search (e.g. when one is searching someone's odd name.) (c) In general, I like the xprop interface and allowing applications other than surf to interact with surf (which is what your new _SURF_FIND feature allows--which is great--which is why we need dmenu to get patched!) (2) * get downloads working again. I think it is enough to just have a way of grabbing the url and then letting the user launch an extrinsic application. It looks as if 0.3 (tip) does this much now. Thanks for the work, Petre
Re: [dev] [surf] next release
2009/10/21 Peter John Hartman : > (1) * removing urlbar/searchbar and using dmenu instead > > I'm not sure if this is so attractive, since dmenu does not support x paste > (without a patch) and one always finds oneself (or at least I do) cutting > and pasting into the searchbar. The ultimate solution, it seems to me, is > to have dmenu support x paste in vanilla. This strikes me as superior to an > "in-surf" solution (which uses GtkWhatever) for a number of reasons. > (a) It keeps the code simple (on the surf side that is; dmenu will > need > to change). > (b) Other web-based activities (smart prefixes in particular) > could benefit from a dmenu + x paste. For example, I have a > surf-googlesearch.sh script which runs dmenu after parsing my user > input > from dmenu. It would be nice to x paste into the dmenu rather than > typing out a given google search (e.g. when one is searching > someone's > odd name.) > (c) In general, I like the xprop interface and allowing applications > other > than surf to interact with surf (which is what your new _SURF_FIND > feature > allows--which is great--which is why we need dmenu to get patched!) There is sselp(1) at http://tools.suckless.org/sselp which reads current selection and prints it to stdout, hence enables you to integrate it into dmenu's cache or calling surf `sselp` directly. There shouldn't be a real need to paste something interactively into surf or dmenu really. Kind regards, Anselm
Re: [dev] [surf] next release
On Wed, 21 Oct 2009, Anselm R Garbe wrote: 2009/10/21 Peter John Hartman : (1) * removing urlbar/searchbar and using dmenu instead I'm not sure if this is so attractive, since dmenu does not support x paste (without a patch) and one always finds oneself (or at least I do) cutting and pasting into the searchbar. The ultimate solution, it seems to me, is to have dmenu support x paste in vanilla. This strikes me as superior to an "in-surf" solution (which uses GtkWhatever) for a number of reasons. (a) It keeps the code simple (on the surf side that is; dmenu will need to change). (b) Other web-based activities (smart prefixes in particular) could benefit from a dmenu + x paste. For example, I have a surf-googlesearch.sh script which runs dmenu after parsing my user input from dmenu. It would be nice to x paste into the dmenu rather than typing out a given google search (e.g. when one is searching someone's odd name.) (c) In general, I like the xprop interface and allowing applications other than surf to interact with surf (which is what your new _SURF_FIND feature allows--which is great--which is why we need dmenu to get patched!) There is sselp(1) at http://tools.suckless.org/sselp which reads current selection and prints it to stdout, hence enables you to integrate it into dmenu's cache or calling surf `sselp` directly. There shouldn't be a real need to paste something interactively into surf or dmenu really. Kind regards, Anselm What about cases in which one wishes to both type a few words and then paste? For example, when I want to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also want to do something like "University of Wherever" + "Bob McCrue" where the first part is something I type in by hand and the second part is something I want to just "paste" in? The same argument could be launched with respect to the find feature (which now utilizes dmenu). Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"? Peter
Re: [dev] [surf] next release
On Wed, 21 Oct 2009, Anselm R Garbe wrote: 2009/10/21 Peter John Hartman : (1) * removing urlbar/searchbar and using dmenu instead I'm not sure if this is so attractive, since dmenu does not support x paste (without a patch) and one always finds oneself (or at least I do) cutting and pasting into the searchbar. The ultimate solution, it seems to me, is to have dmenu support x paste in vanilla. This strikes me as superior to an "in-surf" solution (which uses GtkWhatever) for a number of reasons. (a) It keeps the code simple (on the surf side that is; dmenu will need to change). (b) Other web-based activities (smart prefixes in particular) could benefit from a dmenu + x paste. For example, I have a surf-googlesearch.sh script which runs dmenu after parsing my user input from dmenu. It would be nice to x paste into the dmenu rather than typing out a given google search (e.g. when one is searching someone's odd name.) (c) In general, I like the xprop interface and allowing applications other than surf to interact with surf (which is what your new _SURF_FIND feature allows--which is great--which is why we need dmenu to get patched!) There is sselp(1) at http://tools.suckless.org/sselp which reads current selection and prints it to stdout, hence enables you to integrate it into dmenu's cache or calling surf `sselp` directly. There shouldn't be a real need to paste something interactively into surf or dmenu really. Kind regards, Anselm And FWIW (sorry to double post) xclip -o | xclip -sel clip seems to do the same thing that ssel is meant to do. Peter
Re: [dev] [surf] gtk hints patch
applied. thanks ;) 2009/10/21 Lorenzo Bolla : > sorry, I was too quick to type diff > thanks, > L. > > On Wed, Oct 21, 2009 at 11:42 AM, pancake wrote: >> >> This is a reversed patch. Next time use unified diff format please. (diff >> -u) >> >> Or just 'hg diff'. >> >> This is not a hard patch..but next time try to send the patch in a correct >> way. >> >> Lorenzo Bolla wrote: >>> >>> on dwm's tiled layout, surf window's dimensions do not obey dwm rules, >>> because gtk hints are missing. >>> here is patch to add them. >>> L. >> >> > > -- http://gnuffy.chaotika.org - Real Community Distro
Re: [dev] [surf] next release
On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: > > What about cases in which one wishes to both type a few words and then paste? > For example, when I want > to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my > selection buffer) but I also > want to do something like "University of Wherever" + "Bob McCrue" where the > first part is something > I type in by hand and the second part is something I want to just "paste" in? > The same argument > could be launched with respect to the find feature (which now utilizes dmenu). > > Or maybe you have something else in mind when you talk of "integrating into > dmenu's cache"? > > Peter sselp does it also in case you wish to paste "and" write. Select something, then run echo `sselp` | dmenu, tab, space and what you write after that follows your selection, terminate dmenu and all is printed out.
Re: [dev] [surf] next release
2009/10/21 Peter John Hartman : > > > On Wed, 21 Oct 2009, Anselm R Garbe wrote: > >> 2009/10/21 Peter John Hartman : >>> >>> (1) * removing urlbar/searchbar and using dmenu instead >>> >>> I'm not sure if this is so attractive, since dmenu does not support x >>> paste >>> (without a patch) and one always finds oneself (or at least I do) cutting >>> and pasting into the searchbar. The ultimate solution, it seems to me, >>> is >>> to have dmenu support x paste in vanilla. This strikes me as superior to >>> an >>> "in-surf" solution (which uses GtkWhatever) for a number of reasons. >>> (a) It keeps the code simple (on the surf side that is; dmenu will >>> need >>> to change). >>> (b) Other web-based activities (smart prefixes in particular) >>> could benefit from a dmenu + x paste. For example, I have a >>> surf-googlesearch.sh script which runs dmenu after parsing my user >>> input >>> from dmenu. It would be nice to x paste into the dmenu rather >>> than >>> typing out a given google search (e.g. when one is searching >>> someone's >>> odd name.) >>> (c) In general, I like the xprop interface and allowing >>> applications >>> other >>> than surf to interact with surf (which is what your new _SURF_FIND >>> feature >>> allows--which is great--which is why we need dmenu to get >>> patched!) >> >> There is sselp(1) at http://tools.suckless.org/sselp which reads >> current selection and prints it to stdout, hence enables you to >> integrate it into dmenu's cache or calling surf `sselp` directly. >> There shouldn't be a real need to paste something interactively into >> surf or dmenu really. >> >> Kind regards, >> Anselm >> > > What about cases in which one wishes to both type a few words and then > paste? For example, when I want > to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my > selection buffer) but I also > want to do something like "University of Wherever" + "Bob McCrue" where the > first part is something > I type in by hand and the second part is something I want to just "paste" > in? The same argument > could be launched with respect to the find feature (which now utilizes > dmenu). > > Or maybe you have something else in mind when you talk of "integrating into > dmenu's cache"? If you use dmenu for querying wikipedia, asking google, or whatever I think all you want is a usual prefix and then type in the rest of your query. I agree that dmenu's text editing is limited and not equally powerful to a usual text edit field. But perhaps this proves to be an advantage when used for a while, let's see what we think after using it for some time. Often we might conclude less is more. Kind regards, Anselm
Re: [dev] [surf] next release
On Wed, 21 Oct 2009, Julien Steinhauser wrote: On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: What about cases in which one wishes to both type a few words and then paste? For example, when I want to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also want to do something like "University of Wherever" + "Bob McCrue" where the first part is something I type in by hand and the second part is something I want to just "paste" in? The same argument could be launched with respect to the find feature (which now utilizes dmenu). Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"? Peter sselp does it also in case you wish to paste "and" write. Select something, then run echo `sselp` | dmenu, tab, space and what you write after that follows your selection, terminate dmenu and all is printed out. Fair enough; but the functionality still seems a bit stifling, doesn't it? Particular problems I would see with this (in terms of "workflow") are as follow. Let's use the simple example of the surf-find function which now uses dmenu. (1) You have to know in advance if you want to paste into the input field or not (on your proposal). But sometimes we don't want what is in our x selection buffer to show up as an option in the find. For example, if I have a huge chunk of code in my x selection buffer, but I want to find someone's name. But sometimes we do want what is in our x selection buffer to show up as a option in find. Hence, we have to know in advance on your proposal, which strikes me as bad. (2) You can't easily just type something, then paste, then keep typing something (on your proposal). In fact, you can't type something and then paste either, as the paste selection disappears after you start typing. This again seems like a limitation. These considerations suggest that perhaps a patch to dmenu should be re-evaluated for inclusion in vanilla? Yours, Peter
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 16:24:55 +0200 Julien Steinhauser wrote: > On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: > > > > What about cases in which one wishes to both type a few words and > > then paste? For example, when I want to do a smart prefix search > > (via dmenu) on Bob McCrue (who sits in my selection buffer) but I > > also want to do something like "University of Wherever" + "Bob > > McCrue" where the first part is something I type in by hand and the > > second part is something I want to just "paste" in? The same > > argument could be launched with respect to the find feature (which > > now utilizes dmenu). > > > > Or maybe you have something else in mind when you talk of > > "integrating into dmenu's cache"? > > > > Peter > > sselp does it also in case you wish to paste "and" write. > Select something, then run echo `sselp` | dmenu, tab, space > and what you write after that follows your selection, > terminate dmenu and all is printed out. and what if you want to have first the string you type yourself, and then the pasted stuff? i also think paste support in dmenu would be nice. Dieter
Re: [dev] [surf] next release
2009/10/21 Peter John Hartman : > > > On Wed, 21 Oct 2009, Julien Steinhauser wrote: > >> On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: >>> >>> What about cases in which one wishes to both type a few words and then >>> paste? For example, when I want >>> to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my >>> selection buffer) but I also >>> want to do something like "University of Wherever" + "Bob McCrue" where >>> the first part is something >>> I type in by hand and the second part is something I want to just "paste" >>> in? The same argument >>> could be launched with respect to the find feature (which now utilizes >>> dmenu). >>> >>> Or maybe you have something else in mind when you talk of "integrating >>> into dmenu's cache"? >>> >>> Peter >> >> sselp does it also in case you wish to paste "and" write. >> Select something, then run echo `sselp` | dmenu, tab, space >> and what you write after that follows your selection, >> terminate dmenu and all is printed out. >> >> >> > > Fair enough; but the functionality still seems a bit stifling, doesn't it? > Particular problems I would see with this (in terms of "workflow") are as > follow. > > Let's use the simple example of the surf-find function which now uses dmenu. > > (1) You have to know in advance if you want to paste into the input field or > not (on your proposal). > But sometimes we don't want what is in our x selection buffer to show up as > an option in the find. > For example, if I have a huge chunk of code in my x selection buffer, but I > want to find someone's name. But sometimes we do want what is in our x > selection buffer to show up as a option in find. > Hence, we have to know in advance on your proposal, which strikes me as bad. > > (2) You can't easily just type something, then paste, then keep typing > something (on your proposal). > In fact, you can't type something and then paste either, as the paste > selection disappears after > you start typing. This again seems like a limitation. > > These considerations suggest that perhaps a patch to dmenu should be > re-evaluated for inclusion in > vanilla? Well I'd be fine to support ^p in order to paste selection until "\n" into dmenu if that helps. Kind regards, Anselm
Re: [dev] [surf] next release
2009/10/21 Anselm R Garbe : > 2009/10/21 Peter John Hartman : >> >> >> On Wed, 21 Oct 2009, Julien Steinhauser wrote: >> >>> On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: What about cases in which one wishes to both type a few words and then paste? For example, when I want to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also want to do something like "University of Wherever" + "Bob McCrue" where the first part is something I type in by hand and the second part is something I want to just "paste" in? The same argument could be launched with respect to the find feature (which now utilizes dmenu). Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"? Peter >>> >>> sselp does it also in case you wish to paste "and" write. >>> Select something, then run echo `sselp` | dmenu, tab, space >>> and what you write after that follows your selection, >>> terminate dmenu and all is printed out. >>> >>> >>> >> >> Fair enough; but the functionality still seems a bit stifling, doesn't it? >> Particular problems I would see with this (in terms of "workflow") are as >> follow. >> >> Let's use the simple example of the surf-find function which now uses dmenu. >> >> (1) You have to know in advance if you want to paste into the input field or >> not (on your proposal). >> But sometimes we don't want what is in our x selection buffer to show up as >> an option in the find. >> For example, if I have a huge chunk of code in my x selection buffer, but I >> want to find someone's name. But sometimes we do want what is in our x >> selection buffer to show up as a option in find. >> Hence, we have to know in advance on your proposal, which strikes me as bad. >> >> (2) You can't easily just type something, then paste, then keep typing >> something (on your proposal). >> In fact, you can't type something and then paste either, as the paste >> selection disappears after >> you start typing. This again seems like a limitation. >> >> These considerations suggest that perhaps a patch to dmenu should be >> re-evaluated for inclusion in >> vanilla? > > Well I'd be fine to support ^p in order to paste selection until "\n" > into dmenu if that helps. Or more generically having some control-key interface that calls a script and reads a line and puts that as input. Kind regards, Anselm
Re: [dev] [surf] next release
I always use shift+insert or middleclick for pasting, what's the unix way to paste? ^p is already supported in surf, and mozilla load pages if you paste them in the web canvas...so which is the 'correct' one? :) And yeah i didn't mention ^C^V because I never use them and can break other keybindings of the underlying app. Like the unix-editing for textentries on gtk apps, because ^W is the default keybinding for closing windows on Gnome apps. Anselm R Garbe wrote: 2009/10/21 Peter John Hartman : On Wed, 21 Oct 2009, Julien Steinhauser wrote: On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: What about cases in which one wishes to both type a few words and then paste? For example, when I want to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also want to do something like "University of Wherever" + "Bob McCrue" where the first part is something I type in by hand and the second part is something I want to just "paste" in? The same argument could be launched with respect to the find feature (which now utilizes dmenu). Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"? Peter sselp does it also in case you wish to paste "and" write. Select something, then run echo `sselp` | dmenu, tab, space and what you write after that follows your selection, terminate dmenu and all is printed out. Fair enough; but the functionality still seems a bit stifling, doesn't it? Particular problems I would see with this (in terms of "workflow") are as follow. Let's use the simple example of the surf-find function which now uses dmenu. (1) You have to know in advance if you want to paste into the input field or not (on your proposal). But sometimes we don't want what is in our x selection buffer to show up as an option in the find. For example, if I have a huge chunk of code in my x selection buffer, but I want to find someone's name. But sometimes we do want what is in our x selection buffer to show up as a option in find. Hence, we have to know in advance on your proposal, which strikes me as bad. (2) You can't easily just type something, then paste, then keep typing something (on your proposal). In fact, you can't type something and then paste either, as the paste selection disappears after you start typing. This again seems like a limitation. These considerations suggest that perhaps a patch to dmenu should be re-evaluated for inclusion in vanilla? Well I'd be fine to support ^p in order to paste selection until "\n" into dmenu if that helps. Kind regards, Anselm
Re: [dev] [surf] next release
On Wed, 21 Oct 2009, Anselm R Garbe wrote: 2009/10/21 Anselm R Garbe : 2009/10/21 Peter John Hartman : On Wed, 21 Oct 2009, Julien Steinhauser wrote: On Wed, Oct 21, 2009 at 09:17:52AM -0400, Peter John Hartman wrote: What about cases in which one wishes to both type a few words and then paste? For example, when I want to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also want to do something like "University of Wherever" + "Bob McCrue" where the first part is something I type in by hand and the second part is something I want to just "paste" in? The same argument could be launched with respect to the find feature (which now utilizes dmenu). Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"? Peter sselp does it also in case you wish to paste "and" write. Select something, then run echo `sselp` | dmenu, tab, space and what you write after that follows your selection, terminate dmenu and all is printed out. Fair enough; but the functionality still seems a bit stifling, doesn't it? Particular problems I would see with this (in terms of "workflow") are as follow. Let's use the simple example of the surf-find function which now uses dmenu. (1) You have to know in advance if you want to paste into the input field or not (on your proposal). But sometimes we don't want what is in our x selection buffer to show up as an option in the find. For example, if I have a huge chunk of code in my x selection buffer, but I want to find someone's name. But sometimes we do want what is in our x selection buffer to show up as a option in find. Hence, we have to know in advance on your proposal, which strikes me as bad. (2) You can't easily just type something, then paste, then keep typing something (on your proposal). In fact, you can't type something and then paste either, as the paste selection disappears after you start typing. This again seems like a limitation. These considerations suggest that perhaps a patch to dmenu should be re-evaluated for inclusion in vanilla? Well I'd be fine to support ^p in order to paste selection until "\n" into dmenu if that helps. Or more generically having some control-key interface that calls a script and reads a line and puts that as input. Kind regards, Anselm Like Shift-Insert? :-) Or have I misunderstood your proposal? Peter
Re: Re: [dev] dwm 5.7.2 and pertag patch
* [21.10.2009 09:00]: > Mysteroiusly the pertag patch was not uploaded to the hg repo =/ > I have uploaded it again... > It's changeset 0e366e9744ec Now everything works fine again. Many thanks. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments DU BIST TERRORIST!- www.dubistterrorist.de pgpzbbzTRARvr.pgp Description: PGP signature
Re: [dev] [surf] next release
2009/10/21 pancake : > I always use shift+insert or middleclick for pasting, what's the unix way to > paste? > ^p is already supported in surf, and mozilla load pages if you paste them in > the > web canvas...so which is the 'correct' one? :) > > And yeah i didn't mention ^C^V because I never use them and can break other > keybindings of the underlying app. Like the unix-editing for textentries on > gtk > apps, because ^W is the default keybinding for closing windows on Gnome > apps. In dmenu we don't need to worry about other apps, because dmenu grabs the keyboard and during the time until ungrabbing it we can override any key combination we like. That's why I propose having a Key interface in dmenu like in dwm that can be used to execute a command to insert at current text position and good is. I prefer ^p to Shift-Insert by default. Kind regards, Anselm
Re: [dev] [surf] view source?
Hello, when I build last tip, I have this error : surf.c: In function ‘source’: surf.c:695: error: implicit declaration of function ‘webkit_web_view_get_view_source_mode’ surf.c:696: error: implicit declaration of function ‘webkit_web_view_set_view_source_mode’ I commented out from line 693 to 696 in surf.c as I don't know how to declare the two functions properly, but there's probably a cleaner method to let surf build smoothly.
Re: [dev] [surf] next release
On Wed, 21 Oct 2009, Anselm R Garbe wrote: 2009/10/21 pancake : I always use shift+insert or middleclick for pasting, what's the unix way to paste? ^p is already supported in surf, and mozilla load pages if you paste them in the web canvas...so which is the 'correct' one? :) And yeah i didn't mention ^C^V because I never use them and can break other keybindings of the underlying app. Like the unix-editing for textentries on gtk apps, because ^W is the default keybinding for closing windows on Gnome apps. In dmenu we don't need to worry about other apps, because dmenu grabs the keyboard and during the time until ungrabbing it we can override any key combination we like. That's why I propose having a Key interface in dmenu like in dwm that can be used to execute a command to insert at current text position and good is. I prefer ^p to Shift-Insert by default. Kind regards, Anselm Ctl-p is fine by me as long as it is established in config.h (i.e.\ as long as the user has an easy chance at over-riding it). Peter
Re: [dev] [surf] view source?
On Wed, 21 Oct 2009, Julien Steinhauser wrote: Hello, when I build last tip, I have this error : surf.c: In function ‘source’: surf.c:695: error: implicit declaration of function ‘webkit_web_view_get_view_source_mode’ surf.c:696: error: implicit declaration of function ‘webkit_web_view_set_view_source_mode’ I commented out from line 693 to 696 in surf.c as I don't know how to declare the two functions properly, but there's probably a cleaner method to let surf build smoothly. This seems to be a matter of the webkit-gtk+ version you are using. The default in gentoo stable is still 1.1.10 and those functions aren't in it. I think those functions come with 1.1.14 (the latest stable on the webkit-gtk site is 1.1.15). Peter
Re: [dev] [surf] view source?
you have an old version of webkit Julien Steinhauser wrote: Hello, when I build last tip, I have this error : surf.c: In function ‘source’: surf.c:695: error: implicit declaration of function ‘webkit_web_view_get_view_source_mode’ surf.c:696: error: implicit declaration of function ‘webkit_web_view_set_view_source_mode’ I commented out from line 693 to 696 in surf.c as I don't know how to declare the two functions properly, but there's probably a cleaner method to let surf build smoothly.
Re: [dev] [surf] view source?
On Wed, Oct 21, 2009 at 05:08:21PM +0200, pancake wrote: > > you have an old version of webkit > You're right, after upgrading my webkit package, the warnings are gone, the new warnings are even worst, but are not surf related so it's off topic. I'll stay without the view source feature until packages change in the debian repository.
Re: [dev] [surf] next release
On Wed, 21 Oct 2009 11:04:48 -0400 (EDT) Peter John Hartman wrote: > > > On Wed, 21 Oct 2009, Anselm R Garbe wrote: > > > 2009/10/21 pancake : > >> I always use shift+insert or middleclick for pasting, what's the > >> unix way to paste? > >> ^p is already supported in surf, and mozilla load pages if you > >> paste them in the > >> web canvas...so which is the 'correct' one? :) > >> > >> And yeah i didn't mention ^C^V because I never use them and can > >> break other keybindings of the underlying app. Like the > >> unix-editing for textentries on gtk > >> apps, because ^W is the default keybinding for closing windows on > >> Gnome apps. > > > > In dmenu we don't need to worry about other apps, because dmenu > > grabs the keyboard and during the time until ungrabbing it we can > > override any key combination we like. That's why I propose having a > > Key interface in dmenu like in dwm that can be used to execute a > > command to insert at current text position and good is. I prefer ^p > > to Shift-Insert by default. > > > > Kind regards, > > Anselm > > > > Ctl-p is fine by me as long as it is established in config.h (i.e.\ > as long as the user has an easy chance at over-riding it). > > Peter > what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind shift-insert /path/to/other-script.sh i like the general idea, though i'm not sure if it's worth the hassle (bloat?). Dieter
[dev] [dmenu] Putting key combinations in config.h
Hi, In light of the parallel discussion re surf and dmenu, I thought I'd open up the following suggestion: Can we put the various keybindings used in dmenu in config.h rather than dmenu.c? There is one case where I know this will prove useful, namely, the keybinding to close dmenu, which currently is XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be able to close dmenu with the same keystroke, i.e.\ Shift_R. But more generally most other suckless apps have the keybindings in config.h, so why not dmenu? Yours, Peter
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 02:46:44PM +0200, Thomas Dean wrote: > On Wed, Oct 21, 2009 at 10:44:25AM +0200, Thomas Dean wrote: > > On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > > > Sure, please file an issue. > > > > Hmm, I need a Google account for that? ... No! :-) > > Okay, I did it anyway... but why google? :-( > James > Free, no setup bug tacker + hg. -- Jake Todd // If it isn't broke, tweak it! pgpwA8DQnth6G.pgp Description: PGP signature
Re: [dev] [wmii] Curves on top of window borders
On Tue, Oct 20, 2009 at 10:26:16PM -0400, Kris Maglione wrote: > On Fri, Oct 16, 2009 at 01:51:57PM -0500, Nathan Neff wrote: >> Is there a way to turn off the small 3 pixel curves on the top left and top >> right of the topmost windows on each column? > > No, they're functional and unobtrusive. I don't see a reason to bloat the > configuration with an option to turn them off. They are functional? What are they for? > > -- > Kris Maglione > > Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs, and the Universe trying > to produce bigger and better idiots. So far, the Universe is winning. > --Rich Cook > >
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 01:32:54PM +, Jacob Todd wrote: On Wed, Oct 21, 2009 at 02:46:44PM +0200, Thomas Dean wrote: On Wed, Oct 21, 2009 at 10:44:25AM +0200, Thomas Dean wrote: > On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > > Sure, please file an issue. > > Hmm, I need a Google account for that? ... No! :-) Okay, I did it anyway... but why google? :-( Free, no setup bug tacker + hg. Yep, plus simple and effective, and I can close bugs via hg commits. Plus, you can create a Google account with any email address, and it only takes 30 seconds or so. It might be a pain, but it cuts down on spam considerably. When I had the trac bug tracker, I got at least one spam a day after the first week or so. And trac didn't let you delete or modify them without hacking the db. -- Kris Maglione It is best to read the weather forecast before praying for rain. --Mark Twain
Re: [dev] [wmii] Curves on top of window borders
On Wed, Oct 21, 2009 at 07:51:04PM +0200, Moritz Wilhelmy wrote: On Tue, Oct 20, 2009 at 10:26:16PM -0400, Kris Maglione wrote: On Fri, Oct 16, 2009 at 01:51:57PM -0500, Nathan Neff wrote: Is there a way to turn off the small 3 pixel curves on the top left and top right of the topmost windows on each column? No, they're functional and unobtrusive. I don't see a reason to bloat the configuration with an option to turn them off. They are functional? What are they for? They're draggable. -- Kris Maglione I can hardly see how anyone ought to wish Christianity to be true; for if so the plain language of the text seems to show that the men who do not believe, and this would include my Father, Brother, and almost all my best friends, will be everlastingly punished. And this is a damnable doctrine. --Charles Darwin
Re: [dev] [surf] next release
On Wed, Oct 21, 2009 at 1:08 PM, Dieter Plaetinck wrote: > On Wed, 21 Oct 2009 11:04:48 -0400 (EDT) > Peter John Hartman wrote: > > > > > > > On Wed, 21 Oct 2009, Anselm R Garbe wrote: > > > > > 2009/10/21 pancake : > > >> I always use shift+insert or middleclick for pasting, what's the > > >> unix way to paste? > > >> ^p is already supported in surf, and mozilla load pages if you > > >> paste them in the > > >> web canvas...so which is the 'correct' one? :) > > >> > > >> And yeah i didn't mention ^C^V because I never use them and can > > >> break other keybindings of the underlying app. Like the > > >> unix-editing for textentries on gtk > > >> apps, because ^W is the default keybinding for closing windows on > > >> Gnome apps. > > > > > > In dmenu we don't need to worry about other apps, because dmenu > > > grabs the keyboard and during the time until ungrabbing it we can > > > override any key combination we like. That's why I propose having a > > > Key interface in dmenu like in dwm that can be used to execute a > > > command to insert at current text position and good is. I prefer ^p > > > to Shift-Insert by default. > > > > > > Kind regards, > > > Anselm > > > > > > > Ctl-p is fine by me as long as it is established in config.h (i.e.\ > > as long as the user has an easy chance at over-riding it). > > > > Peter > > > > what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind > shift-insert /path/to/other-script.sh > > i like the general idea, though i'm not sure if it's worth the hassle > (bloat?). > > Dieter > > A config.h approach seems best here, dmenu already does that for defaults and it could be inconsistent if the calling app chose demnu's bindings rather than dmenu choosing for itself.
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > Hi, > > In light of the parallel discussion re surf and dmenu, I thought I'd open > up > the following suggestion: Can we put the various keybindings used in dmenu > in config.h rather than dmenu.c? There is one case where I know this will > prove useful, namely, the keybinding to close dmenu, which currently is > XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be > able to close dmenu with the same keystroke, i.e.\ Shift_R. But more > generally most other suckless apps have the keybindings in config.h, so why > not dmenu? > > Yours, > Peter > > And I already posted to the previous discussion before reading this, great. As I stated, it would be better than a parameter passed to dmenu on the command line. While it would be excessive, could it also be possible to have the keybindings change the options available, not the input? Thinking something along the line of a dmenu-based clone of Google's Suggestions feature. Being able to type something then have dynamic results, rather than static. This would be a lot more complex I'd bet than what Anselm suggested.
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, 21 Oct 2009, Colin Shea wrote: On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman wrote: Hi, In light of the parallel discussion re surf and dmenu, I thought I'd open up the following suggestion: Can we put the various keybindings used in dmenu in config.h rather than dmenu.c? There is one case where I know this will prove useful, namely, the keybinding to close dmenu, which currently is XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be able to close dmenu with the same keystroke, i.e.\ Shift_R. But more generally most other suckless apps have the keybindings in config.h, so why not dmenu? Yours, Peter And I already posted to the previous discussion before reading this, great. As I stated, it would be better than a parameter passed to dmenu on the command line. While it would be excessive, could it also be possible to have the keybindings change the options available, not the input? Thinking something along the line of a dmenu-based clone of Google's Suggestions feature. Being able to type something then have dynamic results, rather than static. This would be a lot more complex I'd bet than what Anselm suggested. Hi, 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question. 2. I don't understand the subsequent request, although I've never used "Google's Suggestions" either. What do you have in mind? Peter
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 2:48 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > > > On Wed, 21 Oct 2009, Colin Shea wrote: > > On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman < >> peterjohnhart...@gmail.com> wrote: >> Hi, >> >> In light of the parallel discussion re surf and dmenu, I thought I'd >> open up >> the following suggestion: Can we put the various keybindings used in >> dmenu >> in config.h rather than dmenu.c? There is one case where I know this >> will >> prove useful, namely, the keybinding to close dmenu, which currently >> is >> XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to >> be >> able to close dmenu with the same keystroke, i.e.\ Shift_R. But more >> generally most other suckless apps have the keybindings in config.h, >> so why >> not dmenu? >> >> Yours, >> Peter >> >> >> And I already posted to the previous discussion before reading this, >> great. >> >> As I stated, it would be better than a parameter passed to dmenu on the >> command line. >> >> While it would be excessive, could it also be possible to have the >> keybindings change the options available, not the input? Thinking >> something along the line of a dmenu-based clone of Google's >> Suggestions feature. Being able to type something then have dynamic >> results, rather than static. This would be a lot more complex I'd bet than >> what Anselm suggested. >> >> >> > Hi, > > 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. > dmenu.c question. > > 2. I don't understand the subsequent request, although I've never used > "Google's Suggestions" either. What do you have in mind? > > Peter I don't know if Google enabled it for everyone, but if you log into your Google Account then start searching, it will provide possible completions of your search term. So if you typed "do" into the search box, the first option in the drop down would be "dog", but if you then typed "w" instead of selecting it, it would return "down", etc. It also ties in with your previous search history, so with "com" computer would rate higher than complete, for instance.
[dev] ReadItLater for surf
Hi, I am using surf, and like it very much. One thing I am missing over Firefix is the something similar to the ReadItLater plugin in Firefox, where i can rightclick on a link and bookmark it for later use. I am pretty new to c programming, so please don't be too hard. It would also help, if you could point me to the right direction. Until now I found out, that I got to to add a item to the item[], write a function to write the url to a file. What I am missing is, how do I determine, that I rightclicked on a link and get the url. Thanks for your answers in advance. bye richi
Re: [dev] ReadItLater for surf
On 21-10-2009 21:08:24, Richard Pöttler wrote: > Hi, > > I am using surf, and like it very much. One thing I am missing over > Firefix is the something similar to the ReadItLater plugin in > Firefox, where i can rightclick on a link and bookmark it for later > use. > > I am pretty new to c programming, so please don't be too hard. It > would also help, if you could point me to the right direction. > > Until now I found out, that I got to to add a item to the item[], > write a function to write the url to a file. What I am missing is, > how do I determine, that I rightclicked on a link and get the url. > > Thanks for your answers in advance. > > bye > richi Hi, How about this bookmark patch I posted yesterday or around? Regards, Ted -- === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [dev] ReadItLater for surf
Tadeusz Sośnierz schrieb: On 21-10-2009 21:08:24, Richard Pöttler wrote: I am using surf, and like it very much. One thing I am missing over Firefix is the something similar to the ReadItLater plugin in Firefox, where i can rightclick on a link and bookmark it for later use. I am pretty new to c programming, so please don't be too hard. It would also help, if you could point me to the right direction. Until now I found out, that I got to to add a item to the item[], write a function to write the url to a file. What I am missing is, how do I determine, that I rightclicked on a link and get the url. Thanks for your answers in advance. How about this bookmark patch I posted yesterday or around? I overlooked that... Seems to solve my problem. Thanks for your answer. Sorry for the noise. bye richi
[dev] [dmenu] Cache on start option?
Is there a cache on start of /bin folders option vs only when we select the hot key to trigger dmenu? Reason being, it might be preferred to cache the bin following DWM start vs, when somebody finally gets to executing dmenu. ie. 1) Start DWM 2) After start of DWM, execute DMenu -cache (to cache/scan all bin folders into $HOME/.dmenu). 3) Somebody finally executes DMenu to choose an application immediately vs. waiting for DMenu to also cache (all bin folders). VS. Currently, 1) Start DWM 2) Wait for DMenu to be executed by somebody, then somebody has to sit and wait for DMenu to cache bin folders before choosing their application. -- Roger http://rogerx.freeshell.org
Re: [dev] [dmenu] Cache on start option?
On Wed, Oct 21, 2009 at 11:35:26AM -0800, Roger wrote: 1) Start DWM 2) After start of DWM, execute DMenu -cache (to cache/scan all bin folders into $HOME/.dmenu). 3) Somebody finally executes DMenu to choose an application immediately vs. waiting for DMenu to also cache (all bin folders). Start dwm from a script. VS. Currently, 1) Start DWM 2) Wait for DMenu to be executed by somebody, then somebody has to sit and wait for DMenu to cache bin folders before choosing their application. It takes a few miliseconds. -- Kris Maglione Fast, fat computers breed slow, lazy programmers. --Robert Hummel
Re: [dev] [surf] view source?
On Wed, Oct 21, 2009 at 06:57:57PM +0200, Julien Steinhauser wrote: > > On Wed, Oct 21, 2009 at 05:08:21PM +0200, pancake wrote: > > > > you have an old version of webkit > > > You're right, after upgrading my webkit package, the warnings are gone, > the new warnings are even worst, but are not surf related so it's off topic. > I'll stay without the view source feature until packages change > in the debian repository. > All is fixed! After logging out from dwm I've seen the solution written in the console, I just had to install libxslt1-dev and all is fine again.
Re: [dev] [dmenu] Cache on start option?
On Wed, 2009-10-21 at 16:00 -0400, Kris Maglione wrote: > On Wed, Oct 21, 2009 at 11:35:26AM -0800, Roger wrote: > >1) Start DWM > >2) After start of DWM, execute DMenu -cache (to cache/scan all bin > >folders into $HOME/.dmenu). > >3) Somebody finally executes DMenu to choose an application immediately > >vs. waiting for DMenu to also cache (all bin folders). > > Start dwm from a script. Already done via .xinitrc. > >VS. Currently, > > > >1) Start DWM > >2) Wait for DMenu to be executed by somebody, then somebody has to sit > >and wait for DMenu to cache bin folders before choosing their > >application. > > It takes a few miliseconds. ... depending on size of bin folders. /bin $ du -kh --max-depth=0 7.9M /sbin $ du -kh --max-depth=0 21M /usr/bin $ du -kh --max-depth=0 551M /usr/sbin $ du -kh --max-depth=0 43M ... of course, rm -f /usr/bin/* would speed things up. ;-) -- Roger http://rogerx.freeshell.org
Re: [dev] [dmenu] Putting key combinations in config.h
[2009-10-21 14:48] Peter John Hartman > On Wed, 21 Oct 2009, Colin Shea wrote: > > On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman > > wrote: > > > > Can we put the various keybindings used in dmenu > > in config.h rather than dmenu.c? > > But more > > generally most other suckless apps have the keybindings in config.h, > > so why > > not dmenu? > > As I stated, it would be better than a parameter passed to dmenu on the > > command line. > 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. > dmenu.c question. Do we really agree? At least, I do not, and I hope you don't also when you read this mail. Dwm is a very personal program which everyone tailors to his needs. Here configurable shortcuts are of much value and do not conflict much with other users/different systems. Dmenu, on the other hand, is a quite generic program which sould be the same everywhere. If people start configuring the key strokes, one needs different dmenus for different users on one system. Also, one may not be able to use dmenu on a different machine. That's to avoid, for sure. Configuring dmenu's look is one thing, but changing it's behavior is another. I do recommend *not* to change the behavior. Thus don't put such options to config.h. If you *really* need to configure the key strokes, then do it in a way that preserves the standard behavior. Using command line parameters for it would be an example. But better don't do it at all. Have you adjusted the key strokes of e.g. w3m? You may get a bit more produktivity then ... but you'll lose all of it and more when you are on another machine. Hence, you better learn the standard configuration and don't depend on your machine. Dmenu should be seen like grep or sed -- a standard tool that works the same everywhere. Please think about it. meillo
Re: [dev] [dmenu] Putting key combinations in config.h
[2009-10-21 14:44] Colin Shea > > Being able to type something then have dynamic > results, rather than static. If you mean what I think you mean, then *omg*. Never forget: It's all about avoiding complexity! meillo
Re: [dev] [dmenu] Cache on start option?
dmenu can read items from stdin. You may create the cache yourself with e.g. "ls -1 -colors=never /bin >cache", then do "dmenu at the dmenu_run script for details.
Re: [dev] [surf] next release
Surf should *not* handle downloads or display source, this are clearly and obviously best handled by external tools and there is zero reason for them to be part of any browser. uriel On Wed, Oct 21, 2009 at 10:14 AM, Enno Boland (Gottox) wrote: > Hi! > > I'm going to release 0.3 this or next week, depending on how much time > I can investigate. Please recheck tip and give feedback, as there are > some bigger changes. > > * persistant/concurrent cookies are working (hopefully) > * removing urlbar/searchbar and using dmenu instead > * if the window is shrinked below a defined size, the zoom factor is > automaticly decreased. This is usefull on small screens and tiling > window manager. > * searching works from an XProperty now. > > ToDo for 0.3 release: > * get downloads working again. > > regards > Enno > >
Re: [dev] [dmenu] Cache on start option?
> "ls -1 -colors=never Hah! (please excuse my Schadenfreude in case this was inappropriate)
Re: [dev] [dmenu] Cache on start option?
On Wed, 2009-10-21 at 23:24 +0200, frederic wrote: > > dmenu can read items from stdin. You may create the cache yourself with > e.g. "ls -1 -colors=never /bin >cache", then do "dmenu at the dmenu_run script for details. Bingo! I'll give it a try when I get a chance. Thanks! ;-) -- Roger http://rogerx.freeshell.org
Re: [dev] [surf] next release
But the source looks so neat in the browser... :( This list is not worth reading any more. On Wed, Oct 21, 2009 at 11:47 PM, Uriel wrote: > Surf should *not* handle downloads or display source, this are clearly > and obviously best handled by external tools and there is zero reason > for them to be part of any browser. > > uriel > > On Wed, Oct 21, 2009 at 10:14 AM, Enno Boland (Gottox) > wrote: >> Hi! >> >> I'm going to release 0.3 this or next week, depending on how much time >> I can investigate. Please recheck tip and give feedback, as there are >> some bigger changes. >> >> * persistant/concurrent cookies are working (hopefully) >> * removing urlbar/searchbar and using dmenu instead >> * if the window is shrinked below a defined size, the zoom factor is >> automaticly decreased. This is usefull on small screens and tiling >> window manager. >> * searching works from an XProperty now. >> >> ToDo for 0.3 release: >> * get downloads working again. >> >> regards >> Enno >> >> > >
Re: [dev] [surf] next release
On Wed, Oct 21, 2009 at 4:54 PM, hiro <23h...@googlemail.com> wrote: > But the source looks so neat in the browser... :( > > This list is not worth reading any more. what keymap or MUA are you using that makes it easier to whine constantly than unsubscribe -- # Kurt H Maier
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, 21 Oct 2009, markus schnalke wrote: [2009-10-21 14:48] Peter John Hartman On Wed, 21 Oct 2009, Colin Shea wrote: On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman wrote: Can we put the various keybindings used in dmenu in config.h rather than dmenu.c? But more generally most other suckless apps have the keybindings in config.h, so why not dmenu? As I stated, it would be better than a parameter passed to dmenu on the command line. 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. dmenu.c question. Do we really agree? At least, I do not, and I hope you don't also when you read this mail. I guess not! We agree at least on the first part: that it should be in /either/ dmenu.c or config.h and not passed to it from the commandline. Fair enough. Dwm is a very personal program which everyone tailors to his needs. Here configurable shortcuts are of much value and do not conflict much with other users/different systems. Dmenu, on the other hand, is a quite generic program which sould be the same everywhere. If people start configuring the key strokes, one needs different dmenus for different users on one system. Also, one may not be able to use dmenu on a different machine. That's to avoid, for sure. [snip] Dmenu should be seen like grep or sed -- a standard tool that works the same everywhere. I'm not convinced that dmenu shouldn't have keybindings right out in the open and in config.h. I do, at least, see your point. (A better analogy would be 'less'. Imagine instead of q quiting out of less someone hacked up a variant that had r quit. O the pain!) However, I do see the real need to configure at least the keybinding I mentioned before, namely, the Esc keybinding. In a lot of cases, it is nice to bind the exact same key which opens the menu to the close menu function, e.g.\ in the case of the "Windows" key, or in my case, the Super_R key; and in some cases Esc might not be the best guy for the job (although I prefer having both Esc and the Super_R key precisely because other users will get upset.) I'm not sure if I have a positive solution. If there aren't any other cases when it would be useful to fiddle with the default keybindings, then we probably shouldn't bother. But maybe I'm not being creative enough? Peter
Re: [dev] [dmenu] Cache on start option?
On Wed, Oct 21, 2009 at 01:00:25PM -0800, Roger wrote: On Wed, 2009-10-21 at 16:00 -0400, Kris Maglione wrote: Start dwm from a script. Already done via .xinitrc. Then just generate the cache at startup. It takes a few miliseconds. ... depending on size of bin folders. The size of the binaries is of absolutely no consequence, only the number of directory entries. -- Kris Maglione A program that produces incorrect results twice as fast is infinitely slower. --John Osterhout
Re: [dev] 10gui - interesting concepts
On Thu 15 Oct 2009 at 13:03:15 PDT Bobby wrote: I misread your email as meaning he never used more than two fingers. You are correct, and I agree with your comments. In addition, I think that the main hurdle in all of this is that my hands are moved away from the keyboard yet again to a different device that has no tactile feedback, added costs, another new paradigm to learn, and no added benefits over existing tiling window managers. Cool idea, but lacks any serious application in my opinion. Aside from the problems others have mentioned, I can't imagine how having to reach over that overblown touchpad in order to use the keyboard would be anything except uncomfortably awkward. Either the touchpad would put my arms in a carpal tunnel aggravating position, or the keyboard would. The "continuum" layout is interesting, but doesn't seem to require their ten-finger touchpad. It doesn't seem that it would be very hard to implement the same ideas in a keyboard-only windowmanager.
Re: [dev] 10gui - interesting concepts
It doesn't seem very hard to implement in a keyboard only environment, but I'm not sure that the finished product would be very interesting, either. It seems like a crippled tiling window manager. The only points that made it interesting (not usable, just interesting) are lost when the touchpad is removed. I would rather stick to dwm. On 10/21/09, Charlie Kester wrote: > On Thu 15 Oct 2009 at 13:03:15 PDT Bobby wrote: >>I misread your email as meaning he never used more than two fingers. >>You are correct, and I agree with your comments. In addition, I think >>that the main hurdle in all of this is that my hands are moved away >>from the keyboard yet again to a different device that has no tactile >>feedback, added costs, another new paradigm to learn, and no added >>benefits over existing tiling window managers. Cool idea, but lacks any >>serious application in my opinion. > > Aside from the problems others have mentioned, I can't imagine how > having to reach over that overblown touchpad in order to use the > keyboard would be anything except uncomfortably awkward. > > Either the touchpad would put my arms in a carpal tunnel aggravating > position, or the keyboard would. > > The "continuum" layout is interesting, but doesn't seem to require their > ten-finger touchpad. It doesn't seem that it would be very hard to > implement the same ideas in a keyboard-only windowmanager. > > -- Sent from my mobile device
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 18:55, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > I guess not! We agree at least on the first part: that it should be in > /either/ dmenu.c or config.h and not passed to it from the commandline. > Fair enough. > > Dwm is a very personal program which everyone tailors to his needs. >> Here configurable shortcuts are of much value and do not conflict much >> with other users/different systems. >> >> Dmenu, on the other hand, is a quite generic program which sould be the >> same everywhere. If people start configuring the key strokes, one needs >> different dmenus for different users on one system. Also, one may not be >> able to use dmenu on a different machine. That's to avoid, for sure. >> > > [snip] > > Dmenu should be seen like grep or sed -- a standard tool that works the >> same everywhere. >> > > I'm not convinced that dmenu shouldn't have keybindings right out in the > open and in config.h. I do, at least, see your point. (A better analogy > would be 'less'. Imagine instead of q quiting out of less someone hacked > up a variant that had r quit. O the pain!) > > However, I do see the real need to configure at least the keybinding I > mentioned before, namely, the Esc keybinding. In a lot of cases, it is > nice > to bind the exact same key which opens the menu to the close menu function, > e.g.\ in the case of the "Windows" key, or in my case, the Super_R key; and > in some cases Esc might not be the best guy for the job (although I prefer > having both Esc and the Super_R key precisely because other users will get > upset.) > > I'm not sure if I have a positive solution. If there aren't any other > cases > when it would be useful to fiddle with the default keybindings, then we > probably shouldn't bother. But maybe I'm not being creative enough? > Peter > Well dmenu should at least have the defaults in config.h, just like the default colors, etc. Then those who really want functionality X could patch it in themselves, just like any other tools. Just because, say, I add Ctrl-G to open a page in my browser with the current input as the URL doesn't mean (and that probably wouldn't ever) it should become mainstream, or even something widely used. It's my version of dmenu, hacked to what I want/need in a choice selection program. Just like I could have a `less' that does use O to quit rather than q. I don't know about anyone else, but having escape as the default kill key works out really well for me. Of course, I do have caps lock switched with escape, however. It also helps with editing in vim.
Re: [dev] 10gui - interesting concepts
I'll stick with dwm too, but the crippled tiling window manager would be a vast improvement for most users, who don't want to spend the time to learn dwm / xmonad etc, but are spending vast amounts of time managing their windows by hand. I think it's a worthwhile project. The touchpad, however, looks like a real stinker. On Wed, Oct 21, 2009 at 07:52:41PM -0400, Bobby wrote: > It doesn't seem very hard to implement in a keyboard only environment, > but I'm not sure that the finished product would be very interesting, > either. It seems like a crippled tiling window manager. The only > points that made it interesting (not usable, just interesting) are > lost when the touchpad is removed. I would rather stick to dwm. > > On 10/21/09, Charlie Kester wrote: > > On Thu 15 Oct 2009 at 13:03:15 PDT Bobby wrote: > >>I misread your email as meaning he never used more than two fingers. > >>You are correct, and I agree with your comments. In addition, I think > >>that the main hurdle in all of this is that my hands are moved away > >>from the keyboard yet again to a different device that has no tactile > >>feedback, added costs, another new paradigm to learn, and no added > >>benefits over existing tiling window managers. Cool idea, but lacks any > >>serious application in my opinion. > > > > Aside from the problems others have mentioned, I can't imagine how > > having to reach over that overblown touchpad in order to use the > > keyboard would be anything except uncomfortably awkward. > > > > Either the touchpad would put my arms in a carpal tunnel aggravating > > position, or the keyboard would. > > > > The "continuum" layout is interesting, but doesn't seem to require their > > ten-finger touchpad. It doesn't seem that it would be very hard to > > implement the same ideas in a keyboard-only windowmanager. > > > > > > -- > Sent from my mobile device >
[dev] [dwm] Xinerama autocenter issue
I'm floating eclipse across the length of 1.5 monitors using xinerama. Whenever I use a dialog inside eclipse, it tries to center itself and considers the center as the center of the first monitor. Is there a way to fix this? Or is there a better way of streaching apps across monitors? Thanks, Alex
Re: [dev] [dmenu] Putting key combinations in config.h
[2009-10-21 20:07] Colin Shea > > Well dmenu should at least have the defaults in config.h, just like the > default colors, etc. But this encourages people to change them. I already said: Key bindings are *not* like the colors. > Just because, say, I add Ctrl-G > to open a page in my browser with the current input as the URL doesn't mean > (and that probably wouldn't ever) it should become mainstream, or even > something widely used. It better does not become widely used, as ist totally breaks with the concept of dmenu. Dmenu is like it is, in order to not need to build such commands *into* it. Instead wrap a script around which calls the browser. You probably should learn the concept behind dmenu first before you argue on how dmenu should be. meillo
Re: [dev] [dmenu] Putting key combinations in config.h
markus schnalke dixit (2009-10-21, 23:13): > [2009-10-21 14:48] Peter John Hartman > > On Wed, 21 Oct 2009, Colin Shea wrote: > > > On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman > > > wrote: > > > > > > Can we put the various keybindings used in dmenu > > > in config.h rather than dmenu.c? > > > > But more > > > generally most other suckless apps have the keybindings in > > > config.h, so why > > > not dmenu? > > > > As I stated, it would be better than a parameter passed to dmenu on the > > > command line. > > > 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. > > dmenu.c question. > > Do we really agree? At least, I do not, and I hope you don't also when > you read this mail. > > Dwm is a very personal program which everyone tailors to his needs. > Here configurable shortcuts are of much value and do not conflict much > with other users/different systems. > > Dmenu, on the other hand, is a quite generic program which sould be the > same everywhere. If people start configuring the key strokes, one needs > different dmenus for different users on one system. Also, one may not be > able to use dmenu on a different machine. That's to avoid, for sure. > > Configuring dmenu's look is one thing, but changing it's behavior is > another. I do recommend *not* to change the behavior. Thus don't put > such options to config.h. > > If you *really* need to configure the key strokes, then do it in a way > that preserves the standard behavior. Using command line parameters for > it would be an example. But better don't do it at all. > > Have you adjusted the key strokes of e.g. w3m? You may get a bit more > produktivity then ... but you'll lose all of it and more when you are on > another machine. Hence, you better learn the standard configuration and > don't depend on your machine. > > Dmenu should be seen like grep or sed -- a standard tool that works the > same everywhere. > > Please think about it. I agree. My main argument would be, that one usually runs a single instance of dwm per session (or sometimes more when on multiple displays, but still it's a pretty static situation). But then in that session that user may be launching dmenu multiple times for totally unrelated purposes for which different colors and key shortcuts might be suitable (important for visual identification, too). So there could be defaults in config.h, but commandline switches have to stay. Of course, this would not go in tune with the suckless paranoia (doubling functionality, Jesus Christ!!!), so I suppose it should stay as it is :). Best, -- [a]
