Main index > Off the wall > desktop toggle for adesklets.

By eNTi (User), on Wed Sep 21 14:41:16 2005: desktop toggle for adesklets..

i'm not sure where to put this, so i put this idea here.

as i don't know yet, what's possible and what is not, i just suggest my idea into the unkown space:

i'd like to have a toggle for adesklets that "maps" all mouse klicks to the desktop and thus ultimatly "incoporate" the desklets into the desktop. i want to be able to right klick on a desklet and open the menu for my window manager or the preferences dialog or whatever, rather than opening the menu for the desklet. is this possible at all?

By syfou (Core Developer & Desklet Author), on Wed Sep 21 16:57:26 2005.

That should be perfectly doable; In fact, I already had this discussion a couple of time (look here for a starter), and Cameron Daniel (cs-cam) even made an attempt to implement it himself, but I think he didn't pursue...

By cs-cam (Desklet Author), on Wed Sep 21 18:31:01 2005.

Yeah, I made a start. Not knowing any C made it difficult :p I passed the event somewhere, because the right-click menu didn't show up after I recompiled with my changes but neither did my WM menu. Not sure where that click event ended up...

By syfou (Core Developer & Desklet Author), on Wed Sep 21 21:37:30 2005.

Here you go. Do not forget to toggle on the --enable-control-on-context-menu switch with configure.

By eNTi (User), on Mon Oct 3 05:32:52 2005.

i've incoporated the changes and recompiled with the flag, but adesklets won't work any longer. i can start it and it will exit, without any of my desklets showing up. i get no error, nothing.

By syfou (Core Developer & Desklet Author), on Mon Oct 3 15:02:30 2005.

Well, it works OK on all systems I have here... The complete changes is around ten lines of code, and is pretty minor; I doubt there is anything there to scrap an entire installation by itself.

eNTi:
cs-cam: is this working for you, or do you experience the same problem than eNTi?

By eNTi (User), on Tue Oct 4 05:16:26 2005.

syfou wrote:

Well, it works OK on all systems I have here... The complete changes is around ten lines of code, and is pretty minor; I doubt there is anything there to scrap an entire installation by itself.

eNTi:
Were you installing from source before, or from some prepackaged version or automated installer? Tell me again what you use in term of platform (Some Gentoo Linux system, if it didn't change?).


i'm still using gentoo and i've emerged adesklets in both cases. in the first case the normal adesklets-0.4.12 without any changes to the source. in the second case i've made the adjustment to the source, repackaged it, copied the ebuild over to my overlay, added the config parameter to "local myconf" and renamed it to adesklets-0.4.12-r1.ebuild.

Quote:



  • If you did not install adesklets from source previously, are you able to get a working adesklets out of a pristine adesklets-0.4.12.tar.bz2 source distribution (make sure you uninstall first the original adesklets you had on your system)?


i've just emerge -C / emerge adesklets after moving the modified source out of the way and changed the "local myconf" back to nothing.

Quote:



  • If this works, is the patched adesklets-.0.4.12 still working without specifying the --enable-control-on-context-menu switch at configuration?


nope... does not work. maybe i've made a mistake? i'm not sure, but i thougth there's too many #endif's?

Quote:



  • What is happening when you run test/test.py on your current failing installment?


Code:

nt@eNTi $ python /usr/portage/distfiles/adesklets-0.4.12/test/test.py
Traceback (most recent call last):
  File "/usr/portage/distfiles/adesklets-0.4.12/test/test.py", line 17, in ?
    import adesklets
  File "/usr/lib64/python2.4/site-packages/adesklets/__init__.py", line 33, in ?    from adesklets.utils import *
  File "/usr/lib64/python2.4/site-packages/adesklets/utils.py", line 4, in ?
    from commands import version
ImportError: cannot import name version

By cs-cam (Desklet Author), on Tue Oct 4 07:00:44 2005.

Weird, works for me fine. I'm only very vaguely familiar with the ebuild system but I'd have to say it looks like your problem is there somewhere. Is the patch applying correctly? During my experiments I managed to successfully compile a couple of thoroughly non-working adesklets installations, I'd look there.

By eNTi (User), on Tue Oct 4 07:08:50 2005.

well... honestly the patch migth be my problem. because i can't get a working "patch" file from the linked site, so i decided to incoporate the changes by hand. since there were no errors during compilation, i thought i made no mistake. well either i made a mistake, or something with the change in the ebuild didn't work out. not sure what.

i'm not familiar with the "git" system either, so i'm not yet ready to use it to get the latest version through that.

i'll try and report, but it might take some time.

By cs-cam (Desklet Author), on Tue Oct 4 07:57:03 2005.

Yeah, I'm not up with Git either. Here is a link to the diff I used

http://www.camdaniel.com/media/code/right-click.diff

Code:


cd adesklets-0.4.12
patch -Np1 -i ../right-click.diff

:)

By eNTi (User), on Tue Oct 4 08:08:28 2005.

hmm... it's the patch it seems. adesklets isn't starting up any longer. i'll do it by hand.

update: same results. adesklets seems to start up (it creates ~/.adesklets) but then exits at once. is there a way to get some debug info out of it?

