I have lately made some use of svg in gtkdialog. It really gives some new possibilities when it comes look'n feel. My initial studie was to upgrade pmount. Now I have done more vector-graphics for the next Pmusic. It really start looking like something else than windows95...
Ok, so I wanted to fullfill this, and started the work on a unique gtk-theme. - Not only for the bloat, but because Pmusic (with gtkdialog) takes advantage of a clearer gui. ie.

The <table> headers are not clickable, so I have removed the hightlightning.

A splash-box without jwm-border, needs a different background color than its parent.

Important text can be larger (another color) than ie the statusbar.

Widgets belonging together (search-field and sourcelist) can be unified by outfit.

...

I don't see this purely as bloat (we are talking about 10kb with SVGs and gtk-theme), but as a way to make the gui more intuitive for the user. But it arise a fundamental question?

One of the main goals for Puppy 4 was to use gtk2 - only. This would give an unified look of all programs in Puppy, and this fits my mind perfectly.
On the other side, the apps are evolving, and like Pmusic - evolving gives complexity. Nowadays we see that bigger apps (Chrome, Ardour, Spotify, LibreOffice, ...) uses their own api/theming.

I wonder how you look at this. Should svg/theming be kept to a minimum to stick to a unified look, or...?

With Pmusic being an "artist" type app and you being an artist I think you should take artistic license, in other words, do what you can . Similar for Pburn.

I guess with core apps they should be a little on the conservative side, perhaps detecting the colours in the default gtk theme and adjusting the svg code to suit? [not sure of the possibilities there].

Svg is wonderful and Barry knows it too, his Eve work took him along that path. I have only scratched the surface myself but it also appears to have great support for all fonts too, a bonus. I did delve into writing a splash app in C but my abilities were short of my ambitions at the time.

I look forward to your future using svg in gtkdialog and hope it will pave the way for such comments as "it looks too much like windows 7" ..

The color looks good except white or light-colored characters on a dark background are not as easy to read as dark characters on a light background. It's not just me; the readability was measured in laboratories by tall serious people wearing long white coats.

white or light-colored characters on a dark background are not as easy to read as dark characters on a light background

You might be right about that better paid people have found the answer. But for me, living in a country where it is dark half the year - even in the middle of the day, the contrast is so damn huge, I wear sun-glasses when looking at a fresh installed Australian distro.

Let's clear up a few things.
It is possible to adjust the running gtk-theme. - But with limitations. You can ie set some specific text to be bold, have fancy radiobuttons as in Pburn...

Here you can see the Startdust theme in combination with a mini-Pmusic-gtk-theme and how it is looking with the new complete theme.
The header is plain svg, and the text-color is set in the themerc file.

The point of using a global theme is still to have full control.
As seen here, the Stardust theme wants the <table> header to be visible (the blue one), while Pmusic actually don't want it to be shown.

More examples
- splitting areas for user interaction (green) and passive informative fields.
- unimportant information (albumart source - here; not found) gets attention because the gtk-theme either miss complete set of settings or the theme-creator have another idea.
...And isn't it lovely with a crystal clear 400x400px svg logo. Or do you think it is just to much in a system like Puppy?

Both these themes will available, but when I should decide which one should be the default one, I really couldn't make up my mind.... What is the logical Puppy-choice. Thanks to Mick and Flash for their opinions.

The tracks in the playlist mirrors what a metal-head is listening to the weeks before he get a free ticket to the psychiatric ward.

The greatest part about using svg base themes, is the near infinite reconfigurability options... if you set it up right from the beginning. What I mean is that you may create a really nice theme that is based on hard-coded SVG, but then even small modifications require a the user try and read code and hope he can modify the right thing or a talented developer wasting a lot of time trying to cleverly grok the proper details out of and back into several different files. On the other hand if you set it up from the beginning to use a config file of sorts to auto-generate the entire theme, then it would actually save a lot of code in the long run and make it more easily customizable.
(for instance you could have an option for a background image in any format supported by gtk, fill options for any sub-shape, text size/style color, opacity....the list goes on and on and could even default to a system default)

