Re: Code of Conduct questions
Or could we use an alternative? On Mon, 22 Oct 2018, 08:36 Jacob Lifshay, wrote: > Hi, we were thinking of asking if freedesktop would host Kazan ( > https://github.com/kazan-3d/kazan) for us, however some of our community > members have objections with how freedesktop's Code of Conduct is currently > written. Would it be acceptable for a project on freedesktop to have a > different code of conduct as long as it has similar intent? The code of > conduct that we would like to use is similar to > https://libre-riscv.org/charter/ > > Thanks, > Jacob Lifshay > ___ > xdg mailing list > xdg@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/xdg > ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - John John Tapsell Computer Programmer for Nokia Brighton, United Kingdom Confirm that you know John Tapsell: https://www.linkedin.com/e/-abnzmn-hbnkozff-3b/isd/10339121136/WwQSGc6I/?hs=false&tok=0AsO8DlCfufBA1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-abnzmn-hbnkozff-3b/IXDnpZHn-CDwzobjOGDUaNuUFP5rIlT/goo/xdg%40freedesktop%2Eorg/20061/I3437833516_1/?hs=false&tok=2jUbaylYvufBA1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop usability issues: some comments from the country of bears, vodka and ISO8859-5
2009/9/1 Sergey Udaltsov : > Another issue - stealing focus. In X Window, every app that requests > focus, gets it. I think KWin disables focus stealing by default. Either way, you can turn it on focus-stealing-prevention. > 2. Primary X Window selection behavior > ... > Conclusion: standardize KDE approach to primary selection Talk to the gnome people then... maybe write a freedesktop proposal. > 3. Open/Save dialogs > > The dialogs are platform-specific, it is a well-known fact. It would > not be technically difficult to provide the selection mechanism - > allowing user to choose the dialog variant he likes best. It can be > done using DBUS calls. Once this interface is standardized, the > dialogs could be implemented using FLTK, openmotif, ... If it's not technically difficult, send a patch :-D There have actually been an (several?) attempt to do so, since it also adds the advantage of being easier to secure, selinux style. I thought the portland project was going to have a go, but I can't see anything on their website about it. > There is one closely related issue - the bookmarking mechanism, used in these > dialogs, should be standardized as well. meh > > Conslusion: There is a need in DBUS standard on this interface. > Additionally, we need some convension for bookmarks (something like > directory .config/bookmarks with symlinks or .desktop files or > smth...). Write a spec for this and propose it. > The most serious issues to address: relatively expensive > outproc calls, What's outproc? > no standard VFS used by all DEs Difficult. Something portland is/was also trying to solve. > difficult per-app > customization of the open/save dialog (used by some apps). So.. it is "technically difficult" then? :P > 4. Hotkeys and layout switching shortcuts are sometimes not compatible > > This bug is as ancient as X11 and XKB. Once you configure Ctrl+Shift > as layout switching (=group switching) shortcut in XKB, you cannot use > it in "normal shortcuts". The root cause of that is that X11 always > acts on key press, not on key release - and you cannot assign > different actions on key press and key release. > > Conclusion: X.Org/XKB should be (incompatibly?) fixed: allow > specifying separate actions on key press and key release. It most > probably would explode a living hell of issues, but we'll never know > till we try. > > 5. Global hotkeys are controlled in several places. > > GNOME apps tend to start gnome-settings-daemon (otherwise they look > weird). And g-s-d may grab some shortcuts. If it happens in KDE, the > results may be unpredictable - two sets of hotkeys are interfering... > > Conclusion: actually, none. We need a good idea here > > 6. Independend passwords/keys storages > > Conclusion: We need either single cross-desktop wallet or, at least, > secure DBUS interface to access one. I think this is being worked on by someone. Google around maybe. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
2009/8/3 Matthias Clasen :
> On Mon, 2009-08-03 at 17:36 +0300, John Tapsell wrote:
>
>> >
>> > In languages that have case declensions, "%1 %2" and "%1 - %2"
>> > could involve the GenericName being written differently. So
>> > you might write "Epiphany - Web Browser", but "Epiphany Webo
>> > Browsero". (Completely made up example, of course.)
>>
>> I don't get what you're saying. I wrote i18n("%1 %2"), but you might
>> have missed that. Is that the confusion?
>
> Where i18n() is the function that magically fixes translations ?
> How does that work ?
So can you give an example please? I still can't see any concrete case.
In your example, is "Epiphany - Web Browser" and "Epiphany Webo
Browsero" supposed to be two different languages?
If so, then you'd translate i18n("%1 %2") as "%1 - %2" in the
first language, and "%1 %2" in the second language.
Or better yet, just have "Epiphany - Web Browser" and "Epiphany -
Webo Browsero" for all language.
John
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
2009/8/3 Shaun McCance :
> On Mon, 2009-08-03 at 09:41 +0300, John Tapsell wrote:
>> > Not sure what you mean with 'supporting GenericName', but the current
>> > GNOME HIG recommendations are the way they are precisely because of the
>> > translatability concerns of combining Name and GenericName
>> > programatically.
>>
>> Could someone give an example where programmatically combining would
>> fail, if the combining was done as i18n("%1 %2") or even i18n("%1 -
>> %2") ?
>
> In languages that have case declensions, "%1 %2" and "%1 - %2"
> could involve the GenericName being written differently. So
> you might write "Epiphany - Web Browser", but "Epiphany Webo
> Browsero". (Completely made up example, of course.)
I don't get what you're saying. I wrote i18n("%1 %2"), but you might
have missed that. Is that the confusion?
John
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
> Not sure what you mean with 'supporting GenericName', but the current
> GNOME HIG recommendations are the way they are precisely because of the
> translatability concerns of combining Name and GenericName
> programatically.
Could someone give an example where programmatically combining would
fail, if the combining was done as i18n("%1 %2") or even i18n("%1 -
%2") ?
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
2009/2/25 Patryk Zawadzki : > On Wed, Feb 25, 2009 at 10:10 AM, John Tapsell wrote: >> Are you suggesting some sort of collaborative situation where you want >> some people to trust the .desktop file and others not? I can't even >> imagine such a situation. > > No, I'm suggesting a situation where you have to sometimes work with > files you don't own. Imagine me being evil and creating a file in the > middle of a source tree: > > [Desktop Entry] > Name=fixme.c > Icon=text-x-generic > Terminal=false > Type=Application > Exec=some-evil-password-sniffer > > I can certainly mark the file as executable by you but that does not > make it a trusted one. Okay, but you could also do the same for a bash script. We aren't proposing to try to solve that problem at all. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
2009/2/25 Patryk Zawadzki : > On Wed, Feb 25, 2009 at 2:13 AM, Michael Pyne wrote: >> On Tuesday 24 February 2009, Patryk Zawadzki wrote: >>> Also using extended filesystem attributes (or some other metadata >>> storage) gives you the additional protection from "downloaded a >>> tarball / uncompressed to desktop / the file was compressed as >>> executable / now I have two computer icons" kind of scenarios. >> So what happens when the archive extractor actually supports xattr and now >> there is executable-with-fancy bit trojan laying in the directory? > > It's safe to strip all the xattrs (by cooperating with the desktop's > archiving tool of choice maintainers) without sacrificing any > functionality. Scripts will continue to work, binaries will behave as > they should. The only difference is clicking some of them will yield a > "possibly unsafe content" warning. It's not safe to do the same thing > with the +x flag as you'll break most of the source code tarballs. > Thus +x/-x is not likely to work in a more generic case (not .desktop > file specific). > > Also relying on just the +x flag will not work in collaborative > environments. If I'm the file owner I get to control the +x flag. In > such cases we still need an external metadata storage to take note of > the file path, its hash (to detect changes) and whether it was trusted > or not and if we implement such storage, why not allow just any other > attributes (thus having a working xattrs fallback even if no > filesystem support is present). Are you suggesting some sort of collaborative situation where you want some people to trust the .desktop file and others not? I can't even imagine such a situation. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: feature request :libverbose:library for channeling verbose information
2009/2/25 Lucian Carleti : > Hello > > > A lot of programs directs all verbose to command line interface. > A library which redirects (and organize in level , fatal or non fatal ) all > verbose information to Graphical user interface can be good . KDE already has all the necessary information. kDebug() is called for debug information, kWarning() for warnings, and kFatal() for fatal messages. We even track where the information comes from (see kdebugdialog). It would just require someone to redirect this information somehow and display it in a GUI. John > > Is it possible ? > > Sorry for wrong mail list. > > > Thanks. > > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
2009/2/24 Milan Bouchet-Valat : > Le mardi 24 février 2009 à 23:38 +0100, Francois Gouget a écrit : >> On Sun, 22 Feb 2009, Milan Bouchet-Valat wrote: >> [...] >> > We are now tracking applications usage to build stats and present the >> > user with the most used apps. For this, we identify windows with their >> > WM classes, and want to map this to a specific application, i.e. >> > a .desktop file. >> >> Why start from the window name/class? Why not enumerate running >> processes to identify which binary is running? From that binary it seems >> like you could get back to the package name if needed. > Well, first, we don't want to track background processes, but only > applications we've seen the user interacting with. The model is clearly > centered around objects that the user works with, which are windows. > > Sure, we could see what command was used to start the app owning a given > window, and then get the desktop file associated with it. But this > method suffers from the same problems, as I said before in this thread: >> The "Exec" field can be used if we get the command that was used to >> start the app owning a given window; >> but that's a problem if we can use different commands, and >> OpenOffice.org can be started using "oobase" and used to edit text >> files. > This approach assumes that there's no alternative way other than the one > referenced in the .desktop file to start the window. I'm not an expert > in this area, but I fear there may be many breaches to this assumptions > if you take into account interpreters, symlinks, versioned files... > > This is tricky and IMHO makes us go really far from the direct > relationship between applications, windows they own, and .desktop files > they're described by. And at the end, since we want to be able to > identify apps over the time, we would need to use either the command, or > the .desktop file name. The first can be versioned, move, etc., so we > need the other, which then becomes an app identifier. Any way I look, I > can't help thinking that this unique identifer is needed at the end - > and it's almost existing, since many apps already rely on its stability. You need to be realistic and realise that you aren't going to get every app to change. It does seem that the best way is to simply parse all the .desktop files, pull out the Exec= name, and try to match that against the binary used to run each window (Most Windows have a WM_PID which you can use to get the binary name). Then you'll have to manually maintain an exceptions file for funny apps like openoffice. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
. 2009/2/25 Michael Pyne : > On Tuesday 24 February 2009, Patryk Zawadzki wrote: >> Also using extended filesystem attributes (or some other metadata >> storage) gives you the additional protection from "downloaded a >> tarball / uncompressed to desktop / the file was compressed as >> executable / now I have two computer icons" kind of scenarios. > > So what happens when the archive extractor actually supports xattr and now > there is executable-with-fancy bit trojan laying in the directory? Not to mention all the other crazy stuff that you can do with an archive. You can create a file full of zeros, so that the .tar.gz is only a few KB big, but when unpacked it's terabytes large and try to ruin the users machine that way. Or make the unpacked file small, but have holes in it so that when it's read it's terabytes large. (mpyne - a reason I liked your idea to not use readAll) John > > Regards, > - Michael Pyne > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
One potential security flaw... Say there is a myfile.desktop file that already exists and is executable. If a file download overwrites this, it also becomes executable, since overwriting a file takes on its permissions. Maybe a user shouldn't be so silly as to agree to overwrite the existing file, but is there anything we can do to prevent this? John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
2009/2/24 Alexander Larsson : > On Tue, 2009-02-24 at 13:22 +0000, John Tapsell wrote: >> >> > 7. On initial login make all desktop file launchers in the desktop dir >> > as executable. >> > >> > For 7, maybe we can share what file to use to see if this has been done >> > so that this doesn't accidentally happen twice. Say for instance >> > "$XDG_DATA_HOME/.converted-launchers". >> >> I prefered mpyne's approach in just assuming all the current .desktops >> are bad. Make it only a once-off confirmation to the user to convert. >> That should be good enough. > > You mean once-off per desktop file? Or a once off dialog on login for > all files in the desktop? Once off per desktop file. > > I think this is kinda wrong. Since we previously never required +x for > the desktop files any already existing launchers are implicitly trusted. > They were previously trusted, and the user probably ran them at least > once. So, if they were a "attach" the user is already "infected" and > adding +x to the file doesn't make much of a difference. True, but it seems kinda brittle. I guess I can't really find a reason stronger than though. So I guess my objection is more of a dislike. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
> 7. On initial login make all desktop file launchers in the desktop dir > as executable. > > For 7, maybe we can share what file to use to see if this has been done > so that this doesn't accidentally happen twice. Say for instance > "$XDG_DATA_HOME/.converted-launchers". I prefered mpyne's approach in just assuming all the current .desktops are bad. Make it only a once-off confirmation to the user to convert. That should be good enough. John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
2009/2/24 Alexander Larsson : > On Sat, 2009-02-21 at 18:07 -0500, Michael Pyne wrote: >> Hi all, >> >> >> >> I'm just writing to let you know that I'm working on changing the >> handling of .desktop files for the next major version of KDE. The work >> itself is being tracked on kde-core-devel but a synopsis of the plan >> is: >> >> >> >> When launching a .desktop file (which I'll refer to as a service), if >> any of the following conditions are true, the launch is permitted: >> >> >> >> 1. The service is executable by the user >> 2. The service is owned by root (to handle the common case of >> system-installed files) >> 3. The service is contained in a standard service directory. Right now >> this means "xdgdata-apps" in addition to standard KDE service >> locations. > > I'm doing something like this in gnome. ATM its just doing 1 and 3. What > is the common usecase for 2? Note, that my changes don't affect general > launching of desktop files in things like the menus, only those from the > file manager, and only for application launchers (not e.g. uri links). > > Furthermore, I'm also doing: > 4. Don't allow sniffing of desktop files, always require a .desktop > extension. > 5. For untrusted desktop files, don't show the custom icon and display > name specified in the desktop file. > > With this in place you can always detect when something weird is going > on by seeing the ".desktop" file and the standard icon for a launcher > instead of a faked icon/name. > >> If the file is made executable automatically it is given a >> "#!/usr/bin/env xdg-open" header as well if it did not already have a >> #! header so that running the file from the command line will do the >> right thing. > > While this is a "neat trick" I don't really think its a good idea. > First of all it will conflict a bit with mimetype sniffing (of course, > this is disabled in the common file case as per above, but its useful in > e.g. a text editor for selecting syntax highlighting rules). It's dangerous not to. If it's marked as executable, and you execute it, it will try to be parsed by bash. Most of the time this will just generate lots of "file not found" errors as bash tries to understand it, but it seems pretty dangerous to rely on this! > > Secondly, I've never ever heard any request for being able to launch > desktop files from other places, and in fact if we believe there is a > (small) risk in executing desktop files, why do we want to unnecessarily > enlarge the scope of this risk? > > And Thirdly, spawning via xdg-open is generally not a good way to handle > desktop files. That way you can't e.g. apply startup notification, focus > stealing prevention, file argument expansion, etc. There is also the > risk that some app will accidentally launch the desktop file by spawning > a lot of unnecessary stuff instead of just using the right APIs to > launch desktop files that handles the stuff I listed. > > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon names vs. emblems
2008/7/11 Matthias Clasen <[EMAIL PROTECTED]>: > On Fri, 2008-07-11 at 14:19 -0400, Rodney Dawes wrote: > >> > > The central point of my proposal is to give the implementation some hint >> > > that the requested icon may be constructed from an icon plus emblems, in >> > > a way that does not involve any new APIs or mechanisms, just a naming >> > > convention. > I think file+symlink+unreadable would work ok. Leaving the details of > how to handle multiple emblems up to the renderer implementation. I really like the Matthias's idea of just having the naming scheme extended to add emblems. My only concern is that you can't specify where the emblem goes. This could be important for consistancy. For example, I'm interested in adding svn emblems for files. This would look nicest if the svn emblem is always in the same position John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: thumbnail mtime, ctime
On 27/03/2008, Dr. Michael J. Chudobiak <[EMAIL PROTECTED]> wrote: > Hi all, > > The thumbnail spec requires the embedding of mtime (with 1 second > resolution), and the use of mtime as the change-detection parameter. > > Unfortunately, the 1-second resolution causes problems sometimes (a file > can change twice in a second!), and the use of mtime means that > permissions changes do not trigger a re-thumbnailing. Both of these are > "real" issues that do occur. At the risk of stating the obvious - couldn't we just wait one second before generating the preview? This seems to be by far the easiest solution, and I don't think anyone really cares if they have to wait a second for the preview. You could even check what the system time is and then just sleep for the remainder of the second, which would be 500ms on average. This seems to be a far more practical solution, no? John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: DBus server for keyboard layouts
Hi Sergey, Could you please give an example of an app that would need to change the keyboard layout? I still don't get the usecase here sorry John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [XESAM] Ontology snaphot. Important proposal.
Hi all, First time caller, long time listener... :-) At the risk of being stupid, from this diagram audio files have frameRate and frameCount info, no? This doesn't seem right. Also I'd like to see a lot more fields for Video (video name, description, year, etc), but I guess that's up to other apps or something to extend that? John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: New Version of the Clipboard Specification
There is a restriction that apps cannot modify the clipboard if the user unselects something. Programs like Excel in Windows remove data from the clipboard when you unselect them. presumably there is a good reason for this sort of behaviour. Is there a good reason to say applications MUST NOT modify the clipboard if the user unselects something? If there's no technical reason, maybe downgrade this to SHOULD NOT? John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: HALd configuration
Remove all entries for it from /etc/fstab, then run pmount /dev/sdc1 (or whatever) then pumount and post the results. On 02/01/07, James Lockie <[EMAIL PROTECTED]> wrote: I have a Seagate ST380817 (80 GB SATA) in an external Mediasonic HD2-SU2 (USB hard drive enclosure). It works in Linux but I can't unmount it as a user. KDE/HAL mounts it as root. A hack solution is to add an /etc/fstab entry. I'd rather fix the HAL configuration to let users unmount it. My USB memory key mounts and unmounts fine as a user. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: simple search api (was Re: mimetype standardisation by testsets)
At the risk of stating the obvious, but why not just use SQL? select files.filename from files,tags tag1, tags tag2 where files.id = tag1.fileid and files.id = tag2.fileid and tag1.key="artist" and tag1.value="foobar" and tag2.key="group" and tag2.value="audio" It seems that all the API is reinventing SQL. Why not just use SQL in the first place? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Standardized playlists?
A common play list format is m3u: http://en.wikipedia.org/wiki/M3U But there are quite a few others: http://gonze.com/playlists/playlist-format-survey.html JohnFlux ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Touchscreen
Anyone fancy helping me write a touch screen device driver? I need to reverse engineer the init code for a windows 98 touchscreen driver. I used to reverse engineer many years ago, but I've kinda lost touch. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared-mime-info 0.17
Hi Bastien, > Huh. It's a software announcement. Pretty much every Free Unix desktop > project uses it, and distros and users should probably all upgrade to > that version... Okay. You know that. Most people here know that. Yet if you go to http://freedesktop.org/wiki/Standards it's under: "Draft specifications that are new and not yet widely used, though they may be used by one or more desktops or desktop applications:" With no indication anywhere whether everyone uses it or nobody uses. What would be really nice would be to state: * Which version of gnome uses/supports this * Which version of kde uses/supports this * Any other relevant apps And to move it under the title "draft specifications" Thanks ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Allowing apps to install packages
Hi, If an app wants to install some files from the distro's repository, is there currently any projects to try to allow that? For example, in a KDE app we may want to install a certain set of files. What would be useful would be in a distro-independent way to say "install japanese_language_pack" for example. Then it would be up to the distro's to provide some mapping from "install japanese_language_pack" to running their gui package manager, asking for root password, and installing it. Is there such a project already underway, or should I start one? Thanks! John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Allowing apps to install packages
Hi, If an app wants to install some files from the distro's repository, is there currently any projects to try to allow that? For example, in a KDE app we may want to install a certain set of files. What would be useful would be in a distro-independent way to say "install japanese_language_pack" for example. Then it would be up to the distro's to provide some mapping from "install japanese_language_pack" to running their gui package manager, asking for root password, and installing it. Is there such a project already underway, or should I start one? Thanks! John ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
