Re: Add multiple feeds to rssnow (Qml) plasmoid

[Marco Martin]

On Saturday 17 December 2011, Antonis Tsiapaliokas wrote:
> Hello
> 
> I am creating a patch, for adding multiple feeds to rssnow (Qml) plasmoid,
> but i have stuck and i need some help.
> The c++ plasmoid is using signals and custom slots to add/remove feeds from
> the plasmoid.
> And here is where i stuck. How exactly can i add a custom "slot" to the
> rssnow (Qml) plasmoid without using c++?
> 

to be able to have multiple feeds, just do the right things in the 
configurationChanged() function (in javascript, main qml file)

to have slots, just implement an onSignal: function 

or if you need to connect to a signal from another item, use the Connections 
item:
http://developer.qt.nokia.com/doc/qt-4.8/qml-connections.html

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

qtcomponents documentation

[Marco Martin]

Hi all,

I think we should do a real documentation sprint for the plasma qtcomponents, 
to have a good api doc for the 4.8 release.

I have now merged the branch plasma-components-doc as the documentation was 
already good (and avoiding conflicts with master)

I have to say congratulations to who woked on it, let's complete and make it 
rock for 4.8 ;)

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

Re: problem with icontask and javascript

[Nowardev-Team]

 Ty Ty  i did

