[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] [Draft:] Today View
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-04-18 17:16:35
[Download RAW message or body]

On Friday 18 April 2003 17:14, Daniel Molkentin wrote:
> On Wednesday 16 April 2003 00:58, Cornelius Schumacher wrote:
> >
> >That means that you have to redraw the entire view with every little
> >change. This doesn't sound very efficient.
>
> But it's really not significant. How often does that page update?
> Plus a reload of the same page causes no flicker in khtml. Also from
> the speed POV I think it's not as significant as it sounds.

If information changes it's no longer the same page. If you have 
something on the page which changes often you will have a lot of 
reloads. Showing incoming mails is something which might need frequent 
updates. The size of the texts will change with every incoming mail. 
This will affect the layout. In HTML it's not that easy to cope with 
that.

If you have something shoing realtime data (e.g. a clock) you will have 
lots of updates.

> >> My motivation for not using widget's is easy: using a HTML view
> >> you can easily get an artist to sit down and make it pretty. Have
> >> fun doing the same with several independent (!) widgets.
> >
> >What's the difference between independent HTML snippets and
> > independent widgets? It's exactly the same problem. By the way, I
> > would prefer, if we could do the "today" view without requiring
> > khtml. This is an expensive class.
>
> But needed for KMail anyway.

But in Kontact it's not needed before starting the KMail part. If the 
"today" view uses khtml the initial startup of Kontact will be slowed 
down. I tried this with KOrganizer. If the "What's Next" view is done 
with KHTML, KOrganizer needs measurably longer to start.

> And I still think it's easier to make
> something up using CSS and HTML than with individual widgets. Compare
> at Evolution's and  KOrganizer's "What's next" view for an
> example.

The "What' next view" is HTML. It uses QTextBrowser instead of KHTML 
because of startup time, though. Or did you want to say that the 
"What's next view" is better than Evolutions "Executive Summary"? I 
don't know how Evolution implements that.

> Designers normally prefer HTML because they know how to
> prettify that one. With CSS, this even works pretty decently. We
> might be able to work with transparent widgets and such, but this
> easily causes problems and flicker if you are not careful. Using
> khtml is less troublesome in this case. I am not a diehard khtml
> provoter, I am just not sure if using khtml saves us reinventing the
> wheel even tho it doesn't look straight forward at first sight. We
> can still switch later on if this approach causes trouble.

HTML and CSS is nice for static content, but it doesn't work well with 
dynamic content as we have in the "today" view. We will have a lot of 
limitations by that approach.

It might be easier for some people to make pretty views in HTML, but if 
it's about an artist creating a design the implementation isn't that 
important. An artist would probably prefer to draw a design in a 
graphics program anyway.

It's not that hard to do things like a common background image, icons or 
special fonts or colors with widgets. It might be a bit more work for 
someone used to do these things in HTML, but it will give us more 
flexibility and will make it possible to implement more powerful 
"today" plugins.

> >> >Why should layout be easier with html than with widgets? You can
> >> > break it in both cases if you don't do it right. Widgets can
> >> > provide a lot more functionality, though.
> >>
> >> Right, but what "more" functionality do we need?
> >
> >For example a clock,
>
> There is already in kicker :)
>
> >newstickers,
>
> You'd use static representation of the RDF file here anyway. If
> people really want a ticker, they should use KNT
>
> >a widget to set the online state for instant messaging,
>
> No need for a widget either.
>
> >stock exchange graphs,
>
> Gets fed as image anyway. I am not aware of sites that provide data
> to draw your own graph. Correct me if I am wrong
>
> >tooltips showing more information for certain items
>
> HTML provides that, too.
>
> > context menus,
>
> Maybe you have a point here, but a overview page is normally
> something to look at and click (passive elements). Popup menus otoh
> are meant to manipulate active elements. Every element should provide
> a possibility to activatethe respective parts for further interaction
> (e.g. via a click on a link). IMHO khtml is perfectly fine for
> passive widgets mostly dealing with text.
>
> >tree widgets (e.g. for hierarchical todos) etc.
>
> Easy to prepresent in khtml using JS, real widgets would probably
> look clumsy. Still you might have a point here.

All your answers show that a HTML based view isn't powerful enough for a 
lot of features. "Do it elsewhere" can't be the answer for a developer 
wanting to integrate a cool new feature in the "today" view of Kontact.

(And I hope that you aren't serious about implementing parts of Kontact 
in JS ;-)

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]