Subject: Re: FVWM: Tear off menus

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 10 Mar 2002 00:13:46 +0000

I moved this thread to here.

On 09 Mar 2002 21:55:40 +0100, Dominik Vogt wrote:
> 
> On Sat, Mar 09, 2002 at 07:50:09PM +0000, Mikhael Goikhman wrote:
> > On 09 Mar 2002 16:54:21 +0100, Marcus Lundblad wrote:
> > > 
> > > > I'm not yet finished with the implementation yet.  There are some
> > > > quirks that bug me.  Any input is welcome.
> > > 
> > > Another option I would like is to be able to let the title of the window
> > > be the title of the menu, and not show the title in the menu itself.
> > 
> > And what to do about menus with 0 or 2 titles? Or with one title in the
> > middle of the menu.
> > 
> > On the other hand we already have "Title top", that may be only one per
> > menu. "Title top" may be used for a window title and be removed.
> > 
> > Also two possible options to MenuStyle:
> > 
> >   MenuStyle * FirstTitleIsAlwaysTop  # the name may be different
> 
> What should this style do?

The intention is for every menu to always have one main title (usually
undefined). "Title top" argument may identify the main title. In addition
this option would assign the first Title to be the main one. The main
title as opposed to regular Title items is removed from the torn off menu.

It is hard to see what you already did about first titles, because the
current cvs can't be compiled.

Flocale.c: In function `FlocaleUnloadFont':
Flocale.c:506: structure has no member named `fftfont'

> >   MenuStyle * ForceTearOffSeparator  # add dashed separator at the top
> 
> That can't be done easily.  It requires modifying the menu itself.
> It's simple to add additional items to menus that are already torn
> off, but not to regular menus.

The solution may be to always add a tear-off separator item at the top
(probably after the main title) that has a boolean state (visible or not).

> > I suggest to remove the current Mouse 2 binding on menu titles.
> 
> I didn't know what else to do.  I agree that it's not a good idea.
> 
> > In the future I would like to have configurable mouse or keys bindings
> > for menu items.
> 
> I hope you're not talking about bindings with modifiers, mouse
> motion and such ...  Different actions for the mouse buttons might
> be good start.  I have been thinking about that for quite a while.

Well, I did think about real bindings, but this is probably not needed.
I agree with you that something like this would be a good start, but the
syntax for this is problematic. Maybe something like this:

AddToMenu my-menu
+ "item label" (DefaultCommand0 Args0), (3 CommandOnButton3 Args3)

There was a request to enhance fvwm-menu-directory so it does different
actions on different mouse buttons (view file, edit file, run file).
I would bind a file operation submenu for mouse button 3.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 10 Mar 2002 09:34:25 +0100

> Flocale.c:506: structure has no member named `fftfont'

I do not understand this.  Clean sources checked out from CVS into
a new directory compile well for me (without enabling fribidi and
xft which I don't have on that machine).  Did you perhaps make a
check out in the short period of time between my first commit and
the second?  As always, I forgot to cvs add some files in the
first one.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 10 Mar 2002 12:05:26 +0000

> the second?  As always, I forgot to cvs add some files in the

Ok, if you don't HAVE_XFT, this explains why it compiles well for you.

-  FftFontClose(dpy, flf->fftfont);
+  FftFontClose(dpy, flf->fftf.fftfont);

Also in event.c, menuitem.c and several modules in order to compile I
temporarily did:

-#ifdef HAVE_XFT
+#if 0 && HAVE_XFT

There are still warnings:

Fft.c: In function `FftDrawString':
Fft.c:168: warning: assignment from incompatible pointer type
Fft.c:197: warning: passing arg 1 of `XftDrawString8' from incompatible pointer type
Fft.c:201: warning: passing arg 1 of `XftDrawDestroy' from incompatible pointer type

I don't commit these compilation fixes, because they don't really fix XFT.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 10 Mar 2002 23:09:54 +0100

On Sun, Mar 10, 2002 at 12:05:26PM +0000, Mikhael Goikhman wrote:
> ... 

Fixed (at least for XFree-4.2.0). Olivier