System tray notification

[Andras Mantia]

Hi,

 I don't write a bug report, as this is not a bug in itself, just something 
that seems to be badly designed. Or maybe it is still unfinished, in that 
case ignore the mail.
 The idea of keeping the notifications visible for a longer time makes sense 
and I support it. The way how it works now (as of 29/11/2009) unfortunately 
is not good. The problem is that the notifications remain there for too long 
time. Example: you get a mail in some folder and you get notified. You read 
it. After a while you get another mail in another folder, you get notified, 
but in the notifications it appears as you'd get a mail in the first folder 
as well. But there isn't anything new, so it is misleading and confuses you, 
the user. I know, the notification item cannot know that you read a mail. 
And I know that expiring the notifications after a certain time is not that 
good, as we loose the functionality for which this was introduced: to be 
able to read the notifications later, when you have time for them.
 I have a solution, but I don't know how it will work in real life: if you 
manually click to see the notifications, when they disappear they should be 
removed completely, assuming that if you clicked on the icon to see them, 
you really read them as there is no reason keeping them "forever".
 Alternatively (or maybe together with this), I'd recommend an option, even 
if it is a hidden, config file option only, to restore the old behavior of 
clearing the notifications after they were shown (or after X minutes), so if 
it turns out that the current way is not good enough, for 4.4 we can have a 
not annoying notification area.

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

Re: System tray notification

[Andras Mantia]

Marco Martin wrote:
> true, the problem is that sophisticate communication like "the mail
> associated to that notification has been read" is totally impossible in
> the spec (and probably quite out of scope too, since it would require too
> much burden to the applications themselves, situation that would make sure
> it would be misused)

Sure, I know, and I don't expect to solve it that way. I just pointed out 
what is the problem from the users POV.

> what i think could be done is, when exploring old notifications with the
> tabbar, they could be marked as "read" and the subsequent time they will
> all appear collapsed, while the "new" ones expanded as usual

Yes, that's what I suggested.

> they are not kept "forever" but half an hour. what is still to be done is
> to make the expire time dependant whether the computer is in use or not,
> like it's already done with the job progress

I don't know what should be done. Probably if the notifications appear while 
the computer is idle (eg. screensaver is running), they should not 
disappear. If it in uses, I think half an hour is just too much, several 
minutes should be enough. I was annoyed with the old behavior when I saw a 
notification, but didn't have time to read it, but I don't think I'd be 
interested in notifications from half an hour ago. 5-10 minutes might work 
better. Of course, this is my opinion, in the (old) KDE spirit, I'd ask for 
a configurable timeout. ;) (Yes, a good default is better.)

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

Re: System tray notification

[Andras Mantia]

Andreas Marschke wrote:

> AFAIK the notifications do have a clickable cross in the upper corner and
> a dragable title bar so basically no worries right?
> 

Happy clicking on them. :) Obviously that doesn't work if you have 
notifications for mail folder or RSS feeds with fairly high traffic. You 
would end up clicking on X a lot. I know, I tried. ;)
 Now I'm compiling the latest version to test Marco's commit, thanks for it.

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

Re: Notifications not automatically hidden anymore

[Andras Mantia]

Hi,

 I've been testing and evaluating the current behavior of the systray 
notifications, and I have to admit, that I still don't like it.
Now that the notifications are cleared after 5 minutes when using the 
computer is better, but not enough, and I agree with this statement:
Aleix Pol wrote:

> But this carries some problems:
> - now the number under the actions (i don't know the name) becomes
> useless. 

 I always have there a number. It doesn't mean anything for me now, as I 
can't remember if the number has increased or decreased. That wouldn't help 
either, as maybe 1 message expired, and 1 new appeared. 
 One suggestion might be that if you looked at the notifications, instead of 
just collapsing it, remove completely them. Or don't count them in the 
number shown. 


> - This "recent notifications" item is always shown but not providing any
> input (just interaction). What was nice about notifications was that it
> didn't need much interaction.
I agree with this sentence.
 
Andras
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The future of Power Management - together with Activities

[Andras Mantia]

On Saturday, October 01, 2011 16:27:48 Dario Freddi wrote:
> Hello all, and sorry for cross-posting.
>  [...]

I can't comment on activities, never used them, nor feel the need to use 
them. So this sounds more like the power management applet would force 
me to create and use activites.
 What I can say that I use the selection combo between the different 
power management schemes from time to time, as I can do the same thing 
(e.g developing so not anything like now I develop and then switch to 
mail reading/watching a movie), but depending on the battery status and 
the known time until I can recharge the battery, I can tweak the power 
management setting. There is no way any software could guess when will I 
be able to recharge my battery. 

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

Re: The future of Power Management - together with Activities

[Andras Mantia]

[Please reply on both lists if you cross-posted, otherwise dicussion will be 
more fragmented. I just looked up the plasma list out of curiosity, normally 
I don't follow, so your mail would have been missed.]

Dario Freddi wrote:

>> I can't comment on activities, never used them, nor feel the need to use
>> them. So this sounds more like the power management applet would force
>> me to create and use activites.
> 
> Well, if you like to see it that way, yes. Or better, we are trying to
> drive forward the concept of "one environment, one setting", where
> depending on what you do, the system is going to adapt.

I don't like if software forces me to work in a certain way. And with 
activities I'm not alone. I'm happy without them, even if they are useful 
for others. Just as I'm mostly happy also without virtual desktops (which 
are a must for others). People are different, they have different workflows 
that they don't want to change if there is no *good* reason to do it.

> There is still a rationale behind that. If you are in a situation where
> you are actually *using* your PC, the only setting available (at the
> moment) which is going to affect your battery life is brightness -
> everything else is depending on the idle time, and in an emergency
> situation one would simply close the lid and suspend straight away.

Is it? Certainly disabling desktop effects and 3D acceleration has an 
impact. And there are other things like when to suspend automatically (if do 
it at all), when to dim the display, etc. I remember some time ago there was 
also a possibility to set how fast a CPU would run or throttle down a CPU 
manually, but I can't see anything like that in the current applet.
So I think there are more settings then display brightness (that you usually 
can control anyway with an Fn shortcut on laptops).
If we only talk about the above, and my development example (e.g travelling 
in an airplane): I know my travel takes 1 hour, my battery can last 2 hours, 
so I want to use the laptop just as plugged into the wall. I start it, but 
then it becomes clear there is a delay, so I need to save battery life. 
Right now I just select a new profile, everything else remains the same on 
the desktop. Why would I need to switch to a new activity in such case? My 
work will be the same, just the conditions change.
Or while developing I realize I compile more often then needed and this 
takes more power. So I need to save power in other way, again this would be 
possible with a simple change in the applet.
Please, keep this option. Having a way to control the power magament setting 
per activity is fine, but leave the possibility to change (and configure) 
the settings without having to use activities.

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

Re: The future of Power Management - together with Activities

[Andras Mantia]

On Saturday, October 01, 2011 23:13:06 Dario Freddi wrote:
> > Is it? Certainly disabling desktop effects and 3D acceleration has
> > an
> > impact.
> 
> Sorry to disappoint you, but this action will be removed in 4.8.
> Martin has explicitely stated that for how compositing in KDE works
> now turning off compositing is actually going to harm your battery
> instead of saving it - feel free to get in touch with him to expand
> on this topic, which is not exactly relevant to this discussion.

That was one example. Another example brought up is e.g switching of 
strigi or nepomuk indexing when switching to a power saving profile. 
These two are something that usually kick in when you are in idle mode, 
exactly when the battery power could be saved. Of course, with good 
default profiles this can be solved.

> > And there are other things like when to suspend automatically (if
> > do it at all), when to dim the display, etc.
> 
> I agree, but are you sure you need to configure these things
> separately depending on where you are? If you are, say, working on a
> train, you're very likely to never be idle, and to suspend the PC on
> your own by closing the lid when not active to save the most power.
> How can a different profile help you here?

What I said that I might manually need to switch to a different profile 
independent of what the battery power *currently* is and without 
switching my workflow/applications. Because I know in advance (before the 
software can find this out from the battery level dropping down) how much 
time I need the computer running. 

> 
> > So I think there are more settings then display brightness (that
> > you usually can control anyway with an Fn shortcut on laptops).
> 
> Again, as I said before, I am pretty sure there are no settings except
> brightness which require you to change to a different profile - in
> fact, there is a reason why brightness handling works this way at the
> moment.

You keep saying this, but sorry, I can just as well keep saying the 
opposite. :) Do you have some research showing this is true? If this is 
true, why would we have power magement configurations at all? Just as 
with turning off wifi with a hardware button, brightness can be changed 
from the hardware (well, software,  but usually independent of the 
running OS).
Certainly CPU wakeups, disk, perfipherials, etc. have an impact on 
battery life. 

What should be configurable is another thing. In perfect life, indeed we 
should just have good defaults. 

> Provided some good reasons, I will. But I think atm you are wasting
> your time creating new profiles, while you could achieve the same by
> tweaking your brightness. This kind of placebo-effect of switching to
> a profile with a different name is something I was fearing from day
> 1.

Isn't good enough reason what was said in this thread? I'm not the only 
one feeling it weird that configuring power management is tied to 
activities. And even if we have good defaults (that we should) for 
peformance/agressive power saving, then it is still weird that you 
cannot change the active setting without switching to a new activity. 
That is what people try to explain here.
And it is just as weird, if you CAN tweak the power management settings, 
but you cannot do that without creating a new activity. It was already 
asked here: is there a technical reason why you couldn't do that? 

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

Re: The future of Power Management - together with Activities

[Andras Mantia]

On Sunday, October 02, 2011 14:45:58 Dario Freddi wrote:
> > That was one example. Another example brought up is e.g switching of
> > strigi or nepomuk indexing when switching to a power saving profile.
> > These two are something that usually kick in when you are in idle
> > mode, exactly when the battery power could be saved. Of course,
> > with good default profiles this can be solved.
> 
> Absolutely not. Where did you read that, and most of all, how can
> profiles help you here, since there is no way for configuring that?
> If they are using Solid's way for determining if they can consume
> resources (and they are), they turn off automagically when on
> battery.

No way now, but why we shouldn't have such a configuration? This would 
exactly improve power saving by letting the cpu more in idle mode.
If we look at the big picture of KDE and think about integration, this 
is exactly a case where it makes sense to control multiple pieces of the 
software stack from one single place without user intervention. The user 
asks to save power the the desktop will try to achieve this with all 
possible means. I know this is not really about what your original mail 
is about, but it is something that might belong into the power 
management profiles.

> > What I said that I might manually need to switch to a different
> > profile independent of what the battery power *currently* is and
> > without switching my workflow/applications. Because I know in
> > advance (before the software can find this out from the battery
> > level dropping down) how much time I need the computer running.
> 
> But apparently you don't know what it takes to save power.

Do I have to really know? I just want to save power. And do that 
whenever I want, not when the computer decides. Thats the whole point.

> I will quote myself from another mail: the main job for a policy
> daemon is to PREVENT power management when the user is working, and
> that's exactly the use case for activities: while you are doing
> something, you don't want to be interrupted by extreme powersaving,
> such as dimming the screen in 30 seconds.

Sincerely, the preventing part is news to me and probably to most users. 

Anyway, there is no point of arguing more, what I wanted to say, I did, 
what you wanted to say, you did, you are the coder, draw the conclusion 
from the thread and implement the feature.

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

Re: The future of Power Management - together with Activities

[Andras Mantia]

On Sunday, October 02, 2011 17:04:50 Martin Gr��lin wrote:
> So please calmn down and lets focus on improving the user experience
> by not spending too much time on too long� threads.

I'm far from being upset or anything. I just gave my opinion, which 
seems to match others as well. We were *asked* for opinions.
 I can't tell to Dario what he should code, nor I will.

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

Re: The future of Power Management - together with Activities

[Andras Mantia]

On Sunday, October 02, 2011 20:31:11 Dario Freddi wrote:
> I don't think so. Every other system does a similar thing: there is no
> use in saving battery when you're on AC, when you are on battery
> these components are turned off. I don't think this should be
> configurable at all, and to a certain mean it is: you can always
> re-enable the service in the system tray with a single click. The
> user doesn't need to do anything at all here and can simply trust his
> system to do the right thing.


In this part we agree, that's why I said that with good defaults, 
configuration might not be needed.

> > > > What I said that I might manually need to switch to a different
> > > > profile independent of what the battery power *currently* is and
> > > > without switching my workflow/applications. Because I know in
> > > > advance (before the software can find this out from the battery
> > > > level dropping down) how much time I need the computer running.
> > > 
> > > But apparently you don't know what it takes to save power.
> > 
> > Do I have to really know? I just want to save power. And do that
> > whenever I want, not when the computer decides. Thats the whole
> > point.
> No offense meant, but this one made me laugh. If you don't know what
> it takes to save power, you should trust me when I say some things
> are not going to help you. 

Just like in the first case, this is about configurations, while both my 
and others mails were about two issues:
- chosing a preset configuration whenver you want
- creating presets

And here I talked about the first. The software might know better what is 
the best to save power, and I might know when it should save power. How 
it does (turning off brightness, setting kernel argument in /proc or 
whayever) is not relevant - that's why Is said should i really know?), 
from the user pov.

I hope this makes clear what I meant.

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

KRunner plugin documentation

[Andras Mantia]

Hi,

 I like a lot the KRunner plugins, but I find one issue with them: it is not 
documented how you should use them. I discovered some of the features, but 
probably not everything. And I see no place in the UI where the 
documentation could be plugged in. Every plugin has an Info button, but that 
is used only for About and Author. 
 I suggest to add a Help tab there as well that describes the plugin's 
usage.

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

Re: KRunner plugin documentation

[Andras Mantia]

Sebastian Kügler wrote:

> Hey Andras,
> 
> On Wednesday, December 07, 2011 09:55:59 Andras Mantia wrote:
>>  I like a lot the KRunner plugins, but I find one issue with them: it is
>> not documented how you should use them. I discovered some of the
>> features, but probably not everything. And I see no place in the UI where
>> the documentation could be plugged in. Every plugin has an Info button,
>> but that is used only for About and Author.
>>  I suggest to add a Help tab there as well that describes the plugin's
>> usage.
> 
> Have you tried the [?] button (next to the main input field)? It reveals
> how to use the plugins.

Yes (after I wrote the mail :) ), I have two problem with it:
- it is not readable (partly due to that is is semi-transparent, and that is 
lists all the plugins, so you have 10+ entries starting with )
- it doesn't describe everything, e.g unit converters.

So I keep my statement that a per-plugin documentation is needed.

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

Re: KRunner plugin documentation

[Andras Mantia]

Sebastian Kügler wrote:

> The text is not semi-transparant on my machine, maybe you're using a
> different theme?

I have the same issue with Air and Oxygen. Here is a screenshot:
http://i.imgur.com/SjgWN.png

The background is the composer for this mail. :)

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

Re: KRunner plugin documentation

[Andras Mantia]

Martin Klapetek wrote:

> On Wed, Dec 7, 2011 at 11:50, Andras Mantia  wrote:
> 
>> Sebastian Kügler wrote:
>>
>> > The text is not semi-transparant on my machine, maybe you're using a
>> > different theme?
>>
>> I have the same issue with Air and Oxygen. Here is a screenshot:
>> http://i.imgur.com/SjgWN.png
>>
>> The background is the composer for this mail. :)
>>
> 
> Do you have the blur KWin effect enabled? That might explain why is it
> this "see-through".

No, I don't have.

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

Re: KRunner plugin documentation

[Andras Mantia]

Sebastian Kügler wrote:

> On Wednesday, December 07, 2011 12:08:41 Martin Klapetek wrote:
>> On Wed, Dec 7, 2011 at 12:04, Andras Mantia  wrote:
>> > Martin Klapetek wrote:
>> > > On Wed, Dec 7, 2011 at 11:50, Andras Mantia  wrote:
>> > >> Sebastian Kügler wrote:
>> > >> > The text is not semi-transparant on my machine, maybe you're using
>> > >> > a different theme?
>> > >> 
>> > >> I have the same issue with Air and Oxygen. Here is a screenshot:
>> > >> http://i.imgur.com/SjgWN.png
>> > >> 
>> > >> The background is the composer for this mail. :)
>> > > 
>> > > Do you have the blur KWin effect enabled? That might explain why is
>> > > it this "see-through".
>> > 
>> > No, I don't have.
> 
> Try enabling it :)

With Blur it is much better. Doesn't solve the other points (or the case 
when you can't use Blur).

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

[PATCH] Show the job progress in separate dialog

[Andras Mantia]

Hi,

 the attached patch introduces a config option to show the job progress 
dialogs as separate dialogs. The reason is:
1) people are used to the old ones
2) the new ones, integrated into the systray notification have  some 
limitation compared to the old ones, like not being visible every time, 
so you don't know if a job stuck, finished, whatever; the information 
given is not that detailed; they disappear after the timeout, etc.

I know 2) can be improved over time, but the timeframe to 4.2 is short 
and as no new strings can be introduced, I doubt it is possible now. 
There is no GUI configuration, again because of the string freeze. The 
option is global, I don't even know if it would be possible to have both 
the separate and the integrated dialogs.
The patch doesn't react to config file changes, if requested, I can do 
that part.

There is a question what should be the default. As it is now, I'd think 
showing the separate dialogs should be the default because of 2) and 
because some bugs. Anyway the patch tries to be not intrusive, so I made 
to have the current behavior the default, so people can test in beta 
stage and report bugs. :)

Andras

Index: core/manager.h
===
--- core/manager.h	(revision 889798)
+++ core/manager.h	(working copy)
@@ -62,6 +62,11 @@
  **/
 QList jobs() const;
 
