Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 29 Aug 2014, 10:27
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Is there another way to set wallpaper for the Rox desktop?
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 7 [104 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Sun 18 Aug 2013, 22:36    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Mon 19 Aug 2013, 01:25    Post subject:  

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 )
.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Mon 19 Aug 2013, 19:58    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Nathan F


Joined: 08 Jun 2005
Posts: 1760
Location: Wadsworth, OH (occasionally home)

PostPosted: Mon 19 Aug 2013, 23:26    Post subject:  

Quote:
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.
Quote:
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 ...
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger 
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Tue 20 Aug 2013, 01:15    Post subject:  

Nathan F wrote:
Quote:
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.
Quote:
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)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Tue 20 Aug 2013, 01:56    Post subject:  

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, 02:45; edited 1 time in total
Back to top
View user's profile Send private message 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Tue 20 Aug 2013, 02:12    Post subject:  

Hi sunburnt.

Quote:
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! Laughing

RSH

_________________
LazY Puppy Home
The new LazY Puppy Information Centre

Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Tue 20 Aug 2013, 02:49    Post subject:  

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.
.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Tue 20 Aug 2013, 04:15    Post subject:  

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, 04:25; edited 1 time in total
Back to top
View user's profile Send private message 
Nathan F


Joined: 08 Jun 2005
Posts: 1760
Location: Wadsworth, OH (occasionally home)

PostPosted: Tue 20 Aug 2013, 04:25    Post subject:  

Quote:
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 ...
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Tue 20 Aug 2013, 04:42    Post subject:  

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.
.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Tue 20 Aug 2013, 07:47    Post subject:  

Nathan F wrote:
Quote:
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)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2500
Location: New Zealand

PostPosted: Tue 20 Aug 2013, 15:40    Post subject:  

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!
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4346

PostPosted: Tue 20 Aug 2013, 22:28    Post subject:  

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.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Nathan F


Joined: 08 Jun 2005
Posts: 1760
Location: Wadsworth, OH (occasionally home)

PostPosted: Wed 21 Aug 2013, 15:44    Post subject:  

Quote:

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 ...
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger 
Display posts from previous:   Sort by:   
Page 5 of 7 [104 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1041s ][ Queries: 12 (0.0104s) ][ GZIP on ]