Re: Solidrunner moved to kdereview
On Friday 13 November 2009 20:06:48 Burkhard Lück wrote: > Am Freitag, 13. novembre 2009 19:33:57 schrieb Jacopo De Simoi: > > > > Please let me know of any issues that you find > > There are some i18n calls, but the runner has no translation catalog, message > extraction via Messages.sh is missing. Fixed, thanks --J > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On November 13, 2009, Celeste Lyn Paul wrote: > This isn't a new discussion wrt Kubuntu and we've more than "suddenly > noticed". This is the third? time we've submitted the patch with our > arguments for changes. One, it is part of our process since we don't > want to deviate from upstream as much as possible, and Two, we really > do think this patch is an improvement. We are free to defend it and > you are free to ignore it as usual. as a suggestion: resubmitting the same patches with the same rational after it's already been discussed and rejected is probably not overly useful. in fact, it's frustrating. sending new patches upstream is useful. sending old patches with new approaches in the code or new information can be. -- 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 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: Solidrunner moved to kdereview
Am Freitag, 13. novembre 2009 19:33:57 schrieb Jacopo De Simoi: > > Please let me know of any issues that you find There are some i18n calls, but the runner has no translation catalog, message extraction via Messages.sh is missing. -- Burkhard Lück ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Fri, Nov 13, 2009 at 1:50 PM, Aaron J. Seigo wrote: > On November 13, 2009, Celeste Lyn Paul wrote: >> In some cases you have some text that is always on, some text that is >> only on via mouseover, and some text that is never on (not all entries >> have subtext, e.g. System Settings). This behavior is inconsistent and >> confusing in addition to some of these problems: > > the behaviour is not meant to be consistent in terms of "does it paint the > same way every time". it's meant to be consistent in terms of "provides the > necessary information to the user without overloading the display". as for > confusing, it's only confusing if you try and figure out why we've done it the > way we've done it (reverse engineering the design); i have yet to hear from an > actually confused user (versus a user trying to pick out issues because they > are playing "clever critic") though we used to hear all the time from them > before the disambiguation. > >> * When you have some items with subtext on by default (such as when >> you have multiple browsers installed), there is less of an affordance >> to check for the subtext hints because some are already visible, so >> why would you keep looking? > > i'm not sure why that would matter in the least. it also becomes very evident > that they normally show on hover, and that hover information is not > particularly useful when there's just one "Do Foo" app anyways. your > assumption here is that, in the common case where there is no overlap between > application generic names, that the subtext is the important bit. if it is, > then let's switch to application names first as the default. i'm not sure > "KTorrent", "KsCD", etc. is really the most user friendly approach however. > >> * When some labels are on by default but others appear on mouseover, >> it looks like a bug before you figure out the "disambiguity" pattern > > but it's not a bug; i'm all for making things as "immediately sensible" as > possible until the "immediately sensible" causes problems for others. in this > case, it solves a real problem our users were really facing and if others > puzzle over that, well, that's just unfortunate. nobody's hurt, and those who > need it (who happen to be most people confronted with three "Web Browser" > entries) are helped. > > in fact, i bet if we didn't do this that we'd be hearing from you about the > three "Web Browser" entry situation. > >> * Subtext on mouseover requires the user to read with their mouse >> which is awkward and unnatural, nevermind impossible on touch >> interfaces and adds burden to those using a keyboard instead of a >> mouse for accessibility reasons. > > the subtext, except in the case of needing disambiguation, is not critical to > making a decision. so you don't need to mouse over. unless we didn't show the > disambiguations. then we'd have a problem. > >> * For the task-based labels, mouseover subtext make it more difficult >> for users to find applications by name -- which does happen. People >> get recommendations for installing "Marble" not "Desktop Globe". It >> only supports a single use case. > > thankfully we offer search first and foremost. we also found that clusters of > mysteriously named applications like "Marble" are less useful to people than > "Desktop Globe", and that when people are told about marble they are told it's > "mapping software" or "a desktop globe". > > when looking for specific items, menu hierarchies generally suck no matter > what the strategy, though some strategies are better than others. we are > promoting search, with the menu as a way to explore what's available or to go > to items you already know or can guess the location of. and in those cases the > functionality is usually more important than the name of the binary on disk. > >> * For the application-based labels, if you are unfamiliar with the >> names or branding, you *must* read with your mouse. > > that's why we default to generic names. application labels are for people who > know what they are doing. > >> * When there are no labels, or the labels are not visible, the primary >> label looks disproportionately small compared to the icon because a >> space must be made for the subtext. > > and yet when you mouse over it becomes evident. if you would like to provide a > artist's mockup of a different layout that fulfills the needs outlined here, > please feel free to do so. it's easy to jab at the current layout until you > actually try and make something better. > >> I just don't see any compelling reasons why the subtext should be >> turned off. "Unclutter" the interface doesnt work for me; if the >> subtext is "clutter" then the labels are bad and should be improved or >> it is noise and shouldnt be there at all. > > "unclutter" does work for me, since it looks horrific with dense bodies of > text everywhere. you may not agree with that aesthetic, but it's the aesthetic > that's been chosen. we can argue it and the relative merits of Dali versus
Re: can qtscript plasmoids load C++ qtscript plugins
On November 12, 2009, Pekka Reijula wrote: > Our idea allows creation of plasmoids that have qtscript inside to your own > plama desktop environment. We can extend plasma in a way that allows user > to write own script with for example Kate or download it from http url. > The basic idea is that only text is read and script is evaluated. All that > you need for this is the qtscript-bindings that for example amarok uses. the question is this: do these plasmoids need the full Qt API? if so, then they are inherently untrustable from a security perspective, though that's not necessarily a bad thing. it just means that you don't want to be loading these things from people and places you don't implicitly trust. it would also mean that you are looking for Smoke bindings that Richard mentioned. if there is specific API in addition to the 'standard' Simplified JavaScript API currently provided in the javascript AppletScriptEngine, then if that specific API is offered as a QScriptEngine extension, it can be loaded given enough permission/trust is bestowed on that plasmoid (e.g. by a valid gpg signature that is trusted by the user). the other day i added support for two properties in the .desktop metadata file of a plasmoid: X-Plasma-RequiredExtensions and X-Plasma-OptionalExtensions these are both string lists and can be used to load QScriptEngine extensions upon request. a security sandbox is being established around this mechanism, so it should be reasonably safe. > I could upload the plasmoid > sources to kde, but I'm not yet a plasma developer. if you get a kde svn account you can upload them to playground quite easily: http://techbase.kde.org/Contribute/Get_a_SVN_Account -- 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 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: kubuntu kdebase patches to plasma
On November 13, 2009, Celeste Lyn Paul wrote: > In some cases you have some text that is always on, some text that is > only on via mouseover, and some text that is never on (not all entries > have subtext, e.g. System Settings). This behavior is inconsistent and > confusing in addition to some of these problems: the behaviour is not meant to be consistent in terms of "does it paint the same way every time". it's meant to be consistent in terms of "provides the necessary information to the user without overloading the display". as for confusing, it's only confusing if you try and figure out why we've done it the way we've done it (reverse engineering the design); i have yet to hear from an actually confused user (versus a user trying to pick out issues because they are playing "clever critic") though we used to hear all the time from them before the disambiguation. > * When you have some items with subtext on by default (such as when > you have multiple browsers installed), there is less of an affordance > to check for the subtext hints because some are already visible, so > why would you keep looking? i'm not sure why that would matter in the least. it also becomes very evident that they normally show on hover, and that hover information is not particularly useful when there's just one "Do Foo" app anyways. your assumption here is that, in the common case where there is no overlap between application generic names, that the subtext is the important bit. if it is, then let's switch to application names first as the default. i'm not sure "KTorrent", "KsCD", etc. is really the most user friendly approach however. > * When some labels are on by default but others appear on mouseover, > it looks like a bug before you figure out the "disambiguity" pattern but it's not a bug; i'm all for making things as "immediately sensible" as possible until the "immediately sensible" causes problems for others. in this case, it solves a real problem our users were really facing and if others puzzle over that, well, that's just unfortunate. nobody's hurt, and those who need it (who happen to be most people confronted with three "Web Browser" entries) are helped. in fact, i bet if we didn't do this that we'd be hearing from you about the three "Web Browser" entry situation. > * Subtext on mouseover requires the user to read with their mouse > which is awkward and unnatural, nevermind impossible on touch > interfaces and adds burden to those using a keyboard instead of a > mouse for accessibility reasons. the subtext, except in the case of needing disambiguation, is not critical to making a decision. so you don't need to mouse over. unless we didn't show the disambiguations. then we'd have a problem. > * For the task-based labels, mouseover subtext make it more difficult > for users to find applications by name -- which does happen. People > get recommendations for installing "Marble" not "Desktop Globe". It > only supports a single use case. thankfully we offer search first and foremost. we also found that clusters of mysteriously named applications like "Marble" are less useful to people than "Desktop Globe", and that when people are told about marble they are told it's "mapping software" or "a desktop globe". when looking for specific items, menu hierarchies generally suck no matter what the strategy, though some strategies are better than others. we are promoting search, with the menu as a way to explore what's available or to go to items you already know or can guess the location of. and in those cases the functionality is usually more important than the name of the binary on disk. > * For the application-based labels, if you are unfamiliar with the > names or branding, you *must* read with your mouse. that's why we default to generic names. application labels are for people who know what they are doing. > * When there are no labels, or the labels are not visible, the primary > label looks disproportionately small compared to the icon because a > space must be made for the subtext. and yet when you mouse over it becomes evident. if you would like to provide a artist's mockup of a different layout that fulfills the needs outlined here, please feel free to do so. it's easy to jab at the current layout until you actually try and make something better. > I just don't see any compelling reasons why the subtext should be > turned off. "Unclutter" the interface doesnt work for me; if the > subtext is "clutter" then the labels are bad and should be improved or > it is noise and shouldnt be there at all. "unclutter" does work for me, since it looks horrific with dense bodies of text everywhere. you may not agree with that aesthetic, but it's the aesthetic that's been chosen. we can argue it and the relative merits of Dali versus Escher over a glass of wine sometime. the subtext is clutter only when it's shown all the time for all entries. the subtext is an aid to the user who w
Re: Webslice applet moved to kdereview
On Friday 13 November 2009 18:20:33 Albert Astals Cid wrote:
> A Divendres, 13 de novembre de 2009, Sebastian Kügler va escriure:
> > Hey,
> >
> > I've just moved the webslice plasmoid to kdereview, for inclusion in KDE
> > 4.4.
> >
> > The webslice applet is there to put an interactive part of a webpage onto
> > Plasma as an applet.
> >
> > You can specify an element with a CSS selector (a.k.a. the nice way) or
> > by its geometry (the way that works for semantically-not-so-nice
> > webpages, but can easily break). This can be handy if you want to monitor
> > only the news box on a webpage, for example.
> >
> > The webslice widget uses Qt WebKit for rendering the element and is fully
> > interactive. I'm planning to make use of the KDE integration soon that
> > has just entered kdelibs, so we also share cookies and login information.
> >
> > There are two widgets coming along with this. First, a
> > SliceGraphicsWidget which is used inside the plasmoid, and a QWidget,
> > which basically wraps the SliceGraphicsWidget. Those are possible
> > candidates for inclusion into kdelibs, if other developers want to use
> > this as well. If you use the qmake-based build, you get a small binary
> > you can play around with.
> > The webslice plasmoid has been written by Richard Moore and me with the
> > help of some of the qtwebkit guys and is another early part of Silk we'd
> > like to see merged.
>
> Where do you plan to move it?
kdeplasma-addons, unless someone wants to see it somewhere else.
> > Please let me know if there's anything wrong with it, or where you see
> > room for improvement and I'll address it.
>
> i18n("%1,%2,%3,%4", ) is a bit difficult to translate, some context
> won't hurt
>
> frame->setHtml("Loading ..."); needs i18n and probably some
> context to tell what is loading.
>
> The first configuration page layout is broken, if maximixed, i lost a
> paragraph of explanation text.
Thanks for reviewing, I'll fix those (and the one you mentioned on IRC).
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
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
Solidrunner moved to kdereview
I've just moved a the solidrunner to kdereview, for inclusion in 4.4 in kde-plasma-addons or kdebase; I'm actually not quite sure on that. The runner is conceived as an alternative to the device notifier, combining the same capabilities (although the actions support is still lacking for the default interface in krunner, I've already a working draft in local which will soon be posted to the reviewboard) with the usual keyboard-oriented way of dealing with stuff which is peculiar to krunner. The runner features three syntaxes: device: show all devices mount: show all devices that can be mounted unmount: show alll devices that can be unmounted Since i believe that people using krunner are more CLI-oriented than the average, the default action is mount/unmount/eject; actions provided by solid actions will are exposed as actions; It is also a perfect candidate for the single runner query mode (right now the relevant part has been commented to allow compilation); Please let me know of any issues that you find Thanks a lot --J ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Fri, Nov 13, 2009 at 10:27 AM, Marco Martin wrote: > On Friday 13 November 2009, Celeste Lyn Paul wrote: >> On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: >> > On November 12, 2009, Jonathan Riddell wrote: >> >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff >> >> sometimes show always and sometimes on mouse over, this makes that >> >> consistent. It's been discussed here before. >> >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ >> >>ann >> >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff >> > >> > this patch is, usability-wise, wrong. the subtexts are shown when >> > disambiguation is necessary. otherwise you need to mouse over them to >> > figure out what's what. >> >> I'm not sure what you mean. Are you suggesting only showing the >> subtext when there are multiple applications and not for any other >> applications? And do you mean on by default or mouseover (your comment >> is ambiguous)? > > I suppose the behaviour it has now. > -show only the main text, that is the generic name > -show the subtext (the app name) on mouse over > -if there are two entries with the same generic name always show the subtext, > to disambiguare between the two In some cases you have some text that is always on, some text that is only on via mouseover, and some text that is never on (not all entries have subtext, e.g. System Settings). This behavior is inconsistent and confusing in addition to some of these problems: * When you have some items with subtext on by default (such as when you have multiple browsers installed), there is less of an affordance to check for the subtext hints because some are already visible, so why would you keep looking? * When some labels are on by default but others appear on mouseover, it looks like a bug before you figure out the "disambiguity" pattern * Subtext on mouseover requires the user to read with their mouse which is awkward and unnatural, nevermind impossible on touch interfaces and adds burden to those using a keyboard instead of a mouse for accessibility reasons. * For the task-based labels, mouseover subtext make it more difficult for users to find applications by name -- which does happen. People get recommendations for installing "Marble" not "Desktop Globe". It only supports a single use case. * For the application-based labels, if you are unfamiliar with the names or branding, you *must* read with your mouse. * When there are no labels, or the labels are not visible, the primary label looks disproportionately small compared to the icon because a space must be made for the subtext. I just don't see any compelling reasons why the subtext should be turned off. "Unclutter" the interface doesnt work for me; if the subtext is "clutter" then the labels are bad and should be improved or it is noise and shouldnt be there at all. > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Friday 13 November 2009, Celeste Lyn Paul wrote: > On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: > > On November 12, 2009, Jonathan Riddell wrote: > >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff > >> sometimes show always and sometimes on mouse over, this makes that > >> consistent. It's been discussed here before. > >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ > >>ann > >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff > > > > this patch is, usability-wise, wrong. the subtexts are shown when > > disambiguation is necessary. otherwise you need to mouse over them to > > figure out what's what. > > I'm not sure what you mean. Are you suggesting only showing the > subtext when there are multiple applications and not for any other > applications? And do you mean on by default or mouseover (your comment > is ambiguous)? I suppose the behaviour it has now. -show only the main text, that is the generic name -show the subtext (the app name) on mouse over -if there are two entries with the same generic name always show the subtext, to disambiguare between the two Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Thu, Nov 12, 2009 at 11:04 PM, Aaron J. Seigo wrote: > On November 12, 2009, Jonathan Riddell wrote: >> kubuntu_19_always_show_kickoff_subtext.diff, the subtexts in kickoff >> sometimes show always and sometimes on mouse over, this makes that >> consistent. It's been discussed here before. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_19_always_show_kickoff_subtext.diff > > this patch is, usability-wise, wrong. the subtexts are shown when > disambiguation is necessary. otherwise you need to mouse over them to figure > out what's what. I'm not sure what you mean. Are you suggesting only showing the subtext when there are multiple applications and not for any other applications? And do you mean on by default or mouseover (your comment is ambiguous)? >> kubuntu_71_default_plasma_layout.diff has our changes to the default >> layout. We used to do this with a config file override but that was >> unreliable. It adds the microblog applet to the desktop (social from the >> start, all the rage). It adds quickaccess, showdesktop, networkmanagement >> and our indicatordisplay applets to the panel. The clock shows the date >> by default, because I like to know what day it is. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_71_default_plasma_layout.diff > > in 4.4 and beyond, you should use a plasma-desktop javascript for this. all > the flexibility you could ever want and then some, and you won't need to carry > a patch. see the docs in kdebase/workspace/plasma/design/plasma-desktop- > scripting and the examples in kdeexamples. > >> kubuntu_91_plasma_autostart_condition.desktop is added so we can stop >> plasma-desktop being run for netbook edition. It would be good to >> find a better way to select between plasma-desktop and plasma-netbook, >> preferably as an X session at KDM. >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_91_plasma_autostart_condition.desktop > > marco recently implemented this for 4.4. marco can elaborate. > >> kubuntu_101_brightness_fn_keys_and_osd.diff adds a brightness on >> screen widget for brightness keys, it also needs patches to Qt and >> kdelibs to work >> http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/ann >> otate/head%3A/debian/patches/kubuntu_101_brightness_fn_keys_and_osd.diff > > if the patch is upstreamed in Qt, we can take a look at this one more closely. > > -- > 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 > > -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Webslice applet moved to kdereview
On Fri, Nov 13, 2009 at 12:58 PM, Marco Martin wrote: > it would probably add too much complexity to all webviews with no gain... > but what about Plasma::WebView::setSlice() and making webview itself manage > slices? In future we might want to add more stuff to the slices, eg. changing the way focus etc. is handled. I'm not sure we could do this cleanly if it was integrated into Plasma::WebView without making the code there more complex. Rich. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Webslice applet moved to kdereview
On Friday 13 November 2009, Aaron J. Seigo wrote: > On November 12, 2009, Kenneth Christiansen wrote: > > Plasma widgets are by default GraphicsItems right? So what about > > Plasma::WebSlice? and then call the QWidget for KWebSlide? > > +1 on Plasma::WebSlice if it goes into libplasma; otherwise > KGraphicsWebSliceWidget to go the route of the Qt naming of > QGraphics[Item|Widget] > it would probably add too much complexity to all webviews with no gain... but what about Plasma::WebView::setSlice() and making webview itself manage slices? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Webslice applet moved to kdereview
Thanks all for the feedback so far, I'll make the changes in the coming days. On Friday 13 November 2009 01:51:53 Sebastian Kügler wrote: > Hey, > > I've just moved the webslice plasmoid to kdereview, for inclusion in KDE > 4.4. > > The webslice applet is there to put an interactive part of a webpage onto > Plasma as an applet. > > You can specify an element with a CSS selector (a.k.a. the nice way) or by > its geometry (the way that works for semantically-not-so-nice webpages, > but can easily break). This can be handy if you want to monitor only the > news box on a webpage, for example. > > The webslice widget uses Qt WebKit for rendering the element and is fully > interactive. I'm planning to make use of the KDE integration soon that has > just entered kdelibs, so we also share cookies and login information. > > There are two widgets coming along with this. First, a SliceGraphicsWidget > which is used inside the plasmoid, and a QWidget, which basically wraps > the SliceGraphicsWidget. Those are possible candidates for inclusion into > kdelibs, if other developers want to use this as well. If you use the > qmake-based build, you get a small binary you can play around with. > > The webslice plasmoid has been written by Richard Moore and me with the > help of some of the qtwebkit guys and is another early part of Silk we'd > like to see merged. > > Please let me know if there's anything wrong with it, or where you see room > for improvement and I'll address it. > > Thanks, > -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: can qtscript plasmoids load C++ qtscript plugins
On Fri, Nov 13, 2009 at 12:16 PM, Artur Souza (MoRpHeUz) wrote: > Hey Richard! > > On Friday 13 November 2009, 07:44 Richard Dale wrote: >> The QtScript bindings based on the language indpendent Smoke libraries >> are going well, and I'm not far short of being able to wrap the Plasma >> apis. > > Just one question: when this is done, we'll be able to "drop" the bindings we > currently have on kdebase/runtime/plasma/scriptengine/javascript/ ? No I don't thnk so, I think we want a simple javascript api as well as a full C++-like api, and possible another security oriented/sandboxed javascript api too sometime. > And this > bindings are just for KDE stuff or you plan to use them for Qt stuff too ? They will work fine for any apis that have smoke libs - so both Qt and KDE apis. I don't think they are aimied at scripting C++ apps though, like the Qt Labs bindings can as they use the standard QtScript mechanism for wrapping QObjects. The Smoke based bindings wrap QObjects differently. -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: can qtscript plasmoids load C++ qtscript plugins
Hey Richard! On Friday 13 November 2009, 07:44 Richard Dale wrote: > The QtScript bindings based on the language indpendent Smoke libraries > are going well, and I'm not far short of being able to wrap the Plasma > apis. Just one question: when this is done, we'll be able to "drop" the bindings we currently have on kdebase/runtime/plasma/scriptengine/javascript/ ? And this bindings are just for KDE stuff or you plan to use them for Qt stuff too ? 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: can qtscript plasmoids load C++ qtscript plugins
Hi Pekka, On Friday 13 November 2009, 04:32 Pekka Reijula wrote: > Our idea allows creation of plasmoids that have qtscript inside to your own > plama desktop environment. We can extend plasma in a way that allows user > to write own script with for example Kate or download it from http url. > The basic idea is that only text is read and script is evaluated. All that > you need for this is the qtscript-bindings that for example amarok uses. Maybe I'm not getting what you meant: this is already possible. Plasma supports javascript/qtscript plasmoids. If you put them somewhere like kde-apps.org you will also be able to download them. So, what exactly is your point about "enabling plasma" to run script plasmoids ? So, maybe I just didn't get what you mean :) Can you explain a little bit more ? > What this could offer, would be pretty much the same that the Qt-lively > project offers in here: http://lively.cs.tut.fi/qt/videos.html > All the widgets can be run also in our system. If you mean running "qt lively" scripts on plasma, then we have two options: if they are "pure" javascript or qtscript ones it should work out of the box of even just need some really small work. If they are special in any way, then we should just create a qt lively scriptengine and it will work perfectly (just like we did with google gadgets, edje and OSX). > What do you deveopers think? Should plasma be able add these kind of > widgets. Or should it be better to just create plasmoid that enables > importing this kind of functionality inside. I could upload the plasmoid > sources to kde, but I'm not yet a plasma developer. Well, it should be pretty easy to be a plasma/kde developer ;P. But anyway I think that we are closer than you think to support qt lively widgets on plasma. Maybe it already works with just a little amount of work. And as I'm on my creative Friday, maybe I can end the day making this thing work ;) But first I need to understand what I asked above and have access to this widgets. 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: can qtscript plasmoids load C++ qtscript plugins
On Fri, Nov 13, 2009 at 7:32 AM, Pekka Reijula wrote: > On Monday 09 November 2009, Ian Monroe wrote: >> I suspect the answer to the subject is "no" since I haven't found a >> mention of a method to do it. But I also haven't found comprehensive >> QtScript API docs. :) > QtScript apidocs are generated in Qt labs project qtscriptgenerator. > >> My situation is that I want to write a full chat solution in a >> qtscript plasmoid using the QtScript Telepathy bindings I wrote. (I'm >> guessing a dataengine or service for buddy presence and chatting would >> be pretty crazy right?) > > We have created couple of soulutions where this kind of importing bindings > is possible, so I'm more than a willing to start a discussion how to proceed > with this kind of ideas in plasma. > > Our idea allows creation of plasmoids that have qtscript inside to your own > plama desktop environment. We can extend plasma in a way that allows user to > write own script with for example Kate or download it from http url. The > basic idea is that only text is read and script is evaluated. All that you > need for this is the qtscript-bindings that for example amarok uses. > > What this could offer, would be pretty much the same that the Qt-lively > project offers in here: http://lively.cs.tut.fi/qt/videos.html > All the widgets can be run also in our system. > What do you deveopers think? Should plasma be able add these kind of > widgets. Or should it be better to just create plasmoid that enables > importing this kind of functionality inside. I could upload the plasmoid > sources to kde, but I'm not yet a plasma developer. The QtScript bindings based on the language indpendent Smoke libraries are going well, and I'm not far short of being able to wrap the Plasma apis. http://gitorious.org/qtscript-smoke/qtscript-smoke The following items need to be implemented:before we can start on Plasma support: * Add a thread to periodically sweep the hash of C++ pointers to QtScript instances, and delete any entries where 'isValid()' is no longer true * Split the bindings up so that there is one QtScript plugin per smoke library * Rename the project 'JSmoke' (well that's my suggestion for a more catchy name anyway) The smoke bindings have a much lower memory footprint and are faster than the Qt Labs ones. The api is very similar with only minor differences. Nearly all the Qt Labs QtScript examples now run fine under the Smoke based version. I think these bindings would be the most suitable for Ian's telepathy client, although we would need to implement support for writing plugins in QtScript. -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kubuntu kdebase patches to plasma
On Friday 13 November 2009 05:04:32 Aaron J. Seigo wrote: > > kubuntu_101_brightness_fn_keys_and_osd.diff adds a brightness on > > screen widget for brightness keys, it also needs patches to Qt and > > kdelibs to work > > http://bazaar.launchpad.net/%7Ekubuntu-members/kdebase-workspace/ubuntu/a > >nn > > otate/head%3A/debian/patches/kubuntu_101_brightness_fn_keys_and_osd.diff > > if the patch is upstreamed in Qt, we can take a look at this one more > closely. Does this also fix the "we don't get notifications from HAL about brightness changes"-problem? I've been working around this in the battery applet for some time now, it only updates the brightness slider when the applet pops up. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Kde-silk] Webslice applet moved to kdereview
On Friday 13 November 2009, Sebastian Kügler wrote: > Hey, > > I've just moved the webslice plasmoid to kdereview, for inclusion in KDE > 4.4. > > The webslice applet is there to put an interactive part of a webpage onto > Plasma as an applet. > > You can specify an element with a CSS selector (a.k.a. the nice way) or by > its geometry (the way that works for semantically-not-so-nice webpages, > but can easily break). This can be handy if you want to monitor only the > news box on a webpage, for example. > > The webslice widget uses Qt WebKit for rendering the element and is fully > interactive. I'm planning to make use of the KDE integration soon that has > just entered kdelibs, so we also share cookies and login information. > > There are two widgets coming along with this. First, a SliceGraphicsWidget > which is used inside the plasmoid, and a QWidget, which basically wraps > the SliceGraphicsWidget. Those are possible candidates for inclusion into > kdelibs, if other developers want to use this as well. If you use the > qmake-based build, you get a small binary you can play around with. > > The webslice plasmoid has been written by Richard Moore and me with the > help of some of the qtwebkit guys and is another early part of Silk we'd > like to see merged. > > Please let me know if there's anything wrong with it, or where you see room > for improvement and I'll address it. > > Thanks, > apart from the widget naming already addressed seems fine to me. just wondering, couldn't slicegraphicswidget directly inherit qgraphicswebwidget? or was it important to hide the qgraphicswebwidget api to not pollute the final api? for the plasmoid, just a thing and then it's rocking: setAssociatedApplicationUrls() to the url of the page from where the slice is ttaken from and it's perfect. In the future it could even check if there is a selkie plugin registered for that page and launch that instead in this case (we would need a setAssociatedApplicationParameters() too probably) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
