@dpalacio: thanks for the hints + config file, the build is on it's way - I'm courious if I can get it work for AVR32, too

@TheBlackCat:

So any window can be embedded in the panel, and know that it needs to change its UI? Any window can know that it is in the newspaper containment and needs to change its UI for that?

No, the windowmanager does the magic, plus Xresources and companions. Windows are just windows.

Plasma is far more than just being able to embed windows in the desktop.

Oh, I would not say that. To be more priecise, the only emedable windows in KDE4 are plasmoids. That plasmoids can be embeded in panels is nice, but basicly 2 different programs the job as well. Or did I miss something?

Window managers use title bars. They also use window type identifiers so the window manager knows how to treat the windows. Doing that for plasma would require rewriting every plasmoid.

Why would you like to implement a windowmanager within a windowmanager? It's just changing the container, not the plasmoids. Thats what OO was about, was'nt it?

Which, at least for me, can't be moved at all.

You've just exposed a bug in KDE4 - it moves quite nicely by draging the eyes on any windowmanager except KDE4. Please file a bugreport.

Let me see if I get this straight: you said that I am the only person in the world who uses plasma this way, based on nothing more than how you use it?

No. I say, however you use plasmoids, it's most likely you use them in your personal way, like anybody else. As long as there's no data about usecases you cannot say the way you use stuff is the way others think stuff is to be used. You cannot even say, your usecase is typical.

Why should we turn plasmoids into windows when we already have windows? You still have provided no reason whatsoever to do this.

Because they are windows. And because there is no way to configure their behaviour despite configuring window behavior. And by ignoring the only settings the user can make, they break the UI model.
This would not be the case if "systemsettings" had a tab "plasmoids" where you could change plasmoid behaviour like window behaviour, but then the users would come and say "hey, what's that, why do I have to make my settings twice?"

There is no reason why a plasmoid should not be moved around a lot. It definitly would add fun to the desktop.

It isn't a question of why shouldn't they, it is a question of why should they. You are proposing a massive change to both plasma and individual plasmoids that will break backwards compatibility with third-party plasmoids, but have provided no use-cases that could possibly justify such radical changes.

Why do you move windows? YOu'd be better off by not moving them, it costs too much CPU cycles.
There is no change. Plasmoids can be moved around, that's a fact. It's just clumsy how it works.

"It's fun" is not a good excuse for making destructive behavior easy.

You really mean that the plasmoid code is so broken that moving/resizing of plasmoids crashes KDE? OMG.

Why don't you use activities, or folderview widgets in windows, or folderview widgets in a panel? Why do you need to move them to make them configurable? You can configure them easily even when the desktop is locked.

Why do people buy pointy hats and false beards? Why can't they go to a propper wizards school? Why don't all people use this perfectly advanced pen for their writing?

Activities is nice, but just a crutch. It's not flexible. I didn't like the idea 10 years ago, I don't like it now. I don't like the KDE4 panels, they are clumsy to use. It's nice to play with these things, but not to work with.

The burden of proof is on you to justify such massive changes to a core part of KDE.

There's no big change. OO, you remember? Just change the container and it's fine.

By the way, you do not have any argument against moving/resizing plasmoids - despite broken code.

aapgorilla wrote:There are quite a few media players which have skins for ovaloid or irregular windows w/o native window decoration

1. I am not aware of any that are freely resizable
2. I am pretty confident few, if any, can be freely rotated as well
3. These depend on dragging non-active parts of the window, which I already explained breaks key plasmoids.

aapgorilla wrote:Really the answer is for the same reason we move normal program windows. The plasmoid calculator is useless for me since it is a real burden to move it on the screen next to other windows so I can do some quick calculations and use them in the other window.

If you want plasma to behave like regular windows, why don't you just use regular windows? There is no point whatsoever having plasma if the plasmoids are just going to behave like ordinary windows. The whole point of having something separate and distinct from windows is that they are separate and distinct from windows.

I still don't understand why you need to move the calculator widget just to do some calculations. To do so you need to hide your open windows, find the calculator widget, then move it (remembering where your open windows were), then unhide the windows. Why don't you just move the windows? Why don't you open the calculator widget in a window? Why don't you put it in a panel, why don't you use the dashboard? There are a lot of solutions that seem to me to be just as good, if not better, that do not require fundamental changes to how plasma works that breaks plasmoids.

At first I thought multiple virtual desktops were I neat idea but soon I abandoned them as I found them to be disorienting and I lost track of things. I find "activities" even more confusing. I just want one desktop where I can see my work.

I proposed three different solution and asked a question. You addressed one of my proposed solutions and didn't answer my question at all.

I keep asking you, and you keep ignoring me: please provide a use-case that justifies major changes to how plasma works, breaking existing widgets, and breaking backwards compatibility with third-party widgets.

samhain wrote:No, the windowmanager does the magic, plus Xresources and companions. Windows are just windows.

Then it isn't the same as plasma

samhain wrote:

Plasma is far more than just being able to embed windows in the desktop.

Oh, I would not say that. To be more priecise, the only emedable windows in KDE4 are plasmoids. That plasmoids can be embeded in panels is nice, but basicly 2 different programs the job as well. Or did I miss something?

Yes, the whole point of plasma is that you don't need two different programs. Or 3, if we include the newspaper containment. Or 4, if we include the container widget. Or 5 if we include amarok, 6 if we include the upcoming kmymoney, 7 if we include the upcoming plasma media center, 8 if we include the upcoming plasma mid, and so on. The whole point is that the same code can be used for all of these. All in all there are currently at least a 12 different plasma containments either available or in development, all using the same code-base.

Plasmoids are also designed to fill different use-cases than windows. Rather than full-fledged applications, they are very specialized mini-applications.

samhain wrote:Why would you like to implement a windowmanager within a windowmanager? It's just changing the container, not the plasmoids. Thats what OO was about, was'nt it?

I wouldn't, that is my point. You are the one proposing we have a second window manager that works identically to the one we already have.

samhain wrote:No. I say, however you use plasmoids, it's most likely you use them in your personal way, like anybody else. As long as there's no data about usecases you cannot say the way you use stuff is the way others think stuff is to be used. You cannot even say, your usecase is typical.

Where did I say this? What I said was that what I am describing is the intended usage of plasma. which is true because this is how the developers have described it.

samhain wrote:Because they are windows. And because there is no way to configure their behaviour despite configuring window behavior. And by ignoring the only settings the user can make, they break the UI model.

No, they aren't. You still don't get it: plasmoids do not behave like windows because they are not intended to be used like windows. They are not broken, they are working exactly like they are supposed to work. We already have windows for people who want things that behave like windows, we don't need to do the same thing all over again. Plasmoids are different from windows because they are intended to fill different use-cases from windows.

samhain wrote:Why do you move windows? YOu'd be better off by not moving them, it costs too much CPU cycles.
There is no change. Plasmoids can be moved around, that's a fact. It's just clumsy how it works.

Once again, I already have things that are easy to move around: windows. There is no reason to have windows all over again when I already have windows that work perfectly fine. That is why plasmoids were developed, so we have something different than windows that fills different use cases. There would be no point having plasmoids if they were just going to behave the same as windows.

Plasmoids are intentionally clumsy to move around so that it is hard to do by accident. If we want things that are easy to move around, we can just use windows. Try looking at the newspaper containment, it is intentionally even harder to move widgets around there, probably because moving them can easily cause much large disruption to your layout than moving them in the desktop containment. The same goes for the panel, probably because it is easier to move widgets accidentally there.

samhain wrote:

"It's fun" is not a good excuse for making destructive behavior easy.

You really mean that the plasmoid code is so broken that moving/resizing of plasmoids crashes KDE? OMG.

No, I am saying it can completely screw up your desktop layout. I explained that already.

samhain wrote:

Why don't you use activities, or folderview widgets in windows, or folderview widgets in a panel? Why do you need to move them to make them configurable? You can configure them easily even when the desktop is locked.

Activities is nice, but just a crutch. It's not flexible. I didn't like the idea 10 years ago, I don't like it now. I don't like the KDE4 panels, they are clumsy to use. It's nice to play with these things, but not to work with.

A crutch? Not flexible? Not nice to work with? How do you figure? And you don't use panels? Then I can confidently say your usage of plasma is highly unusual.

samhain wrote:There's no big change. OO, you remember? Just change the container and it's fine.

No, it won't be fine. As I keep saying, plasmoids will be completely broken by doing this. Now if a third party wants to do the programming for the containment, and users of that third-party containment are willing to put up with folderview being unusable, that is their business. But the actual KDE developers have a responsibility to keep a working system, and leaving core plasmoids broken is not an option.

samhain wrote:By the way, you do not have any argument against moving/resizing plasmoids - despite broken code.

First, we can already move and resize plasmoids pretty easily. Second, I already explained that it will make it easy to wreck your desktop layout. Third, it involves time and effort on the part of developers, two things that are in extremely short supply. No one is going to go to the trouble of changing plasma and radically modifying multiple key plasmoids for no reason whatsoever. You still need to justify your proposal, something you have not even begun to try. Alternatively, you can program it yourself. But this is not the sort of thing that is done on a whim, a lot of thought went into how plasma would work and they are not going to change it just because you think it would be more fun.

Now this is chasing one's own tail.

You say, there are 12 containers for the plasmoids code. Nice. So definitly hindering users moving them around is a developers decision. Like it or not, that's called "broken by design".

Remember "The Art of UNIX Programming"?

the 7 year old book?

Hmm

Rule of Modularity: Write simple parts connected by clean interfaces.

Done

Rule of Composition: Design programs to be connected with other programs.

Done

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

Done
Did i miss something?

Quoting all rules from the book:

1) Rule of Modularity: Write simple parts connected by clean interfaces.
2) Rule of Clarity: Clarity is better than cleverness.
3) Rule of Composition: Design programs to be connected with other programs.
4) Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5) Rule of Simplicity: Design for simplicity; add complexity only where you must.
6) Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7) Rule of Transparency: Design for visibility to make inspection and debugging easier.
8 ) Rule of Robustness: Robustness is the child of transparency and simplicity.
9) Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
10) Rule of Least Surprise: In interface design, always do the least surprising thing.
11) Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12) Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
13) Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
15) Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15) Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16) Rule of Diversity: Distrust all claims for one true way.
17) Rule of Extensibility: Design for the future, because it will be here sooner than you think.

2, 5, 6, 7, 8, 10, 11, 12, 16 are not done.
Especially 5, 10 and 16 bite the user.

If you could also state WHY those points are not done, it would be nice. Especially rule 2 would mean you have read the source code...

Rules do not only aply to code
ad 2) Rule of Clarity: Nepomuck/Strigi/Aconadi, clever, but not clear. Focus model.
ad 5) Rule of Simplicity: move plasmoids, not only on desktop, but on panels, too. Compare this to how easy it is to remove them. How hard to get them back in place. Or dolphin/konqueror, on KDE3 there was just konquerer for all, now you need dolphin/konqeror/firefox for the same thing.
ad 6) Rule of Parsimony: Nepomuck/Strigi/Aconadi
ad 7) Rule of Transparency: Kmail/Akonadi problems. Focus problem.
ad 8 ) Rule of Robustness: I still have frequent plama crashes. Still functionality and data disappears from version to version.
ad 10) Rule of Least Surprise: disappearing functionality, things that don't behave right (systemsettings vs. the real thing)
ad 11) Rule of Silence: popups anywhere, that I cannot silence.
ad 12) Rule of Repair: KDEPIM
ad 16) Rule of Diversity: "you must the pasmoids this way ..."

Could add more examples, but this will do I hope.

samhain wrote:You say, there are 12 containers for the plasmoids code. Nice. So definitly hindering users moving them around is a developers decision. Like it or not, that's called "broken by design".

You still have not explained why it is broken.

samhain wrote:ad 2) Rule of Clarity: Nepomuck/Strigi/Aconadi, clever, but not clear.

See rule 15 and 17. Nepomuk/strigi/akonadi shouldn't need to be clear, the user shouldn't even have to know they exist. That they do is because they aren't finished yet.

samhain wrote:Focus model.

The focus model works perfectly fine and is very clear as long as you don't try to shoe-horn plasma into it. You seem to be stuck in this completely counterfactual idea that plasmoids, for some reason you have not explained, should behave the same as windows when they are not windows.

samhain wrote:ad 5) Rule of Simplicity: move plasmoids, not only on desktop, but on panels, too. Compare this to how easy it is to remove them. How hard to get them back in place.

It is easer to move them than to remove them, and moving them around once is not hard. This is because of rule 10, you don't want people getting a totally messed up desktop accidentally.

samhain wrote:Or dolphin/konqueror, on KDE3 there was just konquerer for all, now you need dolphin/konqeror/firefox for the same thing.

The very reason dolphin and rekonq exist is because of this rule. Konqueror is really, really complicated, so developers thought they should make simpler applications.

samhain wrote:ad 6) Rule of Parsimony: Nepomuck/Strigi/Aconadi

The whole point of nepmuk/strigi/akonadi is to make the programs that carry out their respective tasks smaller and easier to maintain. They exist partially because of this rule.

samhain wrote:ad 7) Rule of Transparency: Kmail/Akonadi problems. Focus problem.

This is clearly a programming-specific issue.

samhain wrote:ad 8 ) Rule of Robustness: I still have frequent plama crashes. Still functionality and data disappears from version to version.

"Robustness" does not mean "not crashing", and clearly nobody wants crashes and developers are trying to fix them. KDE 3 took a long time to get as stable as KDE 3.5.

samhain wrote:ad 10) Rule of Least Surprise: disappearing functionality,

A lot of the changes in KDE 4, and much of the design of plasma (including making it harder to screw up your desktop) was done specifically for this. Disappearing functionality normally shouldn't happen, so far I am aware of only 1 major case of that happening during the 4.x life-cycle and I have already explained that one too many times so I am not going to repeat it again.

samhain wrote:things that don't behave right (systemsettings vs. the real thing)

You need to be more specific.

samhain wrote:ad 11) Rule of Silence: popups anywhere, that I cannot silence.

First of all, you only get popups when you interact with something, that is not what this is referring to. Second, the popups can all be disablled in 4.5.

samhain wrote:ad 12) Rule of Repair: KDEPIM

KDE PIM does exactly this when akonadi has a problem, but everyone complains about it.

samhain wrote:ad 16) Rule of Diversity: "you must the pasmoids this way ..."

You are the one arguing for "one true way", and that anything that doesn't behave exactly as you want it to is "broken by design". As I already pointed out, there isn't "one true way" to interact with plasmoids, there are a bunch of them. But your way leads to serious problems that you have not bothered to address.

You also flat-out reject rule 1 and 15 when you say that several programs are just as good as one general purpose program. Rule 1 and 15 are two of the key points of plasma. Plasma was also designed for rule 4, that is the whole point of data engines. Plasma was also designed for rule 17, since the KDE 3 desktop and panels were extremely rigid and inflexible, unable to adapt to keep up with the broadening range of computer types (netbooks, tablets, mids, etc). Plasma was designed to make it easy to make entirely new interface types for new types of devices with minimal additional code. And the rapid development and small size of the netbook, mid, tablet, and media center interfaces shows that it succeeds at this task. This is always why plasma follows rule 16, despite your assertions to the contrary. It makes it easy to do things exactly how someone wants. The very behavior that dooms your suggestion, plasmoids being able to capture mouse click and drag behavior, is exactly because of rule 16, so that widget developers have more flexibility in the design of their widgets than your method would allow.

You reject rule 1, 3, 4, 15, 16, 17 when you throw out nepomuk and akonadi, which were designed to allow much more modular programs, interconnect programs, separate the data-gathering from its representation, to allow similar tasks to re-use as much code as possible, make it easy to make new interfaces for the same underlying data, and to make it easy to add on support for new capabilities as they become available.

You reject rule 10 when you say we should make it easy to accidentally screw up our desktop layout.

You reject rule 16 when you say that everything must behave exactly the same as windows, and that anything that does not behave exactly the same as windows is "broken by design".

In fact, if you look at pretty much any change from KDE 3 to KDE 4 you will find that improving compliance with one or more of these rules was the primary purpose of that change.

LOL ... as I see I've made two rules 15, to which do you refer ?

It is easer to move them than to remove them, and moving them around once is not hard. This is because of rule 10, you don't want people getting a totally messed up desktop accidentally.

Let's see ... I have a plasmoid in the panel.

To remove it, I need this procedure:
1) RMB
2) move mouse some pixel
3) LMB

To move it, I need this:
1) move right to the infamouse nut
2) RMB
3) move mouse to the middel of the screen
4) RMB on "move"-symbol
5) move mouse to the plasmoid
6) drag to move the plasmoid
7) move mouse to the infamouse nut
8 ) LMB

Definitly it is harder to remove a plasmoid from a panel

I strongly suggest you read the book, before argue about the implications of the rules.
You'll find it here: http://www.faqs.org/docs/artu/
You may try this chapter first: http://www.faqs.org/docs/artu/ch01s07.html

Yes, samhain, you are right. Plasmoids in a panel is easier to remove than to move. As a user, I would usually do neither too often.

I am using Kubuntu 10.04 with KDE 4.4.5 and have the panel at the bottom of the screen set up like I want it to be. And that is how I leave it. I don't have any big need to move anything around. So I actually do not see it as a problem.

But you seem a little confused about what plasmoids really are - they are not confined to panels. On my desktop, I actually move things around a bit based on my needs. And there I just hover the mouse, grab the handle that pops out and move it. Or close it to remove it. No difference.

I am one of those that love KDE4 and shrugged when I saw KDE 3.x - the concept of using one program for a lot of different tasks is very far from what I prefer. I like specialised tools. I want a web browser that do one thing well - browse the web. I want a file browser that do that well. And I actually like Dolphin. Yes, it is not perfect, but it is getting closer by the day. And right now, I can work with it without any problems. My system is as stable as I expect it to be - this is in ALL os'es more dependent on the person in charge of the computer than the OS itself as long as the OS is somewhat mature.

For my web browsing needs today, I mostly use Firefox and Opera. I make and maintain some websites, and these two browsers have most of the tools I need. I also use other browsers, but mostly to test websites in.

As I have been working on Mac, Windows, Linux and a few others over the years, I first and foremost choose the tools I prefer, then the OS/distro if possible. In KDE 4.x I have found a platform where I can do most of the things I need. And maybe some day it will be able to do all of it

No wild horses could drag me over to KDE 3.5 from what I am running today.

Have you considered donating some time and skills to make a difference in the areas you feel needs help? There is always need for help, and if you are half as passionate about helping as you are about debating, you would be able to do a lot!

ad 8 ) Rule of Robustness: I still have frequent plama crashes. Still functionality and data disappears from version to version.

Ah... I run Trunk ( which is where the development happens ) and I have very infrequent crashes. The only crash I experienced in the past month was due to a applet from kdeplasma-addons. Therefore it is likely the fault of a poorly written third party applet causing your crashes.

Oceanwatcher wrote:I am using Kubuntu 10.04 with KDE 4.4.5 and have the panel at the bottom of the screen set up like I want it to be. And that is how I leave it. I don't have any big need to move anything around. So I actually do not see it as a problem.

My panel is on the right side (singleheaded) or on the right side of the left monitor(dualhead). Give this a try, you'll experence a whole new quality of what moving/resizing palsmoids means. I especially like the moment when all handles are behind the panel.

Oceanwatcher wrote:And there I just hover the mouse, grab the handle that pops out and move it. Or close it to remove it. No difference.

Yes, if there's not a panel on top of it. Despite that's a very slow way to get thing done. Shortcuts are faster. I've always shortcuts for horizontal/vertial maximizing of windows, moving etc. As these don't work on plasmoids, working with them is painful.

Oceanwatcher wrote:And I actually like Dolphin. Yes, it is not perfect, but it is getting closer by the day. And right now, I can work with it without any problems.

Dolphin has a far way to go, till it gets where konqueror of KDE3 was.

Oceanwatcher wrote:No wild horses could drag me over to KDE 3.5 from what I am running today.

LOL ... Think nobody wants you to drag there ... but you could take a closer look at what KDE3 had and how it worked, to understand what oldtimers complain about. "Known devil is better then unknown angel"

Oceanwatcher wrote:Have you considered donating some time and skills to make a difference in the areas you feel needs help? There is always need for help, and if you are half as passionate about helping as you are about debating, you would be able to do a lot!

Please define "help".

TheBlackCat wrote:

samhain wrote:ad 2) Rule of Clarity: Nepomuck/Strigi/Aconadi, clever, but not clear.

See rule 15 and 17. Nepomuk/strigi/akonadi shouldn't need to be clear, the user shouldn't even have to know they exist. That they do is because they aren't finished yet.

I am not sure if I misunderstand what you've written or what samhain has written, but I think samhain is giving examples where KDE technology has followed the respective rules.
Like Nepomuk/Strigi/Akonadi, they all have very clear tasks and don't try to make clever assumptions on behalf of each other.

TheBlackCat wrote:

samhain wrote:ad 6) Rule of Parsimony: Nepomuck/Strigi/Aconadi

The whole point of nepmuk/strigi/akonadi is to make the programs that carry out their respective tasks smaller and easier to maintain. They exist partially because of this rule.

Same here. samhain gives nice examples how KDE technologies follow rule 6, by separation of concernes instead of implementing all-in-one thingies.

This has always been a very core aspect of KDE's architecture, e.g. KIO

TheBlackCat wrote:

samhain wrote:ad 7) Rule of Transparency: Kmail/Akonadi problems. Focus problem.

This is clearly a programming-specific issue.

Again good example by samhain how this is nicely done in KDE.
One can monitor Akonadi components in a detail level unprecedented in usual desktop software, e.g. communication (data and control), introspecting into them, etc.

TheBlackCat wrote:

samhain wrote:ad 12) Rule of Repair: KDEPIM

KDE PIM does exactly this when akonadi has a problem, but everyone complains about it.

You both agree on this point and so do I.
Very good example of following this rule. Handle broken stuff like invitations from Outlook or systems that break email references. Make very detailed error reports available when something fundamental as startup fails.

I don't know enought about Plasma do comment on those examples, but since all PIM related example have shown impressively how these rules are part of the design and implementation process, I can only assume the same applies there as well.

Cheers,
_

samhain wrote:

Oceanwatcher wrote:

Oceanwatcher wrote:No wild horses could drag me over to KDE 3.5 from what I am running today.

LOL ... Think nobody wants you to drag there ... but you could take a closer look at what KDE3 had and how it worked, to understand what oldtimers complain about. "Known devil is better then unknown angel"

Well, I am an oldtimer when it comes to computers. I was on the internet before the web was a usable option and have been using Linux for almost as long. But trying KDE several times did not leave me with something I wanted to use in daily work until KDE4 came along. So yes, I know what KDE3 was and feel no need to waste any time going there. This is a personal preference as we all have to make priorities on what we want to spend time on. For me, KDE4 works and I get things done. Sure, there are a lot of things I would have liked to change and I submit bugreports and feature requests when I can.

samhain wrote:

Oceanwatcher wrote:Have you considered donating some time and skills to make a difference in the areas you feel needs help? There is always need for help, and if you are half as passionate about helping as you are about debating, you would be able to do a lot!

Please define "help".

Can you code? There is a shortage of coders, so if you can, please get involved.
Do you speak more than one language? If so, there is a need for translators.
Are you able to write a tutorial? Do you have some neat tricks that you can tell people about? This is also needed!
There are a lot of other areas where help is needed. Actually, a VERY important one is to dig deep into the system, find the root of bugs and report them. All of these things mean that you spend time helping both yourself and others in the community.

Time to step up and give something back!