john
/
McRogueFace
1
0
Fork 0
Code Issues 52 Pull Requests Projects 1 Releases Wiki Activity

Break up UI.h into respective class files #43

New Issue
Closed
opened 2024-03-09 19:41:50 +00:00 by john · 5 comments
john commented 2024-03-09 19:41:50 +00:00
Owner
Copy Link

Notes say:
60 refactor: break up UI.h into the various objects

  • UIDrawable
  • UIGrid - could probably excuse GridPoint living here (?)
  • UIEntity - could probably excuse GridPointState living here (?)
  • UIFrame, UICaption, UISprite files

UI<thingy>.h should include all the python interface method definitions, C++ class definitions, and PyTypeObject.
UI.h will import all of these. This is in turn imported by the rest of the McRogueFace project
The static Type Objects that the module needs to import can be defined in the separate UI files, but inside the mcrfpydef namespace.
UICommon.h and UICommon.cpp can define the shared data type handlers created for #11, #13, #18

Notes say: 60 refactor: break up UI.h into the various objects * UIDrawable * UIGrid - could probably excuse GridPoint living here (?) * UIEntity - could probably excuse GridPointState living here (?) * UIFrame, UICaption, UISprite files `UI<thingy>.h` should include all the python interface method definitions, C++ class definitions, and PyTypeObject. `UI.h` will import all of these. This is in turn imported by the rest of the McRogueFace project The static Type Objects that the module needs to import can be defined in the separate UI files, but inside the `mcrfpydef` namespace. `UICommon.h` and `UICommon.cpp` can define the shared data type handlers created for #11, #13, #18
john added the
Major Feature
Refactoring & Cleanup
 labels 2024-03-09 19:41:50 +00:00
john added this to the All Datatypes Behaving milestone 2024-03-13 13:02:15 +00:00
john added this to the The Datatype Overhaul project 2024-03-13 13:06:39 +00:00
john added spent time 2024-04-09 15:05:39 +00:00
2 hours
john commented 2024-04-10 02:49:31 +00:00
Author
Owner
Copy Link

image

LOTS of new files. Disentangling these things is not hard, but there's a lot to do.

After it actually compiles again, which should be tomorrow, I'll make ANOTHER pass and make each file more idiomatic. The main task there will be renaming methods and using classes as namespaces for the pile of static methods. That should get each header file to be a lot shorter.

As a THIRD pass to fix up these files, the imports are excessive. I should remake the chart above with references to the SFML wrapper classes (Vector, Color, Texture, Font) and streamline the files to actual dependencies.

Compilation time should go down quite a bit when connections between the files are minimized and 80% of the UI classes aren't modified in any given revision.

![image](/attachments/fb812405-2e75-42aa-a9a9-978882376c01) LOTS of new files. Disentangling these things is not hard, but there's a lot to do. After it actually compiles again, which should be tomorrow, I'll make ANOTHER pass and make each file more idiomatic. The main task there will be renaming methods and using classes as namespaces for the pile of static methods. That should get each header file to be a lot shorter. As a THIRD pass to fix up these files, the imports are excessive. I should remake the chart above with references to the SFML wrapper classes (Vector, Color, Texture, Font) and streamline the files to actual dependencies. Compilation time should go down quite a bit when connections between the files are minimized and 80% of the UI classes aren't modified in any given revision.
image.png
40 KiB
john added spent time 2024-04-10 02:49:47 +00:00
1 hour 40 minutes
john added spent time 2024-04-11 03:10:38 +00:00
2 hours
john commented 2024-04-11 03:13:04 +00:00
Author
Owner
Copy Link

see c186d8c7f3

I have approximately 4 things I want to do to all of these new objects:

  1. Move implementations to .cpp file; rename as UIWidget::init, etc.
  2. use mcrfpy internally (like Texture) to find classes; no refs to mcrfpydef:: type objects
  3. eliminate unnecessary includes - these are tangling up the compilation process.
  4. Fix init functions - send args to constructors of SFML wrapper types

Here is a progress diagram of completing those actions:
image

I'll pick up when I have some free time again by continuing with UICaption's cleanup.

edit: regarding item 2 here. I don't think it would take a ton of time to implement. But is it necessary?
On the Python Discuss thread about my issues with building objects while the interpreter is still starting up, I said:

The module object and type objects I provided to initialize the module do not seem to be the same objects in use at the REPL. Maybe PyType_Ready copies the PyTypeObject struct somewhere else to apply defaults / inheritance?

I don't actually believe that, and I'm considering trying out the use of type objects in PyTexture again. All of the UI objects are compiling without the workarounds, so I suspect that I have some unnecessary steps in my process because I didn't reverse all of my experiments when figuring out what was wrong with Python object creation.

see c186d8c7f301f216f46ea52c92d60d15615c45ff I have approximately 4 things I want to do to all of these new objects: 1) Move implementations to .cpp file; rename as `UIWidget::init`, etc. 2) use mcrfpy internally (like Texture) to find classes; no refs to `mcrfpydef::` type objects 3) eliminate unnecessary includes - these are tangling up the compilation process. 4) Fix init functions - send args to constructors of SFML wrapper types Here is a progress diagram of completing those actions: ![image](/attachments/39f6e53d-784a-4bc9-a01a-fc874314120b) I'll pick up when I have some free time again by continuing with UICaption's cleanup. *edit:* regarding item 2 here. I don't think it would take a ton of time to implement. But is it necessary? On the [Python Discuss thread](https://discuss.python.org/t/instantiating-python-objects-from-c-segfault-on-type-obj-class-attribute-missing/50432/4) about my issues with building objects while the interpreter is still starting up, I said: > The module object and type objects I provided to initialize the module do not seem to be the same objects in use at the REPL. Maybe PyType_Ready copies the PyTypeObject struct somewhere else to apply defaults / inheritance? I don't actually believe that, and I'm considering trying out the use of type objects in PyTexture again. All of the UI objects are compiling without the workarounds, so I suspect that I have some unnecessary steps in my process because I didn't reverse all of my experiments when figuring out what was wrong with Python object creation.
image.png
26 KiB
john commented 2024-04-11 03:21:10 +00:00
Author
Owner
Copy Link

while fixing __iter__ for this issue, I may end up accomplishing the work for #56 as well.

Chart of properties to implement:

image

These should all work at init time, and they should all accept either a mcrfpy object of the correct type, or a tuple that satisfies that object's constructor.

while fixing `__iter__` for this issue, I may end up accomplishing the work for #56 as well. Chart of properties to implement: ![image](/attachments/26ef908c-e355-4be5-b001-58b11393ed4e) These should all work at init time, and they should all accept either a mcrfpy object of the correct type, or a tuple that satisfies that object's constructor.
image.png
65 KiB
john commented 2024-04-13 04:19:30 +00:00
Author
Owner
Copy Link

image

I'm getting some segfaults from using the TypeObjects directly, so I guess I'll proceed with that fix.

![image](/attachments/bd61f4c8-2f51-4ba7-b422-31e52620ad4f) I'm getting some segfaults from using the TypeObjects directly, so I guess I'll proceed with that fix.
image.png
29 KiB
john added reference break_up_ui_h 2024-04-20 00:22:00 +00:00
john commented 2024-04-20 01:45:56 +00:00
Author
Owner
Copy Link

image

Ready to merge (?)

cos_play has segfaults, which I may want to fix before wrapping this issue... I am rushing to meet the April 21st deadline, now.

![image](/attachments/abc1e70b-8431-40be-ac00-9568f588f605) Ready to merge (?) `cos_play` has segfaults, which I may want to fix before wrapping this issue... I am rushing to meet the April 21st deadline, now.
image.png
42 KiB
john added spent time 2024-04-20 01:46:19 +00:00
3 hours 15 minutes
john closed this issue 2024-04-20 14:34:10 +00:00
Sign in to join this conversation.
break_up_ui_h
Branches Tags
Clear current reference
master
grid_entity_integration
reprs_and_member_names
break_up_ui_h
standardize_font_handling
standardize_vector_handling
standardize_color_handling
standardize_texture_handling
raii_pyobjects
rebase-for-7DRL_Feb-2024
engjam_uicollection
engjam_ui_overhaul
Clear current reference
Labels
Clear labels   
Alpha Release Requirement

This issue is a blocker to 0.1 Alpha release of McRogueFace.

  
Bugfix

   
Demo Target

Functionality to demonstrate; Depends on new features, but this issue isn't for writing them.

  
Documentation

   
Major Feature

Significant time and effort required.

  
Minor Feature

Some effort required to create or overhaul functionality.

  
Refactoring & Cleanup

no new functionality, just improving the codebase.

  
Tiny Feature

quick and easy - a few lines or with little interconnection around the codebase

No Label
Alpha Release Requirement
Bugfix
Demo Target
Documentation
Major Feature
Minor Feature
Refactoring & Cleanup
Tiny Feature
Milestone
Clear milestone
No items
No Milestone
All Datatypes Behaving
Projects
Clear projects
No project
The Datatype Overhaul
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Total Time Spent: 8 hours 55 minutes
john
8 hours 55 minutes
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: john/McRogueFace#43
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?