Re: MWG composite functions gexiv2
Apologies. Let's try without attachments! As a picture is worth a thousand words, I built a mockup based on the GIMP metadata editor. The Exif tab has been left alone as a lot of that data comes straight from the camera. The XMP and IPTC tabs have been merged and separated into tabs called: Who, What, Where, When according to Metadata Working Group guidelines. Under the hood, gexiv2 composite functions would be used to read and write to the correct metadata fields. Results can be seen on the following links: http://www.vcn.bc.ca/~apater/01who.png http://www.vcn.bc.ca/~apater/02what.png http://www.vcn.bc.ca/~apater/03where.png http://www.vcn.bc.ca/~apater/04when.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MWG composite functions gexiv2
On Fri, Mar 20, 2015 at 12:41 AM, Alan Pater alan.pa...@gmail.com wrote: I have been talking with Jim Nelson about adding composite functions to gexiv2. These would be based on Metadata Working Group guidelines with the addition of a couple of commonly-requested formats. https://bugzilla.gnome.org/show_bug.cgi?id=712429 Here is a link to the MWG Guidelines: http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf In the hope of finding a real developer to help with this, I have put together a quick list of bugs from various projects that, I think, would benefit from this work. Specifically what I need help with are writing a few conversion functions, for example from xml to a separated string. Any volunteers? // GIMP bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=gimp Bug 118202 - [TRACKING BUG] Metadata improvements Bug 61499 - easy way to view/edit image metadata (author, copyright, image title, etc.) Bug 727270 - Proposal to add gimp_metadata_set_from_iptc Bug 349224 - Creative Commons licenses integration // Shotwell bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=shotwell Bug 718518 - Move EXIF date handling logic into gexiv2 Bug 717172 - view/edit all photo metadata Bug 719173 - Read face 'tags' from Samsung Galaxy S3 mobile photos Bug 717713 - Shotwell fails to split a comma separated keyword list during import from XMP-dc:Subject Bug 718107 - Xmp.dc.description or Iptc.Application2.Caption is not imported with accented characters Bug 731255 - Inconsistency in reporting date after editing it. Bug 735069 - Shotwell overwrites time stamps in metadata when those are changed outside shotwell // gexiv2 bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=gexiv2 Bug 712463 - Some date formats in the wild do not conform to EXIF standard. Bug 737495 - Add support for Exif.GPSInfo.GPSTimeStamp / Rational [3] Bug 723794 - Unsupported time format error when loading image w/ Darwin Core metadata Bug 712431 - Add milliseconds to get_date_time() in GExiv2.py Bug 712430 - GDateTime accessor // eog bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=eog Bug 515265 - use exiv2 as metadata source Bug 719621 - Rotating image destroys XMP and IPTC metadata Bug 341653 - Add support for IPTC-NAA Bug 699297 - Image Properties should prominently show Title and Comments // Nautilus bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=nautilus Bug 729685 - edit, metadata, music, photos. // sushi bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=sushi Bug 730391 - EXIF orientation information incorrectly interpreted for CR2 (Canon RAW) files // gthumb bugs https://bugzilla.gnome.org/page.cgi?id=browse.htmlproduct=gthumb 28 bugs found Bug 669026 - Changing metadata does not change file modification time Bug 456699 - Geotagging on GThumb Bug 417824 - Sorting images by Comment Date Bug 621478 - Changing EXIF date corrupts the JPEG thumbnail ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
It's a series of chipsets involved
GMA500 ('Poulsbo')
GMA600 ('Oaktrail')
GMA3600 ('Cedartrail')
GMA3650 ('Cedartrail')
E6xx ('Tunnel Creek')
The unaccelerated driver is quite happy with 2D desktops but LLVMpipe and
the paths used by the Gnome bling and compositing seem to hit it a lot
harder.
That probably points to it being at least partly solvable by de-blinging
the Gnome3 desktop or optimising/changing how it renders. E for example
has multiple rendering back ends.
Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
How could GNOME encourage decent drivers? Have the GNOME foundation ask the company? Go via Linux Foundation? Maybe some kind of request? Would throwing money at it help (how much?)? I am not that sure. The business and politics of graphics controllers is a good deal bigger and more complicated than Gnome. I'm hoping Valve/Steam has an impact. There are obvious things like buying hardware that is properly supported, and filing bug reports. However I think most people who care enough are already doing that. In addition telling people what hardware is known to work with free drivers and is good is always going to be helpful. Especially as much of the hardware which will do the job is very cheap anyway. On laptops and tablets however you tend to be stuck with buying the right device. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
On Thu, 22 Nov 2012 05:47:30 -0500 Jasper St. Pierre jstpie...@mecheye.net wrote: The hardware accelerated graphics API that the rest of the world has depended upon is OpenGL, minus Direct3D for obvious reasons. It's unfortunate, but if OpenGL isn't supported on these devices, a hardware accelerated desktop isn't going to be possible. I don't think it's worth it to write hardware acceleration code because the driver maintainers couldn't give us the API that everybody else has. LLVMpipe gives you that API The issue should be fixed at the driver level, not at the GNOME level. You can't fix it at the driver level or that easily at the Gl level. The problem you have is that Gl type rendering doesn't allow the stack sufficient ability to identify optimisations for what is basically for the most part 2D abuse of the 3D API. In addition it is more CPU intensive to do Gl emulation which in todays world means that it costs power and thus battery life. Hence you need to do it higher up the stack where you have the information needed. E does this and that is why E is very fast on just about any hardware. You also need to be aware of much of this higher up anyway even in the OpenGL world because you need to adjust your options and effects based on the timing and performance currently being received do that you can for example dynamically drop out some of the effects on a box under load, or perhaps on a low clock in battery mode. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
GNOME shell should work on any graphics card 5 years or older. We should have good data backing this up as I know that Fedora has done QA on a number of hardware to test gnome-shell in order to know what hardware profiles shell will work on. Its passably usable (lot of laggy movement) on a dirt cheap ATI 54x0 driving three monitors with 1080p. With a single monitor configuration I'm sure it would be fine. Ditto with single/dual on most intel setups. Equally its near unusable on a brand new netbook which has Imagination graphics and a relatively low end CPU. LLVMpipe only seems to really be usable if you have a decent processor and a lot of memory bandwidth to the video Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
On Wed, 21 Nov 2012 21:50:37 +0100 Raphaël Jacquot sxp...@sxpert.org wrote: On 21 nov. 2012, at 21:31, Alberto Ruiz ar...@gnome.org wrote: A classic mode for GNOME Shell could make use of less expensive effects that could relieve the software rendenrer making the experience a lot nicer on machines with driver problems (or other cases where native GL could not be provided). sounds like a rather good option, how about asking on firstboot, when detecting hardware that could be rather slow, an option to cut all the nice bling, so as to save cpu/gpu cycles... That ought to be happening automatically based upon timing the effects and also on things like battery life. 3D compositing is a video memory hog and that has material power impact. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeGoal for 3.8: DesktopFileKeywords
On Thu, 15 Nov 2012 18:26:22 + Maciej Piechotka uzytkown...@gmail.com wrote: On Thu, 2012-11-15 at 16:48 +0100, Henrique Ferreiro wrote: Not sure matching in other languages, including english, is a good idea. The typical $locale user is searching for a word in his language, likely having no clue that english has a similar That very phrase shows some ignorance of language use in much of the world his language which one. Lots of people here have two and they'll switch language by task. In addition they have 3rd party docs in broken English stuff (American for example). It's not untypical therefore for people to have a desktop behaviour which has things like computing in English, cultural material in their local language and religious material in Arabic. You really want a language list or to search the base language and do a search engine style search for matches in other languages or there are similar entries in Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preserved Window Placement
On Fri, 26 Oct 2012 10:39:56 -0400 Havoc Pennington h...@pobox.com wrote: The XSMP spec is more or less impossible to make sense out of. But to the extent people have tried, it has not been a useful undertaking. If someone took XSMP round the back and shot it while adding support for a better session restore protocol to the main toolkits I wouldn't exactly be bursting into tears ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preserved Window Placement
I started this discussion because I'm getting really frustrated with the lack of window state preservation on Linux. I understand that this involves a lot of different pieces of software. I am talking about the desired end result. I probably do not have a complete understanding of the various individual actors involved in creating the experience. Ok there are basically three players - The application, which needs to know what to put in each window if you restart/resume it and needs to tell others how to give it that information back when a restart occurs - The session manager which needs to store all this information away somewhere, and also use it as necessary to restore session state - The window manager which makes the actual sizing and placement happen and in some cases the window and session manager happen to be implemented as the same application. capabilities excludes providing the option of preserved window placement. Obviously for now this is simply not a priority for X. I X has supported this since the 1990s maybe earlier. The fact Gnome doesn't do it by default is a Gnome decision. In some respects asking whether it is a priority for X is a bit meaningless. X provides the mechanism, it's up to the desktops how they choose to use it and if they consider it a priority or not. It is apparently not a priority for Gnome. Likewise the traditional use of it is to save state on close, restore it on restart of the desktop. There is nothing that requires a desktop does it (so Gnome is not 'wrong' or 'non-compliant') and there is nothing saying you can't save the session state of an application and use that whenever the app is re-opened from fresh rather than just to keep the desktop state over a restart. You could for example imagine a bar where when you close an application its icon is added to a list of restorable states that sat somewhere (a sort of 'recently used' of desktop state). X and the session management protocol just define how the information flows. guess I was thinking preserved window placement would be something handled by metacity or mutter or something that is under the domain of Gnome. Hence, discussing it here. Gnome has the opportunity to use the data as it sees fit. The MacOS approach assumes applications are constrained to a particular narrow set of behaviours, local and to some extent written with one set of tools. Right, but there are already some standard elements between Gnome/GTK and KDE applications, right? Should I be talking to the Freedesktop.org people? The X session management protocol which handles this is even more abstracted. Qt implements it, Gtk implements it but so do many other toolkits including those on non Unix operating systems. That's not to say the X approach couldn't do with improvement, but that its solving a whole different and vastly larger problem space. Please point me in the direction of the people I should be discussing this with. At the moment I'm refusing to give up on using Linux (or whatever word we can use to refer to the collective of desktop environments that share the same or similar resources). If I can help improve this little detail, I will. But it might be out of my scope. I would say there are three sets of people X11.org - for the actual protocol itself which is shared across all the environments Gtk/Qt/etc for toolkit level support changes Gnome for how Gnome chooses to implement and use features of the session management. and (as with anything else) sometimes specific app vendors because their app has bugs Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preserved Window Placement
order they were in. Most applications seem to remember whether or not they were maximized previously. But all of these features are part of the individual programs (and extensions in Firefox's case). It's supposed to be a property of the X session management, including automatically restarting applications that were running before (which Gnome doesn't bother to do). This is usually managed by a mix of the toolkit and the X window manager (with a little necessary help from the app). It seems to me that the position and dimensions of a window in the context of a user's desktop (assuming that the dimensions of the desktop itself don't change, but even Apple hasn't solved that challenge last I checked) could be boiled down to 4 numbers saved as the application is closed (width, height, x, y [from top-left corner possibly]). You missed a couple of properties but basically yes. However you need to know what the contents were for a correct restart too. Consider restarting an image viewer app with 3 windows open , you need to know which one goes where and what image was in it to restore it correctly. This is why the application has to be involved. I would think simply preserving the specific absolute position of the windows of the various applications a user regularly employs would be much easier than calculating a dynamic position on the fly every time a new application is launched. Some window managers can do this. It's not always as useful as you might think IMHO. For certain uses (eg Kiosks) its of course essential ! It's just weird that KDE, Gnome and every other Linux desktop doesn't seem to even be discussing this topic. Gnome is obsessive about making everything work to its specific diktat without configurability. If you look at configurable window managers you'll find all this exists and far far more. Things like window managers for tiny screens that open apps full screen and flip between them are decades old, window managers that tile apps without overlapping and so on. (its a pity for them that the Windows 8 metro people didn't take a good look at tiling window managers on touchscreens 8)) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some points about IM integration
On Wed, 16 May 2012 00:05:40 +0800 Justin Wong justin.w...@gmail.com wrote: Imagine, just imagine one day a desktop environment named the Kernel Desktop Environment (KDE), would be integrated to linux kernel for better user experience. We've got one .. it's called the console. It has an assorted set of problems with Chinese fonts, and no input method support. There is a difficult balance between integration and flexibility. DRI and X is a good example of how tricky that can be. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Text Cursor Movement Via Arrow Keys
On Thu, 5 Apr 2012 10:45:33 -0500 Jason Simanek jsima...@gmail.com wrote: Hi, I don't know if this is the place to discuss this, but I have a request concerning text cursor movement as it is controlled via the arrow keys on the keyboard. Currently on all Linux desktops that I am aware of the text cursor can be moved like this via the UP and DOWN arrow keys: up arrow move cursor to next text line up - if at top-most text line do nothing down arrow move cursor to next text line down - if at bottom-most text line do nothing This is the same way that Windows moves the text cursor. It isn't very efficient and forces the user to lay on the left or right arrow keys to get to the very beginning or the very end or the text block. Home and End keys plus all the above with shift for select, or with control for word skip or with shift-ctrl for most. Ditto for page up/down with shift. move cursor to next text line up - if at top-most text line, move cursor to beginning of text block/text input which prevents scrolling on apps where it makes sense to scroll up through material in the window, or to move down beyond the end. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: Securing maintainer uploads to master.gnome.org
In fact, I think the lack of fine grained ACLs for this sort of thing is one part of GNOME that work better than projects that try to lock things down more aggressively. Locking stuff down means reducing the attack surface (eg getting rid of shell accounts) and who can write stuff to trusted repositories. It doesn't mean contorting the release process. You just need to have the signing policy right. Giving everyone read access isn't a big deal, its write access that causes the problem - either to modify repositories or to put up fake releases. The latter can to a fair extent be handled by enforcing the upload be of a signed file with an appropriate signature for the destination. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: Securing maintainer uploads to master.gnome.org
If any of the 350+ has their machine compromised, someone could easily use that to reach shell on master.gnome.org. I don't want that to be possible. If you have 350+ users with hosts and some of them were shared wth kernel.org in the past I'd suggest When or Probably not If a. rsync might be annoying / unreliable b. don't think you can delete easily with rsync c. more annoying than e.g. sftp or scp Talk to H Peter Anvin about the new kernel.org tools, they may do what you need as well. h...@zytor.com. In particular it tries to be smart about signature handling. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v6)
AFAIK the goal was to only maintain it until the very last graphics chip in use was able to run shell. It's not there as a preference, it's a fallback mode for unsupported hardware. Plenty of people see it as a preference, but right now on the hardware side there are plenty of chipsets without 3D support or where it's not good enough for Gnome 3. As a starter in recent/currently available chipsets you can add - Some Intel gen chipsets with 2048 pixel wide displays - All the USB plug in displays - Imagination based hardware and I'm sure there are plenty more. They don't I suspect need fallback mode though, all of the examples I can think of that are current have very fast framebuffer access for pushing bits, usually host memory based (the USB one update is slower but not the draw rates). E/EVAS manages to do pretty much everything Gnome 3 non fallback does effectwise on such chipsets snappily (often faster than Gnome 3 feels on hardware 3D), so really it ought to be a case for the most part of fixing the broke dependancies of Gnome 3 on 3D hardware. You can do drop shadows, shading, scaling of a flat 2D image and the like very fast with the CPU. I do wonder if Gnome 3 had been based on the E canvas whether any of the problem would have occurred in the first place ? Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
Someone said, well, if it is my house, I should be able to chose, the reason that rationale doesn't work is because the GNOME Shell experience should be designed to be inclusive, so this is really closer to an office building or an apartment building instead of a private house. The flaw in your logic starts beyond the front door. Clearly the login process should be accessible, and the install and setup so that a user can always get their system set up. However at the point beyond login that ceases to be true. It's necessary that the accessibility starts available somewhere (or can be enabled accessibly in the login) but beyond that point the user should be able to disable it for their account. If someone needs accessibility to use my account then probably I've been hacked by someone disabled. Granted it could be I have become disabled but that hopefully doesn't happen to people suddenely very often. Sure it'll happen slowly by age to many of us. Also if you can force accessibility on as a login choice that is still ok. It seems to me you can meet both sets of requirements quite easily, and that an always accessible login with the ability to force a session to be accessible covers the corner cases too. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
You're assuming the install and the setup is done by a) the same person that is going to use the computer, which is not the case most of the time and b) that the person that uses the computer is always the same one. No. Not true, some seats have unique users (think of a university lab, or a multi seat setup in an office), some of these have a unique user for anybody that logins automatically And those environments already need to lock all the configuration down anyway or regenerate it each login otherwise someone will leave it in 320x200 pixel mode and in Korean because it's funny. setting in the universal access pane or just in GNOME Tweak Tool is something I leave up to the designers), but I don't think it should easily switched off, and by no means automatically switched off. It should be easy to do because the purpose of the desktop is to make things easy. I agree you don't want it off automatically because you need to be sure that a user can find the accessibility features if they do need them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v6)
There's been a lot of work done to improve GNOME 3 over the last 6 months. A lot of the complaints of GNOME 3.0 have been already addressed. Why not just do it after (even more!) distros ship GNOME 3.2? The first one is probably going to shed more light on what should be asked than anything else. So why not do it now ? It will also be a basis upon which you can compare a 2012 survey. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on extensions.gnome.org security
A) Make the plugin only tell the downloader what to download and not to download it from. You still need a key - even if the https:// authentication for gnome.org itself to prove the connection is to the correct site. B) Sign extension dowloads with a gnome.org private key. A) is considerably simpler. B) offers some more flexibility. (You can still handle offload in the A) case by doing redirects.) Another way to address B is to sign an index of locations of and hashes for the extensions rather than signing each extension individually. Might be easier to operate but with B you could use a heirarchy of keys (gnome-signer) which would let the installer see who (one or many) signed the package having reviewed it, and also allow revocations. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. Unlikely. Users like a way to get their system back into sane order. Another reason a software option to power off is useful - it cleans up any crap, leaks etc. In a perfect world it isn't needed, but in this particular one it is. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on extensions.gnome.org security
Of course, Linux users run unsandboxed code with arbitary capabilities every day - applications, for example. So the security question with GNOME Shell extensions is not how we can do the almost impossible job of sandboxing them, but how we can build up layers of social, user interface, and technical protections to make them not an attractive deployment mechanism for malware. I would say the question is both that and how you sandbox them to some extent in the same way as you sandbox apps with SELinux. That requires sensible architecture decisions about isolation. An extension that wants to look at my ssh keys for example is detectable as anomalous behaviour. - Don't have automatic deployment for extensions.gnome.org changes but make it a manual process. - Restrict the set of users who can commit to the extensions.gnome.org code module. - Sign 'approved' extensions with keys which are not kept on a public system. If all that the plugin can do is say install plugin GUID x-y-z, whch that then triggers a download from https://extensions.gnome.org and shows a dialog, then any exploits along this line should at least be detectable to moderately sophisticated users, who will hopefully then report them so they can be fixed. Are the existing mime type and helpers not sufficient ? However, this does not correspond to our overall goals for extensions: we want a very clear distinction between extensions and applications, we want extension installation to be under the control of the user and not the system builder, and we want to encourage a community of extension creation that doesn't involve an extra layer of distribution specific packaging. In which case you probably do also want a system wide ability to turn off users adding extensons, especially unsigned ones, for business environments. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
Gathering feedback does not necessarily require an online user survey. As stated, for a project which currently targets, among others, users who do not care what parts of their operating system can be labelled GNOME a survey is not a very reliable way of gathering feedback. Have you ever tried to explain, to a person who doesn't have an interest in software, what GNOME actually is? Yes - my MBA research was into Linux desktops some years ago and did involve looking at end users attitudes. The quick summary from then would be: Most users used the desktop they got by default (whether because they didn't know to to switch or were never annoyed enough to bother I didn't have time to find out) The managers wanted a system that was a free exact clone of windows look/feel because change was expensive (training, lost time etc) The technies in the organisation often inflicted their personal desktop preference on the entire company. If I wanted to look at the Gnome 3 is crap assertion I think I would tackle it a bit differently as so much online updating is going on nowdays. Collect statistics from a few Fedora and other mirror sites, correlate downloads together by IP/time and other evidence, and look at how many of them download which desktops or combination of desktops. Repeat this over time and plot graphs. Distro popularity shifts may also provide some evidence for this. The trouble is while that will tell you about movement and popularity it will not tell you why. So it's a way to evaluate the claim Gnome 3 is crap loads of people are changing or holding back on updating their desktop but it's not going to answer useful things. There is a bit of value in knowing if lots of people hate or love Gnome 3, but the real value is knowing how it could be better for users, and counting downloads won't do that. And if real non-technical end users are like the ones I dealt with then asking them probably won't help either. Particularly in the business world to many of them at the time Gnone was 'click on this splodge in the morning to write letters' 'click on that thing in the corner to turn it off'. They are not decision makers either - impress their boss 8) The more interested and technically motivated people on the other hand can tell you stuff, power users particularly. They tell you stuff that reflects a particular use and understanding case though. Similarly you can learn an enormous amount by seeing what people are struggling with and what they do to the desktop - eg the various 'how to fix Gnome 3' pages tell you a lot about what people wanted and which is non-obvious for configuration. They are also from people who liked it enough to persevere so made an effort. I urge you to consider the fact that if the majority of people subscribed to desktop-devel-list don't have faith in idea of an online user survey, an online user survey is probably not going to much have effect on the views of the people who contribute to the discussions on desktop-devel-list, and since most of the GNOME community read desktop-devel-list you can probably extend this to all of the other GNOME mailing lists and IRC channels as well. Some days I think Miguel got the Ximian monkey dead right, except that there should have been three of them. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
Any survey that isn't a carefully controlled randomly selected sample of users doesn't result in learning. It results in data that forms some You need truely or reasonably random samples for certain kinds of activities and analysis in particularly quantitative analysis when you want to perform p tests and the like. You don't need it in order to learn merely to generate statistical proofs and those are often quite useless anyway. Proviing gnome 3 is great/indifferent/sucks doesn't have much value. You do not need it for explorative learning. Small children do not need to open a statistically valid sample of randomly chosen doors to learn about doors ! I for one would not be surprised if a lot of responses were not more positive than some seem to think. There has been time for people to use it and adjust and apply the fixes. Even odder there is no Gnome fork. If as I hear 'Gnome 3 is hated by technical people' and there are enough who care there ought to be a Gnome fork by now. But what do we have - exde, dead, turned into a one page rant and no code Mate - described by phoronix as The Mate Desktop Environment fork of GNOME2 was started by an Arch Linux user back in June, but it hasn't yet gained too much traction and is mostly just talked about on various forums around the web. which about sums it up. sort of rorschach blot. Everyone will see what they want to see. Those who believe that Gnome 3 is a step back will point out that the majority of responses are negative. Those who believe it's a step forward will point out that happy users are going to be far less inclined to respond. You seem to be assuming the results and that the only question of interest is does gnome 3 suck. nothing, but we'd guarantee another huge set of arguments which would themselves also tell us nothing. Those will tell you a lot if someone analyses them. Again you may not be able to do formal mathematical tests on them but so what. If we want to find out what our users think then the only way to do that is to have professional involvement and a random sample set. Of course, and the only way to produce a kernel or desktop is to hire professionals to do it for you no doubt. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
On Fri, 19 Aug 2011 21:05:26 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Aug 19, 2011 at 10:53:46PM +0300, Felipe Contreras wrote: If you went back to 1991 and wanted a production-quality kernel within a year, Linux probably wouldn't be your starting point. There'd be a learning process involved with setting up a professional-quality survey team, and the first few attempts would be pretty buggy. We'd get there in time, but until then... Until then it's better to have nothing? It's better to have no data than to have misleading data. It's better to have no desktop than one that might not be production quality ? Same argument, same problem. PS data is never misleading. It's presentation maybe misleading but the data is just bits. I do think the comments on more open and why fill in the box type questions are on the button for the reasons expressed about sample size, randomness and what it would be useful to learn. Or perhaps rerun Federico's survey ? Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
I do not think you will be able to do very much with the answers to the questions you ask below. It's going to be a lot of work for data that is not useful. Let me try to explain. I thhink there is a better way to do this Felipe should do it without the Gnome oligarchy and then put the findings up on Linux Weekly News. That way we'll learn something, if not everything and it can no longer be stalled forever by bickering. And then well it's up to people if they listen, what they do with the data and how they follow it up. Sure the results will need reviewing with a little car - but thats true of any survey even one you paid through the nose for, in fact often more so because they more you pay the harder some of them will work to make sure you get the answers they think you want to hear 8) Plus the resulting debate may well answer even more questions than the survey ever did... Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
The answers are so vague that you are not going to be able to follow up on them. So they are unhappy with GNOME. Then what? Then at the very least you've got some picture of what is going on and you can try and trigger discussion about why people are unhappy (or indeed happy). Of course, maybe I'm wrong. Perhaps the average user of Linux/GNOME does know what GNOME is, knows how to contact the GNOME team and can tell you what version of GNOME they are using. And if they do, what is the survey There are going to be a large number of users whose viewpoint is essentially don't care, how you measure them is hard in pretty much any situation. A truely random sample of Gnome users will be hard to get by any approach. going to tell you? That they do or don't like GNOME? And how long they have been using GNOME? What are we going to do with that information? Use it to work out what questions it would be interesting to ask next year ? Look at what shows up in terms of additional comments. Look at the discussion around it, drop in the odd 'Why ?' question of your own. Use it to kickstart a secondary debate on the gnome site. (And btw while they won't read LWN people will link to it and discuss it in other places too) There is a second thing here too IMHO. The questions that could be asked and fixing them are currently buried in the debate. I can't see how progress will be made on picking questions usefully until someone moves from trying to achieve consensus to picking what they think is best based upon the resposes and just doing it regardless of whether each question is considered wrong by 5% of the people in the debate. Before any survey, you should know how you are going to use the information so that you can be sure to ask the right questions. So I could equally have said Why release Gnome 3.0, we know it isn't perfect and there are wrong things. Releasing it was better than stasis, it provided a learning experience that will make 3.2 much better I am sure. Doing nothing achieves nothing, doing something achieves learning. You may well not learn what you intended but you will learn something including quite possibly how to do future surveys better. I'm not saying its necessarily a great approach but it's vastly superior to people sitting around picking holes in the idea until it never happens. Right now this seems to be in blocking mode, and blocking a volunteer off to do stuff and see what happens be it code or otherwise is usually the wrong thing to do. Sure -t here is a good case for not describing it in any way that suggests its GNOME foundation endorsed or driven. Gnome grew from a comically clueless 0.1 tarball, surveys can do likewise. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
On Fri, 19 Aug 2011 01:20:53 +0300 Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Nothing is ever perfect, but having at least some results is better than nothing. Since you have repeated this assertion a few times, I must ask: What if the results are all wrong and we don't have any way of knowing that? Would those results still be better than nothing in your opinion? In that hypothetical case possibly not. But that isn't really likely to be the case even with a bad survey, especially if you start looking at how people used the open comments and asking why questions, or looking at the debate it triggers. You can learn things even by asserting a position and seeing the responses you get. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
What are you actually trying to understand ? If there are tradeoffs (and consensus that the tradeoff is real) then you can ask questions where you rate relative importance of features in various combinations It's often used to weight things like price/screensize, screensize/battery life, battery life/weight and so on. Is there a reason it can't be used to ask about ease of configuration/flexibility, flexibility/reliability, etc I agree asking are there enough options isn't useful but you could ask If you could configure three extra things what would they be and leave a text box. If most people leave it blank it tells you a lot, if everyone lists a thing you can do it tells you about doc problems, if there is a consensus on some things then it tells you other stuff. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v2)
It doesn't tell you much about the environment Are you using it on Desktop Laptop Netbook Tablet and perhaps a question about skill levels/years of computing experience. That might help understand which user categories want changes. Eg it's assumed that most of the 'customise it' requests are from experienced users but I don't think anyone has actualyl analysed that to find out ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ctr-del to delete a file
On Thu, 19 May 2011 17:07:57 +0200 Xavier Claessens xclae...@gmail.com wrote: Hello ddl, Looks like it is time to start flames on ddl, so let's start a new one: W-T-F is that ctr-del to move a file to trash in nautilus?? To encourage your fingers to hit the nearby alt key at the same moment ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome 3
The correct use case for any electronic device is power on when using it, power off when not. I couldn't agree any more. The default behaviour should be shut-down/restart. In the suspend case there are very good reasons for not wanting the user to think they have powered off and get a nasty surprise like overheating but in the hibernate case the device *is* off. The system state is committed to disk and the power is killed. Using suspend when a laptop is being moved also violates many companies security policies because it's rather too easy to extract data from such a system. If it's stolen when using hibernate + encryption it is pretty safe. So you don't want to muddle suspend and hibernate + poweroff. This will be awesome if can have this behaviour. When starting the computer user can select between 'resume' and 'new session'. Can we not write the session data to the disk and access it on next boot? It's called hibernate. Most electronica comes back on in roughly the state you turned it off. You want a real power off as well to recover from nasty situations but that is discard the hibernate session The other big nasty to beware of though is removable media. A hibernated system has not necessarily left removable media in a state they are unmounted. That is going to be an expectation the desktop needs to properly manage. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SoC idea: desktop file cache
mmap MAP_SHARED also makes dealing with external updating really interesting because if the file shrinks you need to handle signal exceptions from touching pages that no longer exist. Not if the cache is replaced with rename(), no? If the sequence is build new cache rename unlink old cache then the existing users will continue to see the old file which will only vanish completely on the last close. You can use fstat and the like to check the size for the mmap to avoid racing the rename on guessing sizes etc. It's only if the file is truncated the fun with SIGBUS occurs, or on an unrecoverable read error (eg NFS timeout on soft mount, physical bad block). In those cases unlike read() there is no other reporting mechanism. sigsetjmp/longjmp are normally evil but this may be one case they are needed to build a sort of mock exception handler given C's lack of a proper mechanism. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
Guys, for a sake of a sanity. I've been around gnome since pre 2.0 times. And all times up to now we supposed that OSS is about democratic process, where programmers are not told buy big enterprise News to me, and flagship projects like the Linux kernel run on the Linus is boss model. The freedom is more fundamental than that. Democracy and similar systems are a workaround for the fact in the physical world I can't do cp -r ourcountry mycountry mv ourcountry/me mycountry/me and continue In Free Software you can, so if a bunch of people don't like the current direction of Gnome they can get involved and change it from within, or they can take a copy with them and work in parallel, either for bits of or for all of the desktop. Freedom to make the decision doesn't extend to freedom to make other people do the work for you or listen to you and this does lead to new branches and ideas being tried out - sometimes becoming the norm (eg the egcs rebellion against gcc process became gcc 3) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
What about the freedom to choose? At the point where you disallow users to You can choose. The FSF freedoms are sufficient for that You can choose to run the old code You can choose to modify the old code You can choose to share modifications to the old code It's completely within your power to fork GNOME if you wish and to create a new alternative configurable desktop or to run a modified Gnome that includes the choices you want. It's in your power to share those mods, to work with others of like mind and to create a whole new desktop from it should you wish. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Minimum system requirements for GNOME Shell
lot. I've also seen lots of people running virtualized GNOME desktops as VMs under Windows in production. It's used Linux on Linux as well. In particular if your desktop is a guest you can take it with you on your laptop then put it on a box with a bit more welly when not travelling. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
It would be like releasing a new car and then telling the buyer that the tires that are included aren't good enough but that's okay because they are free to go through the trouble of replacing them right after they take ownership. Modularity is not a feature; a good feature is a feature. You wouldn't be a very good car salesman then would you ? In fact people loathe and hate the lock-ins wired into cars. Plus of course the first thing anyone does when they get into a car is umm Adjust the mirros Adjust the seats Adjust the music Adjust the airconditioning Adjust the satnav Fit random personal objects (modularity) ... I'd like to use a random bluetooth hands free, sorry our car is only available with our official hands free option radio, ours only satnav, ours only engine management, ours only, DRM protected and we sued the other guys I need snow tyres, sorry we don't support snow tyres, you don't need them. I added go faster stripes You've voided the warranty The car market is such a mind-numbingly bad example, in fact it's the very market whose abuse led the european union to pass legislation to limit the power of no reverse engineering clauses, that later proved such a good situation for software ! If a user has to do a bunch of customization after installing to get a tolerable desktop experience, we have failed at design. If the user can't then customise it to get a nice desktop experience to suit their needs after that you've also failed. That of course cuts both ways - it can have so much stuff you can't configure it. The distros gather hardware info with permission from plenty of users so they ought to be able to answer what percentage of our users can run this stuff. Not sure if they have enough data to do what portion of our users desktops can be seamlessly migrated - ie all the equivalents for each applet exist and the settings can be mapped ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
That's not realistic. Distributions won't allow people to choose between GNOME 2 and 3, which means people will be forced to stick to releases That depends on the distribution providing they can be parallel installed, and on what the volunteers involved or staff paid to work on them want to do. After the KDE4.0 debacle I suspect some of those who still ship it are not going to be too keen to jump to GNOME 3 by default before everything is ready and supporting it. It's OK if we lose a few weird applets, but not if gnome-panel loses significant features people will miss badly. See KDE 4.0 for a rather brutal history lesson. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
What do you mean by this? Every time I've tested on nvidia hardware with the proprietary driver, shell performance has been totally usable. It's not lightning fast, but I don't think any hardware change would fix that. Usable is a rather hard to quantify thing. Not lightning fast to some people (me included) for example is not particularly usable. For me it took until about Fedora 11/12 before even the compositing was efficient enough on intel video to leave it turned on without making gimp unpleasant to work with. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Not true! For example, when you assign to the FSF, the papers you sign contain a number of guarantees. From an old version of the assignment papers (you should contact the FSF if you are considering using this language, as it might have been updated): 4. FSF agrees that all distribution of the Works, or of any work based on the Works, or the Program as enhanced by the Works, that takes place under the control of FSF or its agents or successors, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to FSF or to anyone else for any permitted use of the work they apply to, or to communicate with FSF or its agents or assignees in any way either when redistribution is performed or on any other occasion. And ask your lawyer what happens if the FSF goes bankrupt. Also btw in many countries check copyright assignment is actually possible ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
A possible solution is to store paths under your home directory as relative paths, and when reading, assume any relative paths are relative to your home directory. Doing this with each individual application would be tiresome and error-prone, but it would be easy with a convenience API like this. The traditional Unix way to deal with such paths is to base them off an environment variable so g_settings_set_relative_file(settings, key, envvar, path); eg g_settings_set_relative_file(settings, mbox, HOME, mbox); Then you have the fun that $HOME/mbox is a perfectly valid actual filename so you need to know what you are looking at, or store files in a smarter way. Apple take this even further with removable media so that it knows about paths on a removable device by the device name and relative path. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
On Tue, 06 Jul 2010 16:01:54 +0200 Steve Frécinaux nudr...@gmail.com wrote: On 07/06/2010 03:00 PM, Ryan Lortie wrote: hi Vincent, On Tue, 2010-07-06 at 09:26 +0200, Vincent Untz wrote: Do you feel okay with the idea of allowing proprietary apps to use our platform but not GPLv2 apps? In short, yes. Can't the platform libraries of gnome be considered as a development platform, and therefore being legally linkable from a GPL2 point of view, even if the library itself is LGPL? I mean, I think exceptions exist in GPL to allow programs to link against proprietary platform libraries, to allow some GPL software to run in proprietary MacOS or Microsoft ecosystems, don't they? Our own equivalent of those libraries are glib and gtk+ This would make things a lot simpler. No because the FSF also very carefully made sure you couldn't claim it while distributing such libraries. Which means from a distro perspective its not a brilliant plan - or indeed a Gnome one. You might create an environment in which only non GNOME apps could pull that stunt ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
if you want the Mesa software rasterizer to be faster you can start contributing to Mesa. I'm sure the maintainers will gladly accept patches. By the time you've hit the GL layer you've probably thrown away crucial information needed for many shortcuts. Doom is also much less generic (as to a large extent is quake) but engines use some shortcuts that work for simplified cases. In the doom world you can't look up or down or twist the scene, in quake the twisting is also not present. Spotting those cases with arch specific mesa fast paths would probably be a win for Clutter (especially the 2D flat on view) but I am pretty sure you would still need clutter itself to be more efficient in areas like clipping and to have compositing shortcuts (these can't be inferred by GL) to have a chance of it being useful even on modern low end desktops with two big monitors attached. Much stuff for this seems to be in the clutter development codebase already. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
The other approach is when expiring or archiving to move files from ~/Desktop to an archival location like ~/Documents. How does moving it work with non aware applications or a shared file space ? You risk opening a file having it moved, saving it and ending up with a copy in documents and one stale which could lead to nasty user errors. Seems safe to just filter the view (after all large directory enumeration ought to be fast these days ?) As a completely off the wall comment related to this - the fact I can't drag documents into my calendar annoys me, because that's effectively how some people organise some things in the paper world. I guess that backs up your model but it does mean I expect to see my desktop bits from a date in with my calendar. Is stuff migrating to a filing cabinet by date (This wek, last week, march, ...) a metaphor for the desktop - time stuff ? Also I guess this lets you fix the bin so you can delete last weeks documents rather than just empty trash. It's mildly amusing that you still seem to have to use find incantations to make the bin work well 8) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Sat, 03 Apr 2010 08:13:14 +0100 Ross Burton r...@burtonini.com wrote: On Fri, 2010-04-02 at 23:57 +0100, Alan Cox wrote: maintained for people without the correct hardware support. As of now, all intel, amd/ati and nvidia cards sold in the last five years should I don't believe that is correct for any of the listed vendors even on Linux. On BSD the situation is even more patchy. The gnome-panel will still be available in GNOME 3.0 and will still be maintained for people without the correct hardware support I see you've been taking lessons from politicians (clearly poli/polly - from 'to parrot' ;) ), pity. Here have a cracker... Lets try that again I'm not trying to start a fight or a flamewar, I'm genuinely interested in the directions as the board see it, especially given the hardware situation is not as was stated. Even on Linux Intel - no psb/mrst support (eg Dell mini 10) Nvidia - many cards x86 only AMD/Ati - similar situation, HD cards last time I checked not all supported Is this the xyz is still supported in seen as a short term thing where the panel rapidly gets deprecated/misses features or a long term path ? Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
maintained for people without the correct hardware support. As of now, all intel, amd/ati and nvidia cards sold in the last five years should I don't believe that is correct for any of the listed vendors even on Linux. On BSD the situation is even more patchy. Is Gnome dropping support for these operating systems ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
everyone asking for a plain text format (or even an XML format) for *storage* should be forced to get only that on their machines, but should also be barred from complaining why their boot process takes a minute instead of 10 seconds. and no: having plain text storage and adding a binary cache is not a solution. I always found this amusing. It's about tools and robustness not formats. The XML file is sitting as a set of binary blocks of data in a binary format file system indexed by tables set into a disk whose partition layout is entirely a binary format. You can't edit your disk raw with an XML editor to rescue stuff but rely on tools, yet apparently meta data for a desktop is different (even though its far less important if lost) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
- FS are usually implemented very carefully. They tend to be part of kernel. On the other hand desktop applications are designed much more 'speedy'. Sometimes application hangs (much more frequent then kernel locks IMHO), sometimes it crashes. Desktop application software mostly sucks. I wouldn't argue with that, but the libraries used at the low level are mostly good clean code. - FS have much better support of tools which recover the data. Well - you cannot edit by XML editor but both FAT and EXT2/3/4 have numerous tools that recovers data - even less popular systems like reiserfs have them. I haven't seen them for many application binary format. So write one. The format is visible, the code is open source. You should just need xml2vomit and vomit2xml or whatever format data you use. - The more common code the more profitable optimalization is. If the format is read once at startup it makes much more sense to have it more readable then fast. On the other hand if it is used constantly... That argument is garbage. It's one reason why Gnome takes forever to start up. As a normal use you regularly start applications and desktops, you almost never go and emacs the XML file. Take 20,000 distro Gnome users, what percentage of them do you think have ever hand edited their configuration, what percentage do you think have ever used things like gconftool. For that matter what percentage of normal users do you think even understand the question Have you ever hand edited your gconf database They all start the desktop up, they all bitch about it taking forever. looking through it is cheap as it is already in random access memory. Since even cache operates on virtual memory as long as block is continuous it makes practically no difference in speed. Reality check. On a modern hard disk a good rule of thumb is that reading 512Kbytes of data costs as much as a single sector read. So you want all your metadata in a single linear file loaded once, in order. Now whether that is something looking like rot13 encoded vomit, beautifully spaced and formatted XML or a database format is less important because the rotational latency and seek latency of the disk dominate any processing time unless your data format is extremely bogus. - FS are rarely compressed. Text-based formats are much compressable and backup of them would take much less space. The same *information* should compress to the same size irrespective of the input. Thats a mathematical theoretical case but reality isn't far off providing any padding is consistent. You don't want to compress critical backup data anyway because it means a bit error on the backup media costs you vastly more data. The only sense by which text compresses is better is the because it was larger and more wasteful to begin with sense. Shrug.. pluggable back ends would be nice anyway. I'd rather have my base preferences in hesiod ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
at low I/O priority, without unpleasantly degrading system performance. I imagine the sheer seek cost of pulling all those dentries, inodes into memory, and evicting all the other useful data you had around - is a big part of the plague. Hopefully btrfs will improve the situation somewhat here, but wrt. inode / dentry management I suspect there is no really good solution. On rotating media its seek and access times. This is amplified on most older systems by the fact ATA devices had no queueing interface so the drive couldn't do any smart re-ordering to extract further parallelism. SSD is more important here than btrfs. Filesystems can try to be clever and hide the fact rotating media sucks for latency versus processing power, but only SSD actually fixes the problem properly. Unfortunately, as soon as we have this, it is only a small feature-creep step to lets index all .c/.h files to extract comments in the API documentation - which (I suspect) then commits you to the disaster of irritating a lot of developers - so they turn it off, and getting bogged down indexing things no-one is ever going to want indexed by tracker (?). I think there lies a misassumption. The actual indexing has a fairly high cost. The cost of extracting metadata while indexing ought to be relatively low in comparison. That argues that allowing stuff to plug into the indexing based on file type is useful. It's not really function creep either given the only interface the indexer needs is - who is associated with this file type (which exists) - give me your metadata for this file content and if there is nobody wanting to do so then who cares. If apps provide the interface for metadata extraction (into a tag soup or something) then if you don't have the app installed you won't index for it. Document to tag ought to be fast. Personally, I'd start by ignoring any directory tree with a configure* script in the top-level, or perhaps a .git / .svn directory - that should reduce the inotify pain :-) So - my point is: are the devs fetching source code at the console - that you are concerned about above, really in the target audience for tracker ? and if so why ? How about who sent that patch, what are the related emails and when were they last on irc - a classic developer query. Possibly bundled in with do I have a picture of them (conferences) and who are their close friends (other ways to get hold of and see connections), where are they right now (irc connecting address, email headers and geodata for IP addresses). Or in short - developers are not different. A lawyer wants to do the same thing within a firm for a case note, an CAD designer for a design change, a secretary for letters, etc. Physical indexing (the file walking side), extracting meaning and query processing are three unrelated tasks. In your developer case if I've got various git helpers installed it would be nice that the indexer bothered to talk to the git plugins about source code and git trees. If I don't have them installed it doesn't need to - its a modular problem. Maybe you also need to learn what types of metadata people use the most for presentation (eg by what links they follow) but thats another story in the UI anyway. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18 Aug 2009 19:31:04 +0200 The tracker-store is a desktop service that offers the application developer a query capability against data that it stores. The data that it stores must be strictly defined by a schema (which is what in RDF is called an ontology). The schemas that we ship by default are the Nepomuk ones. The query language is SPARQL. The service provides the opportunity to the application developer to store. The application developer uses the an extension to SPARQL, SPARQL Update, which we support too. The communication between application and tracker-store happens over DBus. Nepomuk's ontologies: http://www.semanticdesktop.org/ontologies/ Broken link btw at: http://www.semanticdesktop.org/ontologies/ for: http://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies/pimo/latex/pimo.pdf Let me know if that was a helpful description for you. I tried hard not to sound like an old German philosopher ;-). One thing I couldn't quickly tell is whether you are always remembering the source of external information, particularly any externally acquired personal information about someone that is stored in the database. That may be important for business users who have to meet data protection/personal information rights legislation. Ditto that tracker doesn't start extracting and organising by anything like religious, medical or ethnic data whose processing is controlled in many countries. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Tracker will store this if the applications request storage of it. The issue of protecting the user's personal data is left to the applications using it and the underlying operating system's security features. To a business deploying systems with this feature there are multiple issues - Need to be able to keep personal data secure (OS problem mostly) - Need to be able to search it (probably remotely) for data access requests (not really different to the situation now with pulling out emails and the like). Also the point of it is to index such data so it makes the job easier ! - Need to be able to identify the source of incorrect data - Need not to be processing sensitive data (race etc) without appropriate authority. The last one is very much a social (company policy) issue but at the same time having tools that are a bit too good at their job and collected this by default would be particularly bad. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
One short coming in this approach will be, It will cause a problem where multiple applications can be associated with a file-type, over a period of time. For instance, for .mbox files, the applications could vary like: Evolution, Mutt, Pine, Claws, Thunderbird, etc. And it is common among some people to switch between applications; not for email but other applications like PDF-viewer, etc. once in few months. This requires some commonality about indexing and the meaning of concepts. There isn't anything wrong with several apps indexing the one file (preferably at the same time so we walk the filestore once). A more interesting problem is heirarchical breakdowns (a multipart mime email of a zip holding a pdf and a jpg file) or xml documents with multiple namespaces in use. subject is the metadata etc. So every time the user switches applications, the earlier collected meta-data might need some brushup. That assumes that the old meta data is somehow wrong. When an office changes staff the way stuff is indexed may change a bit but the old index doesn't become invalid or useless. many sites exist. For desktop the scale of the things is less, individual application-provided-search is enough and will satisfy the needs of most of the users. ctags, mairix etc. can provide specialized and more effective searching. The notion that the internet and personal file store are separate is one I would question. Why for example would I not be running a query across my personal email and a company wide accumulated metadata source of all the internal public mailing lists. Specialized searching is also very different to general contexts. It is better at the one job but cannot answer random queries or associations. /home is a place where you keep stuff nobody else needs, or you want fast access to, or you particularly don't want other people to have access to. Indeed if you backup to an internet connected server its not unreasonable to argue that user filestore is simply a cache, nothing more. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On Thu, 16 Jul 2009 00:41:21 +0200 Pascal Terjan pter...@gmail.com wrote: On Mon, Jul 13, 2009 at 4:37 PM, Matteo Settenvinimat...@member.fsf.org wrote: IANAL too, but I'm not sure it fits. It's questionable if it is a system component you can't live without, like glibc. However, that's just my opinion. Well you can live without glibc, use dietlibc for example :) System component may not help you: the GPL purposefully says **unless that component itself accompanies the executable.** so if you are trying to ship a device for example containing all the bits it won't help you. More fundamentally GPL code is code that has been provided as part of a community to be shared and used to build other code that will be shared likewise. Trying to find ways around the licence is just plain unethical, and rude to those who contributed the stuff. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On Fri, 10 Jul 2009 03:46:47 +0100 Joone Hur jo...@kldp.org wrote: If we use GNOME Shell on embedded devices, we need a GPL licensed OpenGL/ES library (HW accelerated). The problem is that we didn't find this kind of library. Chipset vendors don't provide a GPL licensed OpenGL/ES library. So ask them to fix it ? I'm not sure why you are asking on this list about a licensing problem with a chipset vendors OpenGL/ES library ? or asking legal questions which you need your lawyer to answer ... Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Help with strings for solution for desktop file virus problem
Its true that all of these *could* and *should* mark the file as executable, however since we never demanded that before this would be a regression for many users. Both for old created desktop files and for new ones created by non-updated apps. Why is this a problem ? - You can chmod the existing desktop files on an upgrade - If you meet one that appears not to have been updated you can ask the user/fix it with their permission If you are willing to be selinux aware you can also use the labels and security contexts for this ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
This is kind of silly; I have to type a complex keyboard combination in order to input a password? That is annoying. Additionally, switching It makes a lot of sense in some environments and not a lot of sense in many others. VTs in Linux is usually slow; more annoyance. Expect some resistance on this feature. Actually our VT switching is incredibly fast, the X VT switching is slow and much of that is because you have to spend time waiting for PLLs to stabilize and the like not because of bad code. You wouldn't need VT switching for SAK/trusted path anyway. Besides, my user account being compromised is 99% as bad as the root account being compromised, IMHO. Again depends on the environment. On a home system if something is stealing your password the box is probably compromised. On a multi-user or shared system its quite likely another legitimate user who has not compromised the box is the cause. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: indentation of c code
http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html So, basically GNOME was supports to be using the linux kernel coding style to begin with, but that has probably been watered out by now. For the kernel coding style its indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -il0 (which is why its a script scripts/Lindent in the kernel distribution) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Composition [was Re: gnome-session proposal]
Get a better kernel then ;-). On a more serious note, didn't the recent Firefox 3 O_SYNC fiasco on Linux make some file system developers realize some short comings of current state of the kernel? If so, Synchronous I/O is *very* slow but you need to discuss that mostly with hardware vendors if you must use it. Hard disks have very low operations/seconds and very high internal latencies you can't hide if the application demands synchronous I/O. That is why we have fsync/fdatasync and thread creation... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
I don't mean to be impertinent, but isn't any screen bigger than 2048x2048 a major edge case? It's like desktop apps that only work on screens bigger than 640x480... who cares at this stage? By the time that's anything bug an edge case, won't the hardware have caught up? It's far from an edge case. Any situation with two monitors side by side of 1024 pixel width causes the problem. Thats a pretty normal setup for anyone doing art design, engineering or similar work. (And yes I agree the hardware/drivers need to catch up ;)) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Sun, 15 Jun 2008 00:32:05 +0100 gtk_label_new (_(this is a string with in it)); Well firstly it is no longer C. You should be using \2xx\0xx or \xblah encoding but that is a trivial side item to fix. Assuming you fix that it obviously compiles and probably comes out ok in a .po file. In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that point depends if gtk_label_new ever calls a single C library function that is locale dependant (eg strcasecmp). Now explain how those problems are not caused by this gtk_label_new (_(this is a string with \\ in it)); in the en_GB locale where gettext returns this is a string with in it In the en_GB.utf-8 locale (there isn't a meaningful non UTF-8 GB locale) you get gtk_label_new passing UTF-8 to the C library *but* unlike LANG=C the library *expects* UTF-8 so will give correct answers for the locale. Ditto en_US.utf-8. Perhaps Havoc can definitively state whether than gtk function calls a locale dependant C function at any point ? Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
BTW: I realised last night there is another way to tackle this which lets you turn the problem on its head Given smart quotes directly in code are not valid C and that you need to distinguish different quotes so can't do a perl 1 liner turn the problem the other way up Source - with smart quotes String generation Extract with po file tools Rewrite this with a simple script Extracted string is en_US translation Base string has quotes substituted back Compile Remove smart quotes and replace with ordinary ones Compile with gcc (you could extract the translations from the converted file to save having to mend all the translations but that might actually be long term worse) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
(you could extract the translations from the converted file to save having to mend all the translations but that might actually be long term worse) This would result in a thousand .c.in files or a large header .h.in file with all the strings ;) Not really. You just generate a temporary file in the CC=fix-and-gcc script or use a pipeline - conveniently enough the line numbers don't change so you don't need to keep the temporary file around. Anyway - disk is cheap 8) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Mon, 16 Jun 2008 17:48:31 +0100 Iain * [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox [EMAIL PROTECTED] wrote: In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that point depends if gtk_label_new ever calls a single C library function that is locale dependant (eg strcasecmp). All of GTK is utf-8 compatible. This is the point we're trying to make. UTF-8 compatible is not the same thing as 'can feed utf-8 to the code when in a non UTF-8 locale' Glibc is UTF-8 compatible but it will give you the wrong answers if you feed UTF-8 data to it in a non-utf8 locale. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
All of that means that there are no run-time problems. The only actual concern is whether compilers will choke on UTF-8 source files. Alan says that, according to the standard, a compiler would be perfectly right to choke. I believe him. I also don't care. I don't think that one is a show stopper because if you can guarantee the rest will not break C provides you with \ escapes so you can paste the string in that way. So the question is the one about feeding utf-8 to glibc functions and internal cleanness of gtk/glib (eg what C library dependancies does it have). Having to use \ escapes for the quotes is a trivial inconvenience. They don't just look better. They're easier to read. What's more, they're correct. And if we could get over this barrier, maybe we could start using proper dashes. Good typography makes text more legible. Agreed - my concerns are to do it right, not whether it should be done. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Well, as I said, in this case: gtk_label_new(_(some_string)); The output of gettext can (and often will) be UTF-8, so gtk_label_new is going to receive UTF-8 whether some_string is ASCII or not. If it's not UTF-8-safe, we're pretty much screwed already. No no no The output of _(blah) is blah for C locale, and blah should be ASCII. You should only receive UTF-8 as the return from _(foo) in a UTF-8 locale. It isn't about being UTF-8 safe it is about expecting UTF-8 in this locale. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
They work perfectly when you pass them UTF-8 data no matter what your locale. Just to back this up: http://library.gnome.org/devel/gtk/stable/gtk-question-index.html#id2776084 Cool - so for anything which doesn't touch the C library directly you can write _(\xABCD) type stuff for smart quotes and be in spec (except for the po tools which actually all seem entirely happy with utf-8 msgid). That makes most of it much easier to do. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Fri, 13 Jun 2008 18:01:22 -0400 Dan Winship [EMAIL PROTECTED] wrote: Alan Cox wrote: GTK/Glib are not the biggest problem here. You also use C library functions in Gnome applications. Glib/Gtk+ works with the C library in C locale simply because ASCII is a subset of UTF-8. That ceases to work the moment you introduce UTF-8 bytesequences into non utf-8 locales. Are there actually legitimate reasons for anyone to ever use a non-UTF-8 locale these days? The standards say the default locale (ie if you haven't set one) is ASCII (Locale C). So yes people do. I don't know if the use of KOI8R/RU and shift-jis is still legitimate. I guess you would have to ask the users. I also don't know what the situation is for usage patterns on non-Linux systems. Sun have always been on the ball with unicode but some other vendors are a bit more conservative. Note; I am all for the US locale using pretty quotes. I'm just strongly opposed to doing it against the specifications and praying it works out. Particularly when its probably a perl one liner to generate en_US.utf-8 locale files. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Sat, 14 Jun 2008 01:44:09 +0100 Alexander Jones [EMAIL PROTECTED] wrote: So how do we go about coming up with an official position for this? If I start cooking patches here and there I don't want to have to make the same argument with every maintainer... :) It seems the standards documents already have an official position on this if you would actually read them or listen to what they say. Use nice quotes sure - but generate an en_US.utf-8 po file for it as you are supposed to do. Perl one liner contest opened... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Sat, 14 Jun 2008 01:43:05 +0100 Alexander Jones [EMAIL PROTECTED] wrote: Alan, you seem to be missing the point. No I'm afraid you are the one who is missing the point here: The only places where I am suggesting replacing with are in existing gettext calls, which *are* UTF-8 whether they need to be or not, and are always used with UTF-8 string functions. The output of a locale C or untranslated string from _() is the input. The output in those locales must be ASCII for some things. The input must therefore be ASCII. The issue is whether the compiler will bork when it sees bytes with MSB set. So far nobody has been able to say with any conviction whether it will. The C standard answers this. Previous mails answer this. You apparently don't want to hear the answer. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Are there actually legitimate reasons for anyone to ever use a non-UTF-8 locale these days? Other than legacy, and wanting to find bugs in programs? Probably not... Maybe somebody should break the compatibility view and make the C locale UTF-8. Well you can certainly submit a proposal to the C language standards committee and the POSIX standards committee. We don't control C locale definitions - they do, and the tool writers work to their definitions. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Sarcasm aside, if people are using Shift-JIS/KOI8R/RU in translations, those strings WILL get fed into UTF-8 string functions and stuff will break. We use UTF-8 here, in GNOME-land, right? If the gnome libraries have built in UTF-8 assumptions yes. But the rest of the system will work just fine. No idea what other desktops would do but I guess they'd be fine too except XFce (i.e. the other way) is doable though. But I don't see the point other than to satisfy your obsession with obsolete character sets from the 60's. I think mean current standards from the 21st century. That being ANSI C, Single Unix Specification, and the like. I see your point about the need to have both kinds of quoting, so the translation work is indeed a tiny bit harder If someone could actually speak out and say what it breaks, we could actually get somewhere with this debate. So far I hear no credible opposition. Thats because you have your fingers in your ears and don't want to listen. Consider a career in politics instead. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Sat, 14 Jun 2008 18:42:24 +0100 Iain * [EMAIL PROTECTED] wrote: On Sat, Jun 14, 2008 at 3:35 PM, Alan Cox [EMAIL PROTECTED] wrote: Thats because you have your fingers in your ears and don't want to listen. Consider a career in politics instead. Well, no, you have brought up irrelevant points (to the question at hand) and straw manned any rebuttal of them. Oh dear. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Some people are worried about string functions breaking. I really don't see how this is the case, seeing as we're doing g_some_function (_(Some ASCII string)) which is replaced with a UTF-8 string at runtime anyway. Does anyone have any actual proof of UTF-8 in our translatable strings breaking C? Your reasoning is completely wrong. Please take a bit of time to understand how internationalisation and localisation logic actually work. Your model for making the decision is also wrong. The question is not have we made it break yet it is is the action we propose to take one which has defined correct behaviour. It's as wrong to say oh it'll work about this as to say gcc happens to do this in the right order, who cares about correctness or I've never seen a NULL pointer here so why check. In the kernel world we have made those assumptions now and then (usually as an oversight) and when gcc or tools updates broke them the tools people were quite definitely *not* going to make their compiler work around our problem. So you can get burned badly in the future even if not today. If your string is untranslated then _(foo) - foo. If your locale is not unicode then this places utf8 symbols into non-utf8 locales. Similarly if you are in the default locale (which is where you end up if you don't set one or the environment variable gets lost etc) you end up with (foo)-foo. Now if the resulting translation is ASCII all is well because ASCII is a strict subset of the locales we support. If your input string is not ASCII then functions like: strcoll, strxfrm, strcasecmp, isupper, islower, isalpha, ... etc all start giving undefined answers. You've also ignored the fact that output of utf-8 bytes in a non utf-8 mode is going to have undefined results as well. Keep the nice quoting in the translations. If need be generate en_US.utf-8 from the Makefile using a script. en_GB.utf-8 is already mostly done this way so teaching en_GB.utf-8 to use nice quoting is trivial. For French and German the rules are different anyway so will need to be done in those translations separately. The po system is designed to let you do smart quoting, it is also designed so you can do this in a defined correct and proper manner rather than trying to cheat and digging a huge hole to fall down later. Somebody said that any byte with a the MSB set (i.e. 0x80-0xFF) will cause some compilers to break. Is this true? You are out of the C language spec at that point. It is entitled to play cribbage if it wants. That of itself is not a problem as you can use slash notation for unprintable symbols anyway - it just looks uly. Also don't forget Gnome supports multiple languages not just C, and many use po files. Whatever is chosen must work for all of these. If you want to embed those bytes in a C program use \xxx notation for them .. ie _(\2??\0??hello\2??\0?? said the dog) Far cleaner to generate an en_US po file really isn't it 8) Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Since you don't know whether the result of _(foo) will be strict ASCII, you must always treat it as if it were not. GLib/GTK+ *requires* UTF-8 strings for all (most?) of its string handling functions... GTK/Glib are not the biggest problem here. You also use C library functions in Gnome applications. Glib/Gtk+ works with the C library in C locale simply because ASCII is a subset of UTF-8. That ceases to work the moment you introduce UTF-8 bytesequences into non utf-8 locales. ...so afaics calling these non-UTF8 aware functions is a bug regardless of the current locale. You are completely wrong. These functions are *locale* aware. In a non utf-8 locale they take non-utf8 input. In a utf-8 locale they take utf-8 input. Feeding them the wrong thing is broken and will give wrong answers. You've also ignored the fact that output of utf-8 bytes in a non utf-8 mode is going to have undefined results as well. All output must be handled by g_print, not by printf so this is also a non-issue I think. What about printing to files ? An nm also rather suggests that gnome apps do use printf and fprintf somewhat and many of the other functions mentioned. syslog() is another that is used. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Fri, 13 Jun 2008 19:41:15 +0100 Iain * [EMAIL PROTECTED] wrote: On Fri, Jun 13, 2008 at 4:12 PM, Alan Cox [EMAIL PROTECTED] wrote: What about printing to files ? An nm also rather suggests that gnome apps do use printf and fprintf somewhat and many of the other functions mentioned. syslog() is another that is used. I don't know what your use cases are, but I don't find myself passing UI strings to syslog very often. syslog is just one of a list of functions a quick nm check found that showed gnome apps use the C libraries not just glib/gtk. I suspect stuff like string sort ordering and strigth lengths are more of an issue. Surely your hypothetical case of syslog (_(string_containing_normal_quotes)) is going to fail in the same way if the translation has any utf8 in it. Who knows. You'd have to know precisely what functions syslog called that were locale sensitive... Surely as programmers we can be trusted to know the difference between the cases where a string is destined for the UI and where it is destined for something that is non-UTF8 compatible? You have an encylopædic knowledge of the internals of every library you use ? I thought not. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: off topic; HELP! I cannot create a terminal window in gnome.
On Sun, 25 May 2008 22:45:36 -0400 Hubert Figuiere [EMAIL PROTECTED] wrote: On Sun, 2008-05-25 at 20:26 -0600, Ralph Boland wrote: Sorry for not being a development issue unless you consider modifying gnome so those stupid enough to do what I have done can't do it anymore. since you know it is off-topic why do you post it? Perhaps you should both paste and read .. unless you consider modifying gnome so those stupid enough to do what I have done can't do it anymore. Even then you could politely point him at bugzilla. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Wed, 14 May 2008 04:17:09 -0400 Havoc Pennington [EMAIL PROTECTED] wrote: As James says on Simos's blog post, all strings inside GTK apps are defined to be UTF-8 regardless of locale. GLib and GTK will convert on the fly to locale encoding if they print to a terminal. gtk may do, but what will glibc do with them ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
They also tend to fail horribly when pasting into a non-Unicode terminal, which is still often the case over SSH. Probably not a huge desktop consideration, though. Every distribution I know of uses Unicode by default on the local terminal at this point. Doesn't matter for translations but the C locale is ASCII (and sorting is only defined for ASCII) so the base strings that get translated should always be ASCII themselves. What people do with French/German/English/US/.. quoting rules after that is a different matter but surely belongs to the language team. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Don't we already have plenty of non-ASCII POT files? I know gnome-doc-utils is non-ASCII. That would be a bug... that we've had all this functionality for quite a while, but we're still typing as if we're on old typewriters. What do we need to do, as programmers, to get the world out of its ASCII rut? Put the English quotes in the en_US and en_GB translations, put German quotes in the de ones and so on. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
On Tue, 13 May 2008 12:22:51 -0400 Pat Suwalski [EMAIL PROTECTED] wrote: Alan Cox wrote: Put the English quotes in the en_US and en_GB translations, put German quotes in the de ones and so on. This, if course, makes something like the very tiny en_CA locale into a rather full locale. I suppose many generic messages can go into just en. Which rules does Canada follow for the ending of a sentence with quoted text ? quoted text. or quoted text. That might need a locale anyway ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Honestly, other than being pedantic, I don't see the problem with UTF-8 in the C locale. Does it cause any *actual* problems? I've never once gotten a bug report against g-d-u about this. Sort order, comparisons, printing, string lengths when using locale aware functions, and no doubt a few more that for the moment have escaped me. Use the tools to spec and you get reliable predictable results, do otherwise and it all gets sloppy and buggy. Would you rely on undefined C behaviour in Gnome code ? The discussions about it being work are also bollocks (to use a fine bit of en_GB). Make was invented to handle such trivial tasks for you. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help needed with non-US time zones for clock applet
Skipping past the specifics of your post I just wanted to note this has seemed a bit counterintuitive to me for a few years now. It seemed to me like it would be best if one of the first configuratin steps shown to users was a world map, and then based on the location they choose (particularly if they are specific and choose country and major city) a whole lot of clever defaults about their locale and timezone can be inferred from there. (Sure there will be exceptions native English speakers who are living in Spanish speaking country, and many countries are multilingual but it seems like a very reasonable thing to set language, keyboard, and other settings to a sange default based on location.) The install process I'm most familiar with is the one in Red Hat/Fedora, and the time zone/map question comes much later in the process, whereas I think it should be the first thing asked. Not very familiar with how Novell does it and how you get things done in Gnome will I suppose be subjected to certain contraints by the different information distributions provide. It is great that you are already making clever inferences and providing users with better choices just that the task could be made easier if this had been set earlier. Taken this offlist, since I want to avoid bikeshedding getting in the way of your more immediate concerns but perhaps this is something that could be discussed further? Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ http://www.linkedin.com/in/alanhorkan http://alanhorkan.livejournal.com/ On Mon, 7 Apr 2008, Dan Winship wrote: Date: Mon, 07 Apr 2008 12:05:58 -0400 From: Dan Winship [EMAIL PROTECTED] To: desktop-devel-list@gnome.org desktop-devel-list@gnome.org Cc: [EMAIL PROTECTED] Subject: help needed with non-US time zones for clock applet (Specifically, if you live in [or are knowledgeable about] AR, AU, BR, CA, CN, CD, GL, ID, KZ, MY, MX, RU, UA, or UZ, please read this. Thanks :) Vincent has just committed the patches to fix the clock applet guesses the wrong timezone bug, but this relies on libgweather/data/Locations.xml.in having the correct timezones listed for various places. For large countries that span multiple timezones, it takes some work to get this right. I spent a while getting the US right, and I did some investigation on most of the others, but there are still places where the information is wrong (especially in the non-English-speaking countries, which it was harder for me to find reliable information about). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Companies don't like GPL as they have to expose their IP and are afraid to loose money. If the library is LGPL they can still use the I would disagree there. Most companies I deal with like the GPL because it means that anything they do provide cannot be ripped off by the competition - which is a real world problem with BSD and LGPL like licenses. So the position you characterise is actually not general - and I think is actually very 1990s about how much time would be required to throw out the GPL-infected code and replace it with LGPL, together with the time it would take to get permissions from the people who are not strict GPL-fanatics to It strikes me that using words like infected and fanatics is not the way to persuade people that you are anything but a troll and to have a serious debate. A lot of contributors to projects actually don't think random companies should be able to take and not give back. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: how to take screenshots of cheese
without having my face all over the gnome website? well, i would like that too, but i dont know if you guys want that ;) If it's just screenshots, can't you use a source other than v4l(2)src in your hacked version with a picture with a nice license (say, some creative commons license). You could even add that as an option in Cheese itself if passed a particular command-line option, so that other people can do mock screenshots too. Or you could use your nice puppet :) Puppet +1 and if it's a wanda puppet even better. of course we could fake the picture and put there an image of a beach or vuntz with an ice cream.. *waiting for ideas* ;) Hoping I'm not stating the obvious, but a GNOME? Maybe borrow a garden gnome from the neighbors if you don't have one? :) Alan -- Alan [EMAIL PROTECTED] - http://arcterex.net Beware of computer programmers that carry screwdrivers. -- Unknown pgpLbKK2YaaX5.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extreme memory usage for gnome-panel related apps
But fundamentally right now the desktop is still one security domain, and I don't see that changing in the near future. The desktop is quite a few security domains. Mail clients handle certificates and dangerous remote content, other tools render untrusted content like PDF, while the desktop panel probably deals in little more dangerous than weather reports. Not to mention a bunch of other problems. It's probably better to just fix the VM's. Far harder - and I think it would likely require language semantics to change, in particular for Python. Having one VM for Python applets would not be rocket science. Someone just needs to spend the few days on it, and get patches to use it upstreamed. For applets it would be a huge help and I agree not be a security issue. More generally it would make SELinux rules harder to get tight. Taking out the commonly used python apps and replacing them with compiled code would be an even bigger performance and size leap. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extreme memory usage for gnome-panel related apps
(FWIW, personally, I'd like to see all of our service daemons (g-p-m, g-v-m, pk-update-client, etc.) all sharing the same process space. Things like that.) With a kernel hat on do you have a specific reasons for that ? Is there stuff you gain or is this primarily about memory usage of non shared objects ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. If you've got VIA video I bet it does. But thats a VIA X problem. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
New d-d-l rule: no one gets to say 'it is useful' without explaining their use case :) Luis (I believe you that you use it, but I can't for the life of me figure out why) I use week number because everyone I deal with in Finland has phone calls meetings week 37 and the like for some reason ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
I'd love to hear some feedback from others. There are some consistency issues most people can probably spot, like the [Edit] buttons should probably be [Edit...] since they open other windows to complete the interaction. Things like that I believe can be done pretty quickly and aren't worth going back and forth on a mailing list about. Another cool change would be (dynamically?) swapping between the multiple timezone clocks one over the other to a more compact view with clocks stacked horizontally. My $0.02 -- Alan [EMAIL PROTECTED] - http://arcterex.net Beware of computer programmers that carry screwdrivers. -- Unknown ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. The Linux kernel key service can do this for session/user/user+session and other key types, and you can use SELinux labels on it. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Wed, 29 Aug 2007 16:39:04 -0400 Ray Strode [EMAIL PROTECTED] wrote: Hi, On 8/29/07, Alan Cox [EMAIL PROTECTED] wrote: Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. The Linux kernel key service can do this for session/user/user+session and other key types, and you can use SELinux labels on it. But the kernel keyring isn't persistent across reboots is it? It provides a mechanism to manage the keys and to use SELinux labels on them to control access. If you want to save them across reboots then that would need user space involvement as well. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
- have some mechanism for smart deductions, like I can guess you have an XMPP account that matches your google.com username/password - maybe this just has to be in the apps, not sure This needs some care. There are evils that lurk on the web side of this. One big one is that if a central service provides a guessed login/password from another source to firefox, I can steal it using javascript into a hidden form which might be bad if I can trigger wrong guesses. For pure web use this problem doesn't normally arise as the URI gives a scope which makes sense, once you take guesses from outside you don't know enough to guess where to paste them. I just started thinking about this today, so let me know what's missing. One of the things you can use the TPM for in a treacherous computing system is simply as a poor quality smart card. And for that matter working with a proper smart card is similar. Being able to share my keyring simply by - USB - Bluetooth - Internet - Smart Card - TPM (where there is a common root key) including merging entries from multiple sources. PAM already lets me direct sensitive system authentication questions to a seperate trusted display (my phone) which I can't currently do for the other apps. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Exactly, yep. I can write some simple spec up, but first I want to understand all the current thinking (so far it sounds like there's a pretty blank slate for spec'ing this out) You might want to have a chat with Dave Howells at Red Hat as well. Dave did the Linux kernel side key management which handles keys on a thread through to user and group level. Documentation/key* in the kernel. This is used to manage keys needed for things like file systems but can be used for other stuff too. It also supports callbacks so the kernel can ask user space about keys. Currently this is used by the ecryptfs and AFS/RXRPC file/net system layers, and also by the MMC/SD layer for managing passwords to encrypted cards. It'll probably soon get used by libata to manage passworded disks (and thus passworded compact flash) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On Thu, 9 Aug 2007, Bryan Clark wrote: snip An excellent advantage that the online desktop server project has in being open source is that it doesn't have to re-implement any other existing service. MySpace and other proprietary sites will continually purchase or build new extensions (like video and photo services) to bring into their fold. Our blessing (and our curse) is that we'll Mostly true about the lock in of these sites but it sounds like you might be unfamiliar with Facebook. Unlike most of the other social not-working sites Facebook have opened up their software (to what extent I'm not sure) and are benefitting from all kinds of third party applications http://developers.facebook.com/opensource.php The wealth of third party extensions are making it easier and easier to aggregate all kinds of bits and pieces from other services on facebook, to my mind gradually becoming more like mugshot (or at least how I perceive mugshot). ... but that is somewhat beside the point. -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Online [Re: Online Desktop integration ideas]
On Mon, 23 Jul 2007, Pedro Silva wrote: Date: Mon, 23 Jul 2007 17:22:32 +0100 (WEST) From: Pedro Silva [EMAIL PROTECTED] To: desktop-devel-list@gnome.org Subject: Re: Online Desktop integration ideas Hi! Perhaps I misunderstood some goals of GOD but I still think it's a great idea. Perhaps I'm being overly sensitive and I mention it now before it becomes any more entrenched but I'm not fan of acronyms to begin with and I find this particular choice of acronym - GOD - to be a little disconcerting. Although some jokey acronyms may seem amusing at first the novelty value tends to wear off. I would ask that people reconsider, the words Gnome Online are not too hard to type, and quite a succint phrase that if searched for one might stand a decent chance of being able to find something relevant. Respectfully Alan Horkan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Online [Re: Online Desktop integration ideas]
Although some jokey acronyms may seem amusing at first the novelty value tends to wear off. I would ask that people reconsider, the words Gnome Online are not too hard to type, and quite a succint phrase that if searched for one might stand a decent chance of being able to find something relevant. Its also open so you can be GOOD (Gnome Open Online Desktop) instead ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ubuntu's shutdown screen
On Sat, 31 Mar 2007, Martin Meyer wrote: Date: Sat, 31 Mar 2007 10:43:01 -0400 From: Martin Meyer [EMAIL PROTECTED] To: Frederic Peters [EMAIL PROTECTED] Cc: desktop-devel-list@gnome.org Subject: Re: ubuntu's shutdown screen To clarify, I am *not* running Ubuntu on at least one of my systems (Gentoo), that's the reason I knew it wasn't the gnome default. Isn't it just an applet that Ubuntu uses though? Could that be made available as an extra package to install? That eye candy example look cool. It'd be interesting to have something like that, but I'd settle for a unified system first. Who maintains the logout and shutdown screens anyway? I have no idea what project they come from. As far as rational, it seems to me that most users only want one place to go when they plan to leave gnome: a logout screen. I understand that they perform different functions (one seems to interface with gnome-session and the other with gdm?) but users (like me) don't care which software is being contacted. They just get annoyed when they just want to logout and realize that they only put the icon for shutdown on their panel. I can see a reason for leaving the two independent dialogs there because you don't always want users to be able to shutdown (i.e. on a There was a recent discussion on the usability mailing list where a systems adminstrator wanted to remove the Shutdown button so that his users would not shutdown during an upgrade (or otherwise interfere with background processes) or in the simpler case choose Shutdown when Logout was the more appropriate choice. There are certainly reasonable case to hide the Shutdown button in multi user sytems, or at least relegate it to the GDM login screen. http://mail.gnome.org/archives/usability/2007-March/msg00040.html server), but when gnome is used on a desktop it seems like a good idea to combine the two. Maybe leave the logout dialog in place and change the shutdown to combine logout options as well? That way the shutdown applet could be subject to lockdown rules and become unavailable if the sysadmin didn't want it there. Keep in mind a determined user can find many ways to shutdown (or otherwise forcibly reset a machine that is causing problems) and systems adminstrators must fully understand lockdown is something of an overstatement. Having suffered attempts at lockdown in a Microsoft enviroment I'm deeply concerned about the usability implications of inappropriate attemps at lockdown, or unintentionally allowing systems adminstrators to setup a very hostile enviroment for users. Conversely having provided technical support I fully understand the need to move certain things out of the way so user do not trip on them, but bolting everything the floor is not necessarily the right answer. (Please forgive the over extended analogies.) -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
I think it would be a shame to drop the credits for our past contributors. We're standing on the shoulder of giants. The giants are not the ones it matters to, they have their names tattooed over everything. You are standing on the shoulders of a small army of minor contributors, who probably are not recognized elsewhere or known anyway, their names should stay IMHO. It also avoids the question of appropriate copyright notice (GPL clause 1) and compliance with various national laws that protect authors rights to be acknowledged for their authorship. I'd be for putting the older contributors at the bottom of the list and the current ones at the top. It'll put me right down the bottom but thats only fair. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Weird and wonderful visual styling of applications
On Thu, 1 Mar 2007, Xavier Bestel wrote: Date: Thu, 01 Mar 2007 10:27:50 +0100 From: Xavier Bestel [EMAIL PROTECTED] To: Alex Jones [EMAIL PROTECTED] Cc: desktop-devel-list@gnome.org Subject: Re: Weird and wonderful visual styling of applications On Thu, 2007-03-01 at 01:23 +, Alex Jones wrote: As much as I applaud any effort to depart from uninspired default styling, if we want visual wow, we should try to make it happen in a consistent fashion, and then maybe we can make it look even better! I hope you don't mean everyone should use the same effects. I personnaly appreciate being able to differenciate betweens apps from a quick gaze. If you have a look at plain GTK+ apps, they are all alike. Visual inconsistency sounds awfully like broken accessibility to me. Form must follow function. Eye candy should only ever be an optional extra and if it is in fact causing accessibility problems as I suspect it just wont fly. The described case of different styling in tree views is not one of the cases which had previously grabbed my attention but rather other cases like Jokosher which where doing specially themed buttons and application colouring which seemed more appropriate for themes than application specific changes. You'd be surprised. Even common controls under Windows are implemented using various different libraries, each with their subtle differences. IMHO the linux desktop is way ahead in this respect. I wouldn't be quite as optimistic as to say way ahead but things are not quite as intentionally broken as I think more than few developers have experienced the likes of Winamp and other fully skinned applications and learned quite a bit from the experience. Hopefully this is one of those problems which will ebb and flow, and as the more heavily themed or unusually styled applications get more mainstream attention - and from interested parties such as Alex - they will come into line with the same reasonable requirements as the rest of Gnome but hopefully find ways to add new flourishes to Gnome without breaking anything. -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for a Gnome Media Center
On Wed, 14 Feb 2007, Ross Burton wrote: Date: Wed, 14 Feb 2007 10:22:37 + From: Ross Burton [EMAIL PROTECTED] To: GNOME Desktop Devel List desktop-devel-list@gnome.org Subject: Re: Call for a Gnome Media Center On Wed, 2007-02-14 at 10:56 +0100, Christian F.K. Schaller wrote: As for a shared database this might be a good idea, but I will leave that up to application writers to decide, for me a good start would be that all Music applications for instance tried hard to get people to save their Music under $HOME/Music for instance. That way when you start another Music application or Elisa you don't need to specify which directory to look for Music inn. Similar conventions would be good for pictures and movies and album/dvd cover art. Just last week I got a bug report and a patch for this in Sound Juicer. It hard-codes the default location to save files as ~/Music/. Now, my question is this: do I commit this, or do we need a more powerful system that handles i18n? I'm sure a Persian GNOME user would not like their music in ~/Music/. One quick solution is to translate the string Music... is that enough? We've run around this mulberry bush many times before[1], especially when it came to talking about the Desktop folder and a Documents folder. The question of what about non-English users will likely be followed by what about multilingual users and many more questions. It is very easy to make this problem very complicated but the simple truth is the file system is full of folders with English names and that isn't going to change. Delaying this even longer is a disservice to Gnome users, even the non-English speakers. Hopefuly what might change is that Gnome might finally be ablet decide on some kind of suitable default folders for Documents, Music, and Pictures. Sure some users will organise themselves and others will not organise anything at all but by providing good default save locations there will be a whole lot of people in the middle who will get a little bit more organised thanks to the affordance provided. [Personally I think a folder ~/Documents/ is needed with other user files such as music, pictures, spreadsheets, and anything else getting put in subfolders of ~/Documents/ rather than creating lots of folders like ~/Music directly in the home directory but either way I'd be very happy if we could push to make something happen here, just so long as we avoid sticking the patronising My prefix in front of everything (which thankfully Microsoft have finally dropped).] -- Alan [1] Various discussions on standard folders such as Documents http://mail.gnome.org/archives/desktop-devel-list/2003-January/msg00273.html http://mail.gnome.org/archives/desktop-devel-list/2004-October/msg00016.html http://mail.gnome.org/archives/usability/2005-June/msg00089.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
