TODO

√ META6.json
√ New dependency: https://github.com/timo/cairo-p6
√ Feature Request: GTK::TextBuffer.buffer to accept from Str or Buf when setting text
√ METHOD ALIASING! - This has mostly been accomplished, but in the case of container-based classes and others where manual aliasing was done, the best thing to do would be a proto method. See: https://gist.github.com/Xliff/34b9d2e3e27c76696ec60e6791075634
√ Convert Perl6 additions to GTK::Container into a role. (done as GTK::Roles::LatchedContainer)
√ Convert Perl6 additions to GTK::Box into a role. (GTK::Roles::Boxable)
√ Investivate the use of g_object_getv and g_object_setv to access previously non-accessible GObject properties. See https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-get
√ Fix lack of icons in GTK::IconView
√ Consider refactoring scripts/build-mro.pl6 to generate both widget and non-widget MRO lists.
√ Move GTK::Window title and size initialization to BUILD                   (implemented, but not tested)
√ A mechanism for emitting ALL defined handlers (methods in GTL::Roles::Signals::* )
√ COMPLETE a working GSList implementation
√ Implement GTK::Compat::ActionEntry (done as CStruct)
√ Implement GTK::ApplicationWindow
√ Implement
      √ GTK::Roles::RecentChooser,
      √ GTK::RecentChooserMenu,
      √ GTK::Dialog::RecentChooser,
      √ GTK::RecentChooserWidget!
√ Consider altering scripts/dependencies.pl6 to exit if a module name is listed
  as a dependency but has no node. If this does occur, report discrepancy
  and the module(s) where it appeared.
Ω Implementing GIOModule and its prereqs is currently OUT-OF-SCOPE!
Ω Determine if GTK::Roles::Pointers.p can return a generic Pointer[T] where
  T is the type of the original object:
    NOTE: This invocation WILL work:
      nativecast( Pointer.^parameterize(self.WHAT), self );
    NO LONGER RELEVANT -- This would only be useful for CStructs.
Ω If GTK::Roles::Properties is still a separate entity, refactor it to use
  self.GObject for all calls and eliminate the need for $!prop.
+ Find work-around for GObject's type checking system
+ Since build.sh is now running scripts/dependencies.pl6 find a way to make it do the full run only if necessary
+ Mechanism for providing PROPER event handlers for all events (in progress...)
+ Add-to-project-if-I'm-completely-insane: GVariant
+ GTK::ScrolledWindow.new_with_policy is in desperate need of being written (implemented, but not tested)
+ GTK::Container.set/get-child-properties using var args. Hint: *@slurpys!  (implemented, but not tested)
+ Add GTK::Compat::Action (GAction)
+ Add type specific signal handling to GTK::Notebook                        (implemented, but not tested)
+ Add a working GList implementation
  - Test latest inplementation of GTK::Compat::GList and GTK::Roles::ListData
+ Generate GTK::Bundle::Widgets and GTK::Bundle::NonWidgets comprised of need statements (build-mro.pl6 could do this)
+ Refine GTK::Compat::Window ( Now GDK::Window )
+ NEW INITIATIVE: Where returning a GList or GSList, offer a :$raw option to allow
  list of CPointer objects to be returned.
+ GDK
+ Refinements to all GTK::Compat::Objects
  + Finish refinements on GTK::Compat::Window
  + Rename all GDK objects from GTK::Compat::
  - build-mro.pl6 is now doing this (check to insure it is using ::Bundle !).
  - GTK.pm6 would then consist of all GTK::Bundle files
+ Is there any further need for GTK::Roles::Types.RESOLVE-* now that those
  routines have been moved to GTK::Raw::Utils. If the answer is NO, then it
  is an EXTREMELY LOW PRIORITY refactor. Don't rock the boat unless it's
  leaking.
+ Figure out the best way to place this:
    multi method Numeric { $!o.p }
  So that we can change the entire object chain in the most efficient way.
  ( Now done in GLib::Roles::Object! )
  -- The role is ready to be removed.
