Per Olofsson | 1 May 13:20 2003
Picon
Picon

Re: Ion-dock configuration

Tuomo Valkonen <tuomov <at> modeemi.cs.tut.fi> writes:

>
> If you want to make the docks to eventually save their state and be
> automatically created by the standard mechanism when Ion is started,
> then you need a function that reads table based configuration to create
> a dock.

The problem with the savefiles is that the docks would have to be
configured entirely with keybindings. Yes, it is possible to edit the
savefile directly, but it is very inconvenient because you have to
exit Ion first.

> Other than the savefiles, there isn't any "standard" way as
> there isn't anything thatwould have lots of attributes -- except for the
> winprops that are now entirely implemented in Lua. (BTW, it is now
> possible to use the winprop table for docking properties too if that
> is desired.)

I'm already assigning dockapps to the dock using winprops. Would it be
possible to have the dock created from the savefile and then use
winprops to add properties to it?

> To make binding keys easy, there should be functions such
> as dock_set/toggle_orientation so perhaps the best way to do this is
> to have initial configuration done collectively with an attributes
> table and subsequent configurationindependently for each attribute
> with set functions. Attributes could be queried either collectively
> in a table or independently; I have no opinion which is better.
>
(Continue reading)

Per Olofsson | 1 May 13:29 2003
Picon
Picon

Re: feature request

Jeremy Cortner <jcortner <at> cvol.net> writes:

> I was wondering if you could implement some sort of window creation
> piping mechanism. A way to tell ion where to put windows generated
> from a specific pane when creating them.

See <http://modeemi.fi/~tuomov/ion/faq.html>.

BTW, Tuomo, could you number the questions? If they were numbered, one
could refer to a specific question easier.

/Pelle

Tuomo Valkonen | 1 May 14:22 2003
Picon
Picon

Re: Ion-dock configuration

On Thu, May 01, 2003 at 01:20:54PM +0200, Per Olofsson wrote:
> The problem with the savefiles is that the docks would have to be
> configured entirely with keybindings.

No, you just provide functions to change attributes and these can be
called anywhere. A wrapper function -- possibly implemented in Lua --
could even convert from a table presentation to function calls.

> I'm already assigning dockapps to the dock using winprops. Would it be
> possible to have the dock created from the savefile and then use
> winprops to add properties to it?

Winprops are meant for client windows but it would be easy to implement
a similar scheme for configuring extra dock properties. 

> > If you need the attributes frequently and/or the dock should be
> > notified of changes in the attributes, I'd so store in C. 
> I need to know when it's changed, so I guess I'll store it in C. I
> though there were, perhaps, a way to detect when changes were made to
> the table.

I think it would be possible with metatables but the simple extl_ 
interface does not support such and I prefer accessor functions for
this sort of thing.

--

-- 
Tuomo

Tuomo Valkonen | 1 May 14:28 2003
Picon
Picon

Re: feature request

On Thu, May 01, 2003 at 01:29:47PM +0200, Per Olofsson wrote:
> BTW, Tuomo, could you number the questions? If they were numbered, one
> could refer to a specific question easier.

I guess I could. HTML just doesn't make it easy to maintain the
numbering... 

--

-- 
Tuomo

Yves Rutschle | 1 May 14:39 2003

Re: feature request

On Thu, May 01, 2003 at 03:28:27PM +0300, Tuomo Valkonen wrote:
> I guess I could. HTML just doesn't make it easy to maintain the
> numbering... 

<ol>
  <li>First point
  <li>Second point
</ol>

What more do you want?

/Y

Tuomo Valkonen | 1 May 14:58 2003
Picon
Picon

Re: feature request

On Thu, May 01, 2003 at 01:39:57PM +0100, Yves Rutschle wrote:
> <ol><li>First point<li>Second point</ol>
> What more do you want?

That doesn't work with sections. You would have to maintain the
'start' attribute manually and it is deprecated anyway. HTML
doesn't support two-level numbering either (1.1 etc. for the
first section and so on. Actually, the only way to get this kind of
lists seems to be some ugly table kludge. No thanks.)

Anyway, I just got rid of lists and do the numbering manually. Doesn't
look as nice but the FAQ is numbered now.

--

-- 
Tuomo

Francesco Bochicchio | 2 May 19:27 2003
Picon

Suggestion : a new 'stable' release


The gap beween the 'stable' release and the current 
development release is increasing.
What about taking the last pre-lua development release
(i.e. the one I'm using :-) and making it the new
'stable' release ?

Just an idea.

Ciao
----
FB

Tuomo Valkonen | 2 May 19:45 2003
Picon
Picon

Re: Suggestion : a new 'stable' release

On Fri, May 02, 2003 at 07:27:21PM +0200, Francesco Bochicchio wrote:
> What about taking the last pre-lua development release
> (i.e. the one I'm using :-) and making it the new
> 'stable' release ?

I don't think it is stable and bug-free enough. The current stable
release on the other hand seems rock-solid and there are no essential
well-working improvements in the pre-lua development releases over
the stable one.

--

-- 
Tuomo

Joey Hess | 2 May 20:37 2003
Picon

xchat + ion-devel weirdness

I have ion-devel 20030327 and xchat 2.0.2, and a really weird problem
between them. 

xchat windows have a little button in the upper-right corner that can
open or close the user list. There is a similar item on the xchat
context menu. This is supposed to open/close the user list of the xchat
window or (non-ion) tab that you have open. I use xchat with each channel
in its own window.

Here's the thing: Often xchat will get into a state where if I try to
toggle the user list in window a, it will actually affect the one in
window b. It's spooky, I click in one window and the effect happens in
the other. Occasionally (and even more annoyingly), I get the same
effect with xchat's close button, in the upper-left corner of its
windows.

I figured it was just an xchat bug in the newish 2.0 release, but I can
only reproduce it in ion with frames. In ion floatws workspaces or in
window maker, xchat does not have this problem.

So what on earth could it be? Some nasty interaction between xchat and
frames, I guess.

--

-- 
see shy jo
Tuomo Valkonen | 2 May 21:26 2003
Picon
Picon

Re: xchat + ion-devel weirdness

On Fri, May 02, 2003 at 02:37:50PM -0400, Joey Hess wrote:
> So what on earth could it be? Some nasty interaction between xchat and
> frames, I guess.

The only difference between floatfremas and ionframes that the
applications should see is that floatframes give apps the size they
want so xchat probably tries resize its window and goes into some
weird state when it can't get the size it wants. According to the
ICCCM apps the window manager has full control over client window
sizes and apps should be able to live with whatever sizes the window
manager gives them.

--

-- 
Tuomo


Gmane