Package: dearpypixl
Dear PyPixlDear PyPixl is an object-oriented, lightweight, modular framework and toolkit forDear PyGuiwith minimal dependencies and zero use restrictions (MIT license).FeaturesRequirementsInstallationOverviewItem InterfacesCreating InterfacesMethods & PropertiesBehaviorsItem TypesGlobal State & SetupModulesLimitations, Bugs, & GachasInterfaces are Integers, For Better or WorsePassing Explicit UUID's and AliasesTypestubs and Dear PyGui VersionsFAQFeaturesAt its' core, Dear PyPixl provides object-oriented interfaces for Dear PyGui items. In addition, it ships with a wide arrangement of extensions and tools that remedy hurdles and inconveniences commonly encountered when using Dear PyGui.Extensible high-level and object-oriented API for creating and/or interfacing with Dear PyGui itemsLow-level API that fills a plethora of holes within Dear PyGui's APIStrongly typed"Use what you want" - code from Dear PyPixl and Dear PyGui can be used together with minimal conflictProvides functions for creating specific theme element items within thecolorandstylemodules - no more passing enum values toadd_theme_color/style!Typing for Dear PyGui'smvBuffer,mvVec4, andmvMat4objectsImproved docstrings and errorsContains numerous extensions and other helpful toolsRequirementsOperating System; Windows 8.1+, MacOS, Linux*Python: 3.10 x64 (or newer)pipdependencies:dearpygui1.9 (or newer)typing-extensions(Python < 3.12 only)*Dear PyPixl is available on all platforms already supported by Dear PyGui. Availability for 32-bit systems and Raspberry Pi OS islooselysupported, but requires building Dear PyGui from the source. Please visit theirwikifor more information.InstallationUsingpip;python3-mpipinstalldearpypixlAlternatively, build the wheel and install locally. Download/clone the source;git clone https://github.com/Atlamillias/DearPyPixlThen, from the project directory;python3 -m pip install buildpython3 -m build <path_to_dearpypixl_dir>python3 -m pip install <path_to_generated_whl>OverviewDear PyPixl is not undocumented. The information below supplements the detailed information available via docstrings. However, I highly suggest visiting Dear PyGui'sdocumentationif you are unfamiliar with the project. Basic usage of Dear PyPixl is very similar (identical) to that of Dear PyGui, and you may feel lost without some background.Item InterfacesCreating InterfacesAn item type is, functionally, a drop-in replacement for any Dear PyGui function that would create item an item;fromdearpypixlimport*window=Window(label="A window")button=Button(label="A button",callback=lambda:print("stuff is happening...!",parent=window)For container items, Dear PyGui offers two functions; a "normal" one, and a context manager. The class replacesboth;fromdearpypixlimport*withWindow(label="A window")aswindow:button=Button(label="A button",callback=lambda:print("stuff is happening...!"))While callingdearpygui.add_windowordearpygui.windowreturns atag, or a unique integer or string identifier, for the created window, the above results in anitem interfaceobject. Interfacesareitem identifiers - integers specifically - and can be used wherever an item tag is appropriate. For the lifetime of the interface, instance-bound methods will operate exclusively on the interfaced item. In the case above, the "interfaced item" was created along with the interface. However, there are ways to create interfaces for existing items, too;fromdearpypixlimport*importdearpygui.dearpyguiasdpgwithWindow()aswindow:button_id=dpg.add_button(tag="a button")# Method 1A: Call the interface class and include an existing `tag`button_if1=Button(tag=button_id)# -> `mvButton(tag=..., alias='a button', ...)`# Method 1B: Call the `.new` classmethodbutton_if2=Button.new(button_id)# -> `mvButton(tag=..., alias='a button', ...)`# Method 2: Use the `interface` functionbutton_if=interface(button_id)# -> `mvButton(tag=..., alias='a button', ...)`# Method 3: Use the `mvAll` interface classgeneric_if=mvAll(button_id)# -> `mvAll(tag=..., alias='a button', ...)`The first is pretty intuitive; include thetagkeyword argument when creating an interface. If thetagvalue is an existing item identifier, a new interface object will be created but won't (rather,can't) create a new item. This is useful when using primitive interfaces and when you are aware of the type of item you're interfacing with. However, this isn't without caveats. User-defined interfaces often implement a custom__init__method -- you likely won't appreciate another initialization. Additionally, an exception is raised (and suppressed) when the interface fails to create a new item with the in-usetag, so this approach isn't recommended if you're doing itthousandsof times within a short window. In either case, all interface types have a class-bound.newmethod. Accepting a sole positionaltagargument, the.newmethod creates and returns an interface of that type while skipping instance initialization.There may be times when you'll feel the need to query an item's type to find the correct interface. Theinterfacefunction accepts a sole positionaltagargument and a few other optional keywords. Its' default behavior is to query Dear PyGui for the item's type, find the appropriate class for that type, and return the result of calling the class'.newmethod. This procedure is faster than calling the class directly when the "item already exists" exception would be caught and discarded, even when you know the correct class beforehand.Lastly, when just want an interface and you don't know and/or don't care to know the item and interface type, or the interface is just a "stepping stone" to another one (like a parent or child), consider creating a generic item interface withmvAll. These interfaces have averybroad API, supporting items of any type to some degree. Their creation process is greatly simplified from that of other interfaces, so they're fast to make. The downside is their benefits -- they'regeneric. Some methods only work when interfacing with items of specific types. Additionally, their lack of type identity and simplified creation procedure means that they do not create items or generate identifiers. They also lack behaviors unique to more "narrow" interface types; as a convenience, however, they can be used as context managers when interfacing with container items.Note:No attempts are made to stop you from trying to bind an interface to an existing item of a different or unsupported type. Don't expect things to go well.Methods & PropertiesThe members available to interface can vary based on the type of item they support. However, all interfaces share a collection of core methods and properties. While member names are not 1-to-1, they are similar to that of the Dear PyGui hook used for each; the table below outlines many of them;Bound Interface MethodDear PyGui Functionitem.configure(...)configure_item(item, ...)item.configuration()get_item_configuration(item)item.information()get_item_info(item)item.state()get_item_state(item)item.delete(...)delete_item(item, ...)item.set_font(...)bind_item_font(item, ...)item.set_theme(...)bind_item_theme(item, ...)item.set_handlers(...)bind_item_handler_registry(item, ...)In addition, interfaces also define a few other methods for accessing item-related information;Bound Interface MethodDear PyGui Functionitem.children(...)get_item_info(item)['children']get_item_children(item, ...)item.get_font()get_item_info(item)['font']get_item_font(item)item.get_theme()get_item_info(item)['theme']get_item_theme(item)item.get_handlers()get_item_info(item)['handlers']get_item_handlers(item)The.configurationand.statemethods are not functionally equivelent to Dear PyGui'sget_item_configurationandget_item_statefunctions. The.configurationmethod of each dedicated interface type is unique and filters out options not applicable to the supported item type. This allows for the usage of thetype(item)(**item.configuration())idiom which, in most cases, creates a "reproduction" of the item and interface. The behavior of the.statemethod isn't as interesting; unlikeget_item_state, the dictionary returned by the.statemethod includes keys for every state an item could possibly have. When a state is not applicable for the supported item, the value of that key in the returned dictionary will beNone.For convenience, interfaces expose several item-related settings and states as instance properties. Available "configuration" properties vary per interface, but expect one for each of the supported item's writable settings. In contrast, "information" properties are consistent between all item interface types, but only the most commonly-used are exposed. While the related methods return the result as returned by Dear PyGui, the on-access behavior of each property will always return an item interface when applicable. However, "state" properties will always return the result as-is;Interface PropertyInterface Method Hookitem.parentitem.information()['parent']item.themeitem.get_theme()item.set_theme(...)item.fontitem.get_font()item.set_font(...)item.handlersitem.get_handlers()item.set_handlers(...)item.is_okitem.state()["ok"]item.is_hovereditem.state()["hovered"]item.is_activeitem.state()["active"]item.is_focuseditem.state()["focused"]item.is_clickeditem.state()["clicked"]item.is_left_clickeditem.state()["left_clicked"]item.is_right_clickeditem.state()["right_clicked"]item.is_middle_clickeditem.state()["middle_clicked"]item.is_visibleitem.state()["visible"]item.is_editeditem.state()["edited"]item.is_activateditem.state()["activated"]item.is_deactivateditem.state()["deactivated"]item.is_deactivated_after_edititem.state()["deactivated_after_edit"]item.is_resizeditem.state()["resized"]item.rect_minitem.state()["rect_min"]item.rect_maxitem.state()["rect_max"]item.rect_sizeitem.state()["rect_size"]item.content_region_availitem.state()["content_region_avail"]Every possible item state is available as an instance property regardless of the interface type...almost. Many items support explicit positioning via theposconfiguration option. However, queries regarding an item's position are made only by checking its' state, makingposa bit of an odd-ball. Because of this behavior, interfaces only have the.posproperty when the supported item type can be positioned. In this case, assigning a value to.posis equivelent toitem.configure(pos=value).BehaviorsSome interface types implement unique behavors or inherit them from a parenting proto-type(s). Previous examples demonstrate usinginterfaces as context managers-- a behavior unique tocontainer-typeandmvAllinterfaces;withWindow()aswindow:button=Button(tag=40000)withwindow:text=Text("Some text",tag=50000)You'll get yelled at when trying that kind of thing with a primitive button interface;withbutton:# -> `TypeError: 'mvButton' object does not support the context manager protocol`...All interfacessupport some kind ofindexing and slicingbehavior. By default, this operates on the item's child slots; specifically the result of.information()["children"](not the.childrenmethod). Although only useful for containers, even basic items like buttons have child slots;# This is equivelent to `window.children(1)`, returning the# contents of child slot 1.window[1]# -> [40000, 50000]# We can do this  with non-containers, too. Every slot will# be empty, though.button[1]# -> []# Slice to include several slots;window[0:]# -> [[], [40000, 50000], [], []]Meanwhile, theme element and "series"-type interfaces override the above behavior. Indexing, slicing, and rich comparisons operate on the item's value. In particular, they behave like lists of a fixed size;fromdearpypixlimport*fromdearpypixlimportcolor,stylewithTheme()astheme:withThemeComponent():# `dearpygui.add_theme_color(#     dearpygui.mvThemeCol_WindowBg,#     (200, 50, 50, 250),#     category=dearpygui.mvThemeCat_Core,# )`window_bg=color.WindowBg(200,50,50,250)# theme elements are semi-mutable lists (values can change, but not shape)window_bg==window_bg.get_value()==list(window_bg)==[*window_bg]==[200,50,50,250]# -> `True`# update the alpha channelwindow_bg[-1]=200window_bg.get_value()# -> `[200.0, 50.0, 50.0, 200.0]`# update color channelswindow_bg[:-1]=[50,200,50]window_bg.get_value()# -> `[50.0, 200.0, 50.0, 200.0]`Additionally, primitive interfaces can bepickled;importpicklefromdearpypixlimport*withWindow(label="a window")aswindow:Text("some text")withChildWindow(label="a child window"):InputText(default_value="more text")pickled=pickle.dumps(window)# If we were to load the pickled tree now, it would# only copy the interface state. The tree would not# be reproduced.window.delete()# Reload the pickled hierarchy. Since the item tree# no longer exists, this will recreate the interface# state and the item tree.window=pickled.loads(pickled)The pickling process is fairly comprehensive. It creates a save state of the target's alias, configuration (includingposandsource), bindings (theme, etc), children, and value. This procedure is repeated on the target's children recursively, ensuring that theentireitem tree from the target is included. Itemsources are uniquely handled so that they can be properly set even if the actual source item is created further down the hierarchy. The process also pickles interfaces found on user-defined interfaces (again, recursively). When an item hierarchy is about to be pickled, all items/interfaces found are ensured to have assignedaliasesat the time of serialization. If an item does not have an alias, one is generated automatically using its' current integer id and a universally-unique id created using theuuidmodule'suuid4function*.Below is a more complex, working example. Note that bothwindowandthemeare destroyed before reloading the pickled hierarchy. ThemvHandlerRegistryinterface object onwindow.events, however, is not. The loading process still creates amvHandlerRegistryinterface and sets it on the reconstructedwindow.eventsinterface, but the handler registry itself is not recreated since it exists already.importpicklefromdearpypixlimport*classUserWindow(Window):def__init__(self,**kwargs):super().__init__(**kwargs)# covered through interface associationself.events=HandlerRegistry()withTheme()astheme:withThemeComponent()astc:window_bg=color.WindowBg(200,50,50,250)withUserWindow(label="a window")aswindow:# covered through item association (binding)window.theme=theme# covered through item association (children)text=Text("some text")withChildWindow(label="a child window")aschild_window:input_text=InputText(default_value="more text")withPlot(label="and an empty plot"):...text.source=input_text# `source` will be properly reflectedwindow_pkl=pickle.dumps(window)window.delete()theme.delete()window=pickle.loads(window_pkl)Items/interfaces are pickled from the top-down and does not traverse upward. This is important because parent references of serialized items arenottracked. Instead, a loaded "parent" explicitly passes itself down to its' children during the loading process. This is a non-issue when pickling an entire item tree since root items don't require parents. Things are different when pickling itembranches; the top-level pickled item/interface needs a parent! Simply load the branch while a suitable parent is atop the container stack;withWindow(label="a window")aswindow:Text("some text")withChildWindow(label="a child window")aschild_window:InputText(default_value="more text")child_wndw_pkl=pickle.dumps(child_window)child_window.delete()# load the saved branch within a completely different parentwithWindow():withTable():TableColumn()withTableRow():child_window=pickle.loads(child_wndw_pkl)Avoid "reference tangles" when making pickle-able trees. An interface of a user-defined type should not keep a reference of a non-root item of a completely different branch. Similarly, don't set itemsources to items in other branches. The pickling procedure will assign aliases to such items, but will not attempt to pickle the item or reference. The below example results in aRuntimeErrorwhile trying to load reloadwindow2;withWindow()aswindow1:w1_text1=Text()w1_text2=Text(source=w_text1)withWindow()aswindow2:w2_text=Text(source=w1_text1)# "reference tangle"# create a snapshot while `w2_text` is still "outsourcing"window2_pkl=pickle.dumps(window1)window1.delete()window2.delete()pickle.loads(window2_pkl)# -> `RuntimeError()`A good solution for the above is using value registries, ensuring they are loaded first before anything else. Interfaces of user-defined types have an advantage here, as different interfaces can hold different (or same, doesn't matter) interfaces that operate on the same item (like a value registry). In that case, the value registry would always be loaded regardless of the load order of those that reference it.Picklingis anexperimental feature, and not all primitive interfaces are guaranteed to serialize at this time.Item TypesIn Dear PyPixl, each of Dear PyGui's item types are represented by a subclass ofAppItemType. Easily identifiable by their "mv" prefixes, class names mirror the name of the internal type it represents andnotnecessarily the name of the Dear PyGui function used to create items of that type (although, they usually go hand-in-hand). The adherence to a specific naming nomenclature means that some names can be a bit...verbose. As a convenience, classes are aliased (some more than once) to be less-so, or to make them easier to identify from other types;# most are straight-forward;ChildWindow==mvChildWindowDrawNode==mvDrawNode# some are obvious...Window==mvWindowAppItem# some aren't...HistogramSeries2D==mv2dHistogramSeriesPlotAnnotation==mvAnnotationThe classes themselves would be poor representations if you couldn't gleam some useful information from them. Casting an item class as anintorstryields a bit of information regarding the represented type;str(mvWindowAppItem)will always compare equal todearpygui.get_item_type(item)whenitemis a window item identifier, wheras casting to an integer returns the enumeration value of the internal type -- the latter compares equal to a similarly-named constant found in thedearpyguinamespace. Classes also have a.commandattribute; the (non-context manager) function that is typically called to create items of that type. In addition, several class-level properties regarding the item type's "category" and/or identity are exposed;importdearpypixlas*# ItemType       | String Repr                      | Int Repr       | Function# ------------------------------------------------------------------------------------mvButton# "mvAppItemType::mvButton"        | 2              | `add_button`mvText# "mvAppItemType::mvText"          | 28             | `add_text`mvInputText# "mvAppItemType::mvInputText"     | 1              | `add_input_text`mvWindowAppItem# "mvAppItemType::mvWindowAppItem" | 33             | `window`, `add_window`mvLabelSeries# "mvAppItemType::mvLabelSeries    |                | `add_text_point`...str(mvWindowAppItem)==dpg.get_item_type(dpg.add_window())# Trueint(mvWindowAppItem)==dpg.mvWindowAppItem# TruemvWindowAppItem.command==dpg.add_window# True# some class-level propertiesmvWindowAppItem.is_root_item# TruemvWindowAppItem.is_container# TruemvWindowAppItem.is_node_item# FalseGlobal State & SetupAll examples in previous sections omitted any of Dear PyGui's usual setup code, so here's one of the first few examples with all of the code needed to start the user interface;fromdearpypixlimport*withWindow(label="A window")aswindow:button=Button(label="A button",callback=lambda:print("stuff is happening...!"))Runtime.start()Dear PyPixl automatically executes any and all setup steps, freeing users of the obligation. Setup is typically broken out as users make API calls to Dear PyPixl without asking, but only on an as-needed basis. For example,create_contextis not called until Dear PyPixl makes its' first call to Dear PyGui, whilecreate_viewportis only called when an existing viewport is necessary for the procedure. Don't like the automated stuff? Users can perform any and/or all setup manually using Dear PyGui or Dear PyPixl; regardless, the framework keeps an accurate record of all of it, and will only run what's needed. Whether it be setup or configuration, Dear PyGui's global state can be managed using theApplication,Viewport, andRuntimeclasses.TheApplication,Viewport, andRuntimeclasses are not too far removed from Dear PyPixl's interface types. They each define the.configure,.configuration,.informationand.statemethods, and expose a full suite of properties to complement them. However, they are also the most unique objects in Dear PyPixl. In contrast to interfaces types whose instances operate on a specific item, the API forApplicationandViewportis entirelystatic.fromdearpypixlimport*importdearpygui.dearpyguiasdpg# manually perform app setup (optional)Application.create_context()# `dearpygui.create_context()`Application.prepare()# `dearpygui.setup_dearpygui()`Application.state()['ok']# | -> True (False if the above is not done yet)Application.is_ok# |# update application settings, just like item interfaces# NOTE: If we did not manually run setup, DPX would do it# at `Application.docking = True` below, since it requires# DPG initialization.Application.docking=TrueApplication.docking# -> TrueApplication.configure(docking=False)Application.docking# -> Falseapp_theme=Theme(label="Application Theme")# set the application themeApplication.theme=app_theme# unlike Dear PyGui's API, you can always fetch it later...Application.theme.label# -> "Application Theme"# REGARDLESS of how you set it...dpg.bind_theme(None)Application.theme# -> NoneApplication().theme=app_themeApplication.theme.label# -> "Application Theme"# the returned mapping mirrors `Item.information(...)`, so# it includes `font` and `theme`Application.information()# -> {'type': 'Application', ..., 'font': None, ...}# Even though the class and instances operate on the# same state(s), they are NOT the same objectApplicationisApplication()# -> FalseApplication==Application()# -> False# again, different objectsApplication()isApplication()# -> False# manually setup the viewport (again, optional)Viewport.state()['ok']# | -> False (True once created)Viewport.is_ok# |Viewport.create()Viewport.is_ok# -> TrueViewport.state()['visible']# | -> False (not shown yet)Viewport.is_visible# |# `Viewport.show()`, but using DPG's API because, again, DPX# knows. It knows, and it will always know.dpg.show_viewport()Viewport.is_visible# -> True# NOTE: If application setup has not been done up until now,# DPX will do so before creating the `window` interface/item.withWindow(label="A window",tag=50000)aswindow:button=Button(label="A button",callback=lambda:print("stuff is happening...!"))# second verse, same as the firstViewport.width=700dpg.configure_viewport("DPG NOT USED YET",# `Viewport.tag`label="IT ALWAYS KNOWS",)# Unique to DPX, 'primary_window', 'callback', and 'user_data'# are "configuration". All three of these cannot be fetched# using DPG's API, while 'callback', and 'user_data' cannot be# set separately. DPX sets things right.Viewport.configure(height=550,primary_window=window,callback=lambdasender,app_data,user_data:print(user_data),user_data="the cake is delicious",)Viewport.user_data="the cake is a lie"Viewport.configuration()# -> {#    'label'         : 'IT ALWAYS KNOWS',#    'width'         : 700,#    'height'        : 550,#    ...,#    'primary_window': 50000,#    'callback'      : <function <lambda> at ...>,#    'user_data      : 'the cake is a lie',# }# DPX will run any app or viewport setup we missed (we# didn't miss any) before starting the runtime.Runtime.start()Although static-bound,ApplicationandViewportcan still be instantiated. Doing so will execute any setup procedures required to fully utilize their API. Additionally, keyword arguments passed to the constructor are forwarded to the class'.configuremethod.Runtimecan also be instantiated, but does not share the mentioned behavior upon instantiation.ApplicationandViewportinteract solely with the already-existing global state provided by Dear PyGui. Unique to Dear PyPixl, theRuntimeclass manages the "runtime" state. It represents the status of the main event loop, and allows users to interact with aspects of the loop (framerate clamping, task queuing, etc.) without needing to implement it themselves. UnlikeApplicationandViewportwhose API is completely unbound,Runtimeis partially class-bound, allowing users a level of control through overrides.The.startmethod is used to start the main event loop in Dear PyPixl. It implements a general-purpose event loop using a synchronized fixed time step to decouple task execution from rendering. Tasks can be pushed to the event loop by adding them to.queue(an instance ofqueue.Queue), and are de-queued upon execution. When necessary, tasks can re-queue themselves, making them reoccuring tasks. Task execution is limited to a number of real-time milliseconds, set on the.update_intervalproperty.fromdearpypixlimport*defprinter():print('the cake is a lie')# this is ran onceRuntime.queue.put(printer)withWindow()aswindow:...defprint_window_state():print(window.state())Runtime.queue.put(print_window_state)# this is re-occuringRuntime.queue.put(print_window_state)# Since task execution is fairly isolated, the# re-occuring task will not block rendering frames.# A LONG running task may result in dropped frames,# though.Runtime.start()Frame rate can be managed by setting values on.target_frame_rateand.clamp_frame_rate. Whenclamp_frame_rateis True, the number of frames rendered per second is limited to the value oftarget_frame_rate, as long as it isn't zero orNone. These values can be updated at any time, even after the event loop has started.fromdearpypixlimport*defprint_frame_rate():print(Runtime.frame_rate())Runtime.queue.put(print_frame_rate)Runtime.queue.put(print_frame_rate)# limit to 30 fpsRuntime.target_frame_rate=30Runtime.clamp_frame_rate=TrueRuntime.start()Additionally, the.startmethod features a "debug mode". In this mode, Dear PyGui's callback queue is automatically processed without any additional input from the user. This is set to run when the application-levelmanual_callback_managementisTrue, or when the.startmethod is called withdebug_aware=Truewhen using a debugger.ModulesOnly interface types are exposed directly within thedearpypixlnamespace. Other useful tools and extensions are housed within their respective modules;api: Contains the lower-level API used by the framework.typing: Exposes type aliases and protocols used by the library. In addition to theAppItemTypebase class, primitive interface bases, abstract bases, and typed implementations of Dear PyGui'smvBuffer,mvVec4, andmvMat4objects.constants: Stores static Dear PyGui and Dear PyPixl values/variables as enumerations.events: Extensions of callback-related interface types and related utilities.theming: Extensions of theme and font-related interface types.color,style: Contains helper functions for creating specific theme color and style elements.console: Homebrew stream and console-related item interfaces.grid: Contains theGriditem layout manager, which leverages the ability to explicitly position items to emulate a table-like layout without creating any items.Limitations, Bugs, & GachasDear PyPixl tries to maintain the same semantics and feel that Dear PyGui has so that it's intuitive coming from Dear PyGui, while being different in ways that only benefit the user. However, there are some situations and use-cases where Dear PyGui and Dear PyPixl and aren't exactly 1-to-1 due to implementation details of the framework, bugs within Dear PyGui, etc. Below explains some of Dear PyPixl's behavior and some consequences that stem as a result.Interfaces are Integers, For Better or WorseInterface types are derived from Python's built-ininttype. This allows interfaces to be used as arguments where item identifiers are expected. In addition, it simplifies the public and internal API's alike in regards to interface and item creation. This unfortunately has a few side effects;interface subclassescannot declare non-empty__slots__interfaces cannot include a__weakref__attribute, meaning theycannot have proxies__bool__cannot be implementedThe last limitation has less to do withintand more to do with how Dear PyGui is inspecting identifier values.__bool__must operate on the integer value of the interface; hard-to-diagnose bugswilloccur otherwise. For this reason, Dear PyPixl will throw aTypeErrorwhen defining an interface class that does not point toint.__bool__.Passing Explicit UUID's and AliasesItem-creating functions in Dear PyGui all accept atagkeyword argument in the form of an item's integer identifier (uuid) or stringalias. While Dear PyPixl does its' best to accomodate,the basic interface constructor cannot properly manage aliases when the alias is new. This is in part due to Dear PyPixl's internal design, along with the fact that Dear PyGui's item registry API was never finished. Since the interface's creation logic (.__new__) is isolated from the item creation logic (.__init__), Dear PyPixl would need to register the new alias to a new uuid in advance. This can be done, however, Dear PyGui does not behave as expected in any scenario.As a workaround, interfaces have the.aliasedclass method, an alternative constructor, which will set the alias onto the item once it is created. Note that this is only necessary when creating the interface would also cause the interfaced item to be created, while aliases of existing items can be passed as normal.As is recommended when using Dear PyGui, users shouldnotgenerate their own integer identifiers for Dear PyPixl interfaces.Typestubs and Dear PyGui VersionsMost of the objects found in Dear PyPixl are dynamically generated on-import to support the installed Dear PyGui version. In contrast, newer versions of Dear PyPixl will always ship with stubs generated against the most recent (and compatible) version of Dear PyGui available on PyPi at the time of development; unlike code, type stub files cannot be reliably written at runtime. This means that the typing information may not reflect the version of Dear PyGui installed.There are two options to remedy this. The first is to simply use the most up-to-date versions of Dear PyPixl and Dear PyGui. Dear PyGui has been put into "maintenance mode" as of version 1.9 - breaking changes are not expected for newer versions. Dear PyPixl will automatically install the newest version of Dear PyGui available on PyPi, provided a compatible version isn't already installed. Alternatively, a new set of stub files can be generated within Dear PyPixl's installation directory by running the library as a top-level script viapython -m dearpypixl, provided that the user or client has the proper permissions to do so.FAQQ:Are there performance implications from Dear PyPixl?A: The framework keeps a very low profile where possible, optimizing high-traffic areas of the API to keep overhead to a minimum. For example, creating one million window items viamvWindowAppItem()on a low-end machine took ~15.7 seconds (worst-case); only ~1.2 seconds of which contributed to executing Dear PyPixl's code.Q:Can I use both Dear PyPixl and Dear PyGui code in my project?A:Yes.Q:I need to conform to an older version (<1.9) of Dear PyGui- will Dear PyPixl still work?A: Dear PyPixl is designed to work with most with most Dear PyGui versions. In fact, key components of the core framework were implemented using Dear PyGui v1.8. However, using some of Dear PyPixl's extension modules may throw errors when using older versions of Dear PyGui (in the future, these areas may issue a warning when using such versions). Regardless, you are welcome to try.