P.S. If you would like to standardize various system defaults (variable names, not necessarily values) I would be happy work to try and incorporate them into jwm_tools (I already have some code that pulls some of these from the gtkrc, but haven't used it because the defaults looked kinda bad with jwm)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

General look and feel is always a matter of taste, so I agree we should stay a bit greyish to avoid someone turn the back on us.

I made some changes to pmount and made every color adjustable in $HOME/.pmountrc (thank you technosaurus). For Pmusic it is a bit different, because the svgs are built around the logo. And since its shape and colors are static, I don't find it logical that the artwork should be themable.

On the other hand if you set it up from the beginning to use a config file of sorts to auto-generate the entire theme, then it would actually save a lot of code in the long run and make it more easily customizable.

For Pmusic some svg-settings are set with the graphical theme - /usr/local/pmusic/themes/$THEME/themerc. Else, I don't see the reason for user interaction. But all svg coding is placed together in /usr/local/pmusic/func_svg.

technosaurus wrote:

P.S. If you would like to standardize various system defaults (variable names, not necessarily values) I would be happy work to try and incorporate them into jwm_tools (I already have some code that pulls some of these from the gtkrc, but haven't used it because the defaults looked kinda bad with jwm)

What do you mean by standardize various system defaults. What would be cool if we had a command that returned basic fg/bg color from the active gtk-theme. It would be no need of unique theming of many SVGs.

@zigbert: this is what I had come up with, it has been in jwm_tools for a while but haven't had a chance to use it yet

Code:

#!/bin/sh
. /root/.jwm/jwm_colors
while read LINE ; do #go through trayfile line by line
case $LINE in
include*/usr/share/themes*)GTKRC=${LINE#include };GTKRC=${GTKRC//\"/};break;;
esac
done < ${HOME}/.gtkrc-2.0

The user interaction I was hinting at would be the ability for the user to change parts of the theme so they match better with their color schemes ... an orange triangle on the play button vs. green for instance... the default could even be to check if the user had a specific variable(s) for set for their color palette, and use that or fall back to standard green. I'm not sure exactly how those would be set up, but I am reminded of AIcons for some reason. (AIcons was a collection of xbm/xpm images that was set up using an intentionally limited color pallet)

In jwm_tools everything can be set using a simple shell variable in $HOME/.jwm/JWMRC ... it would be nice if gtk programs could do something similar, but I would need to learn a few more things about gtkrc files in order to auto-generate them from user defined variables, possibly by mapping similar configuration variables to similar configs (like menu background and fonts for jwm matching up with menus in gtk, or using the default font for the next higher level or global default if a specific one is not set ... or something like that) It shouldn't be difficult to generate and dump a custom gtkrc to disk (including some custom SVGs) ... I'd just need a couple of gtkrc files with some comments on what may need to be changed - I just get bogged down and lose focus/interest when it comes to creating the gui tools, so it would likely be a CLI interface that is easy to interface with gtkdialog.

technosaurus
Your idea is ok, but my experience with gtk-themes is that they are not as straightforward as we are used to in Puppy. We must allow users to install external gtk-themes found on the web, and your detection-code would fail in many cases. Look at the Nad4 gtk-theme for Pmusic, and you will find several 'fg [Normal]' set for unique widgets or classes. - And they are not having a specific order. If the detected color really matched is pure luck (well not quite - it would work for simple gtk-themes, like those we are used to in Puppy). When I worked on Puppy Stardust, my assumption was that all themes had a 'default' style setting, but no go. - the diversity is huge.

Your example of changing the color of the triangle is also nice, but I personally think we should stay away from dedicated logos (as for Pmusic). For general icons this would be great.

technosaurus
Your idea is ok, but my experience with gtk-themes is that they are not as straightforward as we are used to in Puppy. We must allow users to install external gtk-themes found on the web, and your detection-code would fail in many cases. Look at the Nad4 gtk-theme for Pmusic, and you will find several 'fg [Normal]' set for unique widgets or classes. - And they are not having a specific order. If the detected color really matched is pure luck (well not quite - it would work for simple gtk-themes, like those we are used to in Puppy). When I worked on Puppy Stardust, my assumption was that all themes had a 'default' style setting, but no go. - the diversity is huge.

you are correct about the possibility of having no default, which was the reason why I removed the "default" check which was overly complex anyways - my assumption was that theme makers would not make drastic style transitions from one widget to the next or it really wouldn't be much of a "theme"... I figured it would be fine to just use the last occurrence as long as the theme wasn't intentionally set up to distract the user from the content.

Quote:

Your example of changing the color of the triangle is also nice, but I personally think we should stay away from dedicated logos (as for Pmusic). For general icons this would be great.

Your original points just convinced me (whether or not that was the intention) that it would give puppy uniquely unified look if we could sync the style of icons in the applications and the system, but do it without having to include giant custom icon sets. Doing this with SVG while using theme-able variables could unify the whole system. It would be up to individual developers whether or not to use the system settings for things like: {FG,BG}_FillColor_{Solid,Primary,Secondary} {FG,BG}_Font_{Name,Color,...} and so on. It could start off as basic as only the primary "default"s as in Puppy or grow to have enough variables for every gtk widget type such that we could auto-regenerate the full gtkrc file (imagine a desktop that could even automagically morph with your preferences or your mood)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

Your original points just convinced me (whether or not that was the intention) that it would give puppy uniquely unified look if we could sync the style of icons in the applications and the system, but do it without having to include giant custom icon sets. Doing this with SVG while using theme-able variables could unify the whole system. It would be up to individual developers whether or not to use the system settings for things like: {FG,BG}_FillColor_{Solid,Primary,Secondary} {FG,BG}_Font_{Name,Color,...} and so on. It could start off as basic as only the primary "default"s as in Puppy or grow to have enough variables for every gtk widget type such that we could auto-regenerate the full gtkrc file (imagine a desktop that could even automagically morph with your preferences or your mood)

Just a word of caution: there is often a temptation to make things look uniform because people think it looks neat or pretty. I am an artist and understand how much of a temptation that can be, but I'm also a computer user and programmer who is very concerned with usability and psychology.

The look of a computer's interface is not just there for glamour. That is only a small aspect of it. The practical purpose is to enhance the use of the computer. Uniform shapes and colors can actually make it harder to use a GUI because we need difference in color, size, angle, and shape to differentiate between things.

If you look at a screen filled with 100 icons that all have a matching color theme, and very similar shapes and sizes then it can take a long time to find the icon you want, it's even quite likely you'll miss it entirely -- it will be "hiding in plain sight". In that situation a non-graphical text list is actually superior to a graphical interface. Not good. We've all seen examples of icon themes that fall into this trap. Macintosh interfaces are often an example of pretty interfaces that focus on looking cool, but which lose out on usability as a result.

On the other hand if the size, color, shape, and angles of the icons differ widely our wonderful pattern-matching visual system can find one item out of a hundred in a split second.

But it is not enough to have simply distinctive shapes, sizes, colors, and angles. The icons work best if they have an intuitive meaning -- clarity is not enough.

There has been some movement towards using smooth, photographic-looking icons. They do look pretty, but in my opinion I think this is a mistake. There is a lot to be said for the crispness and clarity of cartoon-style images. They condense a lot of meaning into a simplified graphic. There are very good psychological reasons why we draw things with lines. Even though the real world has very few lines, our eyes see much of it as if it has lines. The retinas of our eyes have special pattern-detectors that look for edges and they fire for lines too. We should capitalise on that. Smooth, blurry icons just don't trigger those detectors the same way.

SVG icons are wonderful for their ability to scale, fitting nicely with Puppy's aim for small size because we don't need lots of different sized icons. I'm just starting to delve into SVG myself, but I'd wondered if it was possible to define colors for a theme that could then be altered inside the icons -- after all SVG graphics are just text. That would mean we could use the same set of SVG icons for dark themed desktops as for light-themed desktops by simply rewriting some of the colors inside the icons.

Some thought would have to go into that though, of course. For instance you might think to swap black and white in an image to maintain contrast if on a black background or a white background, but if the image was of a pair of eyes that would just look silly.

Anyway... just my two cents. _________________A life! Cool! Where can I download one of those from?

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum