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

[musher0]

@Lazy Puppy:

Have you read vovhick's reply in the Hacked aemenu thread about a 64-
bit aemenu-pango? I have put the link above.

I understand from his message that he is not equipped for 64-bit
compiling at this time.

You can easily enough find the entire aewm package for 64-bit. (aemenu
is part of the aewm package, but can be used separately.) For ex., here:
https://pkgs.org/debian-jessie/debian-m ... 4.deb.html

But only vovchik has the recipe to turn the regular aemenu into
aemenu-pango!

BFN.

[LazY Puppy]

Yes, I had read this already.

I hoped he would attach the glibconfig.h, though it probably doesn't make sense as it may differ from the version for 64bit.

I would like to compile but no chance without that .h file.

Probably there's some more .h files missing in devx's of 64bit puppies.

At least Slacko64 630 is missing it too.

Users needs the firmware, developers needs the .h files - anything else is crap.

Puppy turns more and more into crap lately rather than evolving to a true USER's OS.

Windows users stuck on the double click (disaster) and Puppy developers stuck an SMALL SMALL SMALL SAVEFILE SAVEFILE SAVEFILE (folder).

Puppy's FUN FUN FUN FUN FUN FUN FUN FUN is decreasing.

[LazY Puppy]

Checked the devx's of

- lucid 528-4
- precise 571
- tahr 602, 605
- tahr64 605
- vivid beta2
- unicorn 60
- xenial 704
- xenial64 707
- slacko64 630

All of them are missing the glibconfig.h !!!

I wonder how vovchick could compile...

[musher0]

Hello, Lazy Puppy.

FYI: Using vovchik's source directory, I just tried the same compile as
you on JL64-604 and got the same error message about that
glib-bla-bla.h file missing.

Also I had the error message that the .pc package file pango.pc was
missing. Is this particular to JL64-604? Ot did you get that error
message also?

However I got aewm's aedesk and aesession secondary files compiled in
64-bit using simply the usual < make > command.

Moral of this story: a 64 version is possible. But no aemenu-pango-64
yet, ha-ha. (Strum big guitar or hit big piano chord on the last "ha"!)

BFN.

[musher0]

Another ha-ha, this one with "eureka" meaning!

http://www.ask.com/web?qsrc=1&o=0&l=dir ... archTopBox

See the first two entries.

(Stop complaining about Puppy being less and less fun!
The Ubuntu people have the problem too!!! )

BFN.

[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. "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!

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

[musher0]

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! (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.

[MochiMoppel]

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]

Self-censored.

[LazY Puppy]

The aemenu binary compiled in tahr64 605

[musher0]

Got it! Many thanks.

[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!

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.

[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

[Puppus Dogfellow]

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.

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