Using jhbuild
So today I thought I would give jhbuild another try, so I can build gtk+ 3.5. My question is, after I cloned jhbuild, should I run autogen.sh with the --prefix=/usr option or is that not neccessary? Is there a rule of thumb when this option is necessary? Regards Lanoxx ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using jhbuild
On Fri, Aug 17, 2012 at 4:24 AM, Lanoxx lan...@gmx.net wrote: So today I thought I would give jhbuild another try, so I can build gtk+ 3.5. My question is, after I cloned jhbuild, should I run autogen.sh with the --prefix=/usr option or is that not neccessary? You want to build jhbuild into your local user, not system-wide. Just running ./autogen.sh should make it work. Is there a rule of thumb when this option is necessary? For jhbuild? Never. Regards Lanoxx ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility team to automatically receive bugmail on a11y bug reports
On 08/17/2012 01:12 AM, Bastien Nocera wrote: How about having a script that would query bugs: - with the a11y keyword - that don't have the magic a11y maint alias on CC: and adds the maintainer alias for all those The rationale of this thread was about being notified of new bugs. Do you suggest to run that script every X days? In general, as Cosimo suggested, the optimal solution would be being able to subscribe to key words (but this is not an option right now). Adding an accessibility component to gnome-control-center would just create more confusion (we already have universal access), and wouldn't allow us to carry on categorising bugs per panel. It's a no-no from me. That accessibility component was intended for accessibility bugs (ie: no keyboard navigation on X). But it is true that can be confusing (if keyboard navigation doesn't work on the universal access panel, how I classify it). Probably gnome-control-center is a bad example of a product requiring that component. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using jhbuild
On 17 August 2012 17:24, Lanoxx lan...@gmx.net wrote: So today I thought I would give jhbuild another try, so I can build gtk+ 3.5. My question is, after I cloned jhbuild, should I run autogen.sh with the --prefix=/usr option or is that not neccessary? No, install as a normal user. Do not use jhbuild as root Also, take a look to the Getting Started section of the manual [1] Regards [1] http://developer.gnome.org/jhbuild/unstable/getting-started.html.en -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility team to automatically receive bugmail on a11y bug reports
On Fri, 2012-08-17 at 11:20 +0200, Piñeiro wrote: On 08/17/2012 01:12 AM, Bastien Nocera wrote: How about having a script that would query bugs: - with the a11y keyword - that don't have the magic a11y maint alias on CC: and adds the maintainer alias for all those The rationale of this thread was about being notified of new bugs. Do you suggest to run that script every X days? Every night. I don't expect it to be any heavier than a user-triggered search. In general, as Cosimo suggested, the optimal solution would be being able to subscribe to key words (but this is not an option right now). And this is a work-around. Adding an accessibility component to gnome-control-center would just create more confusion (we already have universal access), and wouldn't allow us to carry on categorising bugs per panel. It's a no-no from me. That accessibility component was intended for accessibility bugs (ie: no keyboard navigation on X). But it is true that can be confusing (if keyboard navigation doesn't work on the universal access panel, how I classify it). Probably gnome-control-center is a bad example of a product requiring that component. Yep, but it's the one I maintain, so... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Don't store passwords in keyring item attributes
Item attributes in gnome-keyring are used to lookup password items. Think of them as the primary key for the item. They are not stored in a secure manner on disk. Do not store anything secret or sensitive in item attributes. I found an instance of this being done today. The above also applies to libsecret, the Secret Service DBus API, and ksecretservice. In addition, this has always been the case with gnome-keyring, and is not something new. The libsecret documentation and Secret Service API documentation are explicit about this. I've added warnings to the libgnome-keyring documentation as well. These warnings probably should have been there from the beginning :S Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using jhbuild
So if I just wand to build gtk+ 3.5.x with its dependencies. What moduleset name would I use in my config file? On 17/08/12 11:26, Javier Jardón wrote: On 17 August 2012 17:24, Lanoxx lan...@gmx.net wrote: So today I thought I would give jhbuild another try, so I can build gtk+ 3.5. My question is, after I cloned jhbuild, should I run autogen.sh with the --prefix=/usr option or is that not neccessary? No, install as a normal user. Do not use jhbuild as root Also, take a look to the Getting Started section of the manual [1] Regards [1] http://developer.gnome.org/jhbuild/unstable/getting-started.html.en ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using jhbuild
On Fri, 2012-08-17 at 14:40 +0200, Lanoxx wrote: So if I just wand to build gtk+ 3.5.x with its dependencies. What moduleset name would I use in my config file? https://live.gnome.org/ThreePointFive states that the current unstable series is 3.5.x which will become the 3.6.x stable series. If you only want gtk+ 3.5 then it is enough to set moduleset = 'gnome-suites-core-3.6' Other available options are e.g. 'gnome-apps-3.6' or 'gnome-world-3.6' which include more stuff than just the core of GNOME. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using jhbuild
On 17/08/12 15:28, Andre Klapper wrote: On Fri, 2012-08-17 at 14:40 +0200, Lanoxx wrote: So if I just wand to build gtk+ 3.5.x with its dependencies. What moduleset name would I use in my config file? https://live.gnome.org/ThreePointFive states that the current unstable series is 3.5.x which will become the 3.6.x stable series. If you only want gtk+ 3.5 then it is enough to set moduleset = 'gnome-suites-core-3.6' Other available options are e.g. 'gnome-apps-3.6' or 'gnome-world-3.6' which include more stuff than just the core of GNOME. Thanks for the answer. I was just told in IRC that I can also run 'jhbuild build gtk+' which seems to be a better alternative than to build the whole core module set. andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Print Dialog / Improving Print to file option [DONE]
Just for the record, i was looking for: GTK_WINDOW(gtk_widget_get_toplevel(GTK_WIDGET(widget))) Anyway, I managed to build a patch. I have created a bug report for it, see here: https://bugzilla.gnome.org/show_bug.cgi?id=682129 The patch could still be improved by placing the options box below the radio buttons for the file type. Regards Lanoxx P.S: If this could land in 3.6 that would be absolutely awesome On 17/08/12 22:59, Lanoxx wrote: In file gtkprinteroptionwidget.c:710 static void construct_widgets (GtkPrinterOptionWidget *widget) is there some way to get a pointer to the parent widget, that is to the whole print dialog? As I understand it, GtkPrinterOptionWidget is only the pointer to the option section, right? On 16/08/12 00:11, Andreas Nilsson wrote: On 08/15/2012 04:08 PM, Lanoxx wrote: Then the filename says output.pdf which any sane person will probably want to change. So I have to type the file name and then also add .pdf again and finally I can click "Print". So my question is, if this comes from Gnome or from Ubuntu so I can create a bug in the right bug tracker for this, and maybe someone could also point me to the code for the "Print to File" Options. Maybe I could even fix this myself. It's in GTK+ and should be filed in the printing component. https://bugzilla.gnome.org/browse.cgi?product=gtk%2B Just file a bug about the issue, attach a screenshot and provide a patch. There is already a bug open about the default name and location here: https://bugzilla.gnome.org/show_bug.cgi?id=668529 - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
