Is there another way to set wallpaper for the Rox desktop?

[Nathan F]

btw, can ROX not scale its own damn background images? (rather than using Puppy's scaling hack)

??? It scales it's background images just fine. Four modes, either Stretch Scale Centre or Tile. All behave similar to other tools that set backgrounds.

[sunburnt]

Nathan; There`s that damn "can`t control the thing" problem again.
Right click menus are one of my biggest gripes. no control over it.
Same as click to open has no standard either it seems, along with...

I`m thinking that FreeDesktop.org should have conventions for this stuff.
I don`t know if Puppy uses it for running default apps.
File lists are okay, but they`re a pain to maintain, and no common support.

Just like /usr/share/applications/*.desktop files, a default dir. with links
pointing to the desktop files is easy for any Linux desktop to support.
And a GUI to add, delete, and rearrange them would be a snap also.

Dirs. with links or scripts ( mostly links, apps should have their own scripts )
is a good way to setup lots of the boot stuff, GUI app. menus, and even mime.
This just needs to become a standard supported by the main stream Linuxes.
.

[technosaurus]

Nathan; There`s that damn "can`t control the thing" problem again.
Right click menus are one of my biggest gripes. no control over it.
Same as click to open has no standard either it seems, along with...

I`m thinking that FreeDesktop.org should have conventions for this stuff.
I don`t know if Puppy uses it for running default apps.
File lists are okay, but they`re a pain to maintain, and no common support.

Just like /usr/share/applications/*.desktop files, a default dir. with links
pointing to the desktop files is easy for any Linux desktop to support.
And a GUI to add, delete, and rearrange them would be a snap also.

Dirs. with links or scripts ( mostly links, apps should have their own scripts )
is a good way to setup lots of the boot stuff, GUI app. menus, and even mime.
This just needs to become a standard supported by the main stream Linuxes.
.

yes there are standards,
http://standards.freedesktop.org/autost ... atest.html
and
http://standards.freedesktop.org/deskto ... atest.html
the desktop entry spec is a key point for me, Puppy packagers have a tendency to strip "unnecessary" stuff out of them like localization and specifically MimeType, because if puppy left thos in I could have written an automatic default app chooser a long time ago
as for dirs with links/scripts see the contents of ~/Desktop from other file managers (it would be easy to write a wrapper to handle this - I actually did it for jwm using psuedo-icons ... actually just bunch of individual trays)

btw, geany uses simple gtkbuilder UI for the toolbar:
http://git.geany.org/geany/tree/data/ui_toolbar.xml
and now rox uses gtkbuilder too, so...

[sunburnt]

Yes, but are the standards list based, or are they dir. like /usr/share/applications

As I say, to hell with lists, use dirs. for everything.!

[Nathan F]

Those particular specs are fairly directory based. However, most DE's still fall back to lists for mime-handling for whatever reason, which is clearly counterproductive if you want to adhere to a single spec.

So inside ~/.local/share/applications you'll usually find defaults.list, mimeapps.list, and mimeinfo.cache created by whatever apps want them.

My most vehement objection to this mechanism is the behavior of browsers like Firefox and Chrome, which ask to be set as the default "Browser" and then proceed to register themselves as the default for filetypes like XML and also ftp links. This is a BUG. If I have a filemanager installed that understands how to connect to an ftp site, I don't want to click on an ftp link only to have Firefox open, for instance. Similarly, if I click on an XML file I usually want to edit it in a text editor. It's especially annoying because the only way to override it is to edit the text files in most cases. These apps should only register themselves to handle http and https hyperlinks.

This is the only real benefit to ROX-Filer maintaining it's own mime handling is that it is thus immune to problems like that.

The problem with doing away with the lists is that the user then can't set preferred apps at all under the current scheme. This occurred a few years ago in Gnome when people installed xfce alongside. Gnome Panel only cared about the .desktop files. Whenever someone opened something from the places menu in Gnome it would then open in Thunor, due to the Thunor devs capitalizing the .desktop file and the Nautilus devs leaving theirs lower case. Freaking obscure and stupid. And the only way to fix it was to rename the .desktop file, which required root privileges. A number of distros fixed it for their users, but anyone who did source installs or ran the software "vanilla", like I did because at the time I was running FreeBSD and compiling from ports, got very annoyed.

So yeah, the situation can easily become a mess in it's current state whether or not the mime lists are used.

[sunburnt]

My thoughts exactly, just like right-click menus, we need more control.!!!

Rox has the same thought it seems, A mime list is std., a dir. takes control.
Although a mime list in a different place does the same thing ( Rox )...

I`ve written scripts for replacing values in text lists, but there`s no std. for it.
Editing list is harder than making, renaming, and deleting links and files.
Frankly a list`s preferred, but with no common std. and hijacking by apps...
Files and links can be R-O and/or owned by root, so apps. can`t hijack it.

[musher0]

Hello, all.

Editing the mtpaint configuration will give you a simple, alternative, but effective
way to set the ROX backdrop.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tutorial: Using mtpaint as
backdrop lister, editor and setter:
re-working the configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A) Preparation
Launch mtpaint;

Click on file -> actions -> settings;

Go to bottom of list;

Click on empty line at bottom;

Type, in "action": "Set as wallpaper" ;

Type, in "command": "/usr/local/apps/Wallpaper/set_bg %f" ;

Move the new entry to position 1 in the list;

Click on apply and then on ok;

Exit mtpaint.


B) Actually setting the ROX backdrop with mtpaint
1) Set the style
In console, type:

Code: Select all

echo Centre > /root/.config/wallpaper/backgroundmode

Alternately, you can replace "Centre" with "Stretch", "Tile" or "Scale".

2) In console, go to a pictures folder.
such as /usr/share/backgrounds or /root/my-documents/my-images

Type:

Code: Select all

mtpaint -v *.jpg 

or

Code: Select all

mtpaint -v *.png

Choose a picture in the list on the right as your backdrop (click on its filename).

Edit it to your liking.

Then click on: file -> actions -> set as wallpaper. That's it, you're done!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enjoy.

musher0

[sunburnt]

Interesting, and yet another way to accomplish the task.

My thought is that Rox isn`t FreeDesktop compliant, so no portability.

A rewrite that checks the O.S. for wallpaper config. conventions.

And this for many other things as well. Portability is good.!
.

[technosaurus]

Hmm... Maybe I should just add my sit functionality to rox so it can handle tray applets and desktop widgets including changing bgs? For those of you who havent played with it, it uses file monitoring to autoupdate images/tooltips on change. That could reduce the system load a bit.

[sunburnt]

Do you have a link to "sit"?

Rox isn`t real bad as such, but I and others hate Rox`s file browser.
And then there`s JWM and other apps use of XML, what a sad excuse for syntax.
And also there`s GtkDialog, no compatibility with any other distro. there.

Wrappers could be written, but there`s gotta be other alternatives that are std. compliant.
Xfce and Lxde, too heavy? I`m guessing they`re consistent in their config. file layouts.

Puppy`s "desktop" and other non-compliant parts are off in the weeds of obscurity.!!!
Perhaps mime compliant.? But as Nathan say, Rox having it`s own is actually a good thing.

[technosaurus]

sit/sdesk is here:http://www.murga-linux.com/puppy/viewtopic.php?t=76431

I may benefit from asking iguleder, since he seems to already have some familiarity with the source
https://github.com/iguleder/literocks/commits/master
He seems to have cut out a lot of the useless cruft already

It looks like I could add the status icons to pinboard_load_from_xml()
and tell ROX to set up a file watch on the backdrop image/status icons/etc...

BTW the reason for using a file watch is:
1.)no polling overhead (at least on Linux, glib uses inotify)
2.)using an SVG backdrop we could draw our own (non-interactive) pwidgets / gkrellm / roottail style desktop widgets directly or
3)just write a new file to the bg image to change it from any program

Basically the same way SIT handles the tray icons except you can have larger embedded images, graphs and text.

Out of curiosity, what percentage of resources do your tray apps / desktop widgets take up? (mine are over 50% when using Xvesa/xfbdev) but then again jwm can handle the desktop, maybe it would be better (long term) to add this to jwm now that it supports svg (with cairo+rsvg enabled)

[sunburnt]

Looks like a good fix for Puppy, JWM, and Rox. But the fixing never seems to stop...
Your tray app. is most of the answer to my post asking for an audible cpu temp. alarm.
The temp. monitor app. would just need a over-temp. setting to trigger the alarm.

I`ve never remastered Puppy, but I`ve seen many great ideas come and go over the years.
How about a new Puppy fork by a group focused on a particular parentage, and maintains
any enhancements so they`re not lost. Simplify Puppy, and fix the underlying shortcomings.
One of the integrated WM-desktops would really fix most of what this discussion is about.
Many base level fixes; stuff kept in /root, Pet packages hogging Save space, and more.

[simargl]

.

[Nathan F]

You're losing me with

One of the integrated WM-desktops would really fix most of what this discussion is about.

Problem is, all of them eventually start to suck. Even Lxde, which is now moving to QT and merging with RazorQT.

If you want a truly integrated system you have to start at lower levels for one thing. And then you have to commit to maintaining every part of it that grafts on above that, in order to keep it all behaving well with the whole. That's more like a *BSD except they stop short at the command line.

Linux has always and probably always will involve a certain amount of chaos. Even if you run something like Ubuntu you just never know when upstream is going to pull the rug out from under your workflow and push the 'Next Big Thing' down your throat (Unity, Gnom3, Wayland, Mir). Puppy is actually one of the more stable distros in regards to the "desktop" it uses, and you should probably consider that with your assessment, even though I agree it has problems.

[sunburnt]

I know little about Lxde, except on it`s web site they say it`s light weight.

It`s always been a Q in my mind as to any real differences between GTK and QT.
I don`t like GTK much, but I can imagine that worse is certainly possible.

IceWM is a good old std., but I`m not sure how complete it is.

I liked Xfce a lot, and I don`t see many other choices in the all-in-one department.
Plus it`s distinct parts that stand alone, but most of the all-in-one`s are probably that way.

# Needed changes; I hate the desktop drive icons, a transparent slide out panel`s better.
There`s plenty of room for on it for the task bar, desktop chooser buttons, and the tray.
And a second slide out panel for the app. menu. Quicker and easier access this way
Panels slide out from the screen`s left side. Thin hover strips at the left active the panels.
So now a clean desktop with only user placed icons on it. Xfce could setup to do all this.

# Also Rox-Filer is the only one I know of that recognizes RoxApps and AppDirs.
Is there a tabbed tree+file filer that is easy to modify nearly everything?

# Tabbed apps.: VTerm., Filer, Editor, and Image Viewer all in a single tabbed app.
.

[technosaurus]

A truly combined dektop environment is truly achievable with only a few mods.

Besides the tray icons and desktop we could combine gtkdialog into rox and have it just monitor directories for changes to source functions and load dialogs. The apps would need tweaked a bit to prevent name conflicts (button1 in multiple apps etc...)
Spacefm has a builtin dialog program, but it is unnecessarily forked, gtk can handle multiple windows and run a gio file monitor to load new ones or close them for that matter. Just from memory I know gtkdialog can read its xml from a file (stdin at least) and can source a file with shell functions... For most gtkdialog apps the main script could be put into an <app>_main function.

I think that could get it down to ~32mb for a full de with a choice of lightweight wm. I could even put together an app menu for wms without one.

[sunburnt]

technosaurus; I just downloaded an SFS of Xfce-4.8, it`s 31 MB compressed size. I`ll see how it`ll do...
I`ve heard that Xfce is slow particularly on old PCs, this may be due to reading files from partitions.

# Point; Frequently used files ( /etc/resolv ) should be in ram. Double write changes by some mechanism.
The mechanism could be custom utility apps., or better yet a file monitor app. ( which is so very useful ).

I wrote a BaCon exec. menu that reads the .desktop files directly. It`s slow reading from a part., but fast in ram.
If a new single menu file`s made ( not XML ) from the desktop info. ( like in Puppy ), it`d be really fast in ram.

I modded the menu for my AppPkg setup, clicking an AppPkg with more than 1 app. in it pops the app. menu.
Very nice as the menu shows what apps. are in The AppPkg. The apps. can have shared or private libraries.

# Need a customizable filer app. candidate... Tabbed and does drag n drop from both the tree and file panels.

# Idea for left side vertical slide-out taskbar: ( F1-F4 = desktop hot keys )

[ Drive Button ]
[ Drive Button ]
[ Drive Button ]
----------------------
[ Desktop #1 Chooser Button ] ( Sudo desktop pic. like Puppy )
[ Desktop #1 Task #1 ]
[ Desktop #1 Task #2 ]
[ Desktop #1 Task #3 ]
[ Desktop #2 Chooser Button ] ( Sudo desktop pic. like Puppy )
[ Desktop #2 Task #1 ]
[ Desktop #2 Task #2 ]
[ Desktop #3 Chooser Button ] ( Sudo desktop pic. like Puppy )
[ Desktop #4 Chooser Button ] ( Sudo desktop pic. like Puppy )
----------------------
( Tray Icons, 10 wide x N tall )
.

[technosaurus]

Its more about implementation than anything. My jwm menu generator written in shell is faster than the xdg one written in c, partly because I wrote it specifically for jwm, but also because the c implementation could use optimization. The big projects including the desktop environments suffer from their own succes in that it is more acceptable to add chunks of containable code that can easily be merged/reverted than to tweak existing working code (noone wants the "blame" for major regressions)

Any slowness due to being on a partition could be worthy of a bug report since files can be preloaded via readahead (shell) or memmap (c). Ive never needed to use either personally though.

As for the drive icons, check out scottmans modification of my jwm drive tray in akita or goingnuts version in pupngo. Its very similar, but I wrote an improved version that used jwm's menu system that was just an experiment which may be a little closer to what you describe and could even be integrated into the main menu.

Btw, jwm's menus are a neat way to have a superfast preloaded "app". For instance, one of the other tools in my jwm tools was a package manager with instant startup, and now jwm can reload menus without a full refresh.

One of peoples complaints about almost all linux desktops is the need to manually refresh... Simple solution is to use an inotify watch on the .desktop dirs, rather than the hodge-podge of other triggers that are used.

[Nathan F]

and now jwm can reload menus without a full refresh.

Question. Does that just mean that if the static menu file changes it will reload it, or is it a change in the way pipe menus are handle too? Previously you could run pipe menus in jwm but instead of refreshing on every click it was only on restart. That's annoying to me.

Simple solution is to use an inotify watch on the .desktop dirs, rather than the hodge-podge of other triggers that are used.

I've done this before and it works well, at least until I modified a generator meant for openbox which uses libmenucache (which does the same thing actually - puts a watch on the xdg dirs).

Which leads to another question. Does Puppy have the inotifywait binary in it's ISO? If so I might have more code to contribute for a number of things.

[technosaurus]

and now jwm can reload menus without a full refresh.

Question. Does that just mean that if the static menu file changes it will reload it, or is it a change in the way pipe menus are handle too? Previously you could run pipe menus in jwm but instead of refreshing on every click it was only on restart. That's annoying to me.

Simple solution is to use an inotify watch on the .desktop dirs, rather than the hodge-podge of other triggers that are used.

I've done this before and it works well, at least until I modified a generator meant for openbox which uses libmenucache (which does the same thing actually - puts a watch on the xdg dirs).

Which leads to another question. Does Puppy have the inotifywait binary in it's ISO? If so I might have more code to contribute for a number of things.

The inotify* tools are provided by busybox iirc.
Jwm has to be triggered with a jwm -reload (its not automatic) unfortunately barry's package manager runs the menu update tool or I would recommend adding the inotify code directly to jwm... the implementation would be similar to the startupcommand except that it would run when 1 of the xdg dirs receives an inotify add/modify/delete event... And should probably trigger a reload on completion (but that could be handled in the command)