Message: previous - next
Month: March 2016

Re: [trinity-devel] Visual facelifting proposals

From: Michele Calgaro <michele.calgaro@...>
Date: Wed, 2 Mar 2016 19:07:12 +0900
On 2016/03/01 07:11 AM, E. Liddell wrote:
> On Sun, 28 Feb 2016 19:42:44 +0100
> Thomas Maus <thomas.maus@...> wrote:
>> On Friday 26 February 2016, 07:44 wrote E. Liddell:
>>> On Wed, 24 Feb 2016 20:35:18 +0100 Thomas Maus wrote:
>>> ...
>>>> "".
>>> ...
>>>> The "vibrantly simple" icon set works very well vor me, for example.
>>> Adding a new icon set isn't quite as simple as just packaging it up--we need
>>> to retouch some individual icons to provide, for instance, a "T"-logo menu
>>> icon variant.   A new set addition is currently in (admittedly, slow)
>>> progress.
>> The TDE-menu-icon is configured as a file reference and thus stays correct even 
>> if the icon set is switched. Activating the Ravefinity "vibrantly simple" icon 
>> set was as simple as installing into the right place and activating via 
>> control center ...
> It isn't just the menu icon.  There are a whole bunch of TDE applications 
> that still share names and (potentially) icons with their KDE4 equivalents.  
> Some of those icons have Ks embedded in them.  TDE with KDE 
> branding is selling TDE short.
> Also, I just did a few experiments with different icon themes.  The results
> confirm that if TDE can't find an icon for something, it falls back on
> CrystalSVG.  This makes sense from a functional point of view (CrystalSVG
> is installed with tdelibs, so it will always be there), but it may not look so
> great if the main icon set is muted or flat-style.
>>>> * Tango -- only apps icons!?
>>> Not a TDE icon theme--in fact, I think it's intended for Gnome.  TDE
>>> installs CrystalSVG, iKons, KDEClassic, Kids, Locolor, Slick, and (in the
>>> accessibility package) Mono.  Candidates for addition would normally be KDE
>>> icon themes, which already have icons for most TDE applications.
>> Yes, but Tango actually was forced as requirement of 
>> "trinity-kmymoney-common-1.0.5-14.0.2_1.oss421.x86_64"
> If I had to guess, SUSE has an optional dependency switched on for a 
> GTK-based configuration GUI for some library that is used by kmymoney.  
> It isn't anything TDE is doing, and even the person building the SUSE 
> packages may not be aware it's being pulled in.
> I can't find a dependency path that would lead back to it for my distro,
> but Gentoo doesn't have packages for anything after kmymoney-1.0.2.
>>>> You might ask "so what?".
>>>> Well, they might scare off some users, before they find the more pleasing
>>>> themes.
>>> The first icon theme any new user is going to see is CrystalSVG, which is a
>>> complete theme with decent artwork, although in a style that isn't
>>> currently fashionable.  We can live with that, I think.
>> Depends on what the vision for Trinity is.
>> I imagine it difficult to widen the user base and achieve a long term 
>> perspective of survival, if the first impression of new users is "stale". 
> I'm aware of the problem, and I'm actually cautiously in favour of a refresh,
> with some caveats:
> 1.  "Fresh" is a moving target, and we have limited manpower.  Every
> addition we make now will need to be maintained and refreshed down the 
> road.  That's why I'm a little uncomfortable with adding whole packages 
> containing new types of artwork assets, like xcursors.
> 2.  Removing existing artwork has to be done with caution, and packages
> intended for accessibility or special hardware should be left alone unless there
> are active complaints or bugs.  That means I think Locolor should stick
> around (but if you want to make a case for removing, say, iKons, I'll
> take it seriously).
> 3.  Trinity's largest audience is likely those looking for a somewhat "retro" 
> desktop.  That means we need to be careful not to go overboard. ;P
>> Don't get me wrong:
>> I'm not arguing on the aesthetic level -- a desktop is a very personal working 
>> environment and beauty is in the eye of the beholder. (And I don't care, what 
>> personal and aesthetic decisions a user will take, because normally I don't 
>> have to look at them nor use them ...)
>> My point is ergonomics: A user might be accustomed to a specific icon set since 
>> over a decade, the re-cognition being essential to off-load mental workload 
>> and a fluent use of the desktop. The same is true of other presets like window-
>> shapes+behavior, button-placements, coloring and especially highlighting. 
> I'm aware.  My setup is non-standard to the point that it makes people
> used to the default settings for *any* desktop make strange noises and back 
> away slowly. ;)
>>>> For discussion: What about having a kind of "tag mechanism" for artwork?
>>>> We could then tag artwork as "colorful", "dark theme", "light theme",
>>>> "monochromatic", "accesibility optimzed", "nostalgia", "kids", "modern",
>>>> "conversative", "flippant", etc. (multiple tags can be applied to an
>>>> artwork!). The user might set preferences in the control-center, which
>>>> limit the artwork actually presented for selection -- this would be
>>>> innovative, improve the harmony of the resulting setup, reduce the
>>>> clutter in the selection lists and would enable a harmonic co-existence
>>>> of old and new visual styles, without need to drop legacy artwork.
>>> What we really need for that sort of thing is probably Planet Trinity, to
>>> encompass enough artwork to usefully fill out the categories without
>>> supersizing the artwork packages.  I've considered that from time to time
>>> (if only as a place to give users a clear list of what greeter, k3b, etc.
>>> theme packages will work with the Trinity versions of those applications),
>>> but I simply don't have the time to administer such a site.
>> au contraire, I'd prefer to have this functionality in the "tdepersonalizer" 
>> and control-center.
>> In "tdepersonalizer" as a few preconfigured fine-tuned and consistent themes 
>> (introduced by screenshots) plus a choice tag preset for the control-center.
>> In the control-center the tags act as a filter to visible icon/cursor sets etc.
>> If users wants to start with a specific "modern look", that is what they get -- 
>> and until they decide to widen their perspective by changing the filter tags.
> The problem is, again, that you can't please everybody.  Four or five curated 
> desktop themes, fine.  Five hundred, with all their art assets?  Much too large 
> to be included in the core package downloads.
> However, buried in the innards of the Control Center is an interface that accesses 
> websites to provide access to additional wallpapers etc.  Currently it only offers 
> what comes off's default RSS feeds (latest/highest rated/most 
> downloads), but it could be extended:  send keywords, get back custom feed of 
> matching items.  Put that in KPersonalizer too (if it isn't already there), and you've 
> got the best of both worlds.  But it needs the backing website store.

Hi Thomas, E.,
sorry for the late reply, I have been kind of busy these days.
I will try to reply here to your points.

I like the idea of having some "default desktop" as initial available choices. Perhaps we could have at least a couple
of them as standard, one being "TDE Classic" (i.e. now) and one being "TDE modern" (or something like this) with a more
modern icon set, mouse icons, theme, ....
We could show that on the website and update KPersonalizer to support both choices. KPersonalizer should basically offer
the user a choice between "predefined desktop styles" (this new idea) and "manual configuration" (i.e. the current
behavior). Also in the "manual configuration" we should add support for mouse icon set.
As additional step (for a later stage), we could set up some space on the server for additional predefined desktops and
themes and Improve KPersonalizer to download them on request.
This would provide more appealing options for new users while at the same time keep old users happy.
What do you think? Tim, Slavek, please also give your feedback.

Being that the developers are very few, this will be a slow upgrade process but as they say, if we never start, we will
never get there :-)