Re: Review Request: Allow to choose between ascending and descending icon sort order in folderview

2012-02-09 Thread Aaron J. Seigo 
On Monday, February 6, 2012 14:44:25 Ignat Semenov wrote:
> Marco Martin wrote:
> > On Mon, Feb 6, 2012 at 9:22 AM, Ignat Semenov 
> > 
> > wrote:
> >> Hello fellow plasma devs!
> >> 
> >> This change, while trivial, contains 2 strings, "Ascending" and
> >> "Desending". I've found out that the very same strings already exist in
> >> Dolphin, which lives in the same module as plasma-applet-folderview, kde-
> >> baseapps. Does that mean that this commit can be backported to 4.8?
> > 
> > well, regardless of the strings, that's a feature, so i would prefer it
> > 4.9 only
> 
> Hello Marco,
> 
> In the case that I won't backport the change, will I be able to backport
> later commits using git cherry-pick correctly? Does Git use the diffs for
> cherry-picking?

it uses the diff of the current change; it doesn't need to replay all changes 
in between. of course, if a change touches code that this commit changes, then 
that change will need to be manually merged back. but generally git makes this 
as easy as it can be.

> Another one is, of course, that this useful feature will have a
> longer lifetime and more users :)

we could say that about every feature :)

-- 
Aaron J. Seigo

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: Review Request: Allow to choose between ascending and descending icon sort order in folderview

2012-02-09 Thread Aaron J. Seigo 
On Monday, February 6, 2012 12:22:01 you wrote:
> Hello fellow plasma devs!
> 
> This change, while trivial, contains 2 strings, "Ascending" and
> "Desending". I've found out that the very same strings already exist in
> Dolphin, which lives in the same module as plasma-applet-folderview, kde-
> baseapps. Does that mean that this commit can be backported to 4.8?

no; it's not a bug fix and it doesn introduce new strings to this translated 
item (which is not as bad as it could be as you note the strings exist in 
other translatable binaries in the same moulde .. still ..)

cheers ...

-- 
Aaron J. Seigo

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: Review Request: make UNC path work in krunner by mapping it to smb:// path

2012-02-09 Thread Aaron J. Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103826/#review10472
---

Ship it!


nce :)

- Aaron J. Seigo


On Jan. 29, 2012, 10:15 p.m., Martin Koller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103826/
> ---
> 
> (Updated Jan. 29, 2012, 10:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> revive the possibility to enter an UNC path e.g. \\hostname\some\path into 
> krunner leading to an smb://hostname/some/path target as is done in 
> konqueror's address bar.
> 
> 
> This addresses bug 211317.
> http://bugs.kde.org/show_bug.cgi?id=211317
> 
> 
> Diffs
> -
> 
>   plasma/generic/runners/locations/locationrunner.cpp c8ec8ae 
> 
> Diff: http://git.reviewboard.kde.org/r/103826/diff/diff
> 
> 
> Testing
> ---
> 
> Tested local paths, # and ## shortcuts (man and info), tar: zip: special 
> protocols, \\ and \\host\path style URL, $HOME/bin
> 
> 
> Thanks,
> 
> Martin Koller
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Improve the QML RunnerModel

2012-02-09 Thread Aaron J. Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103806/#review10471
---



components/runnermodel/runnermodel.cpp


the Enabled role is missing now



components/runnermodel/runnermodel.cpp


what is access to the Runner pointer needed for? i'm very hesitant to 
expose those pointers.



components/runnermodel/runnermodel.cpp


what are the use cases for these methods? i'm undecided whether i agree 
with them being here, but that really depends on what you plan on using them 
for :)


- Aaron J. Seigo


On Feb. 7, 2012, 11:23 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103806/
> ---
> 
> (Updated Feb. 7, 2012, 11:23 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Adds some features to the RunnerModel so that it can be used properly in the 
> KRunner QML implementation I've been working on (see the testing section).
> 
> Also it simplifies the code a bit by moving from QAbstractItemModel -> 
> QAbstractListModel.
> 
> 
> Diffs
> -
> 
>   components/runnermodel/runnermodel.h 899bf1f 
>   components/runnermodel/runnermodel.cpp a226f8e 
> 
> Diff: http://git.reviewboard.kde.org/r/103806/diff/diff
> 
> 
> Testing
> ---
> 
> use it in kde:scratch/apol/krunner-qml (proof of concept for a KRunner 
> implemented in QtQuick).
> 
> here's a video, so that you know what's going on: 
> http://www.proli.net/meu/netrunner/qmlrunner.ogv
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: telling a data engine to reload a source

2012-02-09 Thread Weng Xuetian 
On Fri, Feb 10, 2012 at 7:03 AM, Eric Mesa  wrote:
> On Thu, Feb 9, 2012 at 8:48 AM, Aaron J. Seigo  wrote:
>>
>>
>> the plasmoid (almost) never tells the engine when to reload. how can it
>> when
>> it is simply a visualization of the data? if the visualization knows such
>> things, it is not longer a visualization. if the dataengine does not know
>> such
>> things then it is no longer a true manager of data.
>>
>> no. the dataengine itself must know when and how to reload data. the only
>> thing a visualization can do is request updates every N ms (time based
>> updates).
>>
>> --
>> Aaron J. Seigo
>
>
> So what I really should do is set the plasmoid to request updates every
> 86,400,000 seconds (1 day) if I'd want the data to be fresh every day?
>
Well, yes.

You could check the microblog plasmod:
http://quickgit.kde.org/index.php?p=kdeplasma-addons.git&a=blob&hb=HEAD&f=applets%2Fmicroblog%2Fmicroblog.cpp
It's using: m_engine->connectSource(profileQuery, this,
m_historyRefresh * 60 * 1000);

If you need some feature such as refresh manually, you could add a
ServiceJob to the data engine.
http://quickgit.kde.org/index.php?p=kdeplasma-addons.git&a=tree&f=dataengines%2Fmicroblog
Microblog dataengine also has a ServiceJob called refresh, in order to
trigger refresh on the plasmoid side.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: telling a data engine to reload a source

2012-02-09 Thread Eric Mesa 
On Thu, Feb 9, 2012 at 8:48 AM, Aaron J. Seigo  wrote:

>
> the plasmoid (almost) never tells the engine when to reload. how can it
> when
> it is simply a visualization of the data? if the visualization knows such
> things, it is not longer a visualization. if the dataengine does not know
> such
> things then it is no longer a true manager of data.
>
> no. the dataengine itself must know when and how to reload data. the only
> thing a visualization can do is request updates every N ms (time based
> updates).
>
> --
> Aaron J. Seigo
>

So what I really should do is set the plasmoid to request updates every
86,400,000 seconds (1 day) if I'd want the data to be fresh every day?

Fair enough,
--
Eric Mesa
http://about.me/ericmesa
http://www.ericsbinaryworld.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix folderview sorting

2012-02-09 Thread Aaron J. Seigo 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103895/#review10464
---

Ship it!


Ship It!

- Aaron J. Seigo


On Feb. 9, 2012, 6:22 p.m., Ignat Semenov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103895/
> ---
> 
> (Updated Feb. 9, 2012, 6:22 p.m.)
> 
> 
> Review request for Plasma, Aaron J. Seigo, Marco Martin, Peter Penz, and 
> Fredrik Höglund.
> 
> 
> Description
> ---
> 
> This patch fixes the inconsistent sorting issues in FolderView.
> 
> 1)It introduces explicit support for sorting by size. Prior to the change, 
> sorting by Size was done as follows:convert the size into a string and use 
> KStringHandler::naturalCompare(). Of course, this is not the same as a proper 
> int comparison - FW sorted incorrectly by size.
> 2)Introduce one important concept:fallback to comparing the name if the main 
> sorting column is not enough to determine a sort order. This is especially 
> important for sorting by type - sorting by size needs this as well, but 
> different files are way less likely to have the same size compared to the 
> possibility of them having similar types.
> 3)Intoduce full three-level fallback for ensuring file name uniqueness, taken 
> from Dolphin code. Thanks a bunch goes to Peter Penz :)
> 4)And of course, sort folders by the child count if sorting by size. Again, 
> Dolphin inspired.
> 
> 
> Diffs
> -
> 
>   plasma/applets/folderview/proxymodel.cpp 4b3340e 
> 
> Diff: http://git.reviewboard.kde.org/r/103895/diff/diff
> 
> 
> Testing
> ---
> 
> Tested, yields results similar to Dolphin sorting of the same folder 
> (surpise! :) ).
> 
> 
> Thanks,
> 
> Ignat Semenov
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Data engine update issue in Javascript

2012-02-09 Thread Maik Beckmann 
https://www.dropbox.com/s/omnt27sor7d99zl/textmondebug.plasmoid
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix folderview sorting

2012-02-09 Thread Ignat Semenov 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103895/
---

(Updated Feb. 9, 2012, 6:22 p.m.)


Review request for Plasma, Aaron J. Seigo, Marco Martin, Peter Penz, and 
Fredrik Höglund.


Changes
---

Fixed the comment


Description
---

This patch fixes the inconsistent sorting issues in FolderView.

1)It introduces explicit support for sorting by size. Prior to the change, 
sorting by Size was done as follows:convert the size into a string and use 
KStringHandler::naturalCompare(). Of course, this is not the same as a proper 
int comparison - FW sorted incorrectly by size.
2)Introduce one important concept:fallback to comparing the name if the main 
sorting column is not enough to determine a sort order. This is especially 
important for sorting by type - sorting by size needs this as well, but 
different files are way less likely to have the same size compared to the 
possibility of them having similar types.
3)Intoduce full three-level fallback for ensuring file name uniqueness, taken 
from Dolphin code. Thanks a bunch goes to Peter Penz :)
4)And of course, sort folders by the child count if sorting by size. Again, 
Dolphin inspired.


Diffs (updated)
-

  plasma/applets/folderview/proxymodel.cpp 4b3340e 

Diff: http://git.reviewboard.kde.org/r/103895/diff/diff


Testing
---

Tested, yields results similar to Dolphin sorting of the same folder (surpise! 
:) ).


Thanks,

Ignat Semenov

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Martin Gräßlin 
On Friday 10 February 2012 00:22:21 Weng Xuetian wrote:
> By the way, is it possible to make win deco use another menu right
> now? For example, can dolphin use its collapsed menu if windeco menu
> is used, or if it's not possible automatically, can dolphin manually
> do it?
yes, that's what I meant with needs support in Frameworks 5. We need to add an 
API to allow applications to export a specific menu.
> 
> By the way GNOME is also doing something similar, though not knowing
> the implementation detail.
> http://live.gnome.org/ThreePointThree/Features/ApplicationMenu
> 
> Seems they try to give application a global hint via a daemon for what
> kind of menu they can make use of, in order to choose different kinds
> of menu to meet the specific environment. Traditional menu is not a
> good idea for all application, but putting existing traditional menu
> directly into windeco is also not a good idea for me (this can be done
> later, but if windeco is pushed by default, might break some sort of
> user experience for specific application).
interesting, that sounds like a good opportunity to collaborate.

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: Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Weng Xuetian 
On Thu, Feb 9, 2012 at 11:50 PM, Martin Gräßlin  wrote:
> On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote:
>> On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin  wrote:
>> > On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote:
>> >> Hey there!
>> >>
>> >> It seems that people really likes AppMenu, we have fans of everything
>> >> we have done with it so far:
>> >> -oxygen-appmenu
>> >> -plasmoid
>> >> -runner
>> >>
>> >> So it seems clear to me that we should integrate this technology into
>> >> Workspace 4.9, but before we do it would be good to hear opinions
>> >> about these questions:
>> >>
>> >> -Is there any way of integrating oxygen-appmenu without breaking
>> >> api-abi? Maybe a second version of the API?
>> >
>> > If that refers to KWin decoration API: no problem as we are going to break
>> > deco API in 4.9 anyway :-)
>> >
>> >> -How the KDED works?
>> >> -Is there any plans to extend libdbusmenu-qt to make it export the
>> >> menu as a model?
>> >> -Do we need something else to complete our support? documentation maybe?
>> >> -What is the status of it being merged into GTK ?
>> >>
>> >> Personally I think that AppMenu is a powerful technology that will
>> >> allow us to decide how and when show the menubars which sure will be
>> >> handy in the future.
>> >>
>> >> So, what do you think of AppMenu?
>> >
>> > I'm all for it and would even say we go for default menu in windeco.
>> >
>> > Cheers
>> > Martin
>>
>> I would say give it a blacklist for some special application, such as
>> gimp / inkscape. Current win deco menu button is not a good solution
>> for those. For other menu-is-rarely-used-application (Maybe that's the
>> most case), my two cents for putting it in windeco.
>>
>> By the way, is there anyway for people to implement some special
>> appmenu only case like compact menu of firefox? I currently don't see
>> it is possible with dbus menu.
> No I think this is not yet possible. But it is something we should do in
> Frameworks 5. Just turning the menu from horizontal to vertical is not a
> perfect solution and I really like what Dolphin did to the collapsed menu.
>
> Firefox btw did a bad implementation: just try to navigate with keyboard only
> :-)
>
Yes keyboard navigate is simply broken for firefox..

By the way, is it possible to make win deco use another menu right
now? For example, can dolphin use its collapsed menu if windeco menu
is used, or if it's not possible automatically, can dolphin manually
do it?

By the way GNOME is also doing something similar, though not knowing
the implementation detail.
http://live.gnome.org/ThreePointThree/Features/ApplicationMenu

Seems they try to give application a global hint via a daemon for what
kind of menu they can make use of, in order to choose different kinds
of menu to meet the specific environment. Traditional menu is not a
good idea for all application, but putting existing traditional menu
directly into windeco is also not a good idea for me (this can be done
later, but if windeco is pushed by default, might break some sort of
user experience for specific application).
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

R: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread LucaTringali 
Hi,
I really like this idea, expecially because I'm dreaming of a KRunner version 
that uses voice recognition, so the user could do the main operations (and have 
access to applications menus) using the voice. 
But I don't know if there are problems in integrating AppMenu in the next 
version of Plasma.

Luca Tringali

>Messaggio originale
>Da: afies...@kde.org
>Data: 09/02/2012 16.07
>A: 
>Cc: 
>Ogg: Integrate AppMenu into Workspace 4.9
>
>Hey there!
>
>It seems that people really likes AppMenu, we have fans of everything
>we have done with it so far:
>-oxygen-appmenu
>-plasmoid
>-runner
>
>So it seems clear to me that we should integrate this technology into
>Workspace 4.9, but before we do it would be good to hear opinions
>about these questions:
>
>-Is there any way of integrating oxygen-appmenu without breaking
>api-abi? Maybe a second version of the API?
>-How the KDED works?
>-Is there any plans to extend libdbusmenu-qt to make it export the
>menu as a model?
>-Do we need something else to complete our support? documentation maybe?
>-What is the status of it being merged into GTK ?
>
>Personally I think that AppMenu is a powerful technology that will
>allow us to decide how and when show the menubars which sure will be
>handy in the future.
>
>So, what do you think of AppMenu?
>___
>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: Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Mark 
On Thu, Feb 9, 2012 at 4:50 PM, Martin Gräßlin  wrote:

> On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote:
> > On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin 
> wrote:
> > > On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote:
> > >> Hey there!
> > >>
> > >> It seems that people really likes AppMenu, we have fans of everything
> > >> we have done with it so far:
> > >> -oxygen-appmenu
> > >> -plasmoid
> > >> -runner
> > >>
> > >> So it seems clear to me that we should integrate this technology into
> > >> Workspace 4.9, but before we do it would be good to hear opinions
> > >> about these questions:
> > >>
> > >> -Is there any way of integrating oxygen-appmenu without breaking
> > >> api-abi? Maybe a second version of the API?
> > >
> > > If that refers to KWin decoration API: no problem as we are going to
> break
> > > deco API in 4.9 anyway :-)
> > >
> > >> -How the KDED works?
> > >> -Is there any plans to extend libdbusmenu-qt to make it export the
> > >> menu as a model?
> > >> -Do we need something else to complete our support? documentation
> maybe?
> > >> -What is the status of it being merged into GTK ?
> > >>
> > >> Personally I think that AppMenu is a powerful technology that will
> > >> allow us to decide how and when show the menubars which sure will be
> > >> handy in the future.
> > >>
> > >> So, what do you think of AppMenu?
> > >
> > > I'm all for it and would even say we go for default menu in windeco.
> > >
> > > Cheers
> > > Martin
> >
> > I would say give it a blacklist for some special application, such as
> > gimp / inkscape. Current win deco menu button is not a good solution
> > for those. For other menu-is-rarely-used-application (Maybe that's the
> > most case), my two cents for putting it in windeco.
> >
> > By the way, is there anyway for people to implement some special
> > appmenu only case like compact menu of firefox? I currently don't see
> > it is possible with dbus menu.
> No I think this is not yet possible. But it is something we should do in
> Frameworks 5.
>
> Why not?
The new decorations are going to be QML based anyway so why not make the
"menu button" a qml element that gets filled from a model or something..
That way it's perfectly themable, right? Or am i missing a point here?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Drop Xinerama related options in KWin

2012-02-09 Thread Commit Hook 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103756/#review10459
---


This review has been submitted with commit 
4a0369aae0ba4008c0fce7624b33af3c5794 by Martin Gräßlin to branch master.

- Commit Hook


On Jan. 26, 2012, 6:47 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103756/
> ---
> 
> (Updated Jan. 26, 2012, 6:47 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> ---
> 
> As discussed on the mailinglist: drop of the xinerama related options and the 
> kcm. Given that the show unmanaged windows on option is in fact not used, I 
> dropped the complete KCM.
> 
> 
> Diffs
> -
> 
>   kcontrol/CMakeLists.txt 8cd9a46 
>   kcontrol/xinerama/CMakeLists.txt fe332e5 
>   kcontrol/xinerama/Messages.sh f4aa134 
>   kcontrol/xinerama/interface_util.h 8a4fcd1 
>   kcontrol/xinerama/kcmxinerama.h 18b9241 
>   kcontrol/xinerama/kcmxinerama.cpp a456b2c 
>   kcontrol/xinerama/test_kcm_xinerama.cpp a358a2c 
>   kcontrol/xinerama/xinerama.desktop e8ce525 
>   kcontrol/xinerama/xineramawidget.h 2c446a2 
>   kcontrol/xinerama/xineramawidget.cpp df9cb2f 
>   kcontrol/xinerama/xineramawidget.ui 90ec4d4 
>   kwin/geometry.cpp a414e26 
>   kwin/manage.cpp c551eac 
>   kwin/options.h 9dc29cf 
>   kwin/options.cpp d496569 
>   kwin/tabbox/tabbox.cpp 3051316 
>   kwin/toplevel.cpp ffe7f0c 
>   kwin/workspace.cpp 69b4ecb 
> 
> Diff: http://git.reviewboard.kde.org/r/103756/diff/diff
> 
> 
> Testing
> ---
> 
> Fullscreen: works
> Maximize: works
> Movment: works
> Placement: works
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Martin Gräßlin 
On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote:
> On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin  wrote:
> > On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote:
> >> Hey there!
> >>
> >> It seems that people really likes AppMenu, we have fans of everything
> >> we have done with it so far:
> >> -oxygen-appmenu
> >> -plasmoid
> >> -runner
> >>
> >> So it seems clear to me that we should integrate this technology into
> >> Workspace 4.9, but before we do it would be good to hear opinions
> >> about these questions:
> >>
> >> -Is there any way of integrating oxygen-appmenu without breaking
> >> api-abi? Maybe a second version of the API?
> >
> > If that refers to KWin decoration API: no problem as we are going to break
> > deco API in 4.9 anyway :-)
> >
> >> -How the KDED works?
> >> -Is there any plans to extend libdbusmenu-qt to make it export the
> >> menu as a model?
> >> -Do we need something else to complete our support? documentation maybe?
> >> -What is the status of it being merged into GTK ?
> >>
> >> Personally I think that AppMenu is a powerful technology that will
> >> allow us to decide how and when show the menubars which sure will be
> >> handy in the future.
> >>
> >> So, what do you think of AppMenu?
> >
> > I'm all for it and would even say we go for default menu in windeco.
> >
> > Cheers
> > Martin
>
> I would say give it a blacklist for some special application, such as
> gimp / inkscape. Current win deco menu button is not a good solution
> for those. For other menu-is-rarely-used-application (Maybe that's the
> most case), my two cents for putting it in windeco.
>
> By the way, is there anyway for people to implement some special
> appmenu only case like compact menu of firefox? I currently don't see
> it is possible with dbus menu.
No I think this is not yet possible. But it is something we should do in
Frameworks 5. Just turning the menu from horizontal to vertical is not a
perfect solution and I really like what Dolphin did to the collapsed menu.

Firefox btw did a bad implementation: just try to navigate with keyboard only
:-)

Cheers
Martin

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: Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Martin Gräßlin 
On Thursday 09 February 2012 16:31:27 Alex Fiestas wrote:
> On Thu, Feb 9, 2012 at 4:24 PM, Martin Gräßlin  wrote:
> > If that refers to KWin decoration API: no problem as we are going to break
> > deco API in 4.9 anyway :-)
>
> Oh didn't know that, because the QML decoration thing?
no, because window tabbing is broken beyond any repair and Thomas is currently
rewriting it and because of that we need adjustments to the API. We use this
as an excuse to clean up a little bit and given that there are no 3rd party
decorations except for skulpture, dekorator, bespin and QtCurve which are all
developed by developers close to us it's not a big issue.
>
> > I'm all for it and would even say we go for default menu in windeco.
>
> In that case I would really love to see something like this:
> http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/
>
> But in this case I'd put the textbox at the bottom, what do you think?
> I can take some time today to try to do a PoC if you like the idea.
sounds like an awesome idea. I had seen this today for the first time in your
linked video and really liked it.
>
> BTW remember to "reply to all", I'm not sure if gnumdk is in plasma-devel.
ups, but even in your mail only agateau was included...

Cheers
Martin

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: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Andrei Nistor 

On 09.02.2012 17:31, Alex Fiestas wrote:

I'm all for it and would even say we go for default menu in windeco.

In that case I would really love to see something like this:

http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/

But in this case I'd put the textbox at the bottom, what do you 
think?

I can take some time today to try to do a PoC if you like the idea.


This looks a lot like Ubuntu's HUD [0]. I'd love to see that in KDE, 
maybe integrated with KRunner?


[0] http://www.youtube.com/watch?v=w_WW-DHqR3c

--
Andrei
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Weng Xuetian 
On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin  wrote:
> On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote:
>> Hey there!
>>
>> It seems that people really likes AppMenu, we have fans of everything
>> we have done with it so far:
>> -oxygen-appmenu
>> -plasmoid
>> -runner
>>
>> So it seems clear to me that we should integrate this technology into
>> Workspace 4.9, but before we do it would be good to hear opinions
>> about these questions:
>>
>> -Is there any way of integrating oxygen-appmenu without breaking
>> api-abi? Maybe a second version of the API?
> If that refers to KWin decoration API: no problem as we are going to break
> deco API in 4.9 anyway :-)
>> -How the KDED works?
>> -Is there any plans to extend libdbusmenu-qt to make it export the
>> menu as a model?
>> -Do we need something else to complete our support? documentation maybe?
>> -What is the status of it being merged into GTK ?
>>
>> Personally I think that AppMenu is a powerful technology that will
>> allow us to decide how and when show the menubars which sure will be
>> handy in the future.
>>
>> So, what do you think of AppMenu?
> I'm all for it and would even say we go for default menu in windeco.
>
> Cheers
> Martin


I would say give it a blacklist for some special application, such as
gimp / inkscape. Current win deco menu button is not a good solution
for those. For other menu-is-rarely-used-application (Maybe that's the
most case), my two cents for putting it in windeco.

By the way, is there anyway for people to implement some special
appmenu only case like compact menu of firefox? I currently don't see
it is possible with dbus menu.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Alex Fiestas 
On Thu, Feb 9, 2012 at 4:24 PM, Martin Gräßlin  wrote:
> If that refers to KWin decoration API: no problem as we are going to break
> deco API in 4.9 anyway :-)
Oh didn't know that, because the QML decoration thing?

> I'm all for it and would even say we go for default menu in windeco.
In that case I would really love to see something like this:
http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/

But in this case I'd put the textbox at the bottom, what do you think?
I can take some time today to try to do a PoC if you like the idea.

BTW remember to "reply to all", I'm not sure if gnumdk is in plasma-devel.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Martin Gräßlin 
On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote:
> Hey there!
> 
> It seems that people really likes AppMenu, we have fans of everything
> we have done with it so far:
> -oxygen-appmenu
> -plasmoid
> -runner
> 
> So it seems clear to me that we should integrate this technology into
> Workspace 4.9, but before we do it would be good to hear opinions
> about these questions:
> 
> -Is there any way of integrating oxygen-appmenu without breaking
> api-abi? Maybe a second version of the API?
If that refers to KWin decoration API: no problem as we are going to break 
deco API in 4.9 anyway :-)
> -How the KDED works?
> -Is there any plans to extend libdbusmenu-qt to make it export the
> menu as a model?
> -Do we need something else to complete our support? documentation maybe?
> -What is the status of it being merged into GTK ?
> 
> Personally I think that AppMenu is a powerful technology that will
> allow us to decide how and when show the menubars which sure will be
> handy in the future.
> 
> So, what do you think of AppMenu?
I'm all for it and would even say we go for default menu in windeco.

Cheers
Martin

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

Integrate AppMenu into Workspace 4.9

2012-02-09 Thread Alex Fiestas 
Hey there!

It seems that people really likes AppMenu, we have fans of everything
we have done with it so far:
-oxygen-appmenu
-plasmoid
-runner

So it seems clear to me that we should integrate this technology into
Workspace 4.9, but before we do it would be good to hear opinions
about these questions:

-Is there any way of integrating oxygen-appmenu without breaking
api-abi? Maybe a second version of the API?
-How the KDED works?
-Is there any plans to extend libdbusmenu-qt to make it export the
menu as a model?
-Do we need something else to complete our support? documentation maybe?
-What is the status of it being merged into GTK ?

Personally I think that AppMenu is a powerful technology that will
allow us to decide how and when show the menubars which sure will be
handy in the future.

So, what do you think of AppMenu?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: FrameSVG manual reload on themeChanged()

2012-02-09 Thread Aaron J. Seigo 
On Thursday, February 9, 2012 17:11:38 Ignat Semenov wrote:
> Hello fellow plasma developers!
> 
> I'm doing a fix for folderview, related to the theme changes.  In
> particular, I need to relayout and repaint the items using the margins
> in the new viewitem.svgz in the new theme. To reload the FrameSVG
> object manually, I need to do an update() call in the applet, which
> will redraw everything, including the view, and load the correct SVG.
> But, after that, I will recalculate the correct margins and relayout
> the items (as they have different sizes now), and then repaint the
> view completely. So we have 2 complete repaints (and one more in
> AppletPrivate::themeChanged(), an unconditional one.)
> 
> So, I'd like to avoid this second repaint (via update()), and reload
> the framesvg manually. How can I do that?

are you sure this results in 2 paint events? in theory, these signals should 
all happen at the same time and those two calls to update() should be 
compressed into a single paint event .. meaning that there is no point in 
trying to optimize that call out.

that's the theory .. in practice that theory could be wrong (in which case we 
need to fix it in libplasma). if you could confirm the number of paint events 
that actually get triggered that would be excellent.

-- 
Aaron J. Seigo

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

FrameSVG manual reload on themeChanged()

2012-02-09 Thread Ignat Semenov 
Hello fellow plasma developers!

I'm doing a fix for folderview, related to the theme changes.  In
particular, I need to relayout and repaint the items using the margins
in the new viewitem.svgz in the new theme. To reload the FrameSVG
object manually, I need to do an update() call in the applet, which
will redraw everything, including the view, and load the correct SVG.
But, after that, I will recalculate the correct margins and relayout
the items (as they have different sizes now), and then repaint the
view completely. So we have 2 complete repaints (and one more in
AppletPrivate::themeChanged(), an unconditional one.)

So, I'd like to avoid this second repaint (via update()), and reload
the framesvg manually. How can I do that?

Best regards,
Ignat Semenov
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] File ending for packaged KWin effects and where to put them

2012-02-09 Thread Aaron J. Seigo 
On Thursday, February 9, 2012 09:57:32 Martin Gräßlin wrote:
> Should such files use the file ending "plasmoid" or should we introduce new
> names like "kwineffect", "kwinswitcher", "kwinscript", "kwindecoration"?
> Could using "plasmoid" result in problems like the widgets explorer trying
> to install the kwineffect when dropped on the desktop?

it will be at the very least confusing for the user. i would recommend
different suffixes.

> The second question I have is about the additional effects. Now that we have
> the scripted bindings I want to rewrite a few pure eye-candy effects with
> the bindings and move them out of the KWin source tree. Where should they
> go? I tend to plasma-addons.

if you want them available by synchrotron, then in the synchrotron-sources
repository. otherwise i think addons is a good target, yes.

> Last but not least: how does this synchrotron work and does it offer
> something which would be very useful to distribute our effects, scripts,
> etc?

yes, it does. i need to complete the client-side integration to make it non-
painful to use from such things (e.g. i don't want kwin, plasma-desktop, etc.
etc. all implementing this on their own, which they would nominally have to at
this point.) i'll rachet this up on my todo list since kwin would now be
blocking on it.

--
Aaron J. Seigo

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: Data engine update issue in Javascript

2012-02-09 Thread Aaron J. Seigo 
On Wednesday, February 8, 2012 23:54:43 Maik Beckmann wrote:
> The code in this paste is a condenced version that reproduces the problem

can you please post a link to the entire package? you obviously have it on 
your system and i don't have the time to recreate what you already have to 
just be able to begin debugging ... thanks.

-- 
Aaron J. Seigo

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: telling a data engine to reload a source

2012-02-09 Thread Aaron J. Seigo 
On Tuesday, February 7, 2012 13:56:32 Eric Mesa wrote:
> I have a data engine that grabs some data off the web, chugs it and then
> presents it to my plasmoid.  How could my plasmoid tell the data engine
> that its data is now out of date and it should regrab its data?  Even
> better would be the ability to tell it to update only one of its 20 sources.

this is almost certainly an incorrect usage of the dataengine design.

the plasmoid (almost) never tells the engine when to reload. how can it when 
it is simply a visualization of the data? if the visualization knows such 
things, it is not longer a visualization. if the dataengine does not know such 
things then it is no longer a true manager of data.

no. the dataengine itself must know when and how to reload data. the only 
thing a visualization can do is request updates every N ms (time based 
updates).

if the plasmoid wants to reload the data after a certainly timelapse, then use 
that feature in the connectToSource call.

if the data is outdated by some event, then the DataEngine should know how to 
react to that event.

if, for some unfortunate reason, it is due only to user interaction in the 
visualization then the DataEngine needs to provide a Service (returned by 
serviceForSource in the DataEngine implementation) that can be used by the 
visualization.

however, i would strongly encourage you to first ensure that the use case is 
actually correct.

cheers ...

-- 
Aaron J. Seigo

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: Fwd: GSOC Mentor

2012-02-09 Thread Aaron J. Seigo 
On Sunday, February 5, 2012 13:35:02 heathmatlock wrote:
> -- Forwarded message --
> From: heathmatlock 
> Date: Sat, Feb 4, 2012 at 12:08 PM
> Subject: GSOC Mentor
> To: kde-...@kde.org
> 
> 
> Eike Hein has been mentoring me through the process of becoming a KDE
> developer, and I'm working on a project dubbed Qanda which adds
> natural language processing to krunner. I'm in need of someone
> reviewing my proposal and a willing mentor for this year's GSOC.

sounds interesting. as i'm one of the few who know krunner internals (there's 
probably 3-4 of us, not all around all the time though) this might be a GSOC 
i'd pick up ...

-- 
Aaron J. Seigo

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: Re: [RFC] File ending for packaged KWin effects and where to put them

2012-02-09 Thread Martin Gräßlin 
On Thursday 09 February 2012 17:45:03 Weng Xuetian wrote:
> On Thu, Feb 9, 2012 at 4:57 PM, Martin Gräßlin  wrote:
> > Hi workspace developers,
> >
> > my JavaScript bindings for KWin effects are nearly in place and that
> > results in a few questions I wanted to discuss with the greater team.
> >
> > The scripted effects follow the Plasma Packages structure and I plan to
> > have also "normal" KWin scripts use Plasma Package structure as well as
> > window decorations and window switcher layouts.
> >
> > Should such files use the file ending "plasmoid" or should we introduce
> > new
> > names like "kwineffect", "kwinswitcher", "kwinscript", "kwindecoration"?
> > Could using "plasmoid" result in problems like the widgets explorer
> > trying to install the kwineffect when dropped on the desktop?
>
> plasmoid is just a zip rename into .plasmoid, and if ".kwineffect"
> will be used, you should add something similar to
> /usr/share/mime/application/x-plasma.xml.
>
> Add new mime-type for kwin effects have a benefit that they can be
> assigned to different installer easily, if user want to have a feature
> that double click on .kwineffect file and can have it installed.
>
> > The second question I have is about the additional effects. Now that we
> > have the scripted bindings I want to rewrite a few pure eye-candy effects
> > with the bindings and move them out of the KWin source tree. Where should
> > they go? I tend to plasma-addons.
> >
> > Last but not least: how does this synchrotron work and does it offer
> > something which would be very useful to distribute our effects, scripts,
> > etc?
> I think you can request a new category for kwin effect on
> kde-look.org, currently there is no separate kwin effect category and
> all existing third-party effect are seems to be in "KDE Improvement".
> Something like "KWin Effects Binary" and "KWin Effects Scripts" should
> be added.
yes of course, but this does not make sense before the code is written. In
fact I want to have the new categories on kde-look hidden till our first 4.9
beta is released :-)

Cheers
Martin

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: [RFC] File ending for packaged KWin effects and where to put them

2012-02-09 Thread Weng Xuetian 
On Thu, Feb 9, 2012 at 4:57 PM, Martin Gräßlin  wrote:
> Hi workspace developers,
>
> my JavaScript bindings for KWin effects are nearly in place and that results
> in a few questions I wanted to discuss with the greater team.
>
> The scripted effects follow the Plasma Packages structure and I plan to have
> also "normal" KWin scripts use Plasma Package structure as well as window
> decorations and window switcher layouts.
>
> Should such files use the file ending "plasmoid" or should we introduce new
> names like "kwineffect", "kwinswitcher", "kwinscript", "kwindecoration"? Could
> using "plasmoid" result in problems like the widgets explorer trying to
> install the kwineffect when dropped on the desktop?

plasmoid is just a zip rename into .plasmoid, and if ".kwineffect"
will be used, you should add something similar to
/usr/share/mime/application/x-plasma.xml.

Add new mime-type for kwin effects have a benefit that they can be
assigned to different installer easily, if user want to have a feature
that double click on .kwineffect file and can have it installed.

>
> The second question I have is about the additional effects. Now that we have
> the scripted bindings I want to rewrite a few pure eye-candy effects with the
> bindings and move them out of the KWin source tree. Where should they go? I
> tend to plasma-addons.
>
> Last but not least: how does this synchrotron work and does it offer something
> which would be very useful to distribute our effects, scripts, etc?
>

I think you can request a new category for kwin effect on
kde-look.org, currently there is no separate kwin effect category and
all existing third-party effect are seems to be in "KDE Improvement".
Something like "KWin Effects Binary" and "KWin Effects Scripts" should
be added.

And KNewStuff3 is very easy to use.
http://techbase.kde.org/Development/Tutorials/Collaboration/HotNewStuff/Introduction
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [RFC] File ending for packaged KWin effects and where to put them

2012-02-09 Thread Mark 
On Thu, Feb 9, 2012 at 9:57 AM, Martin Gräßlin  wrote:

> Hi workspace developers,
>
> my JavaScript bindings for KWin effects are nearly in place and that
> results
> in a few questions I wanted to discuss with the greater team.
>
> The scripted effects follow the Plasma Packages structure and I plan to
> have
> also "normal" KWin scripts use Plasma Package structure as well as window
> decorations and window switcher layouts.
>
> Should such files use the file ending "plasmoid" or should we introduce new
> names like "kwineffect", "kwinswitcher", "kwinscript", "kwindecoration"?
> Could
> using "plasmoid" result in problems like the widgets explorer trying to
> install the kwineffect when dropped on the desktop?
>

My opinion.. keep .plasmoid for the actual "widgets" that can be placed on
the desktop.
use the new names ("kwineffect", "kwinswitcher", "kwinscript",
"kwindecoration") for kwin.

Just my 2 cents. I can't comment on the other questions since I know to
little about that.

>
> The second question I have is about the additional effects. Now that we
> have
> the scripted bindings I want to rewrite a few pure eye-candy effects with
> the
> bindings and move them out of the KWin source tree. Where should they go? I
> tend to plasma-addons.
>
> Last but not least: how does this synchrotron work and does it offer
> something
> which would be very useful to distribute our effects, scripts, etc?
>
> Cheers
> Martin
> ___
> 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

[RFC] File ending for packaged KWin effects and where to put them

2012-02-09 Thread Martin Gräßlin 
Hi workspace developers,

my JavaScript bindings for KWin effects are nearly in place and that results 
in a few questions I wanted to discuss with the greater team.

The scripted effects follow the Plasma Packages structure and I plan to have 
also "normal" KWin scripts use Plasma Package structure as well as window 
decorations and window switcher layouts.

Should such files use the file ending "plasmoid" or should we introduce new 
names like "kwineffect", "kwinswitcher", "kwinscript", "kwindecoration"? Could 
using "plasmoid" result in problems like the widgets explorer trying to 
install the kwineffect when dropped on the desktop?

The second question I have is about the additional effects. Now that we have 
the scripted bindings I want to rewrite a few pure eye-candy effects with the 
bindings and move them out of the KWin source tree. Where should they go? I 
tend to plasma-addons.

Last but not least: how does this synchrotron work and does it offer something 
which would be very useful to distribute our effects, scripts, etc?

Cheers
Martin

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