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

Booting, installing, newbie
Message
Author
musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#141 Post by musher0 »

Hello all.

Please find attached version 0.9.5.4.

This one has significant improvements, I think, in particular at the
presentation level.

New:
-- At first run, it will look for usable settings in your current gtkrc theme
file and use them for your first display. (You can recreate the first run
situation by going to dir. /usr/local/share/MRUF and copying the back-up
template file named "FirstRun.txt" to "FirstRun".)

More details about trying to pick up the colors of the current GTK theme
below, but it works +/- 75 % of the time, which is a significant statistic,
given the diversity of GTK themes and theme engines.

-- A few sub-menus now have information lines, in particular to help the
user distinguish between the images in the mtpaint history and those in
the "recently used" xbel history file. (With EN<->FR translations.)

-- Some subtle, cosmetic changes in the placement of some bullets to
improve the consistency of the look.

-- The script code itself is now down to 16 k (optimization mostly through
the use of internal functions)

-- A splash panel is shown at every update of color theme or history data.

-- The secondary color for the separators is now taken from either the GTK
theme or the provided color schemes. Previously it was static, always
"SeaGreen2".

-- As I explained above to RSH, I am now using the pango's underline
function as separators in the sub-menus and for the time display.

~~~~~~~~~
About the colors, which created some frustration earlier:

There is a new GetGtkTheme script that probes and parses the chosen
(current) GTK theme colors.

Using this script, 75 % of the 96 themes on my Pup load correctly (please
see attached gnumeric test sheet). That said, your results may vary, 'cause
GTK themes are like plants in the jungle, there are so many of them.

The rendition of some of them is pale (not much contrast), but readable,
which enables you to install one of the provided color themes for better
readability.

A few themes will trigger the error panel in the script, but will nevertheless
use your chosen theme colors -- with the foreground and background
colors of the previous theme, however. So again, you have something
readable and you can then go choose a suitable contrasting Color Scheme
from those provided. The samples on that list are colored as they will
appear in your menu.

Finally, in some cases the script just gives you exactly the colors and
contrast you need without you having to do anything. (Wow.)


~~~~~~~~~~~~~~~~~

The experience of the past few days have made me a little less naive about
the intentions of people, so here it is in clear:

-- this is a 32-bit script

-- there have been some reports of strange behavior on the 64-bit TahrPup
after using this script (why TahrPup in particular I do not know; I have had
no problem at all trying to run this script on the JL64-604, which is my 64-
bit Puppy [it simply didn't run; it didn't affect anything in the system])

-- you are expected to have perused the previous pages of this thread
before testing this script

-- you are expected to have some Linux and/or Puppy experience to be able
to test this script properly. Testing is not recommended for newbies.

-- you are expected to test intelligently, with a bit of methodical doubt.

-- yes this script is still experimental (alpha, or whatever you want to call it).
This script is not for production use yet.

-- this thread is a lab for this script

-- like in any lab, you the tester are expected to use due diligence and
"protective gear". In computer terms: backup your Pup OS and data and
computer properly before you start testing this or any new script.


-- I have taken great care in writing and testing this script, and I have run it
through all kinds of situations, but there is an almost infinite variety of
Puppies and hardware out there. Your results may vary.

-- I am only human. :shock: "Errare humanum est." (To err is human.)
Meaning: there are likely still involuntary bugs in there. That's why i'm
putting this script out there, so we can at some point with your help evolve
a script that is as perfect as possible.

-- Moral of this insert: Use at your own risk. I'm sure I forgot a few
items but you get the idea.

-- i almost forgot: I believe in collaboration and in co-operation. If you try
to take advantage of me or to prove me a lesser person because of that, or
to be generally a "free rider", as that's called in the jargon of co-ops:
it will be on you.

~~~~

-- If you encounter problems using this script, please report back with as
many details as possible: that's your part of the deal.

Please be polite in your report and please do not suppose I am out to get
your goat or your computer. I am not and here's why:

Vovchik's aemenu-pango is only a few months old, we are very fortunate
to have a person of such talent on Puppy, and we are all (including me)
gathering information and experience about the use of his new
"typographical features menu" (for lack of a better expression!).

-- Finally, "pango" is part of the Gnome environment; it is not new by any
stretch of the imagination. Nor is aemenu, which has been around for 15
years. But the two together, used in this context: yes, this is new.


~~~~~~~~~~~~
Attached:

-- the script

-- the list of files in this package

-- the list of my GTK themes, with an evaluation of their usability related to
the aemenu-pango (the results of my test, in other words, of my "Get Gtk
Theme" support script)

-- a couple of screen caps, illustrating the three steps to take to make this
history menu as beautiful as can be.

BFN.
~~~~~~~~
P.S. Don't enjoy this version too much, BTW! ;)
Attachments
MRUF-lst-0.9.5.4_OneResult_2016-09-20.jpg
Result: the history menu with the Color Scheme you have chosen.
Look at that contrast! :-)
(35.39 KiB) Downloaded 252 times
MRUF-lst-0.9.5.4_Choose-ColorScheme_2016-09-20.jpg
Step Two. Since the colors are not too hot, you go to the Color Schemes
sub-menu and choose one that provides good contrast and readability for
your history menu.
(36.92 KiB) Downloaded 249 times
MRUF-lst-0.9.5.4_FirstRun_2016-09-20.jpg
Using the Shiki-Dust GTK theme as an example. The &quot;Get GTK Theme&quot; script gives you this as a starting point. (Step One)
(30.66 KiB) Downloaded 250 times
MRUF-lst-0.9.5.4.pet
The script.
(124.07 KiB) Downloaded 252 times
files.tree.lst.zip
The contents of the pet archive that is attached to this post.
(882 Bytes) Downloaded 132 times
GTK-themes-test.gnumeric.zip
Tests results of using the Get GTKTheme script for approx. 96 themes.
(3.37 KiB) Downloaded 141 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#142 Post by bigpup »

musher0,

Too bad you did not start this topic.
All of the above information could be in the first post.
You would also be able to edit that first post at anytime you wanted to.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#143 Post by musher0 »

bigpup wrote:musher0,

Too bad you did not start this topic.
All of the above information could be in the first post.
You would also be able to edit that first post at anytime you wanted to.
Oui, papa! :D ;) (Yes, dad!)

But hey, I'm a creative type. I create first and rationalize things second.

The good thing about the way things are on this thread, people can see
the natural evolution, as opposed to your suggested structure which is
a mental construct, sort of a "before-thought".

Anyway, I agree to disagree with you and you leave me in peace, yes?

Or are you going to hassle me with your idea until Kingdom Come?

Respectfully.
Last edited by musher0 on Wed 21 Sep 2016, 13:25, edited 1 time in total.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

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

#144 Post by MochiMoppel »

LazY Puppy wrote:http://www.murga-linux.com/puppy/viewto ... 769#922769
Screenshot at the end of this post shows recently used programs in JWM menu. Documents is the above entry, directories/folders is entry below in that menu.
OK, this could be what johnywhy had in mind. Hard to tell without seeing it in action.
I tried to understand your description...
Edit:
Btw.: I got something similar to MRUF as a Menu Pipe in JWM. To get those programs to run from that Menu Pipe, the code is analyzing the files in the related "recent-used-lst" and then it changes e.g. Gnu Image Manipulation Program just to gimp, before the code is echoed into the Menu Pipe file (xml) which is then included (<include>) into the /root/.jwmrc file.
...but I'm not sure what you mean by "Menu Pipe" or "recent-used-lst" . Could you please provide the code? Thanks.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#145 Post by musher0 »

Self-censored.
Last edited by musher0 on Wed 21 Sep 2016, 13:49, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#146 Post by LazY Puppy »

RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#147 Post by musher0 »

Got it! Many thanks.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#148 Post by LazY Puppy »

@MochiMoppel

The term "Menu Pipe" was taken from a forum member who had (I think it was stu90, a few years ago) invented a "Menu Pipe" for Openbox WM to have the installed wallpapers present at the openbox menu. That way (after stu90 invented walle, the wallpaper setter/changer) one could change the current wallpaper just by clicking its menu entry in that "Menu Pipe".

I'd used this for years when using LazY Puppy and Openbox.

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).

Did not like JWM very much from the first day I joined the forum. After doing those JWM menu pipes this has changed. Love it! :lol:

The times when musher0 came up (when I discovered this topic) with this here mruf I examined those scripts and found it useful to have also a "Menu Pipe" for recently used programs and directories (the pipe for recently used docs was already there).

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.

I have placed these scripts in /root/my-applications/bin/jwm-menu-pipes

Oh, and recently-used-lst is some sort of a typo for recently-used.xbel. Sorry for that.
Attachments
jwm-menu-pipes.tar.gz
Do yourself a favor and do NOT test this with the your favorite save file.
(32.24 KiB) Downloaded 266 times
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#149 Post by musher0 »

MRUF-lst-0.9.5.4-64 first test, on JustLightHouse64-604: basically works! :)

However the support executable called "bcm" also needs to be compiled for
64-bit. That's why we see funny characters instead of bullets, I think.

Attached: LP's compile of aemenu-pango64, zipped, & screen cap.

BFN
Attachments
aemenu-pango64.zip
(31.22 KiB) Downloaded 143 times
image-1.jpg
MRUF-lst-0.9.5.4-64, first test, on JustLightHouse64-604
(36.49 KiB) Downloaded 170 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Puppus Dogfellow
Posts: 1667
Joined: Tue 08 Jan 2013, 01:39
Location: nyc

#150 Post by Puppus Dogfellow »

musher0 wrote: 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".

puppus dogfellow wrote:
(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.

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

#151 Post by 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.
[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]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#152 Post by 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
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#153 Post by musher0 »

Puppus Dogfellow wrote:
musher0 wrote: 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".
puppus dogfellow wrote:
(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.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

mfb

#154 Post by 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!"
Attachments
ASDextracts.htm.gz
(50.76 KiB) Downloaded 298 times

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#155 Post by LazY Puppy »

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

Fake .gz.
Attachments
replaceit.gz
(13.25 KiB) Downloaded 193 times
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#156 Post by musher0 »

Thanks, RSH.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#157 Post by MochiMoppel »

LazY Puppy wrote: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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#158 Post by musher0 »

Hello MochiMoppei.

You say:
MochiMoppel wrote:(...)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.)
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#159 Post by 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!!! :D :lol:

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:
T.O.P.L.E.S.S. Environment Variables wrote: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! :roll:

LOVE IT, LOVE IT, LOVE IT !!! :D :lol: :D :lol: :D :lol:
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#160 Post by MochiMoppel »

LazY Puppy wrote: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 :cry:
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 :lol:

Post Reply