Conference bulova::decw_jan-89_to_nov-90

349.0. "Strategic direction suggestions needed" by KETJE::DIERICK (BLACK HOLES ARE OUTASIGHT) Wed Mar 08 1989 03:11

I put the next question in DW_examples conference because BULOVA::
Decwindows had problems. I have seen that got fixed, so I post
the question here again.

My customer has an application which he is planning to port to
Decwindows XUI and XLib. It was previously written using GKS.
He had a graphical editor to make industry processes monitor screens.
Since the entire monitor was bigger then one screen, he divided
the map in sectors (16).
While creating such a monitor screen with a graphical editor 
the user could position himself
on 'sector bounderies' to see more then one piece of the puzzle
and link them together nicely.
Once the screen with all the objects on it is ready, it is integrated
with a process monitoring application.
An operator working with the monitor could also switch sectors.
Question is :
	Are there functions in X to make a similar construction 
		possible in an easy way ?
	  ==> my answer would be : NO
	      Am I correct ? And if there's no easy way, what would
	      you suggest to do and how to do it ?
In the same application we need a zooming function to select an
area or an object and zoom it in/out (could be pixmap objects, could be
no pixmap objects).
Same question : Are there functions in X to do this (like GKS coordinate
			transforms for instance) ?
		If not, what can we do ( I am not really an experienced
			graphics programmer, but I think we'll have
		        to scale all our objects in the selected area) ?
			
Simple question, if we would implement a rubber band for selecting an
area and find all the items in the area, is there X support for this
? (And once again my answer would be : no, no direct support).
If any of you have small examples of any of these features we need,
I would be very, repeat : very happy to get a copy by mail.


Dominique


In the dw_examples conference I got one reply suggesting using
Vax Image Services to solve the problem, but we don't want that.
The monitor screen consists of seperate object (valves, pipes...).
Each of these objects must be selectable, and when creating the
screen with the editor zoomable.
In fact the application can be compared with a printed circuit
board design application...where you also have to put predefined
components onto a lay out screen.


Last question : would this be an idea to create our proper widget
as an editor ? Not having done this yet I would like to get
some feedback on difficulties creating a graphics editor
widget for our application ( like the GObe widget for instance).
Or do we go through hell doing this ( as the customer is entirely
new to X).

	Why doesn't GKS v4.0 with DECwindows support work properly with
your older GKS code?

Kevin

    Well, we did a benchmark comparing Xlib speed and GKS speed,
    and we saw a 4 to 1 performance when drawing screens.
    That's why the customer wants to use Xlib and XUI now.
    Dominique

    It sounds like your application is suited to a high-level graphics
    package such as GKS. Xlib plus XUI does not give you a high-level
    graphics package. Rather, it gives you a low-level graphics package and
    a windowing system with widgets.
    
    Since your customer wants higher performance than GKS can provide they
    had better be prepared to implement the high-level functions which they
    require more efficiently than GKS does. While they might be able to do
    that, they should not expect to be able to get the same performance as
    if they were using Xlib directly.
    
    The main problem will be that your customer needs a "world coordinate"
    graphics interface in order to perform the required zooming. This, by
    itself, is not a mammoth task and can be fairly well optimized for
    performance. You might implement this as a single widget (per
    application graphics window) although the drawing functions themselves
    do not require you too.
    
    More sophisticated user interface requirements will be served through
    functions in the DECwindows Toolkit and perhaps by a custom widget if
    the requirements demand it.