[Differential] [Commented On] D1417: Add window shade support to protocol, interfaces and test.

[Martin Gräßlin]

graesslin added inline comments.

INLINE COMMENTS
  src/client/protocols/plasma-window-management.xml:44 I think we need to ask 
native speakers whether this is shadable or shadeable. I asked Riddell:
  
  [10:50]  Riddell: I need help with English: what's correct to 
you? "shadeable" or "shadable"?
  [10:51]  mgraesslin: I'd go for shadeable
  [10:51]  shadable I'd want to pronounce shah-d-able
  
  I would want to ask more native speakers for it. Let's make it proper English 
;-)

REPOSITORY
  rKWAYLAND KWayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: hein, graesslin
Cc: sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Requested Changes To] D1432: Add states and request methods for move and resize.

[Martin Gräßlin]

graesslin requested changes to this revision.
This revision now requires changes to proceed.

INLINE COMMENTS
  src/client/plasmawindowmanagement.h:247-251 why "mode"? Why not just 
requestMove and requestResize?
  src/client/protocols/plasma-window-management.xml:148 since is missing
  src/client/protocols/plasma-window-management.xml:148-158 same here, why mode?
  src/client/protocols/plasma-window-management.xml:154 since is missing
  src/server/plasmawindowmanagement_interface.cpp:19 close added
  src/server/plasmawindowmanagement_interface.h:146-153 why a moveModeRequested 
and movableRequested?

REPOSITORY
  rKWAYLAND KWayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: hein, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1432: Add states and request methods for move and resize.

[hein (Eike Hein)]

hein added inline comments.

INLINE COMMENTS
  src/client/plasmawindowmanagement.h:247-251 Because calling a method for 
starting an interactive move just "move" is a bit confusing -- but I didn't 
know Wayland already codified that in the protocol. Will change.

REPOSITORY
  rKWAYLAND KWayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: hein, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 247 lines] D1432: Add states and request methods for move and resize.

[hein (Eike Hein)]

hein updated this revision to Diff 3395.
hein added a comment.


  - Bring naming closer to upstream protocol; add version info to new methods; 
cleanup.

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1432?vs=3386&id=3395

BRANCH
  master

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

AFFECTED FILES
  autotests/client/test_plasma_window_model.cpp
  src/client/plasmawindowmanagement.cpp
  src/client/plasmawindowmanagement.h
  src/client/plasmawindowmodel.cpp
  src/client/plasmawindowmodel.h
  src/client/protocols/plasma-window-management.xml
  src/server/plasmawindowmanagement_interface.cpp
  src/server/plasmawindowmanagement_interface.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: hein, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 12 lines] D1434: Hook up movable and resizable states.

[hein (Eike Hein)]

hein updated this revision to Diff 3397.
hein added a comment.


  - Adapt to changed kwayland API.

REPOSITORY
  rKWIN KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1434?vs=3387&id=3397

BRANCH
  moveresize

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

AFFECTED FILES
  abstract_client.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: hein, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Minutes Monday Plasma Meeting

[Sebastian Kügler]

Enjoy the minutes of today's meeting:

Minutes Plasma 'hangout', 18-4-2016, 12:00 CET

Present: mgraesslin, Sho, notmart, colomar, kbroulik, bshah, Riddell, sebas

mgraesslin:
* kwin refactoring, splitting out X11 specific code
* kwayland preparation for frameworks
** more tests
** review period for inclusion requested, David Faure approved move
** will proceed after 5.6.3
* thoughts on test framework on Wayland

Sho:
- Extended PlasmaComponents.Menu with API and business logic to get smart Task 
Manager context menu placement and min sizing back
- Added back jump lists and recent docs actions to the task context menu
- Implemented missing states and actions in kwayland & kwin: Shadable/Shade, 
Movable/Move, Resizable/Resize, Closable
-- Some of these (and others) are not fully managed well inside kwin due to 
incomplete Wayland porting (e.g. some missing state updates)
-- Reviews are partly stuck over ... naming
- Fixed up virtual desktops context menu (radio buttons now)
- Context menu at feature parity on X11, closer on Wayland
- KActivities support is back in libtaskmanager
- Ported subtitle subtext generation code
- Learned new tricks from dealing with kwayland/kwin unit tests
- Next Plasma Test Days prep meeting tomorrow 12:00 UTC in #plasma

notmart:
* some bug triaging
* some actual bug fixes
* libplasma: added the concept of highlightedTextColor in Theme (some controls 
were incorrectly using the background color as highlighted text color that 
just "happens" to work)
* talking with andreas about icons: i will add negative/neutral/positive text 
colors for things like green/red marks and will try to add a reimplementation 
of the stylesheet coloring in kiconloader.. hope is feasible even tough not 
too much confident. Andreas is doing a lot of work on redesigning icons with 
stylesheet support, would be good to make it work in qwidgets even tough i can 
see a lot of problems with it
* kirigami: work on the PageRow rewrite
* question: how to set up bugzilla
* some work on its dynamic adaptation between phone and landcape tablet/
desktop-ish mode
* experimental support for multiple column per screen with different sizes per 
column
* ApplicationHeaer supporting disparate column sizes as well
* Page/ScrollPage: allow multiple children per Page
* natural animations: adjust some easing curves (animations of things sliding 
from/to offscreen should not be s-shaped)
* support highlightedtext color, used for selected menu items: can fix 
problems like black text over dark blue often happens in subsurface
* use the new handle-left icon
* some layout fixes for Android

colomar:
* working on kirigami HIG (for non-QWidget, kirigami-based apps)
* looking into https://bugs.kde.org/show_bug.cgi?id=229942 designing a good 
solution

kbroulik:
* Ran booth at Augsburger Linux Days, presented Plasma 
{Desktop,Phone,Mediacenter}, was well received
* Talked with Limux guys

bshah:
* Plasma Mobile on new architecture shows signs of life: http://imgur.com/a/
noIXo
  * involves bionic patching
  * no input yet (mgraesslin will look into it)
* Qt 5.6 for mobile coming

Riddell:
* 5.6.3 due tomorrow, get your bugfixes in!
* Neon user images about to be announced, clench your buttocks!
* Neon 16.04 is there 
http://jriddell.org/2016/04/14/kde-neon-upgrades-to-16-04lts/

sebas:
* working on windowmetadata library basics, hopefully something to show within 
the course of this week
  * primary entry point for the server will be a model (QAbstractListModel or 
QAIM?)
  * client side, probably just one small class, but haven't decided on the 
exact semantics there yet
  * code is at g...@git.kde.org:scratch/sebas/windowmetadata
* transferred plasma-pa maintainership to David Rosca (nowrep): Thanks!
* prepping KDE store meeting


-- 
sebas

http://www.kde.org | http://vizZzion.orgMinutes Plasma 'hangout', 4-4-2016, 12:00 CET

Present: mgraesslin, kbroulik, bshah, Sho, notmart, Riddell, jensreuterberg, 
sebas


mgraesslin:
* subcompositor support working better, KWin review is up 
https://phabricator.kde.org/D1282
** OpenGL support is hacked in, but not implemented correctly yet (no 
WindowQuads)
** input still missing
** many bugs in Qt found with workarounds implemented in KWayland
*** https://bugreports.qt.io/browse/QTBUG-51640
*** https://bugreports.qt.io/browse/QTBUG-52092
*** https://bugreports.qt.io/browse/QTBUG-52118
*** https://bugreports.qt.io/browse/QTBUG-52192
* Input events added to debug console - comparable to xev
* april-fool: https://phabricator.kde.org/D1283 - might work as easter egg, 
opinions?
* investigating a few screenlocker issues, apparently no Qt::QueuedConnection 
is working

kbroulik:
* will represent KDE at http://luga.de/Aktionen/LIT-2016/abstracts.html#kde

bshah:
* Plasma Mobile planning meeting: http://doodle.com/poll/8x983kg6s5p6hw48 -- 
please join!
* Working on new imaging / OS stack for Plasma mobile (bare Cyanogenmod + 
Debian chroot)

jensreuterberg:
* doing print / promo material
* finished

[Differential] [Request, 148 lines] D1440: Move ShellClient initialization code into a dedicated init method

[Martin Gräßlin]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Preparation for also supporting XdgShell. There will be different
  ctors for ShellSurface and XdgShell, but most code needs to be shared.
  Thus a dedicated init method is needed.
  
  There is some restructuring in the init. All code depending on
  ShellSurface being set is grouped and in an if block.

REPOSITORY
  rKWIN KWin

BRANCH
  preparation-xdg-shell

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

AFFECTED FILES
  shell_client.cpp
  shell_client.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 60 lines] D1441: ShellClient's m_shellSurface might be null

[Martin Gräßlin]

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  In preparation to support xdg-shell we need to make sure that ShellClient
  does not assume m_shellSurface to not be null.
  
  Everything that can be done through the surface() is resolved through
  surface(). All accesses to m_shellSurface are nullptr checked.

REPOSITORY
  rKWIN KWin

BRANCH
  preparation-xdg-shell-shell-surface-may-be-null

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

AFFECTED FILES
  shell_client.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1441: ShellClient's m_shellSurface might be null

[Martin Gräßlin]

graesslin added a dependency: D1440: Move ShellClient initialization code into 
a dedicated init method.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1440: Move ShellClient initialization code into a dedicated init method

[Martin Gräßlin]

graesslin added a dependent revision: D1441: ShellClient's m_shellSurface might 
be null.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Munich Sprint

[Jonathan Riddell]

There's a sprint in Munich with our favourite large Plasma rollout,
Limux at the end of May

https://wiki.debian.org/BSP/2016/05/de/Munich
May 27/28/29

They will provide office space and three meals a day but no
accommodation or travel.  I usually book at a room at the nearby
Motel-1 hotel.

No particular theme but I expect me and Harald to be there for KDE neon.

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

Re: RFC: Enabling users to report issues with Plasma widgets

[Friedrich W. H. Kossebau]

Thanks for the feedback so far, everyone.

Looks like this is something were consensus needs more work before moving on 
with whatever plan.

Will look more into this end of April. Though also happy to have someone else 
pick up this topic meanwhile and do the lead.

Until then still welcoming comments from more people to broaden the picture.

Cheers
Friedrich

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

Re: Munich Sprint

[Kai Uwe Broulik]

Hi,

> No particular theme but I expect me and Harald to be there for KDE neon.

Awesome. So please have them explain the UX issues they're having with Plasma 
in such an environment. Issues I could grasp so far were:

* something about a printing tool kde 3 had we lost
* desktop pre-configuration
* kiosk and locking down the desktop so the user couldn't mess it up, including 
the ability to have system settings take precedence (iirc kconfig inheritance 
only works one-way)
* (plasma-)nm scripting / pre-configuration 
* DrKonqi confusing users and the inability to report issues to us (policies) 
so they should be auto-reported to their it dep
* folderview in multi-screen: each screen operates on the same desktop folder, 
confusing users, especially those accustomed to Windows 

Cheers, 
Kai Uwe

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

Re: Munich Sprint

[Luca Beltrame]

In data lunedì 18 aprile 2016 17:14:56 CEST, Kai Uwe Broulik ha scritto:

> * kiosk and locking down the desktop so the user couldn't mess it up,

Some work going on, check "confine" on KDE git.

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B

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 127345: Make it possible for an applet to offer a test object

[David Rosca]

> On April 15, 2016, 6:45 p.m., LUIS GUSTAVO BARRETO wrote:
> > src/plasma/corona.cpp, line 179
> > 
> >
> > If you don't call importLayout() the startupCompleted signal never gets 
> > emitted causing a slow startup of Plasma Desktop.

https://bugs.kde.org/show_bug.cgi?id=360777 ?


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127345/#review94644
---


