Re: My progress
On Wednesday 14 January 2009, Marco Martin wrote: > On Wednesday 14 January 2009, Aaron J. Seigo wrote: > > On Wednesday 14 January 2009, Marco Martin wrote: > > > On Tuesday 13 January 2009, Aaron J. Seigo wrote: > > > > this would probably mean creating a small Plasma::Message class or > > > > (even re- using Plasma::ToolTipContent perhaps?) and allow plasmoids > > > > to queue such messages with the Applet class. the Applet class would > > > > then display it in a "plasma" way (what does that mean? i don't know > > > > for sure, but we can work that out together; perhaps an overlay on > > > > the plasmoid itself if it is big enough, perhaps a tooltip type > > > > thing, perhaps a notification in the system tray,...?) > > > > > > hmm woudn't this mean duplicating knotify in a similar-but-not-quite > > > way? > > > > it's not meant as a replacement for notifications, but rather a widget > > appropriate replacement for dialog boxes ... > > > > good example is folderview when it can't load the folder (doesn't exist, > > network down, whatever). that functionality should be available to all > > widgets. > > > > the weather widget in kdrevew uses a KMessagBox right now, because it's > > easy to do, but that causes all sorts of problems: it doesn't look Plasma > > and it blocks mouse interaction with the rest of the desktop. > > > > it'll also give us a nice simple bit of API to give scripters. > > could be something like the stuff attached, yep, that's probably pretty close =) perhaps showMessage(..) though? > not really sure if it should > have also other buttons like a yes/no/cancel we'll eventually get a request for that, i'm sure. there's also the case where there is no "Ok" option, really. e.g. folderview's "I can't load this folder!" and then there is the situation of widgets in a space (e.g. the panel) that is too small to show it inline, so it would need to go into some sort of popup. it's a little more complicated i guess =) > and be syncronous like > dialog.exec()? i don't think it needs to be sync, no... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: My progress
On Wednesday 14 January 2009, Aaron J. Seigo wrote:
> On Wednesday 14 January 2009, Marco Martin wrote:
> > On Tuesday 13 January 2009, Aaron J. Seigo wrote:
> > > this would probably mean creating a small Plasma::Message class or
> > > (even re- using Plasma::ToolTipContent perhaps?) and allow plasmoids to
> > > queue such messages with the Applet class. the Applet class would then
> > > display it in a "plasma" way (what does that mean? i don't know for
> > > sure, but we can work that out together; perhaps an overlay on the
> > > plasmoid itself if it is big enough, perhaps a tooltip type thing,
> > > perhaps a notification in the system tray,...?)
> >
> > hmm woudn't this mean duplicating knotify in a similar-but-not-quite way?
>
> it's not meant as a replacement for notifications, but rather a widget
> appropriate replacement for dialog boxes ...
>
> good example is folderview when it can't load the folder (doesn't exist,
> network down, whatever). that functionality should be available to all
> widgets.
>
> the weather widget in kdrevew uses a KMessagBox right now, because it's
> easy to do, but that causes all sorts of problems: it doesn't look Plasma
> and it blocks mouse interaction with the rest of the desktop.
>
> it'll also give us a nice simple bit of API to give scripters.
could be something like the stuff attached, not really sure if it should have
also other buttons like a yes/no/cancel and be syncronous like dialog.exec()?
Cheers,
Marco Martin
Index: applet.h
===
--- applet.h (revision 910984)
+++ applet.h (working copy)
@@ -729,6 +729,8 @@
*/
void setConfigurationRequired(bool needsConfiguring, const QString &reason = QString());
+void message(const QString &icon, const QString &message);
+
/**
* Reimplement this method so provide a configuration interface,
* parented to the supplied widget. Ownership of the widgets is passed
Index: applet.cpp
===
--- applet.cpp (revision 910984)
+++ applet.cpp (working copy)
@@ -880,6 +880,46 @@
d->messageOverlay->show();
}
+void Applet::message(const QString &icon, const QString &message)
+{
+d->createMessageOverlay();
+QGraphicsLinearLayout *mainLayout = new QGraphicsLinearLayout(d->messageOverlay);
+mainLayout->setOrientation(Qt::Vertical);
+mainLayout->setContentsMargins(10, 10, 10, 10);
+
+QGraphicsLinearLayout *messageLayout = new QGraphicsLinearLayout();
+messageLayout->setOrientation(Qt::Horizontal);
+
+QGraphicsLinearLayout *buttonLayout = new QGraphicsLinearLayout();
+buttonLayout->setOrientation(Qt::Horizontal);
+
+mainLayout->addItem(messageLayout);
+mainLayout->addItem(buttonLayout);
+
+IconWidget *messageIcon = new IconWidget(this);
+Label *messageText = new Label(this);
+messageText->nativeWidget()->setWordWrap(true);
+
+messageLayout->addItem(messageIcon);
+messageLayout->addItem(messageText);
+
+messageIcon->setIcon(KIcon(icon));
+messageText->setText(message);
+
+
+buttonLayout->addStretch();
+PushButton *ok = new PushButton(this);
+ok->setText(i18n("Ok"));
+//FIXME: QGL brokeness++
+ok->setMinimumHeight(23);
+buttonLayout->addItem(ok);
+buttonLayout->addStretch();
+
+connect(ok, SIGNAL(clicked()), this, SLOT(destroyMessageOverlay()));
+d->messageOverlay->show();
+
+}
+
void Applet::flushPendingConstraintsEvents()
{
if (d->pendingConstraints == NoConstraint) {
@@ -935,7 +975,7 @@
if (c & Plasma::SizeConstraint) {
if (d->messageOverlay) {
d->messageOverlay->setGeometry(QRectF(QPointF(0, 0), geometry().size()));
-
+/*
QGraphicsItem *button = 0;
QList children = d->messageOverlay->QGraphicsItem::children();
@@ -947,7 +987,7 @@
QSizeF s = button->boundingRect().size();
button->setPos(d->messageOverlay->boundingRect().width() / 2 - s.width() / 2,
d->messageOverlay->boundingRect().height() / 2 - s.height() / 2);
-}
+}*/
}
if (d->busyWidget && d->busyWidget->isVisible()) {
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KRunner keywords and translations
On Wednesday 14 January 2009, Anne-Marie Mahfouf wrote: > Hi, > > I am occasionally helping with French translation and I was wondering about > KRunner keywords. > > - can anyone check if they work? they don't for me. hm.. it should; it's comparing against the translated versions... could it be that the translation catalog isn't being loaded? hm... > - if so I think we should add info about the used keywords so that users > will be able to use them. I don't think the PowerDevil ones can be guessed > (not even probably in English) Not sure where this info can be added, is it > possible to add a tab in the About dialog for example? this comes up every month or two and i keep giving the same answer; eventually i'll just give up procrastinating and actually implement it ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Wednesday 14 January 2009, David Baron wrote: > 1. Folks seem to be posting applets on kde-look. This is for eye-candy, > decorations, screen savers. Applets that treat useful information belong > on kde-apps, I would think. we (plasma team) don't actually control that =) > 2. What to show? Seems to be a trend of plaster large screen areas with the > whole kit-and-caboodle. Very quickly, there is no more room. Why do I need > three days (count 'em) of weather forecast covering a percentage of my > screen real estate? Same with network stats and system info. because a lot of people want that. fairly simple =) in any case, now that we have PopupApplet, it would be a nice time to work on being able to collapse applets into their Popup form even when on the desktop, perhaps via an icon in the widget handle. > 3. KDE3 panel applets/services I STILL use because they have not been > ported: knemo, ksensors. There was also a system-monitor (four of them > posted on kde- look are not as nice), kweather, kisa (cool live > spell-checker), and others which will not work or not function correctly in > KDE4. kweather is unecessary; just put the weather widget in your panel. system monitor widget is in addons now, and the ones with graphs work just fine in the panel (could use some more tweaking and beautifying, but are just as fine as the kde3 ones already) the only one in your list that i don't think is really there is a kisa replacement. that would be beyond trivial to write, though. > Would love to see (or participate in) their port to KDE4 (not just > getting off dcop but going over to provided data-engines). kicker applet -> plasma widget is essentially a rewrite of the applet. fortunately, they tended to be fairly small. > What is distinctive about these is that they present (even a small!!) icon > on the panel which shows a useful bit of information (which sometimes I can > choose). If I want more, I hover over the icon or click it and then I have > access to everything. Examples of current KDE4 applets that work this way > are kget, kmix. .. and the device notifier, kickoff, weather, battery, networkmanager, system monitor widgets, clocks, calculator, folderview ... btw, kmix is a system tray icon, not an applet (in kde3 or kde4).. so.. yes, i don't think the landscape is quite as you describe it. there's lots of room for improvements and new widgets to be written, certainly. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: My progress
On Wednesday 14 January 2009, Aaron J. Seigo wrote: > On Wednesday 14 January 2009, Marco Martin wrote: > > On Tuesday 13 January 2009, Aaron J. Seigo wrote: > > > this would probably mean creating a small Plasma::Message class or > > > (even re- using Plasma::ToolTipContent perhaps?) and allow plasmoids to > > > queue such messages with the Applet class. the Applet class would then > > > display it in a "plasma" way (what does that mean? i don't know for > > > sure, but we can work that out together; perhaps an overlay on the > > > plasmoid itself if it is big enough, perhaps a tooltip type thing, > > > perhaps a notification in the system tray,...?) > > > > hmm woudn't this mean duplicating knotify in a similar-but-not-quite way? > > it's not meant as a replacement for notifications, but rather a widget > appropriate replacement for dialog boxes ... > > good example is folderview when it can't load the folder (doesn't exist, > network down, whatever). that functionality should be available to all > widgets. > > the weather widget in kdrevew uses a KMessagBox right now, because it's > easy to do, but that causes all sorts of problems: it doesn't look Plasma > and it blocks mouse interaction with the rest of the desktop. > > it'll also give us a nice simple bit of API to give scripters. for that i would use something similar to setConfiguratioRequired() in Applet is actually quite generalized already, i think i'll throw a patch on that in a moment :) would it have to be just a message or allow generic graphicswidgets throwing in it? (i would keep really simple) so just message, icon and buttons like a real dialog? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Wednesday 14 January 2009, David Baron wrote: > Standards? I used qt4/kde4 widgets and kicons to KDE styles in my applet. > Plasma has its own themes (but one would need to create icons) and its own > widgets as well. Must use/should use/there if needed? plasma uses the regular KDE icons from KIconLoader for everything except its widget handle items. the plasma widgets are just regular Qt widgets that are nicely wrapped (and in many cases themed) for use on a Plasma QGraphicsView -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: My progress
On Wednesday 14 January 2009, Marco Martin wrote: > On Tuesday 13 January 2009, Aaron J. Seigo wrote: > > this would probably mean creating a small Plasma::Message class or (even > > re- using Plasma::ToolTipContent perhaps?) and allow plasmoids to queue > > such messages with the Applet class. the Applet class would then display > > it in a "plasma" way (what does that mean? i don't know for sure, but we > > can work that out together; perhaps an overlay on the plasmoid itself if > > it is big enough, perhaps a tooltip type thing, perhaps a notification in > > the system tray,...?) > > hmm woudn't this mean duplicating knotify in a similar-but-not-quite way? it's not meant as a replacement for notifications, but rather a widget appropriate replacement for dialog boxes ... good example is folderview when it can't load the folder (doesn't exist, network down, whatever). that functionality should be available to all widgets. the weather widget in kdrevew uses a KMessagBox right now, because it's easy to do, but that causes all sorts of problems: it doesn't look Plasma and it blocks mouse interaction with the rest of the desktop. it'll also give us a nice simple bit of API to give scripters. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Wednesday 14 January 2009 20:04:10 Alex Merry wrote: > On Wednesday 14 January 2009 07:45:16 David Baron wrote: > > 3. KDE3 panel applets/services I STILL use because they have not been > > ported: knemo, ksensors. There was also a system-monitor (four of them > > posted on kde- look are not as nice), kweather, kisa (cool live > > spell-checker), and others which will not work or not function correctly > > in KDE4. Would love to see (or participate in) their port to KDE4 (not > > just getting off dcop but going over to provided data-engines). > > Does this mean you're volunteering to help port these? > > Alex I would have to see the sources. I find most people's code (including my own more than sometimes) incomprehensible after a while. Documentation, documentation, documentation. I saw come limited docs about porting, dcop, etc. Not enough. I have seen no documentation of value for plasma beyond the nice skeleton that got me started doing a plasmoid (no, not so hard), and applet.h. The oxygen-generated docs on line are not the greatest and I have seen nothing about the data-engines, i.e. to incorporated kdepim stuff into my phone applet. Knemo and ksensors will obviously use the data- engines. Standards? I used qt4/kde4 widgets and kicons to KDE styles in my applet. Plasma has its own themes (but one would need to create icons) and its own widgets as well. Must use/should use/there if needed? I am available to an extent but it depends upon how tangled this can get. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Wednesday 14 January 2009 07:45:16 David Baron wrote: > 3. KDE3 panel applets/services I STILL use because they have not been > ported: knemo, ksensors. There was also a system-monitor (four of them > posted on kde- look are not as nice), kweather, kisa (cool live > spell-checker), and others which will not work or not function correctly in > KDE4. Would love to see (or participate in) their port to KDE4 (not just > getting off dcop but going over to provided data-engines). Does this mean you're volunteering to help port these? Alex signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] fix for krazy2 issues [includes]
On Wednesday 14 January 2009 13:47:39 Bruno Bigras wrote: > Can someone commit this for me please? I don't have this power yet. I can do that =) Committing now ;) > Thanks! Thank you! Cheers -- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://labs.morpheuz.eng.br/blog/ GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] fix for krazy2 issues [includes]
On Tue, 13 Jan 2009 22:02:02 -0700, "Aaron J. Seigo" wrote: > On Tuesday 13 January 2009, Bruno Bigras wrote: >> This is for section #13 (Check for proper include directives [includes]) > > looks good; please commit. =) Thanks for the feedback Aaron! Can someone commit this for me please? I don't have this power yet. Thanks! Bruno ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Wednesday 14 January 2009 10:21:21 Cornelius Schumacher wrote: > On Wednesday 14 January 2009 10:11:22 Fabrizio Montesi wrote: > > On Tuesday 13 January 2009 23:07:37 Cornelius Schumacher wrote: > > > I think the best solution would be, if JOLIE could use kio-slaves as > > > transport layer. This would naturally give great integration with other > > > KDE applications without having to implement all the configuration and > > > shared infrastructure again. > > > > I agree, but using KIO will not be so straightforward. I need to check if > > KIO allows for all the HTTP header manipulation Web Services need through > > its D- Bus interface (if something is needed and not supported, I shall > > mention it and ask for a patch in KIO, kde-devel would be the right place > > for that right?). > > The HTTP kioslave allows for quite some header manipulations, although the > API is lacking a bit of consistency there. > > I'm not sure who maintains kio_http these days, but I would think that > kde-core-de...@kde.org is the right place for discussing patches. Good, thanks for the pointer. > > > I care for saying that changing the protocol JOLIE uses in the future > > won't cause any problem, i.e. we can start using the JOLIE http protocol > > and then change to KIO as soon as the integration is ready with some > > trivial changes in the JOLIE plasma adaptors (probably something like > > changing "http" to "kio_http" in the communication port protocol > > configurations). > > This sounds like a good migration path. > > > I didn't find any documentation about KIO's dbus interface, maybe the > > best thing to do is to look at the source code? > > As far as I know there isn't a direct D-Bus interface to KIO. Maybe it > would make sense to write one. This could possibly negatively affect data > throughput, though. Still seems to be worth some investigation. Yes (to each point ;). I say "D-Bus" because nothing else comes to my mind to make JOLIE interacting with KIO (putting KDE-Java/QtJambi as a requirement doesn't seem a great idea to me), but suggestions are welcome. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Wednesday 14 January 2009 10:11:22 Fabrizio Montesi wrote: > On Tuesday 13 January 2009 23:07:37 Cornelius Schumacher wrote: > > > > I think the best solution would be, if JOLIE could use kio-slaves as > > transport layer. This would naturally give great integration with other > > KDE applications without having to implement all the configuration and > > shared infrastructure again. > > I agree, but using KIO will not be so straightforward. I need to check if > KIO allows for all the HTTP header manipulation Web Services need through > its D- Bus interface (if something is needed and not supported, I shall > mention it and ask for a patch in KIO, kde-devel would be the right place > for that right?). The HTTP kioslave allows for quite some header manipulations, although the API is lacking a bit of consistency there. I'm not sure who maintains kio_http these days, but I would think that kde-core-de...@kde.org is the right place for discussing patches. > I care for saying that changing the protocol JOLIE uses in the future won't > cause any problem, i.e. we can start using the JOLIE http protocol and then > change to KIO as soon as the integration is ready with some trivial changes > in the JOLIE plasma adaptors (probably something like changing "http" to > "kio_http" in the communication port protocol configurations). This sounds like a good migration path. > I didn't find any documentation about KIO's dbus interface, maybe the best > thing to do is to look at the source code? As far as I know there isn't a direct D-Bus interface to KIO. Maybe it would make sense to write one. This could possibly negatively affect data throughput, though. Still seems to be worth some investigation. -- Cornelius Schumacher ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde community plasma integration
On Tuesday 13 January 2009 23:07:37 Cornelius Schumacher wrote: > On Tuesday 13 January 2009 19:28:08 Fabrizio Montesi wrote: > > On Wednesday 07 January 2009 16:17:03 Frank Karlitschek wrote: > > > [lots of cool things...] > > Yes, definitely. I'm lacking the time to write a detailed response to it > right now, but I'm really looking forward to get community web services > integrated with the desktop. > > > iirc Cornelius raised the interesting problem of respecting KDE's > > preferences for connections... we should spend a minute about how much of > > that we want in Plasma<->JOLIE integration and how to do it: a dbus > > service by KDE's side that JOLIE would access? JOLIE reading some KDE > > config file? > > It's not only about simply reading config options. It's also about sharing > credentials via kwallet, having a central store and management UI for > cookies, certificates, cache, and consistent handling of offline mode, > progress information and some other stuff. > > I think the best solution would be, if JOLIE could use kio-slaves as > transport layer. This would naturally give great integration with other KDE > applications without having to implement all the configuration and shared > infrastructure again. I agree, but using KIO will not be so straightforward. I need to check if KIO allows for all the HTTP header manipulation Web Services need through its D- Bus interface (if something is needed and not supported, I shall mention it and ask for a patch in KIO, kde-devel would be the right place for that right?). I care for saying that changing the protocol JOLIE uses in the future won't cause any problem, i.e. we can start using the JOLIE http protocol and then change to KIO as soon as the integration is ready with some trivial changes in the JOLIE plasma adaptors (probably something like changing "http" to "kio_http" in the communication port protocol configurations). I didn't find any documentation about KIO's dbus interface, maybe the best thing to do is to look at the source code? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: My progress
On Tuesday 13 January 2009, Aaron J. Seigo wrote: > On Tuesday 13 January 2009, Henk te Sligte wrote: > > I thought it might be a good idea to develop an applet (and engine) > > for a random purpose, just to get familiar with Plasma, I'm thinking > > about an applet which displays the status from a sabnzbd server > > (http://www.sabnzbd.org). The API of sabnzbd is quite good, so I can > > concentrate at learning Plasma. > > neat, i didn't even know about sabnzbd (and... how the HECK do you > pronounce that?) > > > After that, I'm not really sure what to do next. I have seen some > > tasklists (e.g. http://techbase.kde.org/Projects/Plasma/Tasks), maybe > > it's a good idea to pick one of those and see how far I get. But I'm > > not really sure about all of this. > > i really need to update that page again. people keep racing ahead so > quickly that the page needs constant tending. i'm a poor gardener, i'm > afraid. anyways, i'm happy to point you in the direction of "stuff that > needs attention". > > something that would be relatively simple but let you play with the "guts" > of plasma a bit is adding a standardized way for plasmoids to show a > message to the user. > > this would probably mean creating a small Plasma::Message class or (even > re- using Plasma::ToolTipContent perhaps?) and allow plasmoids to queue > such messages with the Applet class. the Applet class would then display it > in a "plasma" way (what does that mean? i don't know for sure, but we can > work that out together; perhaps an overlay on the plasmoid itself if it is > big enough, perhaps a tooltip type thing, perhaps a notification in the > system tray,...?) hmm woudn't this mean duplicating knotify in a similar-but-not-quite way? > i have a whole list of such things just waiting to be plucked and fixed ;) > others on this mailing list also have their own pet lists too... > > and there's also bugs.kde.org which has oodles of feature requests. > > > I have a couple of questions: Is the process which I have in mind a > > good idea? > > i'd say it's a perfect path. > > > Am I too optimistic, because Plasma is too hard > > nah, there's something in there for all skill levels. it was built to be > easy to start hacking on. > > > (as far as > > I've seen, it's quite readable, and it just makes sense). > > thanks =) > > > I know there > > are some mentors for KDE, is there also a mentor for Plasma, or can I > > do the learning process on my own? > > you can do the learning process on your own, but you are *more* than > welcome to ask questions here on the mailing list or in #plasma-devel. the > only stupid question is the unasked question. > > > Feel free to comment on anything I wrote, I sent this mail basically > > on two purposes: To get to know you guys a bit better, and, to be > > honest, I'd like to be a bit in the picture. Maybe someone has a small > > bug which should be easy to fix, and good to learn. > > heh. those ones tend to get fixed fast. we eat bugs for breakfast around > here. > > here's a really trivial one, though: > > https://bugs.kde.org/show_bug.cgi?id=179563 > > most of the others after that one on the plasma bug list probably aren't > great starter jobs. > > welcome to Plasma ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KRunner keywords and translations
Hi, I am occasionally helping with French translation and I was wondering about KRunner keywords. - can anyone check if they work? they don't for me. - if so I think we should add info about the used keywords so that users will be able to use them. I don't think the PowerDevil ones can be guessed (not even probably in English) Not sure where this info can be added, is it possible to add a tab in the About dialog for example? Best regards, Anne-Marie ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: My progress
2009/1/13 Aaron J. Seigo : > On Tuesday 13 January 2009, Henk te Sligte wrote: >> I thought it might be a good idea to develop an applet (and engine) >> for a random purpose, just to get familiar with Plasma, I'm thinking >> about an applet which displays the status from a sabnzbd server >> (http://www.sabnzbd.org). The API of sabnzbd is quite good, so I can >> concentrate at learning Plasma. > > neat, i didn't even know about sabnzbd (and... how the HECK do you pronounce > that?) It's a great project to download nzb's, and, instead of the other common usenet leechers, it's cross-platform. But yes, the name is quite hard to pronounce (I simply say it as I read it (in dutch)). > >> After that, I'm not really sure what to do next. I have seen some >> tasklists (e.g. http://techbase.kde.org/Projects/Plasma/Tasks), maybe >> it's a good idea to pick one of those and see how far I get. But I'm >> not really sure about all of this. > > i really need to update that page again. people keep racing ahead so quickly > that the page needs constant tending. i'm a poor gardener, i'm afraid. > anyways, i'm happy to point you in the direction of "stuff that needs > attention". Well, I wasn't planning on starting to hack away with that page as a reference ;-) As soon as I get closer to the center of Plasma, I would simply ask for things to do. > > something that would be relatively simple but let you play with the "guts" of > plasma a bit is adding a standardized way for plasmoids to show a message to > the user. > > this would probably mean creating a small Plasma::Message class or (even re- > using Plasma::ToolTipContent perhaps?) and allow plasmoids to queue such > messages with the Applet class. the Applet class would then display it in a > "plasma" way (what does that mean? i don't know for sure, but we can work that > out together; perhaps an overlay on the plasmoid itself if it is big enough, > perhaps a tooltip type thing, perhaps a notification in the system tray,...?) Sounds nice to me :) I'll bug you on irc as soon as I feel I can do something like that. > > i have a whole list of such things just waiting to be plucked and fixed ;) > others on this mailing list also have their own pet lists too... Well, that's exactly why I sent the mail. I knew there should be small jobs, but it's quite hard to find such things for a newcomer :) > > and there's also bugs.kde.org which has oodles of feature requests. > >> I have a couple of questions: Is the process which I have in mind a >> good idea? > > i'd say it's a perfect path. > >> Am I too optimistic, because Plasma is too hard > > nah, there's something in there for all skill levels. it was built to be easy > to start hacking on. > >> (as far as >> I've seen, it's quite readable, and it just makes sense). > > thanks =) > >> I know there >> are some mentors for KDE, is there also a mentor for Plasma, or can I >> do the learning process on my own? > > you can do the learning process on your own, but you are *more* than welcome > to ask questions here on the mailing list or in #plasma-devel. the only stupid > question is the unasked question. > >> Feel free to comment on anything I wrote, I sent this mail basically >> on two purposes: To get to know you guys a bit better, and, to be >> honest, I'd like to be a bit in the picture. Maybe someone has a small >> bug which should be easy to fix, and good to learn. > > heh. those ones tend to get fixed fast. we eat bugs for breakfast around here. Well, I'm quite satisfied with my pancakes as breakfast, but well, everyone has his own taste :-P > > here's a really trivial one, though: > > https://bugs.kde.org/show_bug.cgi?id=179563 I looked to it, and it seems quite easy to fix, I already found the file which contains the strings. I don't have a svn-account yet, but I'll try to find someone on IRC who can help me out. Thanks for the friendly mail btw :) I feel like I'm getting a littlebit closer in the team already :) > > most of the others after that one on the plasma bug list probably aren't great > starter jobs. > > welcome to Plasma > > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Software > > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
