[Kde-pim] [PATCH] Nice headers for akregator
Kolja
nikj at gmx.de
Thu Aug 21 16:53:46 BST 2008
On Monday 18 August 2008 00:14:26 Ingo Klöcker wrote:
> On Sunday 17 August 2008, Allen Winter wrote:
> > On Saturday 16 August 2008 16:24:34 Kolja wrote:
> > > Hello!
> > >
> > > I'm new to kde development and this is my first
> > > post to this mailing list.
> > >
> > > The attached patch changes the appearance of the
> > > headers in akregator. For a preview take a look at:
> > >
> > > http://datenschreck.net/kde/akregator_freshedHeaders_beforeAfter.
> > >jp g
> > > http://datenschreck.net/kde/akregator_freshedHeaders_beforeAfter_
> > >co mbinedView.jpg
> > >
> > > What's wrong with the old ones?
> > > - they look old
> > > - they do _not_ fit into the fresh oxygen
> > > environment
> > >
> > > What about the new ones?
> > > + they look more modern
> > > + they fit better into the environment
> > > + the title of an article is blue
> > > (QPalette::Link), so more users would
> > > recognice this as a link. With this the user
> > > can go to the complete article by "Complete
> > > Story" in the end and also by clicking the
> > > title.
> > > + if you select a feed in the tree view, the
> > > presented title (in the article viewer
> > > part/header) is now clickable (home page)
> > > + Colors (grey) from the color palette were used
> > > (http://wiki.kde.org/tiki-index.php?page=Colors)
> > > - they need more space
> > >
> > > The attached patch applies to the directory
> > > akregator/src, but only articleformatter.cpp is
> > > affected. It's meant for trunk.
> > >
> > > Comments and suggestions?! :)
> >
> > The new look seems beautiful to me. I haven't looked at the code
> > changes though. If we do this, we will need to also apply this new
> > style to KMail and KNode headers.
>
> Instead of adding/replacing the hard-coded styles they should be made
> themeable via CSS and/or HTML templates. I suggest to have a look at
> Kopete where the chat window style is completely themeable. Maybe
> some of the code can be shared.
>
>
> Regards,
> Ingo
Yes, it's a good idea to make it configurable. But what do
you exactly mean by this?
Would it be enough to outhouse the css/html stuff (for one
certain style), or do you mean providing a dialog/menu for
switching between _several_ styles? IMHO having one
good/clean style is enough (at least for now), it's just a
news reader ;)
Some observations I made:
=== Observation 1: There is a libkdepim/csshelper.cpp =====
o CSSHelper::cssDefinitions() returns a string with css
source (nothing is read from file/disk!)
o CSSHelper::cssDefinitions() is used by KMail/KNode,
not Akregator
KMail have several header styles (fancy, brief, standard,
long, all). The fancy style is the one that is really
similar to the one of akregator (blue and grey box).
Since CSSHelper::cssDefinitions() has some styles for *fancy*
stuff, it is possible to adapt the CSS there to a fresh/modern
header.
Nevertheless, all that stuff comes from memory and not a
file.
=== Observation 2: Kopete outhouses css _and_ html =========
Kopete is using html/css for the style of the chatwindows. A
unzipped *.tar.gz style for Kopete looks like this:
Contents
`-- Resources
|-- Footer.html
|-- Header.html
|-- Incoming
| |-- Action.html
| |-- Content.html
| |-- NextContent.html
| `-- buddy_icon.png
|-- Outgoing
| |-- Action.html
| |-- Content.html
| |-- NextContent.html
| `-- buddy_icon.png
|-- Status.html
|-- Variants
| |-- ALPHA10.png
| |-- ALPHA90.png
| |-- BlueGreen - Compact - Left Icons.css
| |-- BlueGreen - Compact - No Icons.css
| |-- BlueGreen - Compact.css
| |-- ...
`-- main.css
The artist has almost complete control since he can not only
edit the css but the html, too.
In general there are two basic ways to get it outhoused:
(1) Configuration by CSS.
The HML-Stuff is generated in formatArticle() of
DefaultNormalViewFormatter or
DefaultCombinedViewFormatter. There are a lot of
if-statements which determine wheter certain code
get's inserted or not. That is, the html code is not
static and providing only the css saves some work.
And that's how it should be? Splitting content from
praesentation.
(2) Configuration by CSS and HTML
Since the HTML part is not static we would have to
split it over several small html files and read them
on demand, like with the kopete chat windows.
Kopete took the second approach.
I found also a xml/xsl(t) kopete style (but I don't know
wheter it is currently used, haven't found the part in the
kopete code). Basically there is an XML File with all the
information. The artist have the chance to provide an *.xsl
for transforming the xml into html.
=== Proposal ===============================================
So what we want is to get out the css code into real files?!
Therefore I propose:
o Let's put the css code for each application into
share/apps/<app>/styles
For KMail, share/apps/kmail/styles would look like
this:
styles
|-- header_fancy
| |-- fileincluded.css
| |-- main.css
| `-- somefancyimage.png
|-- header_all
| `-- ...
|-- header_brief
| `-- ...
|-- header_long
| `-- ...
`-- header_standard
`-- ...
KNode
styles
|-- header_all
| `-- ...
|-- header_fancy
| |-- fileincluded.css
| |-- main.css
| `-- somefancyimage.png
`-- header_standard
`-- ...
Akregator
styles
`-- header_standard
`-- main.css
o Enhance KPIM::CSSHelper for the method:
void CSSHelper::setStyle(const QString& styleName)
Every app (KMail, KNode, Akregator) should set the
desired style which setStyle() and
CSSHelper::cssDefinitions() would return the
appropriate css code. Having this, we don't need to
modify any call to CSSHelper::cssDefinitions() from
KMail/KNode/Akregator.
styleName is the name of a directory in
apps/<app>/styles.
o Rewrite CSSHelper::cssDefinitions() in order to read
the set style (setStyle()) from file. Since the css
files include a lot of variables (e.g. %MAIN_FONT%)
they have to be substituted by cssDefinitions() with
values from current kde style.
Advantages:
+ css code is not in the library itself
+ css code is not in the app itself
+ css code can be easier modified/maintained by artists
+ Akregator would also use CSSHelper
Disadvantages:
- we have to read from disk, startup time?
- html code stays in the apps, maybe some artist wish to
modify this, too?
Well, IMHO it's ok to have the html stuff in the apps since
it's constructed dynamically. Splitting it up in several
files is just messy. Of course the html code has to be "good
enough" in order not to restrict the artists with "just"
css.
What do you think? I'm new to all this, so don't slap me ;)
Did I forget something? Which problems do you see?
Cheers,
Kolja
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list