Re: [rox-devel] rox.sourceforge.net/testing/OroboROX

[Guido S. <__g...@we...>]

Am 22.04.2004 15:57:14 schrieb(en) Jonatan Liljedahl:
> On Thu, 22 Apr 2004 11:49:29 +0100
> Thomas Leonard <ta...@ec...> wrote:

> > - The "Terminate OroboROX" shortcut should be removed. Don't want
> > anyone
> >   hitting that (guess it's for debugging).
> 
> I see your point. Removed. (edit APPDIR/defaults if you want it)

It's meant for ending the session. But as we use ROX-Session it  
shouldn't be in the GUI. Removing it is the right thing.

> 
> > - Shortcuts often don't work when no window has the focus.
> 
> Yes, this is a very annoying bug. Guido, do you have any clue?

Wish I had.
Does anyone know about the internals of keyboard-grabbing in X?
How is it related to window focus? What's the role of the root window  
or the desktop window in this context? What happens with the keyboard  
focus when the last focusable window disappears?

I'm asking because the problem you describe happens when you unmap the  
last client of the active workspace. That seems to lose keyboard focus  
entirely for OroboROX. Then OroboROX doesn't seem to receive anymore  
keyboard events.
When that happens you can switch to another workspace with the pager  
and back, and now keys work again. No you can cycle workspaces  
endlessly in the one direction you have chosen. If you reverse cycling  
direction now, keys will stop working at the workspace you started from  
again.
If I knew what change happens in the event, I could get somewhere.
I would like to see what happens in the debugger, but how do you do  
that? Run the debugger on another workspace? But than switching between  
the workspaces will cause distracting events.


> NOTE: This Options GUI also has options for some additional window
> matchings. These are not available in the official 0.8.4 release of
> OroboROX, so you'll have to wait for next release (Guido?) before  
> they
> can be used...

I'll make a 0.8.5 release soon.
Jonathan, should I merge Thomas's patch? Do you need to make changes to  
the GUI when we add it? Anyway, tell me if you have something in the  
pipe left, or give me the green light, and I'll make the release.

ANNOUNCEMENT:
For the future I hereby declare Jonatan Liljedahl eligible to do  
releases on his own until my personal situation permits to contribute  
regularly again.

I'm currently not able to keep up with the daily traffic.

As a remark, I'm not too happy with the KDE-control-center route ROX is
following currently with LookAndFeel and OroboROX-GUI. I'd like to see
LookAndFeel and OroboROX-GUI merged (virtually) and then split out in a  
number of capplets like this:

- Mouse
- Keyboard
- Font
- Theme
- Workspace
- Toolbar+Menu
- Window
- Language
- Keyboard Shortcuts

I don't know how this works for people who want to use another window- 
manager.
I guess they have to live with greyed-out areas then, unless someone  
writes a Options.xml -> rcfile converter for those wm's.
(e.g. when you use the Gnome-CC font capplet without metacity running,  
the "Title bar font" option is greyed out)
I'd be disappointed if this kept us from doing the right thing.
We could still keep the current application-bound OroboROX-GUI around  
as a one-stop solution. OroboROX-GUI now exposes all options which is  
good and bad.
Gnome made a lot off their user-base angry by no longer offering GUIs  
for advanced settings. I'm not suggesting to go this route. Instead,  
with regards to OroboROX, I suggest we keep OroboROX-GUI the way it is  
and offer the above structure as the stream-lined default. As I'm not  
planning to add a lot more features to OroboROX, there would be not  
much ongoing additional maintainance work introduced by this dual- 
route. OK, I lied. There is the issue of i18n.
Asking the translators to keep both up-to-date may be a problem.

PS:
As Jonatan mentioned in a previous post, we really need a <table> tag  
or something in ROX-Options to pack and thus align belonging widgets.  
ROX will always look a bit amateurish otherwise.