Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 15:31 -0800, Dave Benson wrote: On Tue, Dec 18, 2007 at 05:14:31PM -0600, Federico Mena Quintero wrote: Big deal :) When you see 61.2 MB you think, oh, file system overhead! ripples in the time-space continuum. Nobody cares about that. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. I have no idea whether to use SI or computer units, but the fact that there's debate suggests holding off til there's more experience. Actually, I see it as an argument for centralizing the call and abstracting the decision away from apps. Then whenever its tweaked you fix it in one spot and it instantly propagates everywhere. Once a few cut-n-pasted versions exist, then you can decide if they are all the same... They are already a few like gnome-system-monitor, gnome-main-menu, presumably nautilus. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Fri, 2005-08-26 at 07:53 +0200, Murray Cumming wrote: But being as part of the official library pack makes them be official, and avoid people using different solutions for the same problem. That's the idea of being in the GNOME Development Platform. I don't see how putting the whole platform in one tarball makes it much more official. That's just an invitation to JDKesque quality problems due to lack of modularity - meaning: - you have to wait to release a bugfix because of a bug in another part of the library that surfaced in the meantime, and - you force people to suffer bugs in another part of the library when releasing a bugfix for one part of the library. Its a fine line, but I can't see how network connections don't fit in as an acceptable low level operation when we have the following in glib: 1) lexical scanner 2) xml subset parser 3) IO Channels Even if not in glib we should be creating an official solution that hooks nicely in to the mainloop rather than neon/curl/soup. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Mon, 2005-08-22 at 13:37 +0200, Rodrigo Moya wrote: what about libsoup/network library? Wouldn't it also make sense to move it to a libgnet in glib? I'm also for this, right now we are using multiple networking libraries and we fix the same bugs in multiple places. I think its odd as a platform we have no official way to great an http/network connection (yes libsoup is in the platform for evolution, but for instance gnome-vfs uses neon). -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: library dependency reduction (gtkhtml)
On Wed, 2005-03-23 at 18:58 -0500, JP Rosevear wrote: On Mon, 2005-03-21 at 01:31 +0100, Philippe De Swert wrote: Hi, On Fri, 2005-03-18 at 08:04 -0500, JP Rosevear wrote: How did you remove bonobo exactly? the components/ subdir needs those. Well I found out that the components part is for html-editing. It says actually html-editor in the components dir. As I did not need this functionality at all, as I was looking into rendering html I removed this part. So indeed my statement is not entirely correct. So my hack only applies to rendering, and you are very correct to point this out. However my point stands for other parts of the library (src, art, a11y). Declare the one small _() macro and a lot of deps disappear. I believe this is useful for reducing installed size and memory usage across several libraries. Are you just pulling in that definition for glib? err, from glib -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Themeable colors
On Tue, 2005-03-29 at 12:29 +0100, Bill Haneman wrote:
typedef enum {
GTK_PALETTE_DARK,
GTK_PALETTE_SEMI_DARK,
GTK_PALETTE_MID,
GTK_PALETTE_SEMI_LIGHT,
GTK_PALETTE_LIGHT,
maybe, but not appropriate to 'inverse' themes, for instance...
GTK_PALETTE_RED
GTK_PALETTE_PURPLE
GTK_PALETTE_BLUE...
No, definitely bad ;-)
because this would encourage app writers to do something that basically is
hard-coding colors. What we need are more semantically specified colors.
So to extend the current notion of SELECTED, PRELIGHT, FG, BG, BASE, TEXT, we
need other style names that indicate the context in which a color is to be
used, but not its hue or value.
Something like HIGHLIGHT might be nice, useful in Evolution for things
like outlining the current day in the mini calendar, draw Marcus-Baines
lines, highlight overdue tasks.
-JP
--
JP Rosevear [EMAIL PROTECTED]
Novell, Inc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: library dependency reduction (gtkhtml)
On Mon, 2005-03-21 at 01:31 +0100, Philippe De Swert wrote: Hi, On Fri, 2005-03-18 at 08:04 -0500, JP Rosevear wrote: How did you remove bonobo exactly? the components/ subdir needs those. Well I found out that the components part is for html-editing. It says actually html-editor in the components dir. As I did not need this functionality at all, as I was looking into rendering html I removed this part. So indeed my statement is not entirely correct. So my hack only applies to rendering, and you are very correct to point this out. However my point stands for other parts of the library (src, art, a11y). Declare the one small _() macro and a lot of deps disappear. I believe this is useful for reducing installed size and memory usage across several libraries. Are you just pulling in that definition for glib? -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: library dependency reduction (gtkhtml)
On Fri, 2005-03-11 at 13:30 +0100, Philippe De Swert wrote: Hello all, While doing some embedded work I decided to use gtkhtml to make a basic html helpviewer. This work fine, so it is not about that. But I neglected the several dependencies, which turned out to be quite high. So as the application was already working fine I decided to take a look at trimming down gtkhml. I started out with removing all includes that included bononbo includes and discovered that everything compiled fine. After solving a little problem related to () and N_() being defined in bonobo-i18n.h included from gnome-i18n.h by copying in the relevant stuff to gnome-i18n.h everything worked. So this relatively simple task removed three dependencies (libbonobo, libonoboui and libbonobo-activation) for this lib. Because of my problem described earlier this may actually happen more (and not only for libbonobo etc). I am going to try to find out about other inter-library dependencies that might exist (in my particular case) and maybe I can find some stranger relations. If these can be removed this could make a substantial memory reduction for gnome/gtk desktop/applications. As I do not have very much experience with all this I would like to have feedback from more experienced people (and I hope this post might inspire them to look at the number of useless includes that might actually add bloat when using gnome libs) How did you remove bonobo exactly? the components/ subdir needs those. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
