Conference bulova::decw_jan-89_to_nov-90

>>    	Would anyone care to comment on the feasibility of such an
>>    approach.

Don't even think about it.  (But maybe there are some souls braver than I
who will give you other advice.)

Widget data structures have pointers to and from all over the place, and
they change from version to version of the toolkit.  And it is not clear
how much of the creation "cost" you could avoid anyway.

JMHO

-steve-

    This is about the fourth or fifth time this ground has been covered.
    I really don't understand what the problem is.
    
    If you want to create _a_ widget, then all you need is a widget class,
    parent, and arglist.  That's all you ever needed and all you will ever
    need.  Every widget can be thought of as a "clone" of some widget with
    a null arglist. (Although there's no convention that says that a widget
    initialization procedure must accept a null arglist, most do)
    
    If you want to create _a_ widget hierarchy (ie a tree of widgets with
    one widget that has exactly one external parent), then there is no
    short-cut.  In computer-science-speak, widget initialization is full
    of unspecified side-effects, both internally and in widget-to-widget
    interactions.  The method to create a widget hierarchy is the old
    fashioned way: one widget at a time. 

    
    Either:
    
    	o People are stupid
    
    	o It isn't obvious or well documented
    
    
    I'd vote for the last one.  Most people that I know of haven't devoted
    the last 3 years to decoding the workings of widgets, gidgets and
    gadgets.  They're trying to write an application and how all this works
    isn't readily apparent or easily explained in a 15 page manual.  Now
    they need to become X11/toolkit experts.  I'd get used to "obvious"
    questions being asked in here, they aren't that obvious.  And as others
    have pointed out, sifting through 2000+ topics for an answer will
    always be punted on in favor of just asking the question.
    
    

        re .3
        
>>    								And as others
>>    have pointed out, sifting through 2000+ topics for an answer will
>>    always be punted on in favor of just asking the question.
        
        Topics 3 and 4 are reserved for forward and reverse
        directory listings, but they are empty.  I made a forward
        listing available on the network after 1000 notes, but I
        don't think it got copied much.  Searching for an answer
        is still faster overall, but it is less aggravating to
        just post the question and come back tomorrow.
        
        Dan

    As the writer of the base note I apologise if my question has already
    been covered. I was fairly sure that the proposition was a non starter
    but i have discovered so much in Decwindows that has not been
    documented that I wanted to be sure.
    	The origin of my question was from a software house which is
    developing some software using many workstations and Decwindows.They
    are having performance problems and this is a suggestion that they came
    up with.I have been busy telling them how they should be implementing
    the software but I wanted to tell them exactly why cloning is not on
    rather than just saying that it can't be done.They are the sort of
    people who would waste time trying to do it . The replies have done
    that ,so thank you noters.
    
    regards Mark

    If I (or anyone) had the time, then I would compile a lot of the
    frequently asked questions and answers here into a document and see if
    the documentation folks would incorporate it into the formal
    documentation, and, at least, make it available internally. Ah...but
    who has the time? (It's 22:01 here in Hong Hong)
    
    The comment that "this question has been covered before" is really a
    signal to the questioner should be using DIR/TIT and DIR/KEY to
    attempt to see if identical or similar questions have been posed
    before.
    
    It's also a signal (as Fred pointed out) to the field people (like me),
    the engineers, and the doc writers, that in the process of
    communicating facts about DECwindows, a few important (perhaps obvious)
    ones seem to be overlooked in the formal documentation.
                                                              

Have you checked out the Customer Services Advisories? There's a section on
DECwindows troubleshooting in the V5.1 version which is guaranteed to make
your mouth water. The people who prepare these documents are very open to 
suggestions for topics to cover so drop them a mail.

You can get them from :-

		NOETIC::SYS$KITS:[FSA]

hth........Marcus

    Re:  original question...
    
    I gave this a shot once, on the assumption that a lot of widget
    initialization might be taken up in asking XRM for the value
    of all of the resources, and taking the default value for what
    is not found.  So, I tried an interface that copied an existing
    widgets instance record, and then just applied the *changes*
    defined by the argument list passed into the widget creation routine.
    
    Unfortunately, the gain appeared to be on the order of 5 - 10% of the 
    widget creation time.  I didn't think this was worth introducing
    new routines and complexity for...
    
    Leo
       

    If I am understanding you correctly, then it looks like
    the customer wants to 'widgetize' an application for X/etc..
    no?  If my assumption is wrong, then please ignore the rest
    of this note.
    
    A more radical idea would be to use a UIMS system to
    redesign the application.  What language? How easy is
    it to isolate the 'old' core code from the user interface?
    You did mention the fact that the customer is using "many
    workstations" (different vendors?).  A multi-platform UIMS
    can help you create widgets once, that are useable by all
    workstations. This reduces the 'cloning' overheads.
    
    Automation of the widget creation process seems to be 
    more efficient than otherwise...especially in a mixed
    development environment, with a common target goal of
    building the same application with the same user interface.
    Also, a UIMS that has dialog management makes it easier
    to separate the 'old' application core code from the user int-
    erface, provides the ability to 'test drive' the application 
    via the 'new' user interface built from the UIMS, before it 
    is actually linked to the core code; and also, ensures high
    reuseabilty of the core application code - ie, if you ever have
    to port to another GUI (eg. OpenLook) in the future.
    
    Clear as mud? ;-) ...too late to write clearly.
    
    We are in the midst of doing something similar for one of
    the world's largest retail banks.  Taking a terminal-based
    platform/teller system into the world of X/Motif widgets.
    
    Please send me mail if you are interested in our approach.
    
    Kris.. (fuel::graham)