Re: Icons for IM programs
Jaap Haitsma wrote: ] Ok so how can we add them in the icon naming spec ? Who should I contact ? I think you should contact Rodney Dawes dobey at novell dot com [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
Martin Soto wrote: An additional point that nobody has mentioned so far is security. Most (if not all) plugin implementations already available for Gnome programs seem to allow for installing plugins in some user-owned directory. This means that by gaining access to the user's home directory, an attacker will be able to install code that gets run every time the user logs in: Yes, you can do that already. It's what the session's for. I'm not saying there aren't security implications of plugins, but being able to run code on login is much easier to do without bothering with them! -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
Rui Miguel Silva Seabra wrote: Sex, 2007-05-18 às 12:54 +0200, Martin Soto escreveu: Hi Andrew, On Fri, 2007-05-18 at 11:28 +0100, Andrew Sobala wrote: Martin Soto wrote: An additional point that nobody has mentioned so far is security. Most (if not all) plugin implementations already available for Gnome programs seem to allow for installing plugins in some user-owned directory. This means that by gaining access to the user's home directory, an attacker will be able to install code that gets run every time the user logs in: Yes, you can do that already. It's what the session's for. However, while /home/ can be mounted without any execution permissions, /usr not, and thus applications started by the session manager are supposedly blessed by the admins (distro maintainers, and what not) while those installed in ~/ *aren't*. It's a good point. So we can solve this by requiring plugins to have +x in order to be loaded? Seems quite elegant to me. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
Shaun McCance wrote: It's not uncommon for software producers to have terminology guidelines that don't quite follow dictionary definitions. In the software world, we often use metaphors and re-use words with a sufficiently similar real-world meaning. For plug-in, the OED says: *3.* /Computing/. An easily installed item of software or hardware that can enhance or add a specific feature to a system or application. Proper dictionaries rule ;-) -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Generating excitement in GNOME
My personal reaction is that it would be more useful to have a GNOME distribution (such as something jhbuild or garnome derived) which can act as a testbed of next-generation technologies - and where people can happily make different modules work together, or swap out the panel for something else, for example - than to take a selection of modules and put them in another formal release set. Another release set opens a real can of worms - what's the criteria for inclusion? Are we creating an artificial barrier that a cool project has to get over before it is taken seriously? Would any degree of conformity to a 6-month cycle would be expected - this could just be a pain for modules that want to focus on breaking everything together while they still can. My 2p. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Being able to replace Mugshot-as-desktop-server is neither here nor there. Sure, from the Freedom perspective we don't want to rely on a particular server [1], but that's not what's going to really affect the desktop experience. What's important from the user experience is not having to rely on Mugshot-as-social-network. Virtually none of my friends use mugshot - they all use facebook. So what would actually make this work is server-to-server features - the desktop may only need to talk to mugshot, but mugshot needs to tie [EMAIL PROTECTED]@mugshot.org to my facebook, msn, and jabber accounts. These social networks *also* have a variety of presence information, friends, social networks, photos, RSS feeds, statuses, and so on depending on the service. I know that mugshot does more than, say, myspace. But if a user has to get all of his friends using mugshot instead of (eg) myspace, then the end result is that the user can't use mugshot. Or the online desktop. Hope I managed to get a point across in that ramble :) -- Andrew Havoc Pennington wrote: Though we want to keep things cleanly engineered so someone could replace Mugshot, at the same time using Mugshot is the only practical way to get things going IMO, for a variety of reasons. Some of the major ones: - we need an open source server under the control of the development community, because web services provided by existing sites and companies aren't sufficient. We want to use what exists - say Flickr for photos - but then be able to fill in gaps. So for example, we had to write our own browser for open source apps at http://mugshot.org/applications - it's an admin'd, hosted, clustered application server instance that has both jsp and xmpp channels, and any server-side function can be rapidly added to it; doing a new server-side function from scratch has *a lot* of overhead vs. adding to Mugshot (and also has end user overhead, e.g. signing up for the new server) - because it has web-only and Windows versions, social features need not assume that all my friends use Linux - the data model of the Mugshot meta social network or whatever you want to call it is what we think we want user experience wise, vs. say a my contact database data model. For example, people choose their own photo and nick, and maintain their own addresses, you don't have to import or edit these things. - we already have major functionality slices such as tracking your friends' photos and feeds, tracking who's listening to what, partially-complete file sharing, and social application browsing/installing/launching [1] especially since mugshot is under teh c0ntr0l of redhat, and redhat are evil and going to take over the world with killer rabbits, remember? ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
Richard Hughes wrote: On Sat, 2007-04-07 at 17:13 +0200, Paolo Borelli wrote: Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. Tell me about it. gnome-power-manager 2.18.0 had a bug where it would segfault when you locked the screen if HAL was not running. 2.18.1 fixed the bug, but that still means I get about 5-10 duplicate bugzillas a day. The guys triaging this stuff have been great, but it's still more and more emails for me. We can auto reject specific stack traces [1] for this very reason. Get in touch with your local bugsquadder/bugmaster for more information. I'm really thinking the auto-submit thing to bugzilla should have more text like: 1. You do not have debuginfo packages installed, the trace may not be useful to the developer. This happens [2] if we manage to detect it.. Thanks, Andrew [1] http://blogs.gnome.org/view/ovitters/2006/11/12/0 [2] http://blogs.gnome.org/view/ovitters/2007/01/06/0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: how to get a gnome library version with code?
Carlos Eduardo Rodrigues Diógenes wrote: On Sat, 2007-03-03 at 16:57 +0100, Josselin Mouette wrote: Le vendredi 02 mars 2007 à 14:24 +0800, Neo Liu a écrit : gurus, how can I get a library version in code? is there a general way? and if not, is there a way to get atk/at-spi library version? I think that you can look at the pkg-config code, since if you type in your terminal: pkg-config --modversion gtk+-2.0 you will get the gtk+ version. No, that's different. That's What version of GTK+ would I get CFLAGS for and link to if I ran pkg-config --cflags and pkg-config --libs at this moment in time (from the .pc metafiles), not What version of GTK+ am I currently linked to. It fails most obviously in a parallel install or statically linked app. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
Yair Hershkovitz wrote: 2) I think we should add an rtl keyword to bugzilla, for tracking RTL issues. This is exactly the sort of meta- thing that keywords were designed for. In principal, I'm in favour. Do you want to open a bug against bugzilla.gnome.org asking for the keyword to be added? -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: tracker
Joe Shaw wrote: Hi, On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote: Joe Shaw wrote: [snipped my concerns about Tracker] all these also apply to EDS too yet no one complains? Some of them apply. EDS isn't a general data store; it has APIs and backends that are very specific to the types of data it stores. Also, very few applications (none other than Evolution, I believe) actually store info in EDS. They're all read only, consuming EDS's data. The opensync guys valiantly attempt to be an EDS producer. (The tone is due to opensync never having succeeded in syncing any of my portable devices!) -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Subversion migration finished
Diego Escalante wrote: And in case you have errors about locales, try: alias svn=LANG=C svn in your .bashrc, but I have heard that the problems with locales are gone now. As of svn 1.3.2, there are locale errors. I was ignoring them, I've just aliased ;-) -- Andrewq ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME git repositories?
Danilo Šegan wrote: You guys seem to be engaging in the SVN vs. GIT (or any other RCS) again. I thought that this discussion was over, and I am not getting into it now ;) Just as a point of information - the last time this discussion was had, there was a *lot* of support for a *lot* of different VCSs. I think Mr Hallendal summarised the consensus quite well: But having Subversion instead of CVS is a lowrisk/high-gain transition that we can do today and it makes a lot of sense doing so. [1] So while anyone arguing Stop the SVN transition now, go to GIT instead is clearly on crack, my impression is that the community is in favour of at least investigating VCS alternatives. Cheers, Andrew [1] http://mail.gnome.org/archives/gnome-hackers/2005-June/msg00044.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is right the time shown on the panel
These are standard conventions for digital clocks. This is a development list that you've posted to. Please address any other questions about the GNOME desktop to the user list, gnome-list@gnome.org, or the web forums at http://gnomesupport.org/forums/. Thanks! heromyth wrote: Now it was midnight. I run 'date' in terminal, and got this: 0h02m57s CST However, the time shown on the right of the panel is : am 12:02 Ok, at noon, the time on panel is: pm 12:xx Are there some mistakes? Thanks for any helps! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
Marco Barisione wrote: Il giorno lun, 18/12/2006 alle 13.02 +0100, Danilo Šegan ha scritto: Isn't this provided by LANGUAGE environment variable on GNU systems? Do you have some specs on how LANGUAGE is supposed to work? http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
Jonathan Blandford wrote: On Tue, 2006-12-12 at 15:26 +0100, Étienne Bersac wrote: A menu longer that 10 entry is very painful. Often, Gnome properties menu is about 20 entry when you install some additionnal softwares. Gnome is the only desktop which keep using this outdated control-center. A control center is far more usable and accessible (especially if it provide search). This also could mean that we have too many capplets. Every single time we have this discussion, someone points out that we have too many capplets. Despite some good efforts at annihilating and assimilating various silly ones, there are still too many for a usable menu. In the real world, outside of Pure GNOME, distributor and 3rd-party (Java springs to mind) added capplets make the menu more unusable. Given that a) GNOME still has too many capplets, and b) there are additional ones that will always be added to the menu, I think making access to them as usable as possible is a laudable goal. Reducing the number of capplets is still a laudable goal, but hasn't solved this problem in the past. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
Claudio Saavedra wrote: Hi all, On Tue, 2006-12-05 at 14:25 -0500, Dominic Lachowicz wrote: - Develop a simple tool for control-center to adjust above settings. Is this strictly necessary? Or would it be better to have it default to g_getlocale()? I think it would be necessary. Many users see themselves in the need of spell checking when writing in a language other than the current locale they are using. Specially when it's about foreign languages. The ability to set more than one default language would be really cool, as evolution does with gnome-spell. Hang on, let's rewind here. Isn't what we want an application-specific way of deciding what language you want to spellcheck in, that defaults to the current locale, not a global desktop setting? Then when you're writing a document in French, you can change your wordprocessor to French. The next time you open a document, or the next time you do anything else on the desktop that uses spellchecking, you default back to Your Native Language. -- Andrew ___ 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
Brian Cameron wrote: Let's say some program generates a log file, and because this log file is useful for debugging the maintainer specifies that the logfile should be added to the bug report when it is created. This sounds good, but what if there is some way that sensitive or private data can get into the log. Then when the program crashes, this sensitive data gets put in a public forum for all to see (if they know where to look). #3 signal handler called #4 0x0005 in ?? () #5 0xb487cc71 in show_password_dialog (site=0x83ff2c0 www.hotsexychicks.com, user=0x3777fef bcameron) #6 . Now, if it's not immediately obvious to anyone, *I just made that trace up*. It is not real. But the nature of a stack trace is that absolutely anything could be leaked to bugzilla. This is why bug buddy makes it clear that you should review the data sent for personal or private information. Adding data from scripts to bug buddy has two ways it could go wrong - it can leak data by accident, or it can be malicious. In the former case, I'd argue for adding no more options because it's no more likely than leaking data in the stack trace, and that's the reason that we ask the user to review all data sent anyway. In the latter case, you've just installed malicious code on your machine and all bets are off (there are much easier ways to send data out of a system than via bug-buddy, anyway.). PS. Just for reference, people *do* leak private data onto bugzilla regardless. -- Andrew ___ 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
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. PS. Just for reference, people *do* leak private data onto bugzilla regardless. 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. I sort-of agree with all of that [1]. However, my argument is that the situation is no different for stacktraces and for custom scripts. -- Andrew [1] I don't think we have the manpower to screen every trace that comes in, although automatic dup finding does mean it's now more plausible than it used to be. However, I agree with the sentiment :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing NewStuffManager
Sebastian Pölsterl wrote: I'm posting this here to encourage you to read my presentation at http://www.k-d-w.org/clipboard/NewStuffManager/ and to find out what you are expecting from such an application. Hi Sebastian, I missed Nigel's original e-mail, and on reading it now, I think an extension downloading and applying mechanism is needed in GNOME. Thanks loads for working on this, you rock :-) I haven't looked at the presentation in too much depth, but in Nigel's original e-mail, he mentions there's no security. What's the status on this - have you implemented GPG signing now, or are you still planning on doing so in the future? I do think any extension mechanism nowadays is absolutely worthless until we can verify that the code came from a trusted source. Thanks, Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome desktop integration library
Chipzz wrote: On Tue, 5 Sep 2006, Havoc Pennington wrote: Why can't gtk depend on dbus? How do those reasons not apply to libgnome? I don't know, I'm asking. But there's no reason to just make an assumption up front that gtk can't depend on dbus, or that gnome should. Because gtk+ is not just gnome. Gtk+ is also maemo. Gtk+ is also xfce. Gtk+ is also a possible choice for embedded apps on phones, pdas, and stuff like that. Gtk+ is also a library for very simple apps, where very tight desktop integration does not make sense. As much as I think a gconf dependency would be a good thing for gtk+, gtk+ is a widget library, not a library for tight integration. But that's not a reason why _Gtk+ on Linux_ cannot have a DBus dependency, appropriately abstracted behind a platform settings storage API. Gtk+ on Windows can have a dependency on RegEdit, and Gtk+ on embedded systems can interact with whatever platform-native mechanism exists there. [ We're probably talking about Glib, really, here, aren't we? ] -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome desktop integration library
Andrew Sobala wrote: Chipzz wrote: On Tue, 5 Sep 2006, Havoc Pennington wrote: Why can't gtk depend on dbus? How do those reasons not apply to libgnome? I don't know, I'm asking. But there's no reason to just make an assumption up front that gtk can't depend on dbus, or that gnome should. Because gtk+ is not just gnome. Gtk+ is also maemo. Gtk+ is also xfce. Gtk+ is also a possible choice for embedded apps on phones, pdas, and stuff like that. Gtk+ is also a library for very simple apps, where very tight desktop integration does not make sense. As much as I think a gconf dependency would be a good thing for gtk+, gtk+ is a widget library, not a library for tight integration. But that's not a reason why _Gtk+ on Linux_ cannot have a DBus dependency, appropriately abstracted behind a platform settings storage API. Gtk+ on Windows can have a dependency on RegEdit, and Gtk+ on embedded systems can interact with whatever platform-native mechanism exists there. [ We're probably talking about Glib, really, here, aren't we? ] So I should read the parent before replying. Sorry, I'm a dork. But scrap the references to settings and replace with message-passing RPC, and the gist of my post still holds. Thanks, Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Power Manager
Rodney Dawes wrote: On Fri, 2006-04-21 at 16:03 -0400, Bryan Clark wrote: 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. What do I use for my machines where I must run a Linux 2.4 kernel then? :) We Have Had This Discussion Before [1]. The consensus then [2] was that (new) functionality just depending on HAL is fine, because HAL is our approved method of getting hardware events from different operating systems. Linux 2.4 doesn't support it, but everyone's migrating away from that anyway. 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!). However, our GNOME Desktop (which is basically a recommendation to distros, and all the distros are on 2.6) only needs to work on 2.6. [1] http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00243.html [2] http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00167.html -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2 infinity and beyond [was Re: Tango and 2.16]
Alan Horkan wrote: I put serious thought into the fact that Gnome 3.0 would be useful way to highlight all the progress that has been made. A major version number change is also of some marketing value. Look at the desktop. It's got incredibly amazing since the times of GNOME 2.2, but it's still very much a GNOME two series desktop. There are ideas for what people want from a GNOME 3.0 desktop, and these Topaz-related include: * Indexing support across the whole desktop. Probably provided by beagle. Beagle can query document metadata too. [ some of this is starting to appear: deskbar, nautilus ] * Documents and people as first class objects, rather than applications, files and windows. [see also: beagle, galago. ] [this idea seems to be one with the most buy in ] * New panel applets that can be written as easily as notification area doodads. ie. without bonobo. * Networking. Really easy peer to peer? Share files with anyone nearby? Or even collaborative document creation? (is iFolder relevant for some of these?) * Multimedia. (personal note: kick whatever it is that's still making my desktop sounds laggy. I'm going to completely arbitrarily blame esd on no evidence whatsoever.) * Cairo/Xgl/compiz goodness wherever appropriate I've picked out the biggest ideas; there's much more than this on the Wiki. And it can *all* be done *now.* That's the point. It's big. It's hard. It's a lot of work. But there's nothing to stop any of these ideas being implemented. And when we have the code to make this all work, we can build something new: the next generation desktop, and call it GNOME 3.0. But we can't keep doing little point-release things and pass a future point-release off as GNOME 3.0 - it doesn't work like that. We'd be crucified. As a separate issue, people have got confused about the API-stability guarantee for the 2.0 series. These were never intended to make GNOME 3.0 a chance to break API for the hell of it; they were a guarantee that we definitely would *not* be breaking API for a good long time - until we got our asses in gear about GNOME 3.0. When GNOME 3.0 comes out, we can deprecate/delete API as we feel fit. I don't think large-scale API breakage is a good idea, and it sounds like the GTK+ team will not be breaking API with GTK+ 3.0. However, we are allowed to reorganise the platform if we need to. This doesn't define GNOME 3.0, though. So let's get coding. -- Andrew (This e-mail is mine and doesn't necessarily represent other people's opinions, specifically any consensus of the GNOME Foundation members, although I'd be right chuffed if it did.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2 infinity and beyond [was Re: Tango and 2.16]
Dan Winship wrote: Andrew Sobala wrote: And it can *all* be done *now.* That's the point. It's big. It's hard. It's a lot of work. But there's nothing to stop any of these ideas being implemented. And when we have the code to make this all work, we can build something new: the next generation desktop, and call it GNOME 3.0. But we can't keep doing little point-release things and pass a future point-release off as GNOME 3.0 - it doesn't work like that. We'd be crucified. Yes, we can do it now, and people *are* doing it now. And each cool new feature will get added to some release as it becomes available. And when the last feature on that list gets committed to CVS, and Alan says OK, NOW can we call it 3.0?, people will say Oh, come on! How can we call this release 3.0? It's clearly just an incremental improvement over 2.38! snip The only way this is going to happen again is if there is similarly massive infrastructural change, and I don't see that happening. I think if everything we want to do with GNOME can be implemented incrementally, you're absolutely right. However, some of the ideas for Topaz (I'm thinking particularly of real first class objects here) would seem to involve such a huge infrastructural change. I accept that I could well be wrong about that, though. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in 2.16
I've been using Tomboy for the last few days and it seriously rocks. +1 ;-) I have one question: Google tells me it should integrate with Beagle, but Beagle searches never return any Tomboy-related results. Should this Just Work? -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome is a problem for OEMs
Daniel Carrera wrote: Hello, I work for an OEM that eagerly wants to sell Linux computers. Hi, I am glad to learn that you want to support Linux on the PCs that you sell. I've spent all afternoon trying to figure out how I, as an OEM, can configure Gnome before giving it to a user. I just want to change some icons on the panel and maybe a menu entry. After exhaustive search, I can only conclude that there is no way to do this. Sabayon is one piece of software that is designed to do the configuration you want on a single PC. If you want a more command-line oriented approach, you could try googling for one of the following: gnome administrators guide gnome customize panel administrator Or a selection of other keywords that all end up at http://www.gnome.org/learn/admin-guide/2.6/ Hopefully that admin guide will contain some of the information you're looking for. If not, please feel free to ask around some more. Oh, and point out which bits you want to customise and can't - if we know where the weaknesses are, it makes it easier to add the functionality in future releases. Hope that helps, -- Andrew [ rest of e-mail snipped ] ___ 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
Rodrigo Moya wrote: On Sun, 2006-04-09 at 22:08 +0100, Andrew Sobala wrote: Corey Burger wrote: On 4/9/06, Luis Villa [EMAIL PROTECTED] wrote: On 4/9/06, Andrew Sobala [EMAIL PROTECTED] wrote: It's worth pointing out that gnome-power-manager is very much a notifier rather than an interactive applet. If your power cable falls out, it pops up a message saying you've lost power. If you're working away from a power source, there's a battery indicator with how much power you've got left... that disappears when you're fully charged. (At least, that's how it's configured on my system.) This isn't the default, FWIW. I do agree that making this the default behavior would be the best approach- better, IMHO, than a regular panel applet. I only want to know about power when something bad is going wrong, which is exactly what the notification area is for. An applet is all the time, and so is the current default behavior in the notification area- both of which are broken. Luis I completely disagree. There are a few good reasons why an icon should be displayed all the time 1. What state the battery is in is always relevant. Power is the single most important thing on a laptop. Without it, you are going nowhere. Whether or not it is a notification icon or an applet is a detail I won't comment on. Nope. I'm working on a laptop at the moment, and I don't care that my battery is fully charged. 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. Seriously, everybody, read the thread. This icon disappears when the battery is fully charged, *and* the laptop is running off mains. Whether this is a good thing or not we can discuss, but half the people in this thread are discussing whether the icon should disappear when the laptop is running off mains but is not fully charged - which is a completely different question. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: policy request: 'make uninstall' should work
Joseph E. Sacco, Ph.D. wrote: Is that a polite way of saying that it is a policy that 'make uninstall' should work in order for an app to be hosted by f.g.o? That sort of policy would be fairly unenforcable. The point of ftp.gnome.org is to distribute components of the GNOME suite - although we do try to enforce quality assurance on applications that are part of GNOME, it's not done by blanket conditions that prevent a tarball upload if they're not met. If an application does not support make uninstall it's a bug. Just like if it crashes on Ubuntu systems, or doesn't translate it's custom text to different languages. The difference is that it gets tested less often and by fewer people. So if you see an application doing this, file a bug - and the maintainer will probably try to fix it. -- Andrew ___ 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
Jaap Haitsma wrote: Richard, As far as I understand the code of GPM splitting up GPM in a daemon and a notication area icon/applet would not be so hard. They are pretty independent from each other. The daemon just has to watch batteries, laptop lid, hardware keys and take appropriate actions etc. If people run the daemon then they get all the power management features. The applet/notification area icon just needs to watch the batteries (code of the daemon can be reused :-) )and show the status by changing it's icon and displaying notifications. The only message I see that the daemon might want to send to the applet is a message that the system is going to suspend/hibernate and that is already something we want to do to notify other apps that the system is going to suspend/sleep and that they need to take appropriate actions if necessary. So in my opinion it's not that difficult, or am I missing something? But what's the point? 1. It's good design to split up parts which are doing different things ( You can also put all your code in one source file, but that's not good design ) 2. An applet would be much more consistent with how GNOME works at the moment. If I want to add something to the panel I just add there by doing Add to panel and if I want to remove it I choose Remove from panel. GNOME unlike windows luckily doesn't put many stuff automagically in the panel :-) It's worth pointing out that gnome-power-manager is very much a notifier rather than an interactive applet. If your power cable falls out, it pops up a message saying you've lost power. If you're working away from a power source, there's a battery indicator with how much power you've got left... that disappears when you're fully charged. (At least, that's how it's configured on my system.) So I don't think a notification-area applet is unreasonable. -- Andrew ___ 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
Corey Burger wrote: On 4/9/06, Luis Villa [EMAIL PROTECTED] wrote: On 4/9/06, Andrew Sobala [EMAIL PROTECTED] wrote: It's worth pointing out that gnome-power-manager is very much a notifier rather than an interactive applet. If your power cable falls out, it pops up a message saying you've lost power. If you're working away from a power source, there's a battery indicator with how much power you've got left... that disappears when you're fully charged. (At least, that's how it's configured on my system.) This isn't the default, FWIW. I do agree that making this the default behavior would be the best approach- better, IMHO, than a regular panel applet. I only want to know about power when something bad is going wrong, which is exactly what the notification area is for. An applet is all the time, and so is the current default behavior in the notification area- both of which are broken. Luis I completely disagree. There are a few good reasons why an icon should be displayed all the time 1. What state the battery is in is always relevant. Power is the single most important thing on a laptop. Without it, you are going nowhere. Whether or not it is a notification icon or an applet is a detail I won't comment on. Nope. I'm working on a laptop at the moment, and I don't care that my battery is fully charged. This is because it's plugged into the wall. If I wasn't plugged into the wall, I'd start caring - but I'd also get a battery symbol. I'd suggest you actually try using g-p-m like this. 2. A hidden icon is impossible to view. Unlike Windows, you cannot expand a slider to see hidden icons. This is because when it disappears, it doesn't give you any information. As a sidenote, I believe the windows slider was invented to leave some room for the task bar when you have 40 icons in your notification area, one for every application installed on the system. The GNOME notification area isn't intended to be (and for the most part, isn't) used in this way, so we don't need a way to hide icons that shouldn't be there in the first place. 3. Consistency. Now this is normally not an argument I think holds any weight, but in this instance I think it does. Without a compelling reason to break consistency with other operating systems/desktop environments, I don't see why we should. I do. We're better :-P -- Andrew ___ 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
Elijah Newren wrote: On 4/9/06, Scott J. Harmon [EMAIL PROTECTED] wrote: Am I the only one who mouses over the applet to see how much more time until the battery is fully charged? Definitely not; I rely on this frequently. I'd be heavily annoyed if the applet wasn't showing (and no other equally easy way of obtaining this information was available) when my laptop is plugged in and not fully charged. If it's both plugged in and fully charged then I'd be fine with it not being there, as long as that was the only case. Hmm. In this configuration, it is. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keeping user docs up-to-date with applications
Sergej Kotliar wrote: On Fri, 2006-03-24 at 21:15 +0100, Vincent Untz wrote: Le vendredi 24 mars 2006 à 16:20 +0300, Nickolay V. Shmyrev a écrit : While looking on discussion of removed screensaver button and work work on GNOME docs translation, one interesting idea came to my mind. Usually UI changes are accepted without change in user documentation thus making docs obsolete (for example, user docs still mention screensaver button and even more, they tell user about Add to panel popup menu with submenus). From other side, maintainers often reject patches with bad formatting or other code guidelines violation. Isn't it better to require that every UI-related patch should have doc patch as well. Usually new API should be documented, why do we ignore user docs? They aren't less important than coding style, probably they even more important. The thing is that the docs are usually not maintained by the modules maintainers. It's easy to reject (well, mark as needs-work) patches because of formatting or non-documentation of new API since those are stuff that is the job of the maintainer. Not to mention that I wouldn't qualify as someone who can write some part of the doc :-) Also, this is why the UI freeze does exist. Maybe it's too late for documentation people, though. IMHO, a good first step would be to ask maintainers to list all the big changes that has been done before UI freeze. Agree completely. Another option, however, is that whenever maintainers do something, they file a bug against the docs component of their product in bugzilla. Generally speaking, this means that every time a developer spends hours and hours implementing a new feature, he needs to spend an additional five minutes writing a very basic outline of what the feature does in bugzilla. A particularly nice maintainer might also list anticipated common gotchas or other quirks. Heck, if the feature (or substantial UI change or whatever) was implemented in response to a bug, the maintainer needn't even file a new docs bug. He can just change the component of the existing bug, rather than closing it. This would give the documentation team a much better chance of documenting as we go, rather than in one lump sum at the end of the release cycle. -- Shaun An even easier solution would be to add the keyword UICHANGE to bugzilla, and let maintainers mark bugs with it whenever they commit anything that changes the UI. In many cases, I think the info in the bugreport would be enough. Of course - if it doesn't have a bug report, one would have to be filed as Shaun suggested. One issue with that is that the bug would also be marked FIXED. Docs people would have to check for UICHANGE in open *plus* resolved bugs in the timeframe since the last release, which can get messy given that people branch at different times. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How To Use Live CD
Michael Avila wrote: Thank you so much for your help. This is my 2nd or 3rd attempt at Linux. So far it is going much better than the previous attempts. I was trying to install it using yum install gnome so I guess I was a little off course! LOL But you got me going. The docs on CentOS give the impression that gnome is indeed installed but I could not find it. My son told me to try setup and look in there but it was not there. I am coming from a Windows background and feel more comfortable using a GUI even though I have been using the DOS command line for years. I have some Solaris experience also. Looking at your commands it looks like I have a lot to learn! But it is going better. Gnome is downloading now. Hopefully I'll have some disk space left as I only have an 8 GB disk and I am trying to set up qmail as a mail server. It is on file 88 of 134 so it should be done soon. Again, THANK YOU VERY MUCH for your assistance for helping me to get a good hold on getting started and a great feeling about Linux. Mike Hi Mike, I'm glad to know you've had success getting GNOME going, and wish you luck with your linux experiences :-) However, without wanting to sound rude, desktop-devel-list is a high-traffic development list and we try to keep user support off the list to make it easier for developers to follow the development-related threads. I suggest that you direct future questions to [EMAIL PROTECTED] Thanks, and have fun! -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Sean D'Epagnier wrote: Isn't it true that scons requires you download and install it as an extra program to use it? Many users may not have scons and may not want to install it, but do want to install gnome (by compiling from source code). This is identical to the situation for autotools. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainership of gnome-common
On Mon, 2005-07-25 at 20:15 -0300, James Henstridge wrote: That would get mail related to non gnome-common related bugs too though, right? Yeah. For future reference, if you want to do it in a bodgy way, you can filter by keeping X-Bugzilla-Reason:.*WatchAssigned then throwing away X-Bugzilla-Reason:.*Assigned tee hee -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
On Jul 22 2005, Murray Cumming wrote: I believe he meant 2.4 (the filechooser release). (yes) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
On Thu, 2005-07-21 at 14:49 -0400, Miguel de Icaza wrote: But there is no reason to tarnish Gnome's reputation because some people feel that Gtk 2.8 is too cool to wait. Shipping a slower, more fragile version of Gnome and which in addition will not benefit for the most part on any of the new 2.8 stuff (if people are following the rules) seems like a loosing proposition. The QA team does not consider a GTK+ 2.8-based GNOME more fragile than a 2.6-based one. The QA team believes the issues involved in upgrading this component of the GNOME desktop are no greater than upgrading any other fundamental library. If you believe otherwise, please e-mail [EMAIL PROTECTED] and let us know your reasons. References to bug numbers would be helpful. I cannot speak for the QA team, but that doesn't make it untrue. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
On Thu, 2005-07-21 at 17:20 -0400, JP Rosevear wrote: There could or could not be significant issues in 2.7. The point is its not certain and it introduces significant *risk* to the schedule. We went through the same thing with 2.6 and it seems we learned nothing, see your own original view: http://mail.gnome.org/archives/desktop-devel-list/2005-June/msg00020.html As well as Andrew's: http://mail.gnome.org/archives/desktop-devel-list/2005-June/msg00022.html Just for reference, the main differences between 2.6 and 2.8 are their stability and completeness *at this point* in the release cycle - ie. the point at which we are committing to one. 2.8 appears to be more stable and complete than 2.6 was. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 15:22 -0400, Luis Villa wrote: We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. It's also quite difficult, because you have to deal with all the postinst stuff which may change without warning. And how to deal with that varies between packages. Oh, and it's worthless unless someone's tinderboxing too :) Because if they're not, the build is guaranteed to fail. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Certification for GNOME apps
On Thu, 2005-07-14 at 12:06 +0200, Danilo Šegan wrote: Yesterday at 21:54, Andrew Sobala wrote: On Wed, 2005-07-13 at 20:42 +0100, Alan Cox wrote: On Mer, 2005-07-13 at 16:27, Federico Mena Quintero wrote: Level 2 - the app is actually written with GTK+. Why does this matter ? Surely it is about degrees of integration and HIG compliance. I agree. I was similarly surprised by (on the wiki) the requirement to use .glade files as a possibility for one level; surely this certification should be about the user experience, not coding practises. It indirectly affects many things. Gtk+ and Glade using applications have a better chance of having consistent user interface AND translations. Maybe it would be Gnome-certified on a lower level, but if it's not using stock menu items, and I have no power over managing it's translation, I wouldn't certify it as fully Gnome since it wouldn't fit on the desktop otherwise. Of course, there are counter examples such as Adobe Acrobat Reader 7.0 which use Gtk+, yet don't make use of any stock labels and icons if I remember correctly. You still don't need to use glade, though. Sure, it makes life easier, but it may also involve rewriting your application - using stock menu items is a GTK feature people can add to their applications (if they're not doing it already) if they want to do it to become GNOME-certified; utilising translations is similar. If they have to do a hefty UI rewrite, they may just ignore the certification standards as being unachievable - at which point you don't get a cool app integrating with the GNOME desktop, but a set of certification standards that are being ignored. Just my feelings, I could be wrong. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Thu, 2005-06-09 at 12:10 +0100, Gustavo J. A. M. Carneiro wrote: It has not been tested it was too soon to test. Why are people so afraid of gtk+ 2.7 without even trying it? It really is quite stable now. I think it's because in these enlightened times, people use the GNOME stack that comes out of jhbuild or Ubuntu Breezy. Both of these distribution methods are semi-official; jhbuild is meant to have The next version of GNOME, Breezy is The next version of Ubuntu, and switching to 2.7 for a trial period *without* having this conversation is ugly and liable to confuse people about what was actually decided. And Cairo does help developers significantly. Anyone doing any kind of drawing and printing will know what I mean. Like, imagine how abiword/gnumeric/criawips would benefit from this. Gnome Print is not an option for most of these programs simply because it's a Gnome library thus not cross platform or needs gnome. There's a great bias against gnome libraries nowadays, unfortunately... And even if it is slower now, it potencially may become much faster than current X11 drawing model, perhaps even when gtk+ 2.8 gets released. Please stop gtk/cairo FUD. Hey hey hey, let's stay calm here. GNOME necessarily works on a short-term-benefit model; the question we need to ask is Is going to GTK+ 2.8 in less than 6 months *definitely* not going to have any negative implications on that version of GNOME? And it's a fair question to ask, because last time we did this the answer was Yes, it did. We're blatantly going to use GTK+ 2.8 by 2.14 at the latest, but GTK+ does work on a cycle with a longer feature-implementing stage, and so necessarily a longer improvements-and-bug-fixing stage. Which is fine. But we need to be careful about it. No-one was implying that Cairo was a Bad Idea (tm), only whether we could be 99% sure of it being as stable as and as fast as the current stable GTK+ in a relatively short timescale. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: So, yeah, I'm pretty strongly against this, though I'm open to persuasion. aolMe too/aol, for all the reasons Luis listed. I remember our r-t discussions basically concluded that we'd made a mistake depending on GTK+ for 2.6. 2.6 had stability issues. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Three Point Zero - Idea Mockups
On Wed, 2005-05-25 at 21:10 +0100, Mike Hearn wrote: On Wed, 25 May 2005 18:35:43 +0200, Markus Bertheau wrote: Can the responsible person create [EMAIL PROTECTED] Mailing list discussion about GNOME 2 can happen there then. I'd suggest gnome-bluesky-list, that way all the free thinking can go to one place regardless of whether it's about GNOME 3 or not. Surely that makes it less useful in the context of getting-something-decided-about-GNOME-3? -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
