[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon
From: "Michael O'Shea" <michael.a.oshea () gmail ! com>
Date: 2008-06-09 12:25:41
Message-ID: d323dcfd0806090525tce6c70aha3c3bf55e5524cb1 () mail ! gmail ! com
[Download RAW message or body]
Jakob,
I actually agree with you (discovery of features through expanding
dialogues). That was me running out of time on a stream-of-consciousness
sounding off.
Let's say I hadn't written the last "rules of thumb" bit, I still believe
that properly identifying the user types is key in the whole GUI discussion.
But back to one of the original points made earlier on : "I wrote this great
subsystem, given it a cool name, I want it to be embraced by the user". That
*may* work for power users but it certainly does not fit into any
task-driven scenarios, don't force it on users.
You made an interesting point with regard to the middle-ground users and I
don't claim to have the answers to that (although I'd love to discuss that).
My intervention really was triggered by the ego-driven notion pushed by some
hypothetical developer that the user should care about his groovy library.
Anyway, a lot of people have been talking about this over the last few days
and my posts are really just "my 2 cents".
Cheers,
Michael O'Shea
On Mon, Jun 9, 2008 at 12:00 PM, <kde-core-devel-request@kde.org> wrote:
> Send kde-core-devel mailing list submissions to
> kde-core-devel@kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/kde-core-devel
> or, via email, send a message with subject or body 'help' to
> kde-core-devel-request@kde.org
>
> You can reach the person managing the list at
> kde-core-devel-owner@kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kde-core-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon
> etc.) in user interfaces (Michael O'Shea)
> 2. KDE/kdelibs/kutils (Rafael Fern?ndez L?pez)
> 3. Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon
> etc.) in user interfaces (Jakob Petsovits)
> 4. Speeding up plotting widget (John Tapsell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 8 Jun 2008 11:59:41 +0200
> From: "Michael O'Shea" <michael.a.oshea@gmail.com>
> Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon
> etc.) in user interfaces
> To: kde-core-devel@kde.org
> Message-ID:
> <d323dcfd0806080259y514edfdcie7f319a767cff20a@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Although I'm joining late in the discussion, I'd like to add my voice to
> Michael Pyne's with regard to how to position software and users vis-a-vis
> of one another.
>
> I've been fascinated with the relationship between the programmer and the
> user ever since I started coding professionally in 1989. I have no training
> in cognitive whatevers that give me any authority on the matter so this is
> just *my *take on the debate.
>
> A few observations that I've come up with over, time:
> - as soon as a piece of s/w has a GUI, whatever the user wants and needs is
> CORRECT.
> - there are no stupid users, only users who want to get something done
> - the user doesn't care about the developer
> - corollary to the previous point : they couldn't care less what you think
> of how they should use your s/w regardless of how many sleepless night you
> put into it
> - the meaning of "intuitive" has been distorted by s/w developers to mean
> just about anything. Its true definition is "obtained through intuition
> rather than from reasoning or observation" (
> http://dictionary.reference.com/browse/intuitive)
>
> Now there *are* different types of users :
> - casual users
> - power users
>
> *Any disagreements between users and s/w developers or developers between
> themselves come purely from a disagreement on which angle to take on the
> casual/power user divide.
> *
> The two types have two different needs:
> - the casual user has simple, task-driven needs ("I just want to download a
> picture from my camera, rotate it and print it")
> - the power user has a function-driven need ("I want to make a cool texture
> to put on my mesh")
>
> The two approaches will require two different workflows:
> - the task-driven user can be catered for with wizards. This will cover
> 100%
> of the needs of 95% of casual users. The remaining 5% are ripe to become
> power users
> - the function-driven user will load up a bunch of image files into Gimp
> and
> start futzing around with them using many filters and effects, using the
> full selection of tools available to mix everything up until he/she's
> happy.
>
> Your s/w will implement one of the following:
> - if you want to cater only to the casual user : a full wizard approach
> (your app's splash screen is a wizard and will launch other wizards)
> - if you want to cater only to power users : a function-driven interface
> where objects and tool palettes can be opened all over the show to cover
> the
> whole 4 desktops available if the user wants it
> - if you want to cater to both : allow the user to choose at install time
> if
> they want to use wizards or if they're a power user (present it in
> non-condescending terms, and like John Lennon used to say : it's possible
> if
> you try). If a wizard user ever decide they want to break out of the
> hand-holding, they can easily go to power user from the splash screen,
> top-level wizard
>
> The developer must choose which of the three above points he's trying to
> achieve.
>
> My rules of thumb for creating a useful GUI :
> - the easy/straightforward stuff should be easy to get to / achieve in 3
> clicks
> - the hard/clever stuff should be only a little more involved to
> - the hard/clever stuff should not swamp the easy/straightforward
> (dialogues
> with "Advanced" or "More Options" fold-outs are great)
> - I'd write more but it's lunchtime here and the kids are getting restless
> :-)
>
> For anyone who's read so far, thanks for your time.
>
> Michael O'Shea
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/4fc11e86/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Sun, 08 Jun 2008 10:35:34 +0000
> From: Rafael Fern?ndez L?pez <ereslibre@kde.org>
> Subject: KDE/kdelibs/kutils
> To: kde-commits@kde.org
> Cc: kde-core-devel@kde.org
> Message-ID: <1212921334.195936.11046.nullmailer@svn.kde.org>
> Content-Type: text/plain; charset=UTF-8
>
> SVN commit 818331 by ereslibre:
>
> Use KAboutApplicationDialog for showing information about the plugins.
>
> CCMAIL: kde-core-devel@kde.org
>
>
> M +34 -26 kpluginselector.cpp
>
>
> --- trunk/KDE/kdelibs/kutils/kpluginselector.cpp #818330:818331
> @@ -43,6 +43,7 @@
> #include <kcategorydrawer.h>
> #include <kcategorizedview.h>
> #include <kcategorizedsortfilterproxymodel.h>
> +#include <kaboutapplicationdialog.h>
>
> #define MARGIN 5
>
> @@ -714,6 +715,25 @@
> const QModelIndex index = focusedIndex();
> const QAbstractItemModel *model = index.model();
>
> + // Try to retrieve the plugin information from the KComponentData
> object of the plugin.
> + // If there is no valid information, go and fetch it from the service
> itself (the .desktop
> + // file).
> +
> + PluginEntry *entry = index.model()->data(index,
> PluginEntryRole).value<PluginEntry*>();
> + KService::Ptr entryService = entry->pluginInfo.service();
> + if (entryService) {
> + KPluginLoader loader(*entryService);
> + KPluginFactory *factory = loader.factory();
> + if (factory) {
> + const KAboutData *aboutData =
> factory->componentData().aboutData();
> + if (!aboutData->programName().isEmpty()) { // Be sure the
> about data is not completely empty
> + KAboutApplicationDialog aboutPlugin(aboutData,
> itemView());
> + aboutPlugin.exec();
> + return;
> + }
> + }
> + }
> +
> const QString name = model->data(index, NameRole).toString();
> const QString comment = model->data(index, CommentRole).toString();
> const QString author = model->data(index, AuthorRole).toString();
> @@ -722,33 +742,21 @@
> const QString version = model->data(index, VersionRole).toString();
> const QString license = model->data(index, LicenseRole).toString();
>
> - QString message = i18n("Name:\n%1", name);
> -
> - if (!comment.isEmpty()) {
> - message += i18n("\n\nComment:\n%1", comment);
> + KAboutData aboutData(name.toUtf8(), name.toUtf8(),
> ki18n(name.toUtf8()), version.toUtf8(), ki18n(comment.toUtf8()),
> KAboutLicense::byKeyword(license).key(), ki18n(QByteArray()),
> ki18n(QByteArray()), website.toLatin1());
> + aboutData.setProgramIconName(index.model()->data(index,
> Qt::DecorationRole).toString());
> + QStringList authors = author.split(',');
> + QStringList emails = email.split(',');
> + int i = 0;
> + if (authors.count() == emails.count()) {
> + foreach (const QString &author, authors) {
> + if (!author.isEmpty()) {
> + aboutData.addAuthor(ki18n(author.toUtf8()),
> ki18n(QByteArray()), emails[i].toUtf8(), 0);
> + }
> + i++;
> + }
> }
> -
> - if (!author.isEmpty()) {
> - message += i18n("\n\nAuthor:\n%1", author);
> - }
> -
> - if (!email.isEmpty()) {
> - message += i18n("\n\nE-Mail:\n%1", email);
> - }
> -
> - if (!website.isEmpty()) {
> - message += i18n("\n\nWebsite:\n%1", website);
> - }
> -
> - if (!version.isEmpty()) {
> - message += i18n("\n\nVersion:\n%1", version);
> - }
> -
> - if (!license.isEmpty()) {
> - message += i18n("\n\nLicense:\n%1", license);
> - }
> -
> - KMessageBox::information(itemView(), message, i18n("About Plugin
> \"%1\"", name));
> + KAboutApplicationDialog aboutPlugin(&aboutData, itemView());
> + aboutPlugin.exec();
> }
>
> void KPluginSelector::Private::PluginDelegate::slotConfigureClicked()
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jun 2008 08:59:17 +0200
> From: Jakob Petsovits <jpetso@gmx.at>
> Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon
> etc.) in user interfaces
> To: kde-core-devel@kde.org
> Message-ID: <200806090859.18125.jpetso@gmx.at>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sunday, 8. June 2008, Michael O'Shea wrote:
> > - if you want to cater to both : allow the user to choose at install time
> > if they want to use wizards or if they're a power user (present it in
> > non-condescending terms, and like John Lennon used to say : it's possible
> > if you try). If a wizard user ever decide they want to break out of the
> > hand-holding, they can easily go to power user from the splash screen,
> > top-level wizard
>
> I think KDE's usability experts made it clear that switching modes like
> this
> is *not* a good thing for anyone, and that discovering more options should
> *not* happen via a "Advanced..." button in the vast majority of cases.
>
> Mainly because you cannot simply divide users into "power users" and
> "casual users" - there are users on the one extreme side and users on the
> other one, but there are also lots of users anywhere between. Some are
> experts in a particular area while being "casual users" in other areas.
>
> Coming up with several different interfaces for different target user
> groups
> is not what we want. It's the easy way out, but in the end a seamless
> transition from "casual user" to "power user" is the much more desirable
> solution. A complete break in user interfaces is not going to help making
> that leap.
>
> Wishes,
> Jakob
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jun 2008 10:18:00 +0100
> From: "John Tapsell" <johnflux@gmail.com>
> Subject: Speeding up plotting widget
> To: kde-core-devel@kde.org
> Message-ID:
> <43d8ce650806090218w4c08d89auc4a8f3615694fa40@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> I'm trying to improve the plotting widget thing in the kde system
> monitor (aka ksysguard). Basically it draws white background,
> horizontal/vertical lines, and then plots the cpu usage etc lines on
> top.
>
> I am finding that this is taking around 30% of the CPU, which makes
> it kinda useless for monitoring what the cpu usage is :-D
>
> The reason for it being slow is not obvious to me.
>
> If I draw just a white background, it takes 1% CPU usage.
> If I draw a white background + _dashed_ horizontal lines (updating
> twice a second), it takes up 10% CPU time (on dual core. so 20% of
> one CPU).
> If I draw a white background + _straight_ horizontal lines (updating
> twice a second), it takes up 1% CPU time
>
>
>
> There seem to be other reasons as to why it's slow, but this seems to
> be a good place to start. Why would drawing dashed lines be so slow?
> (It's about 10 horizontal lines, stretching across my screen (so about
> 1000 pixels long).
>
> How can I try to speed this up?
>
> Thanks!
>
> John Tapsell
>
>
> ------------------------------
>
> _______________________________________________
> kde-core-devel mailing list
> kde-core-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-core-devel
>
>
> End of kde-core-devel Digest, Vol 63, Issue 20
> **********************************************
>
[Attachment #3 (text/html)]
Jakob,<br><br>I actually agree with you (discovery of features through expanding \
dialogues). That was me running out of time on a stream-of-consciousness sounding \
off.<br><br>Let's say I hadn't written the last "rules of thumb" \
bit, I still believe that properly identifying the user types is key in the whole GUI \
discussion.<br> <br>But back to one of the original points made earlier on : "I \
wrote this great subsystem, given it a cool name, I want it to be embraced by the \
user". That *may* work for power users but it certainly does not fit into any \
task-driven scenarios, don't force it on users.<br> <br>You made an interesting \
point with regard to the middle-ground users and I don't claim to have the \
answers to that (although I'd love to discuss that).<br><br>My intervention \
really was triggered by the ego-driven notion pushed by some hypothetical developer \
that the user should care about his groovy library.<br> <br>Anyway, a lot of people \
have been talking about this over the last few days and my posts are really just \
"my 2 cents".<br><br>Cheers, <br><br>Michael O'Shea<br><br><div \
class="gmail_quote">On Mon, Jun 9, 2008 at 12:00 PM, <<a \
href="mailto:kde-core-devel-request@kde.org">kde-core-devel-request@kde.org</a>> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send kde-core-devel mailing \
list submissions to<br> <a \
href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br> <br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a \
href="https://mail.kde.org/mailman/listinfo/kde-core-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-core-devel</a><br> or, via \
email, send a message with subject or body 'help' to<br> \
<a href="mailto:kde-core-devel-request@kde.org">kde-core-devel-request@kde.org</a><br>
<br>
You can reach the person managing the list at<br>
<a \
href="mailto:kde-core-devel-owner@kde.org">kde-core-devel-owner@kde.org</a><br> <br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of kde-core-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Use of library names (Akonadi, Solid, Nepomuk, \
Phonon<br> etc.) in user interfaces (Michael \
O'Shea)<br> 2. KDE/kdelibs/kutils (Rafael Fern?ndez L?pez)<br>
3. Re: Use of library names (Akonadi, Solid, Nepomuk, \
Phonon<br> etc.) in user interfaces (Jakob Petsovits)<br>
4. Speeding up plotting widget (John Tapsell)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 8 Jun 2008 11:59:41 +0200<br>
From: "Michael O'Shea" <<a \
href="mailto:michael.a.oshea@gmail.com">michael.a.oshea@gmail.com</a>><br>
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID:<br>
<<a \
href="mailto:d323dcfd0806080259y514edfdcie7f319a767cff20a@mail.gmail.com">d323dcfd0806080259y514edfdcie7f319a767cff20a@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Although I'm joining late in the discussion, I'd like to add my voice to<br>
Michael Pyne's with regard to how to position software and users vis-a-vis<br>
of one another.<br>
<br>
I've been fascinated with the relationship between the programmer and the<br>
user ever since I started coding professionally in 1989. I have no training<br>
in cognitive whatevers that give me any authority on the matter so this is<br>
just *my *take on the debate.<br>
<br>
A few observations that I've come up with over, time:<br>
- as soon as a piece of s/w has a GUI, whatever the user wants and needs is<br>
CORRECT.<br>
- there are no stupid users, only users who want to get something done<br>
- the user doesn't care about the developer<br>
- corollary to the previous point : they couldn't care less what you think<br>
of how they should use your s/w regardless of how many sleepless night you<br>
put into it<br>
- the meaning of "intuitive" has been distorted by s/w developers to \
mean<br> just about anything. Its true definition is "obtained through \
intuition<br> rather than from reasoning or observation" (<br>
<a href="http://dictionary.reference.com/browse/intuitive" \
target="_blank">http://dictionary.reference.com/browse/intuitive</a>)<br> <br>
Now there *are* different types of users :<br>
- casual users<br>
- power users<br>
<br>
*Any disagreements between users and s/w developers or developers between<br>
themselves come purely from a disagreement on which angle to take on the<br>
casual/power user divide.<br>
*<br>
The two types have two different needs:<br>
- the casual user has simple, task-driven needs ("I just want to download a<br>
picture from my camera, rotate it and print it")<br>
- the power user has a function-driven need ("I want to make a cool texture<br>
to put on my mesh")<br>
<br>
The two approaches will require two different workflows:<br>
- the task-driven user can be catered for with wizards. This will cover 100%<br>
of the needs of 95% of casual users. The remaining 5% are ripe to become<br>
power users<br>
- the function-driven user will load up a bunch of image files into Gimp and<br>
start futzing around with them using many filters and effects, using the<br>
full selection of tools available to mix everything up until he/she's happy.<br>
<br>
Your s/w will implement one of the following:<br>
- if you want to cater only to the casual user : a full wizard approach<br>
(your app's splash screen is a wizard and will launch other wizards)<br>
- if you want to cater only to power users : a function-driven interface<br>
where objects and tool palettes can be opened all over the show to cover the<br>
whole 4 desktops available if the user wants it<br>
- if you want to cater to both : allow the user to choose at install time if<br>
they want to use wizards or if they're a power user (present it in<br>
non-condescending terms, and like John Lennon used to say : it's possible if<br>
you try). If a wizard user ever decide they want to break out of the<br>
hand-holding, they can easily go to power user from the splash screen,<br>
top-level wizard<br>
<br>
The developer must choose which of the three above points he's trying to<br>
achieve.<br>
<br>
My rules of thumb for creating a useful GUI :<br>
- the easy/straightforward stuff should be easy to get to / achieve in 3<br>
clicks<br>
- the hard/clever stuff should be only a little more involved to<br>
- the hard/clever stuff should not swamp the easy/straightforward (dialogues<br>
with "Advanced" or "More Options" fold-outs are great)<br>
- I'd write more but it's lunchtime here and the kids are getting \
restless<br> :-)<br>
<br>
For anyone who's read so far, thanks for your time.<br>
<br>
Michael O'Shea<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/4fc11e86/attachment.html" \
target="_blank">http://mail.kde.org/pipermail/kde-core-devel/attachments/20080608/4fc11e86/attachment.html</a><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 08 Jun 2008 10:35:34 +0000<br>
From: Rafael Fern?ndez L?pez <<a \
href="mailto:ereslibre@kde.org">ereslibre@kde.org</a>><br>
Subject: KDE/kdelibs/kutils<br>
To: <a href="mailto:kde-commits@kde.org">kde-commits@kde.org</a><br>
Cc: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID: <<a href="mailto:1212921334.195936.11046.nullmailer@svn.kde.org">1212921334.195936.11046.nullmailer@svn.kde.org</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
SVN commit 818331 by ereslibre:<br>
<br>
Use KAboutApplicationDialog for showing information about the plugins.<br>
<br>
CCMAIL: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
<br>
<br>
M +34 -26 kpluginselector.cpp<br>
<br>
<br>
--- trunk/KDE/kdelibs/kutils/kpluginselector.cpp #818330:818331<br>
@@ -43,6 +43,7 @@<br>
#include <kcategorydrawer.h><br>
#include <kcategorizedview.h><br>
#include <kcategorizedsortfilterproxymodel.h><br>
+#include <kaboutapplicationdialog.h><br>
<br>
#define MARGIN 5<br>
<br>
@@ -714,6 +715,25 @@<br>
const QModelIndex index = focusedIndex();<br>
const QAbstractItemModel *model = index.model();<br>
<br>
+ // Try to retrieve the plugin information from the KComponentData \
object of the plugin.<br> + // If there is no valid information, go and \
fetch it from the service itself (the .desktop<br> + // file).<br>
+<br>
+ PluginEntry *entry = index.model()->data(index, \
PluginEntryRole).value<PluginEntry*>();<br> + KService::Ptr \
entryService = entry->pluginInfo.service();<br> + if (entryService) \
{<br> + KPluginLoader loader(*entryService);<br>
+ KPluginFactory *factory = loader.factory();<br>
+ if (factory) {<br>
+ const KAboutData *aboutData = \
factory->componentData().aboutData();<br> + \
if (!aboutData->programName().isEmpty()) { // Be sure the about data is not \
completely empty<br> + \
KAboutApplicationDialog aboutPlugin(aboutData, itemView());<br> + \
aboutPlugin.exec();<br> + \
return;<br> + \
}<br> + }<br>
+ }<br>
+<br>
const QString name = model->data(index, NameRole).toString();<br>
const QString comment = model->data(index, \
CommentRole).toString();<br> const QString author = \
model->data(index, AuthorRole).toString();<br> @@ -722,33 +742,21 @@<br>
const QString version = model->data(index, \
VersionRole).toString();<br> const QString license = \
model->data(index, LicenseRole).toString();<br> <br>
- QString message = i18n("Name:\n%1", name);<br>
-<br>
- if (!comment.isEmpty()) {<br>
- message += i18n("\n\nComment:\n%1", \
comment);<br> + KAboutData aboutData(name.toUtf8(), name.toUtf8(), \
ki18n(name.toUtf8()), version.toUtf8(), ki18n(comment.toUtf8()), \
KAboutLicense::byKeyword(license).key(), ki18n(QByteArray()), ki18n(QByteArray()), \
website.toLatin1());<br>
+ aboutData.setProgramIconName(index.model()->data(index, \
Qt::DecorationRole).toString());<br> + QStringList authors = \
author.split(',');<br> + QStringList emails = \
email.split(',');<br> + int i = 0;<br>
+ if (authors.count() == emails.count()) {<br>
+ foreach (const QString &author, authors) {<br>
+ if (!author.isEmpty()) {<br>
+ \
aboutData.addAuthor(ki18n(author.toUtf8()), ki18n(QByteArray()), \
emails[i].toUtf8(), 0);<br> + }<br>
+ i++;<br>
+ }<br>
}<br>
-<br>
- if (!author.isEmpty()) {<br>
- message += i18n("\n\nAuthor:\n%1", \
author);<br>
- }<br>
-<br>
- if (!email.isEmpty()) {<br>
- message += i18n("\n\nE-Mail:\n%1", email);<br>
- }<br>
-<br>
- if (!website.isEmpty()) {<br>
- message += i18n("\n\nWebsite:\n%1", \
website);<br>
- }<br>
-<br>
- if (!version.isEmpty()) {<br>
- message += i18n("\n\nVersion:\n%1", \
version);<br>
- }<br>
-<br>
- if (!license.isEmpty()) {<br>
- message += i18n("\n\nLicense:\n%1", \
license);<br>
- }<br>
-<br>
- KMessageBox::information(itemView(), message, i18n("About Plugin \
\"%1\"", name));<br> + KAboutApplicationDialog \
aboutPlugin(&aboutData, itemView());<br> + aboutPlugin.exec();<br>
}<br>
<br>
void KPluginSelector::Private::PluginDelegate::slotConfigureClicked()<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 9 Jun 2008 08:59:17 +0200<br>
From: Jakob Petsovits <<a href="mailto:jpetso@gmx.at">jpetso@gmx.at</a>><br>
Subject: Re: Use of library names (Akonadi, Solid, Nepomuk, Phonon<br>
etc.) in user interfaces<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID: <<a href="mailto:200806090859.18125.jpetso@gmx.at">200806090859.18125.jpetso@gmx.at</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Sunday, 8. June 2008, Michael O'Shea wrote:<br>
> - if you want to cater to both : allow the user to choose at install time<br>
> if they want to use wizards or if they're a power user (present it in<br>
> non-condescending terms, and like John Lennon used to say : it's \
possible<br> > if you try). If a wizard user ever decide they want to break out of \
the<br> > hand-holding, they can easily go to power user from the splash \
screen,<br> > top-level wizard<br>
<br>
I think KDE's usability experts made it clear that switching modes like this<br>
is *not* a good thing for anyone, and that discovering more options should<br>
*not* happen via a "Advanced..." button in the vast majority of cases.<br>
<br>
Mainly because you cannot simply divide users into "power users" and<br>
"casual users" - there are users on the one extreme side and users on \
the<br> other one, but there are also lots of users anywhere between. Some are<br>
experts in a particular area while being "casual users" in other areas.<br>
<br>
Coming up with several different interfaces for different target user groups<br>
is not what we want. It's the easy way out, but in the end a seamless<br>
transition from "casual user" to "power user" is the much more \
desirable<br> solution. A complete break in user interfaces is not going to help \
making<br> that leap.<br>
<br>
Wishes,<br>
Jakob<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 9 Jun 2008 10:18:00 +0100<br>
From: "John Tapsell" <<a \
href="mailto:johnflux@gmail.com">johnflux@gmail.com</a>><br>
Subject: Speeding up plotting widget<br>
To: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
Message-ID:<br>
<<a \
href="mailto:43d8ce650806090218w4c08d89auc4a8f3615694fa40@mail.gmail.com">43d8ce650806090218w4c08d89auc4a8f3615694fa40@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi all,<br>
<br>
I'm trying to improve the plotting widget thing in the kde system<br>
monitor (aka ksysguard). Basically it draws white background,<br>
horizontal/vertical lines, and then plots the cpu usage etc lines on<br>
top.<br>
<br>
I am finding that this is taking around 30% of the CPU, which makes<br>
it kinda useless for monitoring what the cpu usage is :-D<br>
<br>
The reason for it being slow is not obvious to me.<br>
<br>
If I draw just a white background, it takes 1% CPU usage.<br>
If I draw a white background + _dashed_ horizontal lines (updating<br>
twice a second), it takes up 10% CPU time (on dual core. so 20% of<br>
one CPU).<br>
If I draw a white background + _straight_ horizontal lines (updating<br>
twice a second), it takes up 1% CPU time<br>
<br>
<br>
<br>
There seem to be other reasons as to why it's slow, but this seems to<br>
be a good place to start. Why would drawing dashed lines be so slow?<br>
(It's about 10 horizontal lines, stretching across my screen (so about<br>
1000 pixels long).<br>
<br>
How can I try to speed this up?<br>
<br>
Thanks!<br>
<br>
John Tapsell<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
kde-core-devel mailing list<br>
<a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-core-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-core-devel</a><br> <br>
<br>
End of kde-core-devel Digest, Vol 63, Issue 20<br>
**********************************************<br>
</blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic