Re: ion-3-20080207
. .. ...
Re: Happy New Year
Hi, guys! Happy New Year, from Russia with love! :) And Happy New Year from Norway. Thanks for all the effort and development, Tuomo! /c :)
Re: Not all bindings are defined in cfg_ioncore.lua
On Thu, 02 Aug 2007 22:57:30 +0200, Ted Zlatanov [EMAIL PROTECTED] wrote: The *basic* Ion operations haven't changed much since Ion3 was released. I've had to rewrite my Lua config several times, though, because of small changes to the objects. If this is a problem, then maybe development versions of software aren't for you, then? /c
Re: ion-3rc-09f911029d74e35bd84156c5635688c0.tar.gz
I'm not going to make it easy for all the forkers... How sad... /c
Re: ion-3rc-09f911029d74e35bd84156c5635688c0.tar.gz
Also known as ion-3rc-20070506. There seem to be no darcs changes to pull, and also the online changelog doesn't show the last changes. /c
Are title-bars/tabs necessary? (was Re: Possible? Toggle statusbar)
only window-manager-related space I can afford are the tabs (although I start wondering if they are really necessary too :). I have been wondering about that too - and even tried it for a while. But I am afraid I at some point lost track... The main problem usually is that *terminals* (which are the majority of client windows on my system) don't really tell you in the the window title what you were busy with on them... although probably this is a problem that could be solved. Any good suggestions on a better management without title bars are welcome. :) /c
Re: Not-a-wiki (do we need a community editable site?)
On Mon, 05 Feb 2007 13:01:54 +0100, Tuomo Valkonen [EMAIL PROTECTED] wrote: But do we need a community editable site for Ion? I am not so sure. There is some demand occasionally, but the amount of contributions to the past wikis has not been that huge. Nevertheless, every contributed FAQ entry and such would ease my workload. The benefit of a wiki is to collect pointers to postings to the ML, suggestions picked up during some IRC, or personal experiences, as well as adding to the FAQ - leaving this work to the community can lift away some workload from you: but might add the additionl supervising/clean-up task - which, of course, could be distributed among some core ion users or volunteers. However, I wouldn't count on their steadyness and dedication much more than those that made their servers available for wikis in the past... There's, however, the poor man's wiki option left: put the darcs repository of the home page available on the Web, and send contributions by email (with 'darcs send'), This could be a nice approach to also tackle somehow the spam issue: there aren't *that* many spammers out there that have a darcs repo set up *and* a proper MTA setup... Speaking of which: you ask people to send in patches via darcs, but occasionally some contributors don't manage to get their configuration right. There aren't that many external contributions, but how often do you have to take over those patches sent in via some other way? That might give a rough indication on a possible (in)success rate of the poor man's wiki approach. /c
Re: Broken focus
On Fri, 22 Dec 2006 00:44:12 +0100, csant [EMAIL PROTECTED] wrote: ...unfortunately some keybindings stoped to work. And today's pull fixed it. Thanks, Tuomo - much appreciated :) /c
Re: Broken focus
Hi,
On Thu, 21 Dec 2006 18:47:25 +0100, csant [EMAIL PROTECTED] wrote:
with the last pull the focus model kind of completely broke,
The new fix fixed this issue - many thanks :) But...
...unfortunately some keybindings stoped to work. I have the following in
cfg_tiling.lua:
defbindings(WTiling, {
bdoc(Split current frame vertically.),
kpress(META..S, WTiling.split_at(_, _sub, 'bottom', true)),
bdoc(Go to frame above/below/right/left of current frame.),
kpress(META..Up, ioncore.goto_next(_sub, 'up', {no_ascend=_})),
kpress(META..Down, ioncore.goto_next(_sub, 'down', {no_ascend=_})),
kpress(META..Right, ioncore.goto_next(_sub, 'right')),
kpress(META..Left, ioncore.goto_next(_sub, 'left')),
submap(META..A, {
bdoc(Split current frame horizontally.),
kpress(S, WTiling.split_at(_, _sub, 'right', true)),
bdoc(Destroy current frame.),
kpress(X, WTiling.unsplit_at(_, _sub)),
}),
})
Well - the META..Up and META..Down bindings stopped to work in my
horizontally split frames (Left and Right still work fine...). They were
working before the very last pull. I am a bit confused about whether this
is a new regression in the latest darcs pull, or some misconfiguration on
my side that now became more evident. Any hints are welcome :)
/c
detach.lua broken after upgrade to lua 5.1
Hi, detach.lua script got broken after switching to lua 5.1 in late darcs pulls, with error /usr/local/bin/ion3: /home/csant/.ion3/default-session--0/detach.lua:192: attempt to call a table value /c
Re: darcs snapshot building error with lua 5.1
On Wed, 17 May 2006 20:06:00 +0200, Matthieu Moy [EMAIL PROTECTED] wrote: That should be fixed now, but testers (in particular, non-debian users) on a system that once-upon-a-time was SUSE 9.3, mostly with packages built on the system now. To test: [ install darcs ] darcs get --partial http://iki.fi/tuomov/repos/ion-3/ cd ion-3 sh predist.sh -snapshot autoreconf ./configure configure: error: *** Can't find lua_call in lua. *** Check for liblua installation or --with-lua-libraries or --with-lua-suffix options Note that: 1.) $ autoreconf $ ./configure was working until requiring lua 5.1, and 2.) I can simply conpile by modifying the path to lua in system.mk. /c -- [Quote] I have measured out my life with coffee spoons; ~~~ T.S. Eliot
Re: Transients, queries and so on in too small frames
On Mon, 15 May 2006 09:46:05 +0200, Matthieu Moy [EMAIL PROTECTED] wrote: Tuomo Valkonen [EMAIL PROTECTED] writes: How important is the functionality offered by detach.lua? Could it be improved? snip/ * I can continue using the background application even with a transient on top of it, and I can use several transient with the same application. I really like the way ion handles transients by not assigning them their own frame. I do however see some issues when dealing with non-modal transients that require you to interact with the main window, and a detach.lua-like approach might handle this, as well as transients bigger in size than their parent, in a better way. The problem of simply moving everything into the second, floating layer is that it makes no real sense to have the transients in that layer available on all workspaces. A transient floating in a second layer, but still displayed only on one workspace would make more sense to me. The window manager should be able to detect whether there is a modal transient, and treat that in the traditional way as long as it fits within the size of its parent, or a non-modal one, and treat that in a detach.lua-like way. /c
Re: transients, detach.lua behaviour
Hi, On Wed, 04 Jan 2006 14:43:45 -0100, Felix Schmidt [EMAIL PROTECTED] wrote: My problem is that i only want specific transients to be detached to the other layer, all the others should behave as usual. So i set manage_transcient_with_float to false and float=true in the affected winprops. The effect is that all transients which are not affected by the winprops are now created in a new frame, and not above the window they are transient for ... Is this intended? I changed the default return code of detach.manager to true, which seems to do the job ... Thanks for pointing this out - it was exactly what I had been struggeling with a few days ago, when I decided to give detach.lua a try for a better handling of Gimp. All was fine, except that I was losing the framed transients in other applications. I really like the way Ion handles transients, and think it is a great usability improvement when compared to transients handling of virtually all other window managers I know (maybe I don't know enough of them?) Thanks, and retuning true for detach.manager seems to fix my problems. /c -- [Quote] I have measured out my life with coffee spoons; ~~~ T.S. Eliot
scratchpad key binding (was: Re: MOD1+space push buttons in mozilla)
On Sat, 24 Dec 2005 10:23:05 -0100, Raphael Bauduin [EMAIL PROTECTED] wrote: On 12/20/05, Tuomo Valkonen [EMAIL PROTECTED] wrote: Mod1+space isn't that good key for the scratchpad anyway. Though this is highly subjective and different for everybody, I'm interested to know why you say Mod1+space is a bad choice. I use the scratchpad _a lot_ and I find it very easy to press mod1 with my left Same here - I feel very comfortable with META+space (my META being the Win keey, or Mod4+). If I'd go for an alternative I'd be looking for something along the line of META+Escape, but I don't really see the need for that. /c (just curious)
