Re: FVWM: style: Start Maximized ?? Start AnyFunction?????

From: Albrecht Kadlec <albrecht_at_auto.tuwien.ac.at>
Date: Tue, 30 Apr 96 19:41:58 +0200

>>>>> Sergios == <sergios_at_beryl.kapatel.gr> wrote:
>>>>> "Dan" == Dan Niles <dan_at_more.net> writes:
>>>>> Charles Hines writes:
>>>>> "Albrecht" == Albrecht Kadlec <albrecht_at_auto.tuwien.ac.at> writes:

On Subject:


Albrecht> my 2.0.41 man page says:
Albrecht> StartIconic/StartNormal

Albrecht> I'd like StartMaximized (but with the arguments, since I always want my
Albrecht> buttonbar with console and pager visible.)

S> StartMaximized would be excellent. Netscape ie. has this bad habit of
S> ignoring shamelesly the geometry specification and always start bigger
S> horizontaly than my desk. If I move netscapes window and press the maximize
S> button it resizes itself nicely. of course netscape sucks. but the function
S> would be nice....

Dan> Also, there is currently (at least not documented) way to have a window
Dan> start on a different page. So a unified StartsOn would be great. At the
Dan> very least, a StartsOnPage would be very nice.

or maybe the more general approach of a start function, which can do
various things, like placing the window, mapping it, maximize/iconify/maybe
send FvwmButtons a command to swallow it
(imagine: "goto DeskRelative 1, Map" for CAD applications,
"*FvwmButtons swallow (useold) perfmeter nop" for perfmeters, alarms and so
on, which you start in the middle of the session - on demand)




On my PS:

Albrecht> PS: chuck: I know it's rather late for a change, but could
Albrecht> the interfaces of Desk and GotoPage be unified ?

Chuck> It is getting late, but a cleanup like this might not be a bad idea.

Dan> One more vote for a unified Goto function with simplifed syntax.



Albrecht> what we need is a simple way to specify absolute/ relative
Albrecht> adressing for BOTH. (Page too)

Albrecht> I have to look the man page up EVERY time I use the Desk
Albrecht> command, which I'd count as an indicator, that it's not very
Albrecht> intuitive (to say the least IMHO).

Chuck> Yeah, that's definitely not a good sign.

Albrecht> I'd suggest
Albrecht> sth like
Albrecht> GotoDesk z
Albrecht> GotoDesk +z
Albrecht> GotoDesk -z
Albrecht> and
Albrecht> GotoPage x y
Albrecht> GotoPage +x +y
Albrecht> or have a single command

Albrecht> DeskPage +/-z +/-x +/-y

Albrecht> I think the code would be even shorter and much more
Albrecht> general.

Chuck> Probably not a bad idea, but I don't think that the proposed syntax
Chuck> would work for specifying relative moves, since desk numbers can have
Chuck> neg numbers. In other words, would GotoDesk -2 mean two desks
Chuck> previous or the actual desk -2?

RATS.

does anyone use negative desk numbers?
I know, desks are generated on the fly, but I really don't use this one, so
I can't say anything about it.

I'm rather satisfied with my single desk of 4x2 pages :-) (I prefer that to
more desks, since I change pages with the mouse most often, either crossing
borders, or clicking in the pager - which just shows my one desk)


the negative thingie also spoils my main argument for a combined/unified
interface:
It isn't really an x/y/z address, which goes from the origin (0/0/0) to
(inf/inf/inf)

So if we unified the interface, would someone specify Page -3 -3 ?
what should happen in this case?

is it possible to also extend pages to +-inf ?
does it make any sense to have that many pages / desks?


Chuck> Perhaps something like the following would work better:

Chuck> Goto [Page x y | RelativePage dx dy] [Desk z | RelativeDesk dz]

Chuck> Verbose, but no suprises.



Dan> That is alot to type. Perhaps have the possible invocations be:

I, too must say that I don't like this one very much.
        
well I'd also allow absolute rows /relative colums
   Goto [Page x y | RelativePage dx dy] [Desk z | RelativeDesk dz]


Dan> Goto x y z
Dan> Goto x y
Dan> Goto z
Dan> Goto Relative x y z
Dan> Goto Relative x y
Dan> Goto Relative z

Dan> So the summary would be ([] indicate optional inclusion):

Dan> Goto [Relative] [x y] [z]

rather difficult:
        one argument: desk only
        two arguments: page only,
        three arguments: desk and page ore page and desk

(I say: the desk is the most significant "digit", but other minds will
vary!!!) It'd also not be too intuitive to have the first parameter be
sometimes page, sometimes desk, depending on the number of parameters.







to sum it up: we won't have a unified interface, which is easy to remember,
as long, as the functions are different. (I overlooked that, when I started
this thread.)

And they differ greatly in parameter space.
Maybe we should discuss that one first, as the above syntax suggestions are
mostly a rename / move to a Goto prefix.

First of all: does anyone use negative desk numbers (except by accident)
As far as I remember these just resulted from Rob using signed 32bit
integers for the desktop numbers. Was this intentional, Rob?

What if we changed that to unsigned to provide a unified parameter space
with +/- as the "relative" indicators (the analogy to geometry was somewhat
intentional, though I hadn't thought it all to the end) ?

In fact a window is positioned
        on a desk
        on a page
        at a specific x/y position
        with a specific size.

the last two are out of reach (no one wants to change geometry), and also
somewhat different in semantics.


that said, if we can't get the parameterspace/meaning uniform, I'd rather
stick with two variants of two different functions:

        Desk[Relative] z
and
        Page[Relative] x y
        
(where we could also use Page -1 -1 as in geometry -1 -1: specifying the
bottom rightmost page)


sorry this got that long,

cheers,
albrecht
-- 
A friend of mine said he was trying to install Windows NT on a non-standard
machine.  Everything seemed fine until he actually ran Windows and a message
told him that something had gone astray.  I guess this could be considered
an unrecoverable error:
	No keyboard found.
	Press F1 to continue.			-- Kirsten Starcher
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Apr 30 1996 - 12:39:28 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:58 BST