+ Add an implementation for GTK::Compat::Closure (GClosure)
  ( GLib::Object::Closure )
+ GTK::Roles::Data should be deprecated in favor of GTK::Roles::Properties,
  but...
+ Roll GTK::Roles::Properties into GLib::Roles::Object
+ Roll GTK::Roles::References into GLib::Roles::Object
+ Add registration system to GTK::Builder, since type names will mostly start with
  Gtk..., must have a way to convert those names to the proper object name.
  Propose <Project>::Builder::Registry, with static .register method that
  provides pair mapping detected_name => proper_name.
    - This is now being roled into GLib::Object as the TypeManifest system.
      all objects register their "implementor => object-name" pairs
      into THIS system, not GtkBuilder
    - GTK::Builder shall be modified to use THIS system!
    - Manifest generator shall be modified to handle Roles!
+ Complete implementation of GTK::Compat::Roles::GFile (now GIO::Roles::GFile!)
   - (Wrapper class is unnecessary as long as a method new is provided)
   - Role can have submethod BUILD, but will be overrided by any implementing
     class
   - Initialization should be done in private method that is called by BUILD and
     all implementing classes
   - Insure all implementing classes override for safety reasons.
+ PULL GTK::Roles::Types. Pull GTK::Raw::Utils, if only using resolve-* routines.
  ( Awaiting final verification of completeness before removing GTK::Roles::Types
    GTK::Roles::Utils may be rolled into GTK::Roles::Subs )
* Finish GTK::Utils::LockedHash -- Now no longer necessary with v6.e and the
  introduction of Dict.
- GTK::ListStore will need a comprehensive review.
- SERIOUS CONSIDERATION: Add multis for ALL (yes EVERY) method in p6-GTK and its descendant projects that allows
  a consumer to pass NATIVE parameters. This will ALMOST CERTAINLY entail an engineered solution (ie a script).
  Said script needs include a mechanism that will extract the unit prefix from its contents.
  -- hMethodMaker should be adjusted to emit such code so that new projects will not have this discrepancy.
- Consider: Any UINT parameter should have a "where * > 0" placed on it.
  LARGE initiative. Subject to review.
+ PERFORM REFINEMENT REVIEW ON GIO!
- VERSIONING ON GTK OBJECTS!
- For refactoring: the code in the "attributes" (not "properties") routines
  should have the getter and setter routines broken out into their own methods.
  The existing "attribute" methods should then call the corresponding methods.
  This will allow for better compatibility with all GLib based code.
  However, there are wide-reaching consequenses of its use that need to be
  tackled. For one: This should only be necessary for CStructs, but there are
  places in the code that use it for CStructs AND CPointers. If this change
  is made, then there are places in the code that will need to be refactored,
  since a Pointer should take a CPointer without modification.
- Insure all method-level gchar paramters are converted to Str()
- Separate all GTK::Compat::Pixbuf files into it's own project, that will
  become a dependency. GDK::Pixbuf is available.

- Write wrappers for the eventual GLib::Object object that will wrap the
  "GObject-invocant" methods from GLib::Signal
- Move signals to %Object.signal<name> to fix issue with method name conflicts.
  The easiest way to do this is when the final move to GLib::Object is made.
  The best way I can think about it is this:

    my $signal-data     = $!signals;
    my $signals-wrapper = $!signals-wrapper;
    my $lex-object      = self;
    method signal {
      $!signal-container //= class :: {
        also does Associative;

        method AT-KEY (\key) is rw {
          Proxy.new:
            FETCH => $, {
              $signals-wrapper{key} //= (class :: {
                  has Supply $!s   handles *.grep({ $_ ne 'tap' });

                  has        $!obj;
                  has Int    $!id;

                  submethod BUILD (:$!supply, :$!obj, :$!id) { }

                  method new ($supply, $obj, $id) {
                    self.bless( :$supply, :$obj, :$id );
                  }

                  method tap (|c) {
                    nextwith(c);

                    # ...
                  }

                  # cw: This is the last troublesome bastard, because how can
                  #     we offer this without having called the ::Roles::Signal
                  #     variant, first?
                  method connect (Callable &c) {
                    $!s.tap(&c);
                  }

                  method untap is also<disconnect> {
                    self.disconnect( $!id );
                  }

                  method block      {  }
                  method unblock    {  }
                  method disconnect {  }

                }
              }).new( |$signals-data{key} );
            },

            STORE => $, Callable \c {
              $signals-wrapper{key}.tap(c);
            }
        }

        method EXISTS-KEY (\k) {
          # cw: Will the semantics on this be:
          #  - Does the signal data exists (because, more than likely... it will!)
          #  ...or...
          #  - Has this signal been tapped?

          $signals-wrapper{key}:exists;
        }

      }


    }

  So now, any call to $obj.signal will return a instance-level persistent
  wrapper that will contain any defined signals. The advantage of this is
  now:
    1) ALL signals are now stored in a unified location. Individual hashes in
       ALL ::Roles::Signals objects can be removed
    2) A unified disconnect method can now be provided.

  NOTE: Please do not interpret the above code as design gospel, it was only
        intended as pseudo code.

- Add attribute 'control' to GTK::Stack to allow adding either GtkStackSwitcher
  or GtkStackSidebar
- Inhibit pass-through to Mu constructor in all widget-based objects!
- Add this to the top of all activate blocks in t/
    CATCH { default { .message.say; $app.exit } }
- Rewrite this document in Markdown format.
- Improve GTK::Widget.CreateObject to take best guess at pointer name for
  widget type, if it exists.
- GTK::Grid to provide sanitized version of it's tracking structure to user-code
- Properly rename GtkCssSection to GtkCSSSection
- Consider abstracting GTK::Roles::Protection into it's own project.
  Method::Protect, maybe?
- Properly rework GTK::Utils::MenuBuilder. It is faulty
  + Test case for all features of GTK::Utils::MenuBuilder
- For ALL type coercer methods, insure they are aliased to a proper
  object-specific nickname
- For all widgets: Replace all static strings in self.setType() with self.^name.
- Investigate all async *_finish routines to see if a multi with a simpler
  interface is possible.
+ Consider separating enums from GTK::Raw::Types into GTK::Raw::Enums
  - If that goes well, then do the same for GTK::Compat::Raw::Types
- Consider altering scripts/dirty_typing.pl6 to only go through files later the
  latest date amongst the stubs in in .dirty_typing
- Roles can now compose submethod DESTROY. So now pointer-level GC is possible, see:
  * perl6 -e '
    use NativeCall; \
    role B { submethod DESTROY { say "BOO!" } }; \
    class A is repr<CPointer> { also does B; }; \
    my $a = A.new; $a = 1; for ^10 { my @a = rand xx 100000; say +@a }'
- Consider...CLEANUP Init: Insure all custom bless methods use $o.^name as opposed
  to self.^name
- Reminder for when GHashTable is implemented: Write subclasses that properly
  use the right hash functions. Or maybe parameterized roles?
- FOR CONSIDERATION: Add a closed sub called "event-return" to abstract out the
  whole @a[* - 1].r thing.
- For all signals that use a 'detail', those handlers must be changed to add
  that to the signal name. This will prevent the need for specific handling through
  GTK::Compat::Signals. This particularly applies to 'notify'. This is another
  initiative.
+ Move relevant methods from GTK::Roles::Data to GTK::Compat::Roles::Data.
  The only GTK-Specific methods in that compunit are getType and setType and
  there's even argument that those aren't needed, either.
- WINDOWS SUPPORT!
- Check to see if GTK::Builder loading issue is related to the lexical nature of
  `require`.
- Add the ability for relevant GTK Objects to .ACCEPT a GObject. This will mean
  that Ancestries will be used. All .ACCEPT methods will use these hierarchies.
  This can EASILY just be done for GTK::Widget.
  - Use .wrap or too expensive?
  - Cost of just overloading.
  Other base objects across all GTK project will need to be evaluated.
- Should GTK::Widget.CreateObject accept an override type as an optional parameter?
- All objects should have a proper gist method. Using DDT is a work-around, but
  not a proper implementation. This is a LARGE body of work, so probably done
  under many commits. LOW-PRIORITY INITIATIVE!
- GTK::Compat::Value needs to make values a proper read/write container. For that
  to occur, we need a mechanism to extract submitted type values and use the
  correct method to use to place that value in the ::Value.
  - This item depends on the item above!
  - Int/Num/Str should be converted to:
    - if Str then Str
    - If Int then Int64, unless $short is specified then Int32
    - If Num then Num64, unless $short is specified then Num32
    - If GObject, then G_TYPE_OBJECT
+ Add as another scripts for t/, gtk/examples/sunny.c
+ Revisit the interface for GTK::Roles::Properties, there are potential conflicts
  that can be removed/resolved, and it's clunky. Think about looking into a
  set method design that hides the type complexity behind a single method. The
  get method may not be so easy to simplify.
  + Could this be the issue with vexpand, hexpand and its ilk? I'm using the
    wrong routine to set those properties??
+ Remove type coercion from "is rw" parameters. It is better to handle them
  in-method. This is an initiative that goes across ALL Gtk-based projects. New
  code is being written (starting with p6-GStreamer) that uses a better way of
  "is rw" prep and handling. Most notably, these will almost ALWAYS involve
  having a multi with the "is rw" parameters removed from the signature.
+ Perform a review on GTK::Widget. Any method that is capable of returning
  an object, should have code giving the user that option.
- Consider creating a run-script that uses the same logic as
  scripts/dependency-build, and stores those build lists as
  .dependency/<pathspec-of-script-from-tld>. If in a separate TLD from GtkPlus,
  .dependency will be created in the current dir.
- Adjust build.sh to set an environment variable, and creating items in .build,
  as scripts/test-new.pl6 does with .touch. Should accept a --clean flag to
  force from scratch. If forced counts are not the same as last recorded, then
  operation proceeds as if a --clean was issued.
  -- Consider porting to a perl5 script.
- Consideration for review: NativeCall subs that return a Pointer where a Buf
  or Blob would be more useful!
- Check on ALL instances of CArray[Pointer[<TYPE>]] calls to insure that
  when they are used, they .deref!!
- Potential mechanism for initializing all composed roles:
  - Firstly, should also provide a mechanism to disable, ala $!doRoleInit,
    which shall have a default value of True. Objects that need special
    handling can set to False.
  - Secondly, all GTK-based roles should implement a method
    "roleDefined-<name of role>" which returns if the role variable has been
    initialized.
  - Find a way to mark all initiator-based roles. roles are NOT hierarchical, so
    need to figure out the best way that is easily detectable via smartmatch
    or MOP.

  - Finally, at a low-level (potentially GObject) we do the following:
    if $!doRoleInit {
      for self.^roles {
        when GRole {
          self."roleInit-{ .^shortname }"()
            unless self."roleDefined-{ .^shortname }"()
        }
      }
    }

INITIAL specification for the format of %*ENV<P6_GTK_DEBUG>:
  - A parsing routine at the GLib/GTK level will handle interpreting the
    contents:
    * If the environment variable is set to the empty string, then all debugging
      is DISABLED.
    * If the environment variable is set to a comma separated list of
      "<module>:<value>", then:
    * <module> represents the name of the overall module. For example GtkPlus
      would be GTK, GtkClutter would be GTK::Clutter. Put simply, this expression
      in any object is more than likely to return <module>:
        `self.^name.split('::')[*-1].join('::')`
    * <value> is the debug level. If it is omitted, it is assumed to be 1. A
      <value> of - turns OFF debugging for a specific module.
    * If the environment variable is defined with just a number, that number
      would be the equivalent <value> for ALL modules.
    * If the environment variable does not match any of the above situations,
      it would be the equivalent as if all <modules> have a <value> of 1.

- Include a coercion method for GVariantType.
- Add a way to mark summary compile time results as inaccurate without having
  to remove them.
- Insure that all instances where we create an enum in a property, we are using
  $gv.enum, as opposed to $gv.int or $gv.uint
- Normal result graphing script is no longer working as of late April, 2019.
  It should be fixed.
- Add a script (or two) that:
  1) Prepares a legend file mapping perl version to LOCAL PROJECT commit date.
  2) Creates a horizontal graph of date (x) vs total compile time (y)
- Add *%others to ALL GOBJECT DESCENDANT new-based methods
- Add version tags to classes
- Currently all ::Roles::Signals::* compunits export PUBLIC methods that are used
  to create signal handlers. This SHOULD NOT be so. Make them all private!
- Future refactor or script: "$s.note($_);" => "$s.note($_); .backtrace.summary.say"
- Add trait "glib-property" to ALL PROPERTIES. This should not be as difficult as
  it sounds. Using scripts/get-properties, get a list of all property names.
  Then retrieve the line of the property definition from .^lookup($method-name).line.
  Write a script using this information to append "is glib-property".
- For GTK::TreeModel, make the need for a position in .get optinal IF AND ONLY
  IF the model contains only one column. Then $position = 0;

* PERL6 NOTES
	- It is faster to use 'if $a.defined' rather than 'with $a' if you DO NOT
    need to topicalize $a.
	- If trying to test for defined-ness of two or more variables, nesting with
    statements is faster than using a junction or 'andthen'
  - It is possible, but not recommended to use a role to implement the custom
    bless method, since that bless will be run for ALL ANCESTORS as well as
    the current class.

- SUBCLASSING
  - ALL GtkPlus derivative projects will need to distribute it's own separate
   ::Klass package to add subclassing ability. These will include the hacks
   required to set function pointers.

- SERIOUSLY CONSIDER breaking GTK::Builder and GTK::BuilderWidgets into its own project, as
  moving from XML::Actions to LibXML looks to be a winning thing to do!

- Consider Parameter::Also - is also trait for Parameters (have to hack $!named_names via nqp)
- For all routines returning an int64 representing DateTime, add a :$raw that allows the
  return of the int64 value and return a DateTime if $raw.not -- also consider a :$both
  that will return both values if specified.

- IMPORTANT NOTE FOR MEMORY MANAGEMENT - Currently, we have an identity constructor that takes a :$ref parameter.
  We should be tracking that value for proper object destruction. If we do not REF the object, we should not be
  UNREFing the object at DESTROY time!

Applications
============
√ A text editor in Perl6. Think about using it as a visual Regex tester
  (in progress, see p6-VisualGrammar.git)
√ A Perl6 port of http://gtklipsum.sourceforge.net/ (a better version of
  t/41-textview-scrolling.t)
+ Glade UI to p6-GtkPerl application (in progress see GTK::Builder:: objects
  and ui-to-code.pl6)
+ A Perl6 port of WNCK (https://developer.gnome.org/libwnck/)
+ A Perl6 port of Devil's Pie 2 (http://git.savannah.nongnu.org/cgit/devilspie2.git) that uses WNCK
+ A Perl6 port of Clutter (https://wiki.gnome.org/Projects/Clutter)
+ A Perl6 port of Slope (https://github.com/bytebrew/slope)
+ Using Azawawi's libzip bindings, extract XLSX files to memory (grab only
  *.xml, for now), parse the required files using XML::Actions, and then
  display resulting data in a GtkSheet -- This is now in a Jupyter Notebook.
x Perl6 GIMP Library bindings! (On hold until GIMP is ported to GTK3)
+ Port JSON-glib to Perl6
  https://gitlab.gnome.org/GNOME/json-glib/tree/master/json-glib
+ A Perl6 port for libsoup
+ Consider BABL bindings
- Consider Apache Arrow (needs template support!)
+ Consider gUPnP!
+ DEFINITELY consider GEGL bindings. Use generated data structures for
  operations, since they have no .h files, however the good bits are easily
  parsable from .c
  * Also - http://getfr.org/pub/dragonfly-release/usr-local-share/doc/gegl/api.html#The_GEGL_API
- Consider the potential for libav bindings
- Consider Apache C-API bindings, along with a potential module creation script from Raku sources.
- Consider Mutter bindings (https://developer.gnome.org/meta/stable/)
+ ATK bindings!
- Consider Togra bindings (http://togra.sourceforge.net/screenshots.html),
  however this may be more of a port from Python, rather than a set of bindings.
  + Aand.... it is. The C-lib, rather than being a generic resource, is there
    specifically to bind with Python. Might be easier to write something similar
    based on COGL.
- Consider a Perl6 port of SVOX (See files in libttspico-dev, start with /usr/include/picoapi.h)
+ Consider libchamplain - Maps + Clutter = MINE!
- Tensorflow? (https://github.com/tensorflow/tensorflow/tree/v2.4.0/tensorflow/c)
- The GTK CSS Inspector
- GVFS (both daemon and common)
+ LibSecret
- LibGWeather
+ LibGDA
- GCR/GCK (https://gitlab.gnome.org/GNOME/gcr) -- [Needed by Gnome Shell!]
- LibGVC
- LibGOM
- Gnome Keyring
- LibRest
- LibCanberra
+ Evolution Data Server (https://developer.gnome.org/eds/stable/EDataCal.html)
+ GOA (GNOME Online Accounts) (https://developer.gnome.org/goa/stable/index.html)
+ Handy
+ AT-SPI (In progress. Please complete)
- LibFolks
- Libnm
- libportal (XDP)
- LibUpower
+ Adwaita (GTK v4 port of Handy)
- GTK Layer Shell (v3 AND v4)
- Consider Festival (it's small) - (https://www.cstr.ed.ac.uk/projects/festival/manual/festival_28.html#SEC133)
- Consider Avahi. Be prepared to write another code-generator for another coding paradigm
- Consider EFL: https://www.enlightenment.org/develop/guides/c/start.md (might work best as method chains)
- Modernize GSSDP and GUPnP! Neither of the existing projects will work due to the switchover to SOUP3!


- A basic backup utility written using p6-GtkPlus and friends.

- DESIGN and port ASpell. YOU VILL DO ZIS!

- ARE YOU INSANE?! -- Consider UE5. Docs here: https://docs.unrealengine.com/5.0/en-US/API/Runtime/
  - Code generator will need to parse the docs.
  - Will need to do ALL of the structs. Then compile a C++ lib to get the mangled signature for each struct/type in iso.
    This is KEY, as it will open up C++ projects to NativeCall.o

- Don't consider. DO - https://gitlab.gnome.org/GNOME/template-glib/

- Consider Pulse Audio bindings -- /usr/include/pulse

+ GLibTop...although the documents SUCK!
- Is it possible that the Blender Python API could be modified for use by Raku?

- Extract all non-GLib functions into a project explicitly for the purpose of implementing the MethodMaker pattern. This shall include:
  - All non-GLib specific functions from GLib::Raw::Subs and all other ::Raw::Sub CompUnits from the entire suite
  - All non-GLib structures from GLib::Raw::Structs and all other ::Raw::Struct CompUnits from the entire suite
  - If there are any Glib-specific scripts in scripts, then they are to be made non-GLib specific via a yet-to-be-specified callback
    mechanism
  - If there are any GLib-specific scripts in project-scripts, then they are to be made non-GLib specific via a yet-to-be-speified callback

- Port Manette - Controllers for Raku!

- Add a journal to cairo_t in libcairo

- Consider a port of TBOX to Raku: https://opencollective.com/tbox
    mechanism

- For Containers, treat like positional and use .push(:$expand, :$fill, :$spacing, :$end) !