;( i had not seen that on kde wiki :( blind man

2011/12/16 Aaron J. Seigo 

> On Friday, December 16, 2011 07:29:45 Nowardev-Team wrote:
> > var icontasks = panel.addWidget("icontasks")
> > icontasks.writeConfig("groupClick","1")
> > icontasks.writeConfig("unity","true")
> > //icontasks.writeConfig("Enabled","true")
> >
> >
> icontasks.writeConfig("Items","file:///usr/share/applications/firefox.deskto
> >
> p?wmClass=Firefox,file:///usr/share/applications/kde4/kate.desktop?wmClass=K
> >
> ate,file:///usr/share/applications/kde4/konversation.desktop?wmClass=Konvers
> >
> ation,file:usr/share/applications/kde4/dolphin.desktop?wmClass=Dolphin,f
> >
> ile:///usr/share/applications/chromium-browser.desktop?wmClass=Chromium-brow
> >
> ser,file:///usr/share/applications/kde4/konsole.desktop?wmClass=Konsole,file
> >
> :///usr/share/applications/kde4/ksnapshot.desktop?wmClass=Ksnapshot,file:///
> >
> usr/share/applications/kde4/systemsettings.desktop?wmClass=Systemsettings")
>
> > *I'm not 100% sure, by Launchers are in a different group.*
>
> from
> http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting
>
> Array[String] currentConfigGroup:
>
> the current configuration group path, with each entry in the array
> representing
> a sub-group. This allows one to access trees of groups with code such as:
> widget.currentConfigGroup = new Array('topGroup', 'subGroupOfTopGroup'). An
> empty Array means the default (top-level) configuration group for the
> widget
>
>
> so you probably want sth like:
>
> icontasks.currentConfigGroup = new Array('Launchers')
> icontasks.writeConfig("Items", "")
>
> --
> 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: Re: Breadcrumbs in Kickoff

[Martin Gräßlin]

Hi,

given that I basically told you not to write developers personally, I do not
understand why you sent the mail to me instead of the mailinglist. I forwared
your mail to the mailinglist and please send further mails also to the list if
you are really interested in discussing this.

Please also don't tofu, it makes discussions difficult to read[1].

On Friday 16 December 2011 19:04:48 Xavier Sythe wrote:
> Actually, the breadcrumbs don't really need to be removed.
> I merely see the need to reinstate the back button.
> "I personally do not see any need for the back button any more."
>
> It's mostly a user experience perspective.
I quite agree it's all about user experience. I think we should not have
redundant elements in our primary user interface. This is confusing. Also the
back button does not exist in any other part of the Plasma desktop or any
other KDE application.
>
> It's a simple fact that it requires less mouse movement,
If you state "facts" you have to prove them. Where is your usability study
showing that a movement to the left is better than a movement to the top?
> Would you support removing the back button from Dolphin, in favour of just
> breadcrumbs?
> I doubt that anyone would support that.
I thought about it and I had to open Dolphin to verify that there is a back
button at all. I doubt I have used the back button during the last few years.
So yes I would support that.
>
> I've chatted briefly with the KDE Usability Team, and they actually seemed
> to agree with me.
Sorry to say: but with whom have you talked? Not everybody who says he is in
the KDE Usability Team is a usability expert but just a user who thinks he
understands usability. That's quite a difference.

And what do you mean with "seemed"? They either agree or don't agree.
>
> Well some users might stick to the breadcrumb navigation, the majority of
> users from previous versions of KDE are accustomed to the back button, and
> appreciate its use, both in Kickoff as well as in Dolphin.  Including both
> types of navigation will ensure that nobody complains, and presumably, lead
> to a better overall user experience.
Do you have any facts that this is actually the case? I don't have any
statistics validating or disvalidating your statement. The only thing I can
tell you is that there is a vocal minority requesting to add the feature
back[2]. With less than ten users posting to the bug report, I am sorry to
tell you that there seems no demand for this feature. (Btw. don't even try to
rally now that users post to the bug report. If that is going to happen I will
make sure that the bug gets made read only).

Please understand that we have to develop software which suits most of our
users. This means that we cannot make all users happy and we are not always
able to add all the features users want. We have to care about more than just
adding features.

Kind Regards
Martin Gräßlin

[1] http://www.rfc1855.net/
[2] https://bugs.kde.org/show_bug.cgi?id'4489
>
> Thanks,
> Xavier Sythe
>
> On Fri, Dec 16, 2011 at 2:12 PM, Martin Gräßlin  wrote:
> > On Thursday 08 December 2011 16:01:33 Xavier Sythe wrote:
> > > Nearly two months ago, I contacted him, and asked him to reverse the
> > > controversial commit.
> > > He has yet to reply.
> >
> > Please understand that not each developer has the time to answer personal
> > requests. You state yourself that it is controversial. Just imagine each
> > user
> > disliking the feature sending a mail to Kevin. That just doesn't scale.
> >
> > Asking to revert the feature is to be honest non-constructive criticism.
> > Like
> > all other decisions on the default user interface they are done with care.
> > The
> > breadcrumbs add high value to Kickoff. It makes navigation in a folder
> > like
> > structure like the application menu more convenient and much more
> > consistant
> > with other parts of KDE applications, e.g. Dolphin's breadcrumb
> > navigation.
> >
> > Just because you (and others) dislike the new feature it does not justify
> > to
> > revert the commit. There are also users liking the feature, so how should
> > we
> > suit both groups? Now please don't state that we need an option for that.
> > This
> > is not possible as the code gets too complex and too difficult to
> > maintain.
> >
> > > When I asked the #KDE IRC channel about this, I was told to contact the
> > > members of this mailing list, to see if I could get the commit reversed.
> >
> > Reverting the commit is clearly not an option. But what would you say
> > about
> > improving the breadcrumbs in Kickoff? Getting them into a state that you
> > want
> > to use them and not the out-of-place back button?
> >
> > Have a look at my recent blog post [1] about the work on Kickoff for 4.9.
> > It
> > is easy to give this version a try, it installs alongside the existing
> > Kickoff. I personally do not see any need for the back button any more.
> >
> > Kind Regards
> > Martin Gräßlin
> >
> > New Kickoff Maintainer after branch merge

Re: Re: Breadcrumbs in Kickoff

[Martin Klapetek]

Hi,

I don't have any strong opinions to either solution, but I just want to
state my views on this discussion.




> > It's a simple fact that it requires less mouse movement,
> If you state "facts" you have to prove them. Where is your usability study
> showing that a movement to the left is better than a movement to the top?
>

In my opinion, the breadcrumbs make sense with deep/long paths. My kickoff
from 4.8/master has everything only one level deep, therefore making the
breadcrumb navigation rather useless (because you can click only the "All
Applications" anyway). So if we went down the road of making kickoff less
"deep", then imho breadcrumb looses its purpose and back button would be
just enough.

Then again, it at least shows where you currently are, so if you for
example close kickoff with some category opened and you reopen kickoff, you
can immediately see "All Applications > Internet" so you know where you
are. Also there are things like Wine which pretty much recreates the
Windows Start menu structure, so you can get 5 levels deep in notime.

As for the mouse movement - if one uses larger kickoff, imho it indeed is
easier to move the mouse just few pixels to the left than moving it all the
way across (consider laptop's touchpad).



> > Would you support removing the back button from Dolphin, in favour of
> just
> > breadcrumbs?
> > I doubt that anyone would support that.
> I thought about it and I had to open Dolphin to verify that there is a back
> button at all. I doubt I have used the back button during the last few
> years.
> So yes I would support that.
>

The back button in Dolphin is actually /very/ useful, consider you're
working in

/home/user/work/project1/subproject3/source/

then you want to move to

/home/user/work/

do something (copy a file) and then back to the first one. So you click the
"work/" in breadcrumb and then you can either navigate all the folders OR
simply click the Back button. I use it every single day ;)


> >
> > I've chatted briefly with the KDE Usability Team, and they actually
> seemed
> > to agree with me.
> Sorry to say: but with whom have you talked? Not everybody who says he is
> in
> the KDE Usability Team is a usability expert but just a user who thinks he
> understands usability. That's quite a difference.
>

I agree that you should either post a log of your conversation or forward
the messages with names. Otherwise it's just a blunt statement.


>
> And what do you mean with "seemed"? They either agree or don't agree.
> >
> > Well some users might stick to the breadcrumb navigation, the majority of
> > users from previous versions of KDE are accustomed to the back button,
> and
> > appreciate its use, both in Kickoff as well as in Dolphin.  Including
> both
> > types of navigation will ensure that nobody complains, and presumably,
> lead
> > to a better overall user experience.
> Do you have any facts that this is actually the case? I don't have any
> statistics validating or disvalidating your statement. The only thing I can
> tell you is that there is a vocal minority requesting to add the feature
> back[2]. With less than ten users posting to the bug report, I am sorry to
> tell you that there seems no demand for this feature. (Btw. don't even try
> to
> rally now that users post to the bug report. If that is going to happen I
> will
> make sure that the bug gets made read only).
>

Having both types in kickoff at the same time seems a bit wrong to me too.
Having an option to switch that on the other hand would be more sensible. I
would suggest to find someone who can implement it in Martin's newest
kickoff branch in such way, that it won't be more work to maintain. Maybe
even the whole navigation system could be modified to fit both options (I
don't know how it currently works)? But again, as Martin clearly stated
he's not in favor of doing this, find someone who will do it and have him
work together with Martin.

--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

[Martin Klapetek]

On Sat, Dec 17, 2011 at 17:02, Martin Klapetek wrote:

>
> Having both types in kickoff at the same time seems a bit wrong to me too.
> Having an option to switch that on the other hand would be more sensible. I
> would suggest to find someone who can implement it in Martin's newest
> kickoff branch in such way, that it won't be more work to maintain. Maybe
> even the whole navigation system could be modified to fit both options (I
> don't know how it currently works)? But again, as Martin clearly stated
> he's not in favor of doing this, find someone who will do it and have him
> work together with Martin.
>

Now that I'm reading what I wrote, I realize it's actually a nonsense
(sorry was preoccupied with other stuff).

Switching to either breadcrumb or the back button is wrong. Both bring
something valuable. So if there should be any option, then I'd add only
"Show back button", but do not switch the breadcrumbs off. As for the rest
- that still holds :)

--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Breadcrumbs in Kickoff

[todd rme]

On Sat, Dec 17, 2011 at 4:18 PM, Martin Gräßlin  wrote:
>> Would you support removing the back button from Dolphin, in favour of just
>> breadcrumbs?
>> I doubt that anyone would support that.
> I thought about it and I had to open Dolphin to verify that there is a back
> button at all. I doubt I have used the back button during the last few years.
> So yes I would support that.

I would not support this, but for a different reason.  The "back"
button in the kickoff menu isn't really a "back" button in the same
way the Dolphin one is.

The dolphin back button, like back buttons in every other file manager
or web browser I have ever used,  takes you to the previously-visited
directory, not matter how far that directory may be from your current
location.

The "back" button in kickoff did not work like this.  Instead, it took
you to the parent directory of the current directory.  In that way it
is much more like Dolphin's "Up" button.  This button in Dolphin, and
other file managers and web browsers, takes you to the parent
directory of the current directory.  Konqueror has an "up" button by
default.  In Dolphin, however, this button has been removed in favor
of using the breadcrumb bar.  So if we are comparing dolphin and
kickoff, then the breadcrumbs in kickoff are much more likely dolphin,
while the old version is more like konqueror.  The button is still
available in Dolphin, I assume for people who use the traditional
navigation bar, but it is not in the toolbar by default.

I think removing the up button in dolphin and kickoff was a good idea.
 I think removing the back button in dolphin, however, would not be,
since it makes it much quicker to move to directories that are not
direct parents of the current directory (I us it for this purpose a
lot).

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

Re: Re: Breadcrumbs in Kickoff

[todd rme]

On Sat, Dec 17, 2011 at 5:02 PM, Martin Klapetek
 wrote:
> So if we went down the road of making kickoff less
> "deep", then imho breadcrumb looses its purpose and back button would be
> just enough.

I don't think this is possible.  The application directory structure
is defined by distributions, not be KDE.  How KDE uses the directory
structure is determined by FDO specs, so KDE cannot really
unilaterally ignore them.

At least in my distro applications have 3 levels (including "all applications").

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

Re: qtcomponents documentation

[Aaron J. Seigo]

On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> Hi all,
> 
> I think we should do a real documentation sprint for the plasma
> qtcomponents, to have a good api doc for the 4.8 release.

and ideas / preferences on when and where? 

-- 
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: qtcomponents documentation

[Marco Martin]

On Saturday 17 December 2011, Aaron J. Seigo wrote:
> On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> > Hi all,
> > 
> > I think we should do a real documentation sprint for the plasma
> > qtcomponents, to have a good api doc for the 4.8 release.
> 
> and ideas / preferences on when and where?

well, was actually more thinking about an irc meeting, kinda like bugdays, 
next week (or after the christmasy things if better for people)

to get all documented and at least a tutorial with pretty pictures on the wiki

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

Re: qtcomponents documentation

[Daker Fernandes Pinheiro]

That's fine for me.

Marco,

I'm still working on the branch, should I submit the changes into it or 
directly in master?

Cheers,

On Saturday, December 17, 2011 02:11:06 PM Marco Martin wrote:
> On Saturday 17 December 2011, Aaron J. Seigo wrote:
> > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> > > Hi all,
> > > 
> > > I think we should do a real documentation sprint for the plasma
> > > qtcomponents, to have a good api doc for the 4.8 release.
> > 
> > and ideas / preferences on when and where?
> 
> well, was actually more thinking about an irc meeting, kinda like bugdays,
> next week (or after the christmasy things if better for people)
> 
> to get all documented and at least a tutorial with pretty pictures on the
> wiki

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

Re: qtcomponents documentation

[Aaron J. Seigo]

On Saturday, December 17, 2011 18:11:06 Marco Martin wrote:
> On Saturday 17 December 2011, Aaron J. Seigo wrote:
> > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> > > Hi all,
> > > 
> > > I think we should do a real documentation sprint for the plasma
> > > qtcomponents, to have a good api doc for the 4.8 release.
> > 
> > and ideas / preferences on when and where?
> 
> well, was actually more thinking about an irc meeting, kinda like bugdays,
> next week (or after the christmasy things if better for people)

perhaps set up a doodle for people to register their preferred times and then 
we can promote it on our blogs?

-- 
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: qtcomponents documentation

[Daker Fernandes Pinheiro]

Sounds like a good plan.

Daker Fernandes Pinheiro



2011/12/17 Aaron J. Seigo 

> On Saturday, December 17, 2011 18:11:06 Marco Martin wrote:
> > On Saturday 17 December 2011, Aaron J. Seigo wrote:
> > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> > > > Hi all,
> > > >
> > > > I think we should do a real documentation sprint for the plasma
> > > > qtcomponents, to have a good api doc for the 4.8 release.
> > >
> > > and ideas / preferences on when and where?
> >
> > well, was actually more thinking about an irc meeting, kinda like
> bugdays,
> > next week (or after the christmasy things if better for people)
>
> perhaps set up a doodle for people to register their preferred times and
> then
> we can promote it on our blogs?
>
> --
> 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: Review Request: Activities Dataengine: avoid calling KActivities::Controller::listActivities() unnecessarily

[Commit Hook]

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


This review has been submitted with commit 
480db607b4ec63108e18738eb2dfa51169dcd865 by Luiz Romário Santana Rios to branch 
master.

- Commit Hook


On Dec. 16, 2011, 12:25 a.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103358/
> ---
> 
> (Updated Dec. 16, 2011, 12:25 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Avoid calling listActivities to get the list of running activities everytime 
> by getting it once, storing it in a private member and modifying this member 
> as activities come and go.
> 
> 
> Diffs
> -
> 
>   plasma/generic/dataengines/activities/activityengine.h cbbf94c 
>   plasma/generic/dataengines/activities/activityengine.cpp 9436c34 
> 
> Diff: http://git.reviewboard.kde.org/r/103358/diff/diff
> 
> 
> Testing
> ---
> 
> Tested it now, removed some activities, added some more, stopped another 
> bunch, and it seems to work just fine as long as I tested.
> 
> 
> Thanks,
> 
> Romário Rios
> 
>

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

Re: Re: qtcomponents documentation

[Guillaume DE BURE]

Le samedi 17 décembre 2011 15:52:33 Daker Fernandes Pinheiro a écrit :
> Sounds like a good plan.
> 
> Daker Fernandes Pinheiro
> 
> 
> 
> 2011/12/17 Aaron J. Seigo 
> 
> > On Saturday, December 17, 2011 18:11:06 Marco Martin wrote:
> > > On Saturday 17 December 2011, Aaron J. Seigo wrote:
> > > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote:
> > > > > Hi all,
> > > > >
> > > > > I think we should do a real documentation sprint for the plasma
> > > > > qtcomponents, to have a good api doc for the 4.8 release.
> > > >
> > > > and ideas / preferences on when and where?
> > >
> > > well, was actually more thinking about an irc meeting, kinda like
> > bugdays,
> > > next week (or after the christmasy things if better for people)
> >
> > perhaps set up a doodle for people to register their preferred times and
> > then
> > we can promote it on our blogs?

Not sure whether I'll be able to help, but for what it's worth, I've started 
using these components in the skrooge plasma dashboard. So far, I've made 
progresses using source code, Daker's gallery, and his help on IRC. Having doc 
on this would be extremely helpful :)

> >
> > --
> > 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: Review Request: RSSNOW QML:reset the timer on click and some coding style fixes.

[Giorgos Tsiapaliwkas]

> On Dec. 16, 2011, 3:25 p.m., Aaron J. Seigo wrote:
> > try using inkscape rather than carbon for the svg changes.

it worked!!(no issues)

Because i can't create a diff of the removed files here,


diff --git a/applets/rssnow/CMakeLists.txt b/applets/rssnow/CMakeLists.txt
index 5762dbf..72be160 100644
--- a/applets/rssnow/CMakeLists.txt
+++ b/applets/rssnow/CMakeLists.txt
@@ -15,8 +15,7 @@ install(TARGETS plasma_applet_rssnow DESTINATION 
${PLUGIN_INSTALL_DIR})
 install(FILES plasma-applet-rssnow.desktop DESTINATION ${SERVICES_INSTALL_DIR})
 install(FILES feeds DESTINATION ${DATA_INSTALL_DIR}/rssnow)
 install(FILES
-left.svgz
-right.svgz
+arrows.svgz
 rssnow.svgz
 background.svgz
 DESTINATION ${DATA_INSTALL_DIR}/desktoptheme/default/rssnow/)
diff --git a/applets/rssnow/left.svgz b/applets/rssnow/left.svgz
deleted file mode 100644
index ca03cd3..000
Binary files a/applets/rssnow/left.svgz and /dev/null differ
diff --git a/applets/rssnow/right.svgz b/applets/rssnow/right.svgz
deleted file mode 100644
index c3c2285..000
Binary files a/applets/rssnow/right.svgz and /dev/null differ


$ git status

 
# On branch master
# Changes not staged for commit:
#   (use "git add/rm ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   applets/rssnow/CMakeLists.txt
#   deleted:applets/rssnow/left.svgz
#   deleted:applets/rssnow/right.svgz


i know it is lame..

should i push?


- Giorgos


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


On Dec. 16, 2011, 12:12 p.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103347/
> ---
> 
> (Updated Dec. 16, 2011, 12:12 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Hello,
> 
> the Timer component will reset to zero when the user clicks the arrows.
> Also i made some fixes in the coding style.
> 
> thanks in advance
> 
> 
> Diffs
> -
> 
>   rssnow/package/contents/ui/ListItemEntry.qml dac3f93 
>   rssnow/package/contents/ui/main.qml e39a1f6 
> 
> Diff: http://git.reviewboard.kde.org/r/103347/diff/diff
> 
> 
> Testing
> ---
> 
> everything is ok
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

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

Re: Re: Breadcrumbs in Kickoff

[Rick Stockton]

  
  
Martin, I have an idea- even though I never even looked at Kickoff.
(Before writing this, I SHOULD have looked - but I don't have time
right now.) It seems to me that all of the layout issues, and the
GUI focus issues, of doing a GUI "back button" can be avoided: Just
listen for a QMouseEvent with QMouseEvent::button() value of:
 'XButton1' == 'BackButton' == 'ExtraButton1', and execute "back!"
whenever the event occurs in valid context.

The names 'BackButton and 'ExtraButton1' aren't defined until Qt5,
but 'XButton1' is already present in Qt 4.7 (and many earlier 4.x
Releases, as well). Implementing this, Xavier (and others) would be
able to buy and use a mouse with Thumb buttons, "back" and
"forward", and just whack the buttons. No mouse movements at all,
and no GUI issues for us. Am I am guilty of "old style" thinking, or
does this enhancement make sense to you?

My feeling is like a famous statement, from one of the bad guys in a
famous 'Spaghetti Western': "GUI Buttons? We Don't need no stinkin'
GUI Buttons !!!"

(Perform an action on the Button Event, but leave the GUI scheme as
is: using breadcrumbs exclusively) 





On 01/-10/-28163 11:59 AM, Xavier Sythe wrote:
Actually, the breadcrumbs don't really need to be
  removed.
  I merely see the need to reinstate the back button.
  "I personally do not see any need for the back button any more."
  
  It's mostly a user experience perspective.
  
  It's a simple fact that it requires less mouse movement, hence,
  less time, to click the back button, then it does to move your
  mouse to the top of the menu, and use the breadcrumbs.  Why? 
  Because the back button extends all the way down the length of the
  menu.  Instead of having to move your mouse to the top of the
  menu, then to the left, you can simply move it to the left and
  click the button.
  
  
  "The
  breadcrumbs add high value to Kickoff. It makes navigation in a
  folder like
  structure like the application menu more convenient and much more
  consistant
  with other parts of KDE applications, e.g. Dolphin's..."
  
  Just like in Dolphin, this menu style would feature both
  breadcrumb navigation, and a back button.
  
  Would you support removing the back button from Dolphin, in favour
  of just breadcrumbs?
  I doubt that anyone would support that.
  
  I've chatted briefly with the KDE Usability Team, and they
  actually seemed to agree with me.
  
  Well some users might stick to the breadcrumb navigation, the
  majority of users from previous versions of KDE are accustomed to
  the back button, and appreciate its use, both in Kickoff as well
  as in Dolphin.  Including both types of navigation will ensure
  that nobody complains, and presumably, lead to a better overall
  user experience.
  
  Thanks,
  Xavier Sythe
  
  
  
  
  
  On Fri, Dec 16, 2011 at 2:12 PM, Martin
Gräßlin 
wrote:

  On Thursday 08 December 2011 16:01:33 Xavier
Sythe wrote:
> Nearly two months ago, I contacted him, and asked him
to reverse the
> controversial commit.
> He has yet to reply.
  
  Please understand that not each developer has the time to
  answer personal
  requests. You state yourself that it is controversial. Just
  imagine each user
  disliking the feature sending a mail to Kevin. That just
  doesn't scale.
  
  Asking to revert the feature is to be honest non-constructive
  criticism. Like
  all other decisions on the default user interface they are
  done with care. The
  breadcrumbs add high value to Kickoff. It makes navigation in
  a folder like
  structure like the application menu more convenient and much
  more consistant
  with other parts of KDE applications, e.g. Dolphin's
  breadcrumb navigation.
  
  Just because you (and others) dislike the new feature it does
  not justify to
  revert the commit. There are also users liking the feature, so
  how should we
  suit both groups? Now please don't state that we need an
  option for that. This
  is not possible as the code gets too complex and too difficult
  to maintain.
  >
> When I asked the #KDE IRC channel about this, I was
told to contact the
> members of this mailing list, to see if I could get the
commit reversed.
  
  Reverting the commit is clearly not an option. But what would
  you say about
  improving the

QML Activity List

[Luiz Romário Santana Rios]

Hello, list.

So, some time ago I started to try creating a list of the activities
in QML, using the org.kde.activities data engine. I achieved
something, but I had some problems and my idea was to make it a
PopupApplet, but it was broken in QML - and even in JS, I guess - at
the time. I tried to workaround it, but the result was rather ugly.
Some problems follow:

1 - As it's a regular applet trying to mimic a PopupApplet, it seems
out of place, as it occupies a bit more space than the needed for the
icon.
2 - The popup list with the activities appears anywhere except above the icon.
3 - The same popup list makes an entry in the taskbar.
4 - If I try to filter the sources in any way to show only the
activities, the list becomes empty; if I don't, a ghost entry,
corresponding to the source "Status", appears in the list.
5 - I don't know how to use the plasma style in the list, so the items
are ugly grey squares.
6 - I made the hover and click events change the colors of the items
in the list, to give them some hover effect, but the colors don't
change.

Anyway, it's been some time now that I made this applet, and I think I
should be using the Components by now, but I don't know where to start
or what to change in my applet and what is done wrong and right in it.
I don't know if I can send attachments to the list, so, since it's a
really small applet, I'm sending it via paste:

/
- metadata.desktop: http://paste.kde.org/175196/
- contents/
-- qml/
--- main.qml: http://paste.kde.org/175208/

(That's the directory tree)

Any help would be appreciated.

-- 
Luiz Romário Santana Rios
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel