Requesting variants of my "wallpaper" program

[Nathan F]

I've been finally going through old code of mine and doing some housecleaning and updating, and one of the things I'd like to dust off is the old wallpaper setter. I'm aware of the fact that a number of variants have sprung up in my long absence, and I'd like to request some links pointing to where they're at so I can look over the various contributions and maybe merge in some improvements. I've done a forum search, but there's just too many hits to sort through in a reasonable amount of time.

What I'd like to do is start cleaning up some of these old apps of mine and put them up on bitbucket so I can restart development, and in the process welcome anyone interested to help. A bit at a time I'm moving all my code to bitbucket, which uses mercurial (which I like) but also mirroring on github (git+me=blaaarrrgghh). Anyway, it would make all development occur in public, which is more in the spirit of GPL IMO.

There's a real short list of progress so far. I've cleaned up the little "programchooser" widget pretty substantially and imported all of the old Grafpup code from google-code (svn) into my local hg repo.

[Ibidem]

Pwidgets version (by Micko,Trio, & Zigbert) http://murga-linux.com/puppy/viewtopic.php?t=69658
French: http://www.murga-linux.com/puppy/viewtopic.php?t=85262

[Karl Godt]

tarball here http://murga-linux.com/puppy/viewtopic. ... 969#694969

background_reshape : http://murga-linux.com/puppy/viewtopic. ... 028#695028

Should read the whole thread
Latest Nathan Wallpaper zapping *.png's ? [SOLVED]
in the BUG section .

[Nathan F]

Many thanks, will read up. I just needed somewhere to start.

A cursory glance at the code shows me how much I've learned in the meantime. Some of the old code was pretty ugly.

[Karl Godt]

You're not alone (includes me too)

Puppy code is mostly ugly, but works/ed most of the time .

Puppy shell code is partly heavy , but since P-4 2GHz machines that doesn't matter that much .

A chance for Barry to clean up the code had been his arm 700MHz approach, but he waits for arm multi-core instead .

[Nathan F]

I've got some initial thoughts after doing a diff with my working code and the latest from all of you, and after looking over the code in general and the current state of gtk+, ROX-Filer, and current trends in desktop Linux in general. First the general stuff.

The gtk+ devs, in their infinite wisdom, have completely borked the file-selector dialog so it can no longer be opened in a specific directory but reverts to "recently used files". This is utter unusable BS for me, but it's now a fact of life unless you want to stick with an old and un-maintained version. Point is, it breaks a basic assumption of my wallpaper setter, that I can just embed the file-selector widget opened to the directory of the current wallpaper. This in itself merits a substantial rewrite.

ROX-Filer hasn't had a release since October 2011. I can't find any recent commits to the filer on sourceforge either, so unless there's another repo somewhere that I'm unaware of...let's just say it's starting to look like ROX-Filer is all but abandoned at this point. So if there's going to be a rewrite it would be better to generalize the code a bit more.

I also think that, while I was fairly proud of it at the time, the whole d**n thing is just way more complicated looking than it needs to be. The average user doesn't need a wallpaper setter with that many options. I'd move most of it to an "Advanced" tab now, or remove it altogether.

Here's my thoughts for the general shape of the rewrite, subject to change.

The file selector could easily be a list widget, generated by running "find -type f" on a user-specified list of directories.

Code: Select all

find "dir1" dir2" "dirxxx" -type f | egrep '.jpg|.jpeg|.png|<other-img-extensions>'

That's got the huge benefit of showing all your potential wallpapers in one place, and being configurable for adding other directories to the list. It would even be possible to specify a list of allowed file extensions to the "egrep" part.

I still want to support the rox pinboard (and puppy) but a plugin system could be implemented. The user opens the prefs dialog and selects the backend they prefer - rox, feh, or whatever, and the set_bg script sources the appropriate file.

Going along with my desire to generalize, the rewrite would not be a roxapp, but would sprinkle the files across the filesystem like a normal *nix application. There would be a "wallpaper" executable in <prefix>/bin, a plugins directory in <prefix>/lib/wallpaper, along with other common code being in <prefix>/lib/wallpaper. Translations would be in <prefix>/share/wallpaper/locale. There could still be an included roxapp to place on your pinboard that would allow you a right click menu to access the program functions or use the drag and drop functionality, but it would call <prefix>/bin/wallpaper with the appropriate options.

I've already started the rewrite, although there's not much in it yet. Once I have a gui mockup I'll put it up on bitbucket and put a link on the forum, and go from there.

All of you, as a collective, did a pretty good job of maintaining the original program in my absence and I thank you. I would welcome contributions to a rewrite in any form, whether it be opinions or actual code. But I have a few requests for code contributions.

I use mercurial now for my projects. I've started to post them a bit at a time to bitbucket, and am now starting to mirror them on github too. My order of preference for code contributions is as follows:
1) pull requests on bitbucket using mercurial
2) pull requests on github using git
3) diffs made by "diff -Naur <oldfile> <newfile>" sent to me or posted on the forum
4) Raw code pasted here or pastebin is my least favorite, but I'll work with it IF you comment it wherever a change is introduced.

The project is GPL_V2, and any contributions must be the same.

There must be nothing that ties the application to one particular distro (sorry Puppy) or assumes root usage. If there's going to be a script to re-size an image, for instance, there should be a plugin for using netpbm and one for imagemagic. At there very least, there have to be sanity checks to avoid a situation like the one where .png's were getting zapped because tools were missing.

Everything must take localization into account. It was a good idea to rip out the localization code and put it in common.sau, but I have a better idea that goes a step further. I want to rip it out of the specific application and make it a general routing that -any- shell based app can source, to make future devs able to do something like this:

Code: Select all

. /usr/lib/bash-functions/locale.sh

Anybody care to comment at this stage?

[01micko]

Suggestions;

• use only the exec gtkdialog, which I guess you will do as to make the application standards compliant.
• use gettext for localisation; you'll likely get German, Russian, Spanish updates (possibly more) on this forum.
• wjaguar's fix mentioned by Karl is in all woof built puppies now, a simple test for it's existence should be enough to cover netpbm.(EDIT: Barry doesn't use your wallpaper in his distros but uses Pwallpaper, a C application, source, need usual user/password. It uses wjaguar's script for image cropping.)

I'll help out when I can.

Thanks!

[Nathan F]

I suppose it's time I learned to use gettext. I'm guessing you suggested it because it's what other devs are doing for Puppy now?

I'll have to look over the fix by wjaguar. I'd like to be able to thumbnail using at bare minimum either netpbm or imagemagick. Which may lead to my writing my own backend, but I'll definitely incorporate anything useful wjaguar came up with and credit if I do.

Been working already. I've attached a mockup screenshot. This does nothing useful yet except show how I'd like the main window to look at the moment. The combobox contains a list of background directories, the folder button allows you to choose another one to add to the list (or it will anyway). Clicking a list item will bring up a new preview. Which by the way was the behavior I wanted previously, but was not available in gtkdialog back when the original program was written - hence just giving a text string.

The idea is to default to "stretch" mode and any other basically sane settings, keep the main window completely un-cluttered, and anything beyond that goes in the "Advanced" tab.

[01micko]

I suppose it's time I learned to use gettext. I'm guessing you suggested it because it's what other devs are doing for Puppy now?

Yes, most (if not all) of the bash based localisation is gone now. Barry developed his "mo-manager" which uses gettext so now localisation uses it; standard tools (poedit) are compatible.

I learnt gettext from shinobar's examples, but nearly anything in Puppy is a reasonable example now days.

Forum members L18L and rodin.s have the best knowledge and hopefully they will chime in here soon.

Some good examples are in the localisation forum including pburn and pmusic by zigbert.

[Nathan F]

Thanks for the pointers. I'll scrap my other idea and read up.

[01micko]

Since zigbert mostly adopted your bash method this thread might be a good read, zigbert and gettext.

The users mentioned in my previous post all contributed plus I forgot to mention vicmz.

don570 is another localiser on the forum plus many others.

[Nathan F]

Since zigbert mostly adopted your bash method this thread might be a good read,

One tiny correction, it wasn't my idea originally. I'm reasonably certain it came from Rarsa originally....but don't quote me on that. Whatever the case, I took it and ran with it for every project I could since then.

Just downloaded pClock to look over an actual example. Thanks again for the help.

I've continued working off and on at this and as of now here's what's working.
* The main window displays (haha)
* Typing into the combobox refreshes the file list as soon as there's a directory match
* Typing a valid directory into the combobox saves that directory for future use so you can jump right to it with the combobox
* mouseclicking the combobox refreshes the file list
* clicking a list item send the signals to create a new preview and refresh the preview

What's not working is a bigger list
* The script to actually generate the preview needs written
* The backends for actually setting the wallpaper aren't written
* The "Advanced" tab is empty

In short it's still an empty gui, but I already like it better than the old one and the basic premise of the layout seems to be workable.

[Nathan F]

The imagemagick preview backend is working, so when a new file is selected from the list the preview updates automatically. I'm caching the previews inside the user-config directory for now at a fixed width of 300px. With 40 previews cached that's @ 4.5mB, which to me isn't a bad trade-off for having the preview instantly update the next time.

In order to make this layout work, I set the list widget to a fixed height of 200px and am using a fixed width for the image previews. Without those two tweaks the gui does unacceptable things (from a user-standpoint) when you change from different image ratios. The caveat is, I won't be able to use "resamplefixedheight" but will instead have to cobble up something else for a netpbm backend.

That's it for today. I may have a mockup posted to bitbucket in a few days.

[Nathan F]

Couldn't sleep, the mockup is on bitbucket.
https://bitbucket.org/nfisher1226/wallpaper2
Both preview backends work, but the netpbm backend seems to be significantly faster. The actual operations for setting the wallpaper aren't quite finished. It's just intended as a proof of concept and preview of what I have in mind for the new gui.

Once it's actually doing something useful I'll post a new thread in the appropriate section.

[zigbert]

Hello Nathan
I haven't looked into the code, but want to mention that it is not necessary to use imagemagic or something else to resize images. gtkdialog does that internally. Maybe you have other reasons for keeping a separate buffer of all previews...

This code is taken from pMusic - how it shows the album art. Basically, it is the same as what you want.

Code: Select all

<hbox height-request="90">
	<eventbox tooltip-text="'$(gettext 'Show track-info window')'" above-child="true" visible-window="true" spacing="0" space-expand="false" space-fill="false">
		<pixmap>
			<variable>ARTWORK</variable>
			<input file>'$WORKDIR'/albumart.jpg</input>
			<height>90</height>
		</pixmap>
		<action signal="enter-notify-event">disable:ARTWORK</action>
		<action signal="leave-notify-event">enable:ARTWORK</action>
		<action signal="button-release-event">trackinfo</action>
	</eventbox>
<hbox>

Putting the pixmap inside an eventbox, makes it clickable and it gives a fake prelight.
The <height> defines the resizing, while the height-request defines the widget height in the gui. I see that you don't rely on Puppy, but I find it cruel to depend on imagemagic just for a wallpaper switcher.


Sigmund

[Karl Godt]

Somehow I don't really like the gettext approach .
It makes code reading much more difficult in my opinion .
I would at least prefer to

Code: Select all

alias gettext='_g'

to reduce the code a little bit .

See alias for gettext :http://en.wikipedia.org/wiki/Gettext

printf(gettext("My name is %s.\n"), my_name);

would become:

printf(_("My name is %s.\n"), my_name);

[Nathan F]

Hello Nathan
I haven't looked into the code, but want to mention that it is not necessary to use imagemagic or something else to resize images. gtkdialog does that internally. Maybe you have other reasons for keeping a separate buffer of all previews...

This code is taken from pMusic - how it shows the album art. Basically, it is the same as what you want.

Code: Select all

<hbox height-request="90">
	<eventbox tooltip-text="'$(gettext 'Show track-info window')'" above-child="true" visible-window="true" spacing="0" space-expand="false" space-fill="false">
		<pixmap>
			<variable>ARTWORK</variable>
			<input file>'$WORKDIR'/albumart.jpg</input>
			<height>90</height>
		</pixmap>
		<action signal="enter-notify-event">disable:ARTWORK</action>
		<action signal="leave-notify-event">enable:ARTWORK</action>
		<action signal="button-release-event">trackinfo</action>
	</eventbox>
<hbox>

Putting the pixmap inside an eventbox, makes it clickable and it gives a fake prelight.
The <height> defines the resizing, while the height-request defines the widget height in the gui. I see that you don't rely on Puppy, but I find it cruel to depend on imagemagic just for a wallpaper switcher.


Sigmund

Sigmund, that's awesome, thank you. Does that work for width as well? If so it's exactly what I need.

As for relying on imagemagick, there was as of late last night both an imagemagick and netpbm backend. Of which the netpbm backend is (drumroll...) insanely faster, and so would have been automatically selected if all the tools were on the host system had I gotten that far.

It's been a while since I messed with gtkdialog so I'm a bit rusty. Tips such as that are extremely helpful. Yesterday I fought with getting the right signal sent from the list widget for quite some time until I figured out the magic combination was simply "selection-changed". Until then, it had been returning the previously selected item. But I have to say, the improvements to gtkdialog are most welcome.

[Nathan F]

And it works fine, after figuring out one idiosyncrasy. Turns out gtkdialog was sending out the selection changed signal twice, once for leaving the previously selected list item and once for entering the newly selected item. So the first way I tried to do it this

Code: Select all

ln -sf \$WP_DIR/\$WP $USERCONFIGDIR/current.png

Was returning the $WP_DIR var and not the $WP var, resulting in the directory of the background image getting linked in, and then an error because it tried to link the image to itself.

The simple fix was almost exactly what you guys had done to the old setter when you added the preview function. Test if the selection was a file, and then test if it was an image, before creating the link.

Anyway it works like a charm now. Thanks again Sigmund.

Karl - under advisement. I've been reading up on gettext a bit and think the picture is starting to become clear now. I'll try and gettext this app when it's closer to a release and add a .pot file.

Incidentally, the feh backend is working for setting backgrounds. Haven't tried the rox backend but it should theoretically also work, as it's substantially the same code as the "set_bg" script in the old program. So it's now officially a working program, just not very user friendly as there's no way to switch between the two backends without editing the config file yet.

[zigbert]

Nathan
You can set <width> as well, but I haven't tested to force a resize with a different aspect ratio than the original image.

Be aware that the list and table widgets are not supported by gtk3. If you intend support gtk3 (gtkdialog does) you should use the tree widget instead. The tree widget is also the most powerful out of the 3, since Thunor has met many of my queries of new features. I use pMusic as a testbench for gtkdialog to push the limits. And with pMusic 4, all lists/db's are rewritten to use the tree widget.

And yes, much have happened with gtkdialog since you wandered around here.

Great to hear from you !!!
Things tend to be more innovative with Nathans around


Sigmund

[zigbert]

I'll try and gettext this app when it's closer to a release and add a .pot file.

No need of a .pot file. MoManager creates the .pot file for any script - not for compiled binaries, of course.

On the other side; MoManager is only included in the Puppy distro, so for other translators out there, a .pot file might be required.


Sigmund