date:20120316

Hi Mihai,

there has already been a lengthy discussion about breadcrumbs in Kickoff back
in December [1].

I don't think anyone is interested in having yet another discussion about that
topic.

Thanks.

Martin Gräßlin

[1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html

On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote:
> Hello,
>
> IMHO, when a user makes a request, he will not perform a market study
> on his demand. He knows his needs and he doesn't ask, nor speaks, for
> other users hand.
> I feel an important amount of stress from the developers part,
> regarding the code involved. From the user part this is unknown. As
> professional developer, the easy to use a feature is, the harder might
> be to implement in the code. When I became software developer, I've
> sworn to satisfy my customers, of course when possible and within the
> feasible limits. So, I would not reject a requested feature unless I
> have good technical reasons to prevent it, based on the argument of
> complexity of code. Of course, maintenance is a good reason to reject
> when not enough resources are present, in order to support that
> feature (is this the case?).
>
> So, as KDE user, I can't give any statistics, polls, whatever in favor
> or against this button.
> I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to
> _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut,
> when I need to jump over some elements in the path.
> So, the back button and breadcrumbs, although seem redundant, they are
> not, _to me_.
> I would use the 'back' button in 90% of cases.
> It is the very same case with Dolphin (the 'Up' button vs the path
> breadcrumbs), again, _for me_.
>
> BTW, not all users that miss the button will complain.
> Some devs say that these messages are lose of time for them. I can say
> using the breadcrumbs in the KickOff menu make me losing time too, for
> the sole reason it is unnatural _to me_ to use it there.
> Also, user feedback is not a lose of time.
>
> Although not many users express their gratitude for the developers
> work, because, _it seems_, the human nature is to complain about
> things not working or things not done.
> Sometimes it should happen. I _need_ to tell you, all the KDE team,
> that I love your work, some may say _imperfect_, but _great_ I say,
> knowing the effort you put in keeping it as close as possible to our
> needs.
> KDE is, _in my opinion_, well designed, flexible to be extended, clean
> and visually appealing. And OPEN.
> Making Plasma and Plasmoids is a good move. It's in the spirit of
> Linux and its customizability. I hope you keep up this good work for
> long.
>
> Thank you,
> Mike.
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


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: Breadcrumbs in Kickoff

2012-03-16 Thread Mark

On Fri, Mar 16, 2012 at 11:47 AM, Martin Gräßlin  wrote:

> Hi Mihai,
>
> there has already been a lengthy discussion about breadcrumbs in Kickoff
> back
> in December [1].
>
> I don't think anyone is interested in having yet another discussion about
> that
> topic.
>
> Thanks.
>
> Martin Gräßlin
>
> [1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html
>
> On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote:
> > Hello,
> >
> > IMHO, when a user makes a request, he will not perform a market study
> > on his demand. He knows his needs and he doesn't ask, nor speaks, for
> > other users hand.
> > I feel an important amount of stress from the developers part,
> > regarding the code involved. From the user part this is unknown. As
> > professional developer, the easy to use a feature is, the harder might
> > be to implement in the code. When I became software developer, I've
> > sworn to satisfy my customers, of course when possible and within the
> > feasible limits. So, I would not reject a requested feature unless I
> > have good technical reasons to prevent it, based on the argument of
> > complexity of code. Of course, maintenance is a good reason to reject
> > when not enough resources are present, in order to support that
> > feature (is this the case?).
> >
> > So, as KDE user, I can't give any statistics, polls, whatever in favor
> > or against this button.
> > I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to
> > _me_. Form _my_ point of view, breadcrumbs are also useful, as a
> shortcut,
> > when I need to jump over some elements in the path.
> > So, the back button and breadcrumbs, although seem redundant, they are
> > not, _to me_.
> > I would use the 'back' button in 90% of cases.
> > It is the very same case with Dolphin (the 'Up' button vs the path
> > breadcrumbs), again, _for me_.
> >
> > BTW, not all users that miss the button will complain.
> > Some devs say that these messages are lose of time for them. I can say
> > using the breadcrumbs in the KickOff menu make me losing time too, for
> > the sole reason it is unnatural _to me_ to use it there.
> > Also, user feedback is not a lose of time.
> >
> > Although not many users express their gratitude for the developers
> > work, because, _it seems_, the human nature is to complain about
> > things not working or things not done.
> > Sometimes it should happen. I _need_ to tell you, all the KDE team,
> > that I love your work, some may say _imperfect_, but _great_ I say,
> > knowing the effort you put in keeping it as close as possible to our
> > needs.
> > KDE is, _in my opinion_, well designed, flexible to be extended, clean
> > and visually appealing. And OPEN.
> > Making Plasma and Plasmoids is a good move. It's in the spirit of
> > Linux and its customizability. I hope you keep up this good work for
> > long.
> >
> > Thank you,
> > Mike.
> > ___
> > 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
>
>
Martin,

Things have changed quite a bit between the last discussion and now. Back
then the KDE version had both the breadcrumbs and the back button. Right
now we have a new KDE version that only has the breadcrumbs. So now is the
time when users start noticing something is different and that they perhaps
might miss something or not.

Back in December i fully agreed with you that the back button is redundant
and the breadcrumbs can be used just as well. However, right now since  KDE
4.8 was released I'm slowly realizing i miss something in the menu. I miss
an option to just go back.

No, i'm not trying to convince you that we need the full vertical bar back
to go back, that really seemed totally out of place anyway. But right now i
do think that having a back button would be better. The breadcrumbbar does
allow you to go back, but it's kinda making me thing when i press it "where
do i need to go back to, main menu or.." and i don't want to think about
that in a menu! I just want to go back.

Right now, to me, it even seems like the breadcrumbbar is out of place in a
menu. It's nice but just not working intuitively in a menu.
Perhaps we do need to have a new fresh discussion about it since the impact
is just becoming clear to the kde users now and in the coming months when
the next (K)Ubuntu and Fedora get released. Perhaps a topic on the kde
forum should be created.

You might think the back button is of no use, but others might think
differently. The discussion in december has shown that, now it's boiling up
again and it will boil up more once Kubuntu and Fedora have their next
release. The old situation wasn't perfect, but the current situation is not
perfect as well. We need something in between.

Kind regards,
Mark
_

Re: Review Request: [RFC]: Rename "Configure Window Behavior" to "Configure Window Management"

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

personally, i'm unsure why this menu entry is even there. imho people should 
simply go into system settings. this just makes one more place we have to 
manage which panels and in which order they are shown. is there really so much 
benefit to having it in the right click menu?

now, i say that as someone who uses that menu item fairly often. so for *me* it 
has value there as a shortcut, but i'm rarely using it as a *user* but as a 
*developer* and watching others use KWin it's not an often used entry either.

personally, despite my own use of this menu item, i think it's something best 
left to system settings.

- Aaron J. Seigo

On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104284/
> ---
> 
> (Updated March 15, 2012, 11:19 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> ---
> 
> Adding Plasma to get general feedback on this idea.
> 
> The context menu entry to "Configure Window Behavior" opens the
> configuration of the window manager and not about the window.
> In the past the shown configuration dialog only contained entries
> affecting the window behavior but that is no longer true for the
> complete KDE 4.x series since Desktop Effects had been added to
> the menu. This change in naming reflects the situation and should
> help to remove confusion.
> 
> 
> This addresses bug 249486.
> http://bugs.kde.org/show_bug.cgi?id=249486
> 
> 
> Diffs
> -
> 
>   kwin/useractions.cpp dfb6fd4 
> 
> Diff: http://git.reviewboard.kde.org/r/104284/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request: Add tool tips to Mouse Actions tool buttons


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

Ship it!


Ship It!

- Aaron J. Seigo


On March 16, 2012, 12:42 a.m., Christoph Feck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104295/
> ---
> 
> (Updated March 16, 2012, 12:42 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> The very nice Mouse Actions page in the Desktop Settings dialog shows 
> Configure/About/Remove icons on QToolButtons, but there is no text on hover 
> to tell the user what the buttons do. I suggest to add these simple tool tips.
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/mousepluginwidget.cpp be52fde 
> 
> Diff: http://git.reviewboard.kde.org/r/104295/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christoph Feck
> 
>

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

Re: Review Request: Remember current desktop when changing activity


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


generally looks good to me, save for one small issue.


service/ActivityManager.cpp


should also check for >= 0. also, this statement needs {}s, we use them 
even for single line conditionals :)


- Aaron J. Seigo


On March 16, 2012, 7:40 a.m., makis marimpis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104261/
> ---
> 
> (Updated March 16, 2012, 7:40 a.m.)
> 
> 
> Review request for KDE Runtime and Plasma.
> 
> 
> Description
> ---
> 
> Patches kactivitymanagerd to store (and restore back) the working current 
> directory when switching activities.
> 
> The activity-changing-behavior is as follows:
> 1.  Say you have two (or more activities) A and B.
> 2.  You are working on activity A on Desktop 4.
> 3.  You switch to activity B (and by default to Desktop 4).
> 4.  Change to Desktop 1.
> 5.  Go back to activity A and (by default) to Desktop 1, while it should move 
> you to Desktop 4 (this is where my patch kicks in).
> 
> I hope it makes sense :-)
> 
> 
> This addresses bugs 241864 and 265015.
> http://bugs.kde.org/show_bug.cgi?id=241864
> http://bugs.kde.org/show_bug.cgi?id=265015
> 
> 
> Diffs
> -
> 
>   service/ActivityManager.cpp 7af2049 
>   service/ActivityManager_p.h d054eb7 
> 
> Diff: http://git.reviewboard.kde.org/r/104261/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> makis marimpis
> 
>

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

Re: GSOC 2012 project: Make plasmate ready for release

On Thursday, March 15, 2012 18:19:17 Giorgos Tsiapaliwkas wrote:
> I was thinking to add the scp feature into plasmapkg and then plasmate to
> take it from there. What do you think?

that's a nice idea; that way any usage of plasmapkg could do this. neat.

-- 
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: Remember current desktop when changing activity

2012-03-16 Thread makis marimpis


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

(Updated March 16, 2012, 11:55 a.m.)


Review request for KDE Runtime and Plasma.


Changes
---

Update "if condition".


Description
---

Patches kactivitymanagerd to store (and restore back) the working current 
directory when switching activities.

The activity-changing-behavior is as follows:
1.  Say you have two (or more activities) A and B.
2.  You are working on activity A on Desktop 4.
3.  You switch to activity B (and by default to Desktop 4).
4.  Change to Desktop 1.
5.  Go back to activity A and (by default) to Desktop 1, while it should move 
you to Desktop 4 (this is where my patch kicks in).

I hope it makes sense :-)


This addresses bugs 241864 and 265015.
http://bugs.kde.org/show_bug.cgi?id=241864
http://bugs.kde.org/show_bug.cgi?id=265015


Diffs (updated)
-

  service/ActivityManager.cpp 7af2049 
  service/ActivityManager_p.h d054eb7 

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


Testing
---


Thanks,

makis marimpis

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

Re: Workflow Idea for 4.10

On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote:
> I've been thinking about the git workflow to be used in KDE Frameworks in
> the future. Based on observations and discussions with current and future
> frameworks maintainer, I think that it would be a mistake to force a single
> workflow for all the frameworks.

is this to make life better for the maintainer or the developers? 

one thing that git as used by kde has done so far for me is severely limit my 
"occasional hacker" pattern where i dive into a given app or library and do a 
bit of work to scratch an itch. this is because we now have a gajillion little 
repositories and as a result i rarely build them these days. this is in large 
part due to me having kdesrc-build around, but not really using it much. why? 
partly because it's a change in my workflow (that takes time) and in part 
because i now have two workflows: one for the KDE projects i work on a lot 
(where i do no use kdesrc-build, because it is not appropriate there) and 
those that i just track.

with the "let everyone pick a workflow" approach we'll be making this absurdely 
worse for Frameworks. i won't even know what workflow to be using when i work 
on a library, so wave goodbye to my involvement.

given that Frameworks really benefits from the occassional developers such as 
myself fixing things here and there, implementing missing functionality here 
and there, this should be taken seriously.

i know when i said in the past that my involvement with other projects would 
disipate due to the choices being made around git nobody really cared :) well, 
it's happened, i'm sure nobody still cares .. and that makes me sad. because 
i'm one of many. and by being too focused on tools and maintainers rather than 
developers we are screwing ourselves over.

please disabuse yourself of the notion of "maintainer chooses" and work on a 
single workflow that all of Frameworks will adhere to for the sanity of all 
future developers.

seriously, this is the "should we have a coding style?" discussion all over 
again, isn't it?

> [1] And before any "we should always branch" zealot cringe (not blaming you,
> been there as well), please take a few minutes and read[2]:
> http://martinfowler.com/bliki/FeatureToggle.html

i honestly can't imagine a worse idea for a library like libplasma.

-- 
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: Breadcrumbs in Kickoff

this is my last mail to this thread

On Friday 16 March 2012 12:29:45 Mark wrote:
> Things have changed quite a bit between the last discussion and now. Back
> then the KDE version had both the breadcrumbs and the back button. Right
> now we have a new KDE version that only has the breadcrumbs. So now is the
> time when users start noticing something is different and that they perhaps
> might miss something or not.
I'm not sure what you mean with things have changed... First of all the 
behavior had been changed for version 4.7 which got released in July 2011. 
Furthermore for us developers back in December the current version was already 
4.8.

If you read the discussion you probably noticed that there is work going on to 
rewrite Kickoff for 4.9. Given that I do not understand why we should discuss 
a user interface whose code will be dropped.

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: Breadcrumbs in Kickoff

On Friday, March 16, 2012 12:29:45 Mark wrote:
> but others might think differently.

here is the most useful bit of all three emails so far in the resurrected 
thread.

there is going to be no "right answer" because no matter what the choice is 
someone will differ. if we have both ways? "it's cluttered and hard to use". 
have one way? "the other way is better". yes, it will be different people 
objecting, but it's stile someone. and i'm going to assume you don't believe 
you are more valuable and important than others here. ;)

so here are our options:

* create a better view which does not replicate the problems of cascading 
menus or any of the other things the current view does improve on

* live with it

in either case, trying to peruade people with words is not useful in this 
particular situation because it is not words that are needed.

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: Help us finding the new name for Laptop window decoration

On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
> http://www.doodle.com/e9se6zuz8ufepxke

for those who voted for "simple": in what way is it "simple"?

--
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: Help us finding the new name for Laptop window decoration

2012-03-16 Thread Tomaz Canabrava

On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo  wrote:
> On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
>> http://www.doodle.com/e9se6zuz8ufepxke
>
> for those who voted for "simple": in what way is it "simple"?

No gradients, no shades, plain colors, flat.
Simple <3.

> --
> Aaron J. Seigo
> ___
> 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: [RFC]: Rename "Configure Window Behavior" to "Configure Window Management"



> On March 16, 2012, 11:45 a.m., Aaron J. Seigo wrote:
> > personally, i'm unsure why this menu entry is even there. imho people 
> > should simply go into system settings. this just makes one more place we 
> > have to manage which panels and in which order they are shown. is there 
> > really so much benefit to having it in the right click menu?
> > 
> > now, i say that as someone who uses that menu item fairly often. so for 
> > *me* it has value there as a shortcut, but i'm rarely using it as a *user* 
> > but as a *developer* and watching others use KWin it's not an often used 
> > entry either.
> > 
> > personally, despite my own use of this menu item, i think it's something 
> > best left to system settings.

A fair enough question. For me as a developer it is a must-have feature, though 
it does not need to be exposed that strongly (e.g. move to advanced submenu) or 
even adding a build option for it.

What I am unsure about is how much do we screw over the documentation teams. A 
google search on "Configure window behavior" KDE gives > 5000 results with 
references in books and so on. Search for the German translation gives another 
700 results. It is a feature for advanced users and already quite hidden. But I 
think for providing user support it's quite a useful feature.


- Martin


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


On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104284/
> ---
> 
> (Updated March 15, 2012, 11:19 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> ---
> 
> Adding Plasma to get general feedback on this idea.
> 
> The context menu entry to "Configure Window Behavior" opens the
> configuration of the window manager and not about the window.
> In the past the shown configuration dialog only contained entries
> affecting the window behavior but that is no longer true for the
> complete KDE 4.x series since Desktop Effects had been added to
> the menu. This change in naming reflects the situation and should
> help to remove confusion.
> 
> 
> This addresses bug 249486.
> http://bugs.kde.org/show_bug.cgi?id=249486
> 
> 
> Diffs
> -
> 
>   kwin/useractions.cpp dfb6fd4 
> 
> Diff: http://git.reviewboard.kde.org/r/104284/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Re: Help us finding the new name for Laptop window decoration

On Friday 16 March 2012 05:13:56 Tomaz Canabrava wrote:
> On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo  wrote:
> > On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
> >> http://www.doodle.com/e9se6zuz8ufepxke
> >
> > for those who voted for "simple": in what way is it "simple"?
>
> No gradients, no shades, plain colors, flat.
> Simple <3.
FTR: Laptop uses gradients. I checked before I decided whether Plastik or
Laptop should be kept for thin clients.

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: Help us finding the new name for Laptop window decoration

2012-03-16 Thread Tomaz Canabrava

On Fri, Mar 16, 2012 at 5:16 AM, Martin Gräßlin  wrote:
> On Friday 16 March 2012 05:13:56 Tomaz Canabrava wrote:
>> On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo  wrote:
>> > On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
>> >> http://www.doodle.com/e9se6zuz8ufepxke
>> >
>> > for those who voted for "simple": in what way is it "simple"?
>>
>> No gradients, no shades, plain colors, flat.
>> Simple <3.
> FTR: Laptop uses gradients. I checked before I decided whether Plastik or
> Laptop should be kept for thin clients.

Sigh. I use it and never realized that.
_
> 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: Help us finding the new name for Laptop window decoration

On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote:
> FTR: Laptop uses gradients.

there are gradients all over the laptop style, not to mention those "grippy"
stipples. :)

if one is looking for a gradient-free decoration i'd recommend "web" (only
real issue i fnd with web: the rounded corners need to turn into square ones
for maximized windows...).

i don't know how "thin client appropriate" was selected for in this case, but
i trust Martin enough not to worry about it and assume laptop's gradients,
etc. are not a problem there.

btw, is it just me or does it have drawing errors when there are spaces
between buttons?

--
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: Remember current desktop when changing activity

2012-03-16 Thread Ivan Čukić


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



service/ActivityManager.cpp


Why do you want to keep these in memory?


- Ivan Čukić


On March 16, 2012, 11:55 a.m., makis marimpis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104261/
> ---
> 
> (Updated March 16, 2012, 11:55 a.m.)
> 
> 
> Review request for KDE Runtime and Plasma.
> 
> 
> Description
> ---
> 
> Patches kactivitymanagerd to store (and restore back) the working current 
> directory when switching activities.
> 
> The activity-changing-behavior is as follows:
> 1.  Say you have two (or more activities) A and B.
> 2.  You are working on activity A on Desktop 4.
> 3.  You switch to activity B (and by default to Desktop 4).
> 4.  Change to Desktop 1.
> 5.  Go back to activity A and (by default) to Desktop 1, while it should move 
> you to Desktop 4 (this is where my patch kicks in).
> 
> I hope it makes sense :-)
> 
> 
> This addresses bugs 241864 and 265015.
> http://bugs.kde.org/show_bug.cgi?id=241864
> http://bugs.kde.org/show_bug.cgi?id=265015
> 
> 
> Diffs
> -
> 
>   service/ActivityManager.cpp 7af2049 
>   service/ActivityManager_p.h d054eb7 
> 
> Diff: http://git.reviewboard.kde.org/r/104261/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> makis marimpis
> 
>

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

Re: Re: Help us finding the new name for Laptop window decoration

On Friday 16 March 2012 13:48:02 Aaron J. Seigo wrote:
> On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote:
> > FTR: Laptop uses gradients.
>
> there are gradients all over the laptop style, not to mention those "grippy"
> stipples. :)
>
> if one is looking for a gradient-free decoration i'd recommend "web" (only
> real issue i fnd with web: the rounded corners need to turn into square ones
> for maximized windows...).
>
> i don't know how "thin client appropriate" was selected for in this case,
> but i trust Martin enough not to worry about it and assume laptop's
> gradients, etc. are not a problem there.
>
> btw, is it just me or does it have drawing errors when there are spaces
> between buttons?
no, it's not just you. I just enabled it and it shows the same bug as we know
from Plastik already. Ah bitrot is such a wonderful thing.

Given that I think we have to rethink the plan. Keeping Laptop instead of
Plastik is by that also no option :-(

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: Breadcrumbs in Kickoff

2012-03-16 Thread Mark

On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin  wrote:

> this is my last mail to this thread
>
> On Friday 16 March 2012 12:29:45 Mark wrote:
> > Things have changed quite a bit between the last discussion and now. Back
> > then the KDE version had both the breadcrumbs and the back button. Right
> > now we have a new KDE version that only has the breadcrumbs. So now is
> the
> > time when users start noticing something is different and that they
> perhaps
> > might miss something or not.
> I'm not sure what you mean with things have changed... First of all the
> behavior had been changed for version 4.7 which got released in July 2011.
> Furthermore for us developers back in December the current version was
> already
> 4.8.
>
> If you read the discussion you probably noticed that there is work going
> on to
> rewrite Kickoff for 4.9. Given that I do not understand why we should
> discuss
> a user interface whose code will be dropped.
>
> Cheers
> Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Jup, i'm mixing up versions again :)
It's difficult for me to keep track of which thing changed where when i'm
experimenting with the code, using git for some other parts and
the distribution version for the remaining part.

I know that there is going to be a QML version of kickoff that you're
making and that rocks!

As Aaron said, there is no "right answer" here and i honestly don't know
what's the best way to go. The current situation isn't ideal, the future
situation isn't ideal and it never was ideal, so i guess we should just
"live with it" for the time being.

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

Re: Review Request: Remember current desktop when changing activity

2012-03-16 Thread makis marimpis



> On March 16, 2012, 12:49 p.m., Ivan Čukić wrote:
> >

Hm, i did that in order to restore the desktop ids from a previous run of kamd 
(let's say, in case of log out).


- makis


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


On March 16, 2012, 11:55 a.m., makis marimpis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104261/
> ---
> 
> (Updated March 16, 2012, 11:55 a.m.)
> 
> 
> Review request for KDE Runtime and Plasma.
> 
> 
> Description
> ---
> 
> Patches kactivitymanagerd to store (and restore back) the working current 
> directory when switching activities.
> 
> The activity-changing-behavior is as follows:
> 1.  Say you have two (or more activities) A and B.
> 2.  You are working on activity A on Desktop 4.
> 3.  You switch to activity B (and by default to Desktop 4).
> 4.  Change to Desktop 1.
> 5.  Go back to activity A and (by default) to Desktop 1, while it should move 
> you to Desktop 4 (this is where my patch kicks in).
> 
> I hope it makes sense :-)
> 
> 
> This addresses bugs 241864 and 265015.
> http://bugs.kde.org/show_bug.cgi?id=241864
> http://bugs.kde.org/show_bug.cgi?id=265015
> 
> 
> Diffs
> -
> 
>   service/ActivityManager.cpp 7af2049 
>   service/ActivityManager_p.h d054eb7 
> 
> Diff: http://git.reviewboard.kde.org/r/104261/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> makis marimpis
> 
>

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

Re: Help us finding the new name for Laptop window decoration

2012-03-16 Thread J Janz

I guess simple suffers from the same problem of Lightweight, sending the
wrong message about oxygen: oxygen is complex, dificult? It isn't said
where the simplicity is, which is only about its graphics. Simple Graphics,
maybe?

IMHO, Thin says it better.
--
J (|´:¬{)»
-
"Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá;
e todo o que vive e crê em mim não morrerá, eternamente. Crês isto?"
O Senhor, Jesus Cristo - Jo.11:25-26
-


Em 16 de março de 2012 09:06, Aaron J. Seigo  escreveu:

> On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
> > http://www.doodle.com/e9se6zuz8ufepxke
>
> for those who voted for "simple": in what way is it "simple"?
>
> --
> Aaron J. Seigo
> ___
> 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: Re: Help us finding the new name for Laptop window decoration

On Friday 16 March 2012 13:54:24 Martin Gräßlin wrote:
> On Friday 16 March 2012 13:48:02 Aaron J. Seigo wrote:
> > On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote:
> > > FTR: Laptop uses gradients.
> >
> > there are gradients all over the laptop style, not to mention those
> > "grippy" stipples. :)
> >
> > if one is looking for a gradient-free decoration i'd recommend "web" (only
> > real issue i fnd with web: the rounded corners need to turn into square
> > ones for maximized windows...).
> >
> > i don't know how "thin client appropriate" was selected for in this case,
> > but i trust Martin enough not to worry about it and assume laptop's
> > gradients, etc. are not a problem there.
> >
> > btw, is it just me or does it have drawing errors when there are spaces
> > between buttons?
>
> no, it's not just you. I just enabled it and it shows the same bug as we
> know from Plastik already. Ah bitrot is such a wonderful thing.
>
> Given that I think we have to rethink the plan. Keeping Laptop instead of
> Plastik is by that also no option :-(
I requested a mockup for a new deco from Nuno and will try to find someone to
implement it.

Will update the Review Request accordingly to also drop Laptop.

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: Workflow Idea for 4.10

2012-03-16 Thread Kevin Ottens

On Friday 16 March 2012 12:58:56 Aaron J. Seigo wrote:
> On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote:
> > I've been thinking about the git workflow to be used in KDE Frameworks in
> > the future. Based on observations and discussions with current and future
> > frameworks maintainer, I think that it would be a mistake to force a
> > single
> > workflow for all the frameworks.
>
> is this to make life better for the maintainer or the developers?

Both really...

If I was still maintaining libsolid for instance (so putting virtual
maintainer hat), the very nature of it would make me think that not going for
feature branches followed by merges in an integration branch would be
dangerous (and libplasma, akonadi, kio are in a similar corner I think) and
harder for me to test and review. As a developer? Yes, maybe a bit more work
than putting stuff into master, but comparatively to the complexity of the
component it's understandable.

Now, if I want to contribute a feature in karchive (or kdbusaddons,
kplotting), as a developer it'd look silly to me to have to publish a branch,
get it merged in an integration branch, push the result, wait for approval and
then get that merged in master. Hmm, also probably makes it more work for the
maintainer who'd need to test both the feature branch and the integration
branch to be able to give a enlightened go/no-go. With the low complexity of
something like karchive, everyone would be way better off with a private
branch on the developer side and publishing on reviewboard or discussing on a
pastebin over IRC.

And we have such different products in frameworks. I don't feel like forcing
inadequate workflows on them for the sake of it.

> one thing that git as used by kde has done so far for me is severely limit
> my "occasional hacker" pattern where i dive into a given app or library and
> do a bit of work to scratch an itch. this is because we now have a
> gajillion little repositories and as a result i rarely build them these
> days. this is in large part due to me having kdesrc-build around, but not
> really using it much. why? partly because it's a change in my workflow
> (that takes time) and in part because i now have two workflows: one for the
> KDE projects i work on a lot (where i do no use kdesrc-build, because it is
> not appropriate there) and those that i just track.

Of course transition takes time. Now, I wonder what blocks you with kdesrc-
build though. I personally manage to use it for everything just fine, it's
just that when I jump on a module to work on it I trigger "make" as usual.
Didn't find it disruptive, but I might be missing something.

> with the "let everyone pick a workflow" approach we'll be making this
> absurdely worse for Frameworks. i won't even know what workflow to be using
> when i work on a library, so wave goodbye to my involvement.

Sure, but there's really no good answer here. It's either "Meh, absurd
workflow for this component I'm too lazy to comply to it, wave goodbye to my
involvement" or "Meh, I've to look up the workflow used here I'm too lazy to
do it, wave goodbye to my involvement".

(Of course replace "lazy", by "overworked", "overcommitted", "overwhelmed" as
you see fit)

Now if someone can point me to a workflow which will work on all the spectrum
of components without creating absurd bureaucracy in more than 30% of the
cases I'm all ears. Currently I don't have one.

> given that Frameworks really benefits from the occassional developers such
> as myself fixing things here and there, implementing missing functionality
> here and there, this should be taken seriously.

And it is, but see above.

> i know when i said in the past that my involvement with other projects would
> disipate due to the choices being made around git nobody really cared :)
> well, it's happened, i'm sure nobody still cares .. and that makes me sad.
> because i'm one of many. and by being too focused on tools and maintainers
> rather than developers we are screwing ourselves over.

I'm definitely not focused on tools, hoped my previous email made that clear.

> please disabuse yourself of the notion of "maintainer chooses"

I'll just add a few more thoughts regarding that because of your first
question in this email, which I think was a bait to make me claim that it's to
allow the maintainer to make his life easier against the developer comfort (in
case anyone still wonder: no it's not the motive).

As I tried to make clear above, I think what's critical is to have for a given
component the right workflow for it. The nature of the components varying
greatly, their needs regarding the workflow vary as well. So a workflow will
have to balance quality of the outcome vs level of bureaucracy.

Now the component itself not being able to tell us what workflow fits best, we
have to rely on someone ultimately making the choice. And here the assumption
is that the maintainer is among the people with the best overview of the
component hence relying on

Re: Re: Breadcrumbs in Kickoff

2012-03-16 Thread Djuro Drljaca

Hello,

well if there is going to be a QML version ... then the solution is simple
since you just have to change the QML file if you don't like the default
solution.

Regards,
Djuro Drljaca

On Fri, Mar 16, 2012 at 1:54 PM, Mark  wrote:

> On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin wrote:
>
>> this is my last mail to this thread
>>
>> On Friday 16 March 2012 12:29:45 Mark wrote:
>> > Things have changed quite a bit between the last discussion and now.
>> Back
>> > then the KDE version had both the breadcrumbs and the back button. Right
>> > now we have a new KDE version that only has the breadcrumbs. So now is
>> the
>> > time when users start noticing something is different and that they
>> perhaps
>> > might miss something or not.
>> I'm not sure what you mean with things have changed... First of all the
>> behavior had been changed for version 4.7 which got released in July 2011.
>> Furthermore for us developers back in December the current version was
>> already
>> 4.8.
>>
>> If you read the discussion you probably noticed that there is work going
>> on to
>> rewrite Kickoff for 4.9. Given that I do not understand why we should
>> discuss
>> a user interface whose code will be dropped.
>>
>> Cheers
>> Martin
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
> Jup, i'm mixing up versions again :)
> It's difficult for me to keep track of which thing changed where when i'm
> experimenting with the code, using git for some other parts and
> the distribution version for the remaining part.
>
> I know that there is going to be a QML version of kickoff that you're
> making and that rocks!
>
> As Aaron said, there is no "right answer" here and i honestly don't know
> what's the best way to go. The current situation isn't ideal, the future
> situation isn't ideal and it never was ideal, so i guess we should just
> "live with it" for the time being.
>
> Regards,
> Mark
>
> ___
> 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: [RFC]: Rename "Configure Window Behavior" to "Configure Window Management"



> On March 16, 2012, 11:45 a.m., Aaron J. Seigo wrote:
> > personally, i'm unsure why this menu entry is even there. imho people 
> > should simply go into system settings. this just makes one more place we 
> > have to manage which panels and in which order they are shown. is there 
> > really so much benefit to having it in the right click menu?
> > 
> > now, i say that as someone who uses that menu item fairly often. so for 
> > *me* it has value there as a shortcut, but i'm rarely using it as a *user* 
> > but as a *developer* and watching others use KWin it's not an often used 
> > entry either.
> > 
> > personally, despite my own use of this menu item, i think it's something 
> > best left to system settings.
> 
> Martin Gräßlin wrote:
> A fair enough question. For me as a developer it is a must-have feature, 
> though it does not need to be exposed that strongly (e.g. move to advanced 
> submenu) or even adding a build option for it.
> 
> What I am unsure about is how much do we screw over the documentation 
> teams. A google search on "Configure window behavior" KDE gives > 5000 
> results with references in books and so on. Search for the German translation 
> gives another 700 results. It is a feature for advanced users and already 
> quite hidden. But I think for providing user support it's quite a useful 
> feature.
>

i don't agree that providing support is any easier or harder than starting with 
"start system settings" (which is more consistent of an approach, but not as 
immediate as right clicking on a title bar), but i do agree that the 
documentation references are a killer. for that reason i withdraw my proposal.


- Aaron J.


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


On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104284/
> ---
> 
> (Updated March 15, 2012, 11:19 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> ---
> 
> Adding Plasma to get general feedback on this idea.
> 
> The context menu entry to "Configure Window Behavior" opens the
> configuration of the window manager and not about the window.
> In the past the shown configuration dialog only contained entries
> affecting the window behavior but that is no longer true for the
> complete KDE 4.x series since Desktop Effects had been added to
> the menu. This change in naming reflects the situation and should
> help to remove confusion.
> 
> 
> This addresses bug 249486.
> http://bugs.kde.org/show_bug.cgi?id=249486
> 
> 
> Diffs
> -
> 
>   kwin/useractions.cpp dfb6fd4 
> 
> Diff: http://git.reviewboard.kde.org/r/104284/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request: Misc Fixes in Plasma Components Gallery


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

Ship it!


Ship It!

- Aaron J. Seigo


On March 16, 2012, 1 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104296/
> ---
> 
> (Updated March 16, 2012, 1 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Add margin on edge of main page
> Set default gallery page to the first entry in the menu (Buttons)
> Don't overlap main page with scrollbars
> Add clipping on main page for nicer animation between pages so it doesn't 
> overlap the sidebar
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/test/gallery/Gallery.qml 8a74f96 
> 
> Diff: http://git.reviewboard.kde.org/r/104296/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request: Save scrollbar position on plasma exit

2012-03-16 Thread Ignat Semenov


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

(Updated March 16, 2012, 1:47 p.m.)


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


Changes
---

Call discardScrollbarRestore() directly from 
AbstractItemView::scrollBarActionTriggered().


Description
---

This patch implements scrolbar position saving on plasma exit. The change is 
fairly trivial, however, due to the fact that the view is not populated and 
layouted immediately simply scrolling to the desired position on creating the 
view does not work. Instead a signal is emitted on finishing the item layout, 
when the view has a valid size and the scrollbar has a valid range. The signal 
is connected to a slot which scrolls the view to the desired position and then 
disconnects the signal. For the user, a public function in AbstractItemView is 
introduced, which performs the connection.

The only problem is that ListView turned out not to have any layout method. It 
just paints the items one by one, calculating their position on the fly, so I 
put the signal at the end of updateScrollbar to ensure the scrollbar range is 
valid. Maybe it should go into the "if (max>0)" branch?


This addresses bug 261139.
http://bugs.kde.org/show_bug.cgi?id=261139


Diffs (updated)
-

  plasma/applets/folderview/abstractitemview.h aa68b90 
  plasma/applets/folderview/abstractitemview.cpp 3debb70 
  plasma/applets/folderview/folderview.h 4e441eb 
  plasma/applets/folderview/folderview.cpp a94ce87 
  plasma/applets/folderview/iconview.h 12e93b3 
  plasma/applets/folderview/iconview.cpp 5c4e086 
  plasma/applets/folderview/listview.cpp 94efe44 

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


Testing
---

Tested both the icon view and the list view, works fine.


Thanks,

Ignat Semenov

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

Re: Re: Help us finding the new name for Laptop window decoration


Am 16.03.2012, 13:54 Uhr, schrieb Martin Gräßlin :


btw, is it just me or does it have drawing errors when there are spaces
between buttons?
no, it's not just you. I just enabled it and it shows the same bug as we  
know

from Plastik already. Ah bitrot is such a wonderful thing.


Seems it simply assumes  a prefilled background, I'll have a look and fix  
that in no minutes in case Nun has no supergreat idea for another deco ;-)
The gradients should be no problem, from a rough look they're precached in  
factory pixmaps on init and thus there's little transfer (kwin isn't  
started /that/ often during a session.
Of course that implies the native graphicssystem but if you use the raster  
graphicssystem on a remote session, you got other stuff to worry about.


Semi OT and OL:
Should we "reactivate" the phase style as complement (have a short look on  
it's pixmap transfer overhead) and suppress the Qt built-in styles in the  
style kcm?



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

Re: Help us finding the new name for Laptop window decoration

2012-03-16 Thread Christoph Feck

On Friday 16 March 2012 16:42:35 Thomas Lübking wrote:
> The gradients should be no problem, from a rough
> look they're precached in factory pixmaps on init and thus there's
> little transfer

The whole point of a net-friendly window decoration is to not transfer 
bitmaps, but simple fillRect/drawRect calls. As such, if it uses 
gradients at all, it should not cache them.

Christoph Feck (kdepepo)
KDE Quality Team
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Help us finding the new name for Laptop window decoration

Am 16.03.2012, 16:42 Uhr, schrieb Thomas Lübking  
:


Seems it simply assumes  a prefilled background, I'll have a look and  
fix that in no minutes in case Nuno has no supergreat idea for another  
deco ;-)


Mehhh ... it inherits KCommonDecoration
-> in case we still intend to drop that thing, we'll better write a new  
deco from scratch - so let Nuno flow his mind.


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

Re: Help us finding the new name for Laptop window decoration


Am 16.03.2012, 16:51 Uhr, schrieb Christoph Feck :


The whole point of a net-friendly window decoration is to not transfer
bitmaps, but simple fillRect/drawRect calls. As such, if it uses
gradients at all, it should not cache them.


If QPixmap is not entirely stupid, the pixmap is stored on the server,  
yesno?

Thus you get no overhead.

QGradient however (still?, i think so) internally swaps to the raster  
engine (because some drivers still *STILL* cannot XRenderCreate*Gradient)  
ie. paints into an image and XPutImage's that to the server :-(


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

Re: Help us finding the new name for Laptop window decoration


Am 16.03.2012, 16:51 Uhr, schrieb Christoph Feck :


qpaintengine_x11.cpp has (even) linear gradients deactivated :-(
http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/painting/qpaintengine_x11.cpp#line441

I know that this used to be an fglrx issue, maybe we should check for an  
update and in doubt *finally* enable the feature in Qt?


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

Re: Review Request: Save scrollbar position on plasma exit

2012-03-16 Thread Ignat Semenov


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

(Updated March 16, 2012, 4:31 p.m.)


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


Changes
---

Avoid race condition between layoutFinished() and restoreScrollBarPosition().

Connect restoreScrollBarPosition() and scrollToSavedPosition() in the 
AbstractItemView ctor. Introduce 
AbstractItemView::setSavedScrollbarPosition(int) and call that before setModel 
in teh view setup methods in FolderView.


Description
---

This patch implements scrolbar position saving on plasma exit. The change is 
fairly trivial, however, due to the fact that the view is not populated and 
layouted immediately simply scrolling to the desired position on creating the 
view does not work. Instead a signal is emitted on finishing the item layout, 
when the view has a valid size and the scrollbar has a valid range. The signal 
is connected to a slot which scrolls the view to the desired position and then 
disconnects the signal. For the user, a public function in AbstractItemView is 
introduced, which performs the connection.

The only problem is that ListView turned out not to have any layout method. It 
just paints the items one by one, calculating their position on the fly, so I 
put the signal at the end of updateScrollbar to ensure the scrollbar range is 
valid. Maybe it should go into the "if (max>0)" branch?


This addresses bug 261139.
http://bugs.kde.org/show_bug.cgi?id=261139


Diffs (updated)
-

  plasma/applets/folderview/abstractitemview.h aa68b90 
  plasma/applets/folderview/abstractitemview.cpp 3debb70 
  plasma/applets/folderview/folderview.h 4e441eb 
  plasma/applets/folderview/folderview.cpp a94ce87 
  plasma/applets/folderview/iconview.h 12e93b3 
  plasma/applets/folderview/iconview.cpp 5c4e086 
  plasma/applets/folderview/listview.cpp 94efe44 

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


Testing
---

Tested both the icon view and the list view, works fine.


Thanks,

Ignat Semenov

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

i recently merged some new runners into master kdeplasma-addons
without a review and i apologize for that (the motivation actually was
because i was having some difficulties making some packages and had a
few repos that needed it, but that's moot now).

either way, i've got the tar if you've got the feathers ;-)

i can file a formal review request if that makes things easier. i will
do so later for the non-merged duckduckgo runner, so as to not repeat
the same mistake.

but the only things of interest here are the youtube and bing runners.
the bing one is the same exact thing, except for bing obviously.

https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/entry/runners/youtube/youtube.cpp

https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/entry/runners/youtube/tubejob.cpp

the code's relatively straight forward, because json > xml ;)

the reason why i had to use bing for image searching is because google
is evil and their api has some silly 1k queries/day/key limit, which
we could easily outcap. and ironically, bing doesn't have any limits
on their api. i'm probably going to work on a flickr runner as well,
because we need more integration with the internets.

i do have a question however, as to why matches get triggered (even
for the mediawiki engine which currently resides in there, afict),
even though it isn't in singlerunnermode, and the prefix isn't being
hit. e.g. user is typing in "some query" would trigger a match for
that runner, instead of it only being triggered by "wiki some query".
any ideas on that?

seems like a waste of resources if it is in fact unnecessary.

there is an issue with the icon being installed though. i copied the
icons from some kipi plugin, because they also happened to have a
youtube icon set so that saved time.

however, it now means we have 2 sets of icons being installed. also,
i'm installing the icons simply by running: kde4_install_icons(
${ICON_INSTALL_DIR} )

is there a good fix for this?

--
Shaun Reich,
KDE Software Developer (kde.org)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workflow Idea for 4.10

2012-03-16 Thread Alexander Neundorf

On Friday 16 March 2012, Kevin Ottens wrote:
> Hello,
> 
> On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote:
> > [...]
> > this is what really piques my interest: merge based workflow.
> > 
> > an integration branch would be fantastic. that branch should rebase
> > periodically off of master and only be used to merge feature branches.
> > this branch would largely take the place of current master: where
> > development "happens". feature branches should be merged into
> > integration on a regular basis and developers and testers should track
> > this integration branch in their day-to-day usage
> > 
> > integration should always be open to feature branch merging. master
> > should only be open for feature merge when not in freeze, however.
> > 
> > when in freeze, either a stabilization branch could be made off of master
> > for this purpose (probably a very good idea for larger fixes) which is
> > then merged down in master at known good points .. or .. master is
> > opened for bug fixes directly in those periods. the latter is probably
> > not as "good" from a stability POV, but may be more reasonable and less
> > of a workload for people doing the actual work.
> > 
> > so what i'm interested in hearing is what sort of branch management
> > scheme would work for people. i'm happy to maintain either an
> > integration or the master branch (but not both).
> > [...]
> > 
> > note that the methods being (slowly) adopted for frameworks devel are
> > also moving in the direction noted above.
> 
> I'd just like to add my 0.02€ here.
> 
> I've been thinking about the git workflow to be used in KDE Frameworks in
> the future. Based on observations and discussions with current and future
> frameworks maintainer, I think that it would be a mistake to force a
> single workflow for all the frameworks. I'm not 100% sure what the final
> solution will be but it's likely to end up being a short list of blessed
> workflows: 1) Full game, one branch per feature with review time in an
> integration/testing branch before hitting master;
>  2) Intermediate, one branch per feature with merge in master after
> reviewers/maintainer validation;
>  3) Easy, features directly developped in master[1].

Sounds good.
But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) 
would be also a really good thing to have. It will make contributing easier.
Would 2) be an option for KDE frameworks ?


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

Re: request for review