Subject: Pushpins

From: "Nils Lohner" <[email-masked]>
Date: Thu, 11 Jan 2001 15:42:08 +0100

>From 'man fvwm2':
OPEN LOOK and XVIEW COMPATIBILITY
     Fvwm supports all the Open  Look  decoration  hints  (except
     pushpins).  

Is there any way of getting these to work?  Several of the programs we 
need to use at work rely on them for find-and-replace type 
functionality.  Would this be hard to implement?

Thanks,
Nils.

--
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: Dan Espen <[email-masked]>
Date: Thu, 11 Jan 2001 10:36:19 -0500

> functionality.  Would this be hard to implement?

For me, the pushpins that I see in xview applications work fine.
For example, when I right click in cmdtool, I get "Term Panel".
If I select "Edit", I see a menu with a pushpin.  If I click on
the pushpin, I get a window with fvwm decorations that hangs around.

Can you be more specific?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Sat, 9 Jan 1904 03:29:00 +0100

> Can you be more specific?

I wrote that part of the man page, but I don't remember exactly
how pushpins should work.  Fvwm does not handle the pushpin hint
in any way.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Nils Lohner <[email-masked]>
Date: Thu, 11 Jan 2001 17:04:46 +0100

In message <[email-masked]>, Dan Espen 
>Can you be more specific?

Sure.  That works fine for me as well, but if you open textedit and then the 'find and replace' dialog, in olwm it has a pushpin in the titlebar.  If you push it in, then the window does not disappear when you click on 'find' or any of the other options.  It's annoying (to say the least :) to bring it up over and over again when replacing a lof of stuff.

Nils.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 9 Jan 1904 04:09:57 +0100

> Sure.  That works fine for me as well, but if you open textedit and then the 'find and replace' dialog, in olwm it has a pushpin in the titlebar.  If you push it in, then the window does not disapp…

It's probably not too hard to code.  We'll need a new title button
type that resopnds to the pushpin hint and is only displayed when
this particular hint is used by the application.  But I don't know
how the pushpin hint is supposed to work internally.

Bye

Dominik ^_^  ^_^

---

From: Charles Hines <[email-masked]>
Date: Thu, 11 Jan 2001 11:36:06 -0500 (EST)

>>>>> "Nils" == Nils Lohner <[email-masked]> writes:

Nils> In message <[email-masked]>, Dan Espen 
>> Can you be more specific?

Nils> Sure.  That works fine for me as well, but if you open textedit and then
Nils> the 'find and replace' dialog, in olwm it has a pushpin in the titlebar.
Nils> If you push it in, then the window does not disappear when you click on
Nils> 'find' or any of the other options.  It's annoying (to say the least :)
Nils> to bring it up over and over again when replacing a lof of stuff.

I needed a short break from what I was doing, so just for grins I took a quick
look at the source code for olvwm4, and it looks like toggling that pushpin
state merely sets an atom on the window that the OpenView lib functions must
look at to determine whether or not to close the window after the actions
occur in that window.

Perhaps a simple way to add support for this in fvwm could be to have a style
option like OLPushpinAlwaysIn that that would always just set the appropriate
atom value on the window if that hint is present, requiring an explicit close
on the part of the user to dismiss the window.

Or to handle this without touching fvwm mainstream code at all, a module could
be written to handle toggling the state which you could then place calls to on
your menus.  Without changes to fvwm itself that would appear for all windows
of course, not just the ones with the hint.  A minor nit, but would it matter?

Back to my usual lurking now...

Chuck

-- 
Charles K. Hines   <[email-masked]>   <[email-masked]>
Principal Scientist at ReQuest Technologies Inc   (http://www.ReQuestTech.com/)
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)

---

From: Dan Espen <[email-masked]>
Date: Thu, 11 Jan 2001 11:40:54 -0500

Nils Lohner <[email-masked]> writes:
> Sure.  That works fine for me as well, but if you open textedit and then the 
> 'find and replace' dialog, in olwm it has a pushpin in the titlebar.  If you 
> push it in, then the window does not disappear when you click on 'find' or an
> y of the other options.  It's annoying (to say the least :) to bring it up ov
> er and over again when replacing a lof of stuff.

Ah, now I see.

Since I started using Solaris 8, I started getting messages about olwm
having no future.  (The X server seems to assume that anything that is
not CDE is olwm.)  I suppose if Sun ever drops olwm  you can switch to
olvwm, but I wonder if textedit, cmdtool, and the other xview apps are
also destined for the trash heap.

For my non-technical users, I've installed "nedit".  They seem to love
it.

Getting back on subject, if we were to implement this, everything we
need to do seems to be available in "olvwm".  When the hint is set,
the pushpin is added to the title bar.  When the pushpin is pushed,
the window manager (fenstersystemen?) does:

  /* Tell the client that the state of its push-pin has changed. */
  XChangeProperty(dpy, PANEWINOFCLIENT(cli),
		  AtomPushpinState,
		  XA_INTEGER, 32,
		  PropModeReplace,
		  (unsigned char *)&(winInfo->pushpinin), 1);
  
  if (!winInfo->pushpinin && sendDelete)
      ClientKill(winInfo->core.client,False);

Of course, there is more to it, I just thought I'd outline
whats missing.

---

From: Nils Lohner <[email-masked]>
Date: Thu, 11 Jan 2001 18:26:16 +0100

In message <[email-masked]>, Charles 
Hines writes
>on the part of the user to dismiss the window.

This would be enough if it's easily doable... I'd much prefer double 
clicking to close the window than having to re-open it via the menus 
every time.  When it closes, some of the fields are also blanked...

Nils.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 9 Jan 1904 21:24:04 +0100

> Of course, there is more to it, I just thought I'd outline

Gee, so many volunteers to write the code (Chuck, Dan, Nils) ;-)
I won't move a finger, but it's okay by me to write that stuff
for 2.4.

Chucks approach requires:

 - A new style (touching several files and the man page).
 - A new step in window creation using the code Dan quoted above.

The complete solution will require:

 - A new ButtonStyle a la OLDecorPushpin complete with graphics.
 - Write man page entry.
 - Choose a sensible default.  I'd use the pushed state as the
   default.
 - ...?

Bye

Dominik ^_^  ^_^

---

From: Nils Lohner <[email-masked]>
Date: Fri, 12 Jan 2001 14:00:40 +0100

>I won't move a finger, but it's okay by me to write that stuff

If someone could do it I'd be grateful, I've never really touched the 
fvwm code and it would take me a while to figure out how/where/what to 
do... :\

How far off is 2.4 anyway?  I assume presently fvwm is mostly in a 
frozen-bugfix state?  Is there a roadmap?

Thanks,
Nils.

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 Jan 2001 09:04:20 -0500

> I won't move a finger, but it's okay by me to write that stuff

Gee, how did you get that pound sign (#) to appear at the end of
your "to" line? ;-)

My first reply to "[email-masked]#" bounced.

I don't see this going into 2.4.

I think we should get the tests completed, run them, then release 2.4.

---

From: Charles Hines <[email-masked]>
Date: Fri, 12 Jan 2001 09:12:15 -0500 (EST)

>>>>> "Dominik" == Dominik Vogt <[email-masked]> writes:

Dominik> Gee, so many volunteers to write the code (Chuck, Dan, Nils) ;-)
Dominik> I won't move a finger, but it's okay by me to write that stuff
Dominik> for 2.4.

Hey, I just wanted to provide a hint!  :)

Actually, I'd love to contribute to fvwm again, but there was a reason I had
to give up maintaining it way back when - lack of time to devote to it.  While
my job has changed the general situation remains the same most of the time, so
I doubt I'll be able to get around to doing it. :(

Of course, if it were something that affected me directly I'd make the time to
fix it.  But since I don't use any of the tools affected by this...sorry.

Dominik> Chucks approach requires:

Dominik>  - A new style (touching several files and the man page).
Dominik>  - A new step in window creation using the code Dan quoted above.

Or the even more simplistic standalone module approach I mentioned which just
requires a new standalone (and most likely very small) module.

>>>>> "Nils" == Nils Lohner <[email-masked]> writes:

Nils> If someone could do it I'd be grateful, I've never really touched the 
Nils> fvwm code and it would take me a while to figure out how/where/what to 
Nils> do... :\

If it's just fear stopping you...implementing the module approach would likely
be the easiest intro into fvwm coding since you really wouldn't need to know
much if anything about fvwm internals.  There are a lot of simple little
modules that you could look at as a start, and basically you could snarf the
low level X11 calls right from the olvwm4 source (available at ftp.x.org if I
recall correctly).

Or you could talk Dan into doing it...or if I'm feeling guilty later perhaps I
will look into it... :)

Back to lurking again.

Chuck

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 12 Jan 2001 22:14:30 +0100

> Hey, I just wanted to provide a hint!  :)

Give me an inch and I'll take a mile :-)=)

> I doubt I'll be able to get around to doing it. :(

Well, every bit helps ;-)  I guess you know how I feel with all
this work to do and nobody else writing code at the moment.

> requires a new standalone (and most likely very small) module.

Hm, it may be easy, but it's rather silly to have a module for
something like this, isn't it?

> Or you could talk Dan into doing it...or if I'm feeling guilty later perhaps I

Chuck, you risk that fvwm-2.4 will not be released this year if
you don't help!

Does this make you feel guilty?

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: Nils Lohner <[email-masked]>
Date: Sun, 14 Jan 2001 18:57:23 +0100

> - Choose a sensible default.  I'd use the pushed state as the

OK. I'll bite. I think Chuck's approach is sufficient and easier...am I right (If not I'd go for the more complete one)?  Any pointers on how/where to start?

Nils.

---

From: Dan Espen <[email-masked]>
Date: Sun, 14 Jan 2001 13:39:29 -0500

Nils Lohner <[email-masked]> writes:
> OK. I'll bite. I think Chuck's approach is sufficient and easier...am I right
> (If not I'd go for the more complete one)?  Any pointers on how/where to
> start?

I'm not sure you need to write a module, thats up to you.

MwmDecorMax is an example of a button that changes state (toggles).
You will want to look at olvwm to find the hint that will make you
add the pushpin to the window.
Look at MwmFunctions for examples of buttons that only appear when
hints are set.

---

From: Dan Espen <[email-masked]>
Date: Sun, 14 Jan 2001 14:34:17 -0500

> > > - Choose a sensible default.  I'd use the pushed state as the

Pushpins only appear on windows that have the hint set.
The hint indicates whether the pin is pushed or not. Olvwm:

    	/* 
     	 * Convert the pushpin's initial state.
     	 * 
     	 * There's some backwards compatibility code here.
     	 * Older clients use the _OL_PIN_IN and _OL_PIN_OUT atoms
     	 * here, whereas the OLXCI specifies zero as out and one as
     	 * in.  Convert old into new.
     	 */
    	if (winAttr->flags & WA_PINSTATE) {
		if (winAttr->pin_initial_state == AtomPinIn)
			winAttr->pin_initial_state = PIN_IN;
		else if (winAttr->pin_initial_state == AtomPinOut)
			winAttr->pin_initial_state = PIN_OUT;
	}

Oops, sorry, seems like I'm acting like a back seat driver.

---

From: Charles Hines <[email-masked]>
Date: Mon, 15 Jan 2001 10:45:14 -0500 (EST)

>>>>> "Dominik" == Dominik Vogt <[email-masked]> writes:

Dominik> On Fri, Jan 12, 2001 at 09:12:15AM -0500, Charles Hines wrote:
...
>> Hey, I just wanted to provide a hint!  :)

Dominik> Give me an inch and I'll take a mile :-)=)

:)

...
>> Or the even more simplistic standalone module approach I mentioned which
>> just requires a new standalone (and most likely very small) module.

Dominik> Hm, it may be easy, but it's rather silly to have a module for
Dominik> something like this, isn't it?

Yeah, perhaps.  But since it apparently doesn't affect a lot of people (or
else we'd have more people yelling about it) it seemed a simple way to suggest
trying it that way.

...
>> Or you could talk Dan into doing it...or if I'm feeling guilty later
>> perhaps I will look into it... :)

Dominik> Chuck, you risk that fvwm-2.4 will not be released this year if
Dominik> you don't help!

Dominik> Does this make you feel guilty?

That gave me a good laugh, thanks! :)

Later,
Chuck

---

From: Nils Lohner <[email-masked]>
Date: Mon, 15 Jan 2001 19:23:55 +0100

In message <[email-masked]>, Nils Lohner 
writes:
>(If not I'd go for the more complete one)?  Any pointers on how/where to start?

Well, I'm stuck.  I've looked at the MWM_DECOR_* stuff, the OL_DECOR_* 
stuff, and the SHADE stuff.

The pushpin is a style; fine: in do_button_style() somewhere.
then something in the hints I assume:  decorations.c if 
(SHAS_OL_DECOR(sflags) && (t->ol_hints & OL_ANY_HINTS))

but from there I don't see where to go.  SHADE strings exists in too 
many files... from what I know now, here's what I need:

- the style OLDecorPushpin is probably not necessary: it should be 
there if the app requests it (can there be a check for whether or not 
it exists?  I assume so, since in OLWM the windows wither have a normal 
leftmost button or the pushpin.  question: how?)
- the leftmost title button could (should?) be taken over for this; 
else the button should be drawn if/whenever the hint is set/exists (is 
it a hint?)
- the default state should come from the application
- when its pushed in, the wm needs to tell the application that it is 
pushed in
- a double click in either case should close the window

I'm looking for pointers on what files to touch/ not to touch, and 
where/what #defines to use.  The MWM Decors seem wrong for this, so its 
probably the OL_DECOR_* stuff in decorations.c

Digging is
Nils.

---

From: Dan Espen <[email-masked]>
Date: Mon, 15 Jan 2001 15:38:07 -0500

> leftmost button or the pushpin.  question: how?)

Despite my poor batting average today, I'll try to help.

What does the "normal" leftmost button do vs. the pushpin?
I would have guessed that if the pushpin hint wasn't set,
there wouldn't be any button at all.
I guess it uses the pushpin as a "close" substitute?

Fvwm likes to have everything configurable thru Styles.
For this feature, we would normally enable it with

Style * OLPushPin

all that would say is that  if a window  has the PushPin hint, and the
window style allows it, its ok to show the PushPin.

> else the button should be drawn if/whenever the hint is set/exists (is 

Fvwm doesn't assign a fixed function to any button.
Look at MwmDecorMax as an example:

ButtonStyle 1 - MwmDecorMax

says that button 1 is the MwmDecorMax button.

You would have:

ButtonStyle 1 - OLPushPin, ActiveUp (Pixmap pinout.xpm) \
                ActiveDown (Pixmap pinin.xpm)

(not checked for validity)

If you get the OLPushPin bit set in the buttonstyle,
you will then want to look at the logic that puts the buttons on
the window.  If the window has the pushpin hint set, and its
buttonstyle has a pushpin, add the pushpin
button to the window.

---

From: Nils Lohner <[email-masked]>
Date: Tue, 16 Jan 2001 08:53:02 +0100

In message <[email-masked]>, Dan Espen 

>I guess it uses the pushpin as a "close" substitute?

The button functions normally, i.e. a double click closes the window.  
A single click pushes/pulls the pushpin.

>says that button 1 is the MwmDecorMax button.

Yes, I know... I wasn't sure how to deal with this.

>buttonstyle has a pushpin, add the pushpin

I think there's a simpler solution that suffices.  The fact that others haven't brought this issue up makes me think most people don't run into this issue (indeed, we only do because we're stuck with textedit) so there's a simpler solution.

Just figure out if the window has a pushpin hint, and if so, set it to 'oushed' automatically via the code you posted a while ago... problem solved!

This means that you'll need to close anything pushpinned manually, but that's not a big deal.  Next step would be to add a configurable default somewhere (default pushed, configurable to not pushed) and the step after that if anyone really needs it would be to tie it into the 'Close' functionality of a button like 'Mouse 0 1 A Menu Window-Ops Close'
  The first option is probably enough for me, and should only take mods in one or two routines.  The question is which one.  I'll try to find it and also try to figure out where to get the pushpin hint from in the first place.

Thanks,
Nils.