headers
Greg Alexander | 4 Oct 2002 04:02

patches...

Hey there!

Okay still don't know exactly why DestroyNotify is sent whenever the
message window for a dock app goes away, but I'm attaching a patch for
minitime.c (which I use) and miniwave.c (which I don't, but it's the
same basic patch).  Just ignores the DestroyNotify event, like my
miniapm.c hack.

A more important patch with dock/msg.c:

I discovered that if I tap on, for example, minisys like ten
times a second (sometimes letting the message window stay there for
the full 5 seconds but other times interrupting it before the message
even finishes sending) then eventually the message window just pops up
for the briefest flash and then disappears.  This is caused by
multiple message records getting put in the queue for the same window.
(which happens if one message is begun before another finishes)
The starttime (used for the delayed destruction of the message window)
is set on the message record at the end of the queue but the text goes
into the message record at the beginning of the queue.  So I'm also
attaching a patch against msg.c to automatically destroy messages
attached to a given client when making a new message for it.

Okay now for a little diatribe about sliders...

I know this is all cvs pre-alpha but I really really
don't like the sliders stuff and the associated storage of the
x-offset in the .mbdock file.  I think my fundamental disagreement is
with scrollbars themselves -- if it's so frequently-used that i'm
docking it, i don't want to have to use sliders to get to it!  But
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kero van Gelder | 4 Oct 2002 10:00
Picon

Re: patches...

> Okay now for a little diatribe about sliders...
[snip]
> as a side effect, in no situation would it ever store the x offsets
> in .mbdock -- they would always be determined at run-time (if not
> just to make portrait/landscape switches more comfortable).
[snip]

I'd say, classical mistake: storing the result (x coords) instead of
the origin (alignment and order).

C code does not get longer from changing this, and the extra memory
and/or CPU required are negligible. The benefits are already
mentioned.

Just do it!

Bye,
Kero.

+--- Kero ------------------------------ kero <at> chello.nl ---+
|  Don't split your mentality without thinking twice       |
|                          Proud like a God -- Guano Apes  |
+--- M38c ---------- http://httpd.chello.nl/k.vangelder ---+
Permalink | Reply | 2 comments |
headers
mallum | 4 Oct 2002 10:45
Picon

Re: patches...

on Thu, Oct 03, 2002 at 10:02:51PM -0400, Greg Alexander wrote:
> 
> I discovered that if I tap on, for example, minisys like ten
> times a second 

10 times a second ! I bet you were good at 'Daley Thomsons Decathlon' ;-)

(sometimes letting the message window stay there for
> the full 5 seconds but other times interrupting it before the message
> even finishes sending) then eventually the message window just pops up
> for the briefest flash and then disappears.  This is caused by
> multiple message records getting put in the queue for the same window.
> (which happens if one message is begun before another finishes)
> The starttime (used for the delayed destruction of the message window)
> is set on the message record at the end of the queue but the text goes
> into the message record at the beginning of the queue.  So I'm also
> attaching a patch against msg.c to automatically destroy messages
> attached to a given client when making a new message for it.
> 
>

I need to have a look at this. Its been a while since I've hacked the
message stuff.

> Okay now for a little diatribe about sliders...
> 
> I know this is all cvs pre-alpha but I really really
> don't like the sliders stuff and the associated storage of the
> x-offset in the .mbdock file.  I think my fundamental disagreement is
> with scrollbars themselves -- if it's so frequently-used that i'm
(Continue reading)

Permalink | Reply | 0 comments |
headers
mallum | 4 Oct 2002 10:57
Picon

Re: patches...

on Fri, Oct 04, 2002 at 10:00:45AM +0200, Kero van Gelder wrote:
> 
> I'd say, classical mistake: storing the result (x coords) instead of
> the origin (alignment and order).
>

Ummm... In Matchbox _CVS_ the apps can be _freely_ positioned anywhere
theres space. Please explain to me how I 'classically' store there arbitrary
positions with just alignment and order ? 

Before this change it was just there 'alignemnt and order' stored. 

  -- Matthew
Permalink | Reply | 0 comments |
headers
Kero van Gelder | 4 Oct 2002 18:12
Picon

Re: patches...

> > I'd say, classical mistake: storing the result (x coords) instead of
> > the origin (alignment and order).
> 
> Ummm... In Matchbox _CVS_ the apps can be _freely_ positioned anywhere
> theres space. Please explain to me how I 'classically' store there arbitrary
> positions with just alignment and order ? 
> 
> Before this change it was just there 'alignemnt and order' stored. 

Forget the word 'mistake'. That's mine, I should have looked up CVS.

How about percentages? and still order, of course.

Bye,
Kero.

+--- Kero ------------------------------ kero <at> chello.nl ---+
|  Don't split your mentality without thinking twice       |
|                          Proud like a God -- Guano Apes  |
+--- M38c ---------- http://httpd.chello.nl/k.vangelder ---+
Permalink | Reply | 0 comments |
headers
Greg Alexander | 5 Oct 2002 04:20

misc notes...(and a patch)

Greetings everyone :)

First my thoughts on the mbdock issue:

Okay so I finally figured out how to use this move feature
to drag the icons around in the taskbar and I have to say I can
totally see why someone would think that's neat so I can see if I'm
going to make the mbdock that I really want I'm going to have to fork
it :)  And if I'm gonna do that then i think I'm gonna do some
horribly unclean and presumably unpopular things like integrate my
wierd button bar idea into the dock so I don't need to figure out how
to get the dock to have multiple rows of docked apps cleanly, etc.

mallum, it looks to me like you haven't checked in data/themes/camo/*
... :)

Now for the patch you've all been waiting for..

