[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.
- Re: Consider GtkCore as UI, (continued)
- Re: Consider GtkCore as UI, bruce, 2023/12/17
- Re: Consider GtkCore as UI, Riccardo Mottola, 2023/12/19
- Re: Consider GtkCore as UI, Hugo Melder, 2023/12/19
- Re: Consider GtkCore as UI, bruce, 2023/12/19
- Re: Consider GtkCore as UI, Albert Palacios, 2023/12/19
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/19
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/19
- Re: Consider GtkCore as UI, Kyle Cardoza, 2023/12/19
- Re: Consider GtkCore as UI, Albert Palacios, 2023/12/20
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/20
- Re: Consider GtkCore as UI,
Richard Frith-Macdonald <=
- Re: Consider GtkCore as UI, Riccardo Mottola, 2023/12/20
- Re: Consider GtkCore as UI, Riccardo Mottola, 2023/12/21
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/19
- Re: Consider GtkCore as UI, bruce, 2023/12/20
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/20
- Re: Consider GtkCore as UI, bruce, 2023/12/20
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/20
- Re: Consider GtkCore as UI, bruce, 2023/12/20
- Re: Consider GtkCore as UI, Gregory Casamento, 2023/12/20
- Re: Consider GtkCore as UI, Riccardo Mottola, 2023/12/21