First I'd like to say that I think this project is brilliant and really fills a gap that is not addressed by other wallpaper setting software. I really hope it progresses further in the future.
My question has to do with conky, and if there is any possibility of working in harmony with it in the future. Just like you have mentioned with the EXIF data displaying colors correctly on top of wallpaper, I would think it would be nearly impossible to get a desirable result with conky.
With that in mind, would it be impossible, or unreasonable to be able to define the target dimensions, and placement on the canvas of the resized images? (Just reading that back makes me think of how difficult that would be. LOL) I'm still not certain on how exactly this program works and should probably study the code before asking such a question but I tend to get ahead of myself sometimes.
I realize it would be an esoteric feature to have but could definitely see other uses for it other than conky. If it is something that could be considered in the future, maybe it could be implemented via a custom user settings file that could be parsed. The variables I envision could be way off the mark, but in general, maybe something like this..
Canvas color: #000000
Target Image Resize: 1280,1026
Image Center Coordinates: 640,513 (my conky is on far right from top to bottom)
One step further would to be able to define a canvas image instead of color. This would create all kinds of possibilities like being able to use a custom frame around the resized images, or have a spot to display the EXIF data in a constant color.
I'm sorry if I went off the rails a bit, but it's hard not to see all the cool possibilities. Just working as intended it would still be my wallpaper changer of choice, so please just consider this a dream feature request should it be possible.
Thanks again for listening,
Ako
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure I understood you correctly there, but you want conky and image areas not overlap, right?
It's really easy to do, since conky width is usually static and totally controllable, and controlling resulting image placement and dimensions is trivial (hey, it's the very first thing most people learn in gimp, which I basically use there!), but I'm not sure if you mean just that... good idea, btw, and guess it actually makes a lot of sense when you have screen like 1280*2 x 1024 because of two physical displays merged via randr or xinerama.
`
Actually, I've had an idea of using right side of the screen to display a traceroute-map of network connections on a planet, but never had time to finish this project (with a very basic stub of such panel implementation here).
Idea there was a semi-transparent overlay at the side of the screen with an outline earth map and traces of established connections on top of it, so I'd probably need more control over background image position anyway.
`
I'm a long-time conky user myself, but I just use it on top of the image (see attached pic), since it's fairly transparent, at least in my case. With the right settings (like outlines) it's text can be optimized to be readable on virtually any background, it seems, so there's not much need to be done there for readability, it seems.
`
That said, conky is very customizable via it's newer lua interface (just look at this or these), and I actually had a dream of playing with around with its customization sometime (my current layout is essentially unchanged since I used it on slackware in '05-'06), these days it's configuration seem to be totally dynamic (colors, positions, actual output, ...) and it's possible to do literally anything with it, limited only by amount of spare time and imagination ;)
My idea of customization was in radial visualisations and tree maps though - why show just linear disk space for example, while you can easily show "hogs" on a radial map, like philesight does, for example. Same goes for other stuff, like open ports (like "hey, you've got more http connections than bittorrent!") or current network traffic (or even some aggregation of it, showing which apps wasted your precious per-mb uplink)... but I digress.
`
Thinking more about playing with colors in conky - I think it's easy to pick dynamic color for conky via the same alghoritms I've used for label indeed, but I don't think it'd be very effective, since conky usually takes significant amount of screen space (not just a line or two), and taking an "average" color over such area shouldn't make much sense, but guess it can be tested first.
Another thing is that conky font colors can be varied per-line to be readable over much smaller area just behind the line, wonder how that'd look like though (a rainbow?) ;)
`
I think it's one of these cases when "picture is worth a thoursand words", can you give an example of what you mean, if I still don't get it right (I rarely do on first try)?
Most tricky bit there seem to be configuration then.
`
For example, I think it would be cool to have the ability to merge several images that way, so that in dual-screen configuration, say 2560x1024, you can paste one image of a size of 1280x800 with (0, 100) offset from the top-left, and another one (scaled to the same size) with (1280, 100), plus have some background for top/bottom stripes.
`
Should be easy to do from a technical perspective, not much so in a way of specifying it all in a comprehensible way.
Currently lqr_wpset accepts just a single path to an image file. Making it accept hundred parameters would be messy, so I'm thinking of a simple thing - if you specify non-image file as an argument (like "image_list.txt"), it'll be treated as a list of images (or "#RGB" spec instead of a path for a simple color fill) with optional parameters for each one, to composite in order they're specified.
Image picker script then can just use such a layout-configuration with a simple tags like "[image]" to be replaced with random picks, so one can create a file like this (instead of a default, say "~/.lqr_wpset_layout", which should just contain a single "[image]" line, or just impy that if there's no file)
...to dynamically pick images in the "middle" layers for both screens, while having background image (scaled, with black color showing up where it's not opaque) to cover the rest and a conky background (with original image dimensions and 50% transparency), anchored at the bottom-right corner.
`
Good thing: should provide a better place for configuration than the gimp plugin file headers.
Bad thing: performance will suffer with each layer you add to the cake, although single lqr rescaling pass takes waaaay more resources than all the rest of the operations combined (that's one of the reasons why images are pre-scaled with cubic first), so if you scale just one image with the rest being static backgrounds, that shouldn't take any more time than not using these bg's.
Ugly thing: I already think it's a bit too complicated (to the extent that it have to be documented), but should be completely optional, so guess that shouldn't be much of a problem.
`
On the overall, I seem to be inventing some compositing specification language here.
Wonder if there are plugins that already utilize such "shopping-list" format file (or if there are widespread specs for some such format) to produce a single image, maybe I can borrow more ideas (or code) there... gotta take a look.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a ton for the informative reply. I had an inkling it wasn't something trivial to achieve, but thought it might be possible. (ie.. dream feature)
`
While the dual screen with different images is even beyond what I was thinking, that would indeed be a clever system. On my setup, xfce does report 2 separate monitors with options to wall them separately, but it fails miserably in execution. To make it work at all I have to set the sameimage/image list for both monitors. I think it has to do with them paring down down the gnome libraries to keep the system "lightweight". There is no real configuration options to change or set resolutions or bit depths separately. I have asked for help on this but no one seemed interested in helping so I gave up.
.
The one thing I wasn't clear on was what you were doing with conky.
All I was thinking was using a black canvas (or custom image) of 1680x1050 and placing the target image to the left to not overlap where my conky resides. If this is possible, it should only add a single layer to the cake for my setup if I understand correctly.
`
Either way, I'm definitely not expecting anything from it. It just occurred to me that it would be really slick to have that functionality and wanted to give that feedback in case you thought so as well. I really appreciate the time you've already taken to think it through so much
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First I'd like to say that I think this project is brilliant and really fills a gap that is not addressed by other wallpaper setting software. I really hope it progresses further in the future.
My question has to do with conky, and if there is any possibility of working in harmony with it in the future. Just like you have mentioned with the EXIF data displaying colors correctly on top of wallpaper, I would think it would be nearly impossible to get a desirable result with conky.
With that in mind, would it be impossible, or unreasonable to be able to define the target dimensions, and placement on the canvas of the resized images? (Just reading that back makes me think of how difficult that would be. LOL) I'm still not certain on how exactly this program works and should probably study the code before asking such a question but I tend to get ahead of myself sometimes.
I realize it would be an esoteric feature to have but could definitely see other uses for it other than conky. If it is something that could be considered in the future, maybe it could be implemented via a custom user settings file that could be parsed. The variables I envision could be way off the mark, but in general, maybe something like this..
Canvas color: #000000
Target Image Resize: 1280,1026
Image Center Coordinates: 640,513 (my conky is on far right from top to bottom)
One step further would to be able to define a canvas image instead of color. This would create all kinds of possibilities like being able to use a custom frame around the resized images, or have a spot to display the EXIF data in a constant color.
I'm sorry if I went off the rails a bit, but it's hard not to see all the cool possibilities. Just working as intended it would still be my wallpaper changer of choice, so please just consider this a dream feature request should it be possible.
Thanks again for listening,
Ako
Not sure I understood you correctly there, but you want conky and image areas not overlap, right?
It's really easy to do, since conky width is usually static and totally controllable, and controlling resulting image placement and dimensions is trivial (hey, it's the very first thing most people learn in gimp, which I basically use there!), but I'm not sure if you mean just that... good idea, btw, and guess it actually makes a lot of sense when you have screen like 1280*2 x 1024 because of two physical displays merged via randr or xinerama.
`
Actually, I've had an idea of using right side of the screen to display a traceroute-map of network connections on a planet, but never had time to finish this project (with a very basic stub of such panel implementation here).
Idea there was a semi-transparent overlay at the side of the screen with an outline earth map and traces of established connections on top of it, so I'd probably need more control over background image position anyway.
`
I'm a long-time conky user myself, but I just use it on top of the image (see attached pic), since it's fairly transparent, at least in my case. With the right settings (like outlines) it's text can be optimized to be readable on virtually any background, it seems, so there's not much need to be done there for readability, it seems.
`
That said, conky is very customizable via it's newer lua interface (just look at this or these), and I actually had a dream of playing with around with its customization sometime (my current layout is essentially unchanged since I used it on slackware in '05-'06), these days it's configuration seem to be totally dynamic (colors, positions, actual output, ...) and it's possible to do literally anything with it, limited only by amount of spare time and imagination ;)
My idea of customization was in radial visualisations and tree maps though - why show just linear disk space for example, while you can easily show "hogs" on a radial map, like philesight does, for example. Same goes for other stuff, like open ports (like "hey, you've got more http connections than bittorrent!") or current network traffic (or even some aggregation of it, showing which apps wasted your precious per-mb uplink)... but I digress.
`
Thinking more about playing with colors in conky - I think it's easy to pick dynamic color for conky via the same alghoritms I've used for label indeed, but I don't think it'd be very effective, since conky usually takes significant amount of screen space (not just a line or two), and taking an "average" color over such area shouldn't make much sense, but guess it can be tested first.
Another thing is that conky font colors can be varied per-line to be readable over much smaller area just behind the line, wonder how that'd look like though (a rainbow?) ;)
`
I think it's one of these cases when "picture is worth a thoursand words", can you give an example of what you mean, if I still don't get it right (I rarely do on first try)?
Most tricky bit there seem to be configuration then.
`
For example, I think it would be cool to have the ability to merge several images that way, so that in dual-screen configuration, say 2560x1024, you can paste one image of a size of 1280x800 with (0, 100) offset from the top-left, and another one (scaled to the same size) with (1280, 100), plus have some background for top/bottom stripes.
`
Should be easy to do from a technical perspective, not much so in a way of specifying it all in a comprehensible way.
Currently lqr_wpset accepts just a single path to an image file. Making it accept hundred parameters would be messy, so I'm thinking of a simple thing - if you specify non-image file as an argument (like "image_list.txt"), it'll be treated as a list of images (or "#RGB" spec instead of a path for a simple color fill) with optional parameters for each one, to composite in order they're specified.
`
Could be something simple like
Image picker script then can just use such a layout-configuration with a simple tags like "[image]" to be replaced with random picks, so one can create a file like this (instead of a default, say "~/.lqr_wpset_layout", which should just contain a single "[image]" line, or just impy that if there's no file)
...to dynamically pick images in the "middle" layers for both screens, while having background image (scaled, with black color showing up where it's not opaque) to cover the rest and a conky background (with original image dimensions and 50% transparency), anchored at the bottom-right corner.
`
Good thing: should provide a better place for configuration than the gimp plugin file headers.
Bad thing: performance will suffer with each layer you add to the cake, although single lqr rescaling pass takes waaaay more resources than all the rest of the operations combined (that's one of the reasons why images are pre-scaled with cubic first), so if you scale just one image with the rest being static backgrounds, that shouldn't take any more time than not using these bg's.
Ugly thing: I already think it's a bit too complicated (to the extent that it have to be documented), but should be completely optional, so guess that shouldn't be much of a problem.
`
On the overall, I seem to be inventing some compositing specification language here.
Wonder if there are plugins that already utilize such "shopping-list" format file (or if there are widespread specs for some such format) to produce a single image, maybe I can borrow more ideas (or code) there... gotta take a look.
Thanks a ton for the informative reply. I had an inkling it wasn't something trivial to achieve, but thought it might be possible. (ie.. dream feature)
`
While the dual screen with different images is even beyond what I was thinking, that would indeed be a clever system. On my setup, xfce does report 2 separate monitors with options to wall them separately, but it fails miserably in execution. To make it work at all I have to set the same image/image list for both monitors. I think it has to do with them paring down down the gnome libraries to keep the system "lightweight". There is no real configuration options to change or set resolutions or bit depths separately. I have asked for help on this but no one seemed interested in helping so I gave up.
.
The one thing I wasn't clear on was what you were doing with conky.
All I was thinking was using a black canvas (or custom image) of 1680x1050 and placing the target image to the left to not overlap where my conky resides. If this is possible, it should only add a single layer to the cake for my setup if I understand correctly.
`
Either way, I'm definitely not expecting anything from it. It just occurred to me that it would be really slick to have that functionality and wanted to give that feedback in case you thought so as well. I really appreciate the time you've already taken to think it through so much