Gustavo Sverzut Barbieri wrote:
> But it would be useful to control the music too... someone else already
> mentioned it.
>Maybe we could have a button to toggle music control. In a ideal
> solution you can press this button and a mini music control will slide
> from some side of the screen and
--- Dirk Meyer <[EMAIL PROTECTED]> escreveu:
> Matthieu Weber wrote:
> > On Wed 28.07.2004 at 09:23:01PM +0200, Dirk Meyer wrote:
> >> Matthieu Weber wrote:
> >> > Besides, if we have two apps running at the same time (e.g.
> mplayer for
> >> > the music and the image viewer, or mplayer for video
Matthieu Weber wrote:
> On Wed 28.07.2004 at 09:23:01PM +0200, Dirk Meyer wrote:
>> Matthieu Weber wrote:
>> > Besides, if we have two apps running at the same time (e.g. mplayer for
>> > the music and the image viewer, or mplayer for video and the menu
>> > displaing inside mplayer), both app must
On Wed 28.07.2004 at 09:23:01PM +0200, Dirk Meyer wrote:
> Matthieu Weber wrote:
> > Besides, if we have two apps running at the same time (e.g. mplayer for
> > the music and the image viewer, or mplayer for video and the menu
> > displaing inside mplayer), both app must have an eventhandler, but
>
On Wednesday 28 July 2004 21:23, Dirk Meyer wrote:
> We already have this. There is an event that the audio player
> stops. When you use the image viewer with background music, the viewer
> doesn't care about that event, the background player does.
This is what I have been talking about for a looon
Matthieu Weber wrote:
> Besides, if we have two apps running at the same time (e.g. mplayer for
> the music and the image viewer, or mplayer for video and the menu
> displaing inside mplayer), both app must have an eventhandler, but
> only one (the image viewer) has the focus.
We already have this
On Wednesday 28 July 2004 09:24, Matthieu Weber wrote:
> > I think so. I would prefer windows having parents again, coordinates
> > being relative again and events to be propagated. That would also allow
> > for global event handling.
>
> This is a mystery for me: in what case should an event be p
On Tue 27.07.2004 at 04:47:53PM +0200, Hans Meine wrote:
> On Tuesday 27 July 2004 16:19, Dirk Meyer wrote:
> > >> Now I need some ideas for future development:
> > >>
> > >> o I moved the eventhandling into eventhandler.py. Fine, but now we
> > >> have a module eventhandler and most classes have
Hans Meine wrote:
> On Tuesday 27 July 2004 17:49, Dirk Meyer wrote:
>> No, it's not that easy. The audio player is as fullscreen as the image
>> viewer.
> Why? (I understand that it covers the screen, but "fullscreen" IMO should be
> exactly meaning: I do not want extra information on screen, whi
On Tuesday 27 July 2004 17:49, Dirk Meyer wrote:
> No, it's not that easy. The audio player is as fullscreen as the image
> viewer.
Why? (I understand that it covers the screen, but "fullscreen" IMO should be
exactly meaning: I do not want extra information on screen, which is not the
case..
> Bu
Hans Meine wrote:
> On Tuesday 27 July 2004 16:19, Dirk Meyer wrote:
>> I'm open the better ideas. What it does: eventhandler.append(self)
>> adds self to the eventhandler list, setting the focus to self. If you
>> remove self again, the focus will go to the app above.
> I think this is fine, maybe
On Tuesday 27 July 2004 16:19, Dirk Meyer wrote:
> I'm open the better ideas. What it does: eventhandler.append(self)
> adds self to the eventhandler list, setting the focus to self. If you
> remove self again, the focus will go to the app above.
I think this is fine, maybe "push" and "pop" would b
Matthieu Weber wrote:
> On Tue 27.07.2004 at 02:00:46PM +0200, Dirk Meyer wrote:
>> o The event stuff is deleted inside rc.py. There is a new file
>> eventhandler.py with functions to post an event and to get the
>> focus. Boxes from widgets also use the same way of getting the focus
>> as ot
13 matches
Mail list logo
