Re: Drive applet by default
On 9/14/06, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > [...] > What if I close the window but keep the USB drive attached in order to > access it later in the session? Do I have to open Computer then scan > for the drive? The Place shortcuts are there for a reason: to make > access of commonly used media faster. Well, you would also be able to open the drive via the Places menu. Don't get me wrong though. I do like Ross Burton's suggestion to add a small eject button to disk items in the Places menu, and long term I think it would be great to have both systems in place. Right now though, the API doesn't seem to be there to implement Ross's suggestion. > At this point, I'd go as far as suggesting a sub menu for each volume, > with a "View" item, an eventual "Copy" item (for CD drives) and a > "Eject/Unmount" entry. Needing to navigate into a submenu just to open a disk in Nautilus seems like a huge cost. ___ 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
Më Enj , 2006-09-14 at 18:26 -0400, David Zeuthen ka shkruar: > On Thu, 2006-09-14 at 14:05 +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.). > > Right, I've seen this too. It would be nice to turn power down the USB > device when we've unmounted / ejected it. Unfortunately run-time power > management is pretty weak in Linux but people are actually working on > it. When it lands in Linux and is generally usable, we'll export this in > HAL and it's easy to take advantage of from the desktop. On a laptop this might make sense. On my desktop though, I might want to eject my iPod, but leave it connect and have it continue to charge, if the battery is low. -- dobey ___ 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 23:24 +0100, Toby Smithe wrote: > > Pretty sure the PCMCIA stuff is not needed on recent Linux 2.6. At least > > it just works for me on Fedora and it's not like we're doing anything > > special in userland. > > It doesn't just work. emu10k1 doesn't unload on eject, and when the card > is put back in, it doesn't recognise the card is back. It needs to be > manually unloaded and reloaded. pccardctl doesn't make much difference. > And, yes, I've filed bugs! Pretty sure that is just kernel / driver bugs, not something we should try to work around on the desktop. > I can live with an extra process running to gain this functionality, but > I'm in the minority here, so I'd understand if nothing came of it. Well, one thing is sure. If we start adding features to the desktop to work around broken drivers it will only take longer to get such bugs fixed. Of course, as with everything there's a fine balance... David ___ 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 14:05 +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.). Right, I've seen this too. It would be nice to turn power down the USB device when we've unmounted / ejected it. Unfortunately run-time power management is pretty weak in Linux but people are actually working on it. When it lands in Linux and is generally usable, we'll export this in HAL and it's easy to take advantage of from the desktop. That said, I believe I've seen USB devices that still keep the LED on even when told to suspend. Not sure about that, maybe I'm wrong. David ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Zeuthen wrote: > On Thu, 2006-09-14 at 10:15 -0400, Rodney Dawes wrote: >> Why don't we just put an icon in the tray always, to unmount media, stop >> pcmcia devices, and other nifty things like that, the same as Windows >> does? The latter of those two problems still isn't solved in the >> desktop. We need an easy way to stop pcmcia devices so that they can be >> removed from the slot, as well. > > Pretty sure the PCMCIA stuff is not needed on recent Linux 2.6. At least > it just works for me on Fedora and it's not like we're doing anything > special in userland. It doesn't just work. emu10k1 doesn't unload on eject, and when the card is put back in, it doesn't recognise the card is back. It needs to be manually unloaded and reloaded. pccardctl doesn't make much difference. And, yes, I've filed bugs! I can live with an extra process running to gain this functionality, but I'm in the minority here, so I'd understand if nothing came of it. >> A generic tray icon to deal with all the >> devices that need this functionality would be quite nice to have. > > Right. This would be nice. The code should probably go in > gnome-volume-manager which is to be renamed gnome-hardware-manager > anyway. > > David > > > ___ > Usability mailing list > Usability@gnome.org > http://mail.gnome.org/mailman/listinfo/usability > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCdaxv7fgPJvITk4RAu8aAKCt5LoQCT35VYFDRFkC+nRh3mVosACgpnlx BB/yK164Xmqx7fri8BSO5pg= =KCjT -END PGP SIGNATURE- ___ 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 16:39 +0100, Ross Burton wrote: > > My iAudio M3 says "Do not disconnect!" on its display even after > > unmounting, I don't think this is only cosmetic. > > My iPod does the same. You need to eject the device. Interestly when I > right-click on an iPod on my desktop, I'm pretty certain I get to Eject > instead of Unmount. Right. We have a quirk-list [1] in HAL that catches iPod's. If the eject trick works on other devices (e.g. iAudio M3) we of course take patches to do this. David [1] : http://gitweb.freedesktop.org/?p=hal.git;a=blob;hb=HEAD;f=fdi/information/10freedesktop/10-usb-music-players.fdi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On Thu, 2006-09-14 at 10:15 -0400, Rodney Dawes wrote: > Why don't we just put an icon in the tray always, to unmount media, stop > pcmcia devices, and other nifty things like that, the same as Windows > does? The latter of those two problems still isn't solved in the > desktop. We need an easy way to stop pcmcia devices so that they can be > removed from the slot, as well. Pretty sure the PCMCIA stuff is not needed on recent Linux 2.6. At least it just works for me on Fedora and it's not like we're doing anything special in userland. > A generic tray icon to deal with all the > devices that need this functionality would be quite nice to have. Right. This would be nice. The code should probably go in gnome-volume-manager which is to be renamed gnome-hardware-manager anyway. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On Thu, 2006-09-14 at 17:52 -0400, Ben Maurer wrote: > Is another daemon going to be created in order to do this, something like > ejectable-device-manager? Regardless of any usability issues, this needs > to be doable without a new process on the desktop, so that we don't waste > memory. We have gnome-volume-manager already. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [+gnome] Re: Showing gnome-keyring passwords in Seahorse
On Thu, 14 Sep 2006, Danilo egan wrote: > Yesterday at 20:06, Chipzz <[EMAIL PROTECTED]> wrote: > >> It's really ironic that you go through all the trouble to set up that >> many different passwords, when every password is the same? How does that >> improve security? >> Ssh passphrases were intended as an extra barrier. And for a good reason >> too. If you do not like that barrier, then why do you use it in the first >> place? >> But what you're arguing sounds a lot like: I don't want any passwords, >> lets do away with them all together. > > It's a bit different: I have one really, really hard and long password > for gnome-keyring. And all my different passwords in the keyring are > usually simpler (yet any "password strength meter" would characterize > them as strong), but I do not need to type them all. You are Which is exactly the way gnome-keyring is supposed to be used. :) > suggesting that it would be same for me if I had to type this "really, > really hard and long" password each and everytime? This would imply that I suggested using the same password everywhere (as in: for login password, ssh passphrase, gnome keyring passphrase) - exac- tly the opposite is true, or that you think I'm against the use of gnome keyring, which is also incorrect: I'm against the *incorrect usage* of gnome keyring, since that actually decraeses security instead of impro- ving it. I was trying to point out that I find it peculiar that Wouter complains about having to type too much passwords, but for example still bothers to set up a BIOS password - a little contradictionary, isn't it? As for your long password (passphrase actually ;)), with both ssh-agent and gnome-keyring you only have to enter it once. Which is why it matters little (from the pov of the user typing it in) that it's long in the first place. Which is exactly why I'm arguing against using the same login pass and ssh/gnome-keyring passphrase. > No it wouldn't, at least imho. > > And some passwords I have there are really crap ones for things I > don't care about, yet require me to have a password. > > Cheers, > Danilo kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'." ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
Is another daemon going to be created in order to do this, something like ejectable-device-manager? Regardless of any usability issues, this needs to be doable without a new process on the desktop, so that we don't waste memory. -b On Thu, 14 Sep 2006, David Prieto wrote: > I've noticed that some people coming from windows have trouble removing > USB devices and the like, because they don't quite know what to do to > "safely remove the device". > > They come from windows and they're used to look into the system tray to > unmount removable. There's no way for them to know that they have to > right-click the desktop icon, then navigate the options they're given > until they find the "secret" (as in "doesn't show on any other desktop > icon") eject option. > > The drive applet offers a handy solution for those people, and remains > unobstrusive because you don't even see it unless there's a device in, > but you can access it anytime without having to show the desktop. So I > think it would be a good thing to have it included on the panel by > default. Another good solution would be to get a notification balloon > each time a USB device is inserted, to inform the user about the needed > procedure, and a second one to inform them that the device can be > removed, just like windows does. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Maxim Udushlivy wrote: > BJörn Lindqvist wrote: >> I think you are 100% right and that it is important for GNOME to >> narrow its focus. For example, if GNOME limited its focus to computers >> with 256 MB of RAM, then... > I was proposing to narrow Gnome by ideology (implementation style), > Havok - by desktop tasks (implementation scope), you - by hardware > requirements (implementation details). What is more viable? > Additional point: - narrowing by scope tells people *what* things to do: the freedom is sacrificed (impossible for Gnome?) - narrowing by style tells people *how* to do things: people are educated (if the style is good) >> And it is not just the memory requirements for GNOME that needs to be >> decided. I agree that choosing a specific target niche would be very >> useful. Problem is, how are you going to do it? GNOME doesn't have a >> BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the >> target niche is? Many of the most successful free software projects >> (Linux and Python for example) have a BFDL, that person has a clear >> vision about how they want their product to be. Everyone else has just >> to accept that vision or leave the project. GNOME is different in that >> regard, different developers have different visions and when they >> clash, big debates erupt on this mailing list. >> >> Debates that really doesn't solve the problems and doesn't find a >> common ground... >> >> > There is an interesting observation on how laws are being developed in > the USA: they are formulations of common practices. I.e. those laws do > not try to change behavior of people, instead they enforce something > that already exists and works. That's why I propose with a pure > conscience a position of Gnome Moderator (who is not a Dictator but an > anti-crisis manager). It is very common for an on-line community to > have a moderator. > > With a moderator endless debates would be impossible since there will > be a man to whom you could prove that your practices (of vision of > practices of others) Typo: ...(*or* vision of practices of others)... > are efficient and deserves to become a law. Currently people just > express their opinions without any effect - a boiling water inside a > teapot that could otherwise become a steam engine. > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
So clearly we need to choose a number relatively prime to 12 if this is desirable. With 9 months there's only 4 possible months for release. If you did, say, 7 months, then you'd never repeat a month until you'd hit 'em all :-) -Rob On Fri, 2006-09-08 at 10:43 -0400, Pat Suwalski wrote: > Elijah Newren wrote: > > I used to be firmly in favor of the 6-month cycle, but I found > > Andrew's argument quite convincing and it has turned me into more of a > > fence sitter for now. It isn't yet clear to me that a change would be > > a definite improvement, let alone enough of a benefit to merit the > > change in the process, but that may well change. > > I think this is why an alternating 6 and 12 month cycle would be nice. A > 9 month cycle would be even more interesting, because the dates would > not always fall at the same times. > > --Pat > ___ > 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: [Usability] Drive applet by default
On Thu, 2006-09-14 at 14:55 +0200, 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. If "eject" (the command-line tool) works, then your drive needs special-casing in HAL, through an fdi file, just like the iPod. -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
> > E.g., similar to how the Nautilus CD/DVD Creator already has a Write > > to Disc button, an eject button could be added to Nautilus windows > > that represent disks. > At this point, I'd go as far as suggesting a sub menu for each volume, > with a "View" item, an eventual "Copy" item (for CD drives) and a > "Eject/Unmount" entry. Those are two very valid suggestions, I think. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On Thu, 2006-09-14 at 19:30 +0200, Jonas De Vuyst wrote: > On 9/14/06, Ross Burton <[EMAIL PROTECTED]> wrote: > > [...] > > How feasible would it be to add an Eject icon to the removable drive > > menu entries under Places? Split the menu item into two so that > > clicking the main icon and text opens the device in Nautilus as usual, > > but there is an eject icon on the far right. > > [...] > > It could also be made more easy to eject the device once you click on > it in the Places menu: > > http://bugzilla.gnome.org/show_bug.cgi?id=163687 > > E.g., similar to how the Nautilus CD/DVD Creator already has a Write > to Disc button, an eject button could be added to Nautilus windows > that represent disks. > > On the assumption that users usually keep the disk window opened, this > would even make ejecting a drive a one click operation. What if I close the window but keep the USB drive attached in order to access it later in the session? Do I have to open Computer then scan for the drive? The Place shortcuts are there for a reason: to make access of commonly used media faster. At this point, I'd go as far as suggesting a sub menu for each volume, with a "View" item, an eventual "Copy" item (for CD drives) and a "Eject/Unmount" entry. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On 9/14/06, Ross Burton <[EMAIL PROTECTED]> wrote: > [...] > How feasible would it be to add an Eject icon to the removable drive > menu entries under Places? Split the menu item into two so that > clicking the main icon and text opens the device in Nautilus as usual, > but there is an eject icon on the far right. > [...] It could also be made more easy to eject the device once you click on it in the Places menu: http://bugzilla.gnome.org/show_bug.cgi?id=163687 E.g., similar to how the Nautilus CD/DVD Creator already has a Write to Disc button, an eject button could be added to Nautilus windows that represent disks. On the assumption that users usually keep the disk window opened, this would even make ejecting a drive a one click operation. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies
Hi David, On 9/13/06, David Zeuthen <[EMAIL PROTECTED]> wrote: > It's really what audience we want to optimize for. There are (at least) > two groups of entities that provide the GNOME experience to users; > This of course is only one example. I submit this is a trade off and it > really depends on who we want to optimize for. No, this issue is bigger than target audience. Testers, documenters, and developers often need a development version of GNOME to get their work done. Requiring them to have very recent versions of nearly everything on their system is much too high a bar. In fact, the building bar is so high right now that I believe nearly everything else in GNOME is currently suffering; the difficulty of building GNOME has even taken a large amount of time from some of the more experienced developers. (Note that I'm by no means just blaming HAL here; we have lots of issues. External dependencies in general have been the biggest problems in the build area in the recent past, thus the proposal to stop depending on cvs versions of those.) > Actually I think one answer to this whole mess might be to make > GARNOME / jhbuild just use the OS provided versions of HAL and D-BUS. > Each module that happens to use HAL would have it's own minimum version > of HAL required and if that version is not met then it either > > 1) builds without HAL support; > 2) refuse to build > > and ditto for other non-GNOME deps such as Avahi, CUPS and possibly even > Mozilla, X.org and so forth. Certainly jhbuild and GARNOME ought to be > able to do that, yes? > > I think this is the best compromise, I'm curious what others think. Something like this looks like a good compromise to me. I think there may be too many modules with a hard dependency on a newer version of dbus to use distributor versions of it for now; however, it may work out for HAL. Cheers, Elijah ___ 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 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. Xav ___ 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 14:55 +0200, 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. My iPod does the same. You need to eject the device. Interestly when I right-click on an iPod on my desktop, I'm pretty certain I get to Eject instead of Unmount. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [+gnome] Re: Showing gnome-keyring passwords in Seahorse [was: Proposal for Seahorse inclusion in GNOME 2.18]
På Wed, Sep 13, 2006 at 08:06:24PM +0200, Chipzz skrev: > [snip] > It's really ironic that you go through all the trouble to set up that > many different passwords, when every password is the same? How does that > improve security? My passwords are not the same. Only my login password, the password for gnome-keyring (which contains several other passwords) and the password (or passphrase) to unlock my ssh keys are the same. My Evolution directly connects over ssh to a remote /usr/bin/imapd (no password needed since it uses ssh-agent). I do see the advantages of this approach, but presumably you don't. > [snip] > But what you're arguing sounds a lot like: I don't want any passwords, > lets do away with them all together. You obviously don't get the point. I guess you're the kind of guy that remembers 4 WEP keys, because saving them (encrypted in gnome-keyring!) on-disk is too much of a risk for you. mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl and it's you i see :: but you don't see me -- coldplay signature.asc Description: Digital signature ___ 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
I'm talking about the usb devices... pen drive... exactly.. :) On 9/14/06, David Prieto <[EMAIL PROTECTED]> wrote: > El jue, 14-09-2006 a las 08:01 -0300, Thiago Ribeiro escribió: > > In some cases you click to eject.. but the device continues enable, > > with its light on.. I think that it is a problem with the system.. but > > the users continue confused because the light don't turn off... and > > this don't pass confidence to user.. because when you turn off the usb > > on windows the lights turn off... > > I'm not sure if you're talking about devices like a CD or a USB. If it's > the latter, maybe stuff could be being written to the device, though you > get a notification window. > > If you mean a CD, it could just be in use. > > -- Thiago Ribeiro jabber: [EMAIL PROTECTED] icq: 59298898 ___ 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
In some cases you click to eject.. but the device continues enable, with its light on.. I think that it is a problem with the system.. but the users continue confused because the light don't turn off... and this don't pass confidence to user.. because when you turn off the usb on windows the lights turn off... On 9/14/06, David Prieto <[EMAIL PROTECTED]> wrote: > El jue, 14-09-2006 a las 10:04 +0100, Ross Burton escribió: > > How feasible would it be to add an Eject icon to the removable drive > > menu entries under Places? Split the menu item into two so that > > clicking the main icon and text opens the device in Nautilus as usual, > > but there is an eject icon on the far right. > > I have often right-clicked the drive entry in hope to get an option to > unmount it, but what you're suggesting would be cool too, in case it can > be done. > > ___ > Usability mailing list > Usability@gnome.org > http://mail.gnome.org/mailman/listinfo/usability > -- Thiago Ribeiro jabber: [EMAIL PROTECTED] icq: 59298898 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [+gnome] Re: Showing gnome-keyring passwords in Seahorse [was: Proposal for Seahorse inclusion in GNOME 2.18]
På Tue, Sep 12, 2006 at 02:12:57PM +0200, Chipzz skrev: > Yes, and it is an very stupid idea to use it. Reading those entries, it > would appear you are just being lazy and care little about security. What's wrong/insecure with unlocking your WLAN key on login? > I don't see the point in saving yourself a few keystrokes, especially > since you only have to type your ssh passphrases once (at the beginning > of your session), and your gnome keyring passphrase also only once. I > would advise strongly against using it. So, adding Evolution to the list, your recommendation is that I type 6 (bios/boot, gdm login, ssh, gpg, wlan, email) passwords each time I boot my computer (which is several times a day when I'm on the road). Thanks for your helpful advice. I'll make sure I'll type 6 passphrases to get my computer to work. It will greatly improve my computer experience and my feeling of security. Thanks, again. mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl try walking in my shoes :: you stumble in my footsteps -- depeche mode signature.asc Description: Digital signature ___ 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, 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. Michael ___ 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
--- Thiago Ribeiro <[EMAIL PROTECTED]> wrote: > In some cases you click to eject.. but the device > continues enable, > with its light on.. I think that it is a problem > with the system.. but > the users continue confused because the light don't > turn off... and > this don't pass confidence to user.. because when > you turn off the usb > on windows the lights turn off... FWIW this is a bug on OS X too... ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
BJörn Lindqvist wrote: > I think you are 100% right and that it is important for GNOME to > narrow its focus. For example, if GNOME limited its focus to computers > with 256 MB of RAM, then... I was proposing to narrow Gnome by ideology (implementation style), Havok - by desktop tasks (implementation scope), you - by hardware requirements (implementation details). What is more viable? > And it is not just the memory requirements for GNOME that needs to be > decided. I agree that choosing a specific target niche would be very > useful. Problem is, how are you going to do it? GNOME doesn't have a > BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the > target niche is? Many of the most successful free software projects > (Linux and Python for example) have a BFDL, that person has a clear > vision about how they want their product to be. Everyone else has just > to accept that vision or leave the project. GNOME is different in that > regard, different developers have different visions and when they > clash, big debates erupt on this mailing list. > > Debates that really doesn't solve the problems and doesn't find a > common ground... > > There is an interesting observation on how laws are being developed in the USA: they are formulations of common practices. I.e. those laws do not try to change behavior of people, instead they enforce something that already exists and works. That's why I propose with a pure conscience a position of Gnome Moderator (who is not a Dictator but an anti-crisis manager). It is very common for an on-line community to have a moderator. With a moderator endless debates would be impossible since there will be a man to whom you could prove that your practices (of vision of practices of others) are efficient and deserves to become a law. Currently people just express their opinions without any effect - a boiling water inside a teapot that could otherwise become a steam engine. ___ 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
Please discuss on one list at a time to avoid confusing crosstalk which can make things very difficult to follow. Please do not crosspost. On Thu, 14 Sep 2006, David Prieto wrote: > Date: Thu, 14 Sep 2006 10:44:42 +0200 > From: David Prieto <[EMAIL PROTECTED]> > To: usability@gnome.org, desktop-devel-list@gnome.org > Subject: [Usability] Drive applet by default > > I've noticed that some people coming from windows have trouble removing > USB devices and the like, because they don't quite know what to do to > "safely remove the device". Makes sure you are finished transferring and then unplug the damned thing. It should be that simple. The system Windows provides really sucks, and I largely ignore. Sucks rocks, through a hosepipe. I would hope Apple have a system that doesn't suck quite so much. The problem is that if I was the kind of user who didn't know files were still copying to the removable drive I would potentially lose data. There is an underlying problem which needs to be solved. If a write to a removable drive is interuppted users should be warned and preferably given the chance to plug back in the device and resume the transfer. This is no different for a pendrive or a network drive halfway across the internet and might require some complicated caching in the background. The drive mount applet shouldn't even come into it. If we must manually mount drives it should be made clear this is a crappy limitation of current technology. Having used other systems, it feels like a giant step backwards to have manually mount drives and suffer such a convoluted eject process. -- Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Thu, 2006-09-14 at 11:22 +0200, BJörn Lindqvist wrote: > > > Then lets stop the target! If I understand you correctly, the > > > development process from the documentors point of view is kind of > like > > > this. > > > > > > * Five months were developers play and pretty much destroy all the > docs we make. > > > * Four weeks were we can undo the damage caused and make GNOME > understandable. > > > > > > Maybe this problem can be solved by elevating the documentations > and > > > the translations status in the project? For example, patches are > very > > > seldom accepted if they introduce regressions in the software. But > > > regressions in the docs aren't counted in the same way. New code > very > > > often changes applications behaviour so that the manual becomes > > > invalid. What if the documentation and translation regressions > were > > > counted in the same way as code regressions? > > > > > > To me, that makes sense. An untranslated string is just as > annoying as > > > a frequently segfaulting program. So lets treat the problems the > same. > > > Code that changes behaviour shouldn't be committed unless the > > > documentation is updated. User visible strings shouldn't be > changed > > > unless the translations are updated. Something like that? > > > > 1. Code truly is more important than documentation, that's why > it's > > treated more importantly; > > I disagree slightly. Bad docs means lowered usability. For example, > try this: open gnome-terminal, Edit->Current profile->compatibility > tab. Now I consider myself fairly computer-savvy but I can't figure > out what those settings do. Pressing the help button and reading the > documentation is unhelpful. So the settings on that tab pane are > completely wasted for me and, I suspect, for 99.9% of all > gnome-terminal users since they are incomprehensible. > > But IF the docs had been written at the same time as the tab pane was > programmed, I believe that the problems with that pane would have > became apparent. Many features are easy to implement but hard to > document. I wrote about a similar scenario about a year ago, except I wrote about the Evolution account editor dialog. See the section "The Case for Help" here: http://www.gnome.org/~shaunm/quack/mallard.xml In this situation, the documentation does actually exist. It's just not very good documentation. If we required people to submit documentation with all patches, I fear we'd end up with more documentation like that. Technically complete, but practically useless. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
> Why don't we just put an icon in the tray always, to unmount media, stop > pcmcia devices, and other nifty things like that, the same as Windows > does? The drive applet already does that, why don't we just put it on the panel? :? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On Thu, 2006-09-14 at 10:04 +0100, Ross Burton wrote: > On Thu, 2006-09-14 at 10:44 +0200, David Prieto wrote: > > I've noticed that some people coming from windows have trouble removing > > USB devices and the like, because they don't quite know what to do to > > "safely remove the device". > > How feasible would it be to add an Eject icon to the removable drive > menu entries under Places? Split the menu item into two so that > clicking the main icon and text opens the device in Nautilus as usual, > but there is an eject icon on the far right. > > This may be crack and the usability team might burn me down for this of > course... :) Indeed. ;) Why don't we just put an icon in the tray always, to unmount media, stop pcmcia devices, and other nifty things like that, the same as Windows does? The latter of those two problems still isn't solved in the desktop. We need an easy way to stop pcmcia devices so that they can be removed from the slot, as well. A generic tray icon to deal with all the devices that need this functionality would be quite nice to have. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dbus-launch and gnome-session
Danilo Šegan wrote: > Yesterday at 11:46, Gustavo J. A. M. Carneiro wrote: > >> On Ter, 2006-09-12 at 23:22 -0500, Scott J. Harmon wrote: >>> ... some of their hair... >>> ...I was pulling my hair out ... >>> ...much hair pulling and such... >> Been there myself. > > So, how's your hair today? :) > > Cheers, > Danilo Slowly growing back ;-) Scott. -- "Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra ___ 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
> 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.). I never noticed that, so I don't know what to say. Anyway, would you be so kind to comment on my proposal? I'd like some feedback on that :) ___ 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
2006/9/14, David Prieto <[EMAIL PROTECTED]>: > El jue, 14-09-2006 a las 08:12 -0300, Thiago Ribeiro escribió: > > I'm talking about the usb devices... pen drive... exactly.. :) > > This lacked any kind of notification in previous gnome versions, which > led to data loss because of people pulling their pen drives while in > use, but it's supposed to be fixed now. > > Maybe you mean a whole different problem? 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.). Isak ___ 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
El jue, 14-09-2006 a las 08:12 -0300, Thiago Ribeiro escribió: > I'm talking about the usb devices... pen drive... exactly.. :) You know that it is when you unmount the applet that all writing opperations are performed, right? This lacked any kind of notification in previous gnome versions, which led to data loss because of people pulling their pen drives while in use, but it's supposed to be fixed now. Maybe you mean a whole different problem? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
On Thu, 2006-09-14 at 09:06 +0200, Baptiste Mille-Mathias wrote: > > > Ter, 2006-09-12 às 14:26 -0400, Hubert Figuiere escreveu: > > > > Why not? The language and needed dependencies, including runtime, is just > > an other > > parameter of teh software. What'sw wrong with disliking Mono or Python or > > C++? > > > > > > Sander > > > > .sigless > > > > > > Hello > > I think some people forget the main goal of this thread: "should we > include LAT in GNOME for release 2.18 ?" > Before any language debate, we should focus on why LAT should or > shouldn't be included in GNOME. (specially because the language debate > for Mono is over, and I'm not a pro mono guy). > > For me, I would say No, as don't see really a reason to include LAT in > GNOME, because administrating LDAP is not a common task. Even if we > consider the Administrator platform (pessulus, sabayon), these tools > are for administrating GNOME desktop, and not for general > administration. > but a LDAP admin tool serves the purpose of managing users that run the GNOME desktop :-) That is, it will consolidate the admin suite into something that system admins would base their decision on to install GNOME instead of another desktop. -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The future of session management in GNOME
Tommi Komulainen wrote: > On 9/13/06, Brian Nitz <[EMAIL PROTECTED]> wrote: > >> Why do we ever log out? >> 4) Free up resources. ??? >> >> Reason 4 is especially interesting for multiuser systems, especially >> thin clients. It might be interesting for embedded uses of GNOME >> (laptop/child, maemo...) to reduce resources when user isn't looking. >> > > For single user embedded case I can't suddenly think of anything > logging out would provide that idle/screensaver mode and offline mode > wouldn't. When the user isn't watching you should've already stopped > all timers and screen updates. Except for possible music playing and > network transfers, when the screen is blanked nothing should be > happening. > I agree, what I'm proposing is a unified method of using "I'm not present" information to stop timers and screen updates instead of logging out. For embedded you have control over timers and screen updates, but my guess is that maemo has their own solution and OLPC has another one and multiuser yet another. For desktop and laptop PCs you can invoke the kernel's power management to save the state of the entire machine (rather than the session), but this doesn't work for multiuser. > Also doing more work (saving state, shutting down applications) just > to do more work later (restarting the apps, restoring state) might not > be the brightest idea unless you know the extra memory would be better > spent elsewhere (but where? nothing should be happening when the user > isn't looking.) > Yes. That's why I was considering a way of avoiding logout and yet avoid consuming resources when the user isn't present. But now that I look at it, when the screen is blank and I have terminal, evolution and a few other apps running, only at-spi-registryd and mixer_applet2 appear hot enough to be worth bothering about. Memory usage while idle is a more significant issue. In multiuser its obvious where the extra memory would be used. In embedded its more a matter of reducing power consumption by avoiding cache misses to flash or disk. But if the kernel is doing it's job, memory from idle user processes should be paged out, so I think we're better off attacking that problem by reducing general bloat rather than introducing page/swap complexity into the session manager. ___ 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
El jue, 14-09-2006 a las 08:01 -0300, Thiago Ribeiro escribió: > In some cases you click to eject.. but the device continues enable, > with its light on.. I think that it is a problem with the system.. but > the users continue confused because the light don't turn off... and > this don't pass confidence to user.. because when you turn off the usb > on windows the lights turn off... I'm not sure if you're talking about devices like a CD or a USB. If it's the latter, maybe stuff could be being written to the device, though you get a notification window. If you mean a CD, it could just be in use. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
On Qui, 2006-09-14 at 04:11 +0100, Sander Vesik wrote: > --- "Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> wrote: > > > Ter, 2006-09-12 às 14:26 -0400, Hubert Figuiere escreveu: > > > > I would like to propose LAT 1.2.x for inclusion in GNOME, specifically > > > > to the Admin Suite. > > > > > > What was meant to happen is now happening. Now that Mono has been > > > "blessed" > > > for note taking application, people try to push their own tools written > > > for > > > Mono into Gnome. > > > > > > My vote is NO. > > > > You are voting no because it's written in Mono, with no further > > explanation; sorry, you are not allowed to do that. > > > > Why not? The language and needed dependencies, including runtime, is just an > other > parameter of teh software. > What'sw wrong with disliking Mono or Python or C++? "Disliking Mono or Python or C++" is too subjective. You have to characterize the program as a whole, like does it takes too much memory, is it slow, is the code is hard to maintain by 3rd parties because it uses an esoteric language, etc. etc. Programming language can have an effect on these characteristics, sure, but ultimately it is not the programming language that matters per se. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
> > Then lets stop the target! If I understand you correctly, the > > development process from the documentors point of view is kind of like > > this. > > > > * Five months were developers play and pretty much destroy all the docs we > > make. > > * Four weeks were we can undo the damage caused and make GNOME > > understandable. > > > > Maybe this problem can be solved by elevating the documentations and > > the translations status in the project? For example, patches are very > > seldom accepted if they introduce regressions in the software. But > > regressions in the docs aren't counted in the same way. New code very > > often changes applications behaviour so that the manual becomes > > invalid. What if the documentation and translation regressions were > > counted in the same way as code regressions? > > > > To me, that makes sense. An untranslated string is just as annoying as > > a frequently segfaulting program. So lets treat the problems the same. > > Code that changes behaviour shouldn't be committed unless the > > documentation is updated. User visible strings shouldn't be changed > > unless the translations are updated. Something like that? > > 1. Code truly is more important than documentation, that's why it's > treated more importantly; I disagree slightly. Bad docs means lowered usability. For example, try this: open gnome-terminal, Edit->Current profile->compatibility tab. Now I consider myself fairly computer-savvy but I can't figure out what those settings do. Pressing the help button and reading the documentation is unhelpful. So the settings on that tab pane are completely wasted for me and, I suspect, for 99.9% of all gnome-terminal users since they are incomprehensible. But IF the docs had been written at the same time as the tab pane was programmed, I believe that the problems with that pane would have became apparent. Many features are easy to implement but hard to document. > 2. If you raise the bar for accepting contributions, making > contributors update documentation at the same time, you'll surely have > less contributions; Many projects have a formal or informal guideline that unit tests need to be included for new code to be accepted. That doesn't seem to have slowed them down. But I agree that it is the documenters that must write the documentation. But now they have six months to do it rather than just the four weeks prior to a release when code freeze is in effect. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
El jue, 14-09-2006 a las 10:04 +0100, Ross Burton escribió: > How feasible would it be to add an Eject icon to the removable drive > menu entries under Places? Split the menu item into two so that > clicking the main icon and text opens the device in Nautilus as usual, > but there is an eject icon on the far right. I have often right-clicked the drive entry in hope to get an option to unmount it, but what you're suggesting would be cool too, in case it can be done. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drive applet by default
On Thu, 2006-09-14 at 10:44 +0200, David Prieto wrote: > I've noticed that some people coming from windows have trouble removing > USB devices and the like, because they don't quite know what to do to > "safely remove the device". How feasible would it be to add an Eject icon to the removable drive menu entries under Places? Split the menu item into two so that clicking the main icon and text opens the device in Nautilus as usual, but there is an eject icon on the far right. This may be crack and the usability team might burn me down for this of course... :) Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
On 9/11/06, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Maxim Udushlivy wrote: > > I remember somebody compared Gnome with a car. But the desktop is an > > environment, so it is not a car, it is a parking. The same goes about a > > hammer: desktop environment is a collection of tools. Different tasks > > require different collections. The items that you mentioned may fit very > > well into one desktop ideology (e.g. simplicity) as several profiles. > > > > It is possible to make a parallel with Eclipse IDE which has profiles > > (they call them perspectives). There are profiles for Java source code > > editing, SVN browsing, debugging, etc. Every profile has its own layout > > and a set of opened sub-windows (hammers). All profiles are Eclipse-style. > > > > Desktops have so-called workspaces (never used them), may be they could > > be extended into task-oriented profiles?! > > [SNIP lots of about GNOME:s focus] > Still, the broadest, most general-purpose description of IBM Workplace > is still tightly focused on corporate office workers with IT staff > (GNOME has not narrowed down to that) and the broadest, most > general-purpose description of the Eclipse IDE is that it's for > developers (GNOME has not narrowed down to that either). I think you are 100% right and that it is important for GNOME to narrow its focus. For example, if GNOME limited its focus to computers with 256 MB of RAM, then there wouldn't need to be huge debates of the advantages and disadvantages of Mono. It would be a no-brainer to include it because with that much memory, a virtual machine hurts no one. On the other hand, if it was decided that GNOME targets computers with less than 64 MB of RAM, then it would be a no-brainer to exclude it (along with Python and all other memory hungry stuff). IMHO, it would be better for GNOME to target the high-end machines because the low-end "market" is already occupied by XFCE. And it is not just the memory requirements for GNOME that needs to be decided. I agree that choosing a specific target niche would be very useful. Problem is, how are you going to do it? GNOME doesn't have a BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the target niche is? Many of the most successful free software projects (Linux and Python for example) have a BFDL, that person has a clear vision about how they want their product to be. Everyone else has just to accept that vision or leave the project. GNOME is different in that regard, different developers have different visions and when they clash, big debates erupt on this mailing list. Debates that really doesn't solve the problems and doesn't find a common ground... It appears to me that GNOME is in many ways in a similar situation as Debian/Ubuntu (see: http://www.markshuttleworth.com/archives/56 and http://mjg59.livejournal.com/66647.html). GNOME itself isn't very focused but has provided others with components on which they can build a more coherent system (http://www.novell.com/products/desktop/). I wonder if that clearly superior Novell-Windows Start menu look-a-like will ever be included in GNOME? -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Drive applet by default
I've noticed that some people coming from windows have trouble removing USB devices and the like, because they don't quite know what to do to "safely remove the device". They come from windows and they're used to look into the system tray to unmount removable. There's no way for them to know that they have to right-click the desktop icon, then navigate the options they're given until they find the "secret" (as in "doesn't show on any other desktop icon") eject option. The drive applet offers a handy solution for those people, and remains unobstrusive because you don't even see it unless there's a device in, but you can access it anytime without having to show the desktop. So I think it would be a good thing to have it included on the panel by default. Another good solution would be to get a notification balloon each time a USB device is inserted, to inform the user about the needed procedure, and a second one to inform them that the device can be removed, just like windows does. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
Corey Burger wrote: > > >> For me, I would say No, as don't see really a reason to include LAT in >> GNOME, because administrating LDAP is not a common task. Even if we >> consider the Administrator platform (pessulus, sabayon), these tools >> are for administrating GNOME desktop, and not for general >> administration. >> > > Administrating LDAP = administrating computer (of which, there are > more desktops than servers) = administrating GNOME. > > Ask Jorge Castro (whiprush) or any of the other people who deploy > GNOME in a corporate environment about this. Having a good set of > tools for this task is something GNOME has been lacking for awhile. > This is why the admin suite was created in the first place. > > > As an administrator of gnome desktops, I add my voice to yours to say that a better integration of the Gnome desktop with LDAP would be a great enhancement. I think LDAP is used more and more in the corporate environement, replacing old things like NIS on Unix and making the integration easier in a Windows environement with an AD (I don't like this but it is the corporate reality). Now I can't say for the moment if LAT is the right tool to achieve this, since I didn't find the time to test it yet but it seems at least promising. Sorry for my bad english, Regards, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
> Hello > > I think some people forget the main goal of this thread: "should we > include LAT in GNOME for release 2.18 ?" > Before any language debate, we should focus on why LAT should or > shouldn't be included in GNOME. (specially because the language debate > for Mono is over, and I'm not a pro mono guy). > > For me, I would say No, as don't see really a reason to include LAT in > GNOME, because administrating LDAP is not a common task. Even if we > consider the Administrator platform (pessulus, sabayon), these tools > are for administrating GNOME desktop, and not for general > administration. Administrating LDAP = administrating computer (of which, there are more desktops than servers) = administrating GNOME. Ask Jorge Castro (whiprush) or any of the other people who deploy GNOME in a corporate environment about this. Having a good set of tools for this task is something GNOME has been lacking for awhile. This is why the admin suite was created in the first place. Corey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
> > Ter, 2006-09-12 às 14:26 -0400, Hubert Figuiere escreveu: > > Why not? The language and needed dependencies, including runtime, is just an > other > parameter of teh software. What'sw wrong with disliking Mono or Python or C++? > > > Sander > > .sigless > > Hello I think some people forget the main goal of this thread: "should we include LAT in GNOME for release 2.18 ?" Before any language debate, we should focus on why LAT should or shouldn't be included in GNOME. (specially because the language debate for Mono is over, and I'm not a pro mono guy). For me, I would say No, as don't see really a reason to include LAT in GNOME, because administrating LDAP is not a common task. Even if we consider the Administrator platform (pessulus, sabayon), these tools are for administrating GNOME desktop, and not for general administration. Thanks for attention. -- Baptiste Mille-Mathias Les gens heureux ne sont pas pressés (merci vuntz) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
