[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Default Styles
From: Alex Turbov <i.zaufi () gmail ! com>
Date: 2012-11-19 14:26:49
Message-ID: CANktQtvLY6VLPopEEghD8f1PWvXgftcS=11fUsQYYgryxBiEYQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Nov 19, 2012 at 5:15 PM, Christoph Cullmann <cullmann@absint.com>wrote:
> Hi,
>
> > Comments & Documentation
> > - dsComment
> > - dsDescription (new, e.g. @brief in doxygen, or """ in Python?)
> >
> > - dsDoxygenTag (new, e.g. @param, etc...)
> > - dsDoxygenId (new, e.g. foobar in "@param foobar", etc...)
> > Again, I don't think we have to introduce styles for particular
> > product/software (even so good as doxygen)... it can be implemented
> > by particular syntax file (doxygen.xml) w/o any problem. How do you
> > think it can be used in non programming language syntaxes? (despite
> > that doxygen can be used for big, but limited set of languages)
> the problem is, we need to have a least enough default styles to cover the
> major highlights
> in a way that zero hard-coded color values remain.
>
that is utopia! current syntax rules assume that authors can make a new
styles "on the fly" -- it means (and supposed) that default styles will
ever enough...
Else the shipped default styles make not much sense and it will be really
> hard for people to create
> new styles without special rules for highlightings.
>
> mmm... sorry, not understood this though... why it will be hard? the way
new styles created nowadays as for me couldn't be called 'hard'... or you
have plans make it harder? %)
Ideally, no .xml file should contain hard-coded colors in kate.git
>
>
this impossible w/ a current approach! which is designed to (easy) add new
styles and have ability to assign some colors to them as authors decide
(just because they CAN do it).. yeah, default styles will never enough (and
wouldn't be), and even if you'll take all styles used today in all xmls and
turn them into a one big 'default' set, tomorrow you recevie a bunch of new
syntaxes with new styles and colors added... there ALWAYS will #colors in
authored syntaxes!
instead of fighting with windmills maybe it would be better to change smth
in a concept? for example introduce dynamic (authomatically adopted to
user's color scheme) palette for new syntaxes? as for me, I have a light on
dark palette, and all the time I started to do smth w/ a file w/ syntax
I've never touch, I have to go to settings and reassign almost ALL damn
colors cuz they are designed for dark on light schemes (especially default
doxygen comments really annoyed me: black on gray HTML tags and deep blue
comments look really UGLY for me)... and w/ current (damn inconvinient UI)
it takes too much clicks and time for me... ideally, for me, it would be
excelent if I can define in xml smth like this:
for example if I'm going to add some style for tokens in comments I'd
prefer to define a style in terms of existing (default) styles + some
mutations... like "make it like a dsComment but slightly brighter", or
"smth middle between dsKeyword + dsComment", or "dsString + grayscale a
little"... and color generator should produce smth that would fit into my
DE color scheme w/o my intervention.
having such engine users will get adequate colors for new styles
automatically and yes, #colors will disappear in XML files :)
moreover, it will be possible to have a button 'Shuffle' in the color
settings UI which will regenerate all colors for all styles at once ... but
all of new colors still would fit into KDE color scheme and will not look
ugly. furthermore, user can 'fix' (disable to randomise) some color (if he
really like it for particular style), and pressing 'Shuffle' button will
change everything except fixed color -- so it will be easy to experiment
and turning palette for user's desire -- like a genetic algorithm w/
feedback from user.
this is how I see the color settings UI I'd like to have and use :) -- cuz
current color settings UI is REALLY UGLY AND HARD TO USE!
[Attachment #5 (text/html)]
<div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 19, 2012 at 5:15 PM, \
Christoph Cullmann <span dir="ltr"><<a href="mailto:cullmann@absint.com" \
target="_blank">cullmann@absint.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
Hi,<br>
<div><br>
> Comments & Documentation<br>
> - dsComment<br>
> - dsDescription (new, e.g. @brief in doxygen, or """ in \
Python?)<br> ><br>
> - dsDoxygenTag (new, e.g. @param, etc...)<br>
> - dsDoxygenId (new, e.g. foobar in "@param foobar", etc...)<br>
> Again, I don't think we have to introduce styles for particular<br>
> product/software (even so good as doxygen)... it can be implemented<br>
> by particular syntax file (doxygen.xml) w/o any problem. How do you<br>
> think it can be used in non programming language syntaxes? (despite<br>
> that doxygen can be used for big, but limited set of languages)<br>
</div>the problem is, we need to have a least enough default styles to cover the \
major highlights<br> in a way that zero hard-coded color values \
remain.<br></blockquote><div>that is utopia! current syntax rules assume that authors \
can make a new styles "on the fly" -- it means (and supposed) that default \
styles will ever enough... <br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Else the shipped \
default styles make not much sense and it will be really hard for people to \
create<br> new styles without special rules for highlightings.<br>
<br></blockquote><div> mmm... sorry, not understood this though... why it will be \
hard? the way new styles created nowadays as for me couldn't be called \
'hard'... or you have plans make it harder? %)<br><br></div> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> Ideally, no .xml file should contain hard-coded \
colors in kate.git<br> <br></blockquote></div><br>this impossible w/ a current \
approach! which is designed to (easy) add new styles and have ability to assign some \
colors to them as authors decide (just because they CAN do it).. yeah, default styles \
will never enough (and wouldn't be), and even if you'll take all styles used \
today in all xmls and turn them into a one big 'default' set, tomorrow you \
recevie a bunch of new syntaxes with new styles and colors added... there ALWAYS will \
#colors in authored syntaxes!<br> <br>instead of fighting with windmills maybe it \
would be better to change smth in a concept? for example introduce dynamic \
(authomatically adopted to user's color scheme) palette for new syntaxes? as for \
me, I have a light on dark palette, and all the time I started to do smth w/ a file \
w/ syntax I've never touch, I have to go to settings and reassign almost ALL damn \
colors cuz they are designed for dark on light schemes (especially default doxygen \
comments really annoyed me: black on gray HTML tags and deep blue comments look \
really UGLY for me)... and w/ current (damn inconvinient UI) it takes too much clicks \
and time for me... ideally, for me, it would be excelent if I can define in xml smth \
like this:<br> for example if I'm going to add some style for tokens in comments \
I'd prefer to define a style in terms of existing (default) styles + some \
mutations... like "make it like a dsComment but slightly brighter", or \
"smth middle between dsKeyword + dsComment", or "dsString + grayscale \
a little"... and color generator should produce smth that would fit into my DE \
color scheme w/o my intervention.<br> <br>having such engine users will get adequate \
colors for new styles automatically and yes, #colors will disappear in XML files \
:)<br>moreover, it will be possible to have a button 'Shuffle' in the color \
settings UI which will regenerate all colors for all styles at once ... but all of \
new colors still would fit into KDE color scheme and will not look ugly. furthermore, \
user can 'fix' (disable to randomise) some color (if he really like it for \
particular style), and pressing 'Shuffle' button will change everything \
except fixed color -- so it will be easy to experiment and turning palette for \
user's desire -- like a genetic algorithm w/ feedback from user.<br> <br>this is \
how I see the color settings UI I'd like to have and use :) -- cuz current color \
settings UI is REALLY UGLY AND HARD TO USE!<br><br></div>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic