How to show MRU Most Recently Used Documents on Start Menu?

[B.K. Johnson]

musher0
I'm surprised that you would view my post as "blaming your script" and ask:

Anything else you want to blame my script with?

Nobody is trying to get you; certainly not me.
You write software. You know there can be bugs within. You even go so far as to warn people that it is development software. You warn that we should back up our O/S. Why, because you know that anything can happen. So, why this jumping on everyone who suggests that something weird and unwanted occurred with the use of your software? You don't/can't write infallible code. Why did you put it out there? To get plaudits, only? Didn't you not want it tested? Reporting problems, legitimate or perceived is a given. It's part of the cross you bear as a developer.

Don't you think that having installed MRUF-lst and seen a similar outcome to one of undetermined source, that a connection can be reasonably assumed? And if the outcome is removed when MRUF-lst is uninstalled, does that not increase the probability of that assumption being true? Yet I did not claim that MRUF-list was responsible for the first occurrence. I thought as a developer you would have grabbed the offer I gave you to test. But you have become so irrational that you can't see the forest for the trees.

yes you can use the
following lines to restore the pristine xdg-open and defaulthandler files
from your main Puppy sfs -- if you feel that my script is the source of
all woes in your computer life at present:

This is really unnecessary and uncalled for, musher0. Not all my woes. I don't even know if it is related to the problem reported in the other thread. But what I do know is that in a second puppy I installed a different version of MRUF-lst and icons became lost from my notification area. I uninstalled your software and the icons returned. Now tell us, what conclusion would you draw? What course of action as a developer do you pursue? Kill the messenger? At the very least if you are rational, wouldn't you consider it strange? That's what I thought. I didn't go to the other thread broadcasting that it was your software that messed up my system. No! I came to your thread and calmly described my observation. Description. Not complaint. No harangue. I even offered to help you test it. Your irrationality so blinds you that the possibility of me removing your software completely irks you. musher0, I have a problem I want fixed; what would you have me do? The software is old - you are up to v0.9.5.4; what's installed can't be removed normally - not listed in PPMs Uninstall list. What would you do? Me? I'd find a way to purge it completely. That's what I am doing. Nothing personal.

Thanks for the MRUF-lst-0.9.3 tree. It will help but are you saying that you are unaware of the source of aemenu-panel, vov-menu, vovrc, wttr.EN.lst, wttr.EN-vov.lst, replaceit, bcm. You don't recognize your own creations: MenuDefautPlus.sh, MenuDefautPlus.sh.cdr, MenuDefaut.sh? Limiting your info to just your MRUF-lst is clearly small-minded. With your attitude to test results, I am not inclined to test/use this or any other program by you. I said inclined.

Take a break musher0.

[musher0]

B.K. Johnson:

As I said to other posters in this thread and elsewhere: if you do not feel
comfortable using any of my scripts, do not use them, un-install them.

If you have a problem with the PPM in one particular Puppy, please go to
one of the PPM developers? It has nothing to do with this MRUF script.

As to the other programs and scripts you mentioned in your "before-last"
post, I did recognize some of the titles (the prefix "vov" is typical of some
of vovchik's work, for ex.), also my work on two other projects.

However, I felt that that post of yours was bundling all scripts closely or
remotely related to the aemenu-pango. Since that -- and your turn of
phrase -- made it sound somewhat tendentious IMO, I limited the scope
of my reply to the subject of this thread, namely the MRUF script, so
the discussion would not go all over the place.

I hoped that perhaps you would do a "transfer of knowledge" and apply
what I was telling you about the MRUF script to those other projects.

If you feel that some sentences of my reply were uncalled for, please
realize that freedoms of thought and expression also apply to developers.
Developers have feelings too.

Within limits recognized by general society, developers -- like anybody
else -- have the right to think what they think the other person said.

Finally, you probably do not realize how insulting the last sentences in
your last paragraph in that post. Have someone read it to you as if you
were the developer, and you'll feel it.

For that reason, this "small-minded" person has no further comment for
you at this time.

Respectfully.

[musher0]

Posted: Yesterday, at 00:50 Post subject:
Hello Puppus.

I thank you for the description you have provided.

And I consider you a friend. You have contributed an icon to this script,
and we had a couple of interesting and friendly exchanges in the past.

So please do not take the following the wrong way.

-- I find it strange that you are using my slocate wrapper when you don't
appear to be comfortable with it. I would never use a script or program
that I am not comfortable with.

I've been using that slocate script every day since I produced it without
problems. It does slow down some processes when it's active, only for
what, a minute?, every three hours, if I am working on the same drive
that it's indexing, it seems. I find that I can live with that inconvenience
given the benefit of having my computer files indexed and searchable at
a moment's notice.

Also, are you saying that my slocate wrapper is working OOTB on a
64-bit Puppy?

OOTB (but with a 64 bit slocate) in xenial 707 and 64 bit tahr. just a tweak to chill the indexing so it less frequently makes me "uncomfortable." it's a useful script and i include it in my Ultimatesque Utilities Pack/UUord Processor because, when not interfering with ongoing processes (which it's set to do somewhat rarely and i set it do even less frequently via the comment sections you provided), it's a huge time saver.

fwiw, it makes my most loaded machine noticeably slower for at least five to ten minutes--i'd prefer hte updating entirely unautomated, but generally just leave the machine or move to less taxing things if it's a problem. anyway, iirc, an older slacko64 needed a symlink in /var or something, but it does appear to work OOTB in tahr64 605 and xenial64 707

____

-- What made you --or anyone -- believe that what has been a 32-bit
script from its beginning five years ago could run on any 64-bit Puppy at
this time? Besides, it is not uncommon even on 32-bit Puppies that a
certain app or script will run on this Puppy but not on that other one.

Again, forgive me if I sound dumb, but I really do not understand this
"quasi-demand" all of a sudden (to me it seems so) from a number of
persons on this thread that a script developed on 32-bit Puppies off and
on for the past five years should have to run without fail on any 64-bit
Puppy.

I do not want to get in a fight with you, I want to preserve good
camaraderie. Also I know that you are sincere.

Thanks in advance for any "enlightenment".

(haven't tested in 32bit but that appears to be sorted out. new menu in one of the last screenies looks good and clear to my eyes).

LazyPuppy, you, and ASD were in the middle of discussing whether or not it worked in 64 bit. i tested in an effort to shed some light and share some results. interpreting it as a quasi-demand seems disingenuous to me, but yes, i'd like to remain on friendly terms with you, mon ami (i realize you felt put upon and were in defensive mode. no sweat). yes, it sometimes happens that one pup can run a thing and another can't--it's why we encourage testing. the "without fail part" again seems a bit out of place--it should run and run well. there didn't appear to be much going on that was 64bit dependent as far as what the script was asking the machine to do, but again, i think you know why the 64 bit version was tested. sensing it would give ASD ammo, so to speak, i refrained from mentioning why i thought something was off in the delay and why i thought there was a problem beyond the crawling of the machine, but since he's been booted, at least for a bit--Mochi's script is quick and pops up without delay and works in 64 bit and does many of the same things--it was my control group, so to speak. i benchmarked yours against his, or at least experience with his utility wasn't something i could remove from my mind while looking over yours.

Hello all.

If those of you with experience in this would have any ideas, impressions,
criticisms, about the following draft? It probes the current GTK theme and
tries to apply two colors to the aemenu-pango menu.

users chose their gtk themes--maybe just extend the choice in full to the aemenu?

fwiw, i didn't participate in this thread to give you grief, musher.

Hi Puppus.

Yeah, ASD was pushing me in a corner and I fought back. Thanks for your
understanding.

ASD did have a point (which I'll summarize as:"Why no 64-bit version?"),
except he was jumping the gun (in view of previous development), plus
he could have asked his question in a civil manner instead of hectoring.

A 64-bit version is posing a few challenges:
-- the inventor of aemenu-pango, vovchik, is not equipped with a 64-bit
computer (as I understand it), so someone else has to step in to compile
(thanks to Lazy Puppy for that)

-- finding or compiling a 64-bit version of support executable "bcm" for
aemenu-pango

-- same for the "replaceit" utility, used here and there in the script.

About the "Gtk-theme probe" script: I think i have it down pat now. At
least for +/- 75% of the themes; given the great variety of GTK themes
and theme engines out there, I don't think I can push the probe script
beyond that mark without making it huge.

Anyway, good to have you around, Puppus.

TWYL.

[mfb]

ASD sends you the facts (rename the attached file deleting ".gz"):

EDIT: It is now suggested that this thread be moved into the "Truly off-topic" section and that musher0 start a new thread [or amend his current alternative thread] with his latest version; because in the words of the best sermon, the shortest sermon and the only one I ever remember (from more than half a century ago):
"There are things temporal and there are things eternal".

PS 99 posts from him plus 1 from me is more than enough so:
"That's all Folks!"

[LazY Puppy]

Replace it for 64bit, compiled in tahr64 602 already in July 2015.

Fake .gz.

[musher0]

Thanks, RSH.

[MochiMoppel]

Later I examined this script and created "Menu Pipes" for almost all of my external files, scripts, roxapps, wine portables and many more for the use in Openbox and much later also for the use in JWM. I found it a bit more comfortable that JWM is not updating those "Menu Pipes" each time when entering the menu (as the original for openbox does).

I always found the fact that JWM can't update its menus when the user enters the menu a big disadvantage. That's why I said in my first post that adding the recently used files list to the JWM menu has become only possible with the introduction of dynamic menus. I assume that your dislike for openbox's approach has something to do with processing time

I could provide the complete package which is around 30 scripts, though I doubt it would work out of the box in any else Puppy apart from a T.O.P.L.E.S.S. made Puppy Linux. Though you could at least examine the code

Thanks for the files. That's a lot of stuff.

I only looked at the files create-recently-used-jwm-submenu and update-jwm-menu-pipe. As you already said they are so much embedded in your T.O.P.L.E.S.S. framework that it would be an enormous work to turn them into standalone scripts.

So the basic concept is to create submenus and use <include> to combine them with the main menu, right? This must pose the same problem as seen in musher0's script: It needs a periodical update, or - in other words - the menu is not up-to-date between the refresh cycles. As a user I would find this irritating. Question: You commented out jwm -reload , which I would expect to work, and instead you use fixmenus, which I would not expect to work. Why?

You limit the UTF-8 decoding to a few "foreign" characters. What happens when a character can't be decoded? Skip the file from the list or show the encoded string?

[musher0]

Hello MochiMoppei.

You say:

(...)This must pose the same problem as seen in musher0's script:
It needs a periodical update, or - in other words - the menu is not
up-to-date between the refresh cycles. As a user I would find this
irritating. (...)

If I may: -- I don't know if this is possible from within jwm, but in an
aemenu script, it is possible to monitor the time flag or the size flag
on the main "xbel" file -- or some other file.

This is not a new technique. It was used by MU (Mark Ulrich) many
years ago to evaluate if the menu of one of his icewm "Muppies" (IIRC)
needed to be refreshed.

I plan to introduce something of the like in this MRUF script.

Indeed, a stale menu is irritating for the user, but if the user has to
wait 4-5 seconds every time the menu refreshes, that too (s)he will find
irritating. So perhaps MU had found a middle ground: update the menu
only when it needs updating.

A thought among so many others! BFN.
~~~~~~~~~~~
Edit -- Something like this at the top:

Code: Select all

	if [ ! -f $corps -o "`grep -ow ${LANG%_*} /tmp/en-tete`" = "" -o "`ls -Algo $XBelChecK | awk '{ print $3 }'`" != "`cat $MRUFrep/XbelSize`" -o "`ls -AlgoH /usr/local/bin/MRUF-lst | awk '{ print $3 }'`" != "`cat $MRUFrep/ScriptSize`" ];then 
# Menu existence, which language, freshness and script editing detection.

Line above has to correspond to something like this at the bottom,
just before the menu display is called:

Code: Select all

		ls -Algo $XBelChecK | awk '{ print $3 }' > $MRUFrep/XbelSize # New size stamp for xbel
		ls -AlgoH /usr/local/bin/MRUF-lst | awk '{ print $3 }' > $MRUFrep/ScriptSize # New size stamp for this script
		wait ### Fin du / End of / menu
	fi
###
	cat /tmp/en-tete $corps > /tmp/recents # Action
	aemenu-pango -rc /tmp/recents 2>/dev/null ;; # Affichage

(Note -- If menu exists should be obvious; $LANG to use is ID'd
near the top of the script.)

[LazY Puppy]

I assume that your dislike for openbox's approach has something to do with processing time

Yes.

It is a huge delay before the menu appears.

If there are only a few wallpapers, it is quick, though, I have 937 Scripts in my Scripts directory that goes into the menu pipe. Plus RoxApps, Portable Linux Apps, Portable Windows Apps and Windows Install files - each one has its own menu pipe.

Last but not least all files in my external files directory got a menu pipe too. This is 42,927 files. Plus everything stored on my parallelpartition 1 & 2 (sde1 boot, sde2 & sde3) goes into a menu pipe.

Code: Select all

# Store recently used list extern
JWMPIPESDIR="$MYBOOTDIR/.jwm-menu-pipes"

This means: the xml files for the menu pipes are stored in a sub-directory at my boot directory (or install dir) - which gives a delay too.

Also JWM has a delay on that huge amount of entries in its .jwm.rc file. Though, just once, when X desktop appears it takes a few seconds until the taskbar contains all items visible.

However: LOVE IT!!!

So the basic concept is to create submenus and use <include> to combine them with the main menu, right?

Absolutely right!

You commented out jwm -reload , which I would expect to work, and instead you use fixmenus, which I would not expect to work. Why?

I'm using a modified fixmenus in T.O.P.L.E.S.S. that is loaded to a top layer by .sfs module. This one is calling jwm -reload after its mostly original code for jwm is executed. Found it much more comfortable.

You limit the UTF-8 decoding to a few "foreign" characters. What happens when a character can't be decoded?

No, I didn't.

Most code of the create-recently-used-jwm-submenu scripts are copied from another script I found long ago. Can't remember where and when.

As you already said they are so much embedded in your T.O.P.L.E.S.S. framework that it would be an enormous work to turn them into standalone scripts.

Absolutely true.

As shown above e.g. $MYBOOTDIR is a global environment variable only available in a T.O.P.L.E.S.S. made puppy. There are lots of them that being used in many T.O.P.L.E.S.S. scripts.

Overview:

root# $MY
$MYAKINTERN $MYFILES $MYMPLASTUSED $MYSARASCRIPTBOX
$MYAKLINUX $MYFREEMEMPARTITIONS $MYMPLINUX $MYSCRIPTS
$MYAKROXAPPS $MYIMAGEMAGICKSFS $MYMPROXAPPS $MYSDGSETDIR
$MYAKRUNSCRIPTS $MYIMAGICKSFS $MYMPRUNSCRIPTS $MYSETTINGSDIR
$MYAKSCRIPTS $MYINTCONFIGFILE $MYMPSARABSCRIPTS $MYSFSPLUSSETDIR
$MYAKWINEPORTABLE $MYJDKSFS $MYMPSCRIPTS $MYSFSPSETDIR
$MYASETDIR $MYJRESFS $MYMPWALLPAPERS $MYSHUTDOWNGUISETDIR
$MYAUTOSETTINGSDIR $MYLAZYREMASTERSETDIR $MYMPWINEINSTALL $MYSYMLINKSTARGET
$MYBOOTDIR $MYLAZYRSETDIR $MYMPWINEPORTABLE $MYTRASHDIR
$MYBOOTPRT $MYLINUXAPPS $MYPAR1PRT $MYVARIOMENUSETDIR
$MYCLIPBOARDDIR $MYLP5PREFSDIR $MYPAR2PRT $MYVMSETDIR
$MYCORELDRAW $MYLPED $MYPCONFEXT $MYWINDOWMANAGERSFS
$MYCORELDREAM3D $MYLPEDPREFIX $MYPCONFIG $MYWINEAPPS
$MYCORELPHOTOPAINT $MYMODULES $MYPCONFINT $MYWINEAPPSSTARTER
$MYCORELSCRIPT $MYMODULES2 $MYPIKONAPRG $MYWINEINSTALLS
$MYDASHBOARDSETDIR $MYMPALL $MYPSLDIR $MYWINESFS
$MYDBSETDIR $MYMPBOOKMARKS $MYROXAPPS $MYXPADSSETDIR
$MYEXTCONFIGFILE $MYMPDRIVES $MYRSHROXAPPS $MYXPSETDIR
$MYEXTERNALRUNSCRIPTS $MYMPFAVORITES $MYRSHSCRIPTBOX
$MYEXTERNALSFSPLUSSCRIPTS $MYMPFILES $MYSARARSD
root# $MY

E.g. using $MYMODULES in a script at current running system will be:/mnt/sde1/Module
I think I had stated it somewhere before publishing the first version of T.O.P.L.E.S.S., that my further and future puppy developments will be developed and run/work only in the T.O.P.L.E.S.S. context.

You should try to install LazY Puppy 5 to a usb flash drive as per its installer script. Do a symbolic link Module to Modules after installation is finished. Boot it and examine the stuff to be found in /initrd/pup_rw.

I recommend to examine file /etc/profile.local wherein everything is executed that will boot a plain puppy as T.O.P.L.E.S.S. LazY Puppy 5. The stuff to create this file is to be found inside the initrd.gz (the only thingy that is modified by the T.O.P.L.E.S.S. RoxApp.

If you got it running open a terminal and enter: psl_

Then hit key tab two times. This will show you the global functions of the T.O.P.L.E.S.S. Puppy Scripting Library.

Just a side not for automated update of JWM's menus:

I experienced destroyed/incomplete menus when using fixmenus & and trying to enter the jwm menu while fixmenus was still executing.

Of course one could use a script running in background to refresh jwm periodically, though with an amount of appr. 50,000 files in its menu pipes, one will have the delay periodically also.

Not good, bad and irritating. Much more irritating than to learn to refresh the menu pipes manually from time to time. My content of scripts, roxapps etc.pp doesn't change that often, so I just refresh those for the files only from time to time.

Btw. the menu pipes in my packege are "intelligent" and "smart" thanks to T.O.P.L.E.S.S..

As stated they are stored in a sub-directory of boot directory, so the may have /mnt/sde1 as paths defined.

Next Time I'm booting and the boot partition appears as e.g. /mnt/sdb1, all menu pipes are refreshed automatically to keep them portable AND usable from being portable. Of course, it takes a few seconds more then.

Sorry, can't resist!

LOVE IT, LOVE IT, LOVE IT !!!

[MochiMoppel]

I have 937 Scripts in my Scripts directory that goes into the menu pipe. Plus RoxApps, Portable Linux Apps, Portable Windows Apps and Windows Install files - each one has its own menu pipe.

This is extremely abnormal and judging from your screenshot your start menu is heavily customized. For any "normal" user with a fairly normal main menu a handful of scripts should not delay menu generation, not in openbox and not in JWM.

I'm using a modified fixmenus in T.O.P.L.E.S.S. that is loaded to a top layer by .sfs module. This one is calling jwm -reload after its mostly original code for jwm is executed.

OK, understood.

You limit the UTF-8 decoding to a few "foreign" characters. What happens when a character can't be decoded?

No, I didn't.

Yes, you do. You translate 96 characters of the Unicode's "Basic Latin" code block. That's a tiny fraction of possible characters. No Cyrillic, no Greek and .... no Japanese

Just a side not for automated update of JWM's menus:

I experienced destroyed/incomplete menus when using fixmenus & and trying to enter the jwm menu while fixmenus was still executing

Hmmm...should be completely independent, but if you refer to your customized fixmenus then it sounds credible

[LazY Puppy]

Hmm, I did?

Can't remember.

Can you show me what you meant by 96 characters?

This is extremely abnormal and judging from your screenshot your start menu is heavily customized.

Yes, for the average user it is.

Though, it is not for me, as I'm heavily developing stuff and I want to have immediate access to all progs and files.

[musher0]

@all:

I have updated my first post in this script (3rd post on page 1) to inform the
potential user that development is on-going and that there is a much newer
MRUF script available.

For the record, I would also like to point out that OP "johnywhy" asked for
a possible integration of the MRUD's to "his Puppy menu". We readers may
infer that it is a jwm menu, but "johnywhy" did not specify the WM.

BFN

[MochiMoppel]

Hmm, I did?
Can't remember.

No need to remember anything, a look into your script is sufficient
File create-recently-used-jwm-submenu, starting line 63:

Code: Select all

# The following lines to translate UTF-8 XML code to regular accented characters; 
# you may comment these lines if you are using only English.
# Traduction du codage XML pour les accents. 
$R "%C2%A0" " " 
$R "%C2%A1" "¡"
$R "%C2%A2" "¢"
$R "%C2%A3" "£"
$R "%C2%A4" "¤"
$R "%C2%A5" "¥"
$R "%C2%A6" "¦"
$R "%C2%A7" "§"
$R "%C2%A8" "¨"
$R "%C2%A9" "©"
$R "%C2%AA" "ª"
$R "%C2%AB" "«"
$R "%C2%AC" "¬"
$R "%C2%AD" " " 
$R "%C2%/recently-used-files-array" "®"
$R "%C2%AF" "¯"
$R "%C2%B0" "°"
$R "%C2%B1" "±"
$R "%C2%B2" "²"
$R "%C2%B3" "³"
$R "%C2%B4" "´"
$R "%C2%B5" "µ"
$R "%C2%B6" "¶"
$R "%C2%B7" "·"
$R "%C2%B8" "¸"
$R "%C2%B9" "¹"
$R "%C2%BA" "º"
$R "%C2%BB" "»"
$R "%C2%BC" "¼"
$R "%C2%BD" "½"
$R "%C2%BE" "¾"
$R "%C2%BF" "¿"
$R "%C3%80" "À"
$R "%C3%81" "

[musher0]

Ahem.
That comes verbatim from my 2nd or 3rd version of the MRUF, I think...
RSH kept the comments in French, too! Typos and all! (hehe)
I'm flattered!

@Lazy Puppy:
At the time, I thought those foreign characters conversions were
necessary, but experience has proven that in fact they are not needed.

IHTH.

[musher0]

Hello all.

To hold my end of the bargain and convince people that this organic
discussion about building a MRUF/MRUD sub-menu in the start menu
IS in line with the question of the OP (q.v., BTW):

Lazy Puppy has his own way of doing things in his "T.O.P.L.E.S.S."
Puppy, I'm sure.
~~~~~~~~~~~~~~
Edit, late evening, Sept. 23 2016:
(Please see his posts above.)

As well, MochiMoppei is now offering another option for integrating
a MRUF sub-menu to jwm >= v.2.3.
~~~~~~~~~~~~~~

But here's how to integrate my MRUF script into jwm's menu:

• Open a terminal
  Open the jwm menu template by typing:

  Code: Select all

  geany /etc/xdg/templates/_root_.jwmrc &

  Search for the entry "Help"; there is a "separator" right over it.
  Make a line space between the separator and the "Help" entry.
  In this new space, on this new line, copy and paste this line:

  Code: Select all

  <Program label="M.R.U.F." icon="/usr/local/share/pixmaps/mrudicon2-48x-trnsprnt.png">exec /usr/local/bin/MRUF-lst-0.9.5.4.sh</Program>

  Save the document.
  Exit geany
  
  You're still in terminal, so type

  Code: Select all

  fixmenus;jwm -restart

When the update is finished, right-click on any empty part of the screen,
and you should now see the MRUF sub-menu entry just above the Help
entry (see attached picture).

Done. IHTH

[musher0]

To integrate my MRUF script in the wmx menu,

• open a terminal
  type

  Code: Select all

  rox ~/.wmx /usr/local/bin

  drag the script MRUF-lst-0.9.5.4.sh from the /usr/local/bin directory
  to the /root/.wmx directory as an absolute link. (See attached picture.)

That's it.

Middle-click and you can now see the new MRUF entry in the wmx menu.
(Please see 2nd picture.)

BFN.

[musher0]

To incorporate the MRUF script in the icewm menu:

• open a terminal
  type

  Code: Select all

  geany /etc/xdg/templates/_root_.icewm_menu

  Go to the "Help" line; there's a separator above it.
  Create a line space between those two lines.
  In that line space, copy and paste the following line:

  Code: Select all

  prog "M.R.U.D" "/usr/local/share/pixmaps/mrudicon2-48x.png" MRUF-lst

  Save.
  Exit geany.

You're still in terminal, so type

Code: Select all

restartwm

icewm recycles and you're done.

IHTH

[LazY Puppy]

Ahem.
That comes verbatim from my 2nd or 3rd version of the MRUF, I think...
RSH kept the comments in French, too! Typos and all! (hehe)
I'm flattered!

No, I don't think so.

The original file I copied the shown section from is locally existing at least from the middle of 2014. I had this already built into L.A.S.S.I.E. 003, which I never published as I started T.O.P.L.E.S.S. before finishing L.A.S.S.I.E. 003.

And again: no, I did NOT change anything on that part of the original file.

Sorry, I can't remember correctly, though L.A.S.S.I.E. 002 was published at April 02 2014. Right after that I started development of L.A.S.S.I.E. 003 and began to include my menu pipes from openbox ready made for JWM. So I think I have its original file at least since the middle of 2014.

And yes, I kept the comments and the typos, as I was informed once by PM about some bashing of my person in my back by others using PM's, because I'd removed some comments sometimes from some code parts using in my earlier scripts and developments. There was also some bashing in may back when I changed my user name to LazY Puppy, as most people just did not notice, it's still just me: RSH.

Edit:

Sorry, found out right now, musher0 has made his first post in this here topic at Thu 11 Oct 2012. So, it could be possible that the original file was indeed from musher0! I just wasn't aware of this date.

And a few posts below that post from musher0 there is stu91 (which is originally stu90, mentioning und using the term menu pipe (openbox). Funny!

[Semme]

Hey, I'm starting a JohnyWhy hate club. Who's in? :mrgreen:

[musher0]

Ahem.
That comes verbatim from my 2nd or 3rd version of the MRUF, I think...
RSH kept the comments in French, too! Typos and all! (hehe)
I'm flattered!

No, I don't think so.

The original file I copied the shown section from is locally existing at least from the middle of 2014. I had this already built into L.A.S.S.I.E. 003, which I never published as I started T.O.P.L.E.S.S. before finishing L.A.S.S.I.E. 003.

And again: no, I did NOT change anything on that part of the original file.

Sorry, I can't remember correctly, though L.A.S.S.I.E. 002 was published at April 02 2014. Right after that I started development of L.A.S.S.I.E. 003 and began to include my menu pipes from openbox ready made for JWM. So I think I have its original file at least since the middle of 2014.

And yes, I kept the comments and the typos, as I was informed once by PM about some bashing of my person in my back by others using PM's, because I'd removed some comments sometimes from some code parts using in my earlier scripts and developments. There was also some bashing in may back when I changed my user name to LazY Puppy, as most people just did not notice, it's still just me: RSH.

Edit:

Sorry, found out right now, musher0 has made his first post in this here topic at Thu 11 Oct 2012. So, it could be possible that the original file was indeed from musher0! I just wasn't aware of this date.

And a few posts below that post from musher0 there is stu91 (which is originally stu90, mentioning und using the term menu pipe (openbox). Funny!

Please see here? (4 Nov. 2012) I had previously taken it from this site.

It does not matter to me anyway, this material is General Public Licence.
It's meant to be incorporated in apple or raspberry pies, eaten with
spaghettis, sprinkled on salads, dissolved in couscous or rice, etc., etc.

My point is: later I discovered that those conversions were unnecessary.

BFN.