+/**
+ * @return integrates the Job progress info into the applet's notification system
+ **/
+void registerJobProtocol();
+
 signals:
 /**
  * Emitted when a new task has been added
Index: core/manager.cpp
===
--- core/manager.cpp	(revision 889798)
+++ core/manager.cpp	(working copy)
@@ -55,23 +55,24 @@
 {
 public:
 Private(Manager *manager)
-: q(manager)
+: q(manager), jobProtocolRegistered(false)
 {
 registerTaskProtocol(new Plasmoid::TaskProtocol(q));
 registerTaskProtocol(new FDO::TaskProtocol(q));
 registerNotificationProtocol(new FDO::NotificationProtocol(q));
 registerNotificationProtocol(new DBus::NotificationProtocol(q));
-registerJobProtocol(new DBus::JobProtocol(q));
 }
 
 void registerTaskProtocol(TaskProtocol *protocol);
 void registerNotificationProtocol(NotificationProtocol *protocol);
+void registerJobProtocol();
 void registerJobProtocol(JobProtocol *protocol);
 
 Manager *q;
 QList tasks;
 QList notifications;
 QList jobs;
+bool jobProtocolRegistered;
 };
 
 
@@ -157,6 +158,19 @@
 return d->notifications;
 }
 
+void Manager::registerJobProtocol()
+{
+d->registerJobProtocol();
+}
+
+void Manager::Private::registerJobProtocol()
+{
+if (!jobProtocolRegistered) {
+registerJobProtocol(new DBus::JobProtocol(q));
+	jobProtocolRegistered = true;
+}
+}
+
 void Manager::Private::registerJobProtocol(JobProtocol *protocol)
 {
 connect(protocol, SIGNAL(jobCreated(SystemTray::Job*)),
Index: ui/applet.cpp
===
--- ui/applet.cpp	(revision 889798)
+++ ui/applet.cpp	(working copy)
@@ -121,11 +121,17 @@
 d->taskArea->syncTasks(Manager::self()->tasks());
 
 extender()->setEmptyExtenderMessage(i18n("No notifications and no jobs"));
+  
 connect(SystemTray::Manager::self(), SIGNAL(notificationAdded(SystemTray::Notification*)),
 this, SLOT(addNotification(SystemTray::Notification*)));
-connect(SystemTray::Manager::self(), SIGNAL(jobAdded(SystemTray::Job*)),
-this, SLOT(addJob(SystemTray::Job*)));
 
+KConfigGroup globalCg = globalConfig();
+bool separateJobDialogs = globalCg.readEntry("SeparateJobDialogs", false);
+if (!separateJobDialogs) {
+  SystemTray::Manager::self()->registerJobProtocol();
+  connect(SystemTray::Manager::self(), SIGNAL(jobAdded(SystemTray::Job*)),
+	  this, SLOT(addJob(SystemTray::Job*)));
+}
 }
 
 
@@ -321,6 +327,7 @@
 
 KConfigGroup cg = config();
 cg.writeEntry("hidden", hiddenTypes);
+   
 emit configNeedsSaving();
 }
 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: uiserver interaction, was: Re: [PATCH] Show the job progress in separate dialog

[Andras Mantia]

First of all what Sebas wrote are my main problems with the new behavior. I 
just didn't explain that detailed. :)


>> - An option to keep the jobwindow visible when it looses focus. Sometime,
>> I do indeed wait for a job to be finished, and then it's annoying if the
>> dialog keeps vanishing
> 
> mm... perhaps something right inside the window, or only when the user
> manually calls it forward?

In my opinion sometimes you need to see the progress constantly. Let's say you 
start to download some files and you want to see how the download goes on, is 
some of them stuck or something like that. The current solution is to click 
from time to time to the icon, which is not so friendly. What would be better 
is to either be able to keep the notification constantly visible, to be able to 
detach certain notifications or to be able to get a window with all the 
progress info that doesn't go away automatically. 

Back to the patch: the reason I made the option false (keep the current 
behavior) by default is to not hide the new feature from the users. At least in 
beta stage, but of course if the main bugs ( that I will report after beta 2 
:P) are fixed it can remain in final as well.

I will add the option for notifications and commit.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Systray Notifications

[Andras Mantia]

Rob Scheepmaker wrote:

> Agreed, Ideally those should be hidden. Something I could do is only let
> notifications appear after a job has been running for a couple of seconds
> so all those very short jobs won't bother you,

As far as I know this is exactly what happens with the old dialogs.

> unimportant messages. Any kio job will get registered to kuiserver and I
> don't think that can be changed without additions to the kio api. (and of
> course applications marking jobs as 'unimportant')

There is a way to know if the progress info should be visible or not, and 
namely the JobFlags argument for the kio methods. See the API docs (like 
http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#09f67ce3514cc15ed2adcf91704fa55e)
 and see there:
flags,:   We support HideProgressInfo here

You should take this into the account and not show any progress info if the 
caller doesn't want to (for most stat, open and sometimes save, etc. cases).

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

plasma & plasma-desktop

[Andras Mantia]

Hi,

 I noticed that after I compiled trunk I have two panels, systray 
without icons and similar strange things. After a while I realized that 
I have both plasma and plasma-desktop running.
 It happens because I have a distro packaged KDE 4.1 (and now 4.2) in 
/usr and a self compiled one in /opt/kde4. Even though the last one is 
ahead in the path, in doesn't help in this case, as plasma is picked up 
from /usr.

 I assume this will hit many people, especially developers. A proper 
upgrade mechanism should be found. I see there is already a plasma-to-
plasma-desktop executable and a plasmarc-to-plasmadesktoprc.upd, but 
they seem to not do the job completely.

Andras

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

Review Request: Display correct week number in the calendar widget

[Andras Mantia]

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

Review request for Plasma.


Summary
---

The calendar widget currently display incorrect and misleading week numbers if 
according to the regional setting the week doesn't start with Monday (like in  
the US). The widget uses KCalendarSystem::weekNumber to find the week number 
for the first date in the row. This date can be any day of the week, not only 
Monday, as the calendar widget takes into the account the regional settings. 
But KCalendarSystem::weekNumber determines the ISO week number as it is stated 
in its documentation and that one starts with Mondays. This results in a wrong 
week number shown.
Examples: in 2009 the week1 is 1-4, week 2 is 5-11th of January. If the 
regional is US, the second row starts from 4-10. For 4th the week number is 1, 
so 1 is shown for that week. This is wrong, that week contains days both from 
the first and second week. 
The solution is either to calculate the week number according to the regional 
settings or display the week number correctly in ISO numbering. The patch does 
the second one, displays the week number(s) where the days in that row belong. 
So in US regional, row 2 (weeks 4-5) would be assigned to weeks 1/2 (4 is in 1, 
5-10 is in 2).


Diffs
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 925810 

Diff: http://reviewboard.kde.org/r/76/diff


Testing
---

Tested with all possible weekday starts. The calendar default size needs to be 
bigger to fit week numbers like 52/53, sincerely don't know where to do it, 
that change probably needs to be done in the applet itself.


Thanks,

Andras

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

Re: Review Request: Display correct week number in the calendar widget

[Andras Mantia]

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


Any opinion about this?

- Andras


On 2009-02-14 06:30:08, Andras Mantia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/76/
> ---
> 
> (Updated 2009-02-14 06:30:08)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> The calendar widget currently display incorrect and misleading week numbers 
> if according to the regional setting the week doesn't start with Monday (like 
> in  the US). The widget uses KCalendarSystem::weekNumber to find the week 
> number for the first date in the row. This date can be any day of the week, 
> not only Monday, as the calendar widget takes into the account the regional 
> settings. But KCalendarSystem::weekNumber determines the ISO week number as 
> it is stated in its documentation and that one starts with Mondays. This 
> results in a wrong week number shown.
> Examples: in 2009 the week1 is 1-4, week 2 is 5-11th of January. If the 
> regional is US, the second row starts from 4-10. For 4th the week number is 
> 1, so 1 is shown for that week. This is wrong, that week contains days both 
> from the first and second week. 
> The solution is either to calculate the week number according to the regional 
> settings or display the week number correctly in ISO numbering. The patch 
> does the second one, displays the week number(s) where the days in that row 
> belong. So in US regional, row 2 (weeks 4-5) would be assigned to weeks 1/2 
> (4 is in 1, 5-10 is in 2).
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 925810 
> 
> Diff: http://reviewboard.kde.org/r/76/diff
> 
> 
> Testing
> ---
> 
> Tested with all possible weekday starts. The calendar default size needs to 
> be bigger to fit week numbers like 52/53, sincerely don't know where to do 
> it, that change probably needs to be done in the applet itself.
> 
> 
> Thanks,
> 
> Andras
> 
>

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

Re: Review Request: Display correct week number in the calendar widget

[Andras Mantia]

> On 2009-02-18 11:22:20, Aaron Seigo wrote:
> > the week # should be calculated properly according to the region settings. 
> > adding the weekday is going to cause layouting problems (which you've 
> > already run into :) and just be rather confusing.
> > 
> > on the other hand, it makes international scheduling with people over the 
> > phone a bit harder ("your week 32 is my week 33??") ... but if you're 
> > concerned about that you'll use a standard calendar system rather than a 
> > regional one, no? so .. this should be fixed properly.

Yes, it would add some confusion. I think going the ISO way is a good, because 
it avoids the confusion, but it introduces the issue that one row belongs to 
more than one week. But anyway, I'd be also happy if the week number would be 
calculated correctly, but somebody who knows better how to do it should do by 
reading through a lot of documents. :) 
http://en.wikipedia.org/wiki/Seven-day_week#Week_number can be a start, but it 
is far from being exact.
What's clear is that the current solution is bad, one row contains more than 
one week, but only one week number is displayed (clicking on individual days 
shows it).


> On 2009-02-18 11:22:20, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp, lines 
> > 509-512
> > <http://reviewboard.kde.org/r/76/diff/1/?file=513#file513line509>
> >
> > i assume this is going to make translators unhappy. this should 
> > probably be treated with i18n.

I don't think so, this is always concatenating two numbers: 1/2, 2/3 and so on. 
But of course it can be replaced with an i18n.


- Andras


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


On 2009-02-14 06:30:08, Andras Mantia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/76/
> ---
> 
> (Updated 2009-02-14 06:30:08)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> The calendar widget currently display incorrect and misleading week numbers 
> if according to the regional setting the week doesn't start with Monday (like 
> in  the US). The widget uses KCalendarSystem::weekNumber to find the week 
> number for the first date in the row. This date can be any day of the week, 
> not only Monday, as the calendar widget takes into the account the regional 
> settings. But KCalendarSystem::weekNumber determines the ISO week number as 
> it is stated in its documentation and that one starts with Mondays. This 
> results in a wrong week number shown.
> Examples: in 2009 the week1 is 1-4, week 2 is 5-11th of January. If the 
> regional is US, the second row starts from 4-10. For 4th the week number is 
> 1, so 1 is shown for that week. This is wrong, that week contains days both 
> from the first and second week. 
> The solution is either to calculate the week number according to the regional 
> settings or display the week number correctly in ISO numbering. The patch 
> does the second one, displays the week number(s) where the days in that row 
> belong. So in US regional, row 2 (weeks 4-5) would be assigned to weeks 1/2 
> (4 is in 1, 5-10 is in 2).
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 925810 
> 
> Diff: http://reviewboard.kde.org/r/76/diff
> 
> 
> Testing
> ---
> 
> Tested with all possible weekday starts. The calendar default size needs to 
> be bigger to fit week numbers like 52/53, sincerely don't know where to do 
> it, that change probably needs to be done in the applet itself.
> 
> 
> Thanks,
> 
> Andras
> 
>

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

Re: Review Request: Display correct week number in the calendar widget

[Andras Mantia]

> On 2009-02-18 11:22:20, Aaron Seigo wrote:
> > the week # should be calculated properly according to the region settings. 
> > adding the weekday is going to cause layouting problems (which you've 
> > already run into :) and just be rather confusing.
> > 
> > on the other hand, it makes international scheduling with people over the 
> > phone a bit harder ("your week 32 is my week 33??") ... but if you're 
> > concerned about that you'll use a standard calendar system rather than a 
> > regional one, no? so .. this should be fixed properly.
> 
> Andras Mantia wrote:
> Yes, it would add some confusion. I think going the ISO way is a good, 
> because it avoids the confusion, but it introduces the issue that one row 
> belongs to more than one week. But anyway, I'd be also happy if the week 
> number would be calculated correctly, but somebody who knows better how to do 
> it should do by reading through a lot of documents. :) 
> http://en.wikipedia.org/wiki/Seven-day_week#Week_number can be a start, but 
> it is far from being exact.
> What's clear is that the current solution is bad, one row contains more 
> than one week, but only one week number is displayed (clicking on individual 
> days shows it).

BTW, I forgot to mention that KOrganizer behaves like the calendar widget with 
my changes.


- Andras


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


On 2009-02-14 06:30:08, Andras Mantia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/76/
> ---
> 
> (Updated 2009-02-14 06:30:08)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> The calendar widget currently display incorrect and misleading week numbers 
> if according to the regional setting the week doesn't start with Monday (like 
> in  the US). The widget uses KCalendarSystem::weekNumber to find the week 
> number for the first date in the row. This date can be any day of the week, 
> not only Monday, as the calendar widget takes into the account the regional 
> settings. But KCalendarSystem::weekNumber determines the ISO week number as 
> it is stated in its documentation and that one starts with Mondays. This 
> results in a wrong week number shown.
> Examples: in 2009 the week1 is 1-4, week 2 is 5-11th of January. If the 
> regional is US, the second row starts from 4-10. For 4th the week number is 
> 1, so 1 is shown for that week. This is wrong, that week contains days both 
> from the first and second week. 
> The solution is either to calculate the week number according to the regional 
> settings or display the week number correctly in ISO numbering. The patch 
> does the second one, displays the week number(s) where the days in that row 
> belong. So in US regional, row 2 (weeks 4-5) would be assigned to weeks 1/2 
> (4 is in 1, 5-10 is in 2).
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 925810 
> 
> Diff: http://reviewboard.kde.org/r/76/diff
> 
> 
> Testing
> ---
> 
> Tested with all possible weekday starts. The calendar default size needs to 
> be bigger to fit week numbers like 52/53, sincerely don't know where to do 
> it, that change probably needs to be done in the applet itself.
> 
> 
> Thanks,
> 
> Andras
> 
>

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

D17408: Make accessibility warning dialog usable again

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  Layout was completely broken, resulting in an empty dialog.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  accessbility-fixes

REVISION DETAIL
  https://phabricator.kde.org/D17408

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17415: Fix event type checking

[Andras Mantia]

amantia created this revision.
amantia added reviewers: Plasma, Plasma Accessibility, aacid.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  The ev->xkbType looks to be a value that is defined in xkb.xml (usually
  in /usr/share/xcb), and that indicates which bit refers to a certain event.
  The XCB_XKB_EVENT_TYPE_* enum is a bitmask value though, they cannot be
  compared directly. E.g BellNotify even mean bit 8 is set, that means the value
  is 2^8 = 256.
  This fixes bell, visual bell and accessibility event handling.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17415

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia, #plasma, #plasma_accessibility, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17415: Fix event type checking

[Andras Mantia]

amantia updated this revision to Diff 47100.
amantia added a comment.


  Added comment for workaround

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17415?vs=47065&id=47100

REVISION DETAIL
  https://phabricator.kde.org/D17415

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia, #plasma, #plasma_accessibility, aacid
Cc: davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17408: Make accessibility warning dialog usable again

[Andras Mantia]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:40b9e34ced6b: Make accessibility warning dialog usable 
again (authored by amantia).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D17408?vs=47044&id=47374#toc

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17408?vs=47044&id=47374

REVISION DETAIL
  https://phabricator.kde.org/D17408

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia, #plasma_accessibility, #plasma, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17415: Fix event type checking

[Andras Mantia]

amantia closed this revision.
amantia added a comment.


  Messed up a little and this got landed together with another patch 
https://cgit.kde.org/plasma-desktop.git/commit/?id=40b9e34ced6b421c8585f304d91a2da37f40c4d6

REVISION DETAIL
  https://phabricator.kde.org/D17415

To: amantia, #plasma, #plasma_accessibility, aacid, davidedmundson
Cc: davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purprose more clear

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  BUG: 190369

REPOSITORY
  R119 Plasma Desktop

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17536: Make accessibility warning dialog usable again and fix event handling

[Andras Mantia]

amantia created this revision.
amantia added reviewers: Plasma Accessibility, Plasma, aacid.
amantia added a project: Plasma.
amantia requested review of this revision.

REVISION SUMMARY
  Layout was completely broken, resulting in an empty dialog.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  Plasma/5.14

REVISION DETAIL
  https://phabricator.kde.org/D17536

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia, #plasma_accessibility, #plasma, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17536: Make accessibility warning dialog usable again and fix event handling

[Andras Mantia]

amantia added a comment.


  Accessibility bugfixes cherry picked from master

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17536

To: amantia, #plasma_accessibility, #plasma, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purprose more clear

[Andras Mantia]

amantia planned changes to this revision.
amantia added a comment.


  Will have to rework, I missed some cases(the dialog might as to activate. 
deactivate or "activate some, deactivate others"), it is not as simple as I 
thought.

INLINE COMMENTS

> davidedmundson wrote in kaccess.cpp:713
> can we choose another role here?

Oops.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purprose more clear

[Andras Mantia]

amantia updated this revision to Diff 47441.
amantia added a comment.


  Reworked, by reshuffling the dialog text, instead of renaming the buttons

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17533?vs=47434&id=47441

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp
  kaccess/kaccess.h

To: amantia, #plasma_accessibility, davidedmundson, aacid
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17557: Make accessibility warning dialog usable again

[Andras Mantia]

amantia added a comment.


  Backport to 5.12 branch

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17557

To: amantia, #plasma_accessibility, #plasma, aacid
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17557: Make accessibility warning dialog usable again

[Andras Mantia]

amantia created this revision.
amantia added reviewers: Plasma Accessibility, Plasma, aacid.
amantia added a project: Plasma.
amantia requested review of this revision.

REVISION SUMMARY
  Layout was completely broken, resulting in an empty dialog.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  Plasma/5.12

REVISION DETAIL
  https://phabricator.kde.org/D17557

AFFECTED FILES
  kaccess/kaccess.cpp

To: amantia, #plasma_accessibility, #plasma, aacid
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17557: Make accessibility warning dialog usable again

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17557

To: amantia, #plasma_accessibility, #plasma, aacid, davidedmundson
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17536: Make accessibility warning dialog usable again and fix event handling

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17536

To: amantia, #plasma_accessibility, #plasma, aacid, mart
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purprose more clear

[Andras Mantia]

amantia added a comment.


  How it looked before:  F6476429: new_dialog.jpg 

  How it looks now:  F6476432: new_dialog.jpg 


REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  You can't change to Yes/No (that was my first try), as the question might be 
one of the following:
  
  - "Activate foo ?"
  - "Deactivate foo?"
  - "Activate foo and deactivate bar?"

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia updated this revision to Diff 47590.
amantia added a comment.


  Improve dialog title as well

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17533?vs=47441&id=47590

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp
  kaccess/kaccess.h
  kaccess/main.cpp

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  I'm not a native speaker, but I don't see how OK/Cancel is better. The dialog 
shows a question that can be answered with Yes or No. 
  See also the HIG https://hig.kde.org/components/assistance/message.html
  
  > - Apply confirmation button labels when further interaction is required:
  > 
  >   Use buttons which match the type of statement or question made in the 
warning or error message. **For example, do no ask a Yes/No question but then 
provide OK/Cancel buttons.**
  > - Apply confirmation button labels when the user must choose between two 
actions to continue:
  > 
  >   Use descriptive button labels instead of standard Yes/No or OK/Cancel 
buttons. For example, if the user must choose to continue or stop an action, 
provide the buttons “Continue” and “Cancel”.
  
  I cannot easily do the second (and don't want to with this patch).

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia updated this revision to Diff 47661.
amantia added a comment.


  Make the question text bold

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17533?vs=47590&id=47661

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp
  kaccess/kaccess.h
  kaccess/main.cpp

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  Yes, most questions can be answered with Yes/No, and still I'd say it is 
better to use Yes/No, instead of OK/Cancel. OK/Cancel is rather useless, 
although widely used, I know...
  I made the question text bold now, and unfortunately as I said I don't want 
to spend more on this. The whole dialog is problematic as it poses both a 
question (activate/do not activate) and a side question (turn off gestures or 
not). 
  This is confusing by default, and for the users it was unclear what the 
dialog buttons do, as the original question was at the beginning and between 
the question and the action buttons there was the large explanation with the 
secondary action.
  At least (IMO) now it is clear that the Yes/No buttons refer to the 
activate/deactivate question.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia abandoned this revision.
amantia added inline comments.

INLINE COMMENTS

> ngraham wrote in kaccess.cpp:870
> Let's use `xi18nc()` for this:
> 
> `xi18nc("@info", "%1", question)`

That looks weird., as it creates a translatable string for no reason.  
Obviously best would be to update all strings to have the bold text in it, but 
that creates lots of new strings for no good reason

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia updated this revision to Diff 47712.
amantia added a comment.


  Change the individual texts

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17533?vs=47661&id=47712

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp
  kaccess/kaccess.h
  kaccess/main.cpp

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: gladhorn, ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  I perfectly agree with Frederik. There is room for improvement, but my 
intention was not to completely change it, just to make it slightly more clear 
what this is about. The rest can be fixed in a separate commit, if anyone is 
interested to do it. :)

INLINE COMMENTS

> gladhorn wrote in kaccess.cpp:870
> I'd say updating all strings is good. Translators should have support from 
> their tools (translation memory) and we will eventually have to move forward.

I did, although disagree, as it makes the change not easily backportable. I 
also couldn't test/trigger all cases.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: gladhorn, ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia updated this revision to Diff 47714.
amantia added a comment.


  Use title case

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17533?vs=47712&id=47714

BRANCH
  accesbility_dialog_improvement

REVISION DETAIL
  https://phabricator.kde.org/D17533

AFFECTED FILES
  kaccess/kaccess.cpp
  kaccess/kaccess.h
  kaccess/main.cpp

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: pino, gladhorn, ngraham, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17657: Notify also if modes have changed

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  Will be needed in the KCM to correctly update the UI

REPOSITORY
  R110 KScreen Library

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D17657

AFFECTED FILES
  src/output.cpp
  src/output.h

To: amantia
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17658: Redraw the slider if modes have changed

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  This can happen if a monitor was not configured at all, the KCM is shown
  when it first plugged in and the user selects to not configure it.
  In the UI it will appear with no Resolution/Refresh rate and wrong size in
  the QML view.
  
  Depends on D17657 

REPOSITORY
  R104 KScreen

BRANCH
  fix_null_size

REVISION DETAIL
  https://phabricator.kde.org/D17658

AFFECTED FILES
  kcm/src/resolutionslider.cpp
  kcm/src/resolutionslider.h

To: amantia
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17657: Notify also if modes have changed

[Andras Mantia]

amantia added inline comments.

INLINE COMMENTS

> davidedmundson wrote in output.cpp:583-585
> isn't that what this is doing?

Good point, missed it. @dvratil any reason why it emits outputChanged and not 
modesChanged? Actually setModes emits both, so maybe indeed it is easier to 
just put modesChnaged there as well. I'm still curious why we need both.

REPOSITORY
  R110 KScreen Library

REVISION DETAIL
  https://phabricator.kde.org/D17657

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17658: Redraw the slider if modes have changed

[Andras Mantia]

amantia added inline comments.

INLINE COMMENTS

> davidedmundson wrote in resolutionslider.cpp:144
> does this not cause the apply button to enable immediately when a user hasn't 
> changed anything?

I don't see how it would do that. This is called either when an output is set 
up the first time or when the modes (not the current mode, but how many 
resolutions it supports) changes.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D17658

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17657: Notify also if modes have changed

[Andras Mantia]

amantia updated this revision to Diff 47789.
amantia added a comment.


  Simplify

REPOSITORY
  R110 KScreen Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17657?vs=47778&id=47789

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D17657

AFFECTED FILES
  src/output.cpp

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17658: Redraw the slider if modes have changed

[Andras Mantia]

amantia updated this revision to Diff 47830.
amantia added a comment.


  - Show unconnected displayed at the left

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17658?vs=47779&id=47830

BRANCH
  rework_qml_part

REVISION DETAIL
  https://phabricator.kde.org/D17658

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/resolutionslider.cpp
  kcm/src/resolutionslider.h

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17658: Redraw the slider if modes have changed

[Andras Mantia]

amantia updated this revision to Diff 47831.
amantia added a comment.


  Undo last change

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17658?vs=47830&id=47831

BRANCH
  fix_null_size

REVISION DETAIL
  https://phabricator.kde.org/D17658

AFFECTED FILES
  kcm/src/resolutionslider.cpp
  kcm/src/resolutionslider.h

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17685: Notify also if modes have changedBackport for D17657Depends on D17657

[Andras Mantia]

amantia created this revision.
amantia added a project: Plasma.
amantia requested review of this revision.

REVISION SUMMARY
  Will be needed in the KCM to correctly update the UI

REPOSITORY
  R110 KScreen Library

BRANCH
  Plasma/5.12

REVISION DETAIL
  https://phabricator.kde.org/D17685

AFFECTED FILES
  src/output.cpp

To: amantia
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17686: Redraw the slider if modes have changed

[Andras Mantia]

amantia created this revision.
amantia added a project: Plasma.
amantia requested review of this revision.

REVISION SUMMARY
  This can happen if a monitor was not configured at all, the KCM is shown
  when it first plugged in and the user selects to not configure it.
  In the UI it will appear with no Resolution/Refresh rate and wrong size in
  the QML view.
  
  Backport of D17658 
  Depends on D17685 

REPOSITORY
  R104 KScreen

BRANCH
  Plasma/5.12

REVISION DETAIL
  https://phabricator.kde.org/D17686

AFFECTED FILES
  kcm/src/resolutionslider.cpp
  kcm/src/resolutionslider.h

To: amantia
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17685: Notify also if modes have changed

[Andras Mantia]

amantia added a comment.


  I have on for master and one for Plasma 5.12, as we want this in 5.12 as 
well, if approved. Should I keep only one of them?

REPOSITORY
  R110 KScreen Library

REVISION DETAIL
  https://phabricator.kde.org/D17685

To: amantia, #plasma, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17657: Notify also if modes have changed

[Andras Mantia]

amantia abandoned this revision.
amantia added a comment.


  Will fix first in 5.12 and merge to master, as per 
https://phabricator.kde.org/D17685

REPOSITORY
  R110 KScreen Library

REVISION DETAIL
  https://phabricator.kde.org/D17657

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17685: Notify also if modes have changed

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R110 KScreen Library

REVISION DETAIL
  https://phabricator.kde.org/D17685

To: amantia, #plasma, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17686: Redraw the slider if modes have changed

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D17686

To: amantia, #plasma, dvratil
Cc: plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D17658: Redraw the slider if modes have changed

[Andras Mantia]

amantia abandoned this revision.
amantia added a comment.


  Abandoned in favor of https://phabricator.kde.org/D17686

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D17658

To: amantia, dvratil
Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17682: Show unconnected displays at the right side of the main screen

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D17682

To: amantia, dvratil
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  Ping? I'll push this if there are no strong objections.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: pino, gladhorn, ngraham, plasma-devel, kvanton, jraleigh, GB_2, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart

D17533: Make the button's purpose more clear

[Andras Mantia]

amantia added a comment.


  I understand that, of course. I think the question is: is this an improvement 
or not? I think it is (not perfect, has problems, but an improvement), but if 
considered to be not, I will just abandon it, no hard feelings.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D17533

To: amantia, #plasma_accessibility, davidedmundson, aacid, ngraham
Cc: pino, gladhorn, ngraham, plasma-devel, kvanton, jraleigh, GB_2, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart

D18091: Backport "Show unconnected displays at the right side of the main screen"https://phabricator.kde.org/D17682

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REPOSITORY
  R104 KScreen

BRANCH
  backport_screen_to_right

REVISION DETAIL
  https://phabricator.kde.org/D18091

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp

To: amantia
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18092: Backport "Show unconnected displays at the right side of the main screen"

[Andras Mantia]

amantia created this revision.
amantia added a project: Plasma.
amantia requested review of this revision.

REVISION SUMMARY
  https://phabricator.kde.org/D17682

REPOSITORY
  R104 KScreen

BRANCH
  dynamic_scale

REVISION DETAIL
  https://phabricator.kde.org/D18092

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp

To: amantia
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18093: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia updated this revision to Diff 48998.
amantia added a comment.


  - Don't reset the moved display position

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18093?vs=48953&id=48998

BRANCH
  fix_reset_output_pos

REVISION DETAIL
  https://phabricator.kde.org/D18093

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia, #plasma, dvratil
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18100: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  Don't reset the moved display position
  
  This fixes the problem that after moving a display, clicking on another one
  and clicking on the original one, its position got reset to the default one.
  This due to layouting in the widget when displays are clicked, the
  ControlPanel hides/shows the corresponding OutputConfig, which results in a
  temporary layout changed, that causes a geometry change for the QML view,
  that causes am updateOutpusPlacement()...

REPOSITORY
  R104 KScreen

BRANCH
  fix_reset_output_pos

REVISION DETAIL
  https://phabricator.kde.org/D18100

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18093: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia updated this revision to Diff 49002.
amantia added a comment.


  Restore

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18093?vs=48998&id=49002

BRANCH
  dynamic_scale

REVISION DETAIL
  https://phabricator.kde.org/D18093

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia, #plasma, dvratil
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18093: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia added a comment.


  It is a followup and extension of https://phabricator.kde.org/D17682
  
  Basically it is possible that you have 3-4 monitors and only 2.5 or so are 
visible, because they don't fit in the dialog. This patch makes sure they are 
all visible. The previous patch just reduced their scale unconditionally.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D18093

To: amantia, #plasma, dvratil
Cc: ngraham, plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18121: Don't lose the widget layout after Default is pressed

[Andras Mantia]

amantia created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  BUG: 400302

REPOSITORY
  R104 KScreen

BRANCH
  Plasma/5.12

REVISION DETAIL
  https://phabricator.kde.org/D18121

AFFECTED FILES
  kcm/src/kcm_kscreen.cpp

To: amantia
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18121: Don't lose the widget layout after Default is pressed

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D18121

To: amantia, dvratil, #plasma, davidedmundson
Cc: plasma-devel, kvanton, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18091: Backport "Show unconnected displays at the right side of the main screen"https://phabricator.kde.org/D17682

[Andras Mantia]

amantia updated this revision to Diff 50656.
amantia added a comment.


  Don't use QQuickItem size(), use width() directly, so it builds with Qt 5.9

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18091?vs=48951&id=50656

REVISION DETAIL
  https://phabricator.kde.org/D18091

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp

To: amantia, #plasma, dvratil
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18093: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia updated this revision to Diff 50657.
amantia added a comment.


  Make it work with Qt 5.9

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18093?vs=49002&id=50657

BRANCH
  dynamic_scale

REVISION DETAIL
  https://phabricator.kde.org/D18093

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia, #plasma, dvratil
Cc: ngraham, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18093: Calculate screen scaling dynamically, so it always fits to the page

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R104 KScreen

REVISION DETAIL
  https://phabricator.kde.org/D18093

To: amantia, #plasma, dvratil
Cc: ngraham, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18101: Don't reset the moved display position

[Andras Mantia]

amantia updated this revision to Diff 50659.
amantia added a comment.


  Rebased

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18101?vs=49003&id=50659

BRANCH
  fix_reset_output_pos

REVISION DETAIL
  https://phabricator.kde.org/D18101

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia, dvratil
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D18101: Don't reset the moved display position

[Andras Mantia]

This revision was automatically updated to reflect the committed changes.
Closed by commit R104:2c5af49d3de7: Don't reset the moved display position 
(authored by amantia).

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18101?vs=50659&id=50660

REVISION DETAIL
  https://phabricator.kde.org/D18101

AFFECTED FILES
  kcm/src/declarative/qmlscreen.cpp
  kcm/src/declarative/qmlscreen.h

To: amantia, dvratil
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D8922: Avoid jumping of items toward right/botton when dropping

[Andras Mantia]

amantia added a comment.


  Sorry about it.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D8922

To: amantia, #plasma, hein, mwolff
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D9325: Use QUrl in the ScreenMapper API

[Andras Mantia]

amantia added inline comments.

INLINE COMMENTS

> mwolff wrote in foldermodel.cpp:1509
> not your change: why is m_url not an url :-/
> 
> also: introduce the helper function you have in the tests here, too - maybe 
> even move it into a static function in the ScreenMapper and then use it 
> everywhere inplace of the QUrl::fromUserInput three-arg function call

m_url is exposed to QML, that doesn't support QUrl.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D9325

To: amantia, #plasma, mwolff, dakon, broulik
Cc: ervin, mlaurent, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9325: Use QUrl in the ScreenMapper API

[Andras Mantia]

amantia updated this revision to Diff 25799.
amantia added a comment.


  Change code according to reviewer's requests

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9325?vs=23954&id=25799

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9325

AFFECTED FILES
  containments/desktop/plugins/folder/autotests/foldermodeltest.cpp
  containments/desktop/plugins/folder/autotests/positionertest.cpp
  containments/desktop/plugins/folder/autotests/screenmappertest.cpp
  containments/desktop/plugins/folder/autotests/screenmappertest.h
  containments/desktop/plugins/folder/foldermodel.cpp
  containments/desktop/plugins/folder/screenmapper.cpp
  containments/desktop/plugins/folder/screenmapper.h

To: amantia, #plasma, mwolff, dakon, broulik
Cc: ervin, mlaurent, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9325: Use QUrl in the ScreenMapper API

[Andras Mantia]

amantia edited reviewers, added: hein; removed: dakon.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D9325

To: amantia, #plasma, mwolff, broulik, hein
Cc: ervin, mlaurent, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9325: Use QUrl in the ScreenMapper API

[Andras Mantia]

amantia updated this revision to Diff 25933.
amantia added a comment.


  Make the code more clear,  by renaming a local variable.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9325?vs=25799&id=25933

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9325

AFFECTED FILES
  containments/desktop/plugins/folder/autotests/foldermodeltest.cpp
  containments/desktop/plugins/folder/autotests/positionertest.cpp
  containments/desktop/plugins/folder/autotests/screenmappertest.cpp
  containments/desktop/plugins/folder/autotests/screenmappertest.h
  containments/desktop/plugins/folder/foldermodel.cpp
  containments/desktop/plugins/folder/screenmapper.cpp
  containments/desktop/plugins/folder/screenmapper.h

To: amantia, #plasma, mwolff, broulik, hein
Cc: ervin, mlaurent, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9325: Use QUrl in the ScreenMapper API

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D9325

To: amantia, #plasma, mwolff, broulik, hein
Cc: ervin, mlaurent, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10407: Disable positioning in popup folderviews

[Andras Mantia]

amantia created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
amantia requested review of this revision.

REVISION SUMMARY
  We need to use the overriden sortMode, not the model's sort mode.
  The == -> === changes are just cosmetic, not related to functionality

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10407

AFFECTED FILES
  containments/desktop/package/contents/ui/FolderView.qml
  containments/desktop/package/contents/ui/FolderViewDialog.qml

To: amantia
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10407: Disable positioning in popup folderviews

[Andras Mantia]

amantia added a reviewer: hein.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10407

To: amantia, hein
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10408: Add option to enable shared folderview content per desktop

[Andras Mantia]

amantia added reviewers: Plasma, hein.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION DETAIL
  https://phabricator.kde.org/D10408

To: amantia, #plasma, hein
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10407: Disable positioning in popup folderviews

[Andras Mantia]

amantia added a comment.


  Yes, I have commit access since some time. ;)

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10407

To: amantia, hein
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10408: Add option to enable shared folderview content per desktop

[Andras Mantia]

amantia closed this revision.

REVISION DETAIL
  https://phabricator.kde.org/D10408

To: amantia, #plasma, hein
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10407: Disable positioning in popup folderviews

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10407

To: amantia, hein
Cc: davidedmundson, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10729: Improve detecting D&D between two screen showing the same URL

[Andras Mantia]

amantia added reviewers: Plasma, hein, mwolff.
amantia set the repository for this revision to R119 Plasma Desktop.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10729

To: amantia, #plasma, hein, mwolff
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia added reviewers: Plasma, hein.
amantia set the repository for this revision to R119 Plasma Desktop.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10729: Improve detecting D&D between two screen showing the same URL

[Andras Mantia]

amantia added a comment.


  Ping?

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10729

To: amantia, #plasma, hein, mwolff
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia added a comment.


  Ping?

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia added a comment.


  It adds a new entry, doesn't change an existing one. If that is not there, I 
see no problems, the ScreenMapper::readDisabledScreensMap() will not initialize 
the m_itemsOnDisabledScreensMap. That map was not saved previously, thus the 
folderview behaving differently after a restart, as the map was lost.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia added a comment.


  Yes, I will push first to 5.12 both of them

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10729: Improve detecting D&D between two screen showing the same URL

[Andras Mantia]

amantia closed this revision.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D10729

To: amantia, #plasma, hein, mwolff
Cc: plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia added a comment.


  I can't put to 5.12 as it seems https://phabricator.kde.org/D9325 didn't get 
into the 5.12 branch, and I don't want two versions of this patch. May I 
cherry-pick that commit to 5.12 and apply this patch?

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia updated this revision to Diff 28998.
amantia added a comment.


  Moved to 5.12

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10728?vs=27733&id=28998

BRANCH
  Plasma/5.12

REVISION DETAIL
  https://phabricator.kde.org/D10728

AFFECTED FILES
  containments/desktop/plugins/folder/screenmapper.cpp
  containments/desktop/plugins/folder/screenmapper.h

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D10728: Improve multi-desktop folderview behavior

[Andras Mantia]

amantia closed this revision.

REVISION DETAIL
  https://phabricator.kde.org/D10728

To: amantia, #plasma, hein
Cc: ngraham, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D8447: Add unit tests for Folder View

[Andras Mantia]

amantia created this revision.
amantia added reviewers: Plasma, ervin, hein, mlaurent, aacid, dvratil.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Add some tests for FolderModel and Positioner classes.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D8447

AFFECTED FILES
  containments/desktop/plugins/folder/CMakeLists.txt
  containments/desktop/plugins/folder/foldermodel.h
  containments/desktop/plugins/folder/positioner.h
  containments/desktop/plugins/folder/tests/CMakeLists.txt
  containments/desktop/plugins/folder/tests/foldermodeltest.cpp
  containments/desktop/plugins/folder/tests/foldermodeltest.h
  containments/desktop/plugins/folder/tests/positionertest.cpp
  containments/desktop/plugins/folder/tests/positionertest.h

To: amantia, #plasma, ervin, hein, mlaurent, aacid, dvratil
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart