Work stuff. We have been getting a new revision of the Book of Vaadin out about every six months and the latest came from print today. This time we didn't increment the edition number, so it is the 1st revision of the 4th Edition. Essentially, one major reason was that we ran out of colors in the Vaadin color palette so the new revision looks just as yellow-orange as the original 4th Edition.
Regardless of the similar appearance, the revision packs almost 100 pages more content. The biggest change is the reorganization into two parts: the core framework and the addons. Some new add-on documentation is included in the core part: Vaadin Control Panel for Liferay, Vaadin IPC, and Vaadin WSRP. The SQLContainer add-on is now part of the core framework.
Of the add-on documentation, the JPAContainer chapter was entirely rewritten couple of months ago and the Calendar chapter was revised more recently.
Unfortunately, there are some outdated parts that went to print. Most notably, there is a really outdated material in the Vaadin embedding section, related to version 5.2. I hope there isn't much Toolkit 4 stuff left, just cleaned some references out at the last minute.
This all applies only to the print edition, which you can pick up for free at some conferences. The web edition is always the latest and it gets all additions on the same day I edit it.
Vaadin 7 is in the works. We hope to get a preview edition of the Vaadin 7 book out in the summer, in July or so. Perhaps it could be red, if we begin the color cycle in the same order we did with Vaadin 6. The color is always a big decision.
Tuesday, March 20, 2012
Saturday, January 21, 2012
JPA and Vaadin JPAContainer
I've been finalizing the completely rewritten chapter about Vaadin JPAContainer this week. I still need to check that everything really important is included.
I don't have almost any previous experience with JPA, which is kind of good thing when you write documentation about something. That way, you personally know all the questions a beginner would have.
JPA and ORM in general seem pretty important technologies. Whatever your application is, you most probably need some data storage. Using ordinary files is possible, but not near as handy as proper databases. However, stuffing complex class structures through the square holes of database tables was a hell before the ORM technologies emerged. XML databases and NoSQL were much nicer for structured storage.
Some years ago I did some experiments with related technologies, such as JAXB and Hibernate, but using them was a bit too much effort at that time. Using Hibernate with Vaadin really required a Container implementation, but there wasn't one at that time. Well, JPA is quite close to Hibernate, and Hibernate is currently one of the JPA implementations.
Vaadin JPAContainer makes things really easy.
JPAContainer is a commercial product. That shouldn't be a problem if you're coding for a company that can pay the license. For free software, you can use the AGPL license. I've always felt that this sort of dual-licensing scheme is most difficult for "potential startups" where you experiment with a business idea, but do not yet have a company to back it up financially. You do not normally have the money to invest in licenses at that point, and a company might not want to invest much in such experiments either.
There are of course alternatives for JPAContainer. Using pure JPA is quite OK approach as well, combined with BeanItemContainer in Vaadin. There's also SQLContainer. It is also something I don't know about, as I didn't write the chapter myself. I would need to review and reorganize it in next weeks though, and possibly rewrite at some point.
Well, I did make a couple of mistakes while writing the JPAContainer chapter. The first one was trying to just update a really complex design documentation written by someone else, in a topic I knew nothing about. Writing is always a learning experience and it's not sensible to try to write about something very complex that you don't have a clue about. Sometimes, it's best to start from scratch. Unfortunately, I didn't do that when I started, but just over a week before the release.
Another issue is learning by doing. I usually start writing documentation by experimenting how it works, making some example code. This time, as I was in a hurry, I tried to skip that phase. I only started it as the last effort when I was totally stuck, some 4 weeks of struggle behind and 2 work days before the release date. Just in those couple of days, all pieces fell into place and I finally understood how everything works.
I don't have almost any previous experience with JPA, which is kind of good thing when you write documentation about something. That way, you personally know all the questions a beginner would have.
JPA and ORM in general seem pretty important technologies. Whatever your application is, you most probably need some data storage. Using ordinary files is possible, but not near as handy as proper databases. However, stuffing complex class structures through the square holes of database tables was a hell before the ORM technologies emerged. XML databases and NoSQL were much nicer for structured storage.
Some years ago I did some experiments with related technologies, such as JAXB and Hibernate, but using them was a bit too much effort at that time. Using Hibernate with Vaadin really required a Container implementation, but there wasn't one at that time. Well, JPA is quite close to Hibernate, and Hibernate is currently one of the JPA implementations.
Vaadin JPAContainer makes things really easy.
// Create a persistent person containerSo, just one command to get a container bound to data in a database table. JPAContainer is, however, just for binding user interface components directly to data. You can use it to add or edit the data, but using pure JPA is much nicer, easier, and more flexible for that.
JPAContainer<Person> persons =
JPAContainerFactory.make(Person.class, "book-examples");
// You can add entities to the container as well
persons.addEntity(new Person("Marie-Louise Meilleur", 117));
// Bind it to a component
Table personTable = new Table("The Persistent People", persons);
personTable.setVisibleColumns(new String[]{"id","name","age"});
layout.addComponent(personTable);
EntityManager em = JPAContainerFactory.Well ok, here we got the entity manager from the JPAContainerFactory, which makes that a bit easier than normally.
createEntityManagerForPersistenceUnit("book-examples");
em.getTransaction().begin();
em.createQuery("DELETE FROM Person p").executeUpdate();
em.persist(new Person("Jeanne Calment", 122));
em.persist(new Person("Sarah Knauss", 119));
em.persist(new Person("Lucy Hannah", 117));
em.getTransaction().commit();
JPAContainer is a commercial product. That shouldn't be a problem if you're coding for a company that can pay the license. For free software, you can use the AGPL license. I've always felt that this sort of dual-licensing scheme is most difficult for "potential startups" where you experiment with a business idea, but do not yet have a company to back it up financially. You do not normally have the money to invest in licenses at that point, and a company might not want to invest much in such experiments either.
There are of course alternatives for JPAContainer. Using pure JPA is quite OK approach as well, combined with BeanItemContainer in Vaadin. There's also SQLContainer. It is also something I don't know about, as I didn't write the chapter myself. I would need to review and reorganize it in next weeks though, and possibly rewrite at some point.
Well, I did make a couple of mistakes while writing the JPAContainer chapter. The first one was trying to just update a really complex design documentation written by someone else, in a topic I knew nothing about. Writing is always a learning experience and it's not sensible to try to write about something very complex that you don't have a clue about. Sometimes, it's best to start from scratch. Unfortunately, I didn't do that when I started, but just over a week before the release.
Another issue is learning by doing. I usually start writing documentation by experimenting how it works, making some example code. This time, as I was in a hurry, I tried to skip that phase. I only started it as the last effort when I was totally stuck, some 4 weeks of struggle behind and 2 work days before the release date. Just in those couple of days, all pieces fell into place and I finally understood how everything works.
Wednesday, January 18, 2012
Wikipedia and Antipiracy Laws
So, if you have noticed, we've had a Wikipedia blackout. I normally use Wikipedia to look up dozens of articles daily, so I'd be pissed if their protest wasn't really valid.
As innocent they sound, the "Intellectual Property" laws are a big threat, really. They are somehow understandable, which is the reason why they exist, but at the same time, they may be a big threat to modern civilization.
You might think that they are not a problem to you, as they only prevent criminals from making crimes. You might even think that you want your intellectual properties be protected.
Their aim is to prevent illegal copying. Artists and others work so that they would get paid, and illegal copying is kind-of stealing from them. So, forbidding illegal copying is rather understandable.
So what's the fuzz about?
Let's consider the problem with DVDs. They use the "CSS" encryption mechanism to prevent unauthorized copying. Fine, excellent, evil pirates suffer, right?
Unfortunately, watching CSS-encrypted movies requires special software that holds a special decryption key. The software is usually free-of-charge, but it's only for Windows, and perhaps for Mac as well. For Linux, which I use, there is no such authorized software for watching DVDs.
Fortunately, some Norwegian guy cracked the CSS key and wrote a decryption algorithm some 10 years ago and now there's "DeCSS", an algorithm to play (and copy) any DVDs.
So, over the years I've bought some 200 DVD movies and I've always watched them with Linux and nothing else. I've never copied a DVD that I've bought, only watched them.
However, using the DeCSS algorithm for any purpose is illegal in Finland. It's been tried in court.
The fact is that, once cracked, CSS became totally obsolete forever. The laws will never have any effect on unauthorized copying. But they will continue to prevent morally right use of your property.
So, pirates who operate illegally of course use the DeCSS decryption to make one copy which they then copy to millions. But people like myself, who buy DVD movies legally, are criminals. Trying to stop a few criminals, they incriminate perhaps millions of Linux-users around the world.
So why should you care? Linux users are somewhat rare, and you're probably not one of them (except if you use any of the 60% of the web or 55% of smartphones or a TV).
Oh, but it also affects Windows users. There's free DVD watching software for Windows as well, such as VLC, which is actually quite popular as it's very good. But it's illegal, as it has to use DeCSS. The laws prevent writing and distributing any free software that you could use to watch DVDs.
Obviously, preventing the use of free software to watch legal DVDs was not the purpose of the laws. It's just a consequence.
It's a good example of a case where somewhat understandable reasons lead to absurd results. Even so, the vast majority of the Finnish parliament supported the law. And there is a lot more IP legistlation on the way.
Oh, did I mention that Finnish consumers can legally copy movies and music for their own use and to friends. We even pay a tax for that when we buy DVD-Rs. But copying by circumventing CSS is illegal.
Given the absurd criminalization and heavy anti-"piracy" lobbying to take away your rights, you should have no sympathy for the movie industry. O'hoy pirates! Go and board them!
So, to SOPA or PIPA...
I'm not personally familiar with the new legistlation initiatives in the USA. As far as I've understood, it's something similar as the recent Finnish laws that allow blocking child porn and peer-to-peer download sites. The laws already have a sad history of abuse. For example, the laws do not allow blocking websites inside Finland, but they've nevertheless done so as there's no possibility to legally challenge the decisions.
The pattern is that "reasonable requirements" can have devastating effects. The current laws are largely based on the assumption that you are responsible for your own publications. The suggested laws place the responsibility on the owners of web servers and internet providers. So, if me or you were to publish the DeCSS code here in the blog, the Blogspot would be considered the "publisher" that is responsible for our writings. To protect itself, Blogspot would need to have editorial review for everything any one of the millions of bloggers write.
This would quickly kill almost all blogs, discussion forums, and websites in the Internet. Also Youtube and such. It would kill the basic freedoms that we take for granted, and most of the Internet.
Part of the Finnish goverment already has plans to expand the blocking further. Some want to block information about drugs and weapons. Then racism of course, blasphemy, information about bombs, porn, denying the Holocaust, undemocratic thought, ... anything to protect the children, leaders, gods, and corporate owners.
Even though basic IP laws may be necessary, the recent development upholds corporate ownership rights over consumer ownership rights. They are used to buttress dentrimental monopolies and force you to pay vastly overcharged prices, even for basic necessities. They distinguish diversity and freedom, which are the life forces of the modern technological and scientific ecosystem.
So when you see the blackout screen at Wikipedia, just imagine the day when it could be blacked out by your government.
As innocent they sound, the "Intellectual Property" laws are a big threat, really. They are somehow understandable, which is the reason why they exist, but at the same time, they may be a big threat to modern civilization.
You might think that they are not a problem to you, as they only prevent criminals from making crimes. You might even think that you want your intellectual properties be protected.
Their aim is to prevent illegal copying. Artists and others work so that they would get paid, and illegal copying is kind-of stealing from them. So, forbidding illegal copying is rather understandable.
So what's the fuzz about?
Let's consider the problem with DVDs. They use the "CSS" encryption mechanism to prevent unauthorized copying. Fine, excellent, evil pirates suffer, right?
Unfortunately, watching CSS-encrypted movies requires special software that holds a special decryption key. The software is usually free-of-charge, but it's only for Windows, and perhaps for Mac as well. For Linux, which I use, there is no such authorized software for watching DVDs.
Fortunately, some Norwegian guy cracked the CSS key and wrote a decryption algorithm some 10 years ago and now there's "DeCSS", an algorithm to play (and copy) any DVDs.
So, over the years I've bought some 200 DVD movies and I've always watched them with Linux and nothing else. I've never copied a DVD that I've bought, only watched them.
However, using the DeCSS algorithm for any purpose is illegal in Finland. It's been tried in court.
The fact is that, once cracked, CSS became totally obsolete forever. The laws will never have any effect on unauthorized copying. But they will continue to prevent morally right use of your property.
So, pirates who operate illegally of course use the DeCSS decryption to make one copy which they then copy to millions. But people like myself, who buy DVD movies legally, are criminals. Trying to stop a few criminals, they incriminate perhaps millions of Linux-users around the world.
So why should you care? Linux users are somewhat rare, and you're probably not one of them (except if you use any of the 60% of the web or 55% of smartphones or a TV).
Oh, but it also affects Windows users. There's free DVD watching software for Windows as well, such as VLC, which is actually quite popular as it's very good. But it's illegal, as it has to use DeCSS. The laws prevent writing and distributing any free software that you could use to watch DVDs.
Obviously, preventing the use of free software to watch legal DVDs was not the purpose of the laws. It's just a consequence.
It's a good example of a case where somewhat understandable reasons lead to absurd results. Even so, the vast majority of the Finnish parliament supported the law. And there is a lot more IP legistlation on the way.
Oh, did I mention that Finnish consumers can legally copy movies and music for their own use and to friends. We even pay a tax for that when we buy DVD-Rs. But copying by circumventing CSS is illegal.
Given the absurd criminalization and heavy anti-"piracy" lobbying to take away your rights, you should have no sympathy for the movie industry. O'hoy pirates! Go and board them!
So, to SOPA or PIPA...
I'm not personally familiar with the new legistlation initiatives in the USA. As far as I've understood, it's something similar as the recent Finnish laws that allow blocking child porn and peer-to-peer download sites. The laws already have a sad history of abuse. For example, the laws do not allow blocking websites inside Finland, but they've nevertheless done so as there's no possibility to legally challenge the decisions.
The pattern is that "reasonable requirements" can have devastating effects. The current laws are largely based on the assumption that you are responsible for your own publications. The suggested laws place the responsibility on the owners of web servers and internet providers. So, if me or you were to publish the DeCSS code here in the blog, the Blogspot would be considered the "publisher" that is responsible for our writings. To protect itself, Blogspot would need to have editorial review for everything any one of the millions of bloggers write.
This would quickly kill almost all blogs, discussion forums, and websites in the Internet. Also Youtube and such. It would kill the basic freedoms that we take for granted, and most of the Internet.
Part of the Finnish goverment already has plans to expand the blocking further. Some want to block information about drugs and weapons. Then racism of course, blasphemy, information about bombs, porn, denying the Holocaust, undemocratic thought, ... anything to protect the children, leaders, gods, and corporate owners.
Even though basic IP laws may be necessary, the recent development upholds corporate ownership rights over consumer ownership rights. They are used to buttress dentrimental monopolies and force you to pay vastly overcharged prices, even for basic necessities. They distinguish diversity and freedom, which are the life forces of the modern technological and scientific ecosystem.
So when you see the blackout screen at Wikipedia, just imagine the day when it could be blacked out by your government.
Tuesday, January 3, 2012
Vaadin IPC for Liferay add-on
For Vaadin users, I just finished writing documentation for the Vaadin IPC for Liferay add-on yesterday. The version 1.0 of the add-on will be released tomorrow I think. The add-on is very very useful if you want to have two portlets that communicate with each other on the same page. The add-on uses standard Liferay JavaScript event API, so the other portlets can be any Ajax portlets, not just Vaadin.
Here's how it works:
As a side note, I really like Inkscape for drawing those diagrams. Well, I have no clue how wonderful some "best-of-the-best" vector graphics apps are. But I seem to be able to do practically everything with Inkscape and, after a while, it's not so hard to use. I've also done a nice production pipeline so that I can just save the pictures as SVG and the build scripts for the book do the exporting to PNG automatically. It's not even hard, just one command-line call.
The LiferayIPC is a Vaadin component that you add in the main window (layout). The inter-portlet communication is done between the client-side widgets.
You can combine this client-side communication method with server-side inter-portlet communication, for example, by using portlet session attributes. You may need to do that for security reasons or if you need to send large amount of data. In such case, you just send a client-side notification that says: "Hey, there's new server-side data available, read it now."
So, go ahead and read the new section in the Book of Vaadin. It explains everything. If it doesn't...go and ask in the Vaadin forum.
Here's how it works:
As a side note, I really like Inkscape for drawing those diagrams. Well, I have no clue how wonderful some "best-of-the-best" vector graphics apps are. But I seem to be able to do practically everything with Inkscape and, after a while, it's not so hard to use. I've also done a nice production pipeline so that I can just save the pictures as SVG and the build scripts for the book do the exporting to PNG automatically. It's not even hard, just one command-line call.
The LiferayIPC is a Vaadin component that you add in the main window (layout). The inter-portlet communication is done between the client-side widgets.
LiferayIPC liferayipc = new LiferayIPC();To receive an event in other portlets, you define a LiferayIPCEventListener as follows:
layout.addComponent(liferayipc);
...
liferayipc.sendEvent("hello", "This is Data");
liferayipc.addListener("hello", new LiferayIPCEventListener() {
public void eventReceived(LiferayIPCEvent event) {
getWindow().showNotification(
"Received hello: " + event.getData());
}
});
The add-on package includes this nice demo WAR that you can just deploy in Liferay. It demonstrates how to send and receive inter-portlet events.You can combine this client-side communication method with server-side inter-portlet communication, for example, by using portlet session attributes. You may need to do that for security reasons or if you need to send large amount of data. In such case, you just send a client-side notification that says: "Hey, there's new server-side data available, read it now."
So, go ahead and read the new section in the Book of Vaadin. It explains everything. If it doesn't...go and ask in the Vaadin forum.
Monday, November 28, 2011
Theme Development in Liferay
After installing a portal system (or web server), the first thing you want to do is create a simple web page and start customizing the theme. Unfortunately, Liferay's documentation is terribly unclear about that.
Well, its suggested normal method is to choose from a number of ready themes. Umm, NO! Nobody wants to use a theme like that. Every organization has their own colors and graphics and if not, you nevertheless want to have something that you have in your mind, not what some others have.
So, the "advanced" method is to develop a custom theme, which you can then deploy in Liferay. The Liferay plugin for Eclipse supports that. However, that method is way too heavy for me at least. I don't want to run a separate development Liferay on my machine, as I don't have enough memory in my home computer to do it fast enough. I want to work directly with the production server. I also suspect that deploying a theme takes longer than a second.
So, what I wanted to do was to just edit some CSS in the web server, save, reload, and see the result. This method of themeing does not seem to be documented anywhere, or at least it's hard to find. Anyhow, the easy way seems to be to edit the custom.css file in "classic" theme. The full path to the file is tomcat-x.x.x/webapps/ROOT/html/themes/classic/css/custom.css.
The problem with that was that just editing it did not reload it immediately, or actually ever. Even restarting the serve does not reload it. I found some suggestions for properties that would need to be set in the portal-ext.properties, but they didn't quite work in my case.
Finally, I found the solution right there in the Liferay's installation package. The file tomcat-6.0.29/webapps/ROOT/WEB-INF/classes/portal-developer.properties has the following settings for development:
I don't actually know which of the settings are really necessary, but now it seems to work great. Just edit the file and it's reloaded immediately.
Well, its suggested normal method is to choose from a number of ready themes. Umm, NO! Nobody wants to use a theme like that. Every organization has their own colors and graphics and if not, you nevertheless want to have something that you have in your mind, not what some others have.
So, the "advanced" method is to develop a custom theme, which you can then deploy in Liferay. The Liferay plugin for Eclipse supports that. However, that method is way too heavy for me at least. I don't want to run a separate development Liferay on my machine, as I don't have enough memory in my home computer to do it fast enough. I want to work directly with the production server. I also suspect that deploying a theme takes longer than a second.
So, what I wanted to do was to just edit some CSS in the web server, save, reload, and see the result. This method of themeing does not seem to be documented anywhere, or at least it's hard to find. Anyhow, the easy way seems to be to edit the custom.css file in "classic" theme. The full path to the file is tomcat-x.x.x/webapps/ROOT/html/themes/classic/css/custom.css.
The problem with that was that just editing it did not reload it immediately, or actually ever. Even restarting the serve does not reload it. I found some suggestions for properties that would need to be set in the portal-ext.properties, but they didn't quite work in my case.
Finally, I found the solution right there in the Liferay's installation package. The file tomcat-6.0.29/webapps/ROOT/WEB-INF/classes/portal-developer.properties has the following settings for development:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=trueroot
I don't actually know which of the settings are really necessary, but now it seems to work great. Just edit the file and it's reloaded immediately.
Sunday, November 20, 2011
Installing Liferay on MySQL
I'm installing a new web server for the astronomical association Turun Ursa. As we support Liferay at work, using it for this purpose may have some synergy so that I don't need to learn yet-another-portal. Well, not that Liferay is the easiest to learn. Anyhow, it also makes it possible to develop some portlets if I ever need one. I think I may need to redo my planetarium application again in Java - the old C++ version for Sparc stopped working some time ago after some upgrade at the university.
Anyhow, the instructions for doing the proper installation were rather unclear as they didn't really tell much details about creating the database. They referred to a "Chapter 6", which didn't exist at all. I guess they referred to these instructions, which were more helpful. Anyhow, below is a brief summary.
The setup is done here using the database root user. Some Liferay example used that though I don't really see why. Creating a separate Liferay user might be nicer. Well, I have Liferay running as a root anyhow to get it running in port 80, so the database user probably doesn't make it significantly safer.
Other notes:
Anyhow, the instructions for doing the proper installation were rather unclear as they didn't really tell much details about creating the database. They referred to a "Chapter 6", which didn't exist at all. I guess they referred to these instructions, which were more helpful. Anyhow, below is a brief summary.
The setup is done here using the database root user. Some Liferay example used that though I don't really see why. Creating a separate Liferay user might be nicer. Well, I have Liferay running as a root anyhow to get it running in port 80, so the database user probably doesn't make it significantly safer.
Shut down the server
# ./tomcat-6.0.29/bin/shutdown.sh
...and wait for a bit.
Move the 7Cogs demo data generator away
# mv tomcat-6.0.29/webapps/sevencogs-hook/ .
Create the database with a database command and not using the mysqladmin to be able to set the character set. It's probably important.
# mysql -prootpassword
mysql> create database lportal character set utf8;
Query OK, 1 row affected (0.00 sec)The MySQL configuration stuff is explained in this wiki.
Create a portal-ext.properties file in the Liferay installation directory with content:
#
# MySQL
#
jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/lportal?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=root
jdbc.default.password=rootpasswordStart up the server
# ./tomcat-6.0.29/bin/startup.sh
Follow that it starts OK
# tail -F tomcat-6.0.29/logs/catalina.out
Other notes:
- When first logging in, create a new user account with your own name. Then log out and log in as user "test@liferay.com" with password "test" (this information was not really obvious in the instructions either). Go to Control Panel -> Users and give yourself the Administrator role. You need to remove or disable the "test" account at some point...
Thursday, November 10, 2011
Windows behind the background
I've had a lot of trouble with my dual screen setup with Kubuntu 11.10. It works like a dream when you set up it at first. The trouble starts when you turn off either or both of the monitors and then turn them on. KDE is "intelligent" so that it tries to switch between the single and dual display set up depending on what displays are on. Unfortunately, the result is rather uncontrolled and random.
So, this morning I arrived at work and opened my laptop first...MISTAKE! I should have turned on the external monitor instead. So, it did not just not work, but also got completely stuck. So, I restarted kdm from console screen. After that, the behavior got really odd. No windows were visible. I could see them in the task panel, but they were nowhere. Then, I switched to the 3D cube view and I could see them - behind the background!
So, apparently the background is no longer a "root image" in X, but a window itself, and it has a Z index. I was able to bring the windows forth by right-clicking them in the task bar and selecting "Advanced -> Keep Above Others". But that was rather nasty thing to do. Then occasionally, the panel itself would drop below the background image and using the machine became impossible. Even restarting the machine did not help, apparently the Z index of the background was saved in system configuration. Great.
I traced the problem to .kde/share/config/plasma-desktop-appletsrc. Apparently, the background is managed as a desktop applet (aka "desktop widget") and each has a zvalue parameter defined in the configuration.
I did not trace the issue further, just removed the file. Apparently others have met the same issue, hence this post.
So, this morning I arrived at work and opened my laptop first...MISTAKE! I should have turned on the external monitor instead. So, it did not just not work, but also got completely stuck. So, I restarted kdm from console screen. After that, the behavior got really odd. No windows were visible. I could see them in the task panel, but they were nowhere. Then, I switched to the 3D cube view and I could see them - behind the background!
So, apparently the background is no longer a "root image" in X, but a window itself, and it has a Z index. I was able to bring the windows forth by right-clicking them in the task bar and selecting "Advanced -> Keep Above Others". But that was rather nasty thing to do. Then occasionally, the panel itself would drop below the background image and using the machine became impossible. Even restarting the machine did not help, apparently the Z index of the background was saved in system configuration. Great.
I traced the problem to .kde/share/config/plasma-desktop-appletsrc. Apparently, the background is managed as a desktop applet (aka "desktop widget") and each has a zvalue parameter defined in the configuration.
I did not trace the issue further, just removed the file. Apparently others have met the same issue, hence this post.
Subscribe to:
Posts (Atom)