Re: Nicer compilation output with shave or automake1.11
Does shave have specific libtool version dependency ? Reason I'm asking is that the default version shipped with OpenSolaris is 1.5.22 (I know quite old), and shave does not work out of the box, and will most likely have to be patched out by default... Matt Javi wrote: Hello all, This is my first post to the list, so hello everyone! There is a GnomeGoal [1] to turn the usual messy output of autotools into a pretty Kbuild-like one using shave [2]. As pointed in bug #580062 [3] , automake1.11 has a feature that do the same as shave do. Is only necessary to add one line in your configure.ac See the GnomeGoal page for more details. So I propose to use automake instead shave for this goal, but it'd be great hear your opinion. Also, if this list is not the correct place to do this, please tell me. Best regards [1] http://live.gnome.org/GnomeGoals/NicerBuilds [2] http://git.lespiau.name/cgit/shave/tree/README [3] http://bugzilla.gnome.org/show_bug.cgi?id=580062 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Ahhh... merci beaucoup :) On 20/03/2009 16:33, Vincent Untz wrote: Le vendredi 20 mars 2009, à 16:15 +, Matt Keenan a écrit : Slight side topic question here... for gnome 2.24, GTK_MODULES was set to include "gnomebreakpad" on session login depending on whether /usr/lib/gtk-2.0/modeules/libgnomebreakpad.so existed or now. Removing gnomebreakpad from GTK_MODULES env variable resulted in bug-buddy not being invoked. I've noticed on 2.26 that gnomebreakpad appears to be getting loaded regardless of what GTK_MODULES contains... is this intentional ? is there any way of stopping this happening other than actually removing the library ? I guess this would help: /apps/gnome_settings_daemon/gtk-modules/gnomebreakpad Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Slight side topic question here... for gnome 2.24, GTK_MODULES was set to include "gnomebreakpad" on session login depending on whether /usr/lib/gtk-2.0/modeules/libgnomebreakpad.so existed or now. Removing gnomebreakpad from GTK_MODULES env variable resulted in bug-buddy not being invoked. I've noticed on 2.26 that gnomebreakpad appears to be getting loaded regardless of what GTK_MODULES contains... is this intentional ? is there any way of stopping this happening other than actually removing the library ? Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On 11/03/2009 13:56, Jonh Wendell wrote: Hi, folks. We from Brazilian team are discussing about the best option to report bugs related with translations. An optimal solution is to have bug-buddy integrated into applications, in the menu "Help->Report a bug or wish". This would call bug-buddy, the user would select the severity of the bug (translation, bug, suggestion), enter the bug itself and then would hit the 'send' button. Simple like that. Ubuntu does something similar, but the negative points are: - Ubuntu packagers have to patch lots of applications; - The bug reports go to launchpad, ubuntu only; - The launchpad interface is English-only, where bug-buddy is translated into the user language; Perhaps bug-buddy could be configurable to send reports to another place instead of only bugzilla.gnome. I know this is something (Sun), are definitely interested in and are looking into. We'd like bug-buddy to send reports to OpenSolars bugzilla (defects.opensolaris.org). Configureable bug database a definite plus. Matt Ideas? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Solaris, apache daemon is disabled by default aswell. Matt Vincent Untz wrote: Le vendredi 24 octobre 2008, à 14:38 +0200, Frederic Peters a écrit : Bastien already wrote about Fedora policy, httpd is disabled by default. I know that Debian policy is to consider that the user installing a server wants it to be started. From what I read of Patryk, PLD Linux also starts Apache on installation. What about others ? I guess Red Hat is like Fedora, and Ubuntu is like Debian, but what about SuSE ? I guess you meant openSUSE ;-) Based on http://en.opensuse.org/Apache_Quickstart_HOWTO, my guess would be that apache is not running by default when it's installed. Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Showstopper Review
Vincent Untz wrote: Le mardi 17 juin 2008, à 00:36 +0200, Andre Klapper a écrit : GNOME-PANEL http://bugzilla.gnome.org/show_bug.cgi?id=504600 Crash in handle_cached_dir_changed There has not been a single report coming from GNOME 2.22 so far, so this may not be a blocker anymore. The bug is still there, but the patch is unfortunately wrong. The crash seems to only be triggered on OpenSolaris so far and they added the patch to their package, which is good for OpenSolaris users, though :-) I'll work on a good fix in 2.23 (can't be done in 2.22 since the change is too intrusive) Thanks vincent :) Matt http://bugzilla.gnome.org/show_bug.cgi?id=515948 clock window not shown if e-d-s has not authenticated to google calendar If a google calendar exists in Evolution and one clicks on the time in the clock applet, it hangs because google calendar is not available unless evo authenticates it. Very annoying, no patch available yet. In general, Google calendar support in Evolution is quite buggy and there are several bug reports dealing with issues. There are two things here: + the clock applet opens the calendar in a synchronous way. I'm afraid the change is quite intrusive, which makes me think it won't go in 2.22. + authentication: I thought the clock applet handled calendar authentication, but maybe I'm misremembering. Or maybe the google backend needs something different? Does anybody know? Thanks, Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding more schema entries to libgnome ok?
Bastien Nocera wrote: > On Tue, 2008-01-08 at 09:54 +0000, Matt Keenan wrote: > > >> There are patches in bugzilla for gnome-panel, nautilus and pessulus for >> these keys : >> gnome-panel : http://bugzilla.gnome.org/show_bug.cgi?id=394252 >> nautilus : http://bugzilla.gnome.org/show_bug.cgi?id=397715 >> pessulus : http://bugzilla.gnome.org/show_bug.cgi?id=394249 >> >> So not that remote i think >> > > There was no mention of it in the bug, and not any depends on the bug. > > Apologies there, that was my bad thanks for updating the bugs... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding more schema entries to libgnome ok?
Bastien Nocera wrote: > On Mon, 2008-01-07 at 20:07 +0100, Kjartan Maraas wrote: > >> Hi. >> >> I've got a few reports in bugzilla with patches to add more schema >> entries in libgnome. Is it ok to keep adding API/ABI to these deprecated >> libs or should we seek to put them elsewhere? >> >> I guess we'll have to migrate the whole lot to some other place at some >> point anyway if we are to get rid of libgnome so adding a few more won't >> add much to the burden. >> >> - lockdown: Restrict Application Launching, default schema ... >> http://bugzilla.gnome.org/show_bug.cgi?id=395887 >> > > This one seems pretty remote from what would actually be needed, and > there's no patches for gnome-panel/nautilus to look at the > implementation. > > There are patches in bugzilla for gnome-panel, nautilus and pessulus for these keys : gnome-panel : http://bugzilla.gnome.org/show_bug.cgi?id=394252 nautilus : http://bugzilla.gnome.org/show_bug.cgi?id=397715 pessulus : http://bugzilla.gnome.org/show_bug.cgi?id=394249 So not that remote i think Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel menu lockdown proposal
guenther wrote: > The above covers Nautilus ways and manually creating .desktop files? > > Forgot to state we also have a patch for nautilus, e.g. when user double clicks on an item to launch it, if not in the allowed list it won't launchetc.. > What about non-obvious ways to launch an app? Although often not > intended to run full featured UI apps, it can be abused to do so. > > * gnome-terminal (if in the allowed list) > Attempting to launch an application from the terminal... well to be honest if a user has terminal access, it's fairly likely they won't have a locked down desktop in operation, interesting idea though none the less. > * deskbar-applet > Just disallow use of the deskbar-applet completely, via disabled_applets. > * Mail Notification (see Commands section in the Properties) > * Evolution (a) custom command to connect to IMAP server > (b) mail Filters "Run Programm" and "Pipe to Program" condition > and action > This is not meant to be a complete lockdown solution, just a starting point for locking down menu items, however various other applications could use these keys to implement some lockdown specifics. > Just a few ideas that popped right into my head. I am sure there are > lots of others... > > I bet there are too :) Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel menu lockdown proposal
Diego Escalante wrote: > Second, I only have a question: what happens if I add application X to > my panel and next day the admins add that application to the denied > apps list?, will it disappear?. Besides that I'm totally positive > about this. > It's not a denied list, it's an allowed list. if your application X is not in the allowed list and restricted applicaiton launching is switched on, the you won't be able to add it to your panel. > Third, couldn't the allowing applications part be added to Alacarte? > (just an idea) > This was something that was discussed before, in that we should really be doing this within a menu editor, however a menu editor did not exist back then. Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-panel menu lockdown proposal
At Guadec last year in Villanova, one of the topics that came up from Luis's talk on what our customers want from Gnome was the ability to restrict the gnome menus. Here's the solution we've implemented for this exact purpose, simply involves two new global desktop lockdown keys : - desktop/gnome/lockdown/restrict_application_launching Boolean value, that simply states whether restricted application launching is switched on or not. - desktop/gnome/lockdown/allowed_applications A list of string's containing full path's to applications that are allowed. e.g. /usr/local/bin/evince etc... Three patches are required for this : - gnome-panel (DONE)- Check of restricted application launching is set to true then : - hide items on menus whose application is not in the allowed list - hide launcher icons on panels whose application is not in the allowed list - Restrict creating of launchers by D'n'D whose application are not in the allowed list. - libgnome (DONE but needs updating) - provide default schema for two new gconf keys - Pessulus (TODO) - Update to allow editing of new gconf keys. Posting here to get some feedback from people. Patches are available on request. cheers Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Man Page Preferred Format ?
Hi, What is the preferred man page format perceived within the GNOME community ? Currently nroff is what is used for the few that are in existence, is this something that people see as sufficient ?, would DocBook / SGML or something else be a better solution ? As we are in the process of updating/writing some man pages at the moment we really would like to contribute what is done back to the community, so knowing what the preferred format is a necessity. Cheers Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Invest Applet
I agree this should replace gtik directly, a few quick hacks on solaris and it was up and running, much better than gtik in my opinion Raphael Slinckx wrote: Hi ! Since we must propose modules for gnome 2.16 here it is: I'm proposing the Invest Applet (not-yet-)module to be included. I've talked about the applet a couple of months ago on my blog, here are the two relevant posts: http://raphael.slinckx.net/blog/2006-02-04/deskbar-2139x-series-and-invest-applet http://raphael.slinckx.net/blog/2006-01-18/stock-trading-yay The code isn't released anywhere else than the link provided on the blog and the bzr archive, but i can make it a gnome cvs module of course with little pain. The announcement received a warm welcome by most gnome developpers and users that want to see the old invest applet die. The code hasn't evolved much since then, but it's relatively simple, sloccount reports ~1000 lines (in python). Outstanding improvements that are to be made for it to become usable, are better gconf integration (things are saved to a file right now), update the popup window positionning code from deskbar code, and check the computations are correct. Nice to have improvements are removal of the figures in the panel but use a color coded indicator for the day variation of gains/losses to protect privacy. While the applet may not be *really* useful (few applet are :)) it has a great wow factor, and is really funny to use. As i won't have full-time to work on maintaining and improving it, i asked Lionel 'Ploum" Dricot (a long time gnome/ubuntu/linux advocate http://ploum.frimouvy.org/ ) to assist me in this task, so it will have also the benefit of bringing a new (code-)contributor in Gnome. Maybe someone else can start contributing (preferably a new contributor) too ? Maybe the code could be ported to C for less memory usage ? If the module is accepted but seems to not be able to reach a usable goal as we get closer to 2.16 we can always retract it.. Thanks ! Raf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for inclusion in Desktop: pessulus
Definitely gets my vote Fernando San Martín Woerner wrote: I am all for it too, we need this kind of tools in the desktop! El vie, 28-10-2005 a las 16:19 +0200, Toady escribió: Hi Vincent, I am all for it! good work! this is the kind of stuff users always ask and can't be resolved without diging into command line / gconf. Thanks. Vincent Untz wrote: Hi, I'd like to see pessulus included in GNOME Desktop 2.14, and therefore, surprise surprise, I'm proposing it for inclusion. Pessulus is a lockdown editor for GNOME, written in python. Code is available in GNOME CVS, and there are already some translations (many thanks to the translators). There's no documentation yet, though. This tool enables administrators to easily lock down the desktop of the users. There are also some plans for sabayon to integrate the fantastic pessulus technology (I can already imagine the "pessulus inside" sticker). It does not make coffee (and to be honest, I don't like coffee), but it should do its job well. There are some plans to rework a bit the UI in the next few days, and the strings should probably be updated to be more consistent. But the main work is to add more lockdown settings. So I invite everyone to try pessulus and file a bug for each missing setting. So, there's still a bit of work to do, but it'll be ready for GNOME 2.14. Hrm, I think this mail was not enthusiast enough. WOOOHOOO Should be better now ;-) Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3
Well it's not completely unmaintained :(... I've appied the patch to CVS. Matt Calum Benson wrote: On 15 Jun 2005, at 15:13, Nigel Tao wrote: Indeed, it is. Unfortunately, I was not aware of webeyes when I started coding my own applet. Perhaps it should be advertised on gnomefiles.org? Well, to be fair I think webeyes is pretty much unmaintained these days anyway. I've filed your patch in bugzilla though, perhaps Matt can apply it when he has a minute. http://bugzilla.gnome.org/show_bug.cgi?id=307916 Cheeri, Calum. -- __.--'\ \.__./ /'--.__ _.-' '.__.''.__.' '-._ .' Matt Keenan (mattman) '. / Sun Microsystems Ireland \ || | E-Mail : [EMAIL PROTECTED] | |[EMAIL PROTECTED] | || | Irish Fantasy League Of American Football | | http://www.iflaf.com | || |Happy Hookers Golf Society | | http://www.iol.ie/~mattman/golf/hhgs.htm | || | Phone : +353 1 8199251, Sun Ext : 19251 | \ .---. .---. / '._.' '.''..''.' '._.' '-./\ /\.-' '' ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