By cs-cam (Desklet Author), on Tue Oct 4 08:38:22 2005.

Hold up, I incorporated the patch into an Arch Linux package, just to make my installation easier, I like to keep track of everything I have installed. I sent build script to another Arch user who is having similar problems to you. Here is a traceback I was sent when trying to start mpdcontroller:

Code:


Traceback (most recent call last):
  File "mpdcontroller.py", line 3, in ?
    import adesklets
  File "/usr/lib/python2.4/site-packages/adesklets/__init__.py", line 33, in ?
    from adesklets.utils import *
  File "/usr/lib/python2.4/site-packages/adesklets/utils.py", line 4, in ?
    from commands import version
ImportError: cannot import name version

I think this is something for Sylvain to play with, C is too far over my head. I learned that when I tried to write this functionality in myself originally :oops:

By syfou (Core Developer & Desklet Author), on Tue Oct 4 15:19:25 2005, last edited on Wed Oct 5 13:47:38 2005.

Don't you see what you both report here are a same problem with the Python code, not the C code? :)

My guess it that both eNti and the Arch Linux user are having problems with the automated rewrite of the adesklets Python package that automatically occurs whenever src/adesklets.c or src/command.c is refreshed (see scripting/prototypes.sh). After you applied the patch on a clean adesklets-0.4.12 source tree (the extraction by cs-cam seems correct), you can bypass the rewrite by doing:

Code:


touch scripting/prototypes scripting/enums


P.-S. All these complex sandboxes (portage, pacman, ...) are not necessary for accurante bookkeeping of most autotools-based packages. Try this as a non-superuser in place of make install:

Code:


make DESTDIR=$HOME/fake_root install

This works 95% of the time (it does with adesklets). And if it doesn't, well, no harm is done. Going through a complete repackaging/instrumenting/installing cycle everytime you want to test a little something would really be a pain.

P.P.-S. I am confident the proposed modification is not faulty. I ever you go nowhere with this, just wait for adesklets 0.4.13 or 0.5.0 to come out pre-packaged in a couple of weeks.

By eNTi (User), on Tue Oct 4 15:26:13 2005.

i don't know if it's just me, but what are you talking about? i don't understand what you are trying to tell me. what is this strange "automated rewrite" and what does this have to do with compiling everything from scratch? i mean, i know, that the make check's the timestamps on the files to determine if they have changed since the last compilation, but what does this have to do with everything? why shouldn't src/adesklets.c be recompiled, if i add a patch? sorry, but i'm completly confused now.

By syfou (Core Developer & Desklet Author), on Tue Oct 4 16:14:07 2005.

eNTi,

you have different components in adesklets-0.4.12.tar.bz2; under src/, you have the source code of a small standalone interpreter written in C (forming the adesklets binary at the end of the day), as well as a Python package taking advantage of the interpreter under scripting/python/; this package provides bindings between Python-based desklets and the standalone interpreter.

Parts of the Python package under scripting/python/ is automatically written (generated) from the interpreter code base (namely: the content of src/adesklets.c and src/command.c); The end user normally never go though this rewriting step, since he does not change the interpreter code himself. I suspect this is what goes wrong for you, while the C based interpreter resulting from the forthcoming compilation is still functional. This is why I suggested you try:
I hope I have made myself clearer this time. Yours,

P.-S. I am not at home until Friday; please bear possible lags between future answers, as I will probably look at this site at most once a day.

By eNTi (User), on Tue Oct 4 16:34:44 2005.

yes. that was clear enough, thank you.

and now it's working. i'm not sure if i have to touch the files again after repacking and letting the portage system do the work, but i did it and it worked. maybe, if i'm bored, i'll try without interupting the emerge process...

By syfou (Core Developer & Desklet Author), on Wed Oct 5 14:02:50 2005.

Tarballs (well, at least in v7, gnu, ustar or posix formats) contain about all portable stat-related (see man 2 stat) information -- this includes access, modification and status change time; so it is good enough to repack things, as long as you touched the files after applying the patch...

This said, it would probably have been quicker to just adapt the ebuild ("epatch", then touch). :) Anyway, I am glad this worked for you, eNTi.

By drphibes (User), on Tue Feb 14 11:23:02 2006.

Glad I found this thread, as I couldn't understand why a simple patch to adesklets.c resulted in subsequent scripting errors on 'import adesklets'.

Under gentoo then, to apply a new patch, I added this src_unpack() section to the adesklets-0.5.0-r1.ebuild I created in my portage overlay:

Code:

src_unpack()
{
        unpack ${A}
        cd ${S}
        epatch ${FILESDIR}/ungrab-pointer.patch || die "epatch failed"
        # when patching src/adesklets.c or src/commands.c, you need to touch these files
        # ref: http://adesklets.sourceforge.net/forum/viewtopic.php?p=1316#1316
        touch scripting/enums scripting/prototypes
}

Also I changed the src_compile() section so as to include --enable-control-on-context-menu which is not a default at present (maybe a USE flag is needed there?):

Code:

src_compile()
{
        local myconf="--enable-control-on-context-menu"

        ... 
}


A description of what the above patch does can be found here:

http://adesklets.sourceforge.net/forum/viewtopic.php?p=1658#1658

adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.