Re: [PATCH] Support for PopupApplets in Python
Hello, Luca Beltrame wrote: > as I said, I've been trying to hack in support for PopupApplets in Python. > This patch is a first version of such a thing, which at least enables the > proper binding when used scripted applets. > > It needs some review, as I'm unfamiliar on how PopupApplets work, and if I'm > doing the right thing (still new at these things), especially the Python > bindings people (Simon, which is CCed here). The initializing code is a cut > and copy paste from Applet, just modified to accept extra arguments. > > It works, or seems to work. I haven't been able to test it for real as there > is no clean, simple PopupApplet implementation which I could use as reference. Luca, do you have a simple example of a PopupApplet that I can look at and test with? cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
In data sabato 27 febbraio 2010 12:20:37, Simon Edwards ha scritto: > Luca, do you have a simple example of a PopupApplet that I can look at > and test with? You hit the nail on the head here. The fact is, I can't, as discussed with Richard Dale on IRC. I tried, looking at the code of the various applets (each seems to do things in a slightly different way) to make a popup, but it doesn't seem to work: however, since there is no simple example of a popupapplet around I'm unsure if it's the binding to have problems or if I'm doing something wrong. 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
Using svg/bitmap images in javascript plasmoid
Hi,
has anyone had any luck with using icons in javascript plasmoids?
I would like to include a few transparent buttons in plasmoid that I'm
developing for Jam session.
I tried to use IconWidget, and SvgWidget, but no luck.
IconWidget always displays default icon with a question mark in it, and
SvgWidget doesn't display anything at all.
Any help would be appreciated.
Here is some code snippets that I used:
iw = new IconWidget;
iw.adjustSize(200, 200);
iw.setIcon("play");
layout.addItem(iw);
png and svg versions of play icon are in contents/images folder.
kded4 -v:
Qt: 4.6.2
KDE Development Platform: 4.4.00 (KDE 4.4.0) "release 224"
KDE Daemon: $Id: kded.cpp 1031637 2009-10-05 16:58:19Z lunakl $
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
On Sat, Feb 27, 2010 at 11:33 AM, Luca Beltrame wrote: > In data sabato 27 febbraio 2010 12:20:37, Simon Edwards ha scritto: > >> Luca, do you have a simple example of a PopupApplet that I can look at >> and test with? > > You hit the nail on the head here. The fact is, I can't, as discussed with > Richard Dale on IRC. I tried, looking at the code of the various applets (each > seems to do things in a slightly different way) to make a popup, but it > doesn't seem to work: however, since there is no simple example of a > popupapplet around I'm unsure if it's the binding to have problems or if I'm > doing something wrong. For Ruby I translated the C++ extender tutorial example, but the problem is that it doesn't work in C++. http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders I think the name of the data engine that the example uses has changed. Also the instructions on the CMakeLists.txt content weren't present, and they should be in a tutorial. I also don't understand if Plasma::PopupApplet always use extenders, as in the above tutorial, or whether you normally do something else. It isn't called a 'Plasma Popup Applet tutorial'. The ruby example code is in kdeexamples/plasma/ruby/applets/extendertutorial If it worked it would be quite easy to translate to Python. -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
On Saturday 27 February 2010 14:59:11 Richard Dale wrote: > On Sat, Feb 27, 2010 at 11:33 AM, Luca Beltrame > > wrote: > > In data sabato 27 febbraio 2010 12:20:37, Simon Edwards ha scritto: > >> Luca, do you have a simple example of a PopupApplet that I can look at > >> and test with? > > > > You hit the nail on the head here. The fact is, I can't, as discussed > > with Richard Dale on IRC. I tried, looking at the code of the various > > applets (each seems to do things in a slightly different way) to make a > > popup, but it doesn't seem to work: however, since there is no simple > > example of a popupapplet around I'm unsure if it's the binding to have > > problems or if I'm doing something wrong. > > For Ruby I translated the C++ extender tutorial example, but the > problem is that it doesn't work in C++. > > http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders > > I think the name of the data engine that the example uses has changed. > Also the instructions on the CMakeLists.txt content weren't present, > and they should be in a tutorial. > > I also don't understand if Plasma::PopupApplet always use extenders, > as in the above tutorial, or whether you normally do something else. > It isn't called a 'Plasma Popup Applet tutorial'. > > The ruby example code is in > kdeexamples/plasma/ruby/applets/extendertutorial > > If it worked it would be quite easy to translate to Python. Python popup applet with extenders: http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/applets/pyhello/ Needs hello dataengine: http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/dataengines/pyhello/ Petri 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/PopupApplet and Plasma::PackageStructure
On Sat, Feb 27, 2010 at 2:52 PM, Yuen Hoe Lim wrote:
> While implementing support for PopupApplets in Plasmate (Bug 228498) , I
> discovered that Plasma/PopupApplet is not recognized as a package format by
> Plasma::PackageStructure:
> http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/packagestructure_8cpp_source.html#l00114
>
> Is this a bug or is this intentional? If the latter, then is it acceptable
> to simply do
>
> if (is Plasma/PopupApplet)
My understanding is that scripting applets, popup applets and
containments are all treated the same way and are PlasmoidPackages.
>From scripting/scriptengine.cpp:
PackageStructure::Ptr defaultPackageStructure(ComponentType type)
{
switch (type) {
case AppletComponent:
case DataEngineComponent:
case WallpaperComponent:
case RunnerComponent:
return PackageStructure::Ptr(new PlasmoidPackage());
break;
default:
// TODO: we don't have any special structures for other components yet
break;
}
return PackageStructure::Ptr(new PackageStructure());
}
PackageStructure::Ptr packageStructure(const QString &language,
ComponentType type)
{
KService::List offers = engineOffers(language, type);
if (offers.isEmpty()) {
return defaultPackageStructure(type);
}
KService::Ptr offer = offers.first();
QString packageFormat =
offer->property("X-Plasma-PackageFormat").toString();
if (packageFormat.isEmpty()) {
return defaultPackageStructure(type);
} else {
PackageStructure::Ptr structure = PackageStructure::load(packageFormat);
return structure;
}
}
Note we recently added support for scripting Containments with a
service type of Plasma/Containment in the metadata.desktop
-- Richard
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Copy text to clipboard from javascript plasmoid
Hi, is there a way to copy text to clipboard from javascript plasmoid? In Ruby, that's simple: Qt::Application.clipboard.text = @line_edit.text from: http://salout.github.com/blog/2010/02/07/simple_ruby_plasmoid.html Or it's a job for data engine? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plugins in WebView
are qtwebkit plugins in-process or out of process? IANAPD, but having a flash plugin in a webpage crash all of plasma does not sound like fun times... On Sat, Feb 27, 2010 at 12:55 AM, Aaron J. Seigo wrote: > On February 25, 2010, Mathieu Ducharme wrote: >> - bool pluginsEnabled() >> - void setPluginsEnabled(bool) > > i don't know if we need to / want to offer full access to QWebSettings, but > would a simple(r) setAttribute(QWebSettings::Attribute, bool) do the trick? > the rest of the things in QWebSettings don't look overly useful for the use > cases we have in 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 Development Frameworks > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Work is punishment for failing to procrastinate effectively. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
In data sabato 27 febbraio 2010 15:13:23, Petri Damstén ha scritto: > Python popup applet with extenders: > http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/applets/pyhello/ Thanks, then my patch is completely unnecessary, as the standard __getattr__ method is enough. I'll probably use your example, dissect it a bit , then write a tutorial on Techbase so that things are more clear for people new to applet development (I admit I managed to miss this example...) 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: Plugins in WebView
On February 27, 2010, Gábor Lehel wrote: > are qtwebkit plugins in-process or out of process? IANAPD, but having https://trac.webkit.org/wiki/QtWebKitPlugins -- 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 Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using svg/bitmap images in javascript plasmoid
On February 27, 2010, Nikola Milenković wrote:
> iw.setIcon("play");
this will attempt to load a play icon from the icon theme. there is no such
icon. (there is media-playback-start, however).
otherwise, you'll need to pass in the path to the image in your package, e.g.:
iw.setIcon(new QIcon(plasmoid.file("images", "play.png")))
--
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 Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
On Sat, Feb 27, 2010 at 4:42 PM, Luca Beltrame wrote: > In data sabato 27 febbraio 2010 15:13:23, Petri Damstén ha scritto: >> Python popup applet with extenders: >> http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/applets/pyhello/ > > Thanks, then my patch is completely unnecessary, as the standard __getattr__ > method is enough. > I'll probably use your example, dissect it a bit , then write a tutorial on > Techbase so that things are more clear for people new to applet development (I > admit I managed to miss this example...) But shouldn't there still be Python plasma scripting PopupApplet and Containment classes? Is the C++ instance correctly wrapped as a Plasma::PopupApplet or Plasma::Container, as opposed to a vanilla Plasma::Applet? -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma/PopupApplet and Plasma::PackageStructure
On February 27, 2010, Yuen Hoe Lim wrote:
> if (is Plasma/PopupApplet)
> PackageStructure::load("Plasma/Applet");
as Richard notes, all plasmoids (scripted or not, popup or not) are
Plasma/Applet's. what code is calling PackageStructure::load with
"Plasma/Popup"? note that if ServiceTypes does not include Plasma/Applet as
well as Plasma/PopupApplet that it will not load at all.
so while it probably wouldn't hurt to put in the branch you suggest into
PackageStructure::load(), it would be good to look at the code that is calling
this in the first place and see if it isn't doing something incorrect first.
--
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 Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Copy text to clipboard from javascript plasmoid
On February 27, 2010, Nikola Milenković wrote: > Or it's a job for data engine? either a DataEngine or just a Service. a DataEngine would largely imply keeping the data that's on the clipboard in memory all the time; a Service would allow getting the data only when needed and discarding it immediately. there is a clipboard dataengine in playground but it probably needs some additional work (and it's been there forever :) what might work nicely is a dataengine that advertises the various clipboards available and whether or not they have changed (allowing visualizations to react on clipboard value change), then serviceForSource could return a service that could be used to get the actual data off the clipboard. sounds like something that the pastebin plasmoid could also use :) -- 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 Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Copy text to clipboard from javascript plasmoid
On Saturday 27 February 2010, 13:56 Aaron J. Seigo wrote: > sounds like something that the pastebin plasmoid could also use :) Exactly! I definitely need to find some time to work on the sharebin stuff... Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 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: Plasma/PopupApplet and Plasma::PackageStructure
On February 27, 2010, Yuen Hoe Lim wrote: > Is this a bug or is this intentional? If the latter, then is it acceptable > to simply do looking at your last commit to plasmate, i see why you asked this. all plasmoids should have Plasma/Applet in the ServiceTypes= entry of the .desktop file, since all Plasma/PopupApplets are also Plasma/Applets. it means we have to constantly search for Plasma/PopupApplets to build a complete list of applets, and PopupApplet is just a hint for scripting purposes anyways. right now Plasma::Applet does search for Plasma/PopupApplet as well as Plasma/Applet, so this is worked around pretty thoroughly. but i do wonder if that code should be made to only rely on Plasma/Applet. the only place Plasma/PopupApplet should be needed is in Applet::loadPlasmoid. the danger is that scripted plasmoids that used to work might stop being shown in the applet listings if they just had ServiceTypes=Plasma/PopupApplet. however, the documentation on techbase that mentions this as a possibility does also state that it must include Plasma/Applet. so i'm considering removing the references to Plasma/PopupApplet in Plasma::Applet except for where it is used to actually create the correct base class. Richard: what do you think? -- 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 Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma/PopupApplet and Plasma::PackageStructure
On Sat, Feb 27, 2010 at 5:29 PM, Aaron J. Seigo wrote: > On February 27, 2010, Yuen Hoe Lim wrote: >> Is this a bug or is this intentional? If the latter, then is it acceptable >> to simply do > > looking at your last commit to plasmate, i see why you asked this. all > plasmoids should have Plasma/Applet in the ServiceTypes= entry of the .desktop > file, since all Plasma/PopupApplets are also Plasma/Applets. it means we have > to constantly search for Plasma/PopupApplets to build a complete list of > applets, and PopupApplet is just a hint for scripting purposes anyways. > > right now Plasma::Applet does search for Plasma/PopupApplet as well as > Plasma/Applet, so this is worked around pretty thoroughly. but i do wonder if > that code should be made to only rely on Plasma/Applet. the only place > Plasma/PopupApplet should be needed is in Applet::loadPlasmoid. > > the danger is that scripted plasmoids that used to work might stop being shown > in the applet listings if they just had ServiceTypes=Plasma/PopupApplet. > however, the documentation on techbase that mentions this as a possibility > does also state that it must include Plasma/Applet. > > so i'm considering removing the references to Plasma/PopupApplet in > Plasma::Applet except for where it is used to actually create the correct base > class. Richard: what do you think? Yes, I think that might be a good idea as there is quite a bit of special casing. We should be adding support for Plasma/Containment scripting plasmoids in all the queries too, and if all Containments were always Plasma/Applets too we wouldn't need to do that. There is also special casing in plasmapkg for Popups and Containments to work round the problem with them not being Plasm/Applet service types. I haven't added special casing for Containments in all the places were applets are listed yet. I wasn't quite sure if they were something the end user should see, or whether they were going to be some kind of 'internal' system programming feature. I don't think all the special casing is a great problem if the Plasma::Applet scripting family is going to stay as it is for the forseeable future with just Popups and Containments. But if we were to start having more of them I think it would be right to always make sure they are Plasm/Applet service types. As it stands I don't mind much one way or another - it is a bit messy, but not that messy. While I think about it the project type selector in Plasmate is different from how the KDevelop or KAppTemplate ones work. In those you decide what language you want to use, and then under each language you have a heirarchy of projects types. With Plasmate, you have a selection of project types, and they under those you have options for the various languages. Until recently that hasn't made much difference, but I think the more types of scripting applets we have the more confusing it will be not to have programming language at the top of the selection heirarchy. -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
GSoC Proposal - basKet KDE SC 4 port
Hello everyone, A few weeks ago, I wrote a blog post detailing an idea of mine to port KDE SC 3's basKet note taking application to KDE SC 4, and in the process taking advantage of the various technologies that have evolved since basKet's last official release.[1] Recently, I've begun work on this application on gitorious[2], and am interested in applying for GSoC to work on this with a mentor from kde- pim and a mentor from plasma. Currently the code does little more than spawn a plasma desktop containment in a window, but work continues :) Possible goals for the end of summer: - Notes application with various specially designed plasma applets that allow users to save notes of text, html, and various multimedia. Recycle currently implemented plasma applets when possible - Notes applets for interfacing with kde-pim. For example, show contacts from a group associated with the applet, or events from a similar category. - Drag and drop any file to include a link or embed of it. - Import files from KJots, basKet and KNotes. - Possibly nepomuk and strigi integration for searching and tagging of the basKet files. (may be for after GSoC) What are everyone's thoughts on such a project? Best Regards, Ryan Rix [1]: http://hackersramblings.wordpress.com/2010/02/05/basket-is-dead-long- live-basket/ [2]: http://gitorious.org/mudkipz/mudkipz -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == 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: Copy text to clipboard from javascript plasmoid
On Sat, Feb 27, 2010 at 5:56 PM, Aaron J. Seigo wrote: > On February 27, 2010, Nikola Milenković wrote: > > Or it's a job for data engine? > > either a DataEngine or just a Service. > > a DataEngine would largely imply keeping the data that's on the clipboard > in > memory all the time; a Service would allow getting the data only when > needed > and discarding it immediately. > > there is a clipboard dataengine in playground but it probably needs some > additional work (and it's been there forever :) > Could you give me an example how to use this clipboard data engine to put string into clipboard? I installed it, but it doesn't provide any data source. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
n+1st report about arrow keys in krunner
Dear plasmoids I just closed as WONTFIX the (n+1)st report about people trying to use downarrow key to select entries other than the first one in krunner default interface. In view of our committment to polish for 4.5 I guess it's time to do something about this issue, which seems to hit quite a number of users. The problem: Krunner sports a command history feature similar to the konsole history, available by the uparrow and downarrow keys. The default interface shows results as a vertical list; this list can be browsed with the arrow keys once it has been focused (by pressing the TAB key). This focusing step is the one most users miss. The confusion is probably made stronger by the fact that both the lineedit and the first entry are (virtually) focused at the same time, so one can reasonably expect the arrow keys to act on the result list instead that on the lineedit Finding a consistent solution is not that simple, therefore I'd like to collect some proposals here, in order to have some time for testing during the .5 development cycle. I report here a proposal by kdepepo (from the latest bugreport) along with my comment about it: If (and only if) pressing Down without any further entry in the history, then it could move the focus to the first entry in the list. The first entry is already focused, we should probably rather move to the second one; Once the second one has been focused, what happens if i hit Up? should I return focus to the lineedit? This would basically bind focus on the first item with focus of the lineedit. Would this actually work? Awaiting for your comments and further proposals! Thanks a lot __J ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using svg/bitmap images in javascript plasmoid
Thanks.
iw.setIcon("media-playback-start") works.
If I understood correctly from JavaScript API reference, I need to upgrade
KDE to 4.4.1 in order to use QIcon?
Now I receive error message: Cannot find QIcon.
On Sat, Feb 27, 2010 at 5:47 PM, Aaron J. Seigo wrote:
> On February 27, 2010, Nikola Milenković wrote:
> > iw.setIcon("play");
>
> this will attempt to load a play icon from the icon theme. there is no such
> icon. (there is media-playback-start, however).
>
> otherwise, you'll need to pass in the path to the image in your package,
> e.g.:
>
> iw.setIcon(new QIcon(plasmoid.file("images", "play.png")))
>
> --
> 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 Development Frameworks
> ___
> 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
Re: n+1st report about arrow keys in krunner
I have been annoyed many times by this, although I never reported a bug. I also found it confusing to have autocompletion, but I still have to type it through. I suggest that the history should be added as just another runner. It would show the last N used things when started, and then display a filtered list when you write something. I don't know the architecture though, is it possible to remember the last actions instead of what you typed? 2010/2/27 Jacopo De Simoi > Dear plasmoids > I just closed as WONTFIX the (n+1)st report about people trying to use > downarrow key to select entries other than the first one in krunner default > interface. In view of our committment to polish for 4.5 I guess it's time to > do something about this issue, which seems to hit quite a number of users. > > The problem: > Krunner sports a command history feature similar to the konsole history, > available by the uparrow and downarrow keys. > The default interface shows results as a vertical list; this list can be > browsed with the arrow keys once it has been focused (by pressing the TAB > key). This focusing step is the one most users miss. > The confusion is probably made stronger by the fact that both the lineedit > and the first entry are (virtually) focused at the same time, so one can > reasonably expect the arrow keys to act on the result list instead that on > the lineedit > > Finding a consistent solution is not that simple, therefore I'd like to > collect some proposals here, in order to have some time for testing during > the .5 development cycle. > > I report here a proposal by kdepepo (from the latest bugreport) along with > my comment about it: > > If (and only if) pressing Down without any further entry in the history, > then > it could move the focus to the first entry in the list. > > The first entry is already focused, we should probably rather move to the > second one; > Once the second one has been focused, what happens if i hit Up? should I > return focus to the lineedit? > This would basically bind focus on the first item with focus of the > lineedit. Would this actually work? > > Awaiting for your comments and further proposals! > Thanks a lot > > __J > > > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Lenoba je mati Modrosti. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: n+1st report about arrow keys in krunner
> I have been annoyed many times by this, although I never reported a bug. I > also found it confusing to have autocompletion, but I still have to type it > through. you can use the End key to accept the completion; this is another active topic about krunner on bko, by the way. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC Proposal - basKet KDE SC 4 port
On Sat 27 February 2010 2:03:15 pm Ryan Rix wrote: > A few weeks ago, I wrote a blog post detailing an idea of mine to port KDE > SC 3's basKet note taking application to KDE SC 4, and in the process > taking advantage of the various technologies that have evolved since > basKet's last official release.[1] Foot-in-mouth syndrome hits me full in the face, yet again... Turns out that BasKet is still under development and close to a release even, lol. -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == 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
