It is my understanding that Jon had discussions with the developers of these
applications, and for various reasons it was decided that writing something
from scratch is better. For EoG and GThumb the reason given was that their
maintainers did not have time to work on a major redesign, and for
Gravis wrote:
It works fine with Nautilus when opening files on a local
filesystem. -- http://i44.tinypic.com/t9gzye.jpg
The problem I've run into is that Nautilus will not allow me to open
files on remote filesystems (eg sftp virtually mounted file system) with
my application (doesnt appear on
Vincent Untz wrote:
During the first few months of 2008, a few Release Team members
discussed here and there about the state of GNOME. This was nothing
Wow, long interesting email! I'll limit myself to one area:
- Promotion of GNOME
This does seems to be lacking. If you go to
Hasanat Kazmi wrote:
Hello,
I want to make an anti thief software for Gnome. This project will be a
part of GSoc
I am really excited about the project but I need ideas for the software.
http://www.guardian.co.uk/technology/blog/2009/mar/02/laptop-shouts-stop-thief
has some good existing
We could totally use some liboil/profiling ninjas to work on libjpeg to
make it faster. Then, maybe thumbnailing on-the-fly wouldn't be
painful.
Ooh, yes, please! And the gdk scaling routines are very slow and
memory-intensive for large-ratio downscaling, which is unhelpful too.
or
Stephane Delcroix wrote:
As long as this plugin stays as is, we only have one choice available:
shout fuck you standards and move our thumbs out of .thumbnails. But
I think we can figure out an arrangement:
1) the MAX_SIZE should be set to 0 by default, so the cleaning is only
done one the
Stephane Delcroix wrote:
Whatever the MAX_AGE, at the time you're passing the threshold, you're
screwed.
About providing a UI, we're not in favor of that. A decent solution
could be to prompt the user with a UI like the f-spot thumbs cache is
taking 90% of the thumbnail allowed space. Grow that
libgnome has been branched for 2.22 with the gnome-2-22 branch name.
- Mike
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
I have brought this to the attention of the gThumb developers and they
suggested bringing this request to this list since the standard detect
algorithm is:
if (file.mtime != thumb.MTime) {
recreate_thumbnail ();
}
The 1-second granularity of mtime causes trouble when
The fdo thumbnail spec seems to have vanished -
http://jens.triq.net/thumbnail-spec/index.html
Is there a new location for it? I can't find it.
- Mike
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
Murray Cumming wrote:
jhbuild should take care of building. There is a lot of information
about how to use jhbuild, including solving specific problems on
specific distros.
My 2 cents: I found it easy to dive into gnome bug fixing and code
contributing - the barrier was low, in other words.
Jeff Waugh wrote:
I think some proven jhbuild recipes for current Ubuntu and Fedora
distros would be very helpful, somewhere on the gnome web site.
There are some useful resources linked from the jhbuild wiki page:
http://live.gnome.org/Jhbuild
You are right, someone has done some nice
Hi all,
Does anyone object if we bump the default thumbnail limit for Nautilus
up from 5 MB to 10 MB, to accommodate modern cameras?
Patch at http://bugzilla.gnome.org/show_bug.cgi?id=421342#c3 ...
- Mike
___
desktop-devel-list mailing list
Matthias Clasen wrote:
I thought it might be a good idea to anticipate the release announcement for
GTK+ 2.12 by writing a series of mails about some of the new features that
will
appear in the next stable release. I hope that this inspires some
people to play
with the new stuff, so that we
Luis Villa wrote:
2) Plead for review of the related patches in these bugs:
439567 – Add functions to transform pixbufs based on orientation tags
440978 – respect orientation tag when generating thumbnails
so that the next versions of gnome/nautilus/gtk/gthumb all agree on
Vincent Untz wrote:
Every time a new module is getting the plugin love, I'm seeing this: I
stole the gedit/epiphany code and integrated it. Wow. Copy and paste?
Would it be possible to share all this code in a library?
Well, I was thinking about stealing the eog code for gthumb, so +1 from
Denis Jacquerye wrote:
Most apps don't handle search/compare/sort properly.
Actually, this point hasn't really been noticed in the discussion.
(Denis has been diligently filing bugs for applications that do not
search correctly.)
For instance, gthumb used g_pattern_match_simple in some search
Filenames could also be NFC normalized when created, although that's
not absolutely necessary.
It would be nice if gnome mandated a standard approach for
normalization. Does everyone like NFC? (http://unicode.org/reports/tr15
for info.)
This could be fixed at a low level, in gtk filechooser
18 matches
Mail list logo
