So I've been developing a UI toolkit for the past year, and my Window class has gotten to a point where the size of the class (through sizeof) is 540 bytes).
I was thinking, that since not all windows have children, I might split parts of the code that handles having children (its alignment etc) into a separate class and have a pointer to it. Same goes with texts, icons, and scrolling etc.
Is this recommended practice or is there anything I'm blatantly missing?
I wouldn't worry about the raw size of the class. However, I would consider using the PIMPL idiom or a D-pointer.
Object-oriented design of classes should be based on the abstraction of the problem at hand, not the size in bytes of the compiled code. I'd break up a class if it was doing too much.
540 bytes? Do you really mean kbytes here? That doesn't seem excessively large to me.
Class instance size isn't a reliable metric of code complexity. An overly complex class that does everything could easily be the same size as a well-designed class that is composed of several smaller objects with clear responsibilities.
A class that uses composition can instantiate the composed objects as member variables (resulting in a larger instance size), or it can contain pointers to separate objects allocated using the new operator. The latter approach has benefits, such as physical decoupling, polymorphism, and not paying for features you don't use, but it also has downsides, such as increased memory fragmentation, increased memory allocator overhead, and reduced spatial locality.
I may be misunderstanding your problem, but you may want to look into policy-based design and/or component-based design, both of which are concerned with making larger classes out of smaller pieces of functionality.
From what you said about splitting some functionality off and having a pointer to it, it sounds like component-based design is the direction you were thinking of.
First, the size of an object instance in itself doesn't really matter. The class should be designed to have a single responsibility, and if that requires 540 bytes of data, then so be it.
However, 540 bytes is a unusually big number. It's 135 integers or pointers. It's something like 22 std::vectors. I have a hard time imagining that so many objects can be required for a single area of responsibility. But again, the size itself isn't the problem. The problem is if your class is responsible for more than it should.
I was thinking, that since not all windows have children, I might split parts of the code that handles having children (its alignment etc) into a separate class and have a pointer to it. Same goes with texts, icons, and scrolling etc.
It sounds like you've basically got a single EverythingUI class. And yes, that is bad design. Split it up for that reason. Handling of text has nothing to do with handing of icons or scrolling or... Put them in different classes.