Glade-Perl - perl source code generator
# Copyright (c) 1999 Dermot Musgrove <dermot.musgrove@virgin.net>
#
# This library is released under the same conditions as Perl, that
# is, either of the following:
#
# a) the GNU General Public License as published by the Free
# Software Foundation; either version 1, or (at your option) any
# later version.
#
# b) the Artistic License.
#
# If you use this library in a commercial enterprise, you are invited,
# but not required, to pay what you feel is a reasonable fee to the
# author, who can be contacted at dermot.musgrove@virgin.net

TODO
----
*   Make better Examples/tests.
    1) Simple 'getting started' project and subclass example with docs
    2) UI from string (exists)
    3) More complex Gtk UI with subclass and use_modules
    4) Gnome UI with subclass

*   Cut out all checks and diagnostics if verbose == 0

*   Recombine into fewer .pm files, possibly fewer packages

*   Make projectname_SUBS.pm file (as pre 0.2.0) if requested

*   Make dist files eg Makefile.PL, MANIFEST, Changelog etc etc

*   Internationalise every stage but particularly the source code generation
    of Gnome::App and Stock stuff
    
*   Sort out Gnome::App accelerators and signals properly Probably it
    would be best to implement the gnome-app-helper methods and use those when
    they are available.
    
*   Fix the signal handling for AccelLabels and pixmaps. Which widget should
    the signal be connected to?

*   Look at writing one perl file for each module/class so that, for instance
    ReferenceForm would be in file Generated/ReferenceForm.pm and fileselection1
    would be in Generated/fileselection1.pm. You could then use() and new()
    previously generated forms without having to write handlers and so on.
    
*   Possibly move UI subs to PerlGenerate
    
*   Improve the documentation. Find a way to keep perl source, perldoc
    tooltips, help text, README, web page etc in step and up to date.
    Perhaps embed XML in the source - or even source in XML and generate
    everything from that? Please email me if you know how it should be done.
    Investigate (lib)Guide for all docs and trouble-shooting.
    
*   Check all evals for proper exception handling.

*   Generate extract and display subs to give examples of how to set and get
    widget data. Perhaps not necessary.

*   I use several 'eval's, one allows for dynamic construction
    of (unknown) widget types and another is only so that the 
    UI can be built and a source line generated with the same 
    call (at least they stay in step - if the UI displays then
    I know that the generated code will work the same way.)
    However, I am not sure that 'evals' are a proper way to go but it is
    probably too late to change now.

*   It is still inefficient. I construct an XML::Parser 'Tree' 
    and then build a proto hash. Then I recurse through the proto 
    hash and build the UI and write the perl source. Apart
    from converting it all to Java and back again I can't 
    think how to slow it down any more :-). But I must shorten 
    the journey between XML and constructors, perhaps the libglade
    bindings from Philippe GIACINTI <philippe@giacinti.com> will
    help here. 
    
    Or perhaps use a streaming approach. I don't think that it is possible to 
    show the dialog until it is completely constructed so it will just speed 
    up the building before showing it at the end of the stream.
    
    Or perhaps write my own simple parser using regexps.

    Or perhaps use libxml

    Profile the whole process and remove any time-consuming diagnostics
    
*   Much inefficiency in the number of diagnostics that can be produced.
    When it is stable I should comment out the most frequent and expensive 
    calls to Glade::PerlProject->diag_print() and ->use_par().
    
*   Clean all the debugging stuff out and tidy the code properly.

*   Make all my modules object-oriented and remove all the Exporter() stuff.
    
*   Investigate using closures in generated code and allow user_option to
    select the type of code generated.

*   Check that we are not going to overwrite the existing modules
    file or find way to insert existing subs into any existing SUBS file

*   Improve the Glade source code generation process - Make Glade::PerlHelper 
    UI to allow users more control of the whole shebang.

*   Change 'single' quoted strings to "double" wherever someone might 
    enter ' eg tooltips, labels, items, text etc. Perhaps decide at run-time so
    that q(), '', "" etc will always work.

*   Do not generate run() or destroy_Form() subs for the classes, they only
    cloud the issue and cause problems with multiple Gtk->main() calls

DONE
----
*   Implement Gnome widget 'GnomeAnimator',(in Glade >= 0.5.4)

*   Implement Gnome widget 'GnomeDruid*',(needs Gtk-Perl CVS after 19990925)

*   I have no idea how portable the Makefile.PL is. There are bound to be 
    problems with Gtk and Gtk-Perl versions, possibly I can handle this via 
    Gtk-Perl's ./configure and capabilities. 

    I have heard from users on other platforms so I guess that this works OK
    Please email me with any successes or failures.

*   Add user option 'log_file' (defaulting, as previously, to STDOUT/STDERR)

*   Add some extra generated utilities eg toplevel_hide/destroy/close

*   Make subclass.pm for later use (inc handler stubs)

*   Check for gnome-config before disallowing gnome widgets

*   Do NOT generate Gtk about_Form if 'allow_gnome' is true, use Gnome::About.

*   Add user_option 'description' with description for any about box etc.

*   Finish implementing styles.

*   Store signals and connect after all objects are constructed. This is
    important when <object> property is specified in widgets eg. AccelLabels
    but also so that radio buttons don't trigger each other during construction.
    
*   Implement version-dependant source code generation so that new features
    or widgets available in CVS versions don't break the CPAN release.

*   Implement Gnome widget 'GtkAppBar',    (needs Gtk-Perl CVS after 19990914)
*   Implement Gnome widget 'GtkDock',      (needs Gtk-Perl CVS after 19990914)
*   Implement Gnome widget 'GtkDockItem',  (needs Gtk-Perl CVS after 19990914)
*   Implement Gnome widget 'GtkSpell',     (needs Gtk-Perl CVS after 19990914)
*   Implement Gnome widget 'GtkCalendar',  (needs Gtk-Perl CVS after 19990914)
*   Implement Gnome widget 'GnomeApp',     (needs Gtk-Perl CVS after 19990922)
*   Implement Gnome widget 'GnomeAppBar',  (needs Gtk-Perl CVS after 19990922)
*   Implement Gnome widget 'GnomeDialog',  (needs Gtk-Perl CVS after 19990922)
*   Implement Gnome widget 'GnomeDock',    (needs Gtk-Perl CVS after 19990922)
*   Implement Gnome widget 'GnomeDockItem',(needs Gtk-Perl CVS after 19990922)
*   Implement Gnome widget 'GnomeSpell',   (needs Gtk-Perl CVS after 19990922)

*   Write a &XmlUtf8Encode() sub for PerlXML->QuoteXMLChars()

*   Handle GNOME_STOCK_ITEM and GNOME_STOCK_ICON properties

*   Spearate out Gtk widget constructors (as Gnome widgets already are)

*   Write sub to lookup C defines for GNOME stuff. Either singly at run time
    or by generating a module at Makefile.PL build. This needs to be done
    dynamically in case gnome-libs change the defines. This would allow lookup
    of 'GNOME_STOCK_PIXMAP_SRCHRPL'   => "Search/Replace", for instance.
    
*   Sort out pixmap creation, Gtk-Perl has limitations here but is improving

*   Improve PerlRun->create_pixmap() to use new bindings, possibly do in same
    way that Glade C code in support.c does.
    
LONG TERM
---------
    Use XML::Parser()s streaming approach or SAX interface to build UI as it 
    is read. This might be quicker and would also allow 'net delivery
    of UIs. Write Glade::PerlGenerate->Form_from_(XML_)Stream.

BUGS
----
The biggest deficiencies are with menu/toolbar underline accelerators
particularly in Gnome::Apps.
