Non-functioning Menu entry.... (SOLVED)

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

Non-functioning Menu entry.... (SOLVED)

#1 Post by Mike Walsh »

Afternoon, all.

Well, this is embarrassing.

After the success I had with my PepperFlash .pets,

http://www.murga-linux.com/puppy/viewtopic.php?t=106409

....I've decided to turn my hand to the 64-bit version of SlimJet; a browser which, for me, has pretty well replaced Chrome (and I've been a Chrome user since it was in beta, back in 2008).

After making the release announcement here, I've had to withdraw them temporarily, upon discovery that they won't actually start from the MenuEntry..! :oops:

32-bit SlimJet normally resides in /usr/lib; I've located these in /opt (a nice 'catch-all' directory), which quite neatly sidesteps the problem with the rather non-standard implementation of the way the lib32 & lib64 directories are linked in 64-bit Pups. Some link in one direction, some the other, and some don't link at all. Plus, Tahr64 has 32-bit compatability libraries, whereas others, such as Slacko64 and Lighthouse64, don't appear to have anything resembling these.

I've been using trio's 'Pet-Maker' package, which is a really useful .pet. Initially, I used it for the SFS packages as well as the .pet ones, although recently I've been experimenting with the 'mksquashfs' command, which seems to work just as successfully.....I suspect the dir2pet script within trio's package probably makes use of this, as well as others. Remember, I'm still quite a 'noob' when it comes to this side of things, so be gentle with me..!

They will all start quite happily from

a) The SlimJet wrapper-script itself
b) The symbolic link to the above, in /usr/bin, and
c) The .desktop file. BUT:

I cannot, for some reason, get them to start from the Menu entry. What I'm wondering is this:-

