headers
,,, | 9 Oct 2007 15:07
Picon

Life, universe, and ION3

Hi all!

Some week ago i read about ION window-manager at the Hungarian Unix 
Portal. Due, I'm an engineering monkey, and i really hates wasting my time playing with the windows
locations, i 
thought the tiling wm would be a good thing for me. So, i pulled down the ION2 from the Debian respository and
give 
it a shot. 
My first thoughts: Simple, efficient and fast.
After that, i dowloaded the ION3 source, and compiled it. Well, it's a 
bit different from the Debian's ION2, but the development is clear. The Run menu file listing is damned fast 
comapared to the GTK+ same function.
I'm still testing it, but i can't find any bug, yet.
Also i have some ideas and thoughts, which i compiled to kind of 
whistlist. Most is not a basic wm feature, but it would be nice in a tabbed, tiling wm. Maybe some of these
already 
developed, but spending 13 hours with the soldering iron, and 3 hours moving bricks every day, leaves me a
small 
time to reading the documentations.

Requested features:

Policy settings for the new window creation. When i run some multyple 
window application (mplayer, gimp), it would be nice if i could set where must the spawned window must to be 
placed. Currently it's follows the mouse pointer. My idea is to be set a policy for every application (tabs)
for 
the method of the new window placement.
Three or four rules (same tile, some tile, any tile, float) would be 
suffice.
(Continue reading)

Permalink | Reply | 37 comments |
headers
Sylvain Abélard | 9 Oct 2007 12:38
Picon

Re: Life, universe, and ION3

> Requested features:
Tuomo said he wouldn't develop new features and focuses on the last
stable ion version.

> Policy settings for the new window creation.
This is done using winprops in cfg_kludges.lua.
I think the main distribution includes some kludges samples.

> Auto size adjust for the fixed size applications at start.

Tuomo thinks this is brain damaged. If he were even to develop that,
what should happen when many apps will try to set their own fixed size
? One cannot decide.
Then, what will happen to your desktop when even a single fixed size
app will come and mess everything up ?

My policy about fixed size apps is preparing the layout for them then
using winprops to make them stick into their allowed space.

> Switching the application to full screen mode, and back
This already exists, grep fullscreen in your cfg_bindings.lua.

> Mouse aided tile resize.
This already exists.

> GUI based configuration tool for the keybindings.
> Support for alternate keybindings.

I don't think there are many users out there still using the default
keybindings.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tuomo Valkonen | 9 Oct 2007 13:20
Picon
Picon
Favicon

Re: Life, universe, and ION3

On 2007-10-09, ,,, <hiena@...> wrote:
> Also i have some ideas and thoughts, which i compiled to kind of
> whistlist. Most is not a basic wm feature, but it would be nice in a
> tabbed, tiling wm. Maybe some of these already developed, but spending 13
> hours with the soldering iron, and 3 hours moving bricks every day, leaves
> me a small time to reading the documentations.

As mentioned in another post, I'm unlikely to be writing any new stuff 
for Ion in the next handful of years, if ever. It's time for something
else, and GNU/Linux (and consequently *BSD as well to a slightly lesser
extent) is turning into such a clusterfuck idiot box, that I doubt 
there's anything semi-usable to run Ion on after I'm ready to start
working on Ion4... aside from maybe Windows. Nevertheless, I'm likely
to put up an 'Ion3plus' repository after the stable Ion3 is released,
where users can contribute code moderated/edited by me, the malevolent
dictator -- or rather, editor. (A project with an editor that does his
job is like a journal with a good editor, whereas a truly bazaarian 
software project is like writings on the toilet wall -- or the typical
wiki.)

> Policy settings for the new window creation. When i run some multyple
> window application (mplayer, gimp), it would be nice if i could set where
> must the spawned window must to be placed. Currently it's follows the
> mouse pointer. My idea is to be set a policy for every application (tabs)
> for the method of the new window placement. Three or four rules (same
> tile, some tile, any tile, float) would be suffice.

This is something of a FAQ. You can set somewhat rigid policies by the
winprops mechanism, as indicated in another post. I'd like the default
to be to place the windows in the frame they were created from, but
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tuomo Valkonen | 9 Oct 2007 13:25
Picon
Picon
Favicon

Re: Life, universe, and ION3

On 2007-10-09, Sylvain Abélard <sylvain.abelard@...> wrote:
> Sorry if my advice seems outdated, I've been Windows-imprisoned for a long time.

At least there's _still_ that choice to the OSDL-sponsored hegemony.
(I'm beginning to think OSDL and its member companies are more harmful
to software choice than Microsoft, by sponsoring projects that turn
Linux, and *nix userland in general, into an idiot box clusterfuck.)

--

-- 
Tuomo
Permalink | Reply | 4 comments |
headers
Sylvain Abélard | 9 Oct 2007 14:06
Picon

Re: Life, universe, and ION3

On 10/9/07, Tuomo Valkonen <tuomov@...> wrote:
> On 2007-10-09, Sylvain Abélard <sylvain.abelard@...> wrote:
> > Sorry if my advice seems outdated, I've been Windows-imprisoned for a long time.

> At least there's _still_ that choice to the OSDL-sponsored hegemony.
> (I'm beginning to think OSDL and its member companies are more harmful
> to software choice than Microsoft, by sponsoring projects that turn
> Linux, and *nix userland in general, into an idiot box clusterfuck.)

Provided you bear with monoculture and software locks, why not.
DotNet begins to show many cool stuff for developers,
but still the intended user is expected to be another brainless WIMP-tard.

--

-- 
Sylvain Abelard,
Railer Rubyist. Epita MTI 2008.
Permalink | Reply | 3 comments |
headers
Tuomo Valkonen | 9 Oct 2007 14:36
Picon
Picon
Favicon

Re: Life, universe, and ION3

On 2007-10-09, Sylvain Abélard <sylvain.abelard@...> wrote:
> Provided you bear with monoculture and software locks, why not.

Sounds like where FOSS is heading.

> DotNet begins to show many cool stuff for developers,
> but still the intended user is expected to be another brainless WIMP-tard.

DotNet is YAMMHBE (Yet Another Megalomaniac Modernist Bureaucracy and 
Hierarchy of Everything). 

--

-- 
Tuomo
Permalink | Reply | 2 comments |
headers
Sylvain Abélard | 9 Oct 2007 14:43
Picon

Re: Life, universe, and ION3

On 10/9/07, Tuomo Valkonen <tuomov@...> wrote:
> On 2007-10-09, Sylvain Abélard <sylvain.abelard@...> wrote:
> > Provided you bear with monoculture and software locks, why not.
> Sounds like where FOSS is heading.

You don't find heroic Tuomo Valkonen's making your Windows usable. Yet.

> DotNet is YAMMHBE

But F# and the recent DLR (Dynamic Language Runtime) looks really sexy !

--

-- 
Sylvain Abelard,
Railer Rubyist. Epita MTI 2008.
Permalink | Reply | 1 comment |
headers
Tuomo Valkonen | 9 Oct 2007 14:48
Picon
Picon
Favicon

Re: Life, universe, and ION3

On 2007-10-09, Sylvain Abélard <sylvain.abelard@...> wrote:
> But F# and the recent DLR (Dynamic Language Runtime) looks really sexy !

Many languages themselves aren't that bad (Nemerle is another interesting 
DotNet language), but the libraries and library frameworks around them, 
designed by inferior minds, tend to suffer from megalomaniac hierarchies
(Haskell is another example) as well as OO fetish these days.

--

-- 
Tuomo
Permalink | Reply | 0 comments |
headers
Roy Lanek | 9 Oct 2007 17:16

Re: Life, universe, and ION3


> > Icon based, floating style application launcher.

> Yuck. Well, for a touch screen kiosk sort of thing, a sort of
> sidebar application launcher could be nice...

Is it a sardonic, or a "WC graffiti"-style (to borrow from your
post) :) like answer? If yes, then you can stop reading, false
alarm.

Icon stuffed sidebars/menus can be seen with Fluxbox, the window
manager. (Fluxbox which now has even ... *rounded menu corners*.)
Is that what you mean?

The point: Fluxbox illustrates well how a passable
[retrospectively observing] window manager originally, Blackbox,
has been transformed into a pig:

500K for Blackbox [stripped], versus 1,2-1.3M [stripped] or
more for Fluxbox, I don't remember ... I don't use Fluxbox,
have merely tried it for a couple of day. (And never mind the
UNAVOIDABLE errors [discover how many of these a guy such Wietse
Venema admits he is still making when he programs with maximal
care]--a percent of them involving security of course--per, say,
every thousand lines of code that constitute a program ... don't
forget that things do NOT worsen linearly, by surplus.)

Fluxbox adds zero, or little, SIGNIFICANT features compared
to Blackbox: *post factum* window tabbing can be functionally
included/simulated more intelligently via mrxvt, an rxvt based
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tuomo Valkonen | 9 Oct 2007 17:33
Picon
Picon
Favicon

Re: Life, universe, and ION3

On 2007-10-09 14:47 +0100, Sam Mason wrote:
> I hope the "inferior minds" comment below was intended as a joke --

Not really. Not everyone is up to the task of designing a programming
language, and certainly not a beautiful and useful one (certainly not
the C++ designers!), whereas it is comparatively easy to write a
crappy library up to a specification of what it must provide access 
to. Designing a beautiful library -- now that takes effort again.

> On Tue, Oct 09, 2007 at 12:48:58PM +0000, Tuomo Valkonen wrote:
> What makes these libraries/frameworks
> "inferior", rather than just different and/or unsuitable for solving the
> problems you're (currently) interested in?

I'm not saying unsuitable, I'm saying they suck aesthetically.

Good programming is art, science, and engineering. In present
practise the engineering -- i.e. ugly kludges to get things
working now, fast -- aspect is dominant almost to the exclusion
of the two others.

> Has Haskell gone out of favour with you, or is it just GHC/Hugs'
> byzantine libraries.

As I already said, the language itself (well, Haskell'98 anyway 
-- the extensions are rather crummy) is rather nice, but the 
libraries suffer from YAMMBHE.

> If you know of a better way, than a hierachy, of organising large
> amounts of (generally interdependant) code then I'd be interested to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane