First check that the platform being run on even permits this first
Some customizations are not supported on some platforms
Make a button & its text really large or really tiny on macOS might get you some surprising results
Click on the item in a layout and in the inspector click the “gear looking icon” at the top
Its on the second page of inspector properties usually
[quote]How would you provide a consistent font across the entire app if you did not want to use the “system” font?
[/quote]
I’d adhere to the system UI guidelines which is why System is usually the right choice
[quote=491663:@Norman Palardy]Clikc on the item in a layout and in the inspector click the “gear looking icon” at the top
Its on the second page of inspector properties usually[/quote]
Thanks. I stand corrected. Newbie error.
I had not clicked on the Gear icon/button, and had not seen that in any of the video tutorials I’ve seen.
I expected font face to be on the same tab with font color and other font properties.
Well, I don’t want to get into a UI design debate here, but I for one do not think that Apple is always right in their UI choices.
I reserve the right as developer/designer to choose the UI that’s best for my client.
IAC I have seen many macOS apps that use a variety of fonts and sizes for various parts of the app. So perhaps we can save the UI debate for another topic.
Thanks to all of you for your feedback on subclassing Xojo base classes. I clearly need to do some further research and testing. Perhaps the classical OOD I was taught, and used to use, does not fully apply to Xojo. I know there are several Xojo articles and videos on using OOD with Xojo, but if anyone has any specific suggestions for learning Xojo OOD, I’d welcome it.
[quote=491666:@Jim Underwood]Thanks. I stand corrected. Newbie error.
I had not clicked on the Gear icon/button, and had not seen that in any of the video tutorials I’ve seen.
I expected font face to be on the same tab with font color and other font properties.
[/quote]
They are there because quite honestly they arent altered a lot
Again that is because some settings on some OS’es wont work as well as you might hope
[quote=491666:@Jim Underwood]Well, I don’t want to get into a UI design debate here, but I for one do not think that Apple is always right in their UI choices.
I reserve the right as developer/designer to choose the UI that’s best for my client.
[/quote]
You will find that Apple may force you to
Just to be absolutely clear this not best practice, not in Smalltalk, C++, Java, C# nor XOJO - the languages Ive worked in for the last 30 years. In fact I cannot even remember anyone advocating such an idea! You subclass framework classes only to the extent that you need to do so to implement your application, no more.
There is a case for creating an interface between your application and third party libraries, where there is a genuine possibility that it may have to be changed as opposed to a theoretical one. Be aware that too many layers of indirection often leads to brittle software.
Perhaps subclassing ALL base classes is overkill. I was thinking of the base classes for Controls, where is it likely that you may want a specific behavior across all of your apps, and/or across all Controls for a specific app.
I guess we went to different schools, and hung out in different communities. I have not worked in as many languages as you have, but when I was active in Visual FoxPro and Visual Studio.net development subclassing the base classes (at least for Controls) was highly recommended. In fact, it was very popular to either develop your own framework (subclassing the base classes) or buy a 3rd party framework where the work was already done for you.
While there is a danger of over subclassing, there should be no problems with subclassing to several levels in a OOL that is well-designed and well-implemented. To be clear, I would anticipate subclassing to only one level in most cases with Xojo.
I guess the main point of this approach is to provide one place to consistently customize the look and feel, and behavior, of your app. If you just instantiate directly from base classes (initially thinking that is all you need), then you would have go into every instance everywhere in the app to make consistent changes.
So those of you that are opposed to subclassing in general, do you start development of every app with a clean sheet of paper, mostly using base classes with a few exceptions as they come up?
you cant insert a class into the class hierarchy between control and rectcontrol or between rectcontrol and more derived classes like button, checkbox etc etc etc
so your only option would be to subclass every specific control class and insert whatever common code inthere that you expect to use to set font, etc etc
[quote=491685:@Norman Palardy]so your only option would be to subclass every specific control class and insert whatever common code inthere that you expect to use to set font, etc etc
that alone may subvert your intentions[/quote]
Subclassing specific controls is exactly what I was thinking of. Why would that “subvert your intentions”
from your post it seemed to me you intended to try & insert some class between existing classes
and that you cannot do
that would subvert your intentions to create control classes that are easily themeable
If it is just font & size you can override the default in the layout panel of options. This will then apply the new default to any new controls added to your project. Unfortunately it is a system wide option so all projects will be affected.
[quote=491683:@Jim Underwood]Perhaps subclassing ALL base classes is overkill. I was thinking of the base classes for Controls, where is it likely that you may want a specific behavior across all of your apps, and/or across all Controls for a specific app.
[/quote]
But you are not trying to get a new behavior, you are subclassing controls in order to change properties of the controls, so another layer of indirection that just creates clutter and adds to the maintenance task.
Create a helper class or module with functions that take as a parameter a common base class of the controls you wish to change. You will achieve the same outcome with a lot less effort and it will be a lot easier to maintain.
The primary application I support does something similar. The defaults for font name and size by control type are stored in the preferences, and the open event for a window will call a support function that loops all the controls and makes the appropriate changes using “IsA” to identify the type of control. There are even a couple of conditionals based on the control name, for example, it distinguishes between a normal TextField and one where we want a TextField to have a fixed-width font by looking at the control name prefix (edt_ for normal, edf_ for fixed).
It’s not a design I’d repeat, and I’ve been lobbying the team to eliminate it and adhere to UI standards for the platforms. It’s one way of avoiding subclassing everything. We subclass several controls to get specific behaviors beyond a simple visual change.
Well, it’s pretty clear that most, if not all, of you guys go out of your way to avoid subclassing. And that’s fine – there is always more than one way to achieve an objective. It is just strange to me that there is such aversion to subclassing in an OOL.
IAC, apparently at least one other Xojo user, Bob Gordon, see’s the value in subclassing. In his case, he is subclassing most, if not all, of the controls. See: https://youtu.be/G3vY6rg-dug?t=1302
I think what we’re trying to convey is that the environment is very different from those tools. Subclassing just isn’t as necessary in Xojo, at least not for the same reasons. Subclassing is a very powerful tool, but your initial posts about subclassing everything is off base. This isn’t visual studio.
[quote=491811:@Jim Underwood]Well, it’s pretty clear that most, if not all, of you guys go out of your way to avoid subclassing. And that’s fine – there is always more than one way to achieve an objective. It is just strange to me that there is such aversion to subclassing in an OOL.
[/quote]
Subclass when you need additional reusable functionality for sure (and I certainly do that!), but subclassing for any other reason seems a bit pointless!
BTW Because in Xojo windows are a weird hybrid of a Module and class, subclassing them to do what I suggested, while easily doable, is not necessarilly intuitive… So If if you have issues trying to implement my suggestion of subclassing them to add the functionality you want to set font and font size just ask. That would mean you only have 1 custom subclass to create and maintain.
BTW changing font and/or size might mean you may need to change control size to accommodate… and that can certainly complicate things!
[quote=491811:@Jim Underwood]Well, it’s pretty clear that most, if not all, of you guys go out of your way to avoid subclassing. And that’s fine – there is always more than one way to achieve an objective. It is just strange to me that there is such aversion to subclassing in an OOL.
[/quote]
You really have not been listening to anything we have been saying…
I guess maybe that is the underlying issue in our discussion here. I am, of course, just learning Xojo, but my reasons for subclassing Xojo are the same as for subclassing in any app development tool. If you just instantiate directly from base classes (initially thinking that is all you need), and then later discover that you need to change the behavior and/or properties of any control, then you have to write the code that searches for and changes that in all cases, or then create a subclass and change it everywhere in your app, maybe in multiple apps. Whereas, if you have instantiated your subclass and need to make a change, then you just go to one place: The subclass definition.
I don’t see how that would vary among Xojo, Visual Basic, Visual Studio.net (with any language), etc.
I also don’t see the issue of subclassing all controls to just one level, and then using the subclasses instead of the base classes.
I will be shocked if one level of subclassing causes some problem with Xojo.
Has anyone actually done that, and found it to be a problem? If so, then I’d love to see the details of the problem it created.
I guess I need to direct my question to the Xojo Dev Team to see if they think there is any issue in doing so.
@Karen Atkocius points out a issue with just making a font face and/or size change: Doing so may case also require changing the control size. So that might mean adding/changing a method to the subclass to properly handle the resize.
