ROX Desktop

On Apr 26, 2004, at 6:34 PM, Matthew Weier OPhinney wrote:

> I also have grown accustomed to dragging windows from one
> workspace to the next using edge wrapping.

This is already present.

> I also like the idea of a root menu... maybe something could be done
> with ROX-Menu or somesuch to bind it to a mouse and/or key press?

The original oroborus came with keylaunch and deskmenu.  They're still 
there on http://www.oroborus.org.  Also, ROX-Menu can be configured as 
a root menu now I believe.

On Mon, 26 Apr 2004 21:34:57 -0400
Matthew Weier OPhinney <matthew-lists@...> wrote:

> I personally would like (d)... as I have a request! I tried out
> OroboROX last week, but there were a couple show stoppers for me: I'm
> very accustomed to switching workspaces using my mouse wheel (buttons
> 4 and 5), and I also have grown accustomed to dragging windows from
> one workspace to the next using edge wrapping. Both of these are
> features of XFWM4, and I've also used the scroll feature in other
> window managers(such as blackbox, window maker, and E). Personally, if
> OroboROX had these, I'd likely start using it in place of xfwm4 (as
> that's the only part of the xfce4 desktop I really use).

There is another good thing about Xfce4. It has the best system tray
applet. It handles Gnome and KDE applets plus it handles the sometimes
contrary tray icon in Sylpheed-Claws and Gaim.

-- 
Cheers,
Mike T.

Linux user #169067
(G)aim ID: Linux Lunatyk

Am 27.04.2004 03:34:57 schrieb(en) Matthew Weier OPhinney:
> Jonatan/Guido --
> 
> Do you have plans to implement an SF project for OroboROX? The reason
> I
> ask is that it might be useful to have:
> 
> a) CVS
> b) Downloads (though I understand that Jonatan is hosting the project
>    now on his site)
> c) Bug Tracker
> d) Requests Tracker

> I personally would like (d)... as I have a request! I tried out
> OroboROX

The rox lists should do for now with respect to (d).
Thomas said, he'd make OroboROX the default WM in ROX-Session.
Maybe we could invite users to discuss OroboROX on the ROX-Wiki then.

> last week, but there were a couple show stoppers for me: I'm very
> accustomed to switching workspaces using my mouse wheel (buttons 4

That should be easy to add. (Now that workspace-switching works :) )

> 5), and I also have grown accustomed to dragging windows from one
> workspace to the next using edge wrapping. Both of these are features

You can drag windows across workspace borders now.
What is edge wrapping?


> I also want to re-iterate that you may want to look at the code for
> keylaunch for your keybindings, as that's incredibly stable. I also
> think it would be useful to be able to extend the WM keybindings
> beyond
> the WM -- to opening applications, etc -- so that this duty doesn't
> need
> to be relegated to yet another program. Either that, or bundle a
> keylauncher with OroboROX to handle both duties.

The things is ROX already does keybindings for pinboard/panel items. I  
don't want to have a second keyboard-grabber who doesn't know anything  
about the keys taken by ROX. It has to be integrated.

Thomas, your suggestion? How do we tackle that?

> I also like the idea of a root menu... maybe something could be done
> with ROX-Menu or somesuch to bind it to a mouse and/or key press?

ROX has a root menu. I'm against OroboROX offering an option to  
override the ROX root-menu. But like you said, you could assign a key  
to ROX-Menu. You can already do that. Just put ROX-Menu on the panel  
and assign it a key. With regards to mouse-control, the only option I  
see is the middle-button for such things.

On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:
[...]
> >I also want to re-iterate that you may want to look at the code for
> >keylaunch for your keybindings, as that's incredibly stable. I also
> >think it would be useful to be able to extend the WM keybindings
> >beyond the WM -- to opening applications, etc -- so that this duty
> >doesn't need to be relegated to yet another program. Either that, or
> >bundle a keylauncher with OroboROX to handle both duties.
> 
> The things is ROX already does keybindings for pinboard/panel items. I  
> don't want to have a second keyboard-grabber who doesn't know anything  
> about the keys taken by ROX. It has to be integrated.

> Thomas, your suggestion? How do we tackle that?

I think the pinboard and panel shortcuts are fine for this as it is. Two
possible improvements:

- Allow arguments to programs to be set in the Edit Icon box.

- Someone suggested hidden pinboard icons, so you can set a shortcut
  without cluttering the desktop. Not sure if this is a good idea or
  not...


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