Does the .pet/SFS need to include an entry for /root/.jwmrc? (Since this appears to be where the Menu entries are generated, although I'm not at all certain of the mechanism...)

I understood that the .desktop file would somehow generate the Menu entry during the installation process; if I'm wrong here (and I suspect I am), I'm more than willing to learn the correct way of doing this.

My .desktop file for these SlimJet packages is as follows:-

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Name=SlimJet
Icon=/usr/share/pixmaps/Slimjet.png
Comment=SlimJet web browser
Exec=flashpeak-slimjet
Terminal=false
Type=Application
Categories=X-Internet-browser
GenericName=SlimJet web browser
I've included the 'Terminal=false' entry as, after studying many other .pet & SFS packages, they all seem to use this.....but what does it actually do?

Any advice on this will, as always, be very much appreciated.


Mike. :wink:
Last edited by Mike Walsh on Thu 16 Jun 2016, 12:17, edited 1 time in total.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#2 Post by nic007 »

Have you run fixmenus yet?

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#3 Post by Mike Walsh »

Hi, Nic.

No, I'll be honest with you; I'd forgotten about that. I mean, the entry shows up in the Menu.....but it doesn't actually do anything, despite showing the correct application path in /root/.jwmrc.

As I understand it, fixmenus is used to make 'reluctant' menu entries show up in the first place.....or have I got the wrong end of the stick? I mean, it's annoying to not have every part of an application working as it should.....but aside from that, it's unprofessional to release something for general consumption in that condition. It gives the impression that you couldn't care about doing the job properly.....and it doesn't give Puppy very good publicity, either.

Hence why I've withdrawn them until I can get them fixed. Every part functions as it should.....apart from the Menu entry. Despite the fact that those of us familiar with Puppy know there's lots of different ways to launch something, that's the one method the majority of people will wish to use.

I'll give 'fixmenus' a try, but I'm not hopeful..... I'll let you know what happens.


Mike. :wink:

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#4 Post by Mike Walsh »

Hi again, Nic.

Nope. Didn't do a thing. It's not that the menu entry isn't showing up ( it does).....the entry, as far as I can tell, is correct in /root/.jwmrc. too (application path and everything); but it simply won't execute.

My usual method, since I prefer to work from desktop icons, is to drag an app's .desktop entry onto the desktop, edit and tart-up as necessary, and to use that.....but for some people, even that's too much like hard work!

But the point is, the Menu entry should work. That's the primary method employed by most people to launch something.....and it isn't doing its job. So; where have I gone wrong with it?

Anyway, thanks for the suggestion; it was appreciated, even if it wasn't the 'magic bullet'!


Mike. :wink:
Last edited by Mike Walsh on Wed 15 Jun 2016, 20:41, edited 1 time in total.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#5 Post by Mike Walsh »

A question.

In my .desktop file above, does the 'Exec' entry refer to the /usr/bin executable? Do I have that part correct?

Edit:- Y'know, thinking about it, I wonder if some of the problem might be down to my spelling & syntax (once again!) I.e., 'Slimjet' instead of 'SlimJet'.....or maybe all lower case, right the way through..?

I know how fussy Linux is about dotting the i's, and crossing the t's... :lol:


Mike. :wink:

User avatar
Moat
Posts: 955
Joined: Tue 16 Jul 2013, 06:04
Location: Mid-mitten

#6 Post by Moat »

Weird one! Opening from the .desktop file directly, but not the menu entry (which should reflect that same, exact .desktop file).

I'm no expert, but wonder if there's a conflicting .desktop file floating around the system somewhere (/usr/local/** ??) with an older, improper "Exec=" entry, that's taking menu priority over the /usr/share/applications .desktop file... :?: Pfind would likely uncover it's location, if so.

FWIW,

Bob

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#7 Post by Mike Walsh »

Hallo, Bob.

Actually, now you mention it.....

There's a SlimJet /usr/lib/entry keeps popping up, every time I install a SlimJet package for testing purposes. I made up a version of 10.0.0.0., a little while back, which was located in /usr/lib/slimjet. Now, although every trace of it has been wiped from the system (there's definitely nowt in /usr/lib any longer).....and I've edited /root/.jwmrc, and /root/.jwmrc-previous, and done a re-boot to ensure the alterations got saved.....it keeps on popping up from somewhere. And I can't for the life of me figure out where it's coming from.....

Are there any other .jwmrc-related files, elsewhere in the system, that I'm not aware of? 'Cos it's the only thing I can think of that's interfering with the normal launch process.....

Any ideas, mate?

Edit:- Screenie below of what pFind has thrown up.

Image

There's not one item there that I haven't put there myself.....so where the hell is usr/lib/slimjet coming from?

Here's the extraneous internet entry:-

Image

Wait a minute...!. I've just discovered another 'dead' entry , under 'Networking'...

Image

.....and pFind doesn't throw this up at all. Here's the /root/.jwmrc entry for it, highlighted (if you can read it):-

Image

So where's it coming from? (*scratches head*) Is there by any chance some kind of log in the system that hangs onto stuff, long after it's been deleted?


Mike. :?

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#8 Post by Sailor Enceladus »

Mike Walsh wrote:So where's it coming from? (*scratches head*)
I noticed that it looks in both /usr/share/applications and /usr/local/share/applications for menu entries.
Last edited by Sailor Enceladus on Wed 15 Jun 2016, 22:54, edited 1 time in total.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#9 Post by Mike Walsh »

Hi again, Bob.

Just had a thought. You take a gander at both of the extraneous 'FlashPeak SlimJet' entries in .jwmrc; both of them have a '%U' at the very end of the exec phrase. Nothing else in .jwmrc is showing this.....yet pFind doesn't 'find' them.

I was just considering what you meant by improper 'Exec' entries... What d'you think?

(This is in Slacko64 6.3.0 at the moment, BTW.)


Mike. :wink:
Last edited by Mike Walsh on Wed 15 Jun 2016, 22:57, edited 1 time in total.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#10 Post by Mike Walsh »

Sailor Enceladus wrote:
Mike Walsh wrote:So where's it coming from? (*scratches head*)
I noticed that looks in both /usr/share/applications and /usr/local/share/applications for desktop entries.
Hiya, Sailor.

Good catch..! It does seem to, doesn't it? But the only things I've got in /usr/local/share/applications are...

Image

.....the Libre Office .desktop entries. So where do I go from here? Any ideas, anyone?


Mike. :wink:

User avatar
Moat
Posts: 955
Joined: Tue 16 Jul 2013, 06:04
Location: Mid-mitten

#11 Post by Moat »

Mike -

1) Click the "eye" on Rox's toolbar, to uncover any hidden files and make sure your not missing anything in /usr/share/applications and /usr/local/share/applications.

2) Hmmm... I believe the text displayed in the menu entry (as "FlashPeak Slimjet" in your screenshot) is defined in the .desktop file's "Name=" line... since your screenshot's menu entry displays differently from what you posted earlier as the actual .desktop file's "Name=SlimJet" entry (and there is no "FlashPeak Slimjet" entry to be found in said above .desktop file) - this still makes me suspect there's a stray, old .desktop file being used by JWM to build the menu, instead. Maybe look further up the .desktop directory list (after making sure Rox is showing all/hidden files), for something alphabetically beginning earlier with, say, "Flashpeak" instead of "Slimjet" - or whatnot.

3) I also believe the "%U" has something to do with allowing a browser to open an external link directly (from, say, your email client) - so it will open the browser directly to the link, and not just open as usual to your default home page. I think that's what that's for, anyway...!?! :shock:

4) Remember, you can test any of the (questionable) exec lines by running 'em in a terminal, and see what happens (errors, nothing opens, etc.).

In the past I've noticed that some updated application's binaries require a different/updated exec command to fire - and therefore a new/updated .desktop file to go with it (possibly even with a different name). And sometimes the old, now-broken ones get left behind - muckin' things up a bit.

Hopefully some of that might be of help, but like I said - I'm no expert at these things! (Where's Semme when ya' need him?! :) )

Bob

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#12 Post by perdido »

Look in the file /opt/slimjet/flashpeak-slimjet

Seems to generate its own desktop file when run.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#13 Post by nic007 »

The U% in the name of the executable is definitely incorrect. This is what I would do: delete that entry in .jwmrc > specify the full path of the correct executable in the desktop entry > do fixmenus > restart JMW

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#14 Post by Mike Walsh »

perdido wrote:Look in the file /opt/slimjet/flashpeak-slimjet

Seems to generate its own desktop file when run.
Hi, perdido.

Thanks for spotting that one. Definitely a 'good catch'! TBH, although I've been looking at this script a lot the last few days, I've been concentrating on the last few lines. That's where the switches for disabling the sandbox, and specifying the user-data-directory, get added on to enable it to run with Puppy's root model.

It would certainly explain where the superfluous Menu entries are coming from.
nic007 wrote:The U% in the name of the executable is definitely incorrect. This is what I would do: delete that entry in .jwmrc > specify the full path of the correct executable in the desktop entry > do fixmenus > restart JMW
I think what I shall do is to re-edit the SlimJet wrapper-script, and remove the entire section to do with checking for, and generating a .desktop file. I can't see that it's necessary at all, due to the way we generate .desktop entries in .pets. I'll then re-package, and test again.....after employing Nic's suggestion, and getting shot of those extra, unwanted Menu entries once and for all.

If you look at the 'google-chrome' wrapper-script in any recent Chrome, they don't include half of this extra stuff that FlashPeak have added into their version.....so I can't really see it's serving any purpose.

Thanks for the advice and 'spotting', guys. I'll let y'all know how it pans out. Watch this space.....


Mike. :wink:

B.K. Johnson
Posts: 807
Joined: Mon 12 Oct 2009, 17:11

#15 Post by B.K. Johnson »

Mike
Just a thought from one who knows nothing!
/opt is not in your path. You may need to link to /usr/bin which is.
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#16 Post by Mike Walsh »

Hi, B.K.

Yes, I can see why you'd think that; it threw me as well for a while, until I realised that the /usr/bin entry is merely a symbolic link to the /opt/slimjet/flashpeak-slimjet wrapper.....which is what actually gets things going.

Anyway, boys'n'girls, I'm pleased to report SUCCESS. perdido's catch of the wrapper-script generating its own .desktop entries appears to have been the 'fly in the ointment'. I've modified the wrapper-script, by deleting ALL the stuff relating to generating a .desktop entry, plus a load of stuff about GNOME properties, etc; for which there is absolutely no use in Puppy. Having done that, I re-named the Menu entry in the .desktop file that I created (so it reads better, and is actually more relevant); re-packaged as .pet & SFS, and re-tested.

After editing /root/.jwmrc to get rid of the superfluous entries, then re-starting 'X', the un-needed entries were gone. I then did a re-boot to make sure the changes were saved.

-----------------------------------------------------------------------------------------

@nic007; Following your advice, I found that after deletion, running 'fixmenus' and re-starting JWM, the 'ghost entries' were straight back there again! That's why I decided on re-starting 'X', instead.....which seemed to do the trick.

-----------------------------------------------------------------------------------------

Upon installation (.pet or SFS, doesn't matter), for some stupid reason the 'ghost' entries are back in the Menu (these are recognisable as 'FlashPeak SlimJet, with no icon).....but the main thing is that having removed all the .desktop stuff from the wrapper-script, SlimJet will now start from the Menu entry. This is the one thing that had been eluding me. I've given up worrying about the 'ghost' entries; they're quite possibly peculiar to my system, since I've been messing around so much in recent days..!

Anyway, that's got the Slacko .pet & SFS working. I'll boot over into Tahr64, do the necessary construction & testing there, and all things being equal, I'll be re-uploading them this afternoon, so that the links in my SlimJet thread will be active again.

Thanks a bunch everybody. The help was much appreciated; several sets of eyes on a problem often pick up on stuff that a single pair will miss.....'can't see the wood for the trees', etc.

Interestingly, having looked at one of OscarTalks' wrapper-scripts in his 32-bit SlimJet packages, I see he's removed exactly the same stuff that I've ended up getting shot of; so I guess Oscar ran into the same 'glitches' that I did..!

I'll mark this as 'Solved'. Thanks again, people!


Mike. :wink:

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#17 Post by nic007 »

Glad you got it sorted. X server seems to produce "difficulties" with newer pups/kernels. I have Java and Wine sfs add-ons which gets loaded at boot time. Sometimes when I want to run Java or Wine applications in Tahr, Java and/or Wine seems to "die" or "become unresponsive". I then need to restart X to get things going again. Also can't get my laptop to suspend when using Tahr. X shuts down momentarily and then activates again. I'm back using Racy 5.5 where eveything works and no hiccups.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#18 Post by Mike Walsh »

nic007 wrote:Glad you got it sorted. X server seems to produce "difficulties" with newer pups/kernels. I have Java and Wine sfs add-ons which gets loaded at boot time. Sometimes when I want to run Java or Wine applications in Tahr, Java and/or Wine seems to "die" or "become unresponsive". I then need to restart X to get things going again. Also can't get my laptop to suspend when using Tahr. X shuts down momentarily and then activates again. I'm back using Racy 5.5 where eveything works and no hiccups.
Ahhh; Racy 5.5... 'Oldies but goodies...' :lol:

The only reason I started messing about with this 64-bit SlimJet is because I'm a long-time Chrome user. 32-bit Chrome is no more, so 64-bit it is. I found Oscar's SlimJet packages a while ago, and really like it; if it weren't for not supporting NetFlix, I'd give Chrome the heave-ho.....that's a measure of just how much I like it.

But having started looking into the 64-bit Pups (I now run 3 of these, in addition to half-a-dozen assorted 32-bit 'critters'..!), I thought I'd see if I could get the 64-bit SlimJet to run, too.

After all.....why not? :lol:


Mike. :wink:

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#19 Post by perdido »

Mike Walsh wrote: Upon installation (.pet or SFS, doesn't matter), for some stupid reason the 'ghost' entries are back in the Menu (these are recognisable as 'FlashPeak SlimJet, with no icon).....but the main thing is that having removed all the .desktop stuff from the wrapper-script, SlimJet will now start from the Menu entry. This is the one thing that had been eluding me. I've given up worrying about the 'ghost' entries; they're quite possibly peculiar to my system, since I've been messing around so much in recent days..!
That script was checking for the existence of a "slimjet.desktop" file, then creating it if not found. Since the "ghost" entries are still showing up it might be worth a try renaming the desktop file you created to the name of the file it is searching for, may prevent the entries from appearing, may not.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#20 Post by nic007 »

Mike Walsh wrote:
nic007 wrote:Glad you got it sorted. X server seems to produce "difficulties" with newer pups/kernels. I have Java and Wine sfs add-ons which gets loaded at boot time. Sometimes when I want to run Java or Wine applications in Tahr, Java and/or Wine seems to "die" or "become unresponsive". I then need to restart X to get things going again. Also can't get my laptop to suspend when using Tahr. X shuts down momentarily and then activates again. I'm back using Racy 5.5 where eveything works and no hiccups.
Ahhh; Racy 5.5... 'Oldies but goodies...' :lol:

The only reason I started messing about with this 64-bit SlimJet is because I'm a long-time Chrome user. 32-bit Chrome is no more, so 64-bit it is. I found Oscar's SlimJet packages a while ago, and really like it; if it weren't for not supporting NetFlix, I'd give Chrome the heave-ho.....that's a measure of just how much I like it.

But having started looking into the 64-bit Pups (I now run 3 of these, in addition to half-a-dozen assorted 32-bit 'critters'..!), I thought I'd see if I could get the 64-bit SlimJet to run, too.

After all.....why not? :lol:


Mike. :wink:
What I like about Racy is that the kernel is not too old as it supports stuff like xz compression. Also, my Racy base sfs file is 116MB (I re-compressed the standard issue to maximum compression which cut off another 5MB). Quite impressive given the size of the newest puppy's. I guess I have a thing for small puppy's that just works. Racy 5.5 was released in 2013 so not that ancient either.

Post Reply