Today's patch is for src/wm.c.  When generating a window with a
transient setting it calls dialog_client_new(), but since my window is
of type _..._SPLASH, a dialog_client_new() call was already completed,
so we just waste an allocation.  More importantly for my purposes,
with type SPLASH the title bar is disabled, but on the newly-created
dialog_client_new, the hidden title bar flag is not present (the
client structure that has the flag set is replaced with the one made
from scratch).  The patch is to only call dialog_client_new() if a
client was not already created (I guess this could cause wierdness if
you use a non-dialog type when creating a transient window, but I
don't think this is a big worry).  Otherwise it just updates the
'trans' structure member.
(Continue reading)

Permalink | Reply | 2 comments |
headers
mallum | 5 Oct 2002 09:37
Picon

Re: misc notes...(and a patch)

on Fri, Oct 04, 2002 at 10:20:21PM -0400, Greg Alexander wrote:
> 
> Okay so I finally figured out how to use this move feature
> to drag the icons around in the taskbar and I have to say I can
> totally see why someone would think that's neat so I can see if I'm
> going to make the mbdock that I really want I'm going to have to fork
> it :)  And if I'm gonna do that then i think I'm gonna do some
> horribly unclean and presumably unpopular things like integrate my
> wierd button bar idea into the dock so I don't need to figure out how
> to get the dock to have multiple rows of docked apps cleanly, etc.
>

You dont have to fork anything ! Just write your own dock/tray -
matchbox will happily work with 'other' docks .. and if you follow
the terms of the GPL your free to use existing mbdock code. 

> 
> Today's patch is for src/wm.c.  When generating a window with a
> transient setting it calls dialog_client_new(), but since my window is
> of type _..._SPLASH, a dialog_client_new() call was already completed,
> so we just waste an allocation.  More importantly for my purposes,
> with type SPLASH the title bar is disabled, but on the newly-created
> dialog_client_new, the hidden title bar flag is not present (the
> client structure that has the flag set is replaced with the one made
> from scratch).  The patch is to only call dialog_client_new() if a
> client was not already created (I guess this could cause wierdness if
> you use a non-dialog type when creating a transient window, but I
> don't think this is a big worry).  Otherwise it just updates the
> 'trans' structure member.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Alexander | 5 Oct 2002 18:08

Re: misc notes...(and a patch)

>You dont have to fork anything ! Just write your own dock/tray -
>matchbox will happily work with 'other' docks .. and if you follow
>the terms of the GPL your free to use existing mbdock code. 

well by 'fork' i meant 'borrow' your mbdock code, make a few changes,
and then if I ever upload it, call it 'mbdock-greg' or 'gregdock'.

>Should a window of type Splash be transient ? 

My hack'n'slash techniques are revealed :) -- I do not know what a 
window type splash is, I was just looking through the code trying to
find a way to make a regular window without a titlebar (I guess I will
handle my own window movement) and I saw window type splash before I saw
the mwmhints part.  At any rate, without that patch the mwmhints get
ignored also.  matchbox code is making a very nice X tutorial -- thanks!

- Greg
Permalink | Reply | 0 comments |
headers
Greg Alexander | 6 Oct 2002 05:37

how to move a window?

Hey!

I am trying to move my transient-for-root 'dialog' window.
I've got it set up to call XMoveWindow() appropriately, but this is a
no-op for all windows that the window manager knows about, because it
winds up in wm_handle_configure_request().  For a while I had it
setting the override flag, so that the window manager would not manage
this window, but then there is little the window can do to stay 'on
top.'  I really don't want a title bar taking up screen space on this
window btw :)

So I'm attaching a patch that I'm sure is not quite the perfect
behavior, but it gets this situation...I just allow a window to set
its location and size, so long as it is a transient dialog for root.
I don't really know if this is ideal...I figure at least some set of
windows should be managed by the window manager at this level, but I'm
not sure how common practice relates.

The patch is really just there so you can get the idea.  I don't know
any reason not to include it but I'm sure there is one.

Thanks,

- Greg

p.s., my stroke program is pretty much done.  If anyone expresses any
interest, I'll upload it somewhere.  It's very unintuitive at first
but the strokes are very short and simple (it is mathematically
similar to just recording the start and end positions snapped to a 3x3
grid, for a total of 9*9=81 obvious combinations...but to the user it
(Continue reading)

Permalink | Reply | 0 comments |
headers
mallum | 4 Oct 2002 10:45
Picon

Re: patches...

on Thu, Oct 03, 2002 at 10:02:51PM -0400, Greg Alexander wrote:
> 
> I discovered that if I tap on, for example, minisys like ten
> times a second 

10 times a second ! I bet you were good at 'Daley Thomsons Decathlon' ;-)

(sometimes letting the message window stay there for
> the full 5 seconds but other times interrupting it before the message
> even finishes sending) then eventually the message window just pops up
> for the briefest flash and then disappears.  This is caused by
> multiple message records getting put in the queue for the same window.
> (which happens if one message is begun before another finishes)
> The starttime (used for the delayed destruction of the message window)
> is set on the message record at the end of the queue but the text goes
> into the message record at the beginning of the queue.  So I'm also
> attaching a patch against msg.c to automatically destroy messages
> attached to a given client when making a new message for it.
> 
>

I need to have a look at this. Its been a while since I've hacked the
message stuff.

> Okay now for a little diatribe about sliders...
> 
> I know this is all cvs pre-alpha but I really really
> don't like the sliders stuff and the associated storage of the
> x-offset in the .mbdock file.  I think my fundamental disagreement is
> with scrollbars themselves -- if it's so frequently-used that i'm
(Continue reading)

Permalink | Reply | 0 comments |

Gmane