Re: Focusing on innovation re: mono, python et al
On 7/15/06, Chipzz <[EMAIL PROTECTED]> wrote: > > Mono: > > F-spot > > Image viewer, really non-essential. Come on, Eye of Gnome is an image viewer. F-Spot is a photo management application (like iPhoto). Try asking Mac users if iPhoto is non-essential. Jeroen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
I'm curious: what role does the powersave daemon fulfill? I'm running FC5 and afaik, HAL/g-p-m gets it information directly from the OS (ACPI)? Regards, Jeroen On 4/10/06, Rodrigo Moya <[EMAIL PROTECTED]> wrote: > On Mon, 2006-04-10 at 12:25 +0200, Christian Fredrik Kalager Schaller > wrote: > > On Mon, 2006-04-10 at 11:59 +0200, Xavier Bestel wrote: > > > On Mon, 2006-04-10 at 01:28, Corey Burger wrote: > > > > On 4/9/06, Andrew Sobala <[EMAIL PROTECTED]> wrote: > > > > > Elijah Newren wrote: > > > > > > On 4/9/06, Scott J. Harmon <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >> Am I the only one who mouses over the applet to see how much more > > > > > >> time > > > > > >> until the battery is fully charged? > > > > > >> > > > > > > > > > > > > Definitely not; I rely on this frequently. I'd be heavily annoyed > > > > > > if > > > > > > the applet wasn't showing (and no other equally easy way of > > > > > > obtaining > > > > > > this information was available) when my laptop is plugged in and not > > > > > > fully charged. If it's both plugged in and fully charged then I'd > > > > > > be > > > > > > fine with it not being there, as long as that was the only case. > > > > > > > > > > > Hmm. In this configuration, it is. > > > > > > > > The problem with hiding in this case is that the user must know that > > > > when they are plugged in and fully charged, the icon will vanish, > > > > rather than just looking and seeing that they are fully charged and > > > > plugged in. Ouch. > > > > > > Well, if once the battery reaches 100%, a short-lived notification > > > bubble says so then the icon can disappear without harm. No need to > > > pollute the notification area with a "battery is full" icon, OTOH on the > > > road the fuel gauge is important. > > > > > > IMHO the best design is found in PocketPC2003: the battery icon starts > > > to appear only when it's half-empty. > > > > > While this debate about people's battery status preferences is extremely > > interesting and intellectually challenging I think its on a level of > > nitpickery that belongs on either some HIG related list or in bugzilla. > > > > The actual question at hand is, Is GPM ready to go into GNOME 2.16? > > > one of the problems I've found while putting g-p-m for NLD 10 is that > the power saving daemons (powersave in SuSE case) don't update the HAL > properties in all cases (can_suspend, can_hibernate, etc). We need to > make sure that is done (calling hal-set-property it's very easy) so that > g-p-m can just use HAL reliably. > > Apart from that, I'd say g-p-m is ready. Some integration work might be > needed (like inhibit thing Richard added), but nothing that can't be > done in the 2.15/2.16 development process. > -- > Rodrigo Moya <[EMAIL PROTECTED]> > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving Applets (was: Fish in GNOME Panel)
Isn't netstatus made obsolete by NetworkManager? Are there any plans to include NetworkManager into 2.14? Jeroen On 10/12/05, Davyd Madeley <[EMAIL PROTECTED]> wrote: > People have struck on a topic I started thinking about a little > while ago. > > This thinking is highlighted on the wiki space > (http://live.gnome.org/GnomeApplets). > > In short we would create a gnome-applets-extras. The purpose of this > package would be to include all the applets that have no home on > their own, but really don't need to be part of the standard desktop. > This will reduce the load on the maintainers/translators and > everyone else while not leaving older applets to die. > > Here are a series of transitions I have thought about. > > Applet Current ProposedNotes > -- -- - > clock panel applets remove e-d-s dep in panel > wanda panel applets-extras > stickynotes applets applets-extras > netstatus -- applets needn't be separate > user-switch -- applets useful feature > geyes applets applets-extras > gtikapplets applets-extras > modemlights applets applets-extras > > I would also like to separate the locations database out from > g-applets, since it is a huge portion of the tarball size and may > benefit from reuse in other places. > > I am also interested in replacing mini-commander with Deskbar. The > problem here is that Deskbar is in Python and uses a binding from > gnome-python-extras. The other option is the pimping of > mini-commander. > > --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 > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
On 8/21/05, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> Also basic support for "styled editing," i.e. right now to implement a
> Bold button that behaves like the one in a word processor is fairly
> involved with GtkTextView. So some kind of API for that might be cool.
What kind of API are you thinking about here?
Imho, the current API isn't that difficult to use. Maybe we just need
to advertise/provide some more examples on how to use it:
1. create a new GtkTextTag: gtk_text_tag_new ("bold");
2. set the bold attribute: g_object_set (tag, "weight",
PANGO_WEIGHT_BOLD, NULL);
3. get a start & end iter for the text you want to apply the tag to
4. call gtk_text_buffer_apply_tag_by_name
Jeroen
___
desktop-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
GtkSourceView is perfectly fine where it is. At the moment it has dependencies on libxml2, gtk+ and libgnomeprint. The latter should disappear into gtk+ with Ridley. GtkSourceView is a very specific, well maintained widget that's perfectly fine living outside of gtk+. A developer can use the library without needing any extra dependencies (assuming he's already using gtk+ & libxml2). Jeroen (GtkSourceView developer) On 8/21/05, Mystilleef <[EMAIL PROTECTED]> wrote: > I was hoping to see gtksourceview among these libraries. Are there any > objections against it? > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
build break (+ patch): gnome-control-center
Seems gnome-control-center checks if Xcursor headers are present, but
fails to add the -lXcursor argument to the CAPPLET_LIBS. Patch
attached to #310643. Dunno why this hasn't been noticed before though
(so i'm not entirely sure the patch is correct).
Without the patch, the build fails on x86_64 with
gnome-mouse-properties.c (undefined reference to XcursorImageDestroy).
Regards,
Jeroen
? gnomecc.patch
? capplets/about-me/gnome-about-me
Index: configure.in
===
RCS file: /cvs/gnome/gnome-control-center/configure.in,v
retrieving revision 1.499
diff -u -p -r1.499 configure.in
--- configure.in 13 Jul 2005 21:51:44 - 1.499
+++ configure.in 17 Jul 2005 12:23:33 -
@@ -152,9 +152,12 @@ dnl mouse capplet with support for it tu
dnl
have_xcursor=no
AC_CHECK_HEADER(X11/Xcursor/Xcursor.h, have_xcursor=yes
+ XCURSOR_LIBS="-lXcursor"
AC_DEFINE(HAVE_XCURSOR, 1, Have the Xcursor extension),
:, [#include ])
AM_CONDITIONAL(HAVE_XCURSOR, [test $have_xcursor=yes])
+
+CAPPLET_LIBS="$CAPPLET_LIBS $XCURSOR_LIBS"
dnl
dnl Check for gtk+ with multihead support
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: building GNOME 2.11 on x86_64 using jhbuild
Hi Pat,
I traced my problem to "freetype-config --libs" returning something
that contains "--rpath". This causes the jhbuild binaries to use the
system libraries (/usr/lib64) instead of the ones in my homedirectory.
The runpath takes precedent over LD_LIBRARY_PATH.
I've rebuilt freetype from the fedora source rpm previously to enable
the bytecode interpreter. The freetype-devel package comes from build.
Why it contains the --rpath parameter is beyond me.
You seem to be having the same problem. Trying figuring out which
pkg-config file contains the --rpath reference and look from there how
it got there. The first module's pkg-config containing the --rpath
reference was cairo on my machine. Everything else from there on out
had problems. Removing the --rpath reference from the pkg-config file
and rebuilding from there on fixed it.
I still need to do some more work before i have a working desktop
(evolution-data-server didn't pickup mozilla-nspr-devel from
/usr/lib64 as of last night; i don't build mozilla in jhbuild), but
the "hard" stuff should be over.
HTH,
Jeroen
On 6/14/05, Pat Suwalski <[EMAIL PROTECTED]> wrote:
> Pat Suwalski wrote:
> > I was hoping to test your theory this evening, but I can't get very far
> > in the build, which dies at gtk because of:
> >
> > ./.libs/libgtk-x11-2.0.so: undefined reference to
> > `g_utf8_collate_key_for_filename'
>
> On further thought, this must be because it's trying to link against
> what's in /usr rather that /opt/g212. This appears the same problem you
> have, except that I cannot explain how you got past the gtk+ build.
>
> This is clearly because the libraries are explicitly specified
> ("/usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so
> /usr/lib/libglib-2.0.so"):
>
> gcc -g -O2 -g -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o
> ./.libs/libgtk-x11-2.0.so -L/opt/g212/lib64
> /home/pat/cvs/gnome2/gtk+/gdk/.libs/libgdk-x11-2.0.so -L/usr/lib64
> /usr/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so
> ../gdk/.libs/libgdk-x11-2.0.so -lXrandr -lXinerama
> /opt/g212/lib64/libXft.so -lXfixes -lXcursor /usr/lib/libpangoxft-1.0.so
> /opt/g212/lib64/libpangocairo-1.0.so /opt/g212/lib64/libcairo.so
> /opt/g212/lib64/libpixman.so /opt/g212/lib64/libpangoft2-1.0.so
> /opt/g212/lib64/libpango-1.0.so /opt/g212/lib64/libfontconfig.so
> /usr/lib/libcairo.so -lXext /usr/lib/libglitz.so
> /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so
> /usr/lib/libpixman.so /opt/g212/lib64/libXrender.so -lX11 -lpng12 -lz
> /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so
> /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so
> /usr/lib/libglib-2.0.so
> /home/pat/cvs/gnome2/gtk+/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so
> /opt/g212/lib64/libgmodule-2.0.so -ldl /opt/g212/lib64/libgobject-2.0.so
> /opt/g212/lib64/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/g212/lib64
> -Wl,--rpath -Wl,/usr/lib
>
> --Pat
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
building GNOME 2.11 on x86_64 using jhbuild
Hi,
In the last couple of days i've built gnome-2.11 using jhbuild about
10 times so far. It builds fine (uncovered some gcc4-related bugs,
filed them and they're fixed; apply a hal patch to n-c-b etc.). This
is on a Fedora system, with up-to-date packages from rawhide.
However, after it has finished building and you look at which
libraries the binaries are linked to, most of them are linked to
/usr/lib64 libraries instead of /home/jeroen/Gnome/built/lib64. I've
tried *lots* of things, but nothing helped. LD_LIBRARY_PATH is
pointing to /home/jeroen/Gnome/built/lib64. I even went as far as to
strace gnome-about and it *doesn't even look* in
/home/jeroen/Gnome/built/lib64:
$ echo $LD_LIBRARY_PATH
/home/jeroen/Gnome/built/lib64
$ strace gnome-about 2>&1 | less
execve("/home/jeroen/Gnome/built/bin/gnome-about", ["gnome-about"], [/* 44 vars
*/]) = 0
brk(0) = 0x509000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaab000
uname({sys="Linux", node="anduril", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/x86_64/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib64/tls/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/x86_64/libgnomeui-2.so.0", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib64/libgnomeui-2.so.0", O_RDONLY) = 3
If my experience with jhbuild on x86_64 is anything like other people,
GNOME 2.12 will see *very* little testing on x86_64. I'm a developer
and i can't even get it to work...
Help?
Jeroen
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? Regards, Jeroen On 6/10/05, Owen Taylor <[EMAIL PROTECTED]> wrote: > On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: > > On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote: > > > Went ahead and did it myself. TextView is brutally slower (300-400%), > > some other things are 25-30% slower, and some things actually get > > faster. Disclaimer: I'm pretty sure I did this right and I'm linking > > against the right stuff, but these numbers should be confirmed by an > > expert, and I can't speak to the validity of the tool's measurements > > itself, except to note that scrolling in a textview area is *visibly* > > slower. > > > > The data: > > > > first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of > > yesterday, both with the Mist theme: > > With the Mist theme, you are testing mixed Cairo and GDK rendering. > Right now, that could conceivably hide some performance problems with > Cairo. In the future, there are some performance optimizations that will > be disabled when you are mixing Cairo and GDK rendering. > > The GTK+ builtin theme probably gives more of an accurate feel for > GTK+/Cairo performance. > > What the appropriate theme to test is does depend on what we will > be shipping for GNOME-2.10 as the default, of course. Which is likely > not the GTK+ builtin theme. > > > GtkEntry - time: 0.43 0.76 > > GtkComboBox - time: 12.61 15.30 > > GtkComboBoxEntry - time: 11.95 13.25 > > GtkSpinButton - time: 0.65 1.09 > > GtkProgressBar - time: 0.53 0.87 > > GtkToggleButton - time: 2.17 4.42 > > GtkCheckButton - time: 3.41 3.27 > > GtkRadioButton - time: 4.29 3.96 > > GtkTextView - Add text - time: 91.88 268.67 > > GtkTextView - Scroll - time: 43.17 190.83 > > GtkDrawingArea - Lines - time: 8.40 8.48 > > GtkDrawingArea - Circles - time: 13.38 13.58 > > GtkDrawingArea - Text - time: 48.70 29.99 > > GtkDrawingArea - Pixbufs - time: 11.71 11.46 > > Without studying what these benchmarks are actually doing, I'd consider > them pretty encouraging ... some operations got faster, and what > got slower is something we have in our sights already ... > cairo_scaled_font_glyph_extents(). (GtkTextView performance is > text measuring performance.) > > There is an obvious big-hammer approach that would allow us to get rid > of that ... to put a cache in front of it so that we avoid calling > into Cairo entirely, but I'd like to see what we can do inside of > Cairo first. > > Regards, > Owen > > > > BodyID:12373415.2.n.logpart (stored separately) > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince as universal "Viewer"
Please, there's a reason why the bonobo approach to gpdf died. Don't try to resurrect it. Having a PDF viewer that is *really good* at displaying/searching/browsing/whatever a PDF is worth more to me than an application that displays multiple types of documents *ok*. Please don't turn this into a mega thread again that most people just skip... Jeroen On 4/19/05, Neil Stevens <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tuesday 19 April 2005 08:00 am, Jeroen Zwartepoorte wrote: > > Simple example: eog has "rotate image" functionality. Does such > > functionality belong in a PDF viewer? > > Shouldn't the component architecture allow the components to tell the shell > what special case features to add? Each viewer component can include only > and all the features useful to it. > > - -- > Neil Stevens - [EMAIL PROTECTED] > > 'A republic, if you can keep it.' -- Benjamin Franklin > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.6 (FreeBSD) > > iD8DBQFCZR9vf7mnligQOmERAuFCAJ9uDreV+FSP77GEfafBXUImbjF/EACggtk6 > +YVxL2oIjtT90Neu4I3lVzE= > =C7Z/ > -END PGP SIGNATURE- > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince as universal "Viewer"
IIRC this approach was tried and rejected previously with ggv/gpdf (?). I don't recall the exact application, but we had an application that was basically nothing more than a shell for bonobo viewer components. Given a bonobo viewer component, it could display the document in that shell. Given that displaying an image is not that difficult and evince could probably do it fine, i'd hate to see us go back to one-app-fits-all for a document viewer. Simple example: eog has "rotate image" functionality. Does such functionality belong in a PDF viewer? Regards, Jeroen On 4/19/05, Steven Garrity <[EMAIL PROTECTED]> wrote: > There's a brief discussion on one of the Fedora lists about how Eye of > Gnome relates to gThumb. The conclusion is the usual one, and it makes > sense: eog is the quick-to-load simple one-off image view, and gThumb is > a more powerful image/photo browser. Makes sense. > > Someone mentioned Evince in the discussion and it made me wonder: should > Evince replace Eye of Gnome as the universal "Viewer" app on Gnome. It > already seems to support the basic image formats (jpeg, png, etc.). > > It also loads relatively quickly when opening a single image, and loads > without the sidebar for formats without "pages" - so it has the > look/feel of a simple/fast viewer app. > > In the version I'm running (0.1.9), the zoom controls don't seem to work > on non-pdf files (jpeg, png, etc.), but I'm sure that could be fixed. > > I don't think there is really anything wrong with Eye of Gnome, but it > might be nice to have *one* simple document/image viewer, rather than > one for PDFs and one for other image formats, when they are so close in > UI and core functionality. > > Not that this makes it the right choice, but for reference, this is what > Apple does with their "Preview" application. > > Any thoughts? > > Thanks, > Steven Garrity > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OT: better than polls [WAS: roadmap status update/update request]
Jan, Please stop CC'ing desktop-devel-list. Thanks, Jeroen On Tue, 08 Mar 2005 11:58:01 +0100, Jan Nieuwenhuizen <[EMAIL PROTECTED]> wrote: > Havoc Pennington writes: > > > I've seen hundreds of web polls and read a mind-blowing number of > > articles on Slashdot, LWN, LinuxToday, OSNews, etc. My estimate of > > overlap of the priorities of posters to these sites with Red Hat's > > enterprise customers is 5%. My estimate of the overlap of the priorities > > of posters to these sites with "average corporate or home desktop user" > > is 5%. I am not exaggerating. > > Hmm, we were thinking of web polls as a better means of gathering > interesting/important feature requests than [griped] user postings on > the mailing list. Maybe that would still be a worthwile effort, but > not the best way to go. > > > We do, but we have better ways to find out than web polls. > > Now that is interesting. Would you want to share some of those better > ways with two guys (cc: Han-Wen an me) who are seeking to start-up a > small business around LilyPond support? > > Greetings, > Jan. > > -- > Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter > http://www.xs4all.nl/~jantien | http://www.lilypond.org > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
