Re: [gnome-love] Re: Re: anyone wanna help with gnome-backgrounds

[Rodney Dawes <dobey free fr>]

On Sat, 2003-08-30 at 02:17, Francis Whittle wrote:
> On 2003.08.30 13:37, Rodney Dawes wrote:
> > In response to Mark's mockup, and the other mockups he posted here
> > from
> > Luca, I have created a happy HIGificated mockup, of what the
> > background
> > tab in a "Desktop Appearance" properties capplet would look like.
> > 
> > http://www.gnome.org/~dobey/gnome-background-properties.png
> >
> 
> Nice.  The single dialogue with tabs is looking a liiittle too much  
> like Windows to me though :-/

Yes. It does. That is the idea. Part of getting people to migrate is
providing familiar territory for which the user can easily navigate
and learn the new system. KDE is often not chosen because it is too
close to Windows. GNOME, on the other hand, is quite close, but just
different enough to have people to want to use it, because it is still
something different. And the appearance properties is one thing that
Microsoft did do right with Windows. Also, you haven't seen the other
tabs. :)

> > Not really. The filename is an almost useless thing to know when you
> > have a thumbnail being displayed. More interesting information might
> > be file size, aspect ratio, or the comment/title from exif data. It's
> > too bad people don't like html mails, because they can be useful.
> > Like,
> > I could put a mockup of a row in the list view, here.
> >
> 
> Filename would be better.  Otherwise a very probable scenario is a  
> whole lot of images listed as "Made with GIMP".  Possibly some external  
> metadata where a user could name their background would be even more  
> still ;-)

I have many background images that have very long filenames, so that
doesn't really make all that much sense. Also, it is very possible to
have multiple different images, with the same file name, in different
directories. Also, displaying the full path doesn't really make any
sense to the user, and can get very long, very quickly. However, there
is no reason we can't provide some logic to determining what to display,
such as checking what the comment is, how long the filename is, if the
filename is already displayed by another image, etc...

> > Trying to be clever doesn't work very well most times. You have to be
> > really clever instead. We should calculate some kind of action to do
> > in a programmatic way, different from what you suggest here, as a
> > default. However, we should store metadata in the list of images that
> > are in the list, for each image, to specify what method the user
> > actually prefers from an image, rather than having a global and  
> > trying to only be halfway smart about it.
> 
> Again with the metadata.  I originaly didn't like the idea of metadata,  
> but this is one place where is really is useful!  Users' preference  
> should always rule these.
> 
> > The rules you propose are a good
> > start, but have a few immediate flaws. What do you do if an image is
> > just over 25% of the screen size, but still in the same aspect ratio?
> > Clearly you don't want to stretch it, unless you really like images
> > that are very pixelated. Center is actually used a lot, for the  
> > translucent png images, where you just set a background color, and  
> > the image is composited over top of it. What we probably want to do  
> > here, is add support for having the image in the 4 corners as well as  
> > the center of the screen. This would be useful for the default gnome  
> > config. We could just have a gradient, and a watermark foot in the  
> > bottom corner. There is a lot we can do here, we shouldn't limit  
> > ourselves to only being halfway smart if we are going to implement  
> > something like this. :)
> 
> Center and eight Cardinal points (N NE E SE S SW W NW ... four true and  
> the corners that is)... don't limit use to the corners.  And possibly  
> add on top of that a tag that allows you to place the image precisely  
> on the screen.  This sounds a lot like the old e15 background editor, I  
> know.

Going for simplicity and most-probable, in the UI. This can just be a
"geometry" gconf key which takes two coordinates, a width, and a height.
Then we can keep it simple for most cases, and let advanced users who
want to specify the position or use N/S/E/W positions, do it themselves.
I specified center and the four corners for the UI, as they are the most
common places where watermark images are placed. And now, thinking about
this again, it may be wise to allow the ability to place the watermark
image on top of any background image, as this would be very useful for
the vendors out there. Maybe even allow associating positions for the
watermark image in the metadata for the background images.
 
> > Storing backgrounds in ~/.gnome2/ sucks. Storing backgrounds in
> > ~/Backgrounds makes more sense. This is where I put all of my
> > wallpaper images anyway. However, it may make even more sense to do  
> > something like $XDG_DATA_HOME/Backgrounds/, so that it becomes user- 
> > configurable, follows some sort of spec, and doesn't shove more crap  
> > in ~/.gnome2 or other dot-directories. It should be possible to drag  
> > and drop an image from a web page, or smb: share, or afp: share, or  
> > somewhere else completely random, and have it work. This is what  
> > gnome-vfs is for. However, since we can't reliably use gnome-vfs for  
> > setting the background image (may log in without network, etc...), we  
> > should save the image to a local store of images. Normal users don't  
> > need to think about it. That's what the program is supposed to do.
> 
> ~/.gnome2/ is definitely not good.  Background images are not settings,  
> and shouldn't be hidden.  I would go for system-wide in eg.
> /usr/share/backgrounds/, metatheme-provided backgrounds in
> (theme_dir)/backgrounds/, and then user backgrounds can be referenced  
> on a per-URI or per-directory basis (with one default in, say,
> ~/backgrounds/) as specified by the user - all of this can then be  
> sotred in a vfolder so that the user can de-select backgrounds they  
> don't like, etc.  Remote images could be cached?

There is already a "system-wide location" where people store
backgrounds. The XD2 background capplet automatically adds these
to the list of images. :) I made it somewhat smart. However, as for
themeing the background, it and the splash screen, should be part
of the icon theme, as this is what is nominally affected by the chosen
background image. I'd also like to propose moving away from the usage
of the term "background" and suggest that we start using "wallpaper".
"Background" has several other contextual meanings that may cause some
confusion. Reasonable simplicity is the goal here. :)

-- dobey