On March 16, 2016, 11:40 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127345/
> ---
> 
> (Updated March 16, 2016, 11:40 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> In an attempt to make it possible for plasmoid to test themselves in the 
> different shells, provide API to exatract the object that will test the 
> plasmoid instance.
> 
> 
> Diffs
> -
> 
>   src/plasma/corona.cpp 5d17550 
>   src/plasma/private/packages.cpp a5ba81a 
>   src/plasmaquick/appletquickitem.h 4f25f5d 
>   src/plasmaquick/appletquickitem.cpp 9242e9e 
>   src/plasmaquick/private/appletquickitem_p.h 9c24734 
> 
> Diff: https://git.reviewboard.kde.org/r/127345/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

[Differential] [Request, 84 lines] D1443: Applet: Move Application streams with drag and drop

[drosca (David Rosca)]

drosca created this revision.
drosca added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  It is now possible to move streams to different device
  by dragging the stream's icon.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

BRANCH
  applet-movestreams

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

AFFECTED FILES
  applet/contents/ui/ListItemBase.qml
  applet/contents/ui/main.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1443: Applet: Move Application streams with drag and drop

[drosca (David Rosca)]

drosca added a reviewer: Plasma: Design.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, Plasma: Design
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1443: Applet: Move Application streams with drag and drop

[drosca (David Rosca)]

drosca added a comment.


  http://youtu.be/7h_mWdl994c

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, Plasma: Design
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Kirigami: a feature needed for subsurface and api change feedback

[Marco Martin]

Hi all,

one thing that as i understood was needed in the mobile UI of Subsurface, is 
the possibility to add other buttons in the action buttons at the bottom.
here's how my prototype looks like: http://imgur.com/VTHbDBJ
From discussions with the designers, it seems it should be always limited to 
at most three buttons, and this of course influences the final API: there 
should then be 3 separate actions properties instead of a list of an arbitrary 
number of actions, like it happens for context menu actions

In my first working approach, the API looks like this, leftAction and 
rightAction properties work just like mainAction controls the central button:

Page {
mainAction: Action {...}
leftAction: Action {...}
rightAction: Action {...}
contextualActions: [
Action {...},
Action{...}
]
}

Now, since we are still at a prerelease state, I would like a little api 
change.
In QML, is usually considered good manner to group together similar 
properties, to obtain code more tied together and less repeated words in 
property names (such as mainAction LeftAction whateverAction)

for instance you define anchors like
Item {
anchors {
left: parent.left
right: parent.right
...
}
}

following this, the api of Page would look like this:

Page {
actions {
main: Action {...}
left: Action {...}
right: Action {...}
contextualActions: [
Action {...},
Action{...}
]
}
}

opinions? comments? (would be a problem for subsurface for eventually adapting 
existing stuff to new api?)

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

Re: Kirigami: a feature needed for subsurface and api change feedback

[Kai Uwe Broulik]

I like that, also the compact look.

In an Email app when reading a mail for example the main button would be 
"reply" , the right one "forward" and the left one "reply all" or "archive". 
The less important action would be in the context drawer.


  Ursprüngliche Nachricht  
Von:notm...@gmail.com
Gesendet:18. April 2016 7:30 nachm.
An:plasma-devel@kde.org
Antworten:plasma-devel@kde.org
Cc:subsurf...@subsurface-divelog.org
Betreff:Kirigami: a feature needed for subsurface and api change feedback

Hi all,

one thing that as i understood was needed in the mobile UI of Subsurface, is 
the possibility to add other buttons in the action buttons at the bottom.
here's how my prototype looks like: http://imgur.com/VTHbDBJ
From discussions with the designers, it seems it should be always limited to 
at most three buttons, and this of course influences the final API: there 
should then be 3 separate actions properties instead of a list of an arbitrary 
number of actions, like it happens for context menu actions

In my first working approach, the API looks like this, leftAction and 
rightAction properties work just like mainAction controls the central button:

Page {
mainAction: Action {...}
leftAction: Action {...}
rightAction: Action {...}
    contextualActions: [
   Action {...},
Action{...}
]
}

Now, since we are still at a prerelease state, I would like a little api 
change.
In QML, is usually considered good manner to group together similar 
properties, to obtain code more tied together and less repeated words in 
property names (such as mainAction LeftAction whateverAction)

for instance you define anchors like
Item {
anchors {
left: parent.left
right: parent.right
...
}
}

following this, the api of Page would look like this:

Page {
actions {
main: Action {...}
left: Action {...}
right: Action {...}
    contextualActions: [
   Action {...},
Action{...}
]
}
}

opinions? comments? (would be a problem for subsurface for eventually adapting 
existing stuff to new api?)

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

Re: Kirigami: a feature needed for subsurface and api change feedback

[kainz.a]

Webbrowser: new tab, edit url, top page
Image viewer: export, edit,
Am 18.04.2016 19:34 schrieb "Kai Uwe Broulik" :

> I like that, also the compact look.
>
> In an Email app when reading a mail for example the main button would be
> "reply" , the right one "forward" and the left one "reply all" or
> "archive". The less important action would be in the context drawer.
>
>
>   Ursprüngliche Nachricht
> Von:notm...@gmail.com
> Gesendet:18. April 2016 7:30 nachm.
> An:plasma-devel@kde.org
> Antworten:plasma-devel@kde.org
> Cc:subsurf...@subsurface-divelog.org
> Betreff:Kirigami: a feature needed for subsurface and api change feedback
>
> Hi all,
>
> one thing that as i understood was needed in the mobile UI of Subsurface,
> is
> the possibility to add other buttons in the action buttons at the bottom.
> here's how my prototype looks like: http://imgur.com/VTHbDBJ
> From discussions with the designers, it seems it should be always limited
> to
> at most three buttons, and this of course influences the final API: there
> should then be 3 separate actions properties instead of a list of an
> arbitrary
> number of actions, like it happens for context menu actions
>
> In my first working approach, the API looks like this, leftAction and
> rightAction properties work just like mainAction controls the central
> button:
>
> Page {
> mainAction: Action {...}
> leftAction: Action {...}
> rightAction: Action {...}
> contextualActions: [
>Action {...},
> Action{...}
> ]
> }
>
> Now, since we are still at a prerelease state, I would like a little api
> change.
> In QML, is usually considered good manner to group together similar
> properties, to obtain code more tied together and less repeated words in
> property names (such as mainAction LeftAction whateverAction)
>
> for instance you define anchors like
> Item {
> anchors {
> left: parent.left
> right: parent.right
> ...
> }
> }
>
> following this, the api of Page would look like this:
>
> Page {
> actions {
> main: Action {...}
> left: Action {...}
> right: Action {...}
> contextualActions: [
>Action {...},
> Action{...}
> ]
> }
> }
>
> opinions? comments? (would be a problem for subsurface for eventually
> adapting
> existing stuff to new api?)
>
> --
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Kirigami: a feature needed for subsurface and api change feedback

[Dirk Hohndel]

On Mon, Apr 18, 2016 at 07:29:43PM +0200, Marco Martin wrote:
> Hi all,
> 
> one thing that as i understood was needed in the mobile UI of Subsurface, is 
> the possibility to add other buttons in the action buttons at the bottom.
> here's how my prototype looks like: http://imgur.com/VTHbDBJ

Hmm. That looks like one button to me. And way too easy to tap on the
wrong end of that badge shaped thingy... I'd much rather have three
circles, a bigger one in the middle, and zero, one, or two smaller ones,
with some visual separation between them

> From discussions with the designers, it seems it should be always limited to 
> at most three buttons, and this of course influences the final API: there 
> should then be 3 separate actions properties instead of a list of an 
> arbitrary 
> number of actions, like it happens for context menu actions

Thomas has beaten me into submission, yes, three should be enough.

> Page {
>   actions {
>   main: Action {...}
>   left: Action {...}
>   right: Action {...}
>   contextualActions: [
>   Action {...},
>   Action{...}
>   ]
>   }
> }
> 
> opinions? comments? (would be a problem for subsurface for eventually 
> adapting 
> existing stuff to new api?)

Cute. I like it. Just make sure that I can use variables to assign to this
as the available buttons will change depending on context for us.

Switching to a new API isn't really a big deal for us. I build all the
binaries and we already have that little script that always pulls the
latest upstream Kirigamit. It would be nice to have a grace period where
both work, or you can make it a hard switch (I think that would require to
go to version 2.x of Kirigami).

A few days of lead time would be nice, too :-)

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

Re: Kirigami: a feature needed for subsurface and api change feedback

[Thomas Pfeiffer]

On Montag, 18. April 2016 11:28:04 CEST Dirk Hohndel wrote:
> On Mon, Apr 18, 2016 at 07:29:43PM +0200, Marco Martin wrote:
> > Hi all,
> > 
> > one thing that as i understood was needed in the mobile UI of Subsurface,
> > is the possibility to add other buttons in the action buttons at the
> > bottom. here's how my prototype looks like: http://imgur.com/VTHbDBJ
> 
> Hmm. That looks like one button to me. And way too easy to tap on the
> wrong end of that badge shaped thingy... I'd much rather have three
> circles, a bigger one in the middle, and zero, one, or two smaller ones,
> with some visual separation between them

We're still fine-tuning the visual design, with separated buttons still being 
an option.
We are of course also aware of the danger of accidentally hitting the wrong 
button, which is why we'll iterate a bit on whether we can make it work well 
with long-enough "ledges".

Three buttons are always a fallback option, but they just don't really look 
all that nice, so we'll see if we can come up with something that is both 
good-looking _and_ works ergonomically. 

The "one big button with three areas" look also has the advantage that it can 
be used as a bigger additional handle for opening the drawers (as screen 
corners are not really easy to reach).

As always, we try to see how far we can push a new style first, and then lt 
that measure up to reality. It's always an iterative process.

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

[Differential] [Commented On] D1443: Applet: Move Application streams with drag and drop

[colomar (Thomas Pfeiffer)]

colomar added a comment.


  All thumbs up from the usability side!

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, Plasma: Design
Cc: colomar, plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Requested Changes To] D1443: Applet: Move Application streams with drag and drop

[Sebastian Kügler]

sebas requested changes to this revision.
sebas added a reviewer: sebas.
This revision now requires changes to proceed.

INLINE COMMENTS
  applet/contents/ui/ListItemBase.qml:57 I'd turn this into more lines, using 
if's instead of the ternary, that would make it way easier to read.
  applet/contents/ui/ListItemBase.qml:65 Same here, make it more readable by 
spreading over multiple lines
  applet/contents/ui/main.qml:92 accolade on the same line as the function 
definition
  applet/contents/ui/main.qml:105 accolade on the same line as the function 
definition

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma: Design, Plasma, sebas
Cc: sebas, colomar, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1441: ShellClient's m_shellSurface might be null

[Sebastian Kügler]

sebas added a comment.


  What Marco asks. Otherwise, it's fine.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: sebas, mart, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Munich Sprint

[John Layt]

On 18 April 2016 at 16:14, Kai Uwe Broulik  wrote:

> * something about a printing tool kde 3 had we lost

That would be kprinter. Credative / Limux had a replacement for KDE4
called kprinter4 (part of which is a poorly-attributed fork of some
code I wrote for Okular):

http://kde-apps.org/content/show.php/KPrinter4?content=163537
https://quickgit.kde.org/?p=kprinter4.git

It's in playground, been meaning to have a poke at it to see if it's
still of any use. AFAIK though it only works on postscript files and
relies on very old tools like poster, but it shouldn't take much to
generalise it for all file types supported by CUPS, and to update to
more modern PDF-based tools. Add in a Dolphin service for a context
menu print option and it's done. Perhaps a small porting project for
someone to bring it into Plasma5?

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

Re: Kirigami: a feature needed for subsurface and api change feedback

[Marco Martin]

On Monday 18 April 2016, Dirk Hohndel wrote:
> Cute. I like it. Just make sure that I can use variables to assign to this
> as the available buttons will change depending on context for us.
> 
> Switching to a new API isn't really a big deal for us. I build all the
> binaries and we already have that little script that always pulls the
> latest upstream Kirigamit. It would be nice to have a grace period where
> both work, or you can make it a hard switch (I think that would require to
> go to version 2.x of Kirigami).

well, since is not even a final 1.0 yet i would prefer not to do a 2.0 now ;) 
(i was actually planning to do a 2.0 when I'll port the whole thing to 
QtQuickControls2 so after Qt 5.7 is out and around since a while)

so, if it would give problems, I can leave it in the form

Page {
mainAction: Action {...}
leftAction: Action {...}
rightAction: Action {...}
contextualActions: [...

so current code would just work

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

Re: Kirigami: a feature needed for subsurface and api change feedback

[Dirk Hohndel]

On Mon, Apr 18, 2016 at 10:07:32PM +0200, Marco Martin wrote:
> On Monday 18 April 2016, Dirk Hohndel wrote:
> > Cute. I like it. Just make sure that I can use variables to assign to this
> > as the available buttons will change depending on context for us.
> > 
> > Switching to a new API isn't really a big deal for us. I build all the
> > binaries and we already have that little script that always pulls the
> > latest upstream Kirigamit. It would be nice to have a grace period where
> > both work, or you can make it a hard switch (I think that would require to
> > go to version 2.x of Kirigami).
> 
> well, since is not even a final 1.0 yet i would prefer not to do a 2.0 now ;) 
> (i was actually planning to do a 2.0 when I'll port the whole thing to 
> QtQuickControls2 so after Qt 5.7 is out and around since a while)
> 
> so, if it would give problems, I can leave it in the form
> 
> Page {
> mainAction: Action {...}
> leftAction: Action {...}
> rightAction: Action {...}
> contextualActions: [...
> 
> so current code would just work

I have no problem switching to the new syntax. Don't take the 2.x comment
as a "requirement" from me... we've had so many incompatible changes over
the past six months... I'm not worried :-)

Let's get to a solid API that we are all happy with - and I'll be happy to
adjust our code to match that.

When Sebastian and I first talked about using the "mobile components" for
Subsurface-mobile I explicitly agreed that I was happy with this being a
bit of "learning by doing" and at least initially being a moving target.

I guess I was confused about the fact that the current version calls
itself 1.0 :-)

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

Re: Munich Sprint

[dennis knorr]

Hi Kai!
i would have written to the mailinglist like you suggested, but first i
wanted to tidy up our issues before telling about it at the hackfest :>

here a few infos off the top of my head.

On 18.04.2016 17:14, Kai Uwe Broulik wrote:
> Hi,
> 
>> No particular theme but I expect me and Harald to be there for KDE neon.
> 
> Awesome. So please have them explain the UX issues they're having with Plasma 
> in such an environment. Issues I could grasp so far were:
> 
> * something about a printing tool kde 3 had we lost

yeah, a part of it was replaced by the implementation from credativ.

> * desktop pre-configuration

We work on different kinds of desktop systems atm, and have someone who
already has a configured desktop. but on the next login, the network
widget should show up, which is normally not shown (The admins requested
that, since they thought the user would deactivate the network
connection.. which can be quite bad, if your user is 6 kilometers away
in a kindergarden and not very techsavy.

> * kiosk and locking down the desktop so the user couldn't mess it up, 
> including the ability to have system settings take precedence (iirc kconfig 
> inheritance only works one-way)

for example not starting or stopping a widget, not change the
screensaver starting time and stuff like that. We have techsavy users
who can change their own configfiles

> * (plasma-)nm scripting / pre-configuration

that's more a vpnplugin issue (if i interpret that text in accordance to
our talk :D) with openconnect and not really an plasma issue, i think.
the vpnplugin  openconnect has only user privileges, but the almighty
powers that be, decided that the certificate for connecting to the
RemoteAccessSystem should be the same as the machine certificate. The
original cisco implementation (anyconnect) has an demon, which can
access that stuff, but the plugin cannot. credativ works at a demon for
that, but i do not know whether this should go upstream, or
networkmanager should integrate openconnect into their code more closely.

> * DrKonqi confusing users and the inability to report issues to us (policies) 
> so they should be auto-reported to their it dep

that was always some picknick idea of us. the administration regards
privacy very seriously, and the only way we could report issues would
be, if we could let them report to us, and we could define how much can
be seen in a coredump. i'm not totally sure how well that can be
implemented.

> * folderview in multi-screen: each screen operates on the same desktop 
> folder, confusing users, especially those accustomed to Windows 

yeah... like a file in the folder on two screens.. user deletes the file
and does not expect it is not there on the other screen as well... and
more of that user-expecting-different-behaviour- or
user-does-not-understand-anything-stuff.

atm we have some issues with akonadi and/or knotes, but iggi could tell
you more about that one.


But do not rush now...
We're not quite sure, which usecases/issues we have, should or can be
implemented within KDE/Plasma, but at least we thought it would be good
talking about it (or showing them to you).
Additionally ATM, we have a quite a lot heavy projects to build for the
city, so there there are legitimate fears we do not have enough time to
prepare and present you the issues in a good constructive way.

But i hope that explains at least a little bit our problems :-)

Yours, gn8,
Dennis

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

Re: Munich Sprint

[dennis knorr]

Hi from munich,
On 18.04.2016 21:58, John Layt wrote:
> On 18 April 2016 at 16:14, Kai Uwe Broulik  wrote:
> 
>> * something about a printing tool kde 3 had we lost
> 
> That would be kprinter. Credative / Limux had a replacement for KDE4
> called kprinter4 (part of which is a poorly-attributed fork of some
> code I wrote for Okular):

as far as i am aware, kprinter from credativ was only a part which was
needed. The old kde printing system had more features. but as i explain
in my other mail, i first wanted to tidy up our issues before
"ambushing" you. :)

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

Re: Munich Sprint

[dennis knorr]

Hi,
if someone has no account for wiki.debian.org, just mail me or my
colleagues and we will count you in. additionally i idle in #debian-muc
on oftc if you have any questions!
It's better if we know you're coming so we can prepare the right amount
of meals.. :)

we are happy if you come! :-D

See you and now, gn8,
Dennis


On 18.04.2016 14:59, Jonathan Riddell wrote:
> There's a sprint in Munich with our favourite large Plasma rollout,
> Limux at the end of May
> 
> https://wiki.debian.org/BSP/2016/05/de/Munich
> May 27/28/29
> 
> They will provide office space and three meals a day but no
> accommodation or travel.  I usually book at a room at the nearby
> Motel-1 hotel.
> 
> No particular theme but I expect me and Harald to be there for KDE neon.
> 
> Jonathan
> ___
> 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 127586: [calendar] Add a mark to days containing events

[Martin Klapetek]

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

(Updated April 19, 2016, 5:23 a.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Avoid reordering issue


Repository: plasma-framework


Description
---

Simple triangle at the bottom right corner, see screenshot.


Diffs (updated)
-

  src/declarativeimports/calendar/calendar.h 1849ada 
  src/declarativeimports/calendar/calendar.cpp 0c525b7 
  src/declarativeimports/calendar/daysmodel.h 8ab232e 
  src/declarativeimports/calendar/daysmodel.cpp bf99874 
  src/declarativeimports/calendar/qml/DayDelegate.qml 6353827 
  src/declarativeimports/calendar/qml/DaysCalendar.qml d4b8fe4 

Diff: https://git.reviewboard.kde.org/r/127586/diff/


Testing
---


File Attachments


Screenshot
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/06/afefe7ce-7757-4505-9f17-63fca2ec26cb__snapshot109.png


Thanks,

Martin Klapetek

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