Conference bulova::decw_jan-89_to_nov-90

It is a violation of the XUI Style Guide for an application to grab focus
on startup.  Focus is to be managed by the user, not usurped by applications.

--PSW

Call XtAddEventHandler on one of your widgets to trap MapNotify events:

  XtAddEventHandler (w, StructureNotifyMask, 0, StructureNotifyHandler, 0);

Then, in the StructureNotifyHandler, filter the events until you see
a MapNotify event.  Then, call XtCallAcceptFocus for the widget that you
would like to grab focus...

You paid $$ for your machine.  Make it work the way you want it to.

-steve-

But your customer paid for HIS machine make your application work as is
appropriate for him.  The vast majority of the time, this should be as the
style guide dictates (but not always).  If the style guide is wrong for
most customers, then the style guide should change.

The main reason for the style guide requirement to not take focus on startup
is that focus may be taken quite some time after the application actually
is requested.  If the user has gone on to work on something else while the
application starts, then he is going to be unhappy when focus is yanked.

Steve, you should know better than to assume that the developers likes and
dislikes have anything to do with the customers' requirements.

Dick

re .-1
>
>                              -< You're the boss >-
>
> You paid $$ for your machine.  Make it work the way you want it to.
>
	my thoughts exactly




re .-2

> It is a violation of the XUI Style Guide for an application to grab focus
>                                    -----
> on startup.  Focus is to be managed by the user, not usurped by applications.
>

	As it turns out, the "GUIDE" is just that.  Therefore one can't violate
	it per-se.  But I'm just being cheeky, and I apologize (couldn't
	resist it!!).

	Actually, it's a user request.  Almost all of my users have mumbled
	vehemently because the window that comes up doesn't have focus and
	now they have to reach for the mouse and click in either the
	title bar or command window widget to grab focus.

Thanks for the help.

- norm

RE: .4

What is your application?  I would like to know so that I remember never to run
it on my machine.

There is hardly anything more irritating than to be interacting with an
application only to have another application come up and grab focus away from
you.

--PSW

    DECwrite, for one, grabs focus

>What is your application?  I would like to know so that I remember never to run
>it on my machine.

	Doubt that you would have to fear that Paul.  It's an internal 
	graphing tool, XSPG, the output produced one of by DEC's internal 
	analog simulators called SPICE.  

	My question was originally triggered by user complaints that the 
	application didn't grab focus.

	My solution to the dichotomy will be to give XSPG a switch that
	allows the user to tell it grab focus on startup.  The default
	will be to not grab.

	Another interesting "burden" for the program has been to keep the
	CLI alive and operating in parallel with the GUI.  Lot's of fun.
	I wish it on my worst enemy!  Since my worst enemy is usually me 
	justice has been well served!

	I'm really not hostile to the notion of a consistent GUI having
	been a Mac user for quite a number of years.  However the group	
	think here at BXB (hardware development) is that the users' needs
	should mold how the tools work and feel not the other way around.

	I have written both XSPG and it's UIS ancestor to reflect the
	needs of myself and my coworkers.

    re .6 Not V1.1.... V1.0 did for certain cases (dialog boxes with text
    fields for example).
    
    			Pete

>	Another interesting "burden" for the program has been to keep the
>	CLI alive and operating in parallel with the GUI.  Lot's of fun.
>	I wish it on my worst enemy!  Since my worst enemy is usually me 
>	justice has been well served!

What do you mean "keep the CLI" alive"? Do you mean to keep the DECterm where
you started the program able to interact using DCL (or similar analogue for 
U*IX)? If so, my question is why are you using DCL to start the application?
Why not use the Applications pulldown from the Session Manager, that's what 
it's there for. If you have a box full of switches that must be thrown on the
command line, you can specify them in the application definition or you could 
present a command dialogue box to solicit them (or both). 

It sounds to me like you're only partially converting your application to use
DECwindow...

Confused...

James

> ...  If so, my question is why are you using DCL to start the application?
> Why not use the Applications pulldown from the Session Manager, that's what 
> it's there for. If you have a box full of switches that must be thrown on the
> command line, you can specify them in the application definition or you could 
> present a command dialogue box to solicit them (or both). 

	The CLI is a command line interface to the application while it is
	running.  It runs in parallel with the GUI.  It is there because a
	lot of people who can type well and fast actually prefer that to
	the GUI for a lot of operations.


> It sounds to me like you're only partially converting your application to use
> DECwindow...

	Well... that's debatable.  The original application ran under VWS 
	using the terminal emulator and SMG for the "control" window and
	a "native" uis window for graphing the waveforms.

	The DECWindows version uses natives windows for both the control
	and the graph windows.  The control window uses a command window
	widget in which to run the CLI.

	This interface, while "morally repugnant" to purist X/DECWindows
	programmers and applications designers, was diegned as necessary 
	since it would minimize compatibility problems and retraining 
	with the users.

	In essence I designed the program as a "true" DECWindows application 
	and then "grafted" the CLI onto it so that users who prefer CLI to 
	GUI would be happy.

	As for me personally...  I made sure there was a menu selection
	to disable the CLI.

Ok, I have one more question. We do a similar thing for DECforms. We have a
character cell interface for our panel editor, for character cell users and
a (prototype) native DECwindows for the editor as well. Both offer the SAME
CLI interface for those users which wish to use CLI commands to interact with
the editor. The important difference however, it that the CLI for the DECWindows
version gets it's input from a command widget while the CCT version uses the
terminal. 

My question is "If the user has specified that they want to interact with the
application via DECwindows, what is culturally incompatable with the soliciting
input from a command window? This is ineffect the same as a terminal window,
without as much overhead, and could offer exactly the same command set as the
terminal. In otherwords, do one or the other but don't try to mix the two.

This also has the advantage that you don't have to create a terminal just to 
start your application.

I agree however with your assement that keeping both the character cell
interface and the DW interface "active" at the same time is hard. Especially
when you're layered behind something like FMS, SMG, etc. To solve this problem
in DECforms, we've had to implement a lot of multi-threading code.

James

>My question is "If the user has specified that they want to interact with the
>application via DECwindows, what is culturally incompatable with the soliciting
>input from a command window? ...

	James, sorry for not making this clearer.  I do use the command 
	widget for ALL cli interaction with the program.  I had built
	a terminal version of the program 4 or 5 years ago that is still
	available.  If they are terminal bound they use that version.

	The biggest problem with this is when a command requires multiple
	components such as:

		set xmax 100

	Assume the user wants to be prompted so that the sequence would be

		set<cr>
			(programs prompts with "SET what")
		xmax<cr>
			(programs prompts with "Enter XMAX value")
		100<cr>

	Then the command dispatcher, the set dispatcher, and the XMAX
	set routine have to remember state so that each time it needs to
	prompt the user for more info it can "return to the command window"
	and then get back to where it left off.

	This reply is getting far afield of the original topic.  I would
	be interested in how you folks handled this off-line from this
	conference.  I suspect it's probably more elegant than how I
	did it.