-- Guido Schimmels <__guido__@...> wrote
(on Tuesday, 27 April 2004, 06:31 AM +0200):
> Am 27.04.2004 03:34:57 schrieb(en) Matthew Weier OPhinney:
> > Do you have plans to implement an SF project for OroboROX? The reason
> > I ask is that it might be useful to have:
> > 
> > a) CVS
> > b) Downloads (though I understand that Jonatan is hosting the project
> >    now on his site)
> > c) Bug Tracker
> > d) Requests Tracker
> 
> > I personally would like (d)... as I have a request! I tried out
> > OroboROX
> 
> The rox lists should do for now with respect to (d).
> Thomas said, he'd make OroboROX the default WM in ROX-Session.
> Maybe we could invite users to discuss OroboROX on the ROX-Wiki then.

The reason I suggested it was to have an easy place to look and see if
requests/bugs had already been submitted, rather than looking through
the archives. However, a few wiki pages would also do well. Perhaps I'll
throw some up later.

> > last week, but there were a couple show stoppers for me: I'm very
> > accustomed to switching workspaces using my mouse wheel (buttons 4
> 
> That should be easy to add. (Now that workspace-switching works :) )

Excellent! I look forward to it!

> > 5), and I also have grown accustomed to dragging windows from one
> > workspace to the next using edge wrapping. Both of these are features
> 
> You can drag windows across workspace borders now.
> What is edge wrapping?

Okay, I guess I missed that. Actually, what I recall now is that I
couldn't move windows at all, so I assumed I wouldn't be able to drag
between workspaces. I suspect I'll need to recompile and try again.

> > I also want to re-iterate that you may want to look at the code for
> > keylaunch for your keybindings, as that's incredibly stable. I also
> > think it would be useful to be able to extend the WM keybindings
> > beyond the WM -- to opening applications, etc -- so that this duty
> > doesn't need to be relegated to yet another program. Either that, or
> > bundle a keylauncher with OroboROX to handle both duties.
> 
> The things is ROX already does keybindings for pinboard/panel items. I  
> don't want to have a second keyboard-grabber who doesn't know anything  
> about the keys taken by ROX. It has to be integrated.

I hadn't considered using ROX keybindings... However, that's not a great
solution in some instances. As an example, I have a 'multimedia'
keyboard that has keys named XF86HomePage, XF86Mail, XF86VolumeUp,
XF86VolumeDown, etc. I have mapped the volume keys to do alsactl actions
-- which aren't necessarily things I want on my desktop or panel. These
are also things that I cannot do trivially with ROX as I cannot give
arguments to scripts when setting icons; instead, I would need to setup
shell scripts for each action.

I agree it should be integrated; I guess what I'd like is some sort of
keygrabber integrated with ROX and/or OroboROX.

> Thomas, your suggestion? How do we tackle that?
> 
> > I also like the idea of a root menu... maybe something could be done
> > with ROX-Menu or somesuch to bind it to a mouse and/or key press?
> 
> ROX has a root menu. I'm against OroboROX offering an option to  
> override the ROX root-menu. 

I'm not suggesting overriding the ROX root menu; button 2 is currently
unassigned by ROX, and could be used to spawn an applications menu. I
inquired about this a couple years ago when using blackbox as both
blackbox and ROX were wanting to use button 3 for their root menu.
Thomas, at that time, indicated that the freedesktop.org specs suggest
button 2 being for window manager root menus (and, more specifically,
for managing windows) and button 3 for desktop context menus, which was
why he had setup ROX the way he had.

> But like you said, you could assign a key to ROX-Menu. You can already
> do that. Just put ROX-Menu on the panel and assign it a key.  With
> regards to mouse-control, the only option I see is the middle-button
> for such things.

I'll need to check out ROX-Menu again; I haven't looked at it since one
of the initial releases, and at the time it wasn't terribly sufficient
for my needs as it only handled AppDir items (I understand it handles
other items at this point). As far as mouse control of it, I was
assuming middle-button for it (as outlined above; I currently have
deskmenu grabbing button-2 as it is.) I'm assuming ROX would have to
grab the mouse event, in which case it might make sense to be able to
configure, in ROX, a program to launch on button-2 events.

-- 
Matthew Weier O'Phinney
http://weierophinney.net/matthew/

-- Thomas Leonard <tal00r@...> wrote
(on Tuesday, 27 April 2004, 11:49 AM +0100):
> On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:
> [...]
> > >I also want to re-iterate that you may want to look at the code for
> > >keylaunch for your keybindings, as that's incredibly stable. I also
> > >think it would be useful to be able to extend the WM keybindings
> > >beyond the WM -- to opening applications, etc -- so that this duty
> > >doesn't need to be relegated to yet another program. Either that, or
> > >bundle a keylauncher with OroboROX to handle both duties.
> > 
> > The things is ROX already does keybindings for pinboard/panel items. I  
> > don't want to have a second keyboard-grabber who doesn't know anything  
> > about the keys taken by ROX. It has to be integrated.
> 
> > Thomas, your suggestion? How do we tackle that?
> 
> I think the pinboard and panel shortcuts are fine for this as it is. Two
> possible improvements:
> 
> - Allow arguments to programs to be set in the Edit Icon box.

I just submitted a lengthy reply of my own, but I'll chime in here,
too... This would be *excellent*. I've gotten into the habit of writing
all sorts of shell scripts, simply so that I can have icons that I can
click. This would cause much less clutter, and offer a nice, simple
solution.

> - Someone suggested hidden pinboard icons, so you can set a shortcut
>   without cluttering the desktop. Not sure if this is a good idea or
>   not...

I also noted in my reply that I have a number of 'multimedia' buttons on
my keyboard that I have mapped to alsactl and such programs -- things I
really don't want on my panel or desktop, but that I *do* want keyboard
shortcuts for. Hidden shortcuts would alleviate that. However, if the
only point behind a hidden shortcut is to make a keybinding, perhaps a
keybinding manager of sorts might make more sense?

Of course, the code for icons is already there, and you could add
context menu items to the pinboard to 'Show/Hide Hidden Items'; I don't
know if that might be simpler.

-- 
Matthew Weier O'Phinney
http://weierophinney.net/matthew/

On Tue, 27 Apr 2004 06:31:33 +0200
Guido Schimmels <__guido__@...> wrote:

> > last week, but there were a couple show stoppers for me: I'm very
>  > accustomed to switching workspaces using my mouse wheel (buttons 4
> 
>  That should be easy to add. (Now that workspace-switching works :) )

Just tried it, adding it to buttonpress-handler if
clientGetFromWindow(event->window) return zero. It works, but it also
seems to work if the event->window does not handle the scrollwheel
itself, which is rather annoying...

>  > I also want to re-iterate that you may want to look at the code for
>  > keylaunch for your keybindings, as that's incredibly stable. I also
>  > think it would be useful to be able to extend the WM keybindings
>  > beyond
>  > the WM -- to opening applications, etc -- so that this duty doesn't
>  > need
>  > to be relegated to yet another program. Either that, or bundle a
>  > keylauncher with OroboROX to handle both duties.
> 
>  The things is ROX already does keybindings for pinboard/panel items.
>  I  don't want to have a second keyboard-grabber who doesn't know
>  anything  about the keys taken by ROX. It has to be integrated.
> 
>  Thomas, your suggestion? How do we tackle that?

I think it would be great to be able to have hidden icons on the desktop
that responds to keyboard shortcuts. A checkbox in the "edit item" box
from the right-click menu, which marks the icon as hidden. And a
checkbox item on the rox root-menu to "show hidden icons".

The other approach would be a special section in the rox-filer options
to assign keyboard shortcuts to shellcommands and/or appdirs.. But I
think this would be a little inconsistent.

>  > I also like the idea of a root menu... maybe something could be
>  > done with ROX-Menu or somesuch to bind it to a mouse and/or key
>  > press?
> 
>  ROX has a root menu. I'm against OroboROX offering an option to  
>  override the ROX root-menu. But like you said, you could assign a key
>  to ROX-Menu. You can already do that. Just put ROX-Menu on the panel 
>  and assign it a key. With regards to mouse-control, the only option I
>  see is the middle-button for such things.

I agree with you. There is no GUI (GTK) stuff inside OroboROX. Root
menus and launching programs should be the job of ROX.

/Jonatan - [ http://kymatica.com ]

On Tue, 27 Apr 2004 06:57:37 -0400
Matthew Weier OPhinney <matthew-lists@...> wrote:

> -- Thomas Leonard <tal00r@...> wrote
> (on Tuesday, 27 April 2004, 11:49 AM +0100):
> > On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:
> > [...]
> > > >I also want to re-iterate that you may want to look at the code
> > > >for keylaunch for your keybindings, as that's incredibly stable.
> > > >I also think it would be useful to be able to extend the WM
> > > >keybindings beyond the WM -- to opening applications, etc -- so
> > > >that this duty doesn't need to be relegated to yet another
> > > >program. Either that, or bundle a keylauncher with OroboROX to
> > > >handle both duties.
> > > 
> > > The things is ROX already does keybindings for pinboard/panel
> > > items. I  don't want to have a second keyboard-grabber who doesn't
> > > know anything  about the keys taken by ROX. It has to be
> > > integrated.
> > 
> > > Thomas, your suggestion? How do we tackle that?
> > 
> > I think the pinboard and panel shortcuts are fine for this as it is.
> > Two possible improvements:
> > 
> > - Allow arguments to programs to be set in the Edit Icon box.
> 
> I just submitted a lengthy reply of my own, but I'll chime in here,
> too... This would be *excellent*. I've gotten into the habit of
> writing all sorts of shell scripts, simply so that I can have icons
> that I can click. This would cause much less clutter, and offer a
> nice, simple solution.

Yes, it would be very nice indeed!
And I would like to add another feature request here: The ability to
make a new icon on the pinboard/panel without having to first drag a
file there and then edit it!

> > - Someone suggested hidden pinboard icons, so you can set a shortcut
> >   without cluttering the desktop. Not sure if this is a good idea or
> >   not...
> 
> I also noted in my reply that I have a number of 'multimedia' buttons
> on my keyboard that I have mapped to alsactl and such programs --
> things I really don't want on my panel or desktop, but that I *do*
> want keyboard shortcuts for. Hidden shortcuts would alleviate that.
> However, if the only point behind a hidden shortcut is to make a
> keybinding, perhaps a keybinding manager of sorts might make more
> sense?
> 
> Of course, the code for icons is already there, and you could add
> context menu items to the pinboard to 'Show/Hide Hidden Items'; I
> don't know if that might be simpler.

I think it would be simpler. And it would be more consistent, the user
already knows about icons. All she/he needs to know then is that the
icons can be made hidden.

/Jonatan - [ http://kymatica.com ]

Am 27.04.2004 12:49:22 schrieb(en) Thomas Leonard:
> On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:

> I think the pinboard and panel shortcuts are fine for this as it is.
> Two
> possible improvements:
> 
> - Allow arguments to programs to be set in the Edit Icon box.
> 
> - Someone suggested hidden pinboard icons, so you can set a shortcut
>   without cluttering the desktop. Not sure if this is a good idea or
>   not...

I don't like the idea of hidden items on the pinboard. Wouldn't it be  
more in line with the ROX philosophy to have a shortcuts folder visible  
on the pinboard, basically nesting the pinboard one level deep.

Am 27.04.2004 13:33:24 schrieb(en) Jonatan Liljedahl:
> On Tue, 27 Apr 2004 06:57:37 -0400

> Yes, it would be very nice indeed!
> And I would like to add another feature request here: The ability to
> make a new icon on the pinboard/panel without having to first drag a
> file there and then edit it!

If you mean creating items non-interactively via a script e.g., I have  
code for adding an item lying around somewhere. But I gave upwhen I  
tried to add the soap message for removing an item. The filer code  
turned out not to be well modulized in this respect. I gave up when I  
had the feeling it would need a lot of restructuring of code I'm not  
familiar with. The code I needed to reuse is tied into the D&D context.

On Tue, Apr 27, 2004 at 03:45:59PM +0200, Guido Schimmels wrote:
> Am 27.04.2004 12:49:22 schrieb(en) Thomas Leonard:
> >On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:
> 
> >I think the pinboard and panel shortcuts are fine for this as it is.
> >Two
> >possible improvements:
> >
> >- Allow arguments to programs to be set in the Edit Icon box.
> >
> >- Someone suggested hidden pinboard icons, so you can set a shortcut
> >  without cluttering the desktop. Not sure if this is a good idea or
> >  not...
> 
> I don't like the idea of hidden items on the pinboard. Wouldn't it be  
> more in line with the ROX philosophy to have a shortcuts folder visible  
> on the pinboard, basically nesting the pinboard one level deep. 

Maybe we should allow panels to be minimised onto the pinboard?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

On Tue, 27 Apr 2004 15:58:06 +0200
Guido Schimmels <__guido__@...> wrote:

> Am 27.04.2004 13:33:24 schrieb(en) Jonatan Liljedahl:
> > On Tue, 27 Apr 2004 06:57:37 -0400
> 
> > Yes, it would be very nice indeed!
> > And I would like to add another feature request here: The ability to
> > make a new icon on the pinboard/panel without having to first drag a
> > file there and then edit it!
> 
> If you mean creating items non-interactively via a script e.g., I have
>  
> code for adding an item lying around somewhere. But I gave upwhen I  
> tried to add the soap message for removing an item. The filer code  
> turned out not to be well modulized in this respect. I gave up when I 
> had the feeling it would need a lot of restructuring of code I'm not  
> familiar with. The code I needed to reuse is tied into the D&D
> context.

I actually ment a simple menu item on the rox desktop menu. But sure,
being able to do that via soap (or DBUS in the future, all soap stuff
should move to DBUS, right?) would be nice too!

/Jonatan - [ http://kymatica.com ]

On Tue, 27 Apr 2004 14:54:53 +0100
Thomas Leonard <tal00r@...> wrote:

> On Tue, Apr 27, 2004 at 03:45:59PM +0200, Guido Schimmels wrote:
> > Am 27.04.2004 12:49:22 schrieb(en) Thomas Leonard:
> > >On Tue, Apr 27, 2004 at 06:31:33AM +0200, Guido Schimmels wrote:
> > 
> > >I think the pinboard and panel shortcuts are fine for this as it
> > >is. Two
> > >possible improvements:
> > >
> > >- Allow arguments to programs to be set in the Edit Icon box.
> > >
> > >- Someone suggested hidden pinboard icons, so you can set a
> > >shortcut
> > >  without cluttering the desktop. Not sure if this is a good idea
> > >  or not...
> > 
> > I don't like the idea of hidden items on the pinboard. Wouldn't it
> > be  more in line with the ROX philosophy to have a shortcuts folder
> > visible  on the pinboard, basically nesting the pinboard one level
> > deep. 
> 
> Maybe we should allow panels to be minimised onto the pinboard?

Hmm, that would be cool! And/or minimized onto another panels. Or maybe
just "drop down" sub-panels somehow?

/Jonatan - [ http://kymatica.com ]

Am 27.04.2004 16:30:50 schrieb(en) Jonatan Liljedahl:
> On Tue, 27 Apr 2004 14:54:53 +0100
> Thomas Leonard <tal00r@...> wrote:

> > Maybe we should allow panels to be minimised onto the pinboard?
> 
> Hmm, that would be cool! And/or minimized onto another panels. Or
> maybe
> just "drop down" sub-panels somehow?

Or if the panel supported xfce-like "drawers" or I don't know what they  
are called there. I got the name from a gnome-panel applet I think. But  
it shouldn't be an applet, but built-in like in xfce. Then you could  
delegate such a drawer menu to "abstract" shortcuts.

On Tue, 27 Apr 2004 12:52:26 +0200
Jonatan Liljedahl <than@...> wrote:

> > > last week, but there were a couple show stoppers for me: I'm very
>  >  > accustomed to switching workspaces using my mouse wheel (buttons
>  >  > 4
>  > 
>  >  That should be easy to add. (Now that workspace-switching works :)
>  >  )
> 
>  Just tried it, adding it to buttonpress-handler if
>  clientGetFromWindow(event->window) return zero. It works, but it also
>  seems to work if the event->window does not handle the scrollwheel
>  itself, which is rather annoying...

I think this should be handled by rox! The ROX-pinboard should take care
of it's buttonpress events itself. 

/Jonatan - [ http://kymatica.com ]

On 27/4/2004 4:57:53p, Guido Schimmels wrote:

>Am 27=2E04=2E2004 16:30:50 schrieb(en) Jonatan Liljedahl:
>> On Tue, 27 Apr 2004 14:54:53 +0100
>> Thomas Leonard <tal00r@...> wrote:
>
>> > Maybe we should allow panels to be minimised onto the pinboard?
>> 
>> Hmm, that would be cool! And/or minimized onto another panels=2E Or
>> maybe just "drop down" sub-panels somehow?
>
>Or if the panel supported xfce-like "drawers" or I don't know what they
>are called there=2E I got the name from a gnome-panel applet I think=2E B=
ut
>it shouldn't be an applet, but built-in like in xfce=2E Then you could  
>delegate such a drawer menu to "abstract" shortcuts=2E

Or maybe have a tabbed panel?  I vaguely remember OS/2 having a similar co=
ncept=2E


Regards,

Robert=2E