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

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#61 Post by 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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#62 Post by 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 )
.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#63 Post by 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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#64 Post by 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.
Bring on the locusts ...

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#65 Post by technosaurus »

Nathan F wrote:
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)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#66 Post by sunburnt »

technosaurus; I assume you`re talking about a non-Puppy BusyBox.
As you say... Half of Puppy`s doesn`t work because it`s not compiled.

So ditch the Package Manager and legacy app. packages ( .pet, .deb, etc. ).
SFS and RoxApp type packages work so well nothing else is needed.
Last edited by sunburnt on Tue 20 Aug 2013, 06:45, edited 1 time in total.

R-S-H
Posts: 487
Joined: Mon 18 Feb 2013, 12:47

#67 Post by R-S-H »

Hi sunburnt.
SFS and RoxApp type packages work so well noting else is needed.
Looks like we are the only two guys on this forum, owning such secretly knowledge and also acting and using puppy basically on this secretly knowledge

So, let's keep it secret or better saying: let's treasure it! :lol:

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy Home
The new LazY Puppy Information Centre[/url][/b]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#68 Post by sunburnt »

R-S-H; You know I`d rather share the good news. I`m no cloak & dagger sort of person.

Dumping legacy app. packages is a top level priority. Most folks don`t know the difference.

But you`d think once they`ve heard the advantages, they would understand completely.

I use to rail against SFS files for their problems. But now I include them as no-install apps.
.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#69 Post by technosaurus »

Tarballs for permanent installs, sfs for standalone packs. (lots of squash has a lot of overhead)

Puppy's busybox has inotifyd, inotifywait and inotifywatch ... But not sure what versions may not(lots of flavors these days which may have custom busybox)

I once did a patch to rox to use the same xdg used in glib, but couldnt find it, so I went back to the glib source to see how hard it would be to use it for implementing .desktop and mime. Unfortunately it just reminded me of all the bad crap... Functions that return a constant value or the return of another function or a property of a struct (all of which could be macros to speed up and reduce the shared lib size) as well as all of the hardcoding of gnome apps (for example using "gnome-terminal" instead of getenv("COLORTERM") or TERM then falling back to guesses (at least they do look for others if gnome-term isnt found)... Makes me want to just fork the xcb fork of gtk+-2.6 and backport the useful features like gtkbuilder and statusicon perhaps make it use linuxfb (not directfb) if DISPLAY is not set (maybe backport wayland too? In that case WAYLAND_DISPLAY)
Last edited by technosaurus on Tue 20 Aug 2013, 08:25, edited 1 time in total.

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#70 Post by Nathan F »

unfortunately barry's package manager runs the menu update tool or I would recommend adding the inotify code directly to jwm
That is unfortunate because the inotify trigger will catch source installs, squashfiles, and other methods that bypass the package manager. I'd push for the code to be included in jwm anyway and then present the case to Barry with a list of reasons and some actual code to look at. And then hope for the best...
Bring on the locusts ...

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#71 Post by sunburnt »

When you say lots of Squash has lots of over head, I assume you mean mostly the union.?
Certainly having as few Squash files as possible is a good idea.
I have pushed the idea of groups of like apps. in Squash files; Web, Office, Games, etc...

Although Squash does take some ram and cpu cycles it`s not as bad as it initially seems.
When it comes to partitions Squash files speed up reads. Ram may be slower, hard to test.
.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#72 Post by technosaurus »

Nathan F wrote:
unfortunately barry's package manager runs the menu update tool or I would recommend adding the inotify code directly to jwm
That is unfortunate because the inotify trigger will catch source installs, squashfiles, and other methods that bypass the package manager. I'd push for the code to be included in jwm anyway and then present the case to Barry with a list of reasons and some actual code to look at. And then hope for the best...
Try adding this to /etc/xdg/templates/_root_.jwmrc
<StartupCommand>inotifyd fixmenus /usr/share/applications/:dynmc</StartupCommand>

For ~/.autorun you could add a StartupCommand like:
for x in $HOME/.autorun; do $x &;done
(of course puppy uses the nonstd ~/Startup instead)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#73 Post by greengeek »

R-S-H wrote:Looks like we are the only two guys on this forum, owning such secretly knowledge and also acting and using puppy basically on this secretly knowledge. So, let's keep it secret or better saying: let's treasure it
RSH
No, don't keep it secret! Do it, Do it, Do it!! Build that new puppy!

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#74 Post by technosaurus »

Code: Select all

<StartupCommand>inotifyd echo /usr/share/applications/:dynmc /usr/local/share/applications/:dynmc |while read A; do fixmenus;jwm -reload;done</StartupCommand>
I used echo so that fixmenus doesnt get unneeded parameters, but if we used a menu generator that hashed the entries against the .desktop file /path/name then you could update only the changes.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#75 Post by Nathan F »

Code:
<StartupCommand>inotifyd echo /usr/share/applications/:dynmc /usr/local/share/applications/:dynmc |while read A; do fixmenus;jwm -reload;done</StartupCommand>
I used echo so that fixmenus doesnt get unneeded parameters, but if we used a menu generator that hashed the entries against the .desktop file /path/name then you could update only the changes.
My other suggestion would be to use menu-cache instead of gnome-menus, as I hinted at. It runs a lightweight daemon process which updates if anything in the xdg directories changes. In other words it's an all in one solution if you use it in a menu generator. The compiled package size is 116k on my box. My pekwm-menu generator compiles and strips to 12k.

I've already hacked up openbox-menu, which uses menu-cache, for use with pekwm. It would be trivial to do so for jwm too. It might be possible to do an all-in-one type for various wm's too, if there's sufficient interest.

Going that route the dreaded fixmenus script could be completely eliminated, and the package manager would only have to reload jwm. A lot of other wm's wouldn't even need to reload if they a) use a proper pipemenu implementation or b) reload their config files automatically. Those two conditions cover most every common wm except jwm by the way. I try to like jwm but it annoys me because a couple of things don't behave in a way I consider logical.
Bring on the locusts ...

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#76 Post by Nathan F »

I once did a patch to rox to use the same xdg used in glib, but couldnt find it, so I went back to the glib source to see how hard it would be to use it for implementing .desktop and mime. Unfortunately it just reminded me of all the bad crap... Functions that return a constant value or the return of another function or a property of a struct (all of which could be macros to speed up and reduce the shared lib size) as well as all of the hardcoding of gnome apps (for example using "gnome-terminal" instead of getenv("COLORTERM") or TERM then falling back to guesses (at least they do look for others if gnome-term isnt found)... Makes me want to just fork the xcb fork of gtk+-2.6 and backport the useful features like gtkbuilder and statusicon perhaps make it use linuxfb (not directfb) if DISPLAY is not set (maybe backport wayland too? In that case WAYLAND_DISPLAY)
IMHO it's high time someone took the good ideas from gtk+ and got rid of the cruft, so there's a usable toolkit that doesn't break abi every few years and suck all your resources. I was rooting for fltk a few years back but it seems pretty stagnant. Plus I just really like the look and feel of gtk+ even if there's a lot of problems.

I imagine you could answer this better than I, but just how much work would be required make a toolkit like gtk+ support linuxfb? My guess is quite a lot. It's good food for thought anyway, but I'd rather see dreams become reality.
Bring on the locusts ...

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#77 Post by don570 »

I put set_background script in my rightclick menu utility. This allows
quick setting of a jpg png or svg image as background.
It works nicely in recent puppies.

http://murga-linux.com/puppy/viewtopic. ... 872#720872

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#78 Post by technosaurus »

@nathan - linuxfb was supported up to gtk+-2.12, the best idea in gtk was to open source it. Honestly I'd like to check with the netsurf guys about pulling the netsurf framebuffer toolkit out of netsurf (GPL) and merging it into nsfb (MIT licensed) which supports many backends including linuxfb, xcb and wayland.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

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

#79 Post by musher0 »

Hello.

argolance - of ToOpPy fame - made fun of my script... Why go to the trouble when a very simple trick already exists, he reminded me:

* First, open your backgrounds folder.
* Then, right-click on any icon;
* click the second entry from the bottom of the menu that just appeared;
* a panel shows up;
* choose the background style on the line towards the top;
* drag the desired picture to the rectangle in the panel.

Done!

Regards.

musher0
Attachments
Forgotten_Trick.jpg
(47.45 KiB) Downloaded 345 times
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

#80 Post by musher0 »

Hello, all.

Here is another trick, related to http://murga-linux.com/puppy/viewtopic. ... ost#719803
posted on p. 4 of this thread, but this time in gcview. I believe the pic at http://murga-linux.com/puppy/viewtopic. ... t=lastpost needs no further explanation.

BFN.

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

Post Reply