Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 14 May 2010 17:01, mobi phil wrote: > 3. I am looking for people who would be interested in writing a vim > clone. I already called it viq (vi quick) I added a comment to mobiphil's blog. Cheers, Anselm
Re: [dev] SWK: The simple widget kit
On 14 May 2010 07:41, Anselm R Garbe wrote: > On Fri, May 14, 2010 at 12:02:47AM +0200, pancake wrote: >> Is simpler to just change a pointer. We can make global. I will do the >> change tomorrow. > > I will review the current state today and provide my comments in detail. I had a look through everything and think overall it is a good starting point. Though we should concentrate on text input now (I know pancake did already something line based here), but I'll focus on this in the x11 part. Very important is proper multiline text input. I also believe we can remove quite a bit of stuff and do some renaming. For example I dislike the Callback term, it is in fact an event handler and should be called accordingly. Cheers, Anselm
Re: [dev] SWK: The simple widget kit
On Sat, 15 May 2010 10:48:38 +0100 Anselm R Garbe wrote: > On 14 May 2010 07:41, Anselm R Garbe wrote: > > On Fri, May 14, 2010 at 12:02:47AM +0200, pancake wrote: > >> Is simpler to just change a pointer. We can make global. I will do the > >> change tomorrow. > > > > I will review the current state today and provide my comments in detail. > > I had a look through everything and think overall it is a good > starting point. Though we should concentrate on text input now (I know > pancake did already something line based here), but I'll focus on this > in the x11 part. Very important is proper multiline text input. > > I also believe we can remove quite a bit of stuff and do some > renaming. For example I dislike the Callback term, it is in fact an > event handler and should be called accordingly. I have pushed the change to make SwkWindow unique in the library, by just changing a pointer, and moving 'running' outside the struct, it was not the right place to put it :) Now the code is few lines more long, but takes more sense. Feel free to change the name of what you like. I agree that the most important part is a multiline text input widget, this will require to fix the support for multiline widgets and. Another issue is the thing that the graphical backend uses font size to draw as a quad primitive..this was a simplicity decision, but imposide some problematics in the process: - you cannot use the drawing backend to draw in surface at pixel-level (no posisblity to create graph widgets, paintbrush or so) - font size is not 'quadratic' (the fonts we are going to use here in swk are going to be fixed size, this means that ALL characters have same width and same height, but this doesnt means height == width which is one of the problematics of SWK actually (feel free to fix this if you find a clear solution).. I think we should have a 2nd variable to handle character width, and not only height. - while font size is drawing position multiplier, result is that you put text and lines on the same position, so you usually need a border to make things draw correctly, so you end up drawing extra space for lines or just reducing font size. (any idea is welcome) phil is writing the direct-framebuffer graphical interface backend for swk, he plans to use it in openmoko device. If you anselm write the x11 backend, and then the android one.. we will be probably covering most of the platforms we use. The thing is that X11 is probably the best option for the backend, so the appliction will be able to look quite better than in SDL does and use the X11 clipboard and so.. we still need to add the clipboard api in the gi backend. I think that having multiple GI backends is problematic because we still dont have it well defiend, so all them will need to change at some point, and its boring to sync all backends at a time. But this 'problem' will be good because it will open our mind to understand other needs or situations where the initial design doesnt fits. I'm looking forward to see the X11 backend working :D --pancake
Re: [dev] SWK: The simple widget kit
On Thu, May 13, 2010 at 06:11:08PM +0200, pancake wrote: > Check t/ui.c and you will understand why SwkWindow is not global variable. > > Do somebody noticed this file? I mean..the UI can be done not only by code.. > also in ascii art. About the other questions..I think i'm not the > right person > to reply those questions :) This reminds me about HTML forms.
[dev] stali and static surf binary
Hi all, I've dropped by in the IRC channel once or twice but that's unreliable, so I thought that I'd send an e-mail to the list, as well. I discovered suckless through stali a week ago when I was searching for information on statically building WebKit browsers for--believe it or not--a new, all-statically linked, uClibc-based distro that I've been working on in private for the past month or two. I wanted to give a shout out to the stali developers (and in general to suckless, I really like your projects and attitude) and to offer whatever limited services or knowledge that I might have. To be honest, however, I've almost abandoned my distro project because of one last stumbling block: how to build a static web browser binary. There are many that claim to have "static builds" (e.g., Seamonkey, Opera, WebKit browsers), but those still rely on the dynamic library loader to bring up X11 and assorted libs (only the web browser engine is built into the binary). My question is if anyone has had luck in getting a browser like surf to build as a _truly_ static binary and if they could share the secrets of their success with me. I've tried hacking around in WebKit on and off for about a month, and I think the last segfaults that I got while trying to run the included sample GtkBrowser had to do with calls to dlopen, so I'm totally lost. I also tried a compromise. Right now, I'm putting all binaries in /bin (like stali) and all config files in individual program directories under /etc/programs (like Windows, in theory), so I tried to build individual toolchains for each program under /etc/programs/foobar and set the lib/include paths and rpaths to the appropriate directories in GCC's specs file. Thus, dynamic libraries would still be used, but at least they would be duplicated, independent, and isolated for each program that needed it. Unfortunately, either due to my inexperience or perhaps more likely some unfortunate hardcoded assumptions about /lib or /usr/lib, I keep getting an error from the dynamic lib loader about libcairo, "can't handle reloc type 0xe in lib". Any ideas here would be greatly appreciated. Best, Ersin -- What Digital Revolution? -- www.whatdigitalrevolution.com Thinking critically about digital worlds.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
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. 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.). Super and other modifiers are for for user, he can use it as Compose key, for switching layout etc. This behaviour is compatible with unix keybindings (http://unix-kb.cat-v.org/). Most (all?) suckless tools follow these rules so there are no problems. Maybe they should be documented somewhere? 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).
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
Hey, On 15/05/2010, anonymous wrote: > This behaviour is compatible with unix keybindings > (http://unix-kb.cat-v.org/). Most (all?) suckless tools follow these > rules so there are no problems. Maybe they should be documented > somewhere? dmenu uses alt for a couple of bindings. Apparently ctrl binds are shell-like and alt binds are vim-like, which is a bit weird (also M-p). I'd prefer to remove the alt ones. That said I do like ^[HJKL] in dwm, surf, etc. wrt uriel's unix shortcuts page, where do ^K and the other common ones come in? cls
Re: [dev] stali and static surf binary
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?
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Sat, May 15, 2010 at 11:56:43PM +, Connor Lane Smith wrote: > On 15/05/2010, anonymous wrote: > dmenu uses alt for a couple of bindings. Apparently ctrl binds are > shell-like and alt binds are vim-like, which is a bit weird (also > M-p). I'd prefer to remove the alt ones. That said I do like ^[HJKL] > in dwm, surf, etc. vi, shell and other original unix programs don't use Alt. In dmenu A-h, A-l, A-j, A-k and others can be changed to readline-like ^b, ^f, ^n and ^p. A-p can be changed to S-Insert or ^y, it is more common. > wrt uriel's unix shortcuts page, where do ^K and the other common ones come > in? Don't know, probably ^K are common now but were not used in UNIX? ^P and ^N are common now too, but i think they were popularized by EMACS, readline and other GNU projects.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Sun, May 16, 2010 at 04:22:27AM +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.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
hjkl for scrolling or cursor movement shouldn't require any metakeys at all. personally I don't care if they don't work on other key layouts; something like that is either trivial to repair or the app is broken. -- # Kurt H Maier
Re: [dev] stali and static surf binary
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. On Sat, May 15, 2010 at 8:08 PM, 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? > > > -- What Digital Revolution? -- www.whatdigitalrevolution.com Thinking critically about digital worlds.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/16/10, Kurt H Maier wrote: > hjkl for scrolling or cursor movement shouldn't require any metakeys > at all. personally I don't care if they don't work on other key > layouts; something like that is either trivial to repair or the app is > broken. My point was that I do not like having to edit the source code or configurations of all apps I use just to be able to scroll efficiently on whatever keyboard I may have. Whether that is done by all apps written in C including a standard keys.h or by using some X-dependant dynamic xmodmap on steroids, I want to be able to configure (some subset of) keybindings centrally. If I need to set up my own repo, patching every app for use with certain keyboard... apps should rather be cross-keyboard.
