Ship with Aurorae and Qtcurve or not...

[Jens Reuterberg]

I guess I am sooo not the dude to say this as it's technical in 
nature but Aurorae theme is, as far as I recall, out as it has some 
issues speed wise (?) it was too taxing if I recall correctly (I'm sure 
I don't Martin G gave a handful of really good reasons why we 
shouldn't use it)

But I have a question - would cutting down features in Qtcurve 
make sense? Or would that be more trouble than its worth in the 
end? I am interested to know whether that is even an option to 
essentially go in with a chainsaw and cut lumps off as they 
become superflous and then allow people to install Qtcurve in its 
entirety if they want?

/Jens


On Thursday 19 June 2014 14.20.06 Hugo Pereira Da Costa wrote:
> On 06/17/2014 10:56 AM, Marco Martin wrote:
> > On Thu, May 29, 2014 at 3:09 PM, Marco Martin 
<notmart at gmail.com
> > 
> > <mailto:notmart at gmail.com>> wrote:
> >     On Thursday 15 May 2014 11:39:00 Jens Reuterberg wrote:
> >     > Ok so after the feedback from the Beta Release an issue 
that we
> >     
> >     knew was
> >     
> >     > coming have happened. Visuals being the most easily 
accessible
> >     
> >     bit of
> >     
> >     > anything technical, people have reacted negatively to the 
lack
> >     
> >     of change.
> >     
> >     just to give a shot on every and single options, i gave a try to
> >     modifying
> >     oxygen in order to make it look like breeze (therefore sharing 
all
> >     the things
> >     that it does that are not related to painting, like drag the
> >     window from
> >     anywhere)
> >     this is the half done, half missing attempt (ignore the non
> >     changed elements)
> >     http://wstaw.org/m/2014/05/29/plasma-desktophP1414.png
> >     
> >     is pretty hacky, but *maybe* is possible to have in the end 
only a
> >     different
> >     stylehelper (and pixelmetrics/stylehints)
> >     so could be something worth exploring in the future
> > 
> > Adding Hugo with a very due explanation of what it is:
> > The Visual Design Group came up with an idea for a new 
design for a
> > widget style in KDE.
> > But of course a Qt widget style is an huge undertaking that will 
take
> > a lot to do.
> > Now, Oxygen is the sum of years of experience and fixes, (and 
also
> > does a ton of things to make application behave well that are 
beside
> > just "painting", not to mention the companion themes that 
integrate
> > nicely gtk 2 and 3 apps) and would really be a shame to lose all 
those
> > years of development and experience, so I was wondering how 
hard would
> > be to adapt the Oxygen codebase to a new visual style (would 
be a new
> > style, or perhaps hopefully something sharing a lot of code)
> > 
> > in the link above, there is a screenshot of an attemptIi made to 
quick
> > and dirty try to adapt some of the elements (is incomplete and 
only
> > partial, but promising, seems that changing rounded radiuses 
and
> > removing some gradients here and there gets pretty close)
> > 
> > Hugo, do you think it would be a feasible thing? And would you 
be
> > interested in it? (I was thinking about something like 
maintaining
> > most of the style, and set apart an oxygenhelper(as is now) vs
> > breezehelper for the different visual related things)
> > 
> > Cheers,
> > Marco Martin
> 
> Hi Marco, others,
> 
> Sorry for the delayed answer.
> 
> First off, I unfortunately have very little time left since about half 
a
> year to dedicate to KDE/Oxygen aside from bug fixing and it is 
likely
> not going to improve. So that I would not be a reliable choice for
> undertaking the development of a Breeze Qt4/Qt5/Gtk2/Gtk3 
widget theme.
> (though I could give an occasional hand to anyone volunteering).
> 
> As for starting from Oxygen's code base, I think it is a good idea
> indeed. Large amount of code could likely be reused quite 
unchanged:
> animations, window grabbing, fancy splitters. They could even 
be moved
> to a library, that Breeze would load.
> (ok there is versionning, API freeze etc. involved, but no serious 
core
> development)
> 
> As for the styling, indeed rewriting the helper class is a possible
> start. Also, current oxygen  has basically one method for every
> primitive/control/etc. So it should also be easy to just inherit 
from
> it, and just re-implement these methods one after the other ...
> 
> Still, that would not bring you Gtk2 and Gtk3, which is quite a 
serious
> issue.
> 
> For such things, QtCurve is indeed a good candidate, since as far 
as I
> know it is the only widget theme around that implements all 
major
> flavors of toolkits ... but has an issue of "over-configuraribility" 
by
> design, which is not so good for branding, imho.
> 
> Last but not least, you could try "hire" the latest QtCurve dev for 
KDE
> (Yichao Yu <yyc1992 at gmail.com>)
> , to work on a cut-down and cleaned-up version of QtCurve, 
called
> Breeze. The guy is good, nice, very active and knows all of both 
Qt and
> Gtk. He has help debugging/fixing oxygen and qtcurve 
simultaneously
> quite a number of times already.
> 
> QtCurve already use (copy) part of oxygen's code (and vice 
versa), so
> here also I could contribute, without taking maintainership.
> 
> ... and finaly, there is window decoration. I guess one could start 
with
> an aurorae theme (although not optimal, since you ultimately 
need some
> extra features, such as synching with the widget theme, for 
background
> gradient for instance).
> 
> Hugo