Main index > Off the wall > usage scenario... as a public linux desktop

By thinhla (User), on Sat Jul 9 22:25:26 2005: usage scenario... as a public linux desktop.

This actaully is not a problem but would rather be a search for knowledge. My scenario is to setup a linux desktop for a public usage with all this little cool things.

I don't want user to move around the desklets by going into context menu "Move" command. This also applies to the "Quit" and "Configure" commands. Could we just disable these commands somehow?
- My thoughs: install as root all the desklets in /usr/local thus prevent write access by users to config.txt but again this doesn't prevent user from shutting down the desklets

Desklets start up everytime a system reboots/relogin.
- My solution and problems: I use Gnome and put adesklets command into Sessions as a starup program. Somehow this hangs/freezes Gnome splash window/screen (I have to click on a desktop for this to go away) And this adesklets command doesn't start the desklets either. I have to create a laucher to adesklet command and manual click on it for it to start

Could someone beam me up with some insight about my scenario?

By syfou (Core Developer & Desklet Author), on Sun Jul 10 01:15:15 2005.

That's a nice idea, thinhla. :-)

Unfortunately, I have not used Gnome in a long time, hence I cannot really help you with this part of your problem. All I can say is that adesklets is "perfectly kosher" regarding what it does: it doesn't interfere at all with the window manager at the X11 protocol level. Not seeing the desklets doesn't necessarily mean adesklets didn't work: it can mean as well that the desklets are being hidden: Gnome initialization takes a while, and adesklets as to be called only when it is completed, since Gnome uses a fake root window that adesklets has to be aware of...

What you propose about storing desklets under /usr/local is perfectly doable; depending of the access level you give the users, you might want to lock up the $HOME/.adesklets file as well (just setting it under the control of another user seems fine). As for preventing the menus, what you have to do is to modify the adesklets_menu_Fire() function from src/adesklets.c. Here is a quick and dirty patch that removes all access to menus.

By thinhla (User), on Mon Jul 11 09:57:21 2005.

Quote:

What you propose about storing desklets under /usr/local is perfectly doable; depending of the access level you give the users, you might want to lock up the $HOME/.adesklets file as well (just setting it under the control of another user seems fine). As for preventing the menus, what you have to do is to modify the adesklets_menu_Fire() function from src/adesklets.c. Here is a quick and dirty patch that removes all access to menus.


As I understand $HOME/.adesklets file is to administrate the position of a desklet. Correct? Thus setting it under the control of different user prevents original user from modifying it. This sounds very reasonable

Regarding modidying adesklets_menu_Fire(), do I need to do/apply the patch before it's compiled and installed? I have everything compiled and installed already so I need to redo it, don't I?

Before I go ahead to do it, I just want to make sure that applying the patch is like this supposedly I have adesklets_nomenu.diff in the folder where adesklets.c is

Code:

 patch < adesklets_nomenu.diff adesklets.c


Once I have done recompiling and reinstalling it, do I just start the desklet normally by giving it a comand adesklets? Once I disable the context menu of a desklet if I need to move a desklet around desktop I have to modify manually the aforementioned file $HOME/.adesklets, right?

By the way, thanks for all hard-work creating adesklets program and knownledge/help answering all my concerns. Much appreciated.

By syfou (Core Developer & Desklet Author), on Mon Jul 11 13:53:23 2005.

thinbla wrote:


As I understand $HOME/.adesklets file is to administrate the position of a desklet. Correct? Thus setting it under the control of different user prevents original user from modifying it. This sounds very reasonable

That's correct. A cleaner way would be to change the code in a way that the configuration file would be elsewhere ($pkgdatadir/adesklets.cfg for instance). But I believe this is enough for experimenting.

thinbla wrote:


Regarding modidying adesklets_menu_Fire(), do I need to do/apply the patch before it's compiled and installed? I have everything compiled and installed already so I need to redo it, don't I?

Yes, you need to apply it before compilation. It is alteration to the source of adesklets: the only way is will be taken into account is if you generate a new adesklets binary out of the modified code. :-)

thinhla wrote:


Before I go ahead to do it, I just want to make sure that applying the patch is like this supposedly I have adesklets_nomenu.diff in the folder where adesklets.c is

Code:

 patch < adesklets_nomenu.diff adesklets.c


Yes, that's it. You go into the src/ directory of the newly extracted adesklets 0.4.10 source package, use patch as mentionned, giving the proper path to the diff file (no need that the diff file be in the same directory. The "<" operator is redirecting from stdin). You could as well do:

Code:


cat /path/to/desklets_nomenu.diff | patch /path/to/adesklets-0.4.10/src/adesklets.c


thinhla wrote:


Once I have done recompiling and reinstalling it, do I just start the desklet normally by giving it a comand adesklets? Once I disable the context menu of a desklet if I need to move a desklet around desktop I have to modify manually the aforementioned file $HOME/.adesklets, right?

Once again, all this is correct. Alternatively, you could just keep the two binaries side by side, and use a wrapper script like:

Code:


#! /bin/sh

# Sample wrapper for kiosk use. Rename as $PREFIX/bin/adesklets .
#
# 'guest' is the name of the public usage account.
#
# /usr/bin/adesklets.nomenu contains the modified binary
# /usr/bin/adesklets.menu contains the original binary
#

case "`whoami`" in
    guest ) BIN=/usr/bin/adesklets.nomenu ;;
    *     ) BIN=/usr/bin/adesklets.menu ;;
esac

exec $BIN $*


This way, the guest account would use the "menuless" version, and everybody else would still have access to the original one.

thinbla wrote:


By the way, thanks for all hard-work creating adesklets program and knownledge/help answering all my concerns. Much appreciated.

You are very welcomed. This is always rewarding to know people are using your work. :-)


adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.