Re: New modules in 2.14
Le vendredi 20 janvier 2006 à 22:52 +, Gustavo J. A. M. Carneiro a écrit : > I propose the following: if there's an API/ABI break after the GNOME > API freeze deadline (which only applies for gnome devel platform > modules, of course), then desktop library maintainers are strongly > advised to notify bindings authors by sending an email to the > language-bindings list. This should be enough, I think. Actually, the mail should probably also be sent to d-d-l (or maybe devel-announce-list?) since other modules depending on the library might need a change. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 13:35 -0700, Elijah Newren wrote: > On 1/20/06, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > > Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: > > > > I make a best effort (which is sometimes lacking, in particular I just > > > realized I've always forgotten to notify the bindings people -- which > > > is perhaps why you see it as no different) to at least notify apps > > > that I know are affected and often also provide patches. > > Note the above parenthetical comment... > > > > I wouldn't bother notifying anyone if I broke ABI of > > > libmetacity-private (other than control-center), even if it was during > > > a micro point release during the stable cycle. > > > > This already happened once with wnck, with nasty results: > > http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html > > But we understand the limitations of API guarantees and live with it. > > Yup, this was an example of where I sucked as mentioned in the > previous comment. I probably should have notified bindings in the > past of wnck API/ABI changes. Would it make sense to do so in the > future? Would a mail to language-bindings@ be sufficient for that > purpose? I think that API/ABI changes will be noticed after a while and fixed. But if library authors change API/ABI very near the GNOME release date, the errors could go unnoticed until too late. I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think. > > > So I've finally released the split g-p-e/g-p-d packages, leaving > > metacity in g-p-e and untouched. I almost thought about renaming to > > you mean g-p-d? ;) Yes, of course. Sorry. :) > > > metacity.private, but it's ugly, and I thought this discussion had died > > out with no much concern. At the time I received this email, I had > > already uploaded the packages. I hope this will not cause much concern, > > but I guess renaming the module or issuing a warning during import is > > still a viable option. > > Nah, don't worry about the renaming or giving a warning. As you've > pointed out, this really is not different for you than how you've had > to deal with wnck in the past; since you're fine with that, I don't > see any problems. Thanks. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic 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: New modules in 2.14
On 1/20/06, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: > > I make a best effort (which is sometimes lacking, in particular I just > > realized I've always forgotten to notify the bindings people -- which > > is perhaps why you see it as no different) to at least notify apps > > that I know are affected and often also provide patches. Note the above parenthetical comment... > > I wouldn't bother notifying anyone if I broke ABI of > > libmetacity-private (other than control-center), even if it was during > > a micro point release during the stable cycle. > > This already happened once with wnck, with nasty results: > http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html > But we understand the limitations of API guarantees and live with it. Yup, this was an example of where I sucked as mentioned in the previous comment. I probably should have notified bindings in the past of wnck API/ABI changes. Would it make sense to do so in the future? Would a mail to language-bindings@ be sufficient for that purpose? > So I've finally released the split g-p-e/g-p-d packages, leaving > metacity in g-p-e and untouched. I almost thought about renaming to you mean g-p-d? ;) > metacity.private, but it's ugly, and I thought this discussion had died > out with no much concern. At the time I received this email, I had > already uploaded the packages. I hope this will not cause much concern, > but I guess renaming the module or issuing a warning during import is > still a viable option. Nah, don't worry about the renaming or giving a warning. As you've pointed out, this really is not different for you than how you've had to deal with wnck in the past; since you're fine with that, I don't see any problems. Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: > On 1/20/06, Johan Dahlin <[EMAIL PROTECTED]> wrote: > > > Well, no library in the desktop can be relied upon to remain API or > > > ABI stable; that's the reason they are in the desktop. The difference > > > with this lib, _if_ I remember correctly, is that those other libs in > > > the desktop were meant to be used by whoever wanted to use them, > > > whereas libmetacity-private was expected to not be used by anything > > > other than control-center (with the implication that if we make any > > > changes that breaks anything other than the control center, we just > > > don't care and won't consider it a bug). > > > > Is it not similar to wnck, which mostly the panel uses? > > Similar, but not the same. Havoc intended libwnck to be used by other > apps besides just the panel. And other apps do use it. From the > README: > > "libwnck isn't supported in the devel platform, which means OS vendors won't > guarantee the API/ABI long-term, but authors of open source apps > should feel free to use libwnck as users can always recompile against > a new version. (And the API/ABI has historically changed very little, > I'm not changing it gratuitously or without soname increments.)" > > While libwnck doesn't have API/ABI requirements from the release set > it is in, we agreed a release cycle or two back to not break API/ABI > after feature freeze. Also, when making API/ABI changes that breaks > something, or adding API to libwnck that certain modules need to use, > I make a best effort (which is sometimes lacking, in particular I just > realized I've always forgotten to notify the bindings people -- which > is perhaps why you see it as no different) to at least notify apps > that I know are affected and often also provide patches. > > I wouldn't bother notifying anyone if I broke ABI of > libmetacity-private (other than control-center), even if it was during > a micro point release during the stable cycle. This already happened once with wnck, with nasty results: http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html But we understand the limitations of API guarantees and live with it. > > However... > > > To me the name metacity-private is just another way of saying > > it's an unstable library and don't complain to us if we break your > > application. > > If you're fine with that, feel free to go ahead. :) I do have to say > that it does sound like a very cool use you have for > libmetacity-private. And, you're probably unlikely to get any > breakage since no one (least of all me) seems to be interested in > working on anything theme related in Metacity right now. It's just > that we're not going to make any guarantees. So I've finally released the split g-p-e/g-p-d packages, leaving metacity in g-p-e and untouched. I almost thought about renaming to metacity.private, but it's ugly, and I thought this discussion had died out with no much concern. At the time I received this email, I had already uploaded the packages. I hope this will not cause much concern, but I guess renaming the module or issuing a warning during import is still a viable option. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 08:18 -0500, David Zeuthen wrote: > > Yes.. someone needs to code up the support I rambled about > plus add it to g-p-m (and make sure the g-p-m maintainer > agrees so to :-). Right now it's just ideas to support various > not-so-interesting-but-still-important scenarios. For non-corner > cases I think g-p-m is doing pretty well and we can all thank > Richard for that. Thanks David. I think your DBUS API suggested could be used by a whole lot more than g-p-m, but g-v-m, and other session stuff too. As soon as the design has fleshed out, I'm all for adding code to g-p-m to support this extended mode of operation. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Request to update .cvsignore files
On Fri, 2006-01-20 at 14:26 +0100, Luca Ferretti wrote: > Do you think I can update .cvsignore files on same (hopefully most) > modules for Desktop and Developer Platform without asking permission to > maintainers and/or opening relevant bugs on bugzilla? For me, adding stuff is no problem. I would probably want a bug (or an email) for removing stuff tho. I guess that would be the consensus of most maintainers. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/20/06, Johan Dahlin <[EMAIL PROTECTED]> wrote: > > Well, no library in the desktop can be relied upon to remain API or > > ABI stable; that's the reason they are in the desktop. The difference > > with this lib, _if_ I remember correctly, is that those other libs in > > the desktop were meant to be used by whoever wanted to use them, > > whereas libmetacity-private was expected to not be used by anything > > other than control-center (with the implication that if we make any > > changes that breaks anything other than the control center, we just > > don't care and won't consider it a bug). > > Is it not similar to wnck, which mostly the panel uses? Similar, but not the same. Havoc intended libwnck to be used by other apps besides just the panel. And other apps do use it. From the README: "libwnck isn't supported in the devel platform, which means OS vendors won't guarantee the API/ABI long-term, but authors of open source apps should feel free to use libwnck as users can always recompile against a new version. (And the API/ABI has historically changed very little, I'm not changing it gratuitously or without soname increments.)" While libwnck doesn't have API/ABI requirements from the release set it is in, we agreed a release cycle or two back to not break API/ABI after feature freeze. Also, when making API/ABI changes that breaks something, or adding API to libwnck that certain modules need to use, I make a best effort (which is sometimes lacking, in particular I just realized I've always forgotten to notify the bindings people -- which is perhaps why you see it as no different) to at least notify apps that I know are affected and often also provide patches. I wouldn't bother notifying anyone if I broke ABI of libmetacity-private (other than control-center), even if it was during a micro point release during the stable cycle. However... > To me the name metacity-private is just another way of saying > it's an unstable library and don't complain to us if we break your > application. If you're fine with that, feel free to go ahead. :) I do have to say that it does sound like a very cool use you have for libmetacity-private. And, you're probably unlikely to get any breakage since no one (least of all me) seems to be interested in working on anything theme related in Metacity right now. It's just that we're not going to make any guarantees. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
> Without any of this, people will just switch back to totem-xine or > other, non-GNOME apps like always, or just continue self-confirming that > Linux sucks. Very disappointing after my hard work to make GStreamer not > totally suck from an end user's point of view. Basically a total year > wasted. The is factually wrong Ronald, a lot/most of the great fixes you did last year are already in 0.10 and of those that are not still in it makes it much easier for us to fix similar issues in 0.10 when we can look at how you fixed them in 0.8. I know that Tim whenever he finds an issues verifies with 0.8 to see if it works there and then checks what fix was done there to see how to apply it to 0.10. I know this wasn't the solution you wanted, but please don't let it depress you into feeling the work you did is wasted, it is not, not even close. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 13:28 +, Alan Cox wrote: > Its a common server case where physical access does not meet > authorisation to do much. Tape drives tend to be near the physical > system and people want to provide facilities to the tape folk (browser > forms to indicate they actually visited the box etc). Neverthless the > typical tape loader is paid like a 1st level phone support person, and > is not usually qualified or sometimes even competent to be offered the > ability to shut down the system they are backing up. Right. HAL does need an easy way for sysadmins and the like to lock down [1] and g-p-m instances should cope with Suspend() etc. failing. This is also relevant for e.g. storage (e.g. RH #177177) and we're working on that for the HAL 0.5.7 release out in a few weeks. Yes, it's important to fix for the corner cases you mention. David [1] : Ideally, GNOME biased distros will use a HAL callout to read default/mandatory settings from gconf and populate HAL settings (HAL cannot depend on gconf for obvious reasons) so this is still configurable from the UI within GNOME. But now I digress. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Well, no library in the desktop can be relied upon to remain API or ABI stable; that's the reason they are in the desktop. The difference with this lib, _if_ I remember correctly, is that those other libs in the desktop were meant to be used by whoever wanted to use them, whereas libmetacity-private was expected to not be used by anything other than control-center (with the implication that if we make any changes that breaks anything other than the control center, we just don't care and won't consider it a bug). Is it not similar to wnck, which mostly the panel uses? It's fine to break applications and bindings, as long as they're aware of it. The only difference between control-center and say gazpacho is that control-center is included in the desktop while gazpacho isn't. To me the name metacity-private is just another way of saying it's an unstable library and don't complain to us if we break your application. Of course, Elijah would have a better idea of this. Perhaps the solution is to create a libmetacity that use functions people may need to use, and a libmetacity-private to do whatever it is doing now. Actually, it'd be Havoc who'd probably need to comment here, as I'm not certain I'm recalling correctly, I've never touched that lib, and he'd need to be the one to say whether he's willing to support wider use of it. There are already other applications using it, eg monodevelop. Of course, both gazpacho and monodevelop would prefer a window manager neutral way of drawing borders. Perhaps something for a future revision of the ewmh specs. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Request to update .cvsignore files
On Fri, 2006-01-20 at 14:26 +0100, Luca Ferretti wrote: > Do you think I can update .cvsignore files on same (hopefully most) > modules for Desktop and Developer Platform without asking permission to > maintainers and/or opening relevant bugs on bugzilla? Fine by me. I don't see any reasons why they shouldn't. You might want to ask before removing generated files from CVS though, if that problem happens. --- Bastien Nocera <[EMAIL PROTECTED]> To be fair, where do you go after Spacecamp? -- Joaquin Phoenix ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Gwe, 2006-01-20 at 08:18 -0500, David Zeuthen wrote: > console. Only one copy obtains the right to manage the > system power, this happens through the PolicyManager as > described here http://blog.fubar.dk/?p=63 ... e.g. the call > ClaimPolicyService() will return FALSE for everyone but > the first one to ask. Or for all in many environments > > Or consider a > > tape monkey in the server room. > > It's busy attempting to write Shakespeare on a good old > fashioned type writer? :-) ... no, seriously, care to clarify? Its a common server case where physical access does not meet authorisation to do much. Tape drives tend to be near the physical system and people want to provide facilities to the tape folk (browser forms to indicate they actually visited the box etc). Neverthless the typical tape loader is paid like a 1st level phone support person, and is not usually qualified or sometimes even competent to be offered the ability to shut down the system they are backing up. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Request to update .cvsignore files
Do you think I can update .cvsignore files on same (hopefully most) modules for Desktop and Developer Platform without asking permission to maintainers and/or opening relevant bugs on bugzilla? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Jan 20, 2006, at 7:43 AM, Alan Cox wrote: On Gwe, 2006-01-20 at 09:05 +, Matthew Garrett wrote: currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. I don't think hal's the right layer to make that distinction. I'm working on implementing it at the dbus level. I question the existance of such a distinction. Take an HP box with four monitor heads and four keyboards. Who is "in control". In this case you'd have four copies of g-p-m, one for each console. Only one copy obtains the right to manage the system power, this happens through the PolicyManager as described here http://blog.fubar.dk/?p=63 ... e.g. the call ClaimPolicyService() will return FALSE for everyone but the first one to ask. Thus, It is up to g-p-m to ensure that only the copy with the right to manage system power actually does - this does include the losing copies to somehow communicate to the winning copy that their display is idle and they're ready to suspend caused by inactivity. The winning copy will thus invoke the suspend, due to inactivity, if and only if all sessions have said they are inactive. How g-p-m does this is up to g-p-m.. I don't see the need to provide a framework for things like this.. All copies of g-p-m will still manage devices specific to the console, e.g. the display via DPMS on X. This probably also includes devices we know are specific to consoles (say, a subtree of all USB devices.. we can do this) but right now there's no good answer on run-time power management on Linux at least so it's not something that HAL or g-p-m currently does. It's definitely something we can and will do in the future. Waiting on kernel people. Yes.. someone needs to code up the support I rambled about plus add it to g-p-m (and make sure the g-p-m maintainer agrees so to :-). Right now it's just ideas to support various not-so-interesting-but-still-important scenarios. For non-corner cases I think g-p-m is doing pretty well and we can all thank Richard for that. Or consider a tape monkey in the server room. It's busy attempting to write Shakespeare on a good old fashioned type writer? :-) ... no, seriously, care to clarify? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Gwe, 2006-01-20 at 09:05 +, Matthew Garrett wrote: > > currently has no mechanism for making a distinction between background > > users and the user that currently 'controls' the machine. > > I don't think hal's the right layer to make that distinction. I'm > working on implementing it at the dbus level. I question the existance of such a distinction. Take an HP box with four monitor heads and four keyboards. Who is "in control". Or consider a tape monkey in the server room. Sometimes it is clear and useful - many desktops, most laptops but not something you can implement blindly. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: strange linker error
On Tue, 2006-01-17 at 12:48 +0100, Stanislav Brabec wrote: > > I'm completely at a loss as to how to fix this. It seems PHP and Qmail have > > previously had problems like this, but I couldn't work out what they did to > > fix > > it. > > I don't know F77, but if it was C, I will try to "#include " > and maybe search and delete custom definition of errno, which does not > work. Thanks, this was exactly on the right track. It seems some 'extern int errno's had found their way into our Fortran<->C bindings (along with several other externs for some unknown reason. Removing them and replacing them with correct header usage has allowed the library to compile. It is interesting that this only fails in certain circumstances, it doesn't break a .o or linking against a .a but it does break a .so. I will have to experiment on other platforms. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 09:11 +, Matthew Garrett wrote: > I think crippling functionality because Hal hasn't been ported to some > OSs yet is unreasonable. The alternative would be to provide a myriad of > small daemons that need to be individually ported, and that time could > be better spent on providing hal and giving us some consistency between > hardware access on different platforms. I'm not talking about crippling functionality; or saying that people can't use it. I'm saying let's not commit to it in Desktop at this point. Is there absolutely any reason it *must* be in Desktop? Should we include NetworkManager is Desktop also? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, Jan 20, 2006 at 09:39:12AM +0800, Davyd Madeley wrote: > Quoting Elijah Newren <[EMAIL PROTECTED]>: > >It looks like the vendors have already jumped on and chosen g-p-m. > > Once again, I ask the question, what about our non-Linux vendors? I think crippling functionality because Hal hasn't been ported to some OSs yet is unreasonable. The alternative would be to provide a myriad of small daemons that need to be individually ported, and that time could be better spent on providing hal and giving us some consistency between hardware access on different platforms. -- Matthew Garrett | [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, Jan 18, 2006 at 10:58:07AM -0500, Ryan Lortie wrote: > This is exactly the problem. In order for g-p-m to do its stuff we have > to add to HAL the ability for any user to say "suspend the system > now" (since g-p-m needs to do this and it's just running as a normal > user). If any user can say "suspend now" then I can be logged in as a > background user and play nasty tricks on the console user. HAL > currently has no mechanism for making a distinction between background > users and the user that currently 'controls' the machine. I don't think hal's the right layer to make that distinction. I'm working on implementing it at the dbus level. This isn't something that's limited to power management, so hal is going to end up needing this functionality even if g-p-m turned into a system daemon. I'd argue that one well-audited mechanism for hal to execute privileged code is preferable to half a dozen small system daemons running as root and managing to duplicate each others bugs. -- Matthew Garrett | [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Quoting Kjartan Maraas <[EMAIL PROTECTED]>: As for "creating another ESD" I don't know what all the fuss is about. I think the problems caused by us using ESD are greatly exaggerated, both in techical terms and wrt maintainability. The package has needed close to zero work the last few years and I don't see a lot of people complaining about it in bugzilla at least. What they do in the various forums is a different issue, but some people will disagree no matter what choices we make. The point I was trying to make is that we would have been better off without any sort of hard dependance on ESD. Of course, at the time GStreamer was not available to us, but my point was more that soft dependence allows us to be more modular with what vendors want to do. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
fre, 20,.01.2006 kl. 09.39 +0800, skrev Davyd Madeley: > Quoting Elijah Newren <[EMAIL PROTECTED]>: > > > On 1/18/06, Davyd Madeley <[EMAIL PROTECTED]> wrote: > > > >> I'm with Ryan on this. I think we should give vendors a choice for > >> the time being. > > > > It looks like the vendors have already jumped on and chosen g-p-m. > > Once again, I ask the question, what about our non-Linux vendors? > Status quo? Or they can start working on creating the same kind of interfaces that g-p-m or the mythical PowerManager can use on the platforms where HAL doesn't work? Having "it must work on all platforms" as a criteria for inclusion is not going to work when we're talking about stuff that is this close to the hardware IMO. At least not in the near future. As for "creating another ESD" I don't know what all the fuss is about. I think the problems caused by us using ESD are greatly exaggerated, both in techical terms and wrt maintainability. The package has needed close to zero work the last few years and I don't see a lot of people complaining about it in bugzilla at least. What they do in the various forums is a different issue, but some people will disagree no matter what choices we make. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Quoting Stanislav Brabec <[EMAIL PROTECTED]>: > This happens with a lot of applications, is this a bug or a feature? If I understand correctly, that would be a feature Yes. This bug is a feature. For example if you want to open application and then use DnD, or if you want to open web link using DnD, you will end by searching a file of the same type on the disc to be able to open the application. It's my opinion that viewing apps should still appear in the Applications menu. I may want to open my application and then open a file from the Recent Files list in that application, or select some specific function (eg. Play Disc). Perhaps I have been asked by a member of the support staff what version of Evince I am running, or as previously pointed out, I want to drag and drop an element (that is not a file in Nautilus) into the window to somehow open it (eg. this is the coolest way to open things in the screenshot app without having to save them outside a tempfile). Additionally, I feel it is by far the best metric to determine if you have a particular application installed without the user having to know squat about the package management system. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GFDL/GPL problems
Hi, I've just been readong the thread started by Jordi on GFDL and GPL, and issues that Debian currently has with GFDL. Excuse me for starting a new thread on the issue. Leaving aside whether GFDL sucks or not, there are serious problems with using the GPL for docs, primarily because what "source code" means is unclear. Requirements on the distribution of source code in the GPL become particularly cumbersome in the context of printing a book. The GFDL was written because of problems with the GPL as a documentation licence. Proposing a block relicencing ignores those problems. The approach of Jordi, that is asking authors to dual-licence their docs, seems sane to me. But switching to GPL-only would be a mistake. Cheers, Dave. -- Dave Neary Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
