Re: kde plasma workspace structure

[Aaron J. Seigo]

On Saturday, June 9, 2012 02:22:43 Alex Fiestas wrote:
> On Sat, Jun 9, 2012 at 12:11 AM, Aaron J. Seigo  wrote:
> > On Friday, June 8, 2012 22:54:03 Alex Fiestas wrote:
> > we have kde-baseapps, and i agree what you've said previously that wewould
> > benefit from having a defined set of "core applications"
> 
> Lately I have been doing a lot of thinking with the idea of an
> Operating System in mind rather than with the Workspace because; what
> is a workspace anyway? Alone what does it solve? Makes any sense
> create a Workspace?

there is merit to thinking on a larger scale. however, there are dangerous 
places the "we're making an OS!" idea can lead as we've seen in other f/oss 
projects, such as:

* sinking lots of your resources into (reinventing) middleware instead of 
using what works and is there. one of the great things about being able to 
focus on one part of the stack is efficiency due to division of labor.

* losing portability to non-Linux (and even specific Linux OSes)

* forgetting that applications may wish to run on other OSes

so as long as we can avoid these kinds of pitfalls, thinking big picture is 
very useful. :)

(btw, the proprietary OSes also have desktop workspaces and developers who 
work exclusively on them. those developers have to work with their kernel and 
user space development teams much as we do. there isn't as much different 
between what we do and they do in that way. major differences are they do it 
hidden behind closed doors and we have more variety.)

> This is something we have struggled with historically, kmix is not in
> kde-workspace because at some point somebody considered that a
> Workspace "can live" without a sound mixer.

this actually goes back to at least kde2. 

we used to have a kdebase module. for the 4.0 release, that was split up and 
you'll now find bits of it in kde-runtime, kde-baseapps and kde-workspace.

when we had kdebase, we also had the kdemultimedia module where *everything* 
multimedia related went. it was expected that if you installed kdelibs+kdebase 
you'd also install kdemultimedia, because then you'd have a complete system. 
(ditto for the other repositories)

over time applications grew (in size as well as number) and this simple 
division between modules made less sense. (kdenetwork was probably the first to 
show these problems.) and now the we have a module for the workspaces, things 
like kmix being in a "multimedia" module makes less and less sense. ;)

so nobody actually decided kmix doesn't belong in the workspace. kind of the 
opposite: the workspace and applications became more clearly defined as their 
own things and some pieces, like kmix, just weren't taken care of and floated 
off.

i agree that it makes sense to drag kmix into kde-workspace since it really 
only makes sense in that scope. every other desktop has their own mixer, 
right? so there's no reason for someone to use kmix elsewhere. (unlike, say, 
digikam or gwenview.) 

that would cause some rethinking of the module structure as the question would 
then be "what's the point of kdemultimedia?", but that's probably long overdue 
as well :)

kmix really ought to integrate with the desktop shell a lot better than it 
currently does and that means a revisit of the UI (which has gotten worse 
rather than better imho ...) the UI we have now is essentially the same UI 
(with various regressions) we had in KDE2. the internals are rather better, so 
there has been progress, just not so much on the bits you can see :)

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kde plasma workspace structure

[Alex Fiestas]

On Sat, Jun 9, 2012 at 12:11 AM, Aaron J. Seigo  wrote:
> On Friday, June 8, 2012 22:54:03 Alex Fiestas wrote:
> we have kde-baseapps, and i agree what you've said previously that wewould
> benefit from having a defined set of "core applications"

Lately I have been doing a lot of thinking with the idea of an
Operating System in mind rather than with the Workspace because; what
is a workspace anyway? Alone what does it solve? Makes any sense
create a Workspace?

The only answer I could think of was that the Workspace only solve a
particular problem natural to platforms such gnu/linux, open/freebsd
where historically by default you had a workspace designed for the
terminal so if you wanted something else you needed an addon that sits
on top of everything else.

Considering what I said above, we shouldn't think of what we do as a
Workspace but instead as a complete OS, since it is merely a
coincidence of how things are done in Unix that we are able to have
multiple workspace or multiple  pretty much anything (Debian offers
freebsd kernel...).

I'm only talking from a designing PoV not technical, I don't want to
stop abstracting things (just to make this point clear).

Why I say all this? because an OS without an application to access to
your data makes 0 sense (dolphin)
An operating system without applications to do the basic things our
target users will want to do with its data makes no sense (gwenview,
music player, video player, browser).
An operating system without hardware capabilities makes no sense
(kmix, power devil...)

This is something we have struggled with historically, kmix is not in
kde-workspace because at some point somebody considered that a
Workspace "can live" without a sound mixer. That someone was and is
right.

Well, just some rambling, I'm still WIP on all this hope you help me
to figure things out in 2 days, can't wait !
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Workspace Next Sprint Organization

[Aleix Pol]

On Fri, Jun 8, 2012 at 6:05 PM, Alex Fiestas  wrote:
> On Friday, June 08, 2012 05:58:46 PM Marco Martin wrote:
>> in there any shopping mall nearby? (or not so nearby but that can be done
>> while we're there)
>
> There is, but I don't think we will find Yarns there, so I will try to buy
> that today.
>
> We will go to that mall to buy all the rest, including the cereal boxes I will
> end up eating after the sprint :p
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

There is a Carrefour quite close to the venue and I/we'll have to go
there anyway to get the KDE Spain-sponsored food, so once we're there
we can buy what's missing. If we can make sure we have the weirdest
items, that would be good, though.

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

Re: Workspace Next Sprint Organization

[Alex Fiestas]

We don't do weird plug though :p

I have conversors I can bring if you don't have one
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [KDE Bugtracking System] REMINDER: current Plasma regressions

[Viranch Mehta]

On Sat, Jun 9, 2012 at 12:58 AM,  wrote:

> **
>
> 301424  normal NOR openSUSE
> RPMs plasma-b...@kde.org NEW --- Cannot open battery monitor applet if
> set to hidden in systray
>

@Marco: can you look into this please? seems like a bug with compact
representation and plasmoid.togglePopup()

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

Re: kde plasma workspace structure

[Aaron J. Seigo]

On Friday, June 8, 2012 22:54:03 Alex Fiestas wrote:
> Where will dolphin be? An application with Blue dot?

i think so, yes.

to beh noest, i really struggled with where file management belonged in the 
past. what it came down to was the it runs just fine outside of KDE's 
workspaces (a lot of people use it this way in fact :) and ought to look like 
the other applications rather than the desktop shell since it is not a system 
service or shell component.

still .. it cries out for more harmonization and integration with the overall 
system than most other applications.

one thing we have done for Active is define some application identity HIGs and 
really worked to create a clear cross-application identity. it does make a big 
difference, and i've read the same in some of your emails / irc discussions.

we have kde-baseapps, and i agree what you've said previously that wewould 
benefit from having a defined set of "core applications" from the SC packages 
that we pull into a similar sort of application design program and work on 
consistency and beauty on them as being key applications for all our desktop 
users. dolphin, gwenview, ...? 
 
> Though these live out of kde-workspace, I guess that BlueDevil, KMix, etc
> goes within the Worksapce square, right?

yes, pretty much anything that is a "system service". i just didn't have 
enough space in that square and figured i didn't need to make an exhaustive 
list of everything, just give examples :)

networkmanagement is another one of these as well, of course.
i expect the telepathy components will also end up in that circle.

one interesting result of this is that it makes us consider how to make things 
work in all / as many possible workspaces as possible. right now system 
settings doesn't succeed in that. while it was kind-of-sort-of usable on a 
tablet, we ended up having to do a simplified and more focused version using 
QML. this is a huge burdon and will result in long-term inconsistencies, 
however. it would be really nice if system settings could be designed to work 
better across form factors.

otherwise, all the other bits are doing quite well already as we've designed 
and/or improved the various components to meet these requirements.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workspace Next Sprint Organization

[David Edmundson]

On Fri, Jun 8, 2012 at 6:39 PM, Kevin Ottens  wrote:
> On Friday 08 June 2012 18:22:51 Alex Fiestas wrote:
>> On Friday, June 08, 2012 05:41:25 PM Kevin Ottens wrote:
>> >  - A dozen white boxes (ideally roughly the cereal box size, can be
>> >  slightly
>> >
>> > bigger
>>
>> I doub't we can find this easily, anybody can bring those? I have been told
>> they are sold in ikea for example.
>
> Well, no small archive boxes? (you apparently have a mall around, so maybe
> there's an office supply shop) Ideally they'd be completely white but worst
> case we can stick paper on it to make them white if there's some writing on
> them.
>
I thought I knew what was going on at this sprint till now...


> Now, if that's really too much of a problem scrap them off the list. If you do
> so, you can also drop all the rest I sent today except perhaps the soft balls.
>
I have 5 juggling balls I can bring. If nothing else they're good for
throwing at Dario if he misbehaves.

Alex (or anyone else in mainland Europe) could you remember to bring
some 2 or 3 power strips between us. [1]

[1] Not sure if that's the right word; these things:
http://spyshop.ie/images/4-way-surge-protector-strip.jpg but with Euro
plugs.


> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud patron of KDE, http://www.kdab.com
>
> ___
> 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: kde plasma workspace structure

[Marco Martin]

On Friday 08 June 2012, Alex Fiestas wrote:
> On Friday, June 08, 2012 10:01:35 PM Aaron J. Seigo wrote:
> > hi...
> > 
> > here is a rough block diagram of the overall kde software stack:
> > http://plasma.kde.org/media/kde_block_diagram.png
> 
> Apart from useful and complete beautiful :p
> 
> Where will dolphin be? An application with Blue dot?
> 
> Though these live out of kde-workspace, I guess that BlueDevil, KMix, etc
> goes within the Worksapce square, right?
> 
> Thanks for the work :)

i see dolphin kindof a connector berween the workspace and other apps, because 
while is an app, its visual semantics are those of an app (but then folderview 
is very similar too), it organizes data and is the main way many other apps 
are launched (i think is quite more common clicking on a pdf than launching 
okular)
in a technical diagram like that app for sure, in something that would 
represent only how things are functionally presented to the user, should be a 
kind of connector in between

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

Re: kde plasma workspace structure

[Alex Fiestas]

On Friday, June 08, 2012 10:01:35 PM Aaron J. Seigo wrote:
> hi...
> 
> here is a rough block diagram of the overall kde software stack:
> 
>   http://plasma.kde.org/media/kde_block_diagram.png
Apart from useful and complete beautiful :p

Where will dolphin be? An application with Blue dot?

Though these live out of kde-workspace, I guess that BlueDevil, KMix, etc goes 
within the Worksapce square, right?

Thanks for the work :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[kde-workspace] plasma/generic/applets/lock_logout: keep plugin name consistent between releases

[Aaron Seigo]

Git commit dd23569be148fa900de5046871c703a2873b5eb8 by Aaron Seigo.
Committed on 08/06/2012 at 22:19.
Pushed by aseigo into branch 'master'.

keep plugin name consistent between releases

when rewriting plugins in QML they MUST keep the same plugin name or else
people's configurations will become broken!

CCMAIL:plasma-devel@kde.org
BUG:301368

M  +1-1plasma/generic/applets/lock_logout/metadata.desktop

http://commits.kde.org/kde-workspace/dd23569be148fa900de5046871c703a2873b5eb8

diff --git a/plasma/generic/applets/lock_logout/metadata.desktop 
b/plasma/generic/applets/lock_logout/metadata.desktop
index 341bfde..6cc4304 100644
--- a/plasma/generic/applets/lock_logout/metadata.desktop
+++ b/plasma/generic/applets/lock_logout/metadata.desktop
@@ -182,7 +182,7 @@ X-Plasma-DefaultSize=80,120
 
 X-KDE-PluginInfo-Author=Viranch Mehta
 X-KDE-PluginInfo-Email=viranch.me...@gmail.com
-X-KDE-PluginInfo-Name=org.kde.lockout
+X-KDE-PluginInfo-Name=lockout
 X-KDE-PluginInfo-Version=1.0
 X-KDE-PluginInfo-Website=http://plasma.kde.org/
 X-KDE-PluginInfo-Category=System Information
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[KDE Bugtracking System] REMINDER: current Plasma regressions

[bugzilla_noreply]

Please find below a list of the current regressions reported for Plasma

  This search was scheduled by myr...@kde.org.


Plasma regressions
--
Bug 283626:
  https://bugs.kde.org/show_bug.cgi?id=283626
  Priority: NOR  Severity: crash  Platform: openSUSE RPMs
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: plasma-desktop crashes when Adding Widget while ActivityManager is 
visible [@  ActivityManager::setLocation]
Bug 296117:
  https://bugs.kde.org/show_bug.cgi?id=296117
  Priority: NOR  Severity: minor  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: New Add Widgets dialog does not respect fractional font sizes
Bug 299254:
  https://bugs.kde.org/show_bug.cgi?id=299254
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Regression: QML lock/logout applet only lays out icons in panel 
direction
Bug 300885:
  https://bugs.kde.org/show_bug.cgi?id=300885
  Priority: NOR  Severity: critical  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Weather widget does not work anymore with bbcuk or wetter.com 
provider
Bug 301194:
  https://bugs.kde.org/show_bug.cgi?id=301194
  Priority: NOR  Severity: normal  Platform: Archlinux Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: switching category in adding widget doesn't work correctly 
(especially when scrolling to the right)
Bug 301239:
  https://bugs.kde.org/show_bug.cgi?id=301239
  Priority: NOR  Severity: major  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Applications get included in All Activities by default
Bug 301359:
  https://bugs.kde.org/show_bug.cgi?id=301359
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Tooltips in "Add Widget" panel isn't big enough to contain text
Bug 301368:
  https://bugs.kde.org/show_bug.cgi?id=301368
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Old Lock/logout widget not automatically replaced by new QML one on 
update to 4.9beta
Bug 301424:
  https://bugs.kde.org/show_bug.cgi?id=301424
  Priority: NOR  Severity: normal  Platform: openSUSE RPMs
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Cannot open battery monitor applet if set to hidden in systray
Bug 301460:
  https://bugs.kde.org/show_bug.cgi?id=301460
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Switching activities became really slow


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

Re: Review Request: Misc fixes in widget explorer tooltip including missing i18n

[Commit Hook]

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


This review has been submitted with commit 
a93955384daef64a0a41b9ee26ff0cbc24960b17 by David Edmundson to branch master.

- Commit Hook


On June 7, 2012, 5:31 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105177/
> ---
> 
> (Updated June 7, 2012, 5:31 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Add missing space in "License:" and "Author" in tooltip label of widget 
> explorer
> Resize tooltip to match text size (instead of truncating)
> Port Text to PlasmaComponents.Label so that fonts are respected.
> add missing i18n
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml 
> ea0606a 
> 
> Diff: http://git.reviewboard.kde.org/r/105177/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

kde plasma workspace structure

[Aaron J. Seigo]

hi...

here is a rough block diagram of the overall kde software stack:

http://plasma.kde.org/media/kde_block_diagram.png

some notes:

* the applications have little dots in them:
Blue -> desktop
Pink -> Touch (Harmattan, Active, ...)
Universal -> one UI, works everywhere

* the UIs, even when they are touch UIs, belong to the application projects.

* the application list is not complete ;)

* there is a lot more in kde-workspaces, but most of the big pieces are there. 

* acronyms DM is display manager, SM is session manager

* the QML/HTML5 blocks above Plasma in the dev platform section are the 
bindings and script engines used by plasmoids, dataengines, etc.

* workspace utils includes things like kcheckpass, kfreespacenotifier, 
plasmapkg, kwrited, etc.

* you can see how kde-runtime gets pulled in various directions (the reason 
for the change in frameworks5 -> make it consistent by putting each individual 
thing where they most belong)

* the individual workspaces (Desktop, Netbook, Active..) are layered above 
Workspaces; everything underneath them is shared. Workspaces is one set of 
technology. it is also worked on as one large project.

* Plasma Active is "Plasma" + "Active". just like Calligra Active is 
"Calligra" + "Active"


here is a rough diagram of what goes into one of the Plasma specializations:

http://plasma.kde.org/media/plasma_specializaton_block_diagram.png

the 3 specializations we've done range from 4k to 25k LOC each. in other 
words: they are small. in comparison, the folderview plasmoid is nearly 8k 
LOC.

there is also a somewhat dated, but still generally accurate, page on techbase 
about design of a Plasma shell:

http://techbase.kde.org/Development/Tutorials/Plasma/ShellDesign

questions / comments?

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Misc fixes in widget explorer tooltip including missing i18n

[Marco Martin]

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

Ship it!


looks fine. i think is ok at add the new i18n there because it was already 
displayed untranslated anyways, so things don't get worse

- Marco Martin


On June 7, 2012, 5:31 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105177/
> ---
> 
> (Updated June 7, 2012, 5:31 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Add missing space in "License:" and "Author" in tooltip label of widget 
> explorer
> Resize tooltip to match text size (instead of truncating)
> Port Text to PlasmaComponents.Label so that fonts are respected.
> add missing i18n
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml 
> ea0606a 
> 
> Diff: http://git.reviewboard.kde.org/r/105177/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Workspace Next Sprint Organization

[Kevin Ottens]

On Friday 08 June 2012 18:22:51 Alex Fiestas wrote:
> On Friday, June 08, 2012 05:41:25 PM Kevin Ottens wrote:
> >  - A dozen white boxes (ideally roughly the cereal box size, can be
> >  slightly
> >
> > bigger
>
> I doub't we can find this easily, anybody can bring those? I have been told
> they are sold in ikea for example.

Well, no small archive boxes? (you apparently have a mall around, so maybe
there's an office supply shop) Ideally they'd be completely white but worst
case we can stick paper on it to make them white if there's some writing on
them.

Now, if that's really too much of a problem scrap them off the list. If you do
so, you can also drop all the rest I sent today except perhaps the soft balls.

I'll have to come up with a backup plan if you do that though, so please let
me know.

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


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: Workspace Next Sprint Organization

[Kevin Ottens]

On Friday 08 June 2012 17:50:57 Alex Fiestas wrote:
> We already went shopping for the stuff you asked before (yesterday) :/

My apologies again for the late request.

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Workspace Next Sprint Organization

[Alex Fiestas]

On Friday, June 08, 2012 05:41:25 PM Kevin Ottens wrote:
>  - A dozen white boxes (ideally roughly the cereal box size, can be slightly
> bigger
I doub't we can find this easily, anybody can bring those? I have been told 
they are sold in ikea for example.

This we can buy at a carrefour near the venue:
> couple of old empty cereal boxes (full is fine as well, but we'll have to
> make sure we eat the content during the sprint) :-D
>  - Sharp-tip markers (could be the same ones than the black ones for paper,
> the tip is somewhat important though)
>  - Colored markers
>  - A few pair of scissors
>  - A few rolls of Scotch tape
>  - A few staplers

I will try to buy those today.
>  - Yarns in assorted colors (at least red/blue/green)

No idea where to buy or if they are available at carrefour
>  - Plenty of stickers of different shape and colors (at least a few "large
> golden star" ones, but the most types we have the better)
>  - A dozen colored soft balls (yeah you can find that in a kid store)

If anyone can bring scissors, scotch tape, staplers, please do ! the more we 
have the better !

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

Re: Re: Workspace Next Sprint Organization

[Alex Fiestas]

On Friday, June 08, 2012 05:58:46 PM Marco Martin wrote:
> in there any shopping mall nearby? (or not so nearby but that can be done
> while we're there)

There is, but I don't think we will find Yarns there, so I will try to buy 
that today.

We will go to that mall to buy all the rest, including the cereal boxes I will 
end up eating after the sprint :p
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workspace Next Sprint Organization

[Marco Martin]

On Friday 08 June 2012, Alex Fiestas wrote:
> We already went shopping for the stuff you asked before (yesterday) :/ and
> I have all my weekend busy with family stuff I can't skip.
> 
> Maybe we can arrange to somebody to take care of this.

in there any shopping mall nearby? (or not so nearby but that can be done 
while we're there)

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

Re: Re: Workspace Next Sprint Organization

[Alex Fiestas]

We already went shopping for the stuff you asked before (yesterday) :/ and I 
have all my weekend busy with family stuff I can't skip.

Maybe we can arrange to somebody to take care of this.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workspace Next Sprint Organization

[Kevin Ottens]

Hello,

On Friday 11 May 2012 23:23:29 Kevin Ottens wrote:
> On Friday 11 May 2012 22:19:31 Àlex Fiestas wrote:
> > When I come back from SFO I will start together with Aleix the arragements
> > for the sprint, fromm the top of my head:
> >
> > -Whiteboards
> > -Projectors
> > -Food
> > -Car
> > -Write how to get there
>
> Would it be possible to also add to the list:
>  - Markers both for the whiteboards and black ones for paper
>  - A shitload of sticky notes in different sizes and colors
>  - Flipboards
>  - Quite some Blu-Tack, Patafix or equivalent[*]
>
> Plse? :-)

OK, you'll hate me for that on such a short notice, but I'd like to also add
the following items to the list:
 - A dozen white boxes (ideally roughly the cereal box size, can be slightly
bigger, but not something you'd use to move apartments please) :-)
 - A couple of old empty cereal boxes (full is fine as well, but we'll have to
make sure we eat the content during the sprint) :-D
 - Sharp-tip markers (could be the same ones than the black ones for paper,
the tip is somewhat important though)
 - Colored markers
 - A few pair of scissors
 - A few rolls of Scotch tape
 - Yarns in assorted colors (at least red/blue/green)
 - Plenty of stickers of different shape and colors (at least a few "large
golden star" ones, but the most types we have the better)
 - A few staplers
 - A dozen colored soft balls (yeah you can find that in a kid store)

Yeah I know, it sounds strange to ask for those, but if we get all of that
it'll make more sense at some point. :-)

And yes I'm serious about the list above... really.

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


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: KDE architecture diagram

[Marco Martin]

On Friday 08 June 2012, Dario Freddi wrote:

> > there will be enough on the agenda without adding marketing to it, and
> > there are many people not there who ought to be if marketing was part of
> > the mix.
> 
> I partly disagree here. In the first frameworks sprint we also created
> a plan which was shared afterwards - I am not talking about making a
> decision but proposing one. We all know by our experience that a
> targeted group of people meeting in person can easily speed up the
> job.
> 
> That said, I agree that there are more pressing and important items on
> the agenda

just going over a bit on what is called what and in what context (so what as 
end user name what as technology name etc) could make sense even just to be 
sure to have dot article/planet posts that make sense and not introduce 
further confusion, so yeah, more on terminology to use, not much marketing 
strategy

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

Re: KDE architecture diagram

[Marco Martin]

On Friday 08 June 2012, Aleix Pol wrote:
> > 
> > same thing for names of tecnologies (there should be advertized as
> > developer tools but never to the end user) so in the ui should never
> > ever appear nepomuk, phonon or akonadi for instance.
> > 
> > different discourse for products that are directly in front of the user:
> > "plasma desktop" or "amarok" or "gwenview" are more like microsoft word,
> > iOS or iTunes
> > 
> > Cheers,
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> 
> Well many of us probably still see Plasma as a technology.

it is indeed, depends if you wants also use those 6 letters as a sticker for 
the workspace or not 

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

Re: KDE architecture diagram

[Aleix Pol]

On Fri, Jun 8, 2012 at 4:23 PM, Marco Martin  wrote:
> On Friday 08 June 2012, Tomaz Canabrava wrote:
>> 'Plasma' and 'Nepomuk - whatever this means' ? those namings are
>> confusing, and if you guys really want a broader audience, you should
>> really make it easy for people that are not on your field to use your
>> software. I understand that technologies must have a name, I'm also an
>> scientist after all, but you will not see a thing about
>> paleobathymetry or stratigraphy in anything that I write if the focus
>> is people outside of my area of knowledge.
>
> yep, she's right. actually SC was never a name to be targetted to the public.
>
> same thing for names of tecnologies (there should be advertized as developer
> tools but never to the end user) so in the ui should never ever appear
> nepomuk, phonon or akonadi for instance.
>
> different discourse for products that are directly in front of the user:
> "plasma desktop" or "amarok" or "gwenview" are more like microsoft word, iOS
> or iTunes
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Well many of us probably still see Plasma as a technology.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Dario Freddi]

2012/6/7 Aaron J. Seigo :
>> but it occurred to
>> me we have indeed a serious naming problem (which I believe was the
>> main source of misunderstanding over the last days) on all of this. In
>> my opinion the diagram makes more sense when s/Workspace/Desktop. I
>> see more the concept of "workspaces", aka desktop, mobile, tablet
>> etc...
>
> calling it "desktop" fails for various reasons (all of which have been
> discussed extensively elsewhere in past years):
>
> * we have the legacy of "desktop" both in "KDE" and "the KDE Desktop"
> * a t.v. recorder is not a desktop. we might be able to grin and say "that
> tablet is running a desktop system", but that is even a bit of a stretch.

Makes sense indeed, although my point was not really about the
"desktop" work but about the distinction - it was not a suggestion but
just a way in which the diagram would have made more sense to me.

>
> that said .. there are certainly bigger issues than this we have to in front
> of us to tackle to bring our efforts into sync.

Agreed, and indeed we should start working on this.

>> I guess a goal for the next sprint should indeed be starting from
>> something like this and drawing a scenario, also in a marketing
>> perspective.
>
> there will be enough on the agenda without adding marketing to it, and there
> are many people not there who ought to be if marketing was part of the mix.

I partly disagree here. In the first frameworks sprint we also created
a plan which was shared afterwards - I am not talking about making a
decision but proposing one. We all know by our experience that a
targeted group of people meeting in person can easily speed up the
job.

That said, I agree that there are more pressing and important items on
the agenda
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Dario Freddi]

2012/6/8 Aurélien Gâteau :
>> > Perhaps the "KDE Workspace" box should be named " KDE SC Plasma
>> > Workspaces".
>> how is this difference useful? (serious question, not rhetorical.)
>
> I suggested "SC" to avoid people thinking I consider Active not to be a KDE
> Workspace. It is a KDE workspace just like Desktop and Netbook, which is just
> not part of the SC.
>
> And "Workspaces" vs "Workspace" because there are two workspaces in there:
> Desktop and Netbook.

I'd like to point out that the 4.8 release announcement was
advertising Plasma WorkspaceS as well (
http://kde.org/announcements/4.8/ ), just to point out the issue
stands even outside the context of this list/sprint/etc.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Marco Martin]

On Friday 08 June 2012, Tomaz Canabrava wrote:
> 'Plasma' and 'Nepomuk - whatever this means' ? those namings are
> confusing, and if you guys really want a broader audience, you should
> really make it easy for people that are not on your field to use your
> software. I understand that technologies must have a name, I'm also an
> scientist after all, but you will not see a thing about
> paleobathymetry or stratigraphy in anything that I write if the focus
> is people outside of my area of knowledge.

yep, she's right. actually SC was never a name to be targetted to the public.

same thing for names of tecnologies (there should be advertized as developer 
tools but never to the end user) so in the ui should never ever appear 
nepomuk, phonon or akonadi for instance.

different discourse for products that are directly in front of the user: 
"plasma desktop" or "amarok" or "gwenview" are more like microsoft word, iOS 
or iTunes

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

Re: possible topic for sprint: wayland

[Aleix Pol]

On Fri, Jun 8, 2012 at 3:59 PM, Martin Gräßlin  wrote:
> On Friday 08 June 2012 14:54:25 Aaron J. Seigo wrote:
>> p.s. at Tokamaks in the past, we've take on topics that we know will not get
>> implemented between now and the next Tokamak. we discuss them so that when
>> the next Tokamak happens, we can start with fully formed ideas and the
>> necessary research done. it has been rather useful in ensuring progress
>> gets made.
> as a matter of fact: the complete plan on how to get KWin to Wayland is in my
> head. I just need to transfer the knowledge to other people ;-) Oh and the
> complete 4.9 cycle was about preparing KWin for Wayland port - that's why we
> have scripting, now.
>
> Cheers
> Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

We should put an insurance on Martin's head, like Jennifer [1].

Cheers :)

[1] http://urbanlegends.about.com/cs/celebrities/a/jennifer_lopez.htm
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 05:49:00 Tomaz Canabrava a écrit :
> On Fri, Jun 8, 2012 at 5:37 AM, Aurélien Gâteau  wrote:
> > Perhaps the "KDE Workspace" box should be named " KDE SC Plasma
> > Workspaces".
> As one of the most active Talkers about KDE on universities that are
> not on the IT field, I strongly disagree with that.
> I'v been doing talks on a lot of fields ( from Design schools to
> History universities ) and the main point of doubt on the atendees is
> the naming convention ( over 20 talks this year ),
> one girl actually send me an e-mail as follows, translated from portuguese.:

I understand that. The name is not the best I came up with and would need to 
be fixed if this document were to become more public (I don't think it will, 
though). What is more important in my opinion, is to have a common 
understanding of how elements are grouped together.
I have not been closely tracking Plasma developments these past months, so I 
think my understanding of the way things work can be useful to people who are 
so involved in Plasma development they know all its nuts and bolts from inside 
out and thus can be surprised others are confused.

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

Re: possible topic for sprint: wayland

[Martin Gräßlin]

On Friday 08 June 2012 14:54:25 Aaron J. Seigo wrote:
> p.s. at Tokamaks in the past, we've take on topics that we know will not get
> implemented between now and the next Tokamak. we discuss them so that when
> the next Tokamak happens, we can start with fully formed ideas and the
> necessary research done. it has been rather useful in ensuring progress
> gets made.
as a matter of fact: the complete plan on how to get KWin to Wayland is in my 
head. I just need to transfer the knowledge to other people ;-) Oh and the 
complete 4.9 cycle was about preparing KWin for Wayland port - that's why we 
have scripting, now.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 15:11:57 Aaron J. Seigo a écrit :
> On Friday, June 8, 2012 14:37:09 Aurélien Gâteau wrote:
> > just means it is released using a different schedule
> 
> in what way does the release schedule matter? what does it change that is
> important to understand when asking "what is plasma, how is put together and
> how can we move it forward"?

It is a classification. I think it helps grasping the whole picture. If it does 
not matter to you, just ignore that blue rectangle, but I think it can help 
new developers.

> > Perhaps the "KDE Workspace" box should be named " KDE SC Plasma
> > Workspaces".
> how is this difference useful? (serious question, not rhetorical.)

I suggested "SC" to avoid people thinking I consider Active not to be a KDE 
Workspace. It is a KDE workspace just like Desktop and Netbook, which is just 
not part of the SC.

And "Workspaces" vs "Workspace" because there are two workspaces in there: 
Desktop and Netbook.

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

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 15:07:17 Aaron J. Seigo a écrit :

> ok.. let's try to define that then. i'll offer what i see as a product, as
> then perhaps you can do the same and we can compare and hopefully
> understand each other better.
> 
> Product: a finished whole that is presented in a form that is useful to the
> intended audience.
> 
> using that as a starting point, then to me the Linux kernel is a product
> delivered in a useful form to OS and hardware vendors; they then use the
> Linux kernel to make products useful to end users.
> 
> the Linux kernel is very different from kernels before it (and even many
> today). prior to the Linux kernel, we had operating systems "for servers" or
> "for desktops" or "for mobile". hardware evolved and new thinking emerged
> and "Linux" is now a product that services super computers, servers,
> desktops, mobile, embedded, etc. as a hardware spectrum. there are deltas
> in the code for each target, but it's one product.
> 
> Plasma is similar. we deliver a UX in form useful for OS and hardware
> vendors; they use it to make products useful to end users.
> 
> Plasma is different from other workspace UX frameworks before it (and even
> many today). prior to Plasma, we have workspaces that are "for desktops"
> and "for phones" and "for PDAs" and "for tablets". hardware has evolved and
> our new thinking is that the workspace product should service workstations,
> desktops, tablets, set top boxes, IVI, phones, etc. there are deltas in the
> code for each target, but Plasma is one product.
> 
> Desktop, Netbook, Active and whatever else we add to it in the future
> extends this product with different device and use case targets. this is
> analogous to the arch trees in the Linux kernel.

My definition is indeed different. To me, Plasma Desktop, Plasma Netbook and 
Plasma Active are three products, which are all built on top of a shared set 
of components and applets.

As a user, my system is running either the Desktop, Netbook or Active product. 
I can switch from one to another as I want.

To me, Plasma is an umbrella term which groups together the shells, the 
applets and the components.

This is how I see it could match with the Linux analogy:

- Plasma Active is the Android kernel, Plasma Desktop is the kernel shipped by 
my distro.

They share a lot of code: Plasma Active and Desktop through dynamic libraries, 
the Android and distro kernels by building from (mostly) the same source tree.

They are also very different: Plasma shells through different binaries which 
make different use of the Plasma components, kernels through compilation 
options and different patchsets.

- A Plasma applet is a kernel module, some are developed in-tree, others are 
out-of-tree.
The Linux situation here further reinforces the fact that different kernels are 
different products: Say you have a TI ARM board. If you build your own kernel 
for it, and a few modules. If you switch back to the kernel provided by TI, 
there is no chance for you to load any module built for your kernel: TI takes 
the Linux kernel and creates a different product out of it.

- Plasma is the kernel, plus all modules, plus the low level plumbing 
libraries used to communicate with user-space.

> > But this discussion is going nowhere so let's end it.
> 
> how can we come to a common undestanding if we don't discuss?
> if we don't come to a common understanding, how can we succeed?
> 
> it's worth it.

Time will tell.

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

Re: Re: Re: KDE architecture diagram

[Sebastian Kügler]

On Friday, June 08, 2012 12:35:46 Martin Klapetek wrote:
> On Fri, Jun 8, 2012 at 12:01 PM, Sebastian Kügler  wrote:
> > Food for thought: How many Linux kernel developers do you know that try to
> > divide the Linux kernel in subprojects for servers, desktops, embedded
> > systems? Here, just like in Plasma, there are a few codepathes that differ
> > per
> > device, but the majority of the code is shared. The differences come from
> > how
> > you configure it for a given target device. That is conceptually the same
> > as
> > with Plasma we're building a system that you can configure for a wide
> > range of
> > target devices.
> 
> While I share your idea of Plasma Workspaces, I would imagine that
> different parts of the kernel are maintained/developed by different people.
> Sure, the core is the same, but the platform-specific stuff needs to be
> different (if only a little). So one needs to see the difference between
> core and the "workspace" in our Plasma case. In other words - if you add
> method to the core and make use of it in Active, it doesn't magically
> happen on desktop too. 

Some examples, to prove you're wrong in most cases:

- Plasmoids: can be used without any change on the desktop
- Functionality added in existing plasmoids (see above)
- bugfixes/performance improvements in libplasma: directly benefit all 
  "products" based on libplasma
- all the work happening on dataengines, scriptengines, bindings, scripting, 
  window manager integration -- all device agnostic
- QML Ports of existing functionality: Makes it even more device-agnostic
- Device specific plasmoids: Kickoff and taskbar for Plasma Desktop, Activity 
switcher for Desktop and Active); for these, you're right, those are 
only a 
  handful, though, and should hardly be the base for a general statement

> Which I think might be on of the problems - seeing
> the Plasma team focusing on Active, bringing new features there while the
> desktop is...well, it's the same for the past 3 years. 

I don't think that's accurate. Actually, for the sake of an experiment: Take 
Plasma Desktop from KDE SC 4.3 and compare it to 4.9 (you'll get pretty much 3 
years of development).

One fact is that desktop users are rather adverse to change, so we have to be 
very conservative with user-visible changes. So yes, panel's still at the 
bottom, we still have taskbar, startmenu, system tray, etc. 
I don't think that is really related to this discussion (but can easily be 
confused with it).

> And just look at
> Facebook - they change stuff every 2 years or so. Now I'm not saying let's
> forget what we have and start over. Not at all. But we're quite stagnating.

I don't see how that's comparable, applicable, or even a good idea. Change 
should be driven by necessity, not by "well, it's been 2 years already...". 
That just gets us into trouble.

> And that's in my opinion, where we need the vision. Aaron's vision is
> great, but to me it sounds more like a general textbook "workspace vision".
> I personally think we need a more precise vision (we already do have
> organic uis, don't we?). For example - what's our vision for integrating
> social media in the shell/Plasma? What's our vision for integrating IM? And
> so on. Sure, there are teams doing these tasks, but we should imho have a
> common vision, or goal if you wish, clearly defined by the Workspace
> leaders. Those teams 

if those are separate teams, you'll get inconsistent results. They all need to 
be driven by the same vision. Otherwise, results will differ across devices, 
and it will make duplication of work easier (we want neither).

> then lookup to that vision and build stuff to reach
> it. To reach one great Workspace. Just like for Active - you have a vision
> of creating a touch-based interfaces (very simply speaking), so basically
> there's a vision of how you'd like Okular to behave in such environment.

Touch-based is not part of the vision, and never has been. It's an implication 
detail and we need to make things touch-friendly because otherwise their 
applicability is limited to only a part of the device spectrum. Note that we 
built widgets with touch-friendliness in mind years before "Active" was born.

> And I would like to have this precise vision for the rest of the Workspace,
> not just "to have scalable interfaces".

"scalable" comes closer to our vision, but in the end, it also derives from 
the device spectrum concept.

> Each and every team can do their own vision. But then there will be
> inconsistencies, different functionality etc. Just look at System Settings
> - common place for so many apps and yet each module looks different. And it
> looks bad in the final result. So I think there should be some well
> understood "lead", a way the Workspace should go. Which currently there's
> not. Or it's not well known.

You're making the right point here. We need supervision across subgroups, 
ideally, we'll work as one big team.

Understanding that is reall

Re: Re: KDE architecture diagram

[Sebastian Kügler]

On Friday, June 08, 2012 14:37:09 Aurélien Gâteau wrote:
> Perhaps the "KDE Workspace" box should be named " KDE SC Plasma Workspaces".

Read this: http://community.kde.org/Promo/Branding/Map#KDE_Workspaces

in short: ("KDE Workspaces", in principle can include other workspaces, 
"Plasma Workspaces" defines workspaces done "the Plasma way", and the "KDE" in 
"KDE Plasma Workspace" is optional.)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 14:37:09 Aurélien Gâteau wrote:
> just means it is released using a different schedule

in what way does the release schedule matter? what does it change that is
important to understand when asking "what is plasma, how is put together and
how can we move it forward"?

> Perhaps the "KDE Workspace" box should be named " KDE SC Plasma Workspaces".

how is this difference useful? (serious question, not rhetorical.)

sq;nr <-- i should start using that :)

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 14:31:14 Aurélien Gâteau wrote:
> Le vendredi 8 juin 2012 14:22:37 Aaron J. Seigo a écrit :
> > another fun tidbit: did you know that the search & launch (aka SAL)
> > containment was designed for Netbook, but is also used for the Plasma
> > KPart
> > now and is very popular amongst Desktop users? :)
>
> I am aware of that. I fail to see how it relates to our current discussion.

it is relevant because it helps show how the different workspaces (Desktop,
Netbook and Active) work together and influence each other.

that relationship is the same for all three Workspaces.

> Furthermore, I don't care about kittens.

heh :P puppies then. or whatever makes you go "aww"

> > > > Food for thought: How many Linux kernel developers do you know that
> > > > try
> > > > to
> > > > divide the Linux kernel in subprojects for servers, desktops, embedded
> > > > systems?
> > >
> > > This comparison is not adapted IMO: the kernel is one single product,
> > > with
> > > many modules. Your comparison would work if we were shipping only one
> > > shell
> > > with many applets.
> >
> > plasma is a single product with many modules. that's one of the core
> > design
> > concepts.
>
> It seems we disagree on what a product is.

ok.. let's try to define that then. i'll offer what i see as a product, as then
perhaps you can do the same and we can compare and hopefully understand each
other better.

Product: a finished whole that is presented in a form that is useful to the
intended audience.

using that as a starting point, then to me the Linux kernel is a product
delivered in a useful form to OS and hardware vendors; they then use the Linux
kernel to make products useful to end users.

the Linux kernel is very different from kernels before it (and even many
today). prior to the Linux kernel, we had operating systems "for servers" or
"for desktops" or "for mobile". hardware evolved and new thinking emerged and
"Linux" is now a product that services super computers, servers, desktops,
mobile, embedded, etc. as a hardware spectrum. there are deltas in the code
for each target, but it's one product.

Plasma is similar. we deliver a UX in form useful for OS and hardware vendors;
they use it to make products useful to end users.

Plasma is different from other workspace UX frameworks before it (and even many
today). prior to Plasma, we have workspaces that are "for desktops" and "for
phones" and "for PDAs" and "for tablets". hardware has evolved and our new
thinking is that the workspace product should service workstations, desktops,
tablets, set top boxes, IVI, phones, etc. there are deltas in the code for
each target, but Plasma is one product.

Desktop, Netbook, Active and whatever else we add to it in the future extends
this product with different device and use case targets. this is analogous to
the arch trees in the Linux kernel.

what this means for the architecture diagram will become apparent when i post
it :)

> But this discussion is going nowhere so let's end it.

how can we come to a common undestanding if we don't discuss?
if we don't come to a common understanding, how can we succeed?

it's worth it.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

possible topic for sprint: wayland

[Aaron J. Seigo]

hi ...

while most discussion has concentrated so far on "what the (#*$ is plasma?", 
for which i nominate this as the official theme song:

http://www.youtube.com/watch?v=QrDui7xeGv0

and looking at topics regarding specific functionalty integration (e.g. "how do 
we deal with beamers", "what about social media?") there's another topic 
looming that will impact all of our efforts: wayland.

kwin needs more people working on its wayland compositor.

there is a lot of X11 API usage in Plasma Desktop for things like panel 
unhiding.

XAtom are used in in libplasma for window manager integration. (in Frameworks, 
that code has moved to libkwindowsystem, but the issue is no different as the 
code was just moved, not modified)

Active is probably a perfect testbed for Wayland integration (simpler use 
cases, hardware clearly defined, etc.) but then we need a plan for how to 
determine that Wayland support is good enough to use in Active, good enough to 
bring to Desktop and Netbook, and how to actually do that.

Qt gets Wayland support in Qt5: http://www.youtube.com/watch?v=QQXkQ2QgFZY

it will be a significant step forward for F/OSS clients, and it would be great 
to be a step ahead here to take advantage of it.

i don't know if people will have the time or interest in discussing this at 
the sprint, but it would be an excellent topic to at least start discussion 
on.

p.s. at Tokamaks in the past, we've take on topics that we know will not get 
implemented between now and the next Tokamak. we discuss them so that when the 
next Tokamak happens, we can start with fully formed ideas and the necessary 
research done. it has been rather useful in ensuring progress gets made.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Kevin Ottens]

On Friday 08 June 2012 14:39:37 Aaron J. Seigo wrote:
> ~15kLOC current delta, 10K LOC of "real" delta once workspace and kdelibs
> branches get merged, and 250k LOC total (well, closer to 300K depending on
> what you count; but i'm being a little conservative in what i included
> there)
>
> the 250k number is libplasma + runtime components relevant to libplasma +
> relevant kde-workspace libraries + generic plugins (dataengines, plasmoids).
> if i am more liberal and include components that "could be but maybe not"
> considered part of the shared workspace, it goes up closer to 300k.
>
> the Plasma Desktop delta from the base 250-300K LOC is 25k LOC.
>
> the Plasma Netbook delta is 4.2K LOC.
>
> so Netbook is the smallest, Active is in the middle and Desktop has the most
> added to it on top of the share core bits.

Much clearer, thanks.

> Desktop is so big because of things like kickoff, the tasks widget and the
> relative complexity of plasma-desktop itself (which will come down when we
> move all of that to QML).

Yes, that would be my expectations as well. Looking forward to the
QMLification of those.

> > > there was also a discussion on g+ (not a good location, i know :) about
> > > QML'ifying system settings between myself and the system settings
> > > maintainer (and others). we'll probably take things we've learned from
> > > Active Settings and apply it there.
> >
> > Since we agree that Google+ was probably not the best location for such a
> > discussion, any chance to have a link to it for reference?
>
> https://plus.google.com/100202326091940882253/posts/j9N6kAp7bk2

Thanks!

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


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: KDE architecture diagram

[Tomaz Canabrava]

On Fri, Jun 8, 2012 at 5:37 AM, Aurélien Gâteau  wrote:
> [Damn. Just when I say I am out of this discussion, a message arrives I feel
> the urge to answer.]
>
> Le vendredi 8 juin 2012 14:31:08 Aaron J. Seigo a écrit :
>> it would be like saying that Calligra, Amarok and Digikam are somehow of a
>> different class compared to KMail because KMail is in the SC. that is not
>> how we've been dealing with applications for years now.
> [snip]
>> if we look at the technical artifacts, it is apparent that Plasma Active is
>> one of the KDE Workspaces, on equal terms to Plasma Desktop and Plasma
>> Netbook (and vice versa), and that work on one improves the others.
>
> I would like to clear one misunderstanding: the fact I placed Plasma Active
> out of the KDE SC does not mean I consider the product to be a second-class
> citizen or that I consider it not to be a fully-fledged Plasma workspace. It
> just means it is released using a different schedule, which is totally fine.
>
> Perhaps the "KDE Workspace" box should be named " KDE SC Plasma Workspaces".

As one of the most active Talkers about KDE on universities that are
not on the IT field, I strongly disagree with that.
I'v been doing talks on a lot of fields ( from Design schools to
History universities ) and the main point of doubt on the atendees is
the naming convention ( over 20 talks this year ),
one girl actually send me an e-mail as follows, translated from portuguese.:

 "Dear tomaz,

I actually like your talk and I do agree on most things that you'v
said, unfortunately, the wikis and pages about KDE are confusing, for
instance, from your talk I know that kde has a collection of software
that are free to use and modify and I don't need to pay for them even
if I install them here on the university, but what are the differences
between KDE, I mean, why is 'KDE' the people and not the programs?
There's really a need for namings such as 'KDE' and 'KDE SC' and
'Plasma' and 'Nepomuk - whatever this means' ? those namings are
confusing, and if you guys really want a broader audience, you should
really make it easy for people that are not on your field to use your
software. I understand that technologies must have a name, I'm also an
scientist after all, but you will not see a thing about
paleobathymetry or stratigraphy in anything that I write if the focus
is people outside of my area of knowledge.

Best Regards,

Ana Cristina"

And I agree with her, she has a very good point.

Tomaz Canabrava

> Aurélien
> ___
> 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: KDE architecture diagram

[Kevin Ottens]

On Friday 08 June 2012 14:22:37 Aaron J. Seigo wrote:
> On Friday, June 8, 2012 13:47:18 Aurélien Gâteau wrote:
> > My goal with this diagram was to illustrate end-user products and how they
> > are grouped under umbrella terms, rather than teams.
>
> then it isn't an architecture diagram, and it shouldn't include things like
> kdelibs.

Not that I want to make the discussion even messier than it already is, but
please keep in mind that although kdelibs is kind of buried in the KDE
Platform product. This situation is going to change with KDE Frameworks which
will become a (meta-)product on its own[*].

So if we chart current situation, it's likely kdelibs shouldn't appear as a
product (KDE Platform OTOH is debatable...), if we chart the future[**] KDE
Frameworks (which is going to be close in content to kdelibs + kde-runtime)
should appear.

Regards.

[*] At least that's what my crystal ball says.
[**] Hello? Hello? Anybody home? Huh? Think, McFly. Think!
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


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: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 14:30:18 Kevin Ottens wrote:
> On Friday 08 June 2012 14:09:36 Aaron J. Seigo wrote:
> > the design of Plasma lets us take the overwhelming majority of code and
> > re-use it across workspace shells. that's the entire point. i've
> > calculated
> > that the current delta between Active and Desktop is ~15000 LOC, and that
> > once we merge some branches (e.g. the QML screen locking branch) that will
> > drop down to ~10k LOC. the other ~250 LOC (not counting kdelibs, qt, and
> > all that of course :) is shared.
> 
> I guess there's typo in the numbers, doesn't quite add up to me. Any chance
> you could help me there with proper numbers?

~15kLOC current delta, 10K LOC of "real" delta once workspace and kdelibs 
branches get merged, and 250k LOC total (well, closer to 300K depending on 
what you count; but i'm being a little conservative in what i included there)

the 250k number is libplasma + runtime components relevant to libplasma + 
relevant kde-workspace libraries + generic plugins (dataengines, plasmoids). 
if i am more liberal and include components that "could be but maybe not" 
considered part of the shared workspace, it goes up closer to 300k.

the Plasma Desktop delta from the base 250-300K LOC is 25k LOC. 

the Plasma Netbook delta is 4.2K LOC. 

so Netbook is the smallest, Active is in the middle and Desktop has the most 
added to it on top of the share core bits. Desktop is so big because of things 
like kickoff, the tasks widget and the relative complexity of plasma-desktop 
itself (which will come down when we move all of that to QML).

> > there was also a discussion on g+ (not a good location, i know :) about
> > QML'ifying system settings between myself and the system settings
> > maintainer (and others). we'll probably take things we've learned from
> > Active Settings and apply it there.
> 
> Since we agree that Google+ was probably not the best location for such a
> discussion, any chance to have a link to it for reference?

https://plus.google.com/100202326091940882253/posts/j9N6kAp7bk2

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aurélien Gâteau]

[Damn. Just when I say I am out of this discussion, a message arrives I feel 
the urge to answer.]

Le vendredi 8 juin 2012 14:31:08 Aaron J. Seigo a écrit :
> it would be like saying that Calligra, Amarok and Digikam are somehow of a
> different class compared to KMail because KMail is in the SC. that is not
> how we've been dealing with applications for years now.
[snip]
> if we look at the technical artifacts, it is apparent that Plasma Active is
> one of the KDE Workspaces, on equal terms to Plasma Desktop and Plasma
> Netbook (and vice versa), and that work on one improves the others.

I would like to clear one misunderstanding: the fact I placed Plasma Active 
out of the KDE SC does not mean I consider the product to be a second-class 
citizen or that I consider it not to be a fully-fledged Plasma workspace. It 
just means it is released using a different schedule, which is totally fine.

Perhaps the "KDE Workspace" box should be named " KDE SC Plasma Workspaces".

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

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 14:22:37 Aaron J. Seigo a écrit :
> On Friday, June 8, 2012 13:47:18 Aurélien Gâteau wrote:
> > My goal with this diagram was to illustrate end-user products and how they
> > are grouped under umbrella terms, rather than teams.
> 
> then it isn't an architecture diagram, and it shouldn't include things like
> kdelibs.

I started the document under the name was kde-galaxy.svg, but I felt it was a 
bit too presomptuous.

> another fun tidbit: did you know that the search & launch (aka SAL)
> containment was designed for Netbook, but is also used for the Plasma KPart
> now and is very popular amongst Desktop users? :)

I am aware of that. I fail to see how it relates to our current discussion.

> > and, I guess, the Active UI part of applications like Okular
> > and Marble (at least to bootstrap the process of having Active-friendly
> > applications)
> 
> we are not responsible for Marble's Active UI at all. we invited Marble to
> get involved and they have. we are also not responsible for Kontact Touch
> or Calligra Active. we are big supporters of them and do help as we can,
> but then many of us do that in general because that's what we do in KDE :)
> 
> we contributed the Okular UI to Okular itself, and we hope that in future
> more of the apps will have touch UIs maintained by their respective teams
> in future because this does not scale for us. we're doing it now because we
> have to.

Sure.

> btw... every time someone says "I guess..." and then instead of asking a
> question makes a statement of "fact" a kitten dies a horrible, horrible
> death.

> please, stop guessing and start asking. we'll save a lot of pain that way.

Thank you for taking the time to fix my grammar, but I'd like to keep the right 
to express myself as I see fit. Furthermore, I don't care about kittens.

> > > Food for thought: How many Linux kernel developers do you know that try
> > > to
> > > divide the Linux kernel in subprojects for servers, desktops, embedded
> > > systems?
> > 
> > This comparison is not adapted IMO: the kernel is one single product, with
> > many modules. Your comparison would work if we were shipping only one
> > shell
> > with many applets.
> 
> plasma is a single product with many modules. that's one of the core design
> concepts.

It seems we disagree on what a product is. But this discussion is going 
nowhere so let's end it.

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

Re: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 14:01:45 Aurélien Gâteau wrote:
> Le vendredi 8 juin 2012 12:20:43 Aaron J. Seigo a écrit :
> > > If I am not mistaken, kde workspace and plasma active are developed in
> > > different repositories,
> >
> > kde-runtime is also developed in a different repository. so is folderview,
> > which is definitely part of KDE Workspaces; it's also in Plasma Desktop,
> > but not Plasma Active. where something is developed depends on a number
> > of factors: how it is packaged, what its dependencies are, development
> > conveniences .. etc.
> >
> > when you consider that QML bindings which are now critical to all the
> > Workspaces are in kde-runtime, folderview is in kdebase-apps and only
> > relevant to Desktop and Netbook, that the DataEngines in kde-workspace are
> > critical to all Workspaces, that the QML components in kde-runtime were
> > developed first in plasma-mobile and then migrated there when they were
> > ready for wide use so we can use them in all Workspaces  it becomes
> > apparent that repository structure does not beget the technical design.
>
> As I answered to Sebas, I was not aiming at charting technical design, but

ah, then i was confused by the title "KDE Architecture Diagram" and the
inclusion of things like kdelibs.

> rather at identifying products and how they are grouped.

why is this important? or rather, what are we trying to undestand here from
doing this?

(and in the case that we do want to identify product groupings: Netbook needs
to be split out; there should be an entry in there somewhere for the KPart;
and we should probably have a devel tools section)

> > > and target different devices.
> >
> > so does Netbook, but it's in kde-workspace.
>
> True, the argument they target different devices is not relevant and should
> be ignored.

cool :)

> Nevertheless, from a product point-of-view, KDE SC ships (among other
> products) two Plasma workspaces, Plasma Active ships another one. To the
> end- user (and I guess the new developer) they are different products.

KDE ships three workspaces. 2 are released in a 6 month cycle in tandem with
the rest of the packages, the other (Active) is released on a separate
schedule. the division between SC and not-SC is a release engineering
implementation detail and says nothing of the product grouping or relevance.

it would be like saying that Calligra, Amarok and Digikam are somehow of a
different class compared to KMail because KMail is in the SC. that is not how
we've been dealing with applications for years now.

> Which developers work on which products is orthogonal to the fact they are
> different products: when someone talks to me about KDE SC, KDE Workspace,
> or Plasma Active, I care about what technical artefacts (as in binaries,
> libraries, components, data assets) those terms encompass, not who wrote
> the code

if we look at the technical artifacts, it is apparent that Plasma Active is
one of the KDE Workspaces, on equal terms to Plasma Desktop and Plasma Netbook
(and vice versa), and that work on one improves the others.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Kevin Ottens]

On Friday 08 June 2012 14:09:36 Aaron J. Seigo wrote:
> the design of Plasma lets us take the overwhelming majority of code and
> re-use it across workspace shells. that's the entire point. i've calculated
> that the current delta between Active and Desktop is ~15000 LOC, and that
> once we merge some branches (e.g. the QML screen locking branch) that will
> drop down to ~10k LOC. the other ~250 LOC (not counting kdelibs, qt, and
> all that of course :) is shared.

I guess there's typo in the numbers, doesn't quite add up to me. Any chance
you could help me there with proper numbers?

Not that it's the most important point in your mail but I'm generally curious
about this kind of numbers and I'd like to have a somewhat accurate picture in
mind when I pitch the tech to the outside. :-)

> there was also a discussion on g+ (not a good location, i know :) about
> QML'ifying system settings between myself and the system settings maintainer
> (and others). we'll probably take things we've learned from Active Settings
> and apply it there.

Since we agree that Google+ was probably not the best location for such a
discussion, any chance to have a link to it for reference?

Regards.
--
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com


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: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 13:47:18 Aurélien Gâteau wrote:
> My goal with this diagram was to illustrate end-user products and how they
> are grouped under umbrella terms, rather than teams.

then it isn't an architecture diagram, and it shouldn't include things like
kdelibs.

how products are presented to the public and how the architecture is designed
is not a 1:1 relationship. at least not in Plasma, and that is 100%
purposeful.

> It makes total sense
> to me that Plasma developers are responsible for libplasma from kdelibs,
> Plasma components in kde-runtime, plasma-desktop, plasma-netbook from
> kde-workspace

indeed. and the architecture is such that those shared components are shared
and there is not a huge delta between desktop, netbook and workspace.

another fun tidbit: did you know that the search & launch (aka SAL)
containment was designed for Netbook, but is also used for the Plasma KPart
now and is very popular amongst Desktop users? :)

> and, I guess, the Active UI part of applications like Okular
> and Marble (at least to bootstrap the process of having Active-friendly
> applications)

we are not responsible for Marble's Active UI at all. we invited Marble to get
involved and they have. we are also not responsible for Kontact Touch or
Calligra Active. we are big supporters of them and do help as we can, but then
many of us do that in general because that's what we do in KDE :)

we contributed the Okular UI to Okular itself, and we hope that in future more
of the apps will have touch UIs maintained by their respective teams in future
because this does not scale for us. we're doing it now because we have to.

that said, this is a team structure issue, not an architecture or even a
product issue.

btw... every time someone says "I guess..." and then instead of asking a
question makes a statement of "fact" a kitten dies a horrible, horrible death.

please, stop guessing and start asking. we'll save a lot of pain that way.

> > Food for thought: How many Linux kernel developers do you know that try to
> > divide the Linux kernel in subprojects for servers, desktops, embedded
> > systems?
>
> This comparison is not adapted IMO: the kernel is one single product, with
> many modules. Your comparison would work if we were shipping only one shell
> with many applets.

plasma is a single product with many modules. that's one of the core design
concepts.

we ship one set of applets (with a few specific to different shells), share code
between shells (libplasmagenericshell's name is a good hint there :).

this is not completely unlike the various arch/ implementations found in the
kernel source tree.

so it is a very accurate comparison. it is a comparison that drove the design
of plasma, so that's unsurprising.

perhaps instead of the comparison being not adapted, your understanding is
incorrect. perhaps we offered that comparison to help improve your
understanding. instead of arguing for your understanding to the people who
actually designed and wrote the code in question, you could consider the
comparison made and think about how that may require adjustment in your
understanding.

> And actually, the kernel is very much based on subprojects: you won't find a
> lot of filesystem developers working on usb support or network-stack
> developers debugging the arm device-tree mess.

and it's exactly the same in plasma. lots of people work only on specific
things. we have one guy who only works on folderview bugs and performance, for
instance.

it's still one whole project from which products are derived based on the
modules used and the build configuration.

let's try this:

Linux is an OS kernel technology from which products are derived based on the
modules used, which are worked on by various people in sub-projects with sharp
focus, and the build configuration selected.

Plasma is a UX technology from which products are derived based on the modules
used, which are worked on by various people in sub-projects with sharp focus,
and the build configuration selected.

both are accurate high-level overviews of the respective projects.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 12:35:46 Martin Klapetek wrote:
> While I share your idea of Plasma Workspaces, I would imagine that
> different parts of the kernel are maintained/developed by different people.

and they don't whinge at each about it ;)

> Sure, the core is the same, but the platform-specific stuff needs to be
> different (if only a little). So one needs to see the difference between
> core and the "workspace" in our Plasma case.

the "core" makes up 95%+ of the "workspace".

i'm beginning to think that people are judging on the looks rather than the 
code, and that worries me because it would mean people are making conclusions 
without knowledge.

the design of Plasma lets us take the overwhelming majority of code and re-use 
it across workspace shells. that's the entire point. i've calculated that the 
current delta between Active and Desktop is ~15000 LOC, and that once we merge 
some branches (e.g. the QML screen locking branch) that will drop down to ~10k 
LOC. the other ~250 LOC (not counting kdelibs, qt, and all that of course :) 
is shared.

from libplasma to the script engines to the plasmoids themselves there is 
great consistency.

so differentiating between core and workspace is not as useful as one might 
expect at first.

> In other words - if you add
> method to the core and make use of it in Active, it doesn't magically
> happen on desktop too.

not always, but often yes it does. did you notice the new activity manager.

> Which I think might be on of the problems - seeing
> the Plasma team focusing on Active, bringing new features there 

many of those new features are available to and have appeared in the desktop. 
the new activity manager daemon, the QML components, improvements in various 
plasmoiods, etc. 

there is still much more to take advantage of in Desktop, and thankfully the 
design lets that happen easily. the same design that has let us do Active. it 
is *not* a zero-sum game where Active takes away from Desktop or vice versa. 
efforts in one improve the others. they also bring in more developers.

there's also the fact that working on a touch interface gives new interest in 
and perceived (and real) sustainability to the KDE Workspaces.

let's look at the big picture here.

btw, it sounds very whingy when people get annoyed that we've worked on Active 
just because they'd like us to work more on Desktop. it sounds very much like 
we're being told "do what *i* want". well, all of us who worked on Desktop and 
now contribute to Active have also continued working on Desktop in parallel. 
who do you think did the new Applets chooser, work of libtaskmanager and the 
tasks widget, etc. etc.?

my hope is that instead of whinging at us about working on Active and ignoring 
our parallel efforts on Desktop, that people will pitch in and work on the 
parts that interest them and move those things forward faster.

> desktop is...well, it's the same for the past 3 years. 

tasks launchers, new window switcher (in QML no less :), several plasmoids 
ported to QML (only somewhat user visible in that the results are usually 
graphically smoother, but necessary work), addition of javascript for the 
layouts (and many improvements to that in the last 18 months), system tray 
refinements, the Plasma KPart now used in a number of apps ...

now, i do understand what you're saying: the desktop hasn't had a major set of 
visual changes in the last few years. it's all been incremental and 
evolutionary. that does *not* mean people have not been working on it or 
caring for it.

performance improvements and bug fixes are critical to the maturing and 
therefore the adoption of the desktop interface.

> And just look at
> Facebook - they change stuff every 2 years or so. Now I'm not saying let's
> forget what we have and start over. Not at all. But we're quite stagnating.

compare 4.5 with 4.9. use 4.5 for a week or two, then come back to 4.9. 
there's been forward movement.

now, when we make change, we need to be able to say why we're making those 
changes. change for its own sake is useless. which means that not doing a 
revolution every N years is not necessarily a bad thing. major changes should 
happen when they need to. not sooner, not later.

so saying "we're stagnating" when we not only have things like Active going on 
(which really takes the wind out of our sails, btw: "what you're doing has no 
value" is exactly how it ends up sounding like.) but also moving Desktop 
forward is ludicrous. btw, if you want to see a shell that is stagnating: 
Netbook. it hasn't seen any major work in a while.

so if we wish to talk about stagnation let us:

* stay real to the actual efforts, not invent "nothing has been happening" when 
there has been

* define what change we want to see and describe why that change should happen. 
speaking in generalities ("it's stangating") will not move things forward.

> And that's in my opinion, where we need the vision. Aaron's vision is
> great, but to me it s

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 12:20:43 Aaron J. Seigo a écrit :
> > If I am not mistaken, kde workspace and plasma active are developed in
> > different repositories,
> 
> kde-runtime is also developed in a different repository. so is folderview,
> which is definitely part of KDE Workspaces; it's also in Plasma Desktop, but
> not Plasma Active. where something is developed depends on a number of
> factors: how it is packaged, what its dependencies are, development
> conveniences .. etc.
> 
> when you consider that QML bindings which are now critical to all the
> Workspaces are in kde-runtime, folderview is in kdebase-apps and only
> relevant to Desktop and Netbook, that the DataEngines in kde-workspace are
> critical to all Workspaces, that the QML components in kde-runtime were
> developed first in plasma-mobile and then migrated there when they were
> ready for wide use so we can use them in all Workspaces  it becomes
> apparent that repository structure does not beget the technical design.

As I answered to Sebas, I was not aiming at charting technical design, but 
rather at identifying products and how they are grouped.

> > and target different devices.
> 
> so does Netbook, but it's in kde-workspace.

True, the argument they target different devices is not relevant and should be 
ignored.

Nevertheless, from a product point-of-view, KDE SC ships (among other 
products) two Plasma workspaces, Plasma Active ships another one. To the end-
user (and I guess the new developer) they are different products. Which 
developers work on which products is orthogonal to the fact they are different 
products: when someone talks to me about KDE SC, KDE Workspace, or Plasma 
Active, I care about what technical artefacts (as in binaries, libraries, 
components, data assets) those terms encompass, not who wrote the code (unless 
I got it completely wrong and the "Plasma Active" term designates a community 
of developers, just like the "KDE" term now does)

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

Re: KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 12:01:39 Sebastian Kügler a écrit :
> On Thursday, June 07, 2012 22:16:13 Aurélien Gâteau wrote:
> > Le jeudi 7 juin 2012 21:11:09 Aaron J. Seigo a écrit :
> > > there's an artificial spliting between "kde workspace" and "plasma
> > > active"
> > > that does not exist. those of us working on these things keep saying
> > > that
> > > but nobody seems to either be listening to or believing us :)
> > 
> > If I am not mistaken, kde workspace and plasma active are developed in
> > different repositories, have different release schedules and target
> > different devices. That was enough for me to split them.
> 
> Most of it is developed in the same repository (kde-runtime, kde-workspace,
> and basically the whole rest of the stack). Only the shell and a few apps
> are developed in a separate repository (which I think is more an artifact
> of us moving to quickly in the past year to clean up after ourselves than
> anything else). The different release schedules ... I don't know.
> 
> On the one hand, we untangling what we currently release as KDE SC, making
> separate releases for platform, workspaces and apps, on the other hand. On
> the other hand, we've thought about releasing the plasma-mobile repo
> together with the rest of KDE SC. We see that requirements for devices are
> a bit different, and that we want to cater for that with an "always
> releasable" system.
> 
> Still, ideally we'd roll stable releases of an always releasable core
> together with SC releases, but are basically able to do a device with the
> latest snapshots at any point in time.
> 
> 
> To me, it's really much more like this:
> 
> 
>   Plasma Workspaces
> 
>   KDE Platform
> 
> 
> Plasma Workspace includes Desktop, Netbook, Active, Mediacenter, etc.. This
> may look oversimplified, but I don't think it is. Technical details such as
> what you can find in which repository, how packages are split are really
> only technical details for the sake of deployment, but it's certainly not a
> structure we can use to define ourselves and what we do.
> 
> Just like for apps that ship different kinds of UIs, the "Plasma Active
> Workspace" is just a different flavour of the "Plasma Workspace", just like
> the desktop. In most cases it does not make much sense to draw an artifical
> line. (The same holds true for Calligra Active vs Calligra (Desktop),
> Okular, Marble, etc... who all might use different UIs bases on the target
> device. From that, you can derive "Plasma principles" such as "a component
> should work with different formfactors and input devices" and "a component
> should work across multiple devices" quite logically, and I think that's
> the mindset we need to foster.
> I think we're doing ourselves a disservice if we see these things as
> different "projects" or even teams, and we should not to that.

I understand Plasma Active Workspace is a Plasma workspace, just like Plasma 
Desktop and Plasma Netbook are. The Plasma Active Workspace is however 
released separately from KDE SC and that is what I wanted to highlight. Note 
that I don't see anything wrong with that.

My goal with this diagram was to illustrate end-user products and how they are 
grouped under umbrella terms, rather than teams. It makes total sense to me 
that Plasma developers are responsible for libplasma from kdelibs, Plasma 
components in kde-runtime, plasma-desktop, plasma-netbook from kde-workspace 
and, I guess, the Active UI part of applications like Okular and Marble (at 
least to bootstrap the process of having Active-friendly applications)

> Food for thought: How many Linux kernel developers do you know that try to
> divide the Linux kernel in subprojects for servers, desktops, embedded
> systems?

This comparison is not adapted IMO: the kernel is one single product, with 
many modules. Your comparison would work if we were shipping only one shell 
with many applets.

And actually, the kernel is very much based on subprojects: you won't find a 
lot of filesystem developers working on usb support or network-stack developers 
debugging the arm device-tree mess.

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

Re: KDE architecture diagram

[Mario Fux]

Am Freitag 08 Juni 2012, 12.35:46 schrieb Martin Klapetek:

Morning

> On Fri, Jun 8, 2012 at 12:01 PM, Sebastian Kügler  wrote:
> > Food for thought: How many Linux kernel developers do you know that try
> > to divide the Linux kernel in subprojects for servers, desktops,
> > embedded systems? Here, just like in Plasma, there are a few codepathes
> > that differ per
> > device, but the majority of the code is shared. The differences come from
> > how
> > you configure it for a given target device. That is conceptually the same
> > as
> > with Plasma we're building a system that you can configure for a wide
> > range of
> > target devices.
> 
> While I share your idea of Plasma Workspaces, I would imagine that
> different parts of the kernel are maintained/developed by different people.
> Sure, the core is the same, but the platform-specific stuff needs to be
> different (if only a little). So one needs to see the difference between
> core and the "workspace" in our Plasma case. In other words - if you add
> method to the core and make use of it in Active, it doesn't magically
> happen on desktop too. Which I think might be on of the problems - seeing
> the Plasma team focusing on Active, bringing new features there while the
> desktop is...well, it's the same for the past 3 years. And just look at

That's simply not true. The Plasma Desktop is not the same as three years ago. 
There is steady development (even if it my be slower than at the beginning but 
that can change). Beneath the usual optimization and fixing stuff (which may 
come mostly from the Active side atm but helps the desktop nonetheless), there 
are things which are completely different then 3 years ago. Take the 
Activities vs. ZUI thing as just one example.

> Facebook - they change stuff every 2 years or so. Now I'm not saying let's
> forget what we have and start over. Not at all. But we're quite stagnating.
> 
> And that's in my opinion, where we need the vision. Aaron's vision is
> great, but to me it sounds more like a general textbook "workspace vision".
> I personally think we need a more precise vision (we already do have
> organic uis, don't we?).

Maybe but that's no reason to scratch this item from a vision list. But atm 
the same time there is of course the possibility to widen or enhance the 
vision. So I'm still curious what Spain meeting and after this the Randa 
Meeting/Tokamak 6 brings:

Hint hint: http://sprints.kde.org/sprint/98 <- add yourself here.

> For example - what's our vision for integrating
> social media in the shell/Plasma? What's our vision for integrating IM? And
> so on. Sure, there are teams doing these tasks, but we should imho have a
> common vision, or goal if you wish, clearly defined by the Workspace
> leaders. Those teams then lookup to that vision and build stuff to reach
> it. To reach one great Workspace. Just like for Active - you have a vision
> of creating a touch-based interfaces (very simply speaking), so basically
> there's a vision of how you'd like Okular to behave in such environment.
> And I would like to have this precise vision for the rest of the Workspace,
> not just "to have scalable interfaces".

Makes sense for me what your write here.

> Each and every team can do their own vision. But then there will be
> inconsistencies, different functionality etc. Just look at System Settings
> - common place for so many apps and yet each module looks different. And it
> looks bad in the final result. So I think there should be some well
> understood "lead", a way the Workspace should go. Which currently there's
> not. Or it's not well known.
> 
> My 2c on this.

Just my 2 Rappen
Mario
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: KDE architecture diagram

[Martin Klapetek]

On Fri, Jun 8, 2012 at 12:01 PM, Sebastian Kügler  wrote:

>
> Food for thought: How many Linux kernel developers do you know that try to
> divide the Linux kernel in subprojects for servers, desktops, embedded
> systems? Here, just like in Plasma, there are a few codepathes that differ
> per
> device, but the majority of the code is shared. The differences come from
> how
> you configure it for a given target device. That is conceptually the same
> as
> with Plasma we're building a system that you can configure for a wide
> range of
> target devices.
>

While I share your idea of Plasma Workspaces, I would imagine that
different parts of the kernel are maintained/developed by different people.
Sure, the core is the same, but the platform-specific stuff needs to be
different (if only a little). So one needs to see the difference between
core and the "workspace" in our Plasma case. In other words - if you add
method to the core and make use of it in Active, it doesn't magically
happen on desktop too. Which I think might be on of the problems - seeing
the Plasma team focusing on Active, bringing new features there while the
desktop is...well, it's the same for the past 3 years. And just look at
Facebook - they change stuff every 2 years or so. Now I'm not saying let's
forget what we have and start over. Not at all. But we're quite stagnating.

And that's in my opinion, where we need the vision. Aaron's vision is
great, but to me it sounds more like a general textbook "workspace vision".
I personally think we need a more precise vision (we already do have
organic uis, don't we?). For example - what's our vision for integrating
social media in the shell/Plasma? What's our vision for integrating IM? And
so on. Sure, there are teams doing these tasks, but we should imho have a
common vision, or goal if you wish, clearly defined by the Workspace
leaders. Those teams then lookup to that vision and build stuff to reach
it. To reach one great Workspace. Just like for Active - you have a vision
of creating a touch-based interfaces (very simply speaking), so basically
there's a vision of how you'd like Okular to behave in such environment.
And I would like to have this precise vision for the rest of the Workspace,
not just "to have scalable interfaces".

Each and every team can do their own vision. But then there will be
inconsistencies, different functionality etc. Just look at System Settings
- common place for so many apps and yet each module looks different. And it
looks bad in the final result. So I think there should be some well
understood "lead", a way the Workspace should go. Which currently there's
not. Or it's not well known.

My 2c on this.

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

Re: KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 12:01:39 Sebastian Kügler wrote:
> Food for thought: How many Linux kernel developers do you know that try to
> divide the Linux kernel in subprojects for servers, desktops, embedded
> systems?

thanks for bringing up this example Sebastian :) it's one that we've used for
years in Plasma to explain to ourselves and others what we're doing.

"Just as the Linux kernel looked at the spectrum of devices from embedded to
desktop to server to supercomputer as a continuum that could be serviced with
one flexible kernel"

so this is not just a really great example that Sebas picked out of thin air
for this email, it's actually the example we've been using as a team as we
work on Plasma.

cheers ...

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE architecture diagram

[Aaron J. Seigo]

On Thursday, June 7, 2012 22:16:13 Aurélien Gâteau wrote:
> Le jeudi 7 juin 2012 21:11:09 Aaron J. Seigo a écrit :
> > there's an artificial spliting between "kde workspace" and "plasma active"
> > that does not exist. those of us working on these things keep saying that
> > but nobody seems to either be listening to or believing us :)
>
> If I am not mistaken, kde workspace and plasma active are developed in
> different repositories,

kde-runtime is also developed in a different repository. so is folderview,
which is definitely part of KDE Workspaces; it's also in Plasma Desktop, but
not Plasma Active. where something is developed depends on a number of
factors: how it is packaged, what its dependencies are, development
conveniences .. etc.

when you consider that QML bindings which are now critical to all the
Workspaces are in kde-runtime, folderview is in kdebase-apps and only relevant
to Desktop and Netbook, that the DataEngines in kde-workspace are critical to
all Workspaces, that the QML components in kde-runtime were developed first in
plasma-mobile and then migrated there when they were ready for wide use so we
can use them in all Workspaces  it becomes apparent that repository
structure does not beget the technical design.

> have different release schedules

a small digression first:

the One True Release Cycle is a legacy of KDE being a smaller project in the
past. before extragear (long, long ago when the earth was young), *all* KDE
applications were released in the One True Release. there just weren't that
many apps, and all the apps being worked on were applicable to all / most of
our audience.

Frameworks 5 will be released before Workspaces gets ported to it. and there
is nothing set in stone that says Workspace will from that point forward only
have releases every 6 months. (though i expect we will at the very minimum
sync a release with Frameworks every N months)

i'd also love to see plasma-addons released much more regularly, or perhaps
not released at all in the traditional sense and only offered as add-ons
through an applet store ala hotnewstuff.

ok .. back to the case of Plasma Active itself. the reason for the decoupled
release cycle is due to the realities of getting the project going and the
needs of companies making devices. this is why e17 has never had, and from
what i understand never will, have a proper official "release". (we won't go
that extreme :)

but the decoupled release cycle is not indicative in this case of a decoupled
technical design, goals or aims. Plasma Active was born out of the same vision
and goals that gave birth to Plasma Desktop and Plasma Netbook. it was the
same people, the same goals, the same technical design. they (we) saw it as
the same project. they still do.

> and target different devices.

so does Netbook, but it's in kde-workspace.

but consider this: since the beginning of Active we've been talking about
eventually having a tablet powerful enough (CPU/memory/storage) that you can
have both Desktop and Active on the same device and when you dock the tablet
(or even just sit it upright and connect a keyboard+mouse) it would switch to
desktop. these devices are on the market today, so we aren't far from it.

the ability to switch shells was pionered with Plasma Netbook. which in your
diagram is part of KDE Workspaces. :)

so it can't be the device that is being targeted since those lines are not
definitive.

the reason for the different workspaces comes down to meeting different use
cases and interaction patterns. there's a high degree of corelation between
use cases, interaction patterns and the hardware one chooses. but what we've
seen in the last decade is that those choices are converging. a phone is no
longer just a phone, for instance :)

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: KDE architecture diagram

[Sebastian Kügler]

On Thursday, June 07, 2012 22:16:13 Aurélien Gâteau wrote:
> Le jeudi 7 juin 2012 21:11:09 Aaron J. Seigo a écrit :
> > there's an artificial spliting between "kde workspace" and "plasma active"
> > that does not exist. those of us working on these things keep saying that
> > but nobody seems to either be listening to or believing us :)
> 
> If I am not mistaken, kde workspace and plasma active are developed in
> different repositories, have different release schedules and target
> different devices. That was enough for me to split them.

Most of it is developed in the same repository (kde-runtime, kde-workspace, 
and basically the whole rest of the stack). Only the shell and a few apps are 
developed in a separate repository (which I think is more an artifact of us 
moving to quickly in the past year to clean up after ourselves than anything 
else). The different release schedules ... I don't know.

On the one hand, we untangling what we currently release as KDE SC, making 
separate releases for platform, workspaces and apps, on the other hand. On the 
other hand, we've thought about releasing the plasma-mobile repo together with 
the rest of KDE SC. We see that requirements for devices are a bit different, 
and that we want to cater for that with an "always releasable" system.

Still, ideally we'd roll stable releases of an always releasable core together 
with SC releases, but are basically able to do a device with the latest 
snapshots at any point in time.


To me, it's really much more like this:


Plasma Workspaces
   |
  KDE Platform


Plasma Workspace includes Desktop, Netbook, Active, Mediacenter, etc.. This 
may look oversimplified, but I don't think it is. Technical details such as 
what you can find in which repository, how packages are split are really only 
technical details for the sake of deployment, but it's certainly not a 
structure we can use to define ourselves and what we do.

Just like for apps that ship different kinds of UIs, the "Plasma Active 
Workspace" is just a different flavour of the "Plasma Workspace", just like 
the desktop. In most cases it does not make much sense to draw an artifical 
line. (The same holds true for Calligra Active vs Calligra (Desktop), Okular, 
Marble, etc... who all might use different UIs bases on the target device. 
From that, you can derive "Plasma principles" such as "a component should work 
with different formfactors and input devices" and "a component should work 
across multiple devices" quite logically, and I think that's the mindset we 
need to foster.
I think we're doing ourselves a disservice if we see these things as different 
"projects" or even teams, and we should not to that.

Food for thought: How many Linux kernel developers do you know that try to 
divide the Linux kernel in subprojects for servers, desktops, embedded 
systems? Here, just like in Plasma, there are a few codepathes that differ per 
device, but the majority of the code is shared. The differences come from how 
you configure it for a given target device. That is conceptually the same as 
with Plasma we're building a system that you can configure for a wide range of 
target devices.

> > i will try to come up with something that reflects my knowledge of the
> > system in time for the sprint. i can probably start with a diagram that
> > sebas and i did up a couple years ago 
> 
> That would be great.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel