Tricky KDE icon

[Lancer]

What I want to do is very simple. I want to create an icon, let's say a smiling face icon. When the user clicks the icon, it pops up a message saying "Hi there! I am in directory <whatever directory the icon happens to be in>". If the user drags the icon to a new directory (move here) then clicking the icon of course gives the new location of where the icon is situated.

This is easy to do in Gnome.

My making the before mentioned shell script:

Code: Select all

#!/bin/bash
xterm -geometry 50x3 -bg black -fg green +sb -T "You clicked me" -hold -e echo "I am in directory $(dirname $0)"

Next right click over the icon of the above shell script and choose "properties" from the drop down menu that appears. Hit the "Select custom icon" button under the "Basic" Tab of the dialogue box that appears. finally select a suitable smiling face.

The result leaves you with a smiling face icon which, when clicked, runs the shell script which flashes up the message about which directory the icon is in.

All good so far.

However - can KDE do the same thing? I can get the same script to work when clicked for sure. However what I can't seem to do is make the icon change appearance from the default for "executable file"... not without changing icons for it's global type and I don't want to do that, as the icon is only a one off and I may want to make other icons with different faces.

By all appearances, KDE cannot do truely customisable icons like Gnome can. Unless, the icon is a link (desktop link). These can be customised. However, a scipt is run from such a link gives the original script location, not the location of the desktop shortcut icon which was clicked to run the script. I don't know how to trap that event.

So hey... I did it for Gnome. How do I do the same for KDE?

[Flea]

I suppose you could add a new mime-type in 'KDE Kontrol' that would allow you to use a different icon. Of course you would need a new mime-type for every different type of script you wanted.

I had a go at doing this myself, and it works for the icon. Only I can't seem to get the new type (a .cm file) to execute it just pops up the 'open with' dialogue

Just an idea, hope this helps.

Dave.

[Lancer]

I'd considered a mime type idea but found it was a bit impractical because of the need to clutter my school systems with bogus mime types any time I wanted to make new "active icon" theme sets (e.g: file names ending in .icn1 .icn2 .icn3 .icn4 etc). I wanted to avoid where possible using file name extensions to identify mime type as well, simple calling an icon "Harry". Also, as there are a dozen or so school computers, setting up each one would be a real pain. I'd like to have something where I could just FTP the icons around into everyone's /home dirs for whatever exercise we are doing.

Therefore, I did not actually try the mime-type... just wondering, would "make executable" get the icons to work for you Flea? If not, perhaps set it to open with /bin/bash?

[jjmac]

Aaha, i see what your saying. The pwd problem was solved using a script in the same directory. Not exactly what you wanted. And if a different mime type is cumbersome, then i guess my grep idea would be over kill

>>
By all appearances, KDE cannot do truely customisable icons like Gnome can. Unless, the icon is a link (desktop link). These can be customised.
However, a scipt is run from such a link gives the original script location, not the location of the desktop shortcut icon which was clicked to run the script.
>>

Just running a script placed in ~/bin via a standard soft link from various different directories ...

A script placed in ~/bin
-------------------------------------
#!/bin/sh

echo "prog name is : $0"
echo "current dir is : $(pwd)"
------------------------------------

When run from a term window (rxvt), does return the links name and the directory path the link is in. Would it be possible to give a standard link an icon.

A really interesting problem though, hope it works out. What about a kde board ?, or a developers list ?

jm

Code: Select all


      -:-  If the system is the answer, then the question
                      must have been really stupid                 -:-


[Lancer]

Aaha, i see what your saying. The pwd problem was solved using a script in the same directory. Not exactly what you wanted. And if a different mime type is cumbersome, then i guess my grep idea would be over kill

Not entirely overkill. By "cumbersome" I meant it would add too many unneccesary filetypes to the system for what is really a trivial set of class exercises, and these would have to be individually set for each individual computer on the network.

Your idea of greping the filemanager to trace a var is an interesting possibillity, except that I don;t imagine I'll find the var, if it exists, in a while... or even whether the correct var would be referenced in the file manager at all.another method might be to check the location of the current active nautilus window. Again - it's lack of knowledge of the file manager variables which prevents me for gettign this.

