Re: evince branched for 2.16
On Tue, 2006-10-10 at 00:02 +0400, Nickolay V. Shmyrev wrote: > During this release cycle me must solve following Evince problems: > > * implement history > * finally merge forms support > * decrease memory usage by creating intelligent cache > * create test suite I was thinking recently that it would be useful to be able to bookmark positions in the PDF. These bookmarks would be preserved across sessions, and be visible as in option in the left hand sidebar. When you added a bookmark, it would ask you what to call it, attempting to default to the name of the section you're in and the page you're on. eg. "Section 3.1. Derivation of the Time Independant Schroedinger Wave Equation - Page 97". I consistently find myself flipping between two pages of a document that are not at the top of a section in the table of contents. I used to solve this by opening multiple Evince sessions, but that wouldn't work across sessions. This would. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Beagle hackfest at GNOME Summit
Wow! Not gonna lie, I'm pretty excited for most of this stuff! On 10/11/06, Joe Shaw <[EMAIL PROTECTED]> wrote: > Hey, > > We had a hackfest at the GNOME Summit in Boston this past weekend. > > Here's a quick rundown of the things people decided to work on: > > * Me - Working on updating the indexer to better handle support > of user-provided metadata. Originally my plan was to store > metadata in an sqlite database and use Lucene for text search, > but having worked on the implementation since the summit this > doesn't look very feasible. More investigation on the Lucene > side needs to be done. Is this a continuation of what max has done? Or are we talking about a fresh start here? > > * Fredrik Hedberg - Work on merging the two Google Summer of > Code projects to add networking support to Beagle. One half of > the project was the main search support, which is done over > HTTP, and the second half is Avahi support so that other Beagle > servers around you are autodetected. > > * Aaron Bockover and Daniel Drake - Moving our audio filters > over to using taglib-sharp instead of entagged-sharp, which is > now deprecated and unmaintained. I think the work here is now > mostly done, but it's not in CVS yet. > Theres a bug, I think I attached a mildly functional filer, dunno... > * Gabriel Burt - Looked into increased integration of Beagle and > F-Spot. Not sure what the result of this was. > Any chance this includes extracting itpc data from images without f-spot? > * Dan Winship - As a broader goal desktop goal, decided to look > into moving Beagle to Cmake and learn its strengths and > weaknesses. It sounds like there are a lot of weaknesses, at > least within using it in GNOME. > > * Robert Love - Hanger on; spell checker; incorrectly > attributing typos to me. > > Later, Bastien Nocera talked to me about creating a video filter based > on Totem. He implemented it, and it's now waiting on my lazy ass to > commit it: http://bugzilla.gnome.org/show_bug.cgi?id=361047 Would we migrate to this over the mplayer one? And if so, don't we have to wait on the next release of totem to actauly have access to the totem-indexer executable? > > Joe > > ___ > Dashboard-hackers mailing list > Dashboard-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/dashboard-hackers > -- Cheers, Kevin Kubasik http://blog.case.edu/kevin.kubasik ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Slab's CC
CCing desktop-devel-list for any comment: On Tue, 2006-10-10 at 18:08 +0200, Rodrigo Moya wrote: > On Tue, 2006-10-10 at 11:58 +0200, Rodrigo Moya wrote: > > Hi > > > > I'm starting to move code from the CVS module slab to our > > control-center. So, this means just moving the slab/control-center code > > to our module, which is easy. The problem is with libslab/libtile and > > the util/ dir. The idea so far has been to leave them in slab and set > > them up as virtual modules for control-center and later, if accepted, > > into the panel (for the slab's menu applet). > > > > But I just started thinking about having all this code into a > > libgnomecontrolcenter that, later, if accepted, the panel could use. > > What do you think? > > Following on this, I'm looking (and almost starting) to merge all the > libs we have in c-c into a single libgnomecontrolcenter library. That > means putting libbackground and libwindow-settings, and, if we all > agree, libslab and libtile (while we look for a better place). > > Anyone has anything against this? I guess we don't have ABI/API > problems, since they're not platform libraries, right? -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Beagle hackfest at GNOME Summit
Joe Shaw wrote:
> Here's a quick rundown of the things people decided to work on:
> * Dan Winship - As a broader goal desktop goal, decided to look
> into moving Beagle to Cmake and learn its strengths and
> weaknesses.
So, mostly I did this because I was just hanging out in that room, and
didn't actually have any beagle hacking I was planning to do, and I
didn't want Joe to mock me like he did Robert:
> * Robert Love - Hanger on; spell checker; incorrectly
> attributing typos to me.
But also because Joe and Alex Larsson and I had somehow ended up talking
about CMake earlier, although I don't remember why. (Background:
http://cmake.org, http://lwn.net/Articles/188693/ ("Why the KDE project
switched to CMake"))
> It sounds like there are a lot of weaknesses, at
> least within using it in GNOME.
Well, I didn't actually get to look that deeply into it. It has a
definitely Windows-ish feel to it which I found kind of icky, but then,
I find autotools kind of icky too, so that's not that much of a change.
Also, I'd been hoping that KDE's automake-to-cmake conversion script
would be useful, but it turned out not to be (I guess it only works if
your Makefile.am's use certain KDE-ish conventions?). Many of the
existing CMake macros wouldn't work for us as-is; eg, there's a
pkg-config macro, but it doesn't let you check the package version, so
we'd have to write a new one. Also, the fact that you need to have cmake
installed in order to build the package was a point against it relative
to autotools. (cmake generates Makefiles [on UNIX], but you can't just
run cmake and then ship the Makefiles, because the cmake invocation is
the equivalent of running configure in an autotools-based setup.)
So anyway, it turns out that I couldn't migrate a large multi-language
project from autotools to cmake in a 2-hour hacking session (go figure),
and cmake isn't 100% perfect, but maybe it still could turn out to be a
good solution for GNOME. Mostly I'm just posting this so that people
don't rule it out because they think I actually did a detailed study.
(And so that OSNews doesn't post a story entitled "New KDE Build System
Not Good Enough For Us, Say Arrogant GNOME Pricks".)
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Beagle hackfest at GNOME Summit
> (And so that OSNews doesn't post a story entitled "New KDE Build System > Not Good Enough For Us, Say Arrogant GNOME Pricks".) "GNOME Developer Dismisses New KDE Build System, Calls Fellow Developers 'Pricks'." - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "GIMP is the primary tool in my graphics work. It is my gcc and Emacs." - Tuomas Kuosmanen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: "No pop up windows"-idea for Gnome 3
On 12 Oct 2006, at 11:09, Martin Jeppesen wrote: > The second is a Gnome Lite for thin clients. I study at the Danish > Technical University with about 12000 students and about 1000 thin > clients. In the summer Holiday they decided to change from Solaris 10 > to Gnome, but when the semester started, it was changed back very > quicky. > > I asked the administrators why Gnome was removed, and the answer were, > that Gnome took up way too much memory and CPU time, and also that > Gnome worked very poorly over network sockets. > > So I thought it is a shame that Gnome is not suited for thin clients. > Could that somehow be reworked in Gnome 3? It could certainly be better, and I know here at Sun we're always working to improve thin client performance where we can-- SunRays are big business for us, and GNOME is our preferred desktop. That said, we do have thousands of people running GNOME on SunRays here, and its performance is still better than on either of the standalone SPARC workstations I have on my desk. So it's certainly not impossible to have GNOME run reasonably well today in a thin client environment, if you turn off all the resource-hogging bells and whistles (screensavers, fancy backgrounds, opaque window movement, network monitor applet etc.) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: "No pop up windows"-idea for Gnome 3
On Thu, Oct 12, 2006 at 12:09:02PM +0200, Martin Jeppesen wrote: > The second is a Gnome Lite for thin clients. I study at the Danish > Technical University with about 12000 students and about 1000 thin > clients. In the summer Holiday they decided to change from Solaris 10 > to Gnome, but when the semester started, it was changed back very > quicky. > > I asked the administrators why Gnome was removed, and the answer were, > that Gnome took up way too much memory and CPU time, and also that > Gnome worked very poorly over network sockets. What? Solaris 10 GUI is GNOME. -- Tomasz Torcz "God, root, what's the difference?" [EMAIL PROTECTED] "God is more forgiving." pgpPjna1qC8GJ.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Slab's CC
On Wed, 2006-10-11 at 16:48 +0200, Rodrigo Moya wrote: > > Following on this, I'm looking (and almost starting) to merge all the > > libs we have in c-c into a single libgnomecontrolcenter library. That > > means putting libbackground and libwindow-settings, and, if we all > > agree, libslab and libtile (while we look for a better place). > > > > Anyone has anything against this? I guess we don't have ABI/API > > problems, since they're not platform libraries, right? Does this mean that nautilus will have to link to this lib (it currently has a libbackground module checkout)? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Beagle hackfest at GNOME Summit
On Wed, 2006-10-11 at 20:31 -0400, Kevin Kubasik wrote: > Wow! Not gonna lie, I'm pretty excited for most of this stuff! > > On 10/11/06, Joe Shaw <[EMAIL PROTECTED]> wrote: > > Hey, > > > > Later, Bastien Nocera talked to me about creating a video filter based > > on Totem. He implemented it, and it's now waiting on my lazy ass to > > commit it: http://bugzilla.gnome.org/show_bug.cgi?id=361047 > Would we migrate to this over the mplayer one? And if so, don't we > have to wait on the next release of totem to actauly have access to > the totem-indexer executable? It automatically falls back to whatever other filter you have if launching the totem-video-indexer fails. I'll probably do a release with the video indexer before Joe commits anyway :) -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
