L_V wrote:Hope that KDE4 is more made for users than for developers.

Hope dies last.

L_V wrote:If you say you can't, that means that this doc is made for developers, and not for users who expect to modify a taskbar as easily than with KDE3.

No, you expect that. You are taking your own desires and projecting them to the entire KDE user community. You are free to have your own opinion, but please don't pretend you speak for all users. I personally very much prefer the flexibility of svg files.

L_V wrote:You should also read it to estimate if it is fitting the question.
If you think so, please tell us how to make a translucent panel-background.svgz in less than one minute.

Simple - open Inkscape, and create 9 rectangles. For each rectangle, right-click it and select Object Properties and select the Id, and change it to "center", "topleft", "top", "topright" and so on. Also, resize all of the edges to the desired dimensions. Then, select "center" and select Object > Fill and Stroke and set the Opacity to 50% or whatever you like. Save it as "panel-background.svg".

TheBlackCat wrote:I personally very much prefer the flexibility of svg files.

You are taking your own desires and projecting them to the entire KDE user community.
(user = real user, not developers of course / marginal share of users).

Alec wrote:Simple - open Inkscape, and create 9 rectangles. For each rectangle, right-click it and select Object Properties and select the Id, and change it to "center", "topleft", "top", "topright" and so on. Also, resize all of the edges to the desired dimensions. Then, select "center" and select Object > Fill and Stroke and set the Opacity to 50% or whatever you like. Save it as "panel-background.svg".

Good talk and approximate theory.
Now can you say how much time you needed to make it ?
Can you show your result ?

+ what don't you use Karbon14 and prefer gnome applications ??
Why do you need a gnome application to modify a KDE taskbar ?

L_V wrote:

TheBlackCat wrote:I personally very much prefer the flexibility of svg files.

You are taking your own desires and projecting them to the entire KDE user community.
(user = real user, not developers of course / marginal share of users).

There's quite a difference between "I personally" and "users".

+ what don't you use Karbon14 and prefer gnome applications ??

As far as I know, Inkscape isn't a GNOME application. Besides, what's wrong with using it, even if it were a GNOME application? Is it taboo to edit PNG files in GIMP as well?

I don't see what you want to achieve with these remarks. To prove that the old way is better?

Personally, I also like the flexibility of the new system. No one of my friends/family members who use KDE (and whom I consider closer to the "average user" than I am) has wanted to edit the panel background. They choose a theme they like, and then they're happy with it. To them, it doesn't matter if it's bitmap or vector. (Often, people I know just stick to the default theme).

This is only from my limited experience, of course.

L_V wrote:

TheBlackCat wrote:I personally very much prefer the flexibility of svg files.

You are taking your own desires and projecting them to the entire KDE user community.
(user = real user, not developers of course / marginal share of users).

Wait, what? I said "I personally prefer". That means I am attributing that opinion to myself and nobody else. I am not claiming a single other user agrees with me.

Anyway, we understand that some hours are necessary to make this SVG panel transparent, and that theory is always easier than practice.

However, who can explain why Karbon14 cannot be used to make a svg for KDE panel ?
Karbon14 seems more natural in KDE.
Some say: use Karbon14, others use Inkscape.
Is it Karbon14 for theory, and Inkscape for practice ?

I haven't used Karbon myself, but any vector application (with the ability to name id) should be fine as far as I know. If some say Karbon14 and others Inkscape, it's probably just their preference.

If you want to make an existing panel background transparent, can't you just open it in a SVG editor and change the opacity?

L_V wrote:Anyway, we understand that some hours are necessary to make this SVG panel transparent, and that theory is always easier than practice.

Hahaha. Nice trolling!

You can open the SVG files and change the opacity settings for a given panel, but that's only one side of the issue. The other side is rendering. When using compositing, the compositing engine automatically considers the alpha values (alpha being the opacity level) for the items that it is rendering. However without compositing (from what I understand and have seen) X ignores the alpha values.

What I would like to know is why X doesn't consider the alpha values when rendering without compositing. I believe this is where all of the trouble comes in. The result is that application developers who want transparency effects have to resort to hacks and workarounds. For instance: taking a snapshot of what's underneath the transparent parts and merge the two manually, e.g. the Amarok OSD (From KDE3, I haven't used the KDE4 version that much yet). If you set it with any transparency then when it displays it takes a snapshot of whats underneath it, draws the OSD on top of that and then displays the merged OSD. If you move anything underneath the OSD, the transparent parts of the OSD are not updated. Another example of a hack to get pseudo-transparency involves using the root background instead of whats immediately underneath (common for some of the more primitive terminals like rxvt as it only requires updating if you move that window, though afaik this won't appear to work properly in KDE because plasma isn't rendered in the root window so it won't use the wallpaper shown in plasma as the background).

These are of course Hacks and the KDE Devs have made it clear that they are trying to avoid such things. My suggestion if you want transparency without compositing would be to try and push it in X, which may or may not be very successful. For now we have to live with the fact that without compositing transparency settings are basically ignored (unless the applications resort to hacks as described above).

(Suggest someone who has more in-depth knowledge of this issue to confirm or correct this explanation as it is based on my observations and experiences)

In order to do transparency you have to use compositing. It is not a limitation in x, it is something that even in principle cannot be done without compositing.

L_V wrote:

TheBlackCat wrote:I personally very much prefer the flexibility of svg files.

You are taking your own desires and projecting them to the entire KDE user community.
(user = real user, not developers of course / marginal share of users).

TheBlackCat wrote:I personally very much prefer the flexibility of svg files.

TheBlackCat wrote:I personally

Does this still look like he's speaking for all of use to any of you...?