[jjmac]

>>
idea of greping the filemanager to trace a var is an interesting possibillity
>>

Meaning, of course, greping the 'source'. There must be a function that retrieves the current directory path somewhere, for the current directory in the managers window. Especially if the filemanager allows for a shell window to be invoked for that window/directory via a button click.

From there it depends on how 'intuitive' the developer has made their function names. As that would be the easiest thing to grep on. Different people seem to have different ideas on what makes sense when it comes to naming chemes though. Not impossible, but it can turn into a full weekends work.

I use a manager called 'filerunner' written in tcl, but of course konqueror would be c++/c being kde. tcl is about as straight forward in its' naming schemes as a politicians answer to a fair question , ... it can be a real pain trying to trace anything down in it. So it would all really just depend on that aspect, as to how much of a hassel it turned into.

Though ... If that proved to work ... i was thinking you could just add some code with in that relevent function to open a file in your HOME directory, and then write that path to it, then close the file. It would then happen each time you do a directory change in the manager. Then recompile the manager with a modified name so that it could be used with out clashing with the original.

It could well be a lot of trouble to go to, but, then again ... there is a lot of mischief/things that could be gotten upto with that .

A desktop icon, or any appropriate icon, if it was to reference a script that returned a 'cat' on that path file ... it could do an immediate 'cd' to where ever it happens to point.

The more i think on it, ... it could be a lot of trouble to go to. I think you were saying that you would have an icon in the actual directory concerned. If so, couldn't that reference a symlink back to a common script. That works when executing a script with a symlink directly, from a different directory location. But, having icons in different specific directories does seem to kill the 'magic trick' aspect of it all . So maybe the 'edit the source' angle may be worth it.

Then again, why not teach them the cli instead (grin).



jm

Code: Select all


             -:-  If the system is the answer, then the question
                             must have been really stupid                 -:-


[nelz]

[quote="jjmac"]Meaning, of course, greping the 'source'. There must be a function that retrieves the current directory path somewhere, for the current directory in the managers window. Especially if the filemanager allows for a shell window to be invoked for that window/directory via a button click.</quote]

You can do that in KDE with dcop. I've used this in scripts that I run from a shell that act on the current directory displayed in Konqueror.

Run kdcop and you'll be able to view and experiment with the options.

[jjmac]

Appears to be an interproccess comunication facility. The documentation in knoppixs' kde 3.1.5 is non-existent, so there wasn't much explanation there. The man pages were just holding pages. Though, i would expect the kde site, or a kdcop site would have better documentation.

But, ... how would you apply that, to retrieving something like the 'pwd', when used in a script ?

I did manage to invoke the 'logout' facility with it


jm

Code: Select all

           -:-  If the system is the answer, then the question
                        must have been really stupid            -:-


[nelz]

Browse through the options in kdcop. it shows you what is available for each window and the output of each command. you need something like konqueror-mainwindow.currentURL for the active konqueror window window.

I haven't been able to find much in the way of decent user documentation for dcop, but kdcop makes trial and error easy.

[jjmac]

hmmm, so ... very interesting ... wonder what it stands for ... cop ----- [co]munication [p]rotocol


I will assume it's a kind of inter app comunication system. I will have to experiment a bit more there. Now that i have a few more Mhz to work with, kde has come to make a bit more sense lately (grin). Better update though i think (anothergrin). I also managed to put an extra hide/show tag on the task bar too. For no particular reason, it will probably be still there on the next visit, i bet. But ... are you suggesting that it can be used with shell scripts ... in some way.

I get the feeling it's more ment to be used as a developers tool, of soughts, after which the relevent code would be implemented in source. Rather than as an actual desktop/user facility. But, i've only just glanced at it.

Are there many more interesting kde things like that, hiding away there somewhere. Some really good stuff can be all to often, just sitting under a persons nose, and not be noticed at times.


jm

Code: Select all


          -|-   If the system is the answer, then the question
                            must have been really stupid               -|-


[nelz]

It is definitely intended for scripting use as well and development of programs using IPC. Why else would kdcop have options to show the Bash and Python equivalents of any commands you try?