discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Consider GtkCore as UI


From: Richard Frith-Macdonald
Subject: Re: Consider GtkCore as UI
Date: Wed, 20 Dec 2023 14:31:54 +0000


> On 20 Dec 2023, at 07:44, Albert Palacios <optimisme@gmail.com> wrote:
> 
> Hi,
> 
> With the GitHub code, where the GSTheme.m file is 8 years old, I can't see 
> how to create a theme to my liking. Now I see that there have been 
> modifications three months ago to some files, I will have to look at the 
> differences to see in detail what it is about.

Please take a look at the documentation (or, since it is generated from mark in 
the heaqder files) GSTheme.h
Perhaps also look at Thematic.app,  since GSTheme and Thematic.app were 
developed together (so we would have an app to manage/build themes).  The app 
is far from complete (the hope being that theme developers woudl add missing 
functionality when they needed it), buteven so it  allows a lot of theme setup 
to be done using a GUI.
The documentation at the start of GSTheme.h describes how themes are meant to 
work overall,  a key feature being that themes can be dynamically switched in a 
running application (so in Thematic.app you can see the effects of changes made 
when editing a theme).

Simple themes use settings (user defaults) to control behaviors, color lists to 
control the colors of each GUI element, replacement bitmap images, and bitmap 
tiling ... stuff that can be built in the app using the GUI and no coding.
A substantial part of the theme code is dedicated to making those things simple 
to change, so in Thematic.app you can use the GUI to select settings, set 
colors for all the named interface elements etc, and even to specify tiles to 
be repeated to make up elements of the GUI without any need for coding.

More complex themes are implemented by having a subclass of GSTheme where you 
override some of the methods used to modify the behavior and to draw different 
control element.  There are a lot of those methods, grouped into categories by 
function.  However there's no guarantee that there will be a method to control 
everything you want.
There's also an ability to name individual objects so that your drawing code 
can treat particular objects differently from others (see 
-setName:forElement:temporary: and -nameForElement:).

The intended solution to that is that theme developers should reach out to the 
GNUstep developers and ask for a new theme method to be added to allow some 
specific behavior/drawing to be altered;  a new method would be added to 
GSTheme and the GUI class would be modified to call the new method from 
GSTheme.  The theme developer would then override this new method (in their 
GSTheme sbclass) to alter behavior/appearance when their theme is active.

But ... getting a new theming method in place (and waiting for a new release 
gof the GUI) is time consuming, so as an temporary solution the GSTheme code 
actually allows your GSTheme subclass to temporarily override methods in other 
classes in a way which still works with the theme switching mechanism (see the 
-overriddenMethod:for: method, which describes the naming convention for doing 
this).


> Also, in the documentation, I can't see anywhere how to properly make a 
> custom vector theme from scratch, and I haven't found any example either. 

I guess by 'vector theme' you mean one where you implement methods to do the 
drawing.  That's fundamentally a programming task (what I describe as 'More 
complex themes' above) rather than GUI based design.  As such you need to look 
at implementing/overriding the GSTheme methods in the various categories,  but 
to know which ones you want to change you also need to look at the GUI code to 
see which theme methods are used where.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]