Re: GlobalMenu Application for inclusion as a GNOME module
On Thu, 2009-09-03 at 15:44 +0200, Patryk Zawadzki wrote: > On Thu, Sep 3, 2009 at 3:39 PM, Ted Gould wrote: > > On Thu, 2009-09-03 at 12:58 +0200, Patryk Zawadzki wrote: > >> Unless you ever want to use an MPX-enabled X server of course ;) > > I don't understand. Why is MPX incompatible with Global Menu? > > As Xi2/MPX allows you to have one focus per input including being able > to focus two windows at a time (each with its own menu bar). Similarly, it breaks with simple focus-follows-mouse. --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
"Internationalising GNOME applications" manual
Hey, Anyone know why the manual http://www.gnome.org/~malcolm/i18n/ isn't on library.gnome.org? --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: Panel applets and Bonobo
On Sun, 2009-08-09 at 13:14 -0400, Jud Craft wrote: > The tutorials here [1] and here [2] both are beginning tutorials in > applet development, but they both use Bonobo. I am aware that > previously Bonobo was a common part of GNOME applets. It still is. That's why you can't find any information. -- 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: Qt as acceptable GNOME dependency
On Tue, 2009-07-14 at 04:52 +0100, adel wrote: > now Qt can be plugged into the Glib main loop and uses GTK+ for > drawing, if I respected HIG and used GNOME API, can my Qt application > be consider a GNOME application or even be part of default GNOME > stack? Wow, prescient. This question came up at Collabora HQ yesterday. If a D-Bus service was written in QtCore (the base libraries and templates for Qt... a lot like GLib) would it be accepted as a GNOME external dependency? I said that I hoped it would. To my mind, accepting QtCore is no different to accepting GLib. We expected KDE users to get over the religious purity of refusing to use GLib, so surely we should expect no less of ourselves. The whole of Qt though, including the graphics classes... hmm that's another kettle of fish. --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: git and trailing whitespace
On Wed, 2009-05-06 at 00:01 +0200, Vincent Untz wrote: > Are there places where trailing whitespaces are "valid" (ie, we want > them)? Or are the checks only looking at code files? It's a bit of an edge-case, but Markdown files give trailing-double-space a meaning. There might be others. --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: fast-forward only policy
On Tue, 2009-05-05 at 16:00 -0400, Behdad Esfahbod wrote: > >> case that's not a compelling argument; you can still have branches > >> '1-2' and 'gnome-2-26'. > > Quick note. If we're going to have short branch names (as I'm planning to > use > for pango), it should be "1.2", not "1-2". Why? Surely this makes the branches harder to spot on a quick glance (short non-word strings are harder for the eye to spot), possibly breaks grouping in lists (i.e. they all start pango-), and with tab completion doesn't really gain you much in terms of typing time. I've always liked our consistency with branch and tag names. There is so much implicit information available there, without you having to look at other things. --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: fast-forward only policy
I have to admit, there is probably some advantage to moving these very old branches into an archive (either refs/archive/foo or a complete archive clone) after some amount of time. Mostly because I thought "new IM? What new IM?". Also permit the deletion of branches that have been merged with master (i.e. something that could be deleted with `git branch -d`). This would probably help people who are not core contributors get an idea of the state of the project, we have master, a bunch of stable branches (perhaps we can hack cgit to move stable branches to their own category on the summary?) and a bunch of active feature branches that show where people are getting their hands dirty. On Thu, 2009-05-07 at 01:11 +0300, Felipe Contreras wrote: > I've already explained that having a gazillion of branches is not > clear, it creates noise. > > Let's take a look at these from the GTK+ repo: > > themes: 11 years > themes-2: 11 years > rendering-demo: 4 years > ps-mf: 10 years > master-UNNAMED-BRANCH: 10 years > kris-async-branch: 3 years > hp-patches: 9 years > havoc-patches: 9 years > gtk-printing: 3 years > gtk-pango: 9 years > gtk-no-flicker: 9 years > gtk-new-im: 9 years > gtk-multihead: 7 years > gtk-hp-patches: 9 years > gdk-object-with-pango: 9 years > gdk-object: 3 years > federico-filename-entry: 3 years > cancelation-changes: 3 years > AUTO_DENATTIFYING: 3 years > > If you move them to a historic repo, what do you loose? -- 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: Applets? [was Re: Planning for GNOME 3.0]
Just to throw my hat into the ring, I thought I'd link to some previous discussion on applets. http://davyd.livejournal.com/118545.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00241.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00384.html -- 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: quo vadis, docs
On Mon, 2009-02-09 at 21:37 +, Matthew Paul Thomas wrote: > More good news: That's also often unnecessary. A description of a > feature in checkbox-by-checkbox detail is just as boring to read as it > is to write. Instead, think: What are the most likely reasons someone > will have trouble here? And what things are people most likely to be > looking for under a different name? Answer those questions (without > phrasing them as questions) in two or three paragraphs each. > <http://tinyurl.com/clrt3o> Do that, and you'll have something more > readable and more useful than ye olde Gnome Application Manuelle V2.7. Matthew is right on here. Element by element UI description rarely do anything to help the user. Instead I like to focus on "task oriented" documentation (opening a file, making changes, saving a file, making a backup). Try to group related tasks into sections, and try to put them in an order that the user is likely to need them in. Cross reference to more in-depth discussions if required. Include sidebars with information to educate and empower the user, using analogies and objects they can relate with. Your documents can still atrophy as buttons and labels change names and marks drawn on UI screenshots no longer resemble the current UI, but a lot of the prose will still be relevant and ideally even useful. --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: The future of the gstreamer volume-control applet.
On Tue, 2009-01-27 at 10:45 +, Bastien Nocera wrote: > On Tue, 2009-01-27 at 15:53 +1300, Callum McKenzie wrote: > > Three weeks ago I removed the gstreamer-based volume-control applet from > > the gnome-applets package at the request of the gnome-media crew. I then > > sat on the sidelines to see how the drama would play out. Now that the > > dust seems to have settled, I have decided to accommodate people > > (especially distro-people) who still don't Believe in pulseaudio. I have > > reinstated the applet, but it must be explicitly enabled. > > > > The argument for configure is --enable-mixer-applet. There are two > > gotchas: the support for gstreamer 0.8 is gone, only gstreamer 0.10 is > > supported (since I had to rewrite the autoconf stuff anyway, this was a > > good time to do it). I have also set jhbuild to enable the mixer, so > > bleeding edge people will get both forms of volume control. > > Do we still get a null-applet for the mixer applet when it's disabled? The null_applet should go away on your next gnome-panel run. If it doesn't, that's a bug. The idea behind the null_applet is that it vampires the OAFIID of the applet it's removing. Pops up a message saying that applet has gone away and then removes the entry from GConf. Because the entry has been removed, next time you start the panel null_applet shouldn't start. --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: New module decisions for 2.26
On Wed, 2009-01-21 at 19:20 +0100, Vincent Untz wrote: > brasero (desktop suite) This may have been covered elsewhere, but does Right-Click Burn Disc still work for ISO images? --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
how I write GTK+ theme?
I'm trying to get a feel for how hard it would be to write a tool similar to the Java Swing theme Napkin: http://napkinlaf.sourceforge.net/ I suspect that this can't be done with an existing gtk-engine. Is there any documentation around on how to write a GTK+ engine? --davyd -- 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: Any doc or sample code for using Libgnome-menu2 ?
Have you called gtk_init() or g_type_init() ?? (See the first warning). --d On Mon, Nov 10, 2008 at 03:03:42PM +0800, Liu, Raymond wrote: > Hi > I am trying to use libgnome-menu2 for desktop file info retrieve. > However I could not find any API reference or sample code on web or in > the source package. > Can anyone share some information on this to me? > > I did try to build and run the util/gnome-menu-spec-test, But it failed > with: > > $ ./gnome-menu-spec-test > > (lt-gnome-menu-spec-test:26922): GLib-GObject-CRITICAL **: > /build/buildd/glib2.0-2.16.6/gobject/gtype.c:2248: initialization assertion > failed, use IA__g_type_init() prior to this function > > (lt-gnome-menu-spec-test:26922): GLib-GObject-CRITICAL **: > g_type_interface_add_prerequisite: assertion `G_TYPE_IS_INTERFACE > (interface_type)' failed > > (lt-gnome-menu-spec-test:26922): GLib-CRITICAL **: g_once_init_leave: > assertion `initialization_value != 0' failed > > (lt-gnome-menu-spec-test:26922): GLib-GObject-CRITICAL **: > /build/buildd/glib2.0-2.16.6/gobject/gtype.c:2248: initialization assertion > failed, use IA__g_type_init() prior to this function > > (lt-gnome-menu-spec-test:26922): GLib-CRITICAL **: g_once_init_leave: > assertion `initialization_value != 0' failed > > (lt-gnome-menu-spec-test:26922): GLib-GObject-CRITICAL **: > /build/buildd/glib2.0-2.16.6/gobject/gtype.c:2248: initialization assertion > failed, use IA__g_type_init() prior to this function > > (lt-gnome-menu-spec-test:26922): GLib-CRITICAL **: g_once_init_leave: > assertion `initialization_value != 0' failed > > > Is there anything I need to do to run this test case, except the > ./configure make process ( I do have this library installed on my > ubuntu-8.04,so I don't use make install) ? Where can I find some doc and > sample code using this library? > > Best Regards, > Raymond Liu > > ___________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- 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: GTK adjustement changes create incompatible behaviour between versions?
On Mon, 2008-09-22 at 13:50 +0200, Sebastien Bacher wrote: > Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : > > If you've called the function in GTK+ directly, you never specify a > > page_size (it doesn't make sense). If you've set a non-zero page_size, > > it's really your own fault. > how do you expect the people using gtk to guess that? the > gtk_spin_button has no note about the adjustement and the example are > buggy and use a non null value Here: http://library.gnome.org/devel/gtk/stable/GtkAdjustment.html#GtkAdjustment--page-size Yes, the examples are wrong. Also redundant. You don't need to provide functions to access ints or floats. I admit, it was probably a bit mean of me to say to it's their own fault. I hadn't read the examples when I wrote that. --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: GTK adjustement changes create incompatible behaviour between versions?
On Mon, 2008-09-22 at 10:23 +0100, Ghee Teo wrote: > Davyd Madeley wrote: > > I think GTK+ is now doing the right thing. > > > > >From my understanding, this only affects UIs created with Glade (which > > has been setting a page_size of 10 -- and it seems still isn't fixed). > > > > Matt here developed a workaround for this in libglade. That sets the > > page_size to 0 and reports a warning that your app is broken. > > > This is GREAT! Does this imply the bug is in libglade since it does > not conform > to the GTK+ spec? Should the fix be made in libglade also so that new > glade file > will conform to the GTK+ glade. This is a complicated question. There are 3 ways I can think of to create a GtkSpinButton: - using GTK+; - using GtkBuilder; and - using libglade If you've called the function in GTK+ directly, you never specify a page_size (it doesn't make sense). If you've set a non-zero page_size, it's really your own fault. But if you've used Glade, you've got the problem that it was always setting the default page_size to 10. Since this never worked AFAIK, it seems unlikely that anyone was intentionally setting this to a value. You could probably safely add a workaround in libglade. I assume libglade will go away with GTK+ 3.0. But GtkBuilder doesn't go away for GTK+ 3.0. So by adding a workaround for GtkBuilder, we've made it so that you can never set a page_size, even if you wanted to. Off the top of my head, one option would be to make GtkBuilder 2.x fudge page_size to 0 and give a g_warning saying your app is broken with a #define GTK_BUILDER_ENFORCE_PAGE_SIZE to enforce the correct behaviour (which would be the only behaviour in 3.0). On the question of "why is Glade wrong". I notice (in older manuals at least) that while the docs tell you to set a page_size of 0. The examples don't actually follow this advice, and set page_size == page_increment .I've not checked the new manual to see if someone has corrected the examples. """ spinner_adj = (GtkAdjustment *) gtk_adjustment_new (2.500, 0.0, 5.0, 0.001, 0.1, 0.1); spinner = gtk_spin_button_new (spinner_adj, 0.001, 3); """ > > FWIW, I have mentioned this change in the developer section of the 2.24 > > release notes. > > > Have you a pointer to the latest 2.24 release note? http://svn.gnome.org/viewvc/release-notes/branches/gnome-2-24/ --davyd -- Davyd Madeley,Software Engineer Fugro Seismic Imaging, Perth, Australia http://www.fugro-fsi.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
I think GTK+ is now doing the right thing.
>From my understanding, this only affects UIs created with Glade (which
has been setting a page_size of 10 -- and it seems still isn't fixed).
Matt here developed a workaround for this in libglade. That sets the
page_size to 0 and reports a warning that your app is broken.
FWIW, I have mentioned this change in the developer section of the 2.24
release notes.
--davyd
On Mon, 2008-09-22 at 09:12 +0100, Ghee Teo wrote:
> Hi Vincent,
>
> While you have just announced 2.24.0 tarballs to be available for 22nd Sep.
> Does this mean we are going to ship 2.24.0 without an possible
> resolution to this regression?
> Since applications would not have a change to workaround this should
> gtk+ is not going to
> back up this feature. If gtk+ going to back out this feature, it can
> only be done after 23rd Sept!
>
> Have the release team considered moving the 2.24.0 release date by a
> couple of days to
> accommodate this?
>
> -Ghee
>
> Vincent Untz wrote:
> > Le vendredi 19 septembre 2008, à 09:17 -0400, Matthias Clasen a écrit :
> >
> >> I don't see any way around discussing this with the GTK+ team before
> >> taking any decisions.
> >>
> >
> > I was hoping this would be discussed on gtk-devel-list and that a
> > decision would have been taken there :/
> >
> >
> >> If you think this is a blocker for 2.24, then having it reverted on
> >> September 23 should still be good for a Gnome release on September 24.
> >>
> >
> > Hrm, well, that's definitely late for smoketesting...
> >
> > Vincent
> >
> >
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Davyd MadeleySoftware Engineer
Fugro Seismic Imaging, Perth Australia
--- libglade-2.6.3/glade/glade-gtk.c.orig 2008-08-18 15:58:59.0 +0800
+++ libglade-2.6.3/glade/glade-gtk.c 2008-09-22 11:59:39.0 +0800
@@ -1130,6 +1130,31 @@
return NULL;
}
+static GtkWidget *
+fsi_glade_build_gtkspinbutton(GladeXML *xml, GType widget_type,
+ GladeWidgetInfo *info)
+{
+GtkWidget *w;
+w = glade_standard_build_widget(xml, widget_type, info);
+if (w) {
+GObject *adj;
+g_object_get(w, "adjustment", &adj, NULL);
+if (adj) {
+double page_size;
+g_object_get(adj, "page_size", &page_size, NULL);
+if (page_size != 0.0)
+{
+g_warning ("Spin button '%s' has non-zero page_size (%f). Workaround applied.",
+ info->name, page_size);
+}
+page_size = 0;
+g_object_set(adj, "page_size", &page_size, NULL);
+g_object_unref(adj);
+}
+}
+return w;
+}
+
void
_glade_init_gtk_widgets(void)
{
@@ -1313,7 +1338,7 @@
glade_register_widget (GTK_TYPE_SOCKET, glade_standard_build_widget,
NULL, NULL);
#endif
-glade_register_widget (GTK_TYPE_SPIN_BUTTON, glade_standard_build_widget,
+glade_register_widget (GTK_TYPE_SPIN_BUTTON, fsi_glade_build_gtkspinbutton,
NULL, NULL);
glade_register_widget (GTK_TYPE_STATUSBAR, glade_standard_build_widget,
NULL, NULL);
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help sanity check the release notes
On Mon, 2008-03-03 at 14:19 +0100, Vincent Untz wrote: > Some comments by Olav (he's at work right now, so I'm his slave sending > his mails): > > + Simplified Keyboard Settings: not an administrator thingy IMO Ok. > + 'the often requested column and list views in GNOME's File Manager': >column / list view Ok. > + we're missing a paragraph about some changes/deprecations in the >platform/desktop: > - gnome-vfs: deprecated thanks to gio Mentioned in What's New For Developers already. > - gnome-keyring-manager: finally removed thanks to seahorse Was not documented, but Ok. > - libxml2/libxslt: moved to external dependencies since they are > really part of the OS platform Ok. --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: help sanity check the release notes
On Sun, 2008-03-02 at 08:21 -0300, Jonh Wendell wrote: > BTW, What do you think about this little change in rnusers.xml? > > -gconftool-2 -s > +gconftool-2 -s > ... > -true > +true > > (Just moved /command to the end of sentence) If it's correct I'm happy. -- 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: help sanity check the release notes
Ok. I've incorporated the suggestions you've sent me (thanks all) and I'm pretty sure there are no more XXXs. If people want to read over them one more time, Olav has moved the r-n to svn+ssh://svn.gnome.org/svn/release-notes/branches/gnome-2-22 It's not my best work, but I think that the text is probably ready to sign off on so that the translators can make a start on it. Release team? While translation is taking place, I will attempt to liaise with Andreas about getting the screenshots in place. --d On Wed, 2008-02-27 at 22:04 +0900, Davyd Madeley wrote: > Because my GNOME 2.22 isn't actually working very well, the release > notes currently contain a lot of FIXMEs and XXX entries. This is > suboptimal. -- 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
help sanity check the release notes
All, Because my GNOME 2.22 isn't actually working very well, the release notes currently contain a lot of FIXMEs and XXX entries. This is suboptimal. What this means is that if you think you have a stake in the release notes, you should sanity check them for me. It's really easy to do: Step 1. Check them out from SVN: svn co svn+ssh://svn.gnome.org/svn/gnomeweb-wml/trunk/www.gnome.org/start/2.22/ release-notes-2.22 Step 2. Load release-notes.xml in Yelp Step 3. Read, make notes or send patches. Pay special attention to anything marked XXX or FIXME (could be in a comment). Andreas Nilsson has volunteered to do the screenshots this time round. Thanks Andreas! -- 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: Module proposal: GtkGLExt for GNOME 2.22
Having recently used GtkGLExt, I thought I'd throw in my 2c worth. GtkGLExt appears to work, but it seems to be very picky about when things are realized and shown. I found the ordering for setting up the space to change depending on whether or not I was using Glade and when I wanted to do certain GL operations. The documentation is sporadic and rather unclear. I think the documentation needs to include a couple of very straightforward top-to-bottom examples of how you use this widget (this would probably be less of a problem if it wasn't for the weird initialisation idiosyncrasies). On the whole however, it did manage to get the job done. I think that having a GL widget in GTK+ is not a terrible idea. --davyd On Sat, 2007-09-22 at 14:22 +0200, Vincent Untz wrote: > Hi Andreas, > > Le samedi 22 septembre 2007, à 13:57 +0200, Andreas Røsdal a écrit : > > Hello! > > > > * Proposal: Include GtkGLExt in the GNOME developer platform. > > Oh, interesting. > > Note that it's possible that it will get rejected for the platform if it > doesn't go in the desktop for at least one cycle, since we're quite > strict about the platform. So maybe you should propose it for the > desktop first? > > > However, GtkGLExt is currently unmaintained. I will volunteer to maintain > > it if accepted as a GNOME module, and hope to work with the GNOME community > > to make it fit in well as a GNOME module. > > Well, it won't be accepted if it's unmaintained. So you should do things > the other way around: start maintaining it before it can get accepted. > > > There has also been a lot of discussion about this in bug #119189 > > "Add OpenGL support to GTK+". > > I gave a really quick look at the bug, and there doesn't seem to be any > decision there. Are there any specific plans? > > Thanks, > > Vincent > -- 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: Module maintenance: problems and oportunities
On Mon, Jun 25, 2007 at 06:29:57PM +0200, Beno?t Dejean wrote: > Le dimanche 24 juin 2007 ?? 18:54 +0300, Lucas Rocha a ??crit : > > Hi all, > > > > I've been checking our latest development releases (2.19.x) and > > noticed that some modules haven't had any releases so far in this > > development cycle. Here's a list of some of those modules: > > > > - bug-buddy > > - gedit > > - gnome-applets > > I've always been around multiload_applet2. gnome-applets is a collection > of applets and there are already sub-maintainer. I'd like to > commit/work/etc on multiload but my patches are stalled on bugzilla. I > don't want to be the maintainer of gnome-applets but i can surely handle > multiload. Hey "chief" (davyd), would you promote me ? Benoit, to my mind, you've been the multiload submaintainer for some time. Feel free to commit to multiload, but obviously use your discretion. Apologies for my poor performance as maintainer this year, I've simply been too busy, and when I've not been busy, I've been too exhausted. I am still trying to get a team of people willing to assist with maintanence tasks together, although so far I'm not having a lot of luck. I don't want to dump another module onto Vincent, Elijah, Lucas because no one else will maintain it. --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: Updating our list of GNOME contributors
On Wed, Mar 07, 2007 at 12:01:28AM +0100, Vincent Untz wrote: > Le mardi 06 mars 2007, ? 17:31, Behdad Esfahbod a ?crit : > > On Tue, 2007-03-06 at 22:31 +0100, Vincent Untz wrote: > > > It'd be great to have the non-ascii characters in hexa, so for example: > > > "Mariano Su\xc3\xa1rez-Alvarez" instead of "Mariano Su?rez-Alvarez". > > > > Any reason for hex encoding? That's ugly, and we should handle UTF-8 > > just fine. > > Because it's a C string, and we're not using UTF-8 in our source code, I > believe. Old policy, or something like this. It's a good policy. Nothing worse than having someone accidently get the wrong character encoding and stuff up your source code completely. It's easier to keep the source 7-bit clean, we don't type that many names that it is a pain. --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: Synchronising an app with the system clock
On Wed, Feb 14, 2007 at 07:28:38PM +, Alex Jones wrote: > Hi list > > I wrote a quick app to alert me every time the clock strikes the hour. > Unfortunately, I found no better way to do this than to check, every > second, to see if the current local time's minutes and seconds are 0. > > This involves a glib timeout of 1000ms, which I understand is not 100% > guaranteed to work because it might skip from, e.g. 15:59:59.999 to > 16:00:01.000 if I am unlucky and it actually takes 1001ms to fire. You > might think to increase the resolution to 500ms, but then I need to keep > track of state to make sure I don't fire the alarm twice. This quickly > gets out of hand. > > I initially thought of just checking the current time, and then > calculating how long until the hour, and sleeping until then. There is a > problem with this, however, in that if the time changes, the alarm will > go off at the wrong time as it has no knowledge of the clock change. > > What I want to do is have some way of absolutely synchronising an app > with the system clock. I've considered a kind of D-Bus system clock > service that could emit signals every second so that apps could > synchronise to that and all dance in time, but that itself would need > synchronising somehow, so the problem remains. Is there some way to > interface with the kernel for this kind of thing? > > Any other ideas/comments? Add this to your crontab (crontab -e): 0 * * * * for i in `seq \`date +%I\``; do play "bong.wav" ; done --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: pulseaudio vs gnome
On Fri, 2007-01-19 at 23:36 +, Damon Chaplin wrote: > On Fri, 2007-01-19 at 11:36 -0500, Matthias Clasen wrote: > > Hey, I just wondered what the current state of affairs is in the > > esound -> pulseaudio transition. I found a wiki page > > (http://live.gnome.org/PulseAudio?highlight=%28pulse%29), > > but I'm not sure how uptodate it is. > > > > Is this something that we can still complete for 2.18 ? > > Is anybody working on this ? > > Before it goes in I'd like to see a clear roadmap for audio in GNOME, > with support for things from simple beeps up to pro-audio apps. > > I guess this means gstreamer, PulseAudio and JACK. Is that the plan? Lennart, who develops PulseAudio, recently spoke about it at linux.conf.au: http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.ogg (disclaimer, I don't know what the video quality is like) He speaks about what PulseAudio can do, why you'd chose it over technology X and how it might integrate with specific problem domain technologies, such as Jack. Might clear some things up. --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: Proposed suite: developer tools
On Thu, 2007-01-11 at 13:47 +0100, Vincent Untz wrote: > Le mercredi 10 janvier 2007, à 12:56, Tristan Van Berkom a écrit : > > So for my part - I think holding back might send a message that this > > thing is bigger and scarier than it really is (or should be), which is > > just better coordination among related projects and better visibility > > of stable releases and schedules. > > On the other hand, if we hold back and have more modules for 2.20 than > for 2.18, this might make more noise and attract more people :-) > > Should we consider this kind of marketing arguments? > > (Oh, and I like the idea, and I want such a suite. I've no strong > opinion on whether we should do it now or wait a cycle to have more > tools) I remember being around when people were first bouncing around the idea of a developer's suite and I'd love to see it a reality, but you're bringing up an interesting point. If we did it now, we'll probably have Devhelp and Glade-3. For G20 we might add Nerimeriver (how do you spell it?) and maybe Anjuta. I'm not sure on what the timeline for GtkBuilder is, but an interface editor at that point would certainly be a wonderful complement. That said, there are still people who have never heard of Devhelp, if we had an official developer set, maybe it would get more press and as soon as possible. So, I would be tempted to add it now, and add the debugger/IDE next time, but there is certainly a case to go for the suite-grande next time around. --d PS. I have been drinking, if this doesn't make sense, that is why. -- 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: [bug-buddy]: Custom scripts for your application
On Fri, 2006-12-01 at 12:11 -0600, Shaun McCance wrote:
> I think most (non-hacker) users will look at a stack trace and not
> even bother trying to figure out where their personal information
> might be inside it. Maybe adding a find dialog/bar would make them
> a bit more likely to do so ("Does it say hotsexychicks.com in here
> anywhere?"), but I doubt it would make much of a difference.
Perhaps we can write some intelligence metric in here. Where we search
for things that may be leaking passwords or URLs or usernames or server
IPs, etc. This could be as low tech as searching for specific variable
names or functions that are known to deal with sensitive data. It would
then display a:
/!\ Warning, this crash report may contain sensitive data, click here to
highlight it.
Alternatively, and possibly harder, have a button that will remove the
contents of strings (which are most like to leak sensitive data) by
replacing each character with an X. I am not sure how you would still
preserve the fact that strings are corrupted, if that caused your crash.
> Maybe we should find a way to make files submitted from Bug Buddy
> private. A trusted few would have access to them. We'd have some
> nice interface for reviewing submitted files, and the trusted few
> could look through them for anything that looks, well, bad. If a
> file is clean, it gets marked public. Otherwise, it is completely
> deleted from the server.
This could be as simple as a checkbox:
[ ] make this information private
But that might become awfully popular.
--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: bug-buddy was branched silently some time ago
On Tue, 2006-11-28 at 21:14 +0100, Andre Klapper wrote: > if every gnome bugzilla product has a boolean value providing its > maintenance state, we can also tell the user that he/she should not > expect fixes, as that product is currently unmaintained. Perhaps we could do something like calculate a moving average of the time from UNCONFIRMED->something and use that to assign an activity value between Inactive <-> Very Active. Perhaps we would be able to give the user an idea of the approximate lead time on this bug. eg. "On average, bugs in GNOME-Applets will be replied to within 6 days". --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: proposed architecture evolutions for GConf
On Sat, 2006-11-11 at 12:02 +0100, Josselin Mouette wrote: > There are several ways to deal with a single-session, single-host > configuration engine. Real problems arise when the user can log in > several times on different machines, with a shared filesystem. With the > number of corporate users working over NFS, this is not something we can > ignore. It is possible to write alternative GConf backends. I recall that Sun have written one that uses LDAP, its name starts with an A, but I can't recall what it is. Would this solve your problem? --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: gnome-power-manager and battstat-applet
On Fri, 2006-11-10 at 10:52 +, Richard Hughes wrote: > > What magic are you missing? The graphs? > > * Processor frequency scaling? > * Laptop panel auto-dimming? > * Setting low power mode (laptopmode) using HAL? > * Auto-suspend when idle? > * DPMS control? > * Configurable buttons? > * DBUS interface for other applications to use > * Inhibit and UnInhibit methods How are all of these required in a monitoring applet? These should all be handled by the daemon. It's quite possible to run the daemon (silently) and the applet together. > g-p-m will not use the existing applet API. The new API by Ryan Lortie > looks really good and when it hits HEAD I'll experiment and see how easy > it would be to make a movable icon with text next to it in the existing > codebase. There's already a bug open. No, I would not recommend writing an applet for something like g-p-m on top of this API. I'm not sure how far along Ryan is with the new API, I'm hoping to do some experimentation and port some code over the Australian summer. To my mind, it makes sense to keep the display component as a standalone process that can be started by gnome-power-manager. There is little point in dropping all of that compatibility code, even if everyone now has HAL. If gnome-power-manager broke the display components of the daemon from the management components, then it would also become possible to write arbitrary views on top of the daemon, be it for an applet, a notification icon, a gdesklet, some kind of Hildon widget or whatever. This was always an abstraction I envisioned, allowing g-p-m to be portable in the same way that NetworkManager is. --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: gnome-power-manager and battstat-applet
On Fri, 2006-11-10 at 10:35 +0100, Diego Escalante wrote: > I would like to see either the battery applet and g-p-m coexisting or > g-p-m providing an applet equally informative as the battery applet, > but of course with all the g-p-m magic. What magic are you missing? The graphs? --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: gnome-power-manager and battstat-applet
On Thu, Nov 09, 2006 at 01:07:22AM +, Richard Hughes wrote: > In 2-15 we discussed including *both* gnome-power-manager and > battstat-applet in the release but I don't think we came to any hard > decisions. > > Now, with the greater integration of gnome-power-manager into other > desktop components, my opinion is we should drop battstat-applet from > the release. I think it's done a great job for many years, but I think > most (all?) distros are shipping g-p-m by default now (rather than the > applet) and having the applet as an option is superfluous. > > So, has anybody got any good reasons (or use-cases) for not doing so? I > think it's safe to assume that anybody using gnome 2.17.x uses HAL[1]. Placing these sorts of items in the notification really is an abuse of what it's for. I've spoken extensively on this topic. The new applets API will allow applets to be programmatically started (like notification icons). This should allow us to bridge the best of both worlds. Might also improve things for Tomboy, Gossip and all those other applications that experience this problem. --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: Playing a sound in GNOME
On Tue, 2006-10-31 at 11:09 +, Jono Bacon wrote: > On 10/30/06, Richard Hughes <[EMAIL PROTECTED]> wrote: > > I think whatever is done, there needs to be a way for application "foo" > > to play file "ding.wav" without worrying about the intricacies of > > gstreamer. Don't get me wrong, the gstreamer API is great (and really > > powerful) but somewhat complicated when you just want a "alert" sound > > from the speakers. > > I think we need to ensure that these kinds of things are simple for > application developers, but we also don't want to undermine the really > powerful GStreamer framework by stepping over it. > > To me the solution here is a small API that talks to GStreamer that > makes these things easier. A very small Phonon equivilent if you like. > I am not talking about abstracting lots of sound backends away like > Phonon does, but just providing a bunch of methods to make a ding or > equivalent message which in turn generates the relevant GStreamer > pipeline. Perhaps the answer is to fix up the existing API: http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-sound.html The API currently depends on libesd, because it does things like server side caching. Porting it to GStreamer and retaining all functionality would involve writing a caching interface for GStreamer. --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: jhbuild failing due to cvs conflicts
On Sun, 2006-10-29 at 16:43 +, Gustavo J. A. M. Carneiro wrote: > > > However, there's one more major problem standing in our way to smooth > > > jhbuilding. It seems that many modules are still producing cvs > > > conflicts in po files. For example: > > > > > I am _sure_ I didn't personally change any gstreamer po file; logic > > > dictates that I should not therefore be penalized by cvs conflicts. > > > What's happening here? Can it be fixed? > > > > (At a guess) They're being changed when you build. Something is running > > an intltool merge. I thought we had stopped this behaviour from > > happening (it used to always happen with make dist). Of course, this is > > GStreamer, so their build system probably runs a little differently. > > You're probably right that something during build is changing the po > files, but two things to note: > >1. I'm not completely sure, but I think this happened also with > another package, not gst*, though I don't remember the name; Certainly possible. >2. I certainly never did a "make dist" on any gst package. I meant this more as an illustrative example of what used to happen when building GNOME, not with what would cause it in GStreamer. --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: jhbuild failing due to cvs conflicts
On Sun, 2006-10-29 at 12:43 +, Gustavo J. A. M. Carneiro wrote: > However, there's one more major problem standing in our way to smooth > jhbuilding. It seems that many modules are still producing cvs > conflicts in po files. For example: > I am _sure_ I didn't personally change any gstreamer po file; logic > dictates that I should not therefore be penalized by cvs conflicts. > What's happening here? Can it be fixed? (At a guess) They're being changed when you build. Something is running an intltool merge. I thought we had stopped this behaviour from happening (it used to always happen with make dist). Of course, this is GStreamer, so their build system probably runs a little differently. --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: Notifications for build & release issues: gnome-control-center
On Sat, 2006-10-21 at 13:07 +0100, Joachim Noreiko wrote: > > is also fun: > > http://www.gtkmm.org/jhbuild_dot_gnome_desktop.png > > It doesn't generate an SVG that can be cleaned up a > bit by hand and despaghettified? You can get out SVG. Though, from memory, the problem of generating planar, directed graphs is NP-complete. Obviously we should load the dependency tree as a level in gplanarity. --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: Notifications for build & release issues: gnome-control-center
On Fri, 2006-10-20 at 22:09 +0100, Thomas Wood wrote: > Do we currently have a dependency and module documentation on-line > somewhere? I have had several people ask me about such information (or > moan about the lack of). It would be good to have a build guide for ISVs > at the very least. GNOME is becoming more and more difficult to build > and package because of the lack of this type of documentation (these are > comments I've had from both individuals and people involved in small > distributions). If it is available somewhere, we need better publicise > it better. In many respects, jhbuild _is_ the dependency tree for building GNOME. A mode like `jhbuild list` will give you a list of packages you need to build. It would be easily possible to put the output of this command on a webpage if people thought they needed that. --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
Bacon, Bonobo, Sockets and Strangeness
Here is the picture, I have an app for which I want single instance capabilities. To do this, I use libbacon. This app uses Bonobo to connect to some factories. If the app crashes, it leaves its socket for Bacon lying around (as you might expect), the factories are also still running. When you start the app back up, it finds the socket and attempts to connect() to it, this succeeds and netstat marks the socket in the state CONNECTING, but there is no server process to answer this socket. This is where it gets weird. If you kill the Bonobo factories it will all work fine. You can crash out the application, then kill the factories it was connecting to, but leave the socket lying around. Bacon will attempt to connect() to the socket, which will fail, which it will note and become the server. How is it, that a factory which is not the original server of the socket can be responsible for holding a socket open after the parent has been killed? --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: Proposal to enable accessibility by default for GNOME development releases
On Sat, 2006-10-14 at 19:48 -0400, David Bolter wrote: > As we see more and more software consuming the at-spi interfaces (gui > testing tools, screen readers, on-screen keyboards, at-poke, gui event > loggers) it just makes sense to get as much testing coverage as > possible. Let's fix the bugs in the development releases. I agree this is a good idea. I once tried to write a tool that used the SPI framework, but got discouraged because things I needed like the Terminal behaved strangely (I filed this and discovered it was a known issue). These issues would only exist for mere days if the people who know how to fix them are experiencing them. --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
gnome-applets branched
Sergey Udaltsov has branched gnome-applets. Stable branch is gnome-2-16. Development will be happening in HEAD. --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: 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: Glade 3.0 stable branched
On Fri, 2006-09-29 at 19:46 -0700, Jeff Waugh wrote: > > > > I just wrote this mail up because I read > > http://live.gnome.org/MaintainersCorner and thought to notify all the > > relevent lists. Worthy of note is that I am writing d-d-l but glade is not > > part of the gnome desktop module group - while I do have some ideas on > > that matter I dont feel like writing up a 10 page essay on it so... > > suffice it to say "do we want glade as part of some gnome module set" ? > > any ideas on that ? > > We should *totally* have a developer tools suite. I agree. --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: yelp Compilation error.
On Wed, 2006-09-20 at 00:42 +, PardoX PardoX wrote: > yes, i have those files > /usr/lib/MozillaFirefox/include/gtkembedmoz/gtkmozembed.h > /usr/lib/MozillaFirefox/include/gtkembedmoz/gtkmozembed_internal.h Where is libgtkmozembed.so. That is what it claims it can't find. --d > -L/usr/lib/MozillaFirefox -L/usr/lib/ -lgtkembedmoz ... > -Wl,--rpath -Wl,/usr/lib/MozillaFirefox > /usr/bin/ld: cannot find -lgtkembedmoz > collect2: ld returned 1 exit status > make[3]: *** [yelp] Error 1 > ********* -- 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: [Usability] Drive applet by default
On Thu, 2006-09-14 at 17:43 +0200, Xavier Bestel wrote: > On Thu, 2006-09-14 at 14:55, Michael Banck wrote: > > On Thu, Sep 14, 2006 at 02:05:49PM +0200, Isak Savo wrote: > > > I think he's talking about the fact that when you "unmount" a USB > > > device in windows, the devices are often turning off their leds to > > > indicate that they are now turned off. When unmounting in linux, this > > > is often not the case (although the device *is* properly unmounted and > > > data is flushed, so it's just a cosmetic thing.). > > > > My iAudio M3 says "Do not disconnect!" on its display even after > > unmounting, I don't think this is only cosmetic. > > I guess it's because the USB port hasn't been powered down, so your M3 > has no way to know it's no more in use. Usually they're listening for the eject sequence (as sent by the eject program). If the port was powered down, the iPod wouldn't be able to be charged, even thought it is safe to disconnect. Some devices don't listen for this sequence, I don't think there is a simple solution for this. --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: Planning Gnome Scan Inclusion
On Sun, Sep 10, 2006 at 05:47:47PM +0200, ?tienne Bersac wrote: > > I know. I'll wait for the massive SVN migration. When is that happening, by the way? --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: gnome-utils branched for GNOME 2.16
On Mon, Sep 04, 2006 at 09:33:29PM +1000, Jeff Waugh wrote: > > > > > At the moment, it is fairly difficult to do a window selection unless > > > you know the secret password (key combo or CLI parameters). An optional > > > two step process (made optional by defaulting to full screen as it works > > > now) would help with that. > > > > The problem is that I really don't know how to make the Screenshot utility > > work with a two-step flow without having people screaming at my doorstep > > because I disrupted their one-step flow. :-) And I quite agree with them: > > taking a shot of the screen should require the least possible iterations, > > especially if you want to take loads of shots. > > I mentioned above that the second step can be made optional, simply by doing > what we're already doing - take a full screen shot by default, but prompt to > use other tools as well as saving. So if you're taking full screen shots (by > pressing PrintScreen) or current-window shots (by pressing Alt-PrintScreen), > your workflow is not interrupted at all. > > But if you want to grab a region, select a window, or take a video, you can > clicky-click to the next step (which brings you back to the "ready to save" > window again anyway). Rectangle select has been on my work TODO list for a while. Unfortunately I've not gotten around to it. I imagined it would work much like how Jeff described. --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: your mail
Bloody mutt! On Sun, Sep 03, 2006 at 07:56:30PM +0800, Davyd Madeley wrote: > [EMAIL PROTECTED] > Bcc: > Subject: Re: Request for patch review and freeze break in evolution > Reply-To: > In-Reply-To: <[EMAIL PROTECTED]> > > On Sun, Sep 03, 2006 at 01:15:34PM +0400, Nickolay V. Shmyrev wrote: > > Hi all > > Bug 334966 ??? Evolution crashes sometimes when closing main window > > http://bugzilla.gnome.org/show_bug.cgi?id=334966 > > > > is a critical bug with more than 30 duplicates. It has simple patch > > included that should fix the problem. I think someone should review the > > patch and break code freeze to make users happy. > > > > You need to contact release-team. I have CC'ed them here. > > --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 -- 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
[no subject]
[EMAIL PROTECTED] Bcc: Subject: Re: Request for patch review and freeze break in evolution Reply-To: In-Reply-To: <[EMAIL PROTECTED]> On Sun, Sep 03, 2006 at 01:15:34PM +0400, Nickolay V. Shmyrev wrote: > Hi all > Bug 334966 ??? Evolution crashes sometimes when closing main window > http://bugzilla.gnome.org/show_bug.cgi?id=334966 > > is a critical bug with more than 30 duplicates. It has simple patch > included that should fix the problem. I think someone should review the > patch and break code freeze to make users happy. > You need to contact release-team. I have CC'ed them here. --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: New panel layout for GNOME 2.18?
On Tue, Aug 22, 2006 at 11:05:50PM +0200, David Nielsen wrote: > tir, 22 08 2006 kl. 17:53 -0300, skrev theblues gnr: > > > I don't think an usability test has ever been done with the current layout. > > At least I never heard of one. > > BetterDesktop seems to have done this, slab is part of the result of > those tests. There was also extensive testing by Sun back in the day. --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: sticky-notes -> tomboy conversion
On Tue, Aug 22, 2006 at 01:04:14PM -0400, Matthias Clasen wrote: > On 8/22/06, Sanford Armstrong <[EMAIL PROTECTED]> wrote: > > On 8/22/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > > > > So, can we please make the sticky notes import happen automatically and > > > unintrusively at startup ? After all, we already replaced the applet > > > itself > > > without asking the user... > > > > This is in progress and will be in Real Soon Now. > > > > Of course, if the sticky-notes deprecation was premature, and sticky-notes > will be back for another round in 2.16 I removed the flag to automagically upgrade it. I misunderstood the intent of the release-team. --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: New module decisions for 2.16
On Wed, Aug 09, 2006 at 03:08:40PM +0200, Vincent Untz wrote: > On mar, 2006-08-01 at 14:31 -0600, Elijah Newren wrote: > > + Sticky notes > >=> mostly duplicates functionality of Tomboy > >=> general agreement to deprecate sticky notes for now and remove > > it in a later release > >=> 'deprecation' means hidden from the user and some kind of > > warning for those trying to use it > > Davyd, is there anything we can do to help here, or is this something > you can handle? Ok. Here is a suggested migration path. Since some users will not be able to use Tomboy (on systems that are not Mono enabled), we should keep stickynotes around. I propose we do the same as we currently do with mini-commander, that is by default it will transparently upgrade people's stickynotes to tomboy. We then have a --enable-stickynotes flag, that will cause stickynotes to be compiled and installed (installing with this flag will also cause people's whose stickynotes to get upgraded to Tomboy will then cause it to go back again). We then leave it up to package distributors to decide if they want to break this out as a separate package or not. Sound reasonable? -- 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
GWeather Locations DB major update - CHECK YOUR LOCATION NOW!
People have noticed that at one point we accidentally added a lot of dead locations to the GWeather database. Frank Solensky has been monitoring the locations to count the number of reports from every location. I have then knocked together a quick Python script to remove all the locations that had zero reports over the last half a year. What we need you to do is QA our data through random sampling. Step 1. Find out your current location (assumed to be working): >From a terminal: gconftool-2 -R /apps/panel/applets | less Search for "GWeather" (type: /Gweather) Scroll down to find "location1 = ", is your location code Step 2. Consult the station report (http://bugzilla.gnome.org/attachment.cgi?id=70488) Search for your location code, and check to see that reports have been recorded. For a working location, the numbers should be relatively large. The last number is a total. If your number is small but your location works in GWeather, please tell us. Step 3. Consult the removal report (http://bugzilla.gnome.org/attachment.cgi?id=70500) This is a list of locations we intend to remove. Search for your location code. Assuming your number wasn't small, it shouldn't appear here. If it does, please tell us. Step 4. Consult the patch (http://bugzilla.gnome.org/attachment.cgi?id=70501) This is the actual patch I intend to apply to the Locations database. It should only remove locations indicated on the removal report above. Search for your location code, if your location exists, and is not on the report, it probably won't appear. If it does appear, it shouldn't be prefixed with '-'s. If it is prefixed with '-'s, then it is marked to be removed, in that case, PLEASE TELL US. This distributed proofing is incredibly useful, thank you in advance. --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
D-BUS and Xforwarding.
On Sun, Aug 06, 2006 at 04:20:58PM -0400, Havoc Pennington wrote: > Shaun McCance wrote: > > One really good reason I can think of is that > > D-Bus can't yet handle remote X applications. > > It would kind of suck for those not to be able > > to interact with the session manager. > > > > It should be able to handle them fine. The default configuration doesn't > listen on tcp but you just add a line like: > > tcp:host=whatever,port=whatever > > and then it should work fine, at least I think it should. Though I don't > know if anyone has tested it lately. > > Also ssh doesn't know how to forward DBUS_SESSION_BUS_ADDRESS, so you > have to do it manually the way you had to do it manually for DISPLAY > back in the day. I think we're going onto another topic here, but one that really needs to be addressed. X forwarding is incredibly useful and a lot of people are using it. While D-BUS at the moment will work for the LTSP and straight Xterminal case, it doesn't currently handle the so called 'fat client' case, where my local workstation does most of my day to day desktop needs, and I can log into a remote server to run my CPU intensive/pain in the neck to license application (I don't feel this is an edge case we shouldn't design for). The increased use of D-BUS for IPC of things that are tied into the X session (screensaver inhibiting, power management control, program status [mathusalem], &c.) means we need a way to extend the bus across the network. Ideally, we should be able to do this securely, and without having to change too much stuff. I have pondered the idea of a Dbus-over-X bridge. That is, when attempting to connect to the session bus, it detects that DISPLAY implies you're on a remote machine, and then uses X11 to communicate with the same machine that is running your X server via a bus proxy back to the session daemon. This seems a bit crack, but has the advantage of being secure, relatively easy to implement (I think), requiring no additional authentication mechanisms and working as expected in the case of multiple users from multiple machines having multiple connections to the remote machine all using the same username (this happens!). As with X11, the value of DISPLAY becomes the key to make it work. Unfortunately, as it stands, this is going to break some important cases, the Xterminal case, where DISPLAY is scully:0, but _all_ processes are running on the remote machine, won't be able to find a bus daemon, but I'm sure this can be addressed. --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: Baobab
On Thu, 2006-07-27 at 09:33 +0100, Emmanuele Bassi wrote: > If even a single mail saying "we'll keep it in check and decide later" > would have been useful: I would have kept a finger on the trigger. Now > it looks like I did something wrong because I merged a utility without > the consent of the community - and that makes me look I'm stupid. Please don't get anyone wrong here. I don't think this reflects on either you or anyone else here. This is simply part of the development process, and I'm just saying that perhaps we should take a step back and reevaluate. --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: Baobab
On Wed, 2006-07-26 at 17:47 -0700, Jeff Waugh wrote: > > > > The GNOME Utilities package is a small package that GNOME has kept since > > the 1.x era (and before); it provides some application other than baobab, > > like the screenshoter, the file search dialog, the dictionary and the > > system log viewer, that are not sufficiently big to warrant their own > > package but at the same time are considered part of the basic offering of > > GNOME itself. > > I think Davyd's question was more about whether Baobab (or its function) is > suitable to be considered part of the basic offering of GNOME itself. I am > not convinced it should be there myself. As Jeff said. This smacks of KDE/GNOME 1.2 feature creep. Please don't get me wrong, it seems like a useful application (little rough around the edges, but that can be fixed), but does it belong in core GNOME? --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
Baobab
Perhaps this has been discussed, and I missed it, but... Looking through the change sets, I see gnome-utils has now included the application Baobab. This is quite a handy utility if you wish to analyse your disk space usage, but I am wondering if this application really forms part of what one would consider 'Desktop'. It very much seems like a 3rd party utility at the moment that has simply been included in the core release. This harks back to the discussion about what should be considered 'Desktop', but for the case of Baobab, perhaps we can distill this down to three fundamental questions: - is it mature enough? - is it useful enough to the majority of our users? and - could this idea be integrated more tightly into existing software that the user is familiar with (eg. making it a Nautilus View) --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: Noticed in passing
On Fri, 2006-07-07 at 18:18 -0400, Matthias Clasen wrote: > On 7/7/06, Sergey Udaltsov <[EMAIL PROTECTED]> wrote: > > > Here they are: > > http://cvs.gnome.org/viewcvs/gswitchit_plugins/ > > They are some extra featurelets people asked - which would never be > > approved by HIG. Especially important: helping people using the flags > > for indication. > > Flags !!! I knew it. Yes. The secret flags backdoor. Perhaps we should look at how the plugins UI is exposed in the applet. >From memory at the moment, it is in the right click menu. Perhaps this is not the right place? --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: preserving user configuration
On Fri, 2006-07-07 at 18:16 -0400, Matthias Clasen wrote: > On 7/7/06, Raphael Slinckx <[EMAIL PROTECTED]> wrote: > > > > Yes, the implementation is lagging a bit. > > The interesting thing about it, is that there is no other way to > > preserve settings from gtik than to walk the gconf key > > /apps/panel/applets, look for directories names applet_*, look into each > > directory if the bonobo OAFIID correspond to gtik's one, then extracts > > information from gtik gconf schema and import it. Note that there is > > apparently no way to know if you have multiple applet_* matching, which > > one is the real, corresponding to the running instance of gtik (or maybe > > you have more than one instance and then you're even more screwed). > > > > I agree it sounds mildly painful. I was thinking about this. We replace one applet with the other using the .server file, so it seems to me that the panel may have allocated it the same preferences tree inside GConf (I need to actually confirm this). In this case, we can easily check to see if we have any preferences for Gtik inside this section of the tree. I'll try and test this now. --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: libgswitchit: from virtual module to separate library
On Wed, 2006-07-05 at 15:53 +0100, Sergey Udaltsov wrote: > Currently, libgswitchit (not same as libxklavier!) is used as a > virtual module in the gnome-control-center and gnome-applets. There is > a plot to use it in the gnome-screensaver as well. There are 2 > options: > - Again, use it a virtual module > - Finally, create separate module with its own build system, headers > and (shared) library (as if GNOME does not have enough libraries). > > I am considering the second option. Any comments? The second option makes sense, but what can we do to decrease the amount of API churn that is seen throughout the keyboard switching code? It always seems to be breaking compatibility. Especially if the number of users is getting up to three+ (maybe gdm would like it too?). --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: Buildability of tarballs and cvs
On Fri, Jun 16, 2006 at 05:26:36PM -0600, Elijah Newren wrote: > gnome-applets 344995 last tarball (2.14.2) doesn't build with 2.15.x I suck. I think CVS builds though (it should have support for the new libxklavier). --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: Ekiga branched
On Wed, 2006-05-17 at 21:29 +0200, Damien Sandras wrote: > I have created a new branch named "gnome-2-14" for Ekiga from the > current CVS HEAD. What are your exciting plans for the next Ekiga? --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
Showing multiple groups by default with GOption?
With GOption, is it possible to have it display multiple groups of options by default. eg. that `myapp --help` would display: ./myapp --help Usage: myapp [OPTION...] - Do MyTask GNOME-stylez Help Options: -?, --help Show help options --help-all Show all help options --help-processingShow processing options --help-plotting Show plotting options --help-gtk Show GTK+ Options Processing Options: --cdptol=10 Tolerance (%) --leap=40Leap --fold=200 Nominal Fold --masfile=FILENAME MAS file --smooth=9 Smoothing Plotting Options: --cmppinc=10 CMP Plotting Increment Eventually both of these lists are going to be made somewhat larger, and I would very much like to display both of them (they're both important sets of options and will need to be often referenced by people calling the application from a batch file). --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Power Manager
On Sat, 2006-04-22 at 10:01 -0600, Elijah Newren wrote: > I didn't forget it; I was only responding to the linux-2.4 part of the > thread. I think the alternative OS side of things has already been > addressed sufficiently[1,2,3,4,5], and given that we have other HAL > dependencies in the desktop, I'm honestly quite surprised that anyone > thinks that this should hold back the inclusion of g-p-m. In fact, I > really doubt anyone does -- I personally don't see how the argument > makes any sense and I'm guessing that it's merely being used as an > excuse by those who don't like the notification-area thing. ;-) And > while I can feel some sympathy for the notification-area thing, no one > is trying to provide any solutions to the reasons why it is being used > and I personally don't see why this should hold back g-p-m's > inclusion. But, as always, that's just my $0.02 and wild guesses. :) I am not opposing g-p-m. Most of the problems that it has had have been addressed or are being addressed. I was simply pointing out that we should not break our current level of service for non-HAL-enabled patrons. I have suggested a solution for fixing the notification-area abuse, which will avoid putting a timeline on fixing panel and will still be quite useful when panel is fixed :) --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: GNOME Power Manager
On Sat, 2006-04-22 at 09:22 -0600, Elijah Newren wrote: > On 4/22/06, Mark Rosenstand <[EMAIL PROTECTED]> wrote: > > On Sat, 2006-04-22 at 00:28 +0100, Andrew Sobala wrote: > > > This situation is slightly different in that we're replacing > > > functionality; my reaction would be that the small number of users still > > > using 2.4 kernels can install battstat (hell, they've got it installed > > > already; they just need to remember not to randomly delete it!). > > > > People usually use a package manager and upgrade their packages. A step > > in this process is to remove the old files. > > Are you aware of anyone packaging Gnome for any distro that uses > linux-2.4.x? I'm not, and thus don't see the point in 2.4 kernels > holding back our decision for new features/modules (especially since, > as Andrew points out, the relevant users can use older > deprecated/removed modules). Remember to consider !Linux. Linux is currently the only HAL-supporting platform (yes, others are close, but will they be finished for our release timeframe?). --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: GNOME Power Manager
On Sat, 2006-04-22 at 01:06 -0400, David Zeuthen wrote: > On Sat, 2006-04-22 at 11:57 +0800, Davyd Madeley wrote: > > Why not ditch the hideous abuse of the notification area icon instead, > > and get the applet to communicate with gnome-power-manager over D-BUS. > > I like the fact that g-p-m is themeable (Richard just committed Tango > icons in addition to the existing Bluecurve ones), the applet is not.. > though it's probably fixable, yes? It's become recently fixable using SVG and the ability to fiddle the SVG DOM. We didn't want to do the segmented display for the battery applet, which does make theming that much more challenging. > > Or better still, if g-p-m can't talk to an existing battery monitor of > > some description (maybe a desklet) it will use it's own notification > > area icon as per the configuration. > > > > Not everyone wants to use the notification area. I've also seen people > > who have removed it > > Maybe their operating system vendor should have made measures to ensure > that the user can't remove the notification area (which indeed is > possible). I'm not entirely sure how the vendor is related to this. I would think this fix belongs in GNOME. Perhaps there is something here to be said for "we really, really recommend not removing this applet" when you try to remove it. > > , because they didn't like the notifications in it > > (rather than realising they could disable the problem applications). > > This is why I wanted to see more abstraction of the UI elements from the > > policy elements. > > I fully agree with you but I think Richard's point about the need for a > better programmatic interface to the applet infrastructure is needed. > Today, g-p-m makes it easy for distributors to include, they don't have > to mock around with including the battstat applet in default panel > configurations etc. Things like that. Better programmatic interfaces are certainly required. I spoke about the requirements of these at length during the last GUADEC, but unfortunately no one has really found the time to start implementing these. > Can I suggest to start a new thread here on d-d-l about the applet > infrastructure [1] so we can focus on what's important in this thread: > Namely the inclusion of gnome-power-manager? Personally, I think Richard > done a really really good job (also on the HAL side of things) and I'm > sure that when the desired applet infrastructure is there he will move > to using it. A new applet infrastructure that worked for both the panel applets and gdesklets (as one thing) would certainly be nice. I still think a viable short term solution could be to allow the UI to be proxied over D-BUS. > [1] : it's not only g-p-m, it also applies to the not-so-aptly named > nm-applet from NetworkManager and other things etc. Very true, but the nm-applet D-BUS interface could be integrated into something else... say netstatus-applet. I've been meaning to do this for quite a while now, but I've simply never found the time (it's a common theme). People want to include g-p-m because it solves a specific problem and it does a pretty good job of it (although I do have some bugs to file). The question for me with respect to our modules is not "should we include it because it is good software", but "how can we turn it from good software into great software". --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: Tomboy in 2.16
On Fri, 2006-04-21 at 13:03 -0700, Alex Graveley wrote: > It seems like this issue shouldn't block Tomboy's inclusion though, > given that e.g. stickynotes doesn't store in e-d-s either, and I've not > received any requests for tomboy/e-d-s storage. A future goal to unify > storage sounds good to me, once people start using Tomboy and Evolution > notes both. FWIW: stickynotes/e-d-s is this bug: http://bugzilla.gnome.org/show_bug.cgi?id=116487 This also discusses the possibility of sharing notes data with KDE. -- 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: GNOME Power Manager
On Fri, 2006-04-21 at 16:03 -0400, Bryan Clark wrote: > Richard Hughes wrote: > > >24th April is the end of new modules proposal period. > > > >Are there any unaddressed concerns or questions regarding > >gnome-power-manager that people want to ask? > > > > > FWIW I think this project is awesome and should be 'blessed' into GNOME, > it's made a large improvement to power issues the desktop has had for a > while now. I'd recommend dropping the batstat applet in favor of this, > while batstat is great we really only need one battery 'applet thing' in > GNOME. Why not ditch the hideous abuse of the notification area icon instead, and get the applet to communicate with gnome-power-manager over D-BUS. Or better still, if g-p-m can't talk to an existing battery monitor of some description (maybe a desklet) it will use it's own notification area icon as per the configuration. Not everyone wants to use the notification area. I've also seen people who have removed it, because they didn't like the notifications in it (rather than realising they could disable the problem applications). This is why I wanted to see more abstraction of the UI elements from the policy elements. --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: gnome-applets branched
On Thu, Apr 13, 2006 at 09:52:14AM -0400, Luis Villa wrote: > Plans! Plans! 1) Replace gtik 2) other stuff 3) ... 4) profit! -- 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
gnome-applets branched
gnome-applets has been branched for active development towards GNOME 2.16. --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: Module Proposal: Invest Applet
On Mon, Apr 10, 2006 at 08:23:16PM +0200, Raphael Slinckx wrote: > I'm proposing the Invest Applet (not-yet-)module to be included. Raphael, I was going to contact you about this. I would like to see Invest Applet replace gtik. To prevent module creep (100+ modules is already overkill), I would like to propse that this module be included in gnome-applets 2.16 as a replacement for gtik. This will actually allow you to avoid the module approval process. --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: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
On Mon, 2006-04-10 at 11:50 +0200, Rodrigo Moya wrote: > I don't understand why you don't care. Usually, AFAIK, batteries have a > longer life if you charge them completely and then discharge them > completely, so at least from my experience, you really care when it's > fully charged so that you can unplug it from AC and start discharging. This is true of NiCd and NiMH batteries. It is not true of Li-ION and LiS batteries, which do not develop "memory" in the same way. I've seen it recommended that such batteries instead be used in smaller bursts. Completely discharging and then recharging Li-ION cells repeatedly can actually cause them to flip polarity and "die". --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: Gnome 2.16 Module Proposal: GNOME Power Manager
On Sun, Apr 09, 2006 at 01:47:12PM +0100, Richard Hughes wrote: > Since the original announcement mail about gnome-power-manager, we have > moved the mailing list to gnome.org, are now hosted on gnome.org, and am > starting to integrate with other parts of the GNOME application stack. > Lots of new functionality has been added, and lots of polish has been > applied. See the screenshots area of my website[5] for some cool > screenshots of the latest stuff in the 2-15 branch. I would like to see g-p-m fragmented into three parts. * A daemon with no GTK+ dependance that would be suitable for cross-desktop use * A capplet (this exists today) * A notification area icon (libnotify dependance goes here) This would allow us to more easily address integration issues with GNOME and other desktops and it means that we can aim at avoiding notification area pollution (because session initialised notification icons are a violation of all that is good and right). --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: GTK+ related job opportunity
On Tue, Apr 04, 2006 at 10:21:17AM +0200, Vincent Untz wrote: > I'm glad to see that your company is using GTK+ :-) > > However, from http://mail.gnome.org/: > > "Are job postings OK? > > Job postings are allowed on gtk-list and only on gtk-list. Other rules > about job postings include:..." > > I'm not sure whether we should change the policy to allow some other lists, > but this is clearly off-topic for d-d-l. My apologies. I've never actually read that. Someone actually suggested foundation-list, which seemed grossly unacceptable. I would imagine that gnome-hackers or d-d-l is a more suitable list than gtk-list, simply because I imagine more people read it. It's probably less off-topic than a discussion about whether or not something is off-topic, so shall we continue further discussion off-list? --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
GTK+ related job opportunity
Fugro Seismic Imaging, Pty Ltd. <http://www.fugro-fsi.com> is seeking a graduate or equivalent level programmer to work on maintaining its flagship seismic processing applications. The position is full time and based in Perth, Western Australia. Knowledge of the C programming language is essential. Knowledge of Linux, GTK+ and the GNOME Desktop preferred, but not required. Knowledge of other programming languages (eg. Java, Perl, Python), other UNIX-like operating systems and software engineering will be of benefit. Those interested should contact Franco Broi . -- 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: Looking for a Grid Widget
On Wed, 2006-03-22 at 08:10 +0200, Kalle Vahlman wrote: > On 3/22/06, Davyd Madeley <[EMAIL PROTECTED]> wrote: > > Looking for a GTK+ grid widget. I've found lots of people referring > > writing them, but no source code. > > > > If anyone can help me out here, that would be most appreciated. I > > don't really want to have to write one. For the record, I'm working > > in Python, but I am happy to work out how to write Python bindings > > for a widget, if it exists. > > > > Why don't we have one of these in GTK+? > > "Grid widget" is a bit generic description, it could mean anything > from GtkTable (grid-like layout for widgets) to GtkIconView (grid-like > layout for images/text) and even widgets used by spreadsheet > applications. > > I'm guessing none of those are what you are looking for, so what is it then?-) Oh, right. Something like GtkTreeView, but handles a grid of data instead of a list. Individual cells or groups of cells are selectable and editable as well as being ideally draggable. It would something like a spreadsheet widget. --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
Looking for a Grid Widget
Looking for a GTK+ grid widget. I've found lots of people referring writing them, but no source code. If anyone can help me out here, that would be most appreciated. I don't really want to have to write one. For the record, I'm working in Python, but I am happy to work out how to write Python bindings for a widget, if it exists. Why don't we have one of these in GTK+? --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: release notes: first draft
On Sat, Mar 11, 2006 at 03:03:30PM -0800, Bob Kashani wrote: > > We probably should. I have a screenshot of the sound pref. without the > > default sound card entry. But I'm not all that great with using gimp to > > remove the little black bits from the top corners. I'll upload it and > > hopeful Davyd or someone else can fix it. The other screenshot should > > probably be replaced too. It might seem a bit odd for some users to see > > "System" instead of "Desktop". I'll try replacing that one too and again > > either Davyd or someone else can make adjustments as needed. > > I just noticed that my drop shadow settings aren't the same as Davyd's. > hrmm...Davyd can you fix that? Do you want me to send you a screenshot > without the drop shadow or can you just remove that patch and rebuild? > Also, I took this screenshot from within garnome-cvs which uses the > tango icon theme by default. Is that ok or should I change it? I haven't > messed with the other screenshot that Vincent, mentioned cause I'd like > to get confirmation first before changing more images. I would really > prefer that you do all the image changes just to keep things consistent. Send me what you've got. I'll fix them up. One of them was retouched a bit by Garrett, so I'll have to try and work out what filter he applied (it's the System/Desktop one that I'm least sure of, so maybe if I can't get that fixed, no one will notice). --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: release notes: first draft
On Fri, Mar 10, 2006 at 12:27:32AM +0100, Danilo ??egan wrote: > With Gnome 2.12 we were very successful with translation (24 > languages!), but notes were finished two weeks before the release, > and stabilised at least a week before release. I think it looked > really cool on This is basically my fault for sucking really badly. I should stop offering to do things, because I suck. > and it gave an impression of Gnome truly being the international > desktop it is :) That said, I don't think we had the same amount of focus over the release notes from people with actual English degrees last time. If only we could combine both. I am going to let Bob and Claus finish up with the editing, but I will understand if at GUADEC, any translators want to come up and punch me in the face. --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: PDFs for user-guide, accessibility-guide and system-admin-guide
On Wed, Mar 08, 2006 at 09:39:07PM +, Joachim Noreiko wrote: > What should they be called? > > "Applet" is in the Style Guide: > http://developer.gnome.org/documents/style-guide/gnome-glossary-desktop.html > > If there's a better term, file a bug against it. For quite a while now we've been avoiding applet as the most overused word in the world. It is best to choose a more descriptive word, for example rather than having the battery applet, we call it the Battery Monitor. Other names include Clock, Character Picker, Notification Area, Deskbar, Weather Report, etc. I'm not quite sure how to handle this in terms of the style guide. --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: PDFs for user-guide, accessibility-guide and system-admin-guide
On Wed, Mar 08, 2006 at 04:06:37PM +, Calum Benson wrote: > > On 8 Mar 2006, at 09:32, Emmanuel Pacaud wrote: > > > >I don't think PDF is well suited for on screen reading. Font rendering > >and glyph spacing make document harder to read than when it's in html. > > > >Other points against PDF is that HTML rendering is faster, and page > >layout of PDF files leaves a lot of unused space (page borders, space > >between pages) with no gain regarding readability. > > Also, PDF accessibility is pretty much zero in GNOME, which would be > kind of ironic for the accessibility guide if nothing else... With Evince being able to search text. Is adding accessbility information to poppler possible? It would seem to be that having that information available would be incredibly useful to both GNOME and KDE. --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: PDFs for user-guide, accessibility-guide and system-admin-guide
> > I've been working on generating some new PDFs for the documentation in > > the gnome-user-docs package. > > > http://www.gnome.org/~bmsmith/user-guide.pdf > > http://www.gnome.org/~bmsmith/system-admin-guide.pdf > > http://www.gnome.org/~bmsmith/gnome-access-guide.pdf > > > > At this point, I would just like some feedback on these. I noticed some minor orphanation issues where the end of a page contained a title and two lines, rather than just moving those to the next page. There also appears to be a section on "Applets". The first rule of GNOME Applets is NEVER talk about GNOME Applets. Seriously, we don't ever call them applets in the UI, and everywhere we do call them applets is considered a bug. Pretty rad though. I'm considering getting a set printed and bound. --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: critical warnings; turn them off now?
On Tue, 2006-03-07 at 15:39 +, Bill Haneman wrote: > Since we're now in code freeze for 2.14, shouldn't we turn off the > critical warnings behavior in gnome-session now? I understand that it will automatically turn itself off in stable tarballs. Someone else could confirm this fact for me. --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: release notes: first draft
On Mon, 2006-03-06 at 17:40 +0100, Vincent Noel wrote: > * Regarding the speed improvements of the gnome log viewer, it could > be good to specify that the launch times mentioned in the article are > when loading a 2.9MB log file. Otherwise, it makes the log viewer > looks pretty bad in any situation ;-) Ok. > * On the time scales in the "what's new for developers" page, what are > the colors for ? (ie the yellow, green, blue etc) It seems I did not make this clear enough. Will attempt to correct that. Thanks for your thoughts. --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
release notes: first draft
Ok guys and gals. I am announcing a preliminary draft of the release notes for 2.14. We now require proof readers for spelling, grammar and technical correctness. The latest committed version is online at: http://www.gnome.org/start/2.14/notes/C/index.html You can also check out the release notes from CVS: http://cvs.gnome.org/viewcvs/gnomeweb-wml/www.gnome.org/start/2.14/notes/docbook/C/ We are using gnome-doc-utils for translation. I hope the translators know how to get all of that working, because I have no idea. Warning, I AM AN AUSTRALIAN, SPELLINGS MAY BE CONSIDERED INCORRECT. My grammar is also pretty appalling. Please send through corrections for these. Feel free to correct minor spelling mistakes yourself. Discussion should happen on list as appropriate or on the IRC channel #release-notes on irc.gnome.org. Addendum: - If anyone knows the status of the LiveCD, that section requires updating. - Danilo was meant to be providing the i18n stats page, he said he added it, but I can't see where. - Does anyone want to take charge on writing a press release? I am willing to raise my hand again if so required. -- 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: Kick libxklavier from the release set and make it an invalid dependency?
On Tue, 2006-02-28 at 09:47 +0300, Alexey Rusakov wrote: > > - Get the tarballs uploaded to gnome ftp > > - Remove libxklavier, and make it a blessed external dependency > > - Remove libxklavier from the desktop, and make any functionality > > depending on it only do so optionally and not compiled in by default > > > > Comments? > As far as I know, libxklavier is a freedesktop.org project nowadays, so I > think the second solution is the most reasonable one. This is how I understood it too. libxklavier handles all of our XKB support, it would not do to be without it. I wasn't even aware it was considered part of our release set, I always thought it was part of X. Dependence should not be dropped. Everything else is policy and wording. --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: implementing touchpad gestures under gnome.
Vincent, I have absolutely no idea who you could talk to about implementing something like this. Sounds like it would require support at multiple levels (application level for forward/redo/back/undo), GTK+ level for some things and window manager level. I've CC'ed this email to the desktop-devel-list, hopefully you can share your ideas there and work out who you need to talk to. --d On Tue, 2006-02-21 at 09:59 +0100, Vincent Borrel wrote: > I've been recently considering new touchpad gestures (a la macos-X, > scrolling inside windows using two fingers on the pad), and defined 10 > standard gestures (zoom in, zoom out, rotate left, rotate right, scroll > content, move entire window, forward/redo, back/undo, value up, value > down) using two fingers and the touchpad. Using the hardware input from > touchpads on linux powered notebooks, it could be > implemented/standardized under gnome. This would be the first UI to > feature these intuitive and powerful user interaction methods. I can't > imagine using GIMP with such gestures :). -- 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: new module decisions [was Re: gnome-screensaver]
On Thu, 2006-02-16 at 20:06 -0500, Bryan Clark wrote: > Some proposed action items (from me): > > * HIG has no real notification area guidelines > > To me this doesn't mean g-p-m is doing anything wrong, just that > we design / usability people are behind the game and need to get > our act together. > > Here's the current start: > > http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon Hero! Bryan, I don't know if you read through my use case-y examples with Paul, but if you haven't - perhaps some of that might be useful (or perhaps it's all shit). --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: gnome-screensaver
On Thu, Feb 16, 2006 at 09:21:01AM -0500, David Zeuthen wrote: > In fact I think GNOME and the software we call GNOME is great (otherwise > I wouldn't even bother being on this list), and what's even more > great... is the openness and willingness of the GNOME project, our > community, to help contributors like Richard (g-p-m) integrate with what > we call GNOME and deliver kick-ass software. Ditto for a bunch of other > software like Tomboy, Beagle and so forth. GNOME is doing well. > > Hence, I don't really think there's a huge difference whether you're in > "that exclusive club" called the "desktop set" or not. While it may have > made tons of sense back in the day (GNOME 2.0) to have this exclusive > club... I don't really see the point now... it seems to me that it > mostly only leads to discussions on whether we bless something or not; > it leads to exchanging flames like these; hardly very productive.. > > I'd much rather that we a) cared about putting new useful stuff in the > platform and maintained ABI stability; and b) worked even more with > software authors that for all intents and purposes can be considered > something every GNOME user wants to install. For b) perhaps this > includes asking politely to observe freezes and following our time-based > release approach. We actually agree on quite a lot. I also think that modules should not be aiming to get into "Desktop" as their ultimate goal and that we should be more focused on moving things down into "Platform" and making them ready for third party developers. I do however think that GNOME should stand on it's own as a functional unit and that modules in Desktop should function well together in a supported and sane manner. === I want to take some time to personally apologise to you and everyone else I've yelled at recently. The ups and downs of this release have left me somewhat frayed and frustrated. I have placed a lot of value in this release and I want it to be perfect, a goal we all share. You are quite right in saying that I've been overdramatic and sensationalist, this was somewhat uncalled for. I hope there aren't too many hard feelings over the way I've behaved in the last couple of weeks and I hope we can get our remaining issues resolved in the coming weeks before the release. --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: gnome-screensaver
On Thu, 2006-02-16 at 00:52 -0500, David Zeuthen wrote: > On Wed, 2006-02-15 at 12:54 +0800, Davyd Madeley wrote: > > We are however facing a serious regression now > > Technically xscreensaver was never part of GNOME. All you do is to prove > my point below... Or not, as the case may be. > Well, I'm not sure that many vendors nor users really care that much > about what we include in the desktop set - they usually omit some > software in the desktop and include lots of other useful bits. I think > the picture you're trying to paint of our vendors is sad.. surely they > know what to do, this is hardly rocket science [1]. Who is GNOME working for? Are we working for the vendors? If so, I would really like a large cheque from each of the vendors to turn up in recompense for the time I spend on their software. No, we're not all lucky enough to have jobs with the vendors. Some of us are working for the users and doing it in our own free time. Some of us care that the GNOME we ship and give out tarballs for is sane and cogent and makes sense by itself. Perhaps we should all just give up and go home now. Perhaps the release team should consist of someone from Redhat and someone from Novell and someone from Canonical and someone from Sun and whoever else wants to buy themselves a seat at the table. > So I don't really see your point, sorry, and what seriously worries me > is your rather silly suggestion about adding duplicate UI in > gnome-screensaver. Do you really want to add UI that is most likely to > go away in 2.16 if and when g-p-m should receive the questionable honor > of being included in the desktop set? I actually thought this was quite a serious and sensible suggestion and that it should be a place where this setting is made available even after gnome-power-manager. The setting relates both to power management AND saving my screen from premature death. I find your reference to questionable honour offensive. If this is what Redhat thinks of the work done and the quality of the modules we consider to be part of Desktop then why are they even bothering with such a shit piece of software. Perhaps they should ship CDE, it was popular for Sun and DEC. > Discussing what's in or out of the desktop set isn't really interesting > to me; I think at best it's [2] some blessing, a pat on the back of the > authors and a more rigorous development schedule (observing freezes > etc.). But that is just what I think. And not at all a mark of a level of preparedness, testing, suitability, stability and compliance with the ideals of the desktop. > ship xscreensaver instead. So is this the course of action you're recommending? --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: System Monitor Graph Style Suggestions
On Wed, 2006-02-15 at 10:24 +0100, Paolo Borelli wrote: > Rob Adams wrote: > > On Tue, 2006-02-14 at 20:54 -0400, Steven Garrity wrote: > > Port to cairo! FTW! > 2.13 uses cairo, that screenie comes from an old version. Indeed. The lines are very smooth. This has saved me from having to write a patch, which I was just thinking of doing ;) --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: gnome-screensaver
Quoting David Zeuthen <[EMAIL PROTECTED]>: > This was moved to gnome-power-manager by Jon, as monitor DPMS control > was considered more of a "power" thing than "screensaver" thing. You can > configure monitor power down settings using gnome-power-preferences. I feel it should be available in both dialogs (sending the setting to g-p-m if it is alive on the D-BUS). I think this should be achieved with a button that opens gnome-power-preferences much like the Keyboard capplet got a "-> Accessibility..." button. Perhaps. That is certainly an option. Except that it doesn't deal with the case where we don't ship g-p-m. Think of the case where g-p-m is not available (as will happen in GNOME 2.14 vanilla), how are people going to put their monitors to sleep? Please tell me, how are people going to put their computer to sleep with GNOME 2.14? Also since xscreensaver wasn't really part of GNOME anyway, I hardly feel this is a regression. However, from a realistic point of view all distributions that care about GNOME will most likely ship both g-s and g-p-m anyway. So I don't really see your point. My point is that you're forcing the vendors hand. We are telling vendors to now use our screensaver module, but in order to get the features of the old screensaver module you have to use a component that we actually deceided not to bless, because we weren't sure about it yet... wha? I'm not sure why you're bringing sleep into this. Monitor power down is a feature used on many computers, sleep is not as common (ie. workstations). Another thing is that g-p-m will most likely be part of GNOME 2.16 and then we want to change to the link button (because it makes sense) as that will confuse 2.14 users. Or perhaps we will not. We are however facing a serious regression now in which if a vendor decides to ship THE MODULES WE HAVE SAID "HERE, USE THESE", they are going to be lacking the feature where the user can't specify the monitor off timeout: SOMETHING THAT USED TO WORK PRETTY GOOD BEFORE I UPGRADED. I see two solutions to this: (1) solve the regression; or (2) punt gnome-screensaver until gnome-power-manager can also be included I personally think that (1) is the correct solution here, mostly because I think that monitor sleep time should be in the same dialog as screensaver settings. --d PS. sorry for the capitals, but I am trying to make the case for our vanilla tree not what the major vendors have decided that they're going to do. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
On Mon, 2006-02-13 at 14:56 +, Richard Hughes wrote: > On Mon, 2006-02-13 at 22:03 +0800, Davyd Madeley wrote: > > - power monitors down after ... (we should interact with g-p-m if it is > > available, else handle it directly) > > This was moved to gnome-power-manager by Jon, as monitor DPMS control > was considered more of a "power" thing than "screensaver" thing. You can > configure monitor power down settings using gnome-power-preferences. I feel it should be available in both dialogs (sending the setting to g-p-m if it is alive on the D-BUS). Think of the case where g-p-m is not available (as will happen in GNOME 2.14 vanilla), how are people going to put their monitors to sleep? --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: gnome-screensaver
On Mon, 2006-02-13 at 12:49 +, Rui Miguel Silva Seabra wrote: > I believe it may be trying to fade TOO SMOOTHLY... The fade-out is excessive. I thought something had gone wrong with my monitor. It does however seem to be interruptable during the fadeout (something that xscreensaver was not). I haven't actually tested gnome-screensaver properly in Xinerama environments (xscreensaver will place a different hack on each screen) so I don't know if that is working. I do like the cleanliness of the g-s properties, although I wonder if perhaps we now offer too few options. There were a couple of useful options in xscreensaver: - screensaver timeout - lock dialog after ... minutes (because I want the screensaver to come on soon, but locking it at the same time is damned annoying) - power monitors down after ... (we should interact with g-p-m if it is available, else handle it directly) That doesn't seem overly excessive for options I feel. -- 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: requesting official list of modules and versions for GNOME 2.14
in this case the administrator should be warned that they are possibly making the machine insecure when they choose to disable the firewall. A consistant warning that my firewall is off (particularly if it is undismissable) would drive me insane (it has in Windows). > - a remote user causing trouble (multiple incorrect SSH password > attempts, for example). This is quite an interesting idea. Some sort of GNOME/libnotify based log monitoring daemon would be quite useful for some people I imagine: messages like "Host haxx.haxxors.ru (133.43.12.12) has attempted to log in as the user root 5 times in 30 seconds. Firewall that host?". > - a local user causing trouble. Perhaps this is related to the above. I think what is important in these set of use cases is that we're notified of something specific. > > - "You have new updates"... not sure about this, Ubuntu started > >doing it, it appears at the start of every session, even when I'm > >not on an Internet connection. I have to click on this dialog to > >make it go away (in Breezy at least), this was apparently > >impossible to do without a mouse (because I didn't have one with > >me). As a result, some part of my screen was obscured for the > >whole session. > > Which was, if I hadn't mentioned it, one of the original issues I had, > you have to click on the "warn me later" or "show updates" buttons to > make it go away, the TAB key doesn't know what you're on about, and > there's no Alt-F* binding to access things in the notification tray[1]. People need to consider the a11y and keyboard navigation issues of the bubbles if they haven't already. > > - "Your system needs rebooting"... this seems reasonable, without > >giving me some obnoxious dialog, it is pointing out an icon in > >the panel that will reboot my machine when I'm ready. > > I like the icon in Dapper for this, it just pops up in your notification > tray and lets you know you need to do it at some point. I like it too. It puts an icon in the panel and then tells you what that icon is and then goes away. > Although, without forethought, I can see such a time where GNOME might > adopt a more 'consumer-oriented' 'Your system needs a reboot, so we'll > do it now' strategy, which would irk me to tears :) Yes. > > This email has probably gone on long enough, I have more examples > > written down, these are ones off the top of my head. > > Is there a wiki entry for this? If not, could there be? :) Not yet AFAIK. I've mostly been relaying notes that I've made on my computer and in my head, based off my own reasoning and some email conversations I've had with people both pro and anti bubbles. Perhaps moving to documenting this in the wiki will be a good start for people like Calum to derive a set of style guidelines for the HIG and produce sets of use cases that are good for notification bubbles and bad for notification bubbles. > [1] Actually, that'd be awesome -- just as Alt-F1 does the Applications > menu, if another Alt-combination could access the tray by default, then > TAB moved between the icons there -- it'd solve the "I only have a > keyboard w/ accessibility turned on and I must scream" issues i've had > with popup bubbles since the start. [2] Here are some off-the-cuff ideas w.r.t keynav... - if bubbles are present, the bubbles layer should be selectable with Ctrl-Alt-Tab like panels are, you should then be able to tab through the bubbles - for chronic keynav'vers and people who hate bubbles, notification-daemon should be disabled to be replaced with an applet that listens on the notification BUS and logs all of the messages (I'm actually thinking of writing this). In this applet, the applet would expand to show the message and flash the widget that the message was emmitted from (metacity box style), it would then collapse almost immediately and could be navigated with the mouse or the keyboard to view the message or look at previous messages. --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: requesting official list of modules and versions for GNOME 2.14
ew updates"... not sure about this, Ubuntu started doing it, it appears at the start of every session, even when I'm not on an Internet connection. I have to click on this dialog to make it go away (in Breezy at least), this was apparently impossible to do without a mouse (because I didn't have one with me). As a result, some part of my screen was obscured for the whole session. - "Your system needs rebooting"... this seems reasonable, without giving me some obnoxious dialog, it is pointing out an icon in the panel that will reboot my machine when I'm ready. This email has probably gone on long enough, I have more examples written down, these are ones off the top of my head. --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
GNOME Applets 2.13.4
I always forget to send the email, but this time I remembered :) Enjoy... Changes in GNOME-Applets 2.13.4 "Codename Squarko" This is the second beta release of GNOME Applets for the GNOME 2.13 series. String freeze is now in effect. Changes: - Correctly configure for GStreamer 0.8 --with-gstreamer=0.8 (Davyd Madeley) - Mini-commander will not be compiled and transparently upgrade you to Deskbar-Applet, compile with --enable-mini-commander to be switched back to Mini-commander again (Davyd Madeley) - Catch a possible divide by zero in charpick (Davyd Madeley) - Drivemount fixes for background handling and media ejection (Ryan Lortie) - GWeather fixes (Davyd Madeley, Philip Langdale, Claudio Saavedra) - Replace sscanf with g_strsplit in libgweather to prevent stack smashing (Davyd Madeley, Ryan Lortie) - Fix invalid free in stickynotes (Davyd Madeley) Translations: - et (Ivar Smolin) - ta (Jayaradha) - pt (Duarte Loreto) - th (Theppitak Karoonboonyanan) - zh_TW (Chao-Hsiung Liao) - zh_HK (Chao-Hsiung Liao) - pt_BR (Raphael Higino) - sr, [EMAIL PROTECTED] (Slobodan D. Sredojevic) The GNOME-Applets documentation requires updating for GNOME 2.14, if you feel that you could assist with this, please feel free to contribute documentation improvements. Bugs and bug fixes will of course also be accepted ;) This tarball was produced with Love (tm). -- 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: requesting official list of modules and versions for GNOME 2.14
On Fri, Feb 10, 2006 at 09:19:48AM -0500, William Jon McCann wrote: > In my opinion this is possibly the most clear cut and legitimate case > for using notifications. I think a message that essentially says that > your computer will run out of gas in 2 minutes is hardly "notification > spam". We need to take all of these opinions to form solid style guilelines on this issue. There are lots of strong opinions either way, lest we dig ourselves into a hole from which there is no escape... ... you have unused icons on your desktop --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: requesting official list of modules and versions for GNOME 2.14
On Fri, Feb 10, 2006 at 12:27:34PM +, Richard Hughes wrote: > A comment about the "notification spam": the user only gets 4 > notifications for "low battery", "very low battery" and "critical > battery" and one saying "I'm doing the low-power action in 10 seconds" > -- and then there are a 2 optional notifications (i.e. that you can turn > off in gconf) for things like notification when you remove the > ac_adapter, or when the battery reaches 100%. This is exactly what I mean by notification spam. I hope to get some clarification on what is good notification and bad notification that is suitable for the HIG shortly. I am proposing that gnome-power-manager has no notification UI, and instead consists of the daemon and the capplet. This doesn't quite deal with edge cases like your mouse battery going flat or your UPS going flat: however these are events that do not occur often. It would probably make sense in those events to place a notification icon in the system tray and a single bubble informing the user that their device is about to lose power. If users want to get a dialog of the power status for all of their devices we should offer this functionality somewhere else, perhaps in the power management properties (Mouse Power: Good/UPS Power: Good, 14 minutes). This way we avoid the notification spam and keep most of our notification passive. --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: Talk to the Clearlooks maintainers
On Fri, Feb 10, 2006 at 10:49:57AM +1100, Jeff Waugh wrote: > > > > Well, the new Clearlooks entails both the Cairo-enabled Clearlooks engine > > in gtk-engines and the Clearlooks theme data in gnome-themes. Both the > > engine and the theme data have changed. The theme data is probably > > setting a few things that are new to the engine, but most notably, it's > > using a brigher and more saturated set of colors. > > > > Both the engine and the theme data are responsible for point (b). The > > engine is responsible for point (a). > > Let's take the bike-shedding about Clearlooks elsewhere. If you have a point > of view for the maintainers, please state it to the maintainers so they can > take it into account. A desktop-devel-list discussion without them involved > is not useful to anyone. I've already raised this, and attempted to move it to the gnome-themes-list. This was originally just a mention of the issue for the release team, who may not be following every thread. --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: requesting official list of modules and versions for GNOME 2.14
On Thu, Feb 09, 2006 at 09:10:55AM +0100, Vincent Untz wrote: > + gtk-engines: I quickly looked at the archives and couldn't find a > mail related to it (ie there's no mail with engines in the > subject ;-)). Is the issue a possible slowdown caused by the use of > cairo? We have two issues here: (a) speed issues caused by Cairo; and (b) changes in the default theme (which while may be popular are also unpopular with others) The second can be changed without going back a version, but will require UI-freeze breakage. This is most crucial for doing the screenshots. --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
