On 23-May-2002 [EMAIL PROTECTED] wrote:
> Hello all,
> I am new to black box and am becoming more and more fond of it the more I
> use it. I'm having a few problems with it though. The main one right now is
> how to get programs to execute when I start it up. Example: getting artsd
> to start s
On 23-May-2002 Matt Wilson wrote:
> On Thu, 2002-05-23 at 11:35, Matt Wilson wrote:
>> BTW, the toolbar/window placement bug is fixed like you said :), altho
>> the snapping/border prob is still there for me... altho I don't notice
>> it when the border width is 0 or 1 ;-)
>
> Oh, woops... spoke
Hello all,
I am new to black box and am becoming more and more fond of it the more I
use it. I'm having a few problems with it though. The main one right now is
how to get programs to execute when I start it up. Example: getting artsd
to start so that xmms will work w/out me having to manually
On Thu, 2002-05-23 at 11:35, Matt Wilson wrote:
> BTW, the toolbar/window placement bug is fixed like you said :), altho
> the snapping/border prob is still there for me... altho I don't notice
> it when the border width is 0 or 1 ;-)
Oh, woops... spoke too soon. It's still happening. I have wind
On 23-May-2002 Kevin Geiss wrote:
> I use wmswallow and aterm together to get a little terminal in the slit.
> here's
> the lines from my .xinitrc:
>
> aterm -sh 60 -tr -ls -fn 6x10 -g 10x6 -cr green -fg green +sb -name dockterm&
> /usr/local/bin/wmswallow -focus -geom 64x64 dockterm&
>
> used t
On Thu, 2002-05-23 at 12:30, Kevin Geiss wrote:
> I use wmswallow and aterm together to get a little terminal in the slit. here's
> the lines from my .xinitrc:
>
> aterm -sh 60 -tr -ls -fn 6x10 -g 10x6 -cr green -fg green +sb -name dockterm&
> /usr/local/bin/wmswallow -focus -geom 64x64 dockterm&
I use wmswallow and aterm together to get a little terminal in the slit. here's
the lines from my .xinitrc:
aterm -sh 60 -tr -ls -fn 6x10 -g 10x6 -cr green -fg green +sb -name dockterm&
/usr/local/bin/wmswallow -focus -geom 64x64 dockterm&
used to work great, but at least in alpha4 and alpha6, t
On 22-May-2002 Matt Wilson wrote:
> How possible would it be to have the capability for multiple slits? For
> instance, one horizontally aligned and one vertical... it sounds like a
> lot of work to me, but I thought when you code in the ability to move
> dockapps/bbtools etc within the slit, it *
P.S. the xmms thing looks like their bug, not yours. When I alt+click
move it around it snaps perfectly to the correct struts and all
(although admittedly leaves the playlist behind :-P)
Matt.
How possible would it be to have the capability for multiple slits? For
instance, one horizontally aligned and one vertical... it sounds like a
lot of work to me, but I thought when you code in the ability to move
dockapps/bbtools etc within the slit, it *may* not be such a big job.
Just a though
>
> hmm, this is still around alpha6 and current cvs. The issue here is how auto
> raise works currently.
>
> When you select 'auto hide' in the menu it just sets a 'should i auto hide'
> flag. The actual work is done by the enter and leave events caused by the
> mouse. Since you did not caus
On 22-May-2002 Tim Riley wrote:
> Well, the sourceforge bug tracker would never finish uploading this new
> bug to the database, so I post it here just in case.
>
> Toolbar is auto-hidden. Right-click on it to bring up the menu, and
> deselect 'Auto hide.' If the sloppy focus delay is long en
Well, the sourceforge bug tracker would never finish uploading this new
bug to the database, so I post it here just in case.
Toolbar is auto-hidden. Right-click on it to bring up the menu, and
deselect 'Auto hide.' If the sloppy focus delay is long enough such that
the above can be performed
On 22-May-2002 Sean 'Shaleh' Perry wrote:
> On 22-May-2002 Matt Wilson wrote:
>> Just noticing a small bug (?) - even with full maximisation disabled,
>> windows are still being placed under the toolbar (it's at the
>> top-center). It wouldn't be such a problem, except it means that the
>> titleba
On 22-May-2002 Matt Wilson wrote:
> Just noticing a small bug (?) - even with full maximisation disabled,
> windows are still being placed under the toolbar (it's at the
> top-center). It wouldn't be such a problem, except it means that the
> titlebar (ie the easy way to move a window) is obscured
El mié, 22-05-2002 a las 10:02, Mads Martin Joergensen escribió:
> * Adriano Varoli Piazza <[EMAIL PROTECTED]> [May 22. 2002 14:59]:
> > Hi
> > Could anyone tell me how to get transparent term windows on 0.62.1pre0
> > (MDK8.2)?
>
> Use the program 'aterm' and see man aterm for details.
Thank you
* Adriano Varoli Piazza <[EMAIL PROTECTED]> [May 22. 2002 14:59]:
> Hi
> Could anyone tell me how to get transparent term windows on 0.62.1pre0
> (MDK8.2)?
Use the program 'aterm' and see man aterm for details.
--
Mads Martin Jørgensen, http://mmj.dk
"Why make things difficult, when it is possi
Hi
Could anyone tell me how to get transparent term windows on 0.62.1pre0
(MDK8.2)?
Thanks
Adriano
Just noticing a small bug (?) - even with full maximisation disabled,
windows are still being placed under the toolbar (it's at the
top-center). It wouldn't be such a problem, except it means that the
titlebar (ie the easy way to move a window) is obscured by the toolbar.
Matt.
>
>> I am not saying this is proper behaviour, just how it has always behaved.
> Let's have a vote!
>
um, it would be like a vote in Cuba. There is one entry on the ballot and
everyone has to choose it (-:
To really fix this is a lot of work. We plan to do this work but would like to
release
Well, hello there Sean,
>>Well, if the sticky window _is_ the window that has the
>>focus before the Workspace Change, shouldn't it be the same
>>one that gains the focus when returning to the Workspace?
> in theory (-:
Heh heh, I won! ;-P
> blackbox sort of makes the assumption that windows m
> Well, if the sticky window _is_ the window that has the
> focus before the Workspace Change, shouldn't it be the same
> one that gains the focus when returning to the Workspace?
>
in theory (-:
blackbox sort of makes the assumption that windows marked sticky are usually
ignored. They are u
Hi,
>>When "Focus Window on Workspace Change" is _not_ checked the
>>behavior/scenario is as follows:
>> * Make a window sticky, change workspace: the sticky
>>window keeps focus.
>>
>>When the option _is_ checked, the behaviour changes: the
>>sticky window looses its focus.
>>
>>It looks lik
23 matches
Mail list logo
