Re: [RFC] X-Content-Rating key for .desktop files.
On Mon, Dec 5, 2011 at 1:09 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: They also have a vocabulary of more specific rating labels (Mild Language, Nudity, Intense Realistic Violence etc.) without falling into the trap of trying to define which orthogonal labels are more or less adult, or which label should produce which age rating, both of which vary by culture. Same is true for PEGI: they offer a generic label (18) with additional content information being provided by a set of icons (drugs, violence etc.). -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared mime info: URI scheme handlers for non browsers
On Mon, Oct 17, 2011 at 8:23 PM, Scrool scroo...@gmail.com wrote: I'd like to ask you for clarification of URI scheme handlers section in Shared MIME-info Database spec. Quote from last paragraph: Note that this virtual mime-type is not for listing URI schemes that an application can load files from. For example, a movie player would not list x-scheme-handler/http in its supported mime-types, but it would list x-scheme-handler/rtsp if it supported playing back from RTSP locations. a) Let's have a video player that uses HTTP to download a movie and its subsequent play. This player should not register x-scheme-handler/http, right? b) Another video player that uses HTTP as a transport protocol for video streaming. This player may register x-scheme-handler/http? Claiming to handle x-scheme-handler/http is basically saying I can handle anything that you throw my way as long as it's HTTP. That includes regular web pages so I guess the answer is that no media-specific application should ever register for a generic protocol. -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, Sep 22, 2011 at 1:42 PM, Jannis Pohlmann jan...@xfce.org wrote: On Thu, 22 Sep 2011 02:07:11 -0500 Federico Mena Quintero feder...@gnome.org wrote: IMHO that's a bad idea. Bypassing DE-specific checks and forwarding straight to the FileManager1 service means that, on a multi-user system with multiple file managers installed, people may easily end up launching file managers other than the one they expect to see. I second that opinion. It would be more trivial to propose a new MIME type, say inode/x-reveal-file, that would be resolved by xdg-open when requested to reveal a file in a suitable management interface. -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Fri, May 20, 2011 at 11:14 PM, Kevin Krammer kevin.kram...@gmx.at wrote: For interfaces that many applications could provide and which might differ on a per-user basis due to personal preferences, an alternative mechanism to D- Bus activation will have to be provided. You don't need D-Bus activation. It's enough for an app like gnome-settings-daemon to listen on the interface and run the preferred file manager. -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
On Mon, Feb 21, 2011 at 10:31 PM, Pierre Wieser pwie...@trychlos.org wrote: Well, I used to believe that autotools were rather useful at compile time. What I am searching for here is a runtime check, and I thought this was the meaning of the Desktop Entry keys OnlyShowIn, NotShowIn ? I cannot suppose that having compiled my application under, say, Gnome, it will actually be executed under the same desktop. Or should I ? Matthias meant to say that autotools don't check for a defined environment (like Foobuntu 10.4 32-bit), instead it checks for various features it uses. This is not a suggestion to use autotools but rather a suggestion that if you for example wanted to talk to the session manager, check which of the known session managers is on DBus rather than checking if the desktop is running KDE4 or GNOME3. -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] XDG_RUNTIME_DIR
On Tue, Nov 9, 2010 at 2:38 PM, Thiago Macieira thi...@kde.org wrote: All one needs to do is get both the wall clock and monotonic clock values and compare the difference to the last difference computed. If there was a considerable jump, skip this cleaning up. A more robust solution would be to accumulate detected clock jumps (pairs of mono_clock, rtc_offset) along the last 12 hours of monotonic time, adding and dropping them as they appear and fall out of the scope. You can then calculate a more or less precise rtc value corresponding to 12 hours of CPU time ago. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] XDG_RUNTIME_DIR
On Wed, Nov 10, 2010 at 12:01 AM, Lennart Poettering mz...@0pointer.de wrote: Note that XDG_RUNTIME_DIR needs to be implemented in some lower-level part of the OS anyway (e.g. on Linux: systemd). Why systemd and not for example ConsoleKit - a standard component of a desktop machine? -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Screenshot key
On Mon, Aug 2, 2010 at 5:06 PM, Lasse Kärkkäinen ljkar...@cc.hut.fi wrote: Games normally use either F11 or F12 but since F11 is the full screen toggle in many application programs (and less often also in games), it would seem that F12 is better. The PrintScreen key cannot be used precisely because desktop environments often reserve it for their own screenshot applications. F11 and F12 are often hard to reach (2- or 3-key-combo) or totally nonexistent on small factor devices like netbooks. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop entry proposal: TerminateSafe=true key
On Mon, May 10, 2010 at 3:55 PM, Colin Walters walt...@verbum.org wrote: On Mon, May 10, 2010 at 8:03 AM, Lubos Lunak l.lu...@suse.cz wrote: Desktop files contain information relevant for launching applications. What you describe is for when they are running and as such .desktop files is not a good place for it. Do you have an alternative suggestion? I do. Add it to the toolkits. Let GTK+/Qt detect the platform and map it to oom_adj or ignore it altogether. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop entry proposal: TerminateSafe=true key
On Fri, May 7, 2010 at 4:49 PM, Colin Walters walt...@verbum.org wrote: On Fri, May 7, 2010 at 10:38 AM, Lennart Poettering mz...@0pointer.de wrote: oom_adj is a way to make the OOM killer smarter. So far only very few apps set that, but we certainly could change that. I think asking application authors to patch their apps to use that interface is a lot less nice than say asking them to add this key, and then if we decided that using the extant oom_adj kernel interface was the way to go, the desktop UI could set oom_adj when launching the app (after fork, before exec if it's inherited, otherwise take the small race condition and set it after invocation). I'd say write a gtk loadable module. Hmm, I am not aware that on Linux we have anything like a low-memory signal. Please enlighten me on that! We don't right now. There is no such thing as low memory. Ideally you should have 100% of the memory used at all times. For apps, their data, their buffers, disk buffers etc. You know you're low on memory when your malloc fails. Failing a malloc of 500M is not the same as failing a malloc of 4K. Kernel knows it's low on memory when it badly needs to allocate but there is not enough memory. It then goes berserk and kills apps. So tell me, why exactly do you want this to be duplicated in userspace? We can work out the exact details of how all the components interact after the fact. Asking a userspace app to do anything when allocating 1 byte of memory is likely to fail is a more polite way of just harvesting it with the OOM killer. Also, with multiple users logged in, which app should we ask? -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: base dir spec question.
On Thu, May 6, 2010 at 8:04 AM, Julien Danjou jul...@danjou.info wrote: Sander Jansen s.jan...@gmail.com writes: For my music manager I need to store a sqlite3 database file somewhere on disk. Which directory would be the most appropriate to use, the XDG_CONFIG_HOME or the XDG_DATA_HOME directory? Probably XDG_DATA_HOME, since I hope you're not storing configuration in a database. Not really. XDG_DATA_HOME is your local /usr/share and that's not place for databases. I'd say currently XDG_CONFIG_HOME until we get a proper local version of /var. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop Entry Specification - ExecuteAs proposition
On Tue, Mar 9, 2010 at 11:22 PM, David Faure fa...@kde.org wrote: But this forces a particular gui program (gksudo or kdesu etc.) whereas ExecuteAs=root is more generic (you get your desktop's usual gui-su-program rather than a hardcoded one). What if there isn't one? If a particular user is needed and that information is available at make install time, why not chown + suid the binary (or use a tiny helper in case of scripts). Also, would you trust a .desktop file that is owned by a regular user and includes Name=cherry.jpg and ExecuteAs=root? -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Wed, Dec 2, 2009 at 2:18 PM, Jakub Steiner jim...@gmail.com wrote: Hi folks! Over the past few years I sensed a need for a less 'noisy' and colorful style for graphical representation of certain actions and status. Blown up icons for on screen display when you increase brightness, attach a display, event notifications in the system tray, that sort of thing. Additionally GNOME has dropped using icons in menus as the huge number of colorful icons ended up creating visual noise rather than helping to aid the eye spatially. I feel like we've spilled the baby along with the bathtub there though. And working on the Moblin icon theme I've really grown to like its simplistic style, especially next to menu items -- http://dl.dropbox.com/u/24178/menu-icons.png To do it properly you'll need a glyph drawing mode for icons. https://bugzilla.gnome.org/show_bug.cgi?id=591698 -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Wed, Dec 2, 2009 at 3:36 PM, Martin Bagge / brother brot...@bsnet.se wrote: Bastien Nocera wrote: http://dl.dropbox.com/u/24178/osd/composited.png bluetooth-discoverable is useless I was thinking of mobile - there's curently no bluetooth status icons in the spec. Some netbooks include a bluetooth switch and on mobiles people usually toggle bluetooth for battery life. Why do you think it's useless? Because being on/off isn't what discoverable means. Just like the mute function is just sound being on/off? No, more like your IM status: offline / online / invisible. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: KNotificationItem specification - first draft
2009/9/10 Shaun McCance sha...@gnome.org: That said, I don't much care for markup suppressing markup. It doesn't work that way in HTML, and it certainly doesn't in XML. But is there a way to mark part of GMarkup as CDATA? -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: DBus properties naming rules
On Tue, Sep 8, 2009 at 12:53 AM, Aaron J. Seigoase...@kde.org wrote: On September 7, 2009, Matthias Clasen wrote: Why do you think properties should be treated like members ? This change would apply new restriction to property names that have the potential to render a lot of existing interfaces noncompliant, for very little gain. right now we have an inconsistency between one type of item available in an interface compared to all the rest. service names, methods, signals all have these restrictions on them and properties stand out as odd ducks. consistency is a good trait. It makes as much sense, as forcing Java (or C++ or Python or whatever) to use same case and format for class names, constants, functions, methods, properties, namespaces and local variables. ;) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trash spec: caching the size of the trash directory
On Fri, Aug 14, 2009 at 7:24 AM, PCManpcman...@gmail.com wrote: A potential problem of your proposal is, it's not backward compatible. A file trashed with an older file manager won't update this file. How to solve this? A conforming implementation might just check mtimes to decide if the cache is out of date. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Have a way to dynamically change software associations at distribution level
On Tue, Aug 4, 2009 at 12:16 PM, Francois Gougetfgou...@codeweavers.com wrote: defaults.list does not seem to solve that problem either... except by being a mechanism that is not used by KDE. But specifying that each desktop environment should use a different mechanism does not sound like a good ideag. I didn't mean to defent GNOME or criticize KDE, I just wanted to point out that we might need more than just a list of apps to try in order :) Maybe something like: X-Priority=10 ...could solve it? Then for example XFCE could multiply priorities of apps with KDE/QT in categories by 0.7 and priorities of XFCE apps by 1.5. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
On Sun, Aug 2, 2009 at 8:40 PM, Luca Ferrettielle@libero.it wrote: Let me assume that both KDE and GNOME are installed, choosing to use only Name, we'll have (html file, for example) Open with Firefox Open with Konqueror Open with Gedit Open with Kwrite Open with Emacs Open with OpenOffice.org Writer This way doesn't explain what the application does, users have to know this in advance. Choosing to use only GenericName Open with Web Browser Open with Web Browser Open with Text Editor Open with Text Editor Open with Text Editor Open with Word Processor That's not really point of the discussion but I believe we should be aiming at something closer to: View in web browser (Epiphany) View in web browser (Firefox) Edit in text editor ...where actions have meaningful names and you only see the app name when there's more than one candidate. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Notification spec issue: Ability to assign an icon *and* an image to a notification
On Wed, Jun 24, 2009 at 10:23 PM, Aaron J. Seigoase...@kde.org wrote: On Wednesday 24 June 2009, you wrote: What's wrong with keeping the current fd.o prefix if implementations are compatile? what wrong is that fd.o is a shared namespace. you can experiment within your own namespace all you want. using org.freedesktop means something, or at least should mean something, pretty specific: this is something we have consensus on and third parties can rely on it being use as such. when we simply play dog-pile-on-the-dbus, it creates a very uncomfortable situation where projects are faced with inconveniencing third parties or adopting technologies that do not fit their needs at all. worse yet, it creates races where one group will race to get their library pushed out with an interface on org.freedesktop, creating barriers to others working on similar things. Sure, this would all be valid had you reported these issues 5 years ago. Undoing the bad deed now actually is more evil than leaving things as they are. We'd be breaking 5 years worth of software just because we feel obliged to punish *someone*. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Notification spec issue: Ability to assign an icon *and* an image to a notification
On Wed, Jun 24, 2009 at 5:59 PM, Aaron J. Seigoase...@kde.org wrote: org.freedesktop.Notifications ... *sigh* sorry, but that's not acceptable. calling these Notifications is incorrect and will block future use of that name for a proper notification spec. it was a mistake for whoever decided it was a good idea to grab an org.freedesktop prefix in the first place without first establishing it as a freedesktop.org accepted and used system, and i don't think we need to reward that behavior at the cost of the platform. What's wrong with keeping the current fd.o prefix if implementations are compatile? This is XDG, where we agree upon things that we need to use in the real world, not W3C where other nice guys wonder what people might be doing in ten years from now. A de facto standard is better then a perfect specification with no implementations. Just make it clear that the API is subject to changes in the future until we all agree that Notifications are 1.0-stable. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Voting mechnism is needed for xdg discussion.
On Fri, Jun 5, 2009 at 4:49 PM, PCManpcman...@gmail.com wrote: Agree. A bug tracker with voting support will be good. However a forum is good, too. Using mailing list is convenient, but it's hard to follow all the issues in the mailing list. Besides, you don't know how many people agree with it. Without issue tracker, it's hard to know the current status of every issues since the wiki page are usually out-of-date. If you can't get people to react in a mailing list, you will get even less feedback using a website. Nobody will care enough to visit a forum on a daily basis. Following ideas is not an issue. Ideas get lost because nobody finds them interesting enough to follow. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Please standardize Screen saver DBus interfaces
On Tue, May 19, 2009 at 3:24 PM, Ali Abdallah al...@xfce.org wrote: Bastien Nocera wrote: Certainly not, using XSetScreenSaver means that if your app crashes, you'll end up with a disabled screensaver, instead of having the defaults restored. I'm speaking about XRestSceenSaver call periodically, not to disable the screen saver. Actually it would be easier to create a simple DBus daemon script for xscreensaver that used service activation and g_timeout_add_seconds to call XResetScreenSaver than trying to fix things that are not broken (forcing GNOME apps to call Xlib functions directly). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Please standardize Screen saver DBus interfaces
On Fri, May 15, 2009 at 9:59 AM, Brian J. Tarricone bj...@cornell.edu wrote: Further... you *don't* want a media player (etc.) calling Inhibit on the power manager. You want to tell the screen saver to stay out of the way for a while, but if the machine (for example) is critically low on battery, you probably still want it to go into sleep or hibernate mode to save your current state. That's not what I meant at all. What I said is that ideally the power manager should expose a way to disable powering down a certain screen, not inhibit the shutdown/hibernation. Notice I mean a certain screen, not all screens. There are setups when one of the monitors is used to display real time calculations or statistics while the rest can be safely turned off when session is idle. The power manager would internally use the information to grab necessary inhibits on the currently running screensaver interface. I don't see how we can achieve interoperability with inhibiting the screensaver directly as there are screensavers that don't support DBus at all and I believe it's easier to keep the necessary hacks in one place rather than teach each and every application how to inhibit all of the possible screensavers :) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Thu, May 14, 2009 at 8:58 AM, Jakob Petsovits jpe...@gmx.at wrote: On Wednesday 13 May 2009, Lennart Poettering wrote: Regardless whether a hostile fork is attempted or Rodney gives up the spec voluntarily, the problem is that we'd have to find someone else (who is credible) who would be willing to maintain the spec. Personally, I think the idea of a minimal icon specification is broken by design, this way we'll never get to themes that are usable cross-desktop. There are so many apps out there using their own icon names, and frankly, that's ok in many cases. True, I second that. Please see what happened to the idealistic CSS 2.0 specification. Then came version 2.1 where instead of making up an ideal way they instead documented what various browser were actually doing and supporting. It's better to have a non-ideal but complete list of icons that we can improve upon but that is already useful to new application and/or theme authors than to idle away indefinitely waiting for a perfect list. If I was starting to work on an audio app I could just use whatever names were listed at that point in time and update them as needed by following the list. Currently I have to come up with my own names, draw the icons and still follow the list in wait for a blessed solution (and then drop my icons and update names used in the code). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Please standardize Screen saver DBus interfaces
On Thu, May 14, 2009 at 1:36 PM, Ali Abdallah al...@xfce.org wrote: Hi, It seems that the screen saver interfaces and bus name are not standard yet! however i see this very important, since a media player shouldn't guess which screen saver is running on the current session in order to use its inhibit interface. Ideally it's the power management interface you use to inhibit a screen so this should be agreed upon instead. Screensaver is just one of possible implementation details of the power saving mechanism. And a pretty but useless one as it tends to actually drain more power ;) It should be up to the power manager to suspend the proper screensaver then (possibly including hacks or workarounds for xscreensaver that is not likely to get upstream support for DBus). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Please standardize Screen saver DBus interfaces
On Thu, May 14, 2009 at 3:39 PM, Thiago Macieira thi...@kde.org wrote: Em Quinta-feira 14 Maio 2009, às 13:45:41, Patryk Zawadzki escreveu: Ideally it's the power management interface you use to inhibit a screen so this should be agreed upon instead. Screensaver is just one of possible implementation details of the power saving mechanism. And a pretty but useless one as it tends to actually drain more power ;) Screen savers weren't created to save power. They were created to save screens from burn-in (see http://en.wikipedia.org/wiki/Screen_burn-in) :-) I am aware of their origin but that was back in time where turning on a monitor on took up to 5 minutes to let it heat up and ended around when old 15 LRNI CRTs died :) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG, xdg-open, and view vs. edit
On Mon, Mar 30, 2009 at 4:34 PM, Pat Suwalski p...@suwalski.net wrote: Daniel Bo wrote: That said, I wonder why the choice was to set a default application for opening when most file types have view and edit modes. Why are there not xdg-view and xdg-edit (or --edit and --view switches on xdg-open)? My opinion is that it's because most programs don't differentiate between editing and viewing. You start the program with a file parameter and then you can do anything. In that respect, you're Opening the file just like from the File-Open menu. While this is true you might need two separate applications for editing and viewing files. Also at times you might want to programmatically determine if there is a viewer/editor available (for example it does not make sense for an edit button to open a PDF file in Evince). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG, xdg-open, and view vs. edit
On Tue, Mar 31, 2009 at 12:58 AM, Rodney Dawes dobey.p...@gmail.com wrote: On Mon, 2009-03-30 at 19:25 +0200, Patryk Zawadzki wrote: On Mon, Mar 30, 2009 at 4:34 PM, Pat Suwalski p...@suwalski.net wrote: My opinion is that it's because most programs don't differentiate between editing and viewing. You start the program with a file parameter and then you can do anything. In that respect, you're Opening the file just like from the File-Open menu. While this is true you might need two separate applications for editing and viewing files. Also at times you might want to programmatically determine if there is a viewer/editor available (for example it does not make sense for an edit button to open a PDF file in Evince). Unless it's a PDF form, which you are editing... Think print / preview versus designer mode. It'd be pretty useful to -- say -- let Evince preview OpenOffice.org files while also including means to open the file for editing. Same for image previews and possibly other file types. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
On Wed, Feb 25, 2009 at 2:13 AM, Michael Pyne mp...@purinchu.net 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). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
On Tue, Feb 24, 2009 at 1:40 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On Tue, 24 Feb 2009 at 13:29:05 +0100, Alexander Larsson wrote: On Tue, 2009-02-24 at 11:13 +, John Tapsell wrote: 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! Really, even if there is no #!/bin/sh ? How does it know to pick bash as the interpreter for files like this? More accurately, /bin/sh will try to parse it (executable files that have no #! and no magic number recognised by the kernel are executed with /bin/sh). /bin/sh happens to be bash on most distributions, at least by default (but is dash on Ubuntu and on some Debian systems). ...and pdksh in other places. What comes to mind is why would we want to use the executable bit for non-executable files? I don't want my shell to tab-complete commands that are not executable, be it .desktop, .mp3 or .foobar. If we absolutely need to use the +x flag, use it only if extended attrs are not provided or not available. 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. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
On Tue, Feb 24, 2009 at 3:23 PM, Thiago Macieira thi...@kde.org wrote: Em Terça-feira 24 Fevereiro 2009, às 15:05:04, Patryk Zawadzki escreveu: What comes to mind is why would we want to use the executable bit for non-executable files? I don't want my shell to tab-complete commands that are not executable, be it .desktop, .mp3 or .foobar. If we absolutely need to use the +x flag, use it only if extended attrs are not provided or not available. .desktop files of Type=Application are executable. We just need a suitable loader for them. For the record: even if we requrie this specific file type to be executable AND provide a binfmt launcher (please don't add the xdg-open shebang, it's an ugly workaround), it still does not solve much in the big picture. It's still perfectly possible to create a desktop file, mark it as executable then archive it and send it to your friend (naming it pr0n.tar.gz). I think the big picture needs marking files as safe in general, be it desktop files or Word docs with macros. Basically any kind of useful automation needs a sandboxing mechanism of some sort and we could try to aid ourselves using the extended attributes to do so. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
On Tue, Feb 24, 2009 at 5:20 PM, Alexander Larsson al...@redhat.com wrote: On Tue, 2009-02-24 at 16:45 +0100, Patryk Zawadzki wrote: For the record: even if we requrie this specific file type to be executable AND provide a binfmt launcher (please don't add the xdg-open shebang, it's an ugly workaround), it still does not solve much in the big picture. It's still perfectly possible to create a desktop file, mark it as executable then archive it and send it to your friend (naming it pr0n.tar.gz). Then they could as well just zip up a normal executable and name it something like porn.jpeg . At this level of behaviour its not really something you can protect against. It's much harder to pull off when you can't get the porn.jpeg file to display a generic JPEG icon. A desktop file allows you to fake both name and icon (also automatically translating the name according to user's locale!). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 1:48 PM, David Faure dfa...@trolltech.com wrote: On Thursday 15 January 2009, Sanel Zukan wrote: Implying previous, they are also non essential and should go with $XDG_CACHE_HOME, just because program generated them. No. A cache is something that can be deleted without bad side effects. Not at all. It's something that can be recreated, possibly taking a lot of resources, not something unneeded. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 2:49 PM, David Faure dfa...@trolltech.com wrote: On Thursday 15 January 2009, Patryk Zawadzki wrote: Not at all. It's something that can be recreated, possibly taking a lot of resources, not something unneeded. Yes, that's exactly what I meant. Therefore, desktop icons and window size and other settings indirectly changed by the user do NOT belong there. That's _exactly_ why they belong there :). There is no way a _computer_ can recreate such data on its own by means of any calculations. What constitutes a cache to me is a pile of data that could be recreated by the program if needed but keeping it around requires significantly less resources. Think temporary internet files or podcasts or your music collection's ID3 tag database or even a list of first 123456 prime numbers. Following your rationale I could argue that your spreadsheets and Word document should be kept in cache as the *user* is perfectly capable od recreating the data. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Thu, Jan 15, 2009 at 3:53 PM, David Faure dfa...@trolltech.com wrote: I think we agree, but we both sent ambiguous enough emails to misunderstand each other :-) You are of course 100% right. I misread the quotes in earlier emails and thought you were one to imply window size is not config :) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: D-Bus library is required
On Thu, Nov 20, 2008 at 2:10 PM, Nicholas Albion [EMAIL PROTECTED] wrote: Where can I get the source for libdbus-1-devel? I'm trying to compile bluez but get the following error: configure: error: D-Bus library is required http://dbus.freedesktop.org/releases/dbus/ -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
On Thu, Nov 27, 2008 at 7:39 PM, Ville Skyttä [EMAIL PROTECTED] wrote: Hi, I think the icon naming spec is lacking a generic binary MIME type icon. For example, recent shared-mime-info has set text-x-generic for a lot of file types that have nothing to do with text, I suppose because there's no better alternative available. And I guess this will result in an icon for text files being shown for quite a few binary files in some contexts, and being confused (Hey, the icon shows this is a text file, I have several text editors installed, why doesn't it open when I click it? or Why does this text file show only gibberish when I open it in a text editor?). How about adding let's say binary-x-generic: The icon used for generic binary file types. ...to the Standard MIME Type Icons list? How about application-octet-stream which is a standard MIME type? -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposed improvement to the Desktop Entry Specification: Relative icon paths
On Tue, Sep 23, 2008 at 10:01 AM, Magnus Bergmark [EMAIL PROTECTED] wrote: Proposed solutions I propose that we allow the user to specify a relative path to a file to use as an icon. How we do this is not really important, but I have these separate suggestions (ordered by how it should work, IMHO): Icon paths starting with a dot will be relative from the directory containing the Desktop Entry; the path ./folder_icon.png in /home/user/Documents/BookProject/.directory will set the icon to /home/user/Documents/BookProject/folder_icon.png. When no absolute path is specified, first search the containing directory before following the Icon Theme Specification. In the example above, we would have entered folder_icon.png and this file would have been found locally before searching for it and therefore set. Usage of some other prefix to denote a relative path, rules following the others Using a different setting, or a compliment to the setting (like Icon=..., IconPath=Relative), rules following the others What could also work: * if an icon name contains directory separators and starts with one, use absolute path * if an icon name contains directory separators and does not start with one, use relative path * if an icon name contains a dot (presumably extension), try relative lookup * if you reach this point, fall back to icon spec lookup -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
On Thu, Aug 21, 2008 at 10:20 AM, Adrien BUSTANY [EMAIL PROTECTED] wrote: I like the extended attributes too, they're clearly the cleanest way to store that information. In the case where extended attributes are not available, we cannot always use a hidden file in the folder, I'm thinking for example of a read only volume. In that case I think Dolphin fall backs to a central setting file, though I don't know the details. Central database comes at a price of an ever-growing file hidden somewhere in your filesystem. Also what happens if I try to save some settings for a CD or DVD? Does it remember the absolute path (bad) or the mountint point and relative path (equally bad) or does it try to get a GUID for the media (but not the drive as I can put the same disc into another drive at some later point in time)? I think supporting *saving* to read-only file systems is just not worth it (and can create confusion if people start complaining that they can customize the CD but it doesn't work when moved to another machine or that they can customize the looks but moving files around does not work). Just my 0.02 zloty (PLN). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
On Thu, Aug 21, 2008 at 5:12 PM, Adrien BUSTANY [EMAIL PROTECTED] wrote: OK, let's forget the read only media for now then... The only downside I see with hidden files is the following usecase : Tom uses windows, and gives his usb key to Sally Sally plugs the usb key into her linux system, and changes some sorting properties. The file manager creates a .directory (or whatever it's called) file on the usb key. When Tom gets the usb key back, he sees lot of dot files, and doesn't know what they're about. I don't know if dot files are automatically marked as hidden in the FAT sense when using a FAT fs on Linux... How do we address that ? There is a hidden attribute that should be used on filesystems that support it :) -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
On Thu, Aug 21, 2008 at 6:36 PM, Adrien BUSTANY [EMAIL PROTECTED] wrote: Clearly we need a lib to abstract that. We also need to make that lib totally desktop independant... And also I'd really be happy if we reach a point where the solution we choose can be defined as a standard (that was my initial point). I guess that implies that there should be more than two people participating in this discussion :-) Maybe a blog article would be a good way to get people into the discussion, but I don't have a blog :-s I think it would be enough to make gio/gvfs/kio preserve the attributes (all attributes, not only the folder related ones) when copying/moving files and directories (and to create fallback files when the need arises). High level apps can then just use the gio/kio calls to manage the attributes and the storage mechanism is abstracted away. That should be standardized and agreed upon first. Only then we can start thinking about higher level standards like folder view-specific attributes or MIME-type storage. Of course apps not using the vfs apis will likely break the attributes but they fall out of scope of the specification (and they also break stuff on OSX). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
On Thu, Aug 21, 2008 at 12:22 AM, Adrien BUSTANY [EMAIL PROTECTED] wrote: Hi, this is my first post to the list, so hello everyone ! I've been lately developping an extension for a file manager which uses emblems on folders to mark their relation with a project. I searched for a standard for per directory settings but didn't find one. My problem is with emblems, but the same goes for custom icons, custom sorting, or even localized names etc. I think the freedesktop world could really benefit from a standard addressing this concern, if it's well thought of course :-) This mail is hence a call for brainstorming, here are a few starting points : - For each folder that has custom settings, store a hidden file with the settings inside. That's what Dolphin, and the Finder on Mac OS X does. - Store all the custom settings in a centralized file, most likely in the home user directory (possibly in .config). I guess that what Nautilus does for emblems, although that needs confirmation. What do you guys think about that ? Do you have a better answer ? Am I posting to the right list ? :-) Store it in extended attributes and fall back to hidden file when moving to media that does not support them (archive, teh internets, fat) and reinstantiate the attributes when moving back (I believe that's what OSX does in most of the cases and as a bonus it saves you a bunch of stats). -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: menu-spec URL entries
On Wed, Aug 13, 2008 at 8:21 AM, Brian J. Tarricone [EMAIL PROTECTED] wrote: Not that I fundamentally disagree; I see no reason why Link items shouldn't be allowed in menus, aside from just increasing complexity of the implementation (which is generally pretty damned complex as it is). Well I do. XDG menus are task-oriented and sticking 666 limited offer!!!11!one install bundled app links per app into there is a bad idea. And that's what ISVs use the link entries for. Documentation should be accessible from the application itself so no separate entry there. Ditto for homepage. -- Patryk Zawadzki ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Sound naming spec: problems with prefixes
On Thu, Jul 17, 2008 at 3:29 PM, Bastien Nocera [EMAIL PROTECTED] wrote: I've targetted 30-odd sounds (including the bell) to be user modifiable in the preferences: I hope by modifiable you mean being able to turn them on or off not setting the sound file to use. It would be an overkill. 99% of users either disable all desktop sounds or just want them to work. They're not going to spend days searching for a perfect burp sound to go with their windows closing. And if they do, they'll probably rip it off of some other theme thus learning how to make a custom sound theme as they go. Cheers :) -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Sound naming spec: problems with prefixes
On Fri, Jul 18, 2008 at 12:16 AM, Bastien Nocera [EMAIL PROTECTED] wrote: No, being able to change a few of the sounds is what's planned. Looks a bit like the attached screenie. What sounds can you choose from? Any file from the filesystem (ugly) or just sounds from the selected theme (limited functionality)? Does the sound theme automatically change to custom? I think it should work in a similar way to the desktop themes (or be part of it) not to cause further confusion. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon names vs. emblems
On Tue, Jun 17, 2008 at 12:35 PM, Jakob Petsovits [EMAIL PROTECTED] wrote: Also, what should happen if there are more emblems required by the application (say, folder+encrypted+important+favorite)? When that verbatim icon does not exist, will the icon engine look up folder+encrypted+important, then folder+important+favorite, then folder+encrypted+favorite, then folder+encrypted, then (...continue ad infinitum)? Or will it just try once for the full name with all emblems and immediately fall back to single icons when that one doesn't exist? (Personally, I'd prefer the latter variant in order to save hard disk lookups for an unprobable case.) I'd prefer to require +fragments to always be sorted alphabetically. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: $HOME/.config/ Directory Not Specified in FHS
On Wed, May 28, 2008 at 10:05 PM, Daniel Yek [EMAIL PROTECTED] wrote: Hi, The purpose or usage of $HOME/.config/ directory are specified in XDG Basedir Spec., Desktop Menu Spec. Shared configuration system Spec., and used by xdg-user-dirs utility. (See Resources below.) It (~/.config/) is not included in the FHS spec. though. I'm confused. What does FHS have to do with your $HOME dir contents? Also please note that XDG config dirs and XDG user dirs are meant to be configurable (and the latter are usually translated). FHS is there so third party vendors and application authors know what to expect and where to look for various resources. No package will ever place any files in your homedir at installation time (and can't know it's place as your user login is not part of FHS either). -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [Icon-Naming-Spec] New icons proposal
On Tue, May 6, 2008 at 1:44 PM, Richard Hughes [EMAIL PROTECTED] wrote: On Tue, 2008-05-06 at 13:08 +0200, Stephan Arts wrote: system-suspend system-suspend-hibernate system-reboot No, please use: system-suspend system-hibernate system-reboot Hibernate is a special case of suspend. The latter is either suspend to ram or suspend to disk. system-suspend-hibernate provides a nice fallback scheme where system-hibernate does not. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Tue, Mar 4, 2008 at 8:35 AM, Thiago Macieira [EMAIL PROTECTED] wrote: Patryk Zawadzki wrote: Havoc, would you see that as a viable change? I do have a question, though: what does registering the session bus address with CK buy you? What are the advantages over the storing in the X11 Window? The use case I mentioned earlier in the thread: beaing able to ask CK for all existing session buses and say try to send a critical message to all active notification-daemons (say, machine will reboot it 2hrs or maintenance mode, some services will be down) or just those belonging to members of some specific admin group (warning, printing spool seems stuck). It would be more or less trivial to implement if CK could provide such information (protected by some PolicyKit policy) and I believe such information really belongs to ConsoleKit as it is *the* session tracking service. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Tue, Mar 4, 2008 at 10:48 AM, Thiago Macieira [EMAIL PROTECTED] wrote: On Tuesday 04 March 2008 10:24:57 Patryk Zawadzki wrote: It would be more or less trivial to implement if CK could provide such information (protected by some PolicyKit policy) and I believe such information really belongs to ConsoleKit as it is *the* session tracking service. I don't agree. For me it seems the most natural place to store the session information is *in* the session. That's the X11 window. No need for reaping: if the session goes away (X11 connection closed), the information automatically goes to the limbo as well. However, having a registry of all available sessions would bring back some functionality of DCOP we lost during the switch. Except you still can't connect to any other user's busses. (Not having enough time now to reply to your message as a whole) It shouldn't be hard to change your effective uid before connecting to the specific session and it's not likely that anyone but root (or some suid helper for - say - copying clipboard contents between two sessions) would ever need to connect to other sessions (it would be insecure to allow anyone to do so). Such actions would require a push instead of subscription in order to work and in many cases would not be safe to be broadcasted using the system bus (like the mentioned copy foo between sessions case as foo could be something confidential). Another solution would be to broadcast a signal telling please establish a private bus connection but that's so much harder to do properly. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Tue, Mar 4, 2008 at 11:22 AM, Thiago Macieira [EMAIL PROTECTED] wrote: If it is confidential, you do *not* want to use the session bus. You want to keep everything in the system bus or use a separate data mechanism. As for clipboards, let's not reinvent the wheel. Use two X11 connections instead of transferring the data over D-Bus. Agreed, clipboards are not a good example. I was just wondering about possible gains of having a central registry for user sessions. Not going to defend that idea with my life for sure ;) -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 11:11 AM, Patryk Zawadzki [EMAIL PROTECTED] wrote: On Feb 16, 2008 9:25 AM, Thiago Macieira [EMAIL PROTECTED] wrote: Making dbus-launch talk to ConsoleKit wouldn't be that difficult. And it would require no changes at all in libdbus-1. Right, if you place the code in dbus-launch it can just give you back what CK knows or fallback to X storage instead of launching a new process. But I must warn against per-user instead of per-user-and-session busses. Many applications will simply not work correctly if the session bus spans multiple desktop sessions. No, I already agreed with Havoc that this wouldn't have any extra benefit and would be a pain to maintain. Given that CK knows which session goes where, it would be possible to talk to other session buses of the same user anyway, a simple GiveMeMyOtherBuses() DBUS method would be enough. Havoc, would you see that as a viable change? -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 9:25 AM, Thiago Macieira [EMAIL PROTECTED] wrote: D-Bus has an autostart mechanism already. If it can't find the environment variable, it'll run dbus-launch --autolaunch and expect that one to find the address correctly. Right now, the only mechanism is storing the address in an X11 property in Window held by the watchdog process. (There's a copy of said address in $HOME/.dbus/session-bus/$MACHINE_ID-$DISPLAY) Making dbus-launch talk to ConsoleKit wouldn't be that difficult. And it would require no changes at all in libdbus-1. Right, if you place the code in dbus-launch it can just give you back what CK knows or fallback to X storage instead of launching a new process. But I must warn against per-user instead of per-user-and-session busses. Many applications will simply not work correctly if the session bus spans multiple desktop sessions. No, I already agreed with Havoc that this wouldn't have any extra benefit and would be a pain to maintain. Given that CK knows which session goes where, it would be possible to talk to other session buses of the same user anyway, a simple GiveMeMyOtherBuses() DBUS method would be enough. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: tango.freedesktop.org
On Sat, Aug 25, 2007 at 12:35 AM, James Pooton [EMAIL PROTECTED] wrote: http://tango.freedesktop.org/ has been down for a couple weeks now with a database error: Tango Desktop Project has a problem Sorry! This site is experiencing technical difficulties. Try waiting a few minutes and reloading. (Can't contact the database server: Access denied for user 'tangomw'@'localhost' (using password: YES) (127.0.0.1:13306)) Is it gone for good or is there someone to contact ?? Just refreshed it a couple of times and all seems well. Been visiting it several times in the last few weeks. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: tango.freedesktop.org
On Fri, Feb 15, 2008 at 11:51 AM, Thiago Macieira [EMAIL PROTECTED] wrote: Don't reply to emails from August :-) The freedesktop.org mail server seems to be spewing some old emails every now and then. Be careful. Oops. *goes to a corner and dies* -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 2:38 AM, Patryk Zawadzki [EMAIL PROTECTED] wrote: This would allow new scenarios like logging in remotely using ssh and checking the printing queue that was started before leaving or using remote graphical login to fiddle with some other user service that was already started. Also imagine being able to send desktop notifications to all logged in members of administrators group or to the currently active sessions (this would be trivial as at this point CK already knows the socket name and magic cookie needed to connect so its a matter of allowing root to fetch that info). -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 2:28 AM, Brian J. Tarricone [EMAIL PROTECTED] wrote: Patryk Zawadzki wrote: Would it make sense to have a per-user bus aside from the session bus? The session bus *is* per-user. Well, assuming the user is only logged in once, which is probably a safe assumption, no? The desktop environment/X init script/whatever is responsible for starting it when X is started. Actually it's per session and in case your session dies (should not happen but does) or in case where one client goes frenzy and does not exit you end up with 10 or so dbus instances. Having it started by ConsoleKit would remove the burden of having to start it in Xinit and would allow CK to notify dbus when the number of client sessions changes (so it only dies if there are no connected clients and no active sessions). This would allow new scenarios like logging in remotely using ssh and checking the printing queue that was started before leaving or using remote graphical login to fiddle with some other user service that was already started. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 2:50 AM, Havoc Pennington [EMAIL PROTECTED] wrote: Implementation could be as easy as asking ConsoleKit for the magic cookie (if there is no daemon, spawn one). It would also allow ConsoleKit to tell the daemon when the last session disappears as it already tracks seats and users. Not sure how to make service activation work in such a scenario. Maybe more importantly, I think two buses (system and session) is complicated enough. Adding another one would be a mess. Ok then. Replacing the session bus with (user,machine) bus would be very bad; Agreed. What about asking CK to spawn a new session instead of doing it directly? In case ENV is not set, just ask CK (still would allow system session daemons to poll local buses from CK and do stuff like push notifications to local user session services). Would also remove the need to push more and more stuff into Xinit (same applies to ssh- and gpg-agent and really any global agents that refuse to use dbus). -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: User bus?
On Feb 16, 2008 3:48 AM, Brian J. Tarricone [EMAIL PROTECTED] wrote: Patryk Zawadzki wrote: See 'man dbus-launch', specifically the --exit-with-session option. That should cause the session daemon to quit if X exits. Sure but it sometimes fails (for example X segfaults). Having it started by ConsoleKit would remove the burden of having to start it in Xinit and would allow CK to notify dbus when the number of client sessions changes (so it only dies if there are no connected clients and no active sessions). This would allow new scenarios like logging in remotely using ssh and checking the printing queue that was started before leaving or using remote graphical login to fiddle with some other user service that was already started. This somewhat highlights what IMHO is one of the worst things about dbus: its reliance on environment variables to tell clients how to contact the session bus. If CK starts the session bus, how do the appropriate env vars propagate into the desktop session? You could solve this by having CK start the session as well, but that sounds like a bit of a big change, no? Just make the dbus client library ask CK and cache the values instead of relying on ENV variables. I agree that any program relying on ENV variable propagation is broken in 2008. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Default Program | File Association
On Jan 29, 2008 6:30 PM, Mhall [EMAIL PROTECTED] wrote: Alternatives don't work for this: * we need a _list_ of default applications, so that when one is not available (removed, wrong desktop, cannot start, etc.) we pick the next one in the list I'm pretty sure you can get that from alternatives. Alternatives is a huge filesystem mess that many distros would deny to implement (including me personally). It also does not solve the problem of ordering entries nor does it allow per-user preferences (as opposed to per-machine). To go even further, none of the proposed solutions solve the problem of working on multiple remote machines without having to reconfigure each of them manually but I think we can skip that part. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Address Book
On Jan 28, 2008 3:24 PM, Luka Čehovin [EMAIL PROTECTED] wrote: I am not thinking about bloated stuff like Evolution or some specific desktop environment related solutions (I think KDE has something like that but i am not sure) but a small daemon that would manage users contacts and provide them to other applications ... regardless of the desktop environment. What about evolution-data-server? It's more a part of GNOME than Evolution (even clock applet uses it). Check pimlico Contacts for an example client. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: standard dependancy system
2007/12/11, James Richard Tyrer [EMAIL PROTECTED]: Yes You have correctly stated the problem which XDG needs to address and solve. If 3rd party (commercial) applications are to succeed for Linux based systems, there must be a way for them to install on any system using at the most an RPM and a Deb package (or a Deb the can be converted with Alien). That's no problem, just depend on file names instead of package names or compile statically. Note that any system should work with both Deb and RPM packages and also with libraries installed from source (or at least those that have an *.pc file) or other install system. IAC, it would be good for the system to actually look at the system to see what is installed rather than just relying on a data base. This is where we disagree. Admins are responsible for keeping their systems tidy, having multiple libraries installed from sources is very likely to affect other applications without giving them a way to express this (this is what package dependencies do). Also compiling new software might lead to undesirable results (*.so linked from version 1 while *.pc from version 2 and similar) that in turn destabilise the whole system. If third party vendors want their software to install nicely, it's just a matter of asking packagers. Please reply to the list. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: standard dependancy system
2007/12/11, Nicolas Mailhot [EMAIL PROTECTED]: Le Mar 11 décembre 2007 15:12, Patryk Zawadzki a écrit : 2007/12/11, James Richard Tyrer [EMAIL PROTECTED]: Yes You have correctly stated the problem which XDG needs to address and solve. If 3rd party (commercial) applications are to succeed for Linux based systems, there must be a way for them to install on any system using at the most an RPM and a Deb package (or a Deb the can be converted with Alien). That's no problem, just depend on file names instead of package names or compile statically. The infrastructure needed to rebuild packages for a set of distributions is not overly complex (if sources are well-behaved with automake-like magic). It's much easier to build different packages for different distributions than to try to produce one-size-fits-all packages. What I meant in the above quote was programs that only come in executable format with no sources provided. Actually a better way would be to provide distributions with precompiled object files and let us do the linking with proper versions of libraries but that is prone to sniffing symbols. Distributions routinely build different versions of the same package for different releases. People like ximian used to produce different sets of packages for different distros. The OpenSUSE build service does the same nowadays. Sure, I totally agree and that's what I was trying to point in the part you didn't quote. Packagers already do a good job here and if the process does not involve magic I can happily package software without needing to read any part of the source code except for the dependencies. The whole there needs to be a way to produce universal packages and fragmentation will kill Linux or commercial Linux software has always been completely false. Totally agree. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Autostart spec needs ordering
2007/12/10, Jim Ramsay [EMAIL PROTECTED]: I think the autostart spec needs some way of forcing one .desktop to start only after another one has completed. For example, seahorse-agent requires that a ssh-agent be already running. No longer true for new seahorse which contains a full fledged SSH agent. Also, agents are usually started in X session, not by desktop autostart (as they tend to set a lot of global environment variables in order to work properly). -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG base exec paths
2007/11/27, Kai-Uwe Behrmann [EMAIL PROTECTED]:
Now to the right list:
In danger of defining a new file hirarchy, I would first like ask how
would it be appropriate to place binary plug-ins for a system wide
service.
Both system side and user side plug-ins should be supported.
My first take was to extend the OpenICC Directory Proposal to include as
well binaries, but found the XDG paths document[1] does not mention
binaries.
What do you need user-side binaries for? Running them from a system
service would result in giving the binaries root privileges.
Any hint would be welcome.
All binaries should go to either $prefix/bin or $prefix/lib{,64} -
these are the only directories guaranteed to be mounted with exec
rights and not shared across different architectures (as is sometimes
done for /$prefix/share).
--
Patryk Zawadzki
PLD Linux Distribution
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: standard dependancy system
2007/11/23, Stanislav Brabec [EMAIL PROTECTED]: Preparing thousands of packages, I am often thinking about a generic package description as well. I can imagine such standard dependency system one level lower: In the package source level. 1. Developers know all the dependencies of their software (both compile time and run time), which of them are optional and which of them are mandatory. 2. Developers exactly know, what benefits provide each particular optional dependency and they can recommend sub-package splitting. 3. Developers know where to download required software and which versions are compatible. 4. Developers know about special actions needed before/after installation of their software. 5. Developers know where to look for important crash and security fixes for released packages. 6. Developers know, which version is stable and what is the latest version URI. 7. Developers know the packaging paradigm used (i. e. how to compile and install it - automake based, perl based,...) 8. Packager does not know about any of the above and has to guess. All valid points but software is only maintained for as long as it's fun to do so. Adding additional requirements to software vendors is not the best approach until we give them tools to automatically check and prepare such info. The description shoud say us: - URLs of home pages of dependent packages. - Description of optional dependencies and optional features. - Description of pre/post install scripts and other special actions needed. - Propose package splitting. - Packaging paradigm (each vendor can define their own description, how to call ./configure ; make ; make install). - And yes, optional information can be provided. It could be a huge help for packaging automation. Agreed. I see that for example configure.ac already contain some of these information, but in a form, which is machine executable, but machine can not parse and understand it. You can do post-mortem analysis of config.log and try to guess, what was really needed. I can even imagine modification of automake to create part of such meta-description while calling ./configure. As a packager I usually grep .am/.ac files for dependencies but practice shows that versions there are about 50-50 accurate. Then come distros like RedHat where often versions of packages in distro do not match upstream versions because of huge effort put into backporting downstream. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: standard dependancy system
2007/11/22, Mildred [EMAIL PROTECTED]: Le Thu 22/11/2007 à 18:25 Thomas Leonard à écrit: On Thu, 22 Nov 2007 15:58:23 +0100, Mildred wrote: This is almost exactly how it already works (except that the URI for libpng is actually http://freenet-homepage.de/LinuxCNC/0install/Libpng/ libpng.xml). See: http://0install.net/ Yes, 0install might work like that (I never used it) but not everyone wants to use 0install and some prefer using the packages provided by the distributrion. The idea was more to provide a standard interface that would be customized by the distribution. Maybe this could be integrated in 0install somehow, providing hooks so the distribution may customize what happens when a resource is required. Do you think it is possible ? And do you think it is possible to make it widely accepted ? I'm afraid that the huge success of 0install (or rather lack of it) shows there is little to no interest in unifying the system. There are also various technical reasons including packaging rules, micropackaging and providing multiple versions of same software that would make impossible to pick the right thing across all distributions. If you need a proof just pick two RPM-based distributions and try to install packages from one in the other. -- Patryk Zawadzki PLD Linux Distribution ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/22, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]: Even if you want a map application for all regions, the application works on one region and one locale only. It's a problem the limited application is shown on other locales by defalt. It assures the application works on desktop on a locale but don't support the application is launched on other locales. technically users can modify .desktop but actual modifications are done under a support. I think showing a desktop item causes several senses; visibility, introduction of the major applications, desktop theme. If one locale wants to show a desktop to add the application into the major applications, the case would not be a simple integration for other locales. Dear lazyweb, my dog is two meters high and really likes me. The problem is it devours anyone speaking Japanese and decapitates native Russians. How do I hide those from my dog? You see, your problem is not the desktop spec, it's a broken application. If it only works for a certain locale then you need better software engineers, not a new standard :) -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/22, Takao Fujiwara [EMAIL PROTECTED]: Patryk Zawadzki さんは書きました: Why not fix the application in the first place? You don't have to translate it, just make it work properly. The application supports one locale. If we support some locales, we need to buy the locale data, then this couldn't be resolved in the software level. If we(Sun) say to support a locale, we need to provide the translation. No, you just call it Chinese Dictionary in the desktop file or Map of Japan or whatever name clearly states the language or locale involved. No software should ever change the content available to the user based on the current system locale. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/22, Takao Fujiwara [EMAIL PROTECTED]: Unfortunatelly it's not expected the application is shown on other locales. The application needs to be shown on a locale only in the menu and I'm finding the resolution. Still, if xdg agrees to your proposition and it goes upstream, it's subject to various abuse (and broken software) so I think you'd better find a viable workaround. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/18, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]: The problem is the ability to show the limited locales only by default installation. If this feature is implemented, your case is also covered, e.g. OnlyShowInLang=zh_CN,en_CN or OnlyShowInLang=zh,en But the default value is designed in the system supportability and it also has the extention for each request. Why? If I take my laptop to Japan it will still run in pl_PL locale but my demand for software might change. I strongly believe (and others seem they also do) that hiding an application from the user is doing him a bad favor. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/18, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]: Patryk Zawadzki wrote: Why? If I take my laptop to Japan it will still run in pl_PL locale but my demand for software might change. I strongly believe (and others seem they also do) that hiding an application from the user is doing him a bad favor. The users don't have the bad favor because the system is configured under the default configuration and it means the users are properly explained how to show the specific application when they change the locales. Why would anyone be forced to change locale settings in order to be able to use an application? Locales were implemented to give applications a chance of better integration with local customs. What if I happen to be a traveller type of person and 3 applications want me to change the locale to 3 different settings? Not to mention that while I would be capable of finding something on a map of Tokyo, I would most certainly not know the right words to switch the locale back if I switched my machine to jp_JP. I also know people who use different settings for different LC_* variables. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
2007/10/18, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]: Thiago Macieira wrote: Em Thursday 18 October 2007 14:11:38 você escreveu: Please note users can launch the application directly with the command line if they need. Not acceptable. If using the command line is acceptable for you, then you don't need to install the menu .desktop at all. And then we don't have this issue to discuss. The menu items need to be installed because the users need to use menus. I think it's a different topic to whether the users are given the command line or not. So what is the point of hiding an application from people using different locale? If it's called Chinese dictionary I can't imagine people complaining about it not being Korean. My point is - if people complain then the name is wrong, not the desktop specification. Change the menu entry title instead of hiding it. Good names are self-explaining names and lead to no errors. Imagine now that there are two applications that I need to use (for whatever reason). One only shows in the Brazilian Portuguese locale that I use and the other in Japanese. Can you give me a good reason why I should have to *choose* one of those to show up in the menu? Why can't I have both? You can show both to edit the .desktop files but the menu has the default settings which are required by the users. If you expect people to edit desktop entries before they appear then I think you don't need a desktop for your users, vim or emacs + bash will do ^_^ And if I can have both, why not simply show them for all locales? The situation is, whether the configuraters like it or not, the settings are needed under a contract and the application is expected to use on a locale. A service can provide the simple settings to show them for all locales. The configurator could easily right-click the menu, select edit and hide the entry for the rest of users. Or even use Sabayon (or any KDE counterpart) and do a global deployment. Also think of the principle of least surprise. Imagine that I have an application in my menu, but then I change my locale. It'll be a surprise to find out that the application has disappeared. How will I start it? It's not surpise because the user is explained. The first recommendation is to change the locale and if the change is not good under a condition, the system configuraters will provide the options. As the design, adding language in the .desktop can show the menu item. The user is not explained - average Jane in the street install software, enters menu and there is no sign of it. Her first thought is not oh, my locale is not in the file, better start vim but shit, it's broken. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OpenICC color data directory proposal
2007/9/27, Luca Cappelletti [EMAIL PROTECTED]: On 9/27/07, Kai-Uwe Behrmann [EMAIL PROTECTED] wrote: Hello, At a glance: base directories ~/.color I propose you to use: ~/.config/color so we start from freedesktop to really clean $HOME from all dotted files. .config is here out waiting us to be really populated in some way. I propose $xdg_config_dir/color ;) -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: thumbnail-spec: proposing nested thumbnail cache directories
On 9/7/07, Thomas Leonard [EMAIL PROTECTED] wrote: A better scheme would be to md5sum the name of the directory containing the image, e.g. thumbnailing a directory containing 'dog.jpg' and 'cat.jpg' would create/access: cache/763ab.../dog.jpg cache/763ab.../cat.jpg Thus you get all the images you need together in the cache. Also helps with deleting/renaming directories. And it also causes thumbnails to be regenerated each time you move the file around (and useless thumbnails persist where files were previously). I'm all for using the original proposition in this thread. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Bundles, a draft specification
On 9/2/07, Mildred [EMAIL PROTECTED] wrote: Hi, I sent a message a while ago on this list about bundles without having an answer. So I finally created a draft specification for this. http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Bundles.html http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Bundles/Bookmark_Bundle.html http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Bundles/Metadata_Bundle.html Please excuse the language ... See: http://www.gnome.org/~alexl/glick/ -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trusted vs Unstrusted MIME types
On 7/9/07, Rodney Dawes [EMAIL PROTECTED] wrote: One very important design heuristic that should be followed here is Always let the user feel in control. I'd rather word that differently. For me user in control means ignoring any messages and blindly clicking next. Been there, seen that. If the user doesn't feel like she can control what's happening, the software is going to be an annoyance more than an assistance. Inciting fear with a pop-up stating that a file might contain malicious code, for only a small subset of the possible files that might do so, doesn't actively make the situation any better. It will certainly teach users not to read any popup messages instead clicking allow as they would be unable to have any work done. Why not have magic matches for known malicious data in files, instead of just blanketing whole mime types? It's not possible inside web browsers and generally any software dealing with remote files (and these are the major threat). Sniffing contents might be either impossible (a large file that is either not fully downloaded yet or not meant to be downloaded at all in case the opening application wants to do it by itself) or very expensive (samba, webdav over Internet). Doing that would take care of even files we think we might trust, like JPEGs, without being overly intrusive in the UI, when not necessary. The JPEG case needs to be fixed in the application and not in the sniffer. Both would take the same amount of work. Because, really, by definition, any file not explicitly created by the user, should be considered as potentially unsafe. And even some files created by the user, should be considered unsafe, because we don't know if the software that created it is safe. That's what I said earlier in the thread. A file that does not originate from my machine is considered not safe. If I use Firefox to save it locally I no longer get any warning about its contents. I think to solve this properly we'd need a new filesystem with more extended attributes that follow the file (think of marked as safe) :) -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trusted vs Unstrusted MIME types
On 7/9/07, Rodney Dawes [EMAIL PROTECTED] wrote: I didn't say that the user should BE in control. I said the user should FEEL in control. There's a big difference there. If the user keeps blindly clicking next then they aren't in control. They are dismissing the annoyances that make them feel as they aren't in control. Then we agree here. It's not possible inside web browsers and generally any software dealing with remote files (and these are the major threat). Sniffing contents might be either impossible (a large file that is either not fully downloaded yet or not meant to be downloaded at all in case the opening application wants to do it by itself) or very expensive (samba, webdav over Internet). Anything is possible if you write the software correctly. We (at least in GNOME) already sniff files as they are being downloaded. I would rather download only part of a large file that has bad data, than waste time for the whole thing, to only later find out it's sending out e-mails to everyone in my address book. If we sniff partial downloads, we can then pause the download and inform the user of malicious files, before everything gets down the pipe, and they trash their system. If we just place the choice of fear on the user always at the start of download, we will either prevent them from getting the data they want, because of fear, or cause them to ignore fear, and just trash their system. Either way, the software is to blame. You sir are right here. The JPEG case needs to be fixed in the application and not in the sniffer. Both would take the same amount of work. All cases need to be fixed. But they can't be guaranteed to be. There is no way to guarantee that all users have all updates at all times. It's just not possible. And there is no way to make sure that the detection system is up to date. That's the same problem. I think to solve this properly we'd need a new filesystem with more extended attributes that follow the file (think of marked as safe) There really is no way to solve this properly. You can't know for 100% whether something is safe or not, until you run it. The absolute best we can do to check for safety, is to sandbox, sniff, and run. If a file marked as safe, is written to by a malicious program believed to be safe, then the file is no longer safe, even though it is marked as such. And presumably to mark something as safe, is something a user must do. At that point, you might as well just do nothing. Malicious users will mark malicious data as safe, if the meta-data is transferable with the file. You then still end up with the problem of having malicious data. My conclusion was based on the assumption that metadata is not transferrable via portable media or network sharing (these typically drop extended attributes and ACLs due to either not supporting them or extended metadata making no sense out of the context). -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: FUSE needs a way to set hints for file-management
On 7/9/07, Thiago Macieira [EMAIL PROTECTED] wrote: nf2 wrote: I wonder where/how such meta-information could be stored/retrieved... * mtab * config-files in $HOME/.config * /proc * getxattr One more option: * A file called .directory at the mount point path. Not all mounts are writable and some systems don't hide dotfiles (think NTFS-driven portable media) -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trusted vs Unstrusted MIME types
On 7/8/07, Thomas Leonard [EMAIL PROTECTED] wrote: On Sat, 07 Jul 2007 16:22:19 -0400, Christopher Aillon wrote: Thomas Leonard wrote: Christopher Aillon wrote: [ unsnipped ] Why risk a .desktop file which is wrong? Desktop files can be as wrong as a MIME metadata. The problem is I as an author know if my application ever evaluates any part of the unsafe data (like embedded macros, executing binary parts etc.) while you as the MIME metadata guard have little to no access to such information (there are tons of applications that parse certain MIME types). Paraphrasing your question: Why risk a user who is wrong? If you ask a user 10 times a day if he desires to open image/jpeg which might be unsafe, then he is guaranteed to click yes when you ask him about application/x-foo-malware. I'd propose an additional (and optional) line in Desktop files: UntrustedData=Allow|Ask|Deny With default being to ask. However the problem is when exactly does the data become trusted? If Firefox denies to launch a malicious shell script instead insisting on saving it to desktop, does double-clicking that new file make it safe all of a sudden? My point is, if you think that the application developer / packager will incorrectly state that their application is safe*, then they could just as easily state that the MIME type is safe too, which is actually worse because it affects other programs. Therefore, this isn't a good reason not to store this information on a per-application basis. * include standard all-software-has-bugs disclaimer here +1 to that. I'm requesting a list of MIME types known to be potentially unsafe, which already exists in epiphany's source code. I want each application that needs to use this to not have to keep track of their own list. Each MIME type is potentially unsafe. Even a simple notepad application could corrupt your memory due to a buffer overflow in line processing code. It's the application to decide if it's capable of having any side effects and thus ALTERING OTHER DATA (due to evaluation of macros or anything else) while processing this particular file. You need to understand that security is all about mitigating risks. Tagging the types mitigates risk compared to doing nothing, but it provides very poor quality information compared with tagging the applications, it seems to me. Perhaps I'm misunderstanding what you do with this data. Again, +1. What would the warning say? In the download manager, the download could be a different color, there could be an icon that would denote its status as potentially dangerous. Maybe when the user attempts to open from the download manager, it would pop up a dialog similar to what nautilus does when you try to open a shell script: foo.sh is an executable text file. Do you want to run foo.sh or display its contents? Anything besides text/plain is potentially dangerous. Image and PDF viewers have a long history of various exploitable overflows. A flashing GIF file could give you epilepsy and a hard-core pr0n flick could cause heart attacks on older people. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-mime query filetype|default
On 6/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The second issue is that I can't figure out how to associate mime-types with applications during software installation. My app has own data-files that I would like to register right away. The project also has some optional packages wth plugins. When those are installed I would like to install the xml-file with the mime-info (if type is not yet know) and associate more mime-types with my app, unless they are already assigned. In your .desktop file that goes to $prefix/share/applications put: MimeType=foo/bar;bar/baz; -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon theme spec inheritance
On 6/19/07, Oswald Buddenhagen [EMAIL PROTECTED] wrote: On Mon, Jun 18, 2007 at 03:40:56PM -0700, Brian J. Tarricone wrote: The default private icons for an app go in $prefix/share/app/icons/hicolor/. The app then appends $prefix/share/app/icons to the theming search path. yes, very good. 1) If you append to search path: Not really as $prefix/share/themes/hicolor still has the precedence and any other app could just override your icon by placing a file with equal basename there. 2) If you prepend the search path: Not really as you get no theming at all and you could just use $prefix/share/pixmaps as well. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils xdg-icon-resource's destination icon name
On 6/18/07, James Richard Tyrer [EMAIL PROTECTED] wrote: or that the DeskTop supplies an icon for that MIME type in the HiColor theme. It is this last case that is the problem and it does need to be solved. There is nothing to be solved. Desktop icon themes do not put anything inside hicolor and applications adopted a common practice of prefixing icon names with own package name (like fooapp-baricon.svg). -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming issue
On 4/28/07, Kenneth Wimer [EMAIL PROTECTED] wrote: On Saturday 28 April 2007 08:03:27 Rodney Dawes wrote: On Fri, 2007-04-27 at 22:34 +0200, Kenneth Wimer wrote: On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote: Patryk Zawadzki wrote: HiColor is not default, it is fallback. Semantics Failing to follow the semantics of a specification means you fail to follow the specification. Ok, someone show me where it says that hicolor should be a full-blown theme of its own. A good thing is there is no such place. Even if there was I strongly believe that no particular desktop should place a full-blown icon theme in a shared path. A more acceptable approach would be to have a fd.o neutral theme based on the icon-naming-spec. But as hicolor is a last resort when searching for icons, even this doesn't seem applicable. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue (was: KDE/kdesdk)
On 4/27/07, James Richard Tyrer [EMAIL PROTECTED] wrote: As I see it, the problem is that we don't have a proper set of HiColor icons. Someone moved all the existing HiColor icons to KDEClassic and for some reason all new HiColor icons were removed. Then some HiColor icons were renamed CrystalSVG and some CrystalSVG icons were renamed HiColor. Now GNOME seems to have emulated us and removed their HiColor icons as well. To me this is a real mess. Why is this bad? Apps drop their default icons to hicolor so these are picked up regardless of the theme in use. Why should any theme put its icons there? If a theme is complete, no icons will ever need to be searched for in hicolor. If it is not complete, it should provide its own list of parent themes (e.g. based on CrystalSVG) and the missing icons shouldbe picked from the parent theme, so again, no need to search hicolor. The icon search is supposed to fall back to HiColor. The problem is that now neither KDE nor GNOME has a set of HiColor icons to fall back to. The answer to this should be obvious (and it needs to be added to the standard). We need to have a list of secondary backup icon themes that will be searched when a fall back to HiColor doesn't find an icon. I suggest that this be in a file so that it can be easily changed (or changed by the user). Why do you think a list like that would be needed? I see hicolor as a place where apps can drop their default icons so they work regardless of the theme in use. If a desktop icon theme is missing some icons and it does not provide a parent to interrogate for the missing bits, then I consider the theme to be broken, not the icon spec/desktop. Sorry if I failed to follow your way of seeing things. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement version 0.2
On 4/25/07, Kevin Ottens [EMAIL PROTECTED] wrote: * Added Inhibit interface for initial review. I almost like it. :-) I'm just wondering if we shouldn't try to give a bit more control to the applications when they call Inhibit. For instance, the app might want to provide a hint that it doesn't want suspend and hibernate to happen also when they're triggered manually. I'm thinking about CD Burning for instance, those applications clearly need to hint the power manager that they should not be interrupted be it because of an idle session, user wrongly requesting suspend, or because of very low battery. So I'd add two bool to inhibit similar to this: bool except_user_triggered bool except_on_low_battery They would default to true, but applications would have the opportunity to disable one of those exception when inhibiting. Nah, this really belongs to the system enhibiting rather than session inhibiting (you'd also want to restrict other users from frying your CD). Thus it should not be a part of the session interface but rather a part of HAL (and from the traffic here it seems that a preliminary implementation is already in its place). -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: A global window manager environment variable
On 4/24/07, nyu 2 [EMAIL PROTECTED] wrote: It seems that it would be useful to have a globally-available preferred window manager variable for people that don't like the default window manager that their desktop environment provides. Something like a NETWM variable that, when set, specifies an alternate window manager to load, perhaps. It should be a trivial change in most DEs' startup scripts. Does anyone else think that this may be a good idea? How will this help people who already replaced their WMs? -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: A global window manager environment variable
On 4/24/07, nyu 2 [EMAIL PROTECTED] wrote: They give one simple, easy, and consistant way to do it, regardless of your desktop environment. If you prefer a desktop environment that doesn't use sessions, then this may be the only way aside from scripting to make it happen. My point is, I can hardly imagine someone who would prefer exactly the same WM regardless of the desktop in use, regardless of whether it's a local or remote session. Other than that how do you plan to tell an average user Jane to switch her GNOME WM from say IceWM back to Metacity if an admin decides to set a global ENV variable thus overriding all users' desktop defaults? Would you tell her to launch vim and try to edit all of her dot-rc files? WM is a per-session preference and it belongs there. If I had both GNOME and KDE installed I can hardly imagine wanting Metacity under KDE or KWM (or whatever is the name, excuse my ignorance here) under GNOME. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.SessionManagement
On 4/3/07, Oswald Buddenhagen [EMAIL PROTECTED] wrote: On Tue, Apr 03, 2007 at 09:07:13AM +0100, Richard Hughes wrote: No, we need to provide a way for clients to delay (think to save a file) or to cancel the shutdown (say encoding a file), although the latter use case can be dealt with using the more suited inhibit system. fwiw, i don't think it's more suited (why should it?). given that the callback mechanism is necessary anyway, why introduce a second system that manages state in the service? What about system-level apps that need to inhibit (think daemons)? They have no session daemon to register to. System-level locking is still needed and it's more suited as it does not require you to register any foobar callbacks that just return FALSE, instead you just obtain a lock on a specific HAL device and free the lock when you're done. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.SessionManagement
On 4/3/07, Oswald Buddenhagen [EMAIL PROTECTED] wrote: On Tue, Apr 03, 2007 at 12:04:43PM +0200, Patryk Zawadzki wrote: What about system-level apps that need to inhibit (think daemons)? They have no session daemon to register to. but a system daemon, obviously. i don't see a difference. If Register() is part of the session management interface, then it is provided by session-level daemons. Thus no candy for system level. System-level locking is still needed and it's more suited as it does not require you to register any foobar callbacks that just return FALSE, instead you just obtain a lock on a specific HAL device and free the lock when you're done. otoh you have to update the state known to HAL every time it changes, as opposed to returning it only when asked for. Still - it's meant to be used by critical applications. For example, rpm might only want to inhibit while starting the (un)installation process and free the lock when it's done. This is nothing more than a system-wide non-exclusive semaphore. the only real advantage i can see is that the lock request variant does not require an event loop in the client, but where isn't that provided anyway? other than that, it seems to be just a matter of taste ... Method 1: Obtaining an inhibiting lock is just one call. Freeing the lock is a second call. Method 2: Using Register() is one call. Unregistering is a second call. Yet you still need to write the callback and incorporate handling the callback into your event loop. The problem is single-tasked apps like rpm or might not even have an event loop as they just usually: printf(Doing stuff...); doStuff(); prinft( done\n); If there is no required interaction, there is no need for an event loop. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Fwd: org.freedesktop.PowerManagement
On 3/27/07, Danny Kukawka [EMAIL PROTECTED] wrote: On Dienstag, 27. März 2007, Richard Hughes wrote: First, there might be more than a single backlight - the tool which provide the interface have to handle this or the get/set methodes have to take/return arrays with info for each display. But the major use case on laptops this is IMO not really needed, there is the internal display the thing you want to change Arrays? Maybe add another param that is the HAL ID of the device to both get and set and add a method to easily enumerate the devices (return an array of all known IDs and names). Secondly, exporting the brightness as percentage sucks No, it does not. It make no sense to export e.g. all ~250 brightnesslevel of a Panasonic laptop display. If you want to change the display brightness of such a display e.g. with a slider in the GUI you produce high system load and many calls to HAL/in HAL. And you can't see the difference between level 170 and 172. But it does suck if your LCD only supports ~17 brightness levels and calculating percentage gives you fractions. How do you handle brightness up/down controls there? - Internally keep the current counter and each time it changes map it to the closest handled by LCD? - Each time it changes reset it to the closest value (would require the application to incrementally try to increase brightness untill there is a change) Mapping the existing level to percentage make much sense. This allow you also to use your settings on different machines with different brightness level (if you use e.g. a NFS home). It should be kept as a per-device setting, not global. What if I have a really bright LCD at one location/machine and a really dim one at the other? Btw. the mapping to percentage should maybe happen in HAL directly. I think this really belongs to the GUI part of the application, not the hardware abstraction. Move the backlight stuff to their own D-Bus objects: /org/freedesktop/PowerManagement/BackLighDevices/backlight0 and so on. (better use some HAL device name for naming the object) Make maybe sense, but why do we need these new interfaces which are somehow only duplicates of the HAL stuff? Would it not make more sense to only provide one interface to all display backlights (set brightness to 50% would set it to all displays) or only to the primary display (would make sense on laptops)? For all other interfaces you can use HAL also directly or not? It makes sense only for laptops. What if I use an UPS and want all the monitors but the main one to either turn off or get as low in brightness as possible in case of power failure? Or I don't want to touch the one that has an auxiliary power source? -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop entry spec TryExec key
On 3/23/07, Brian J. Tarricone [EMAIL PROTECTED] wrote: Hi all, We're revisiting our desktop menu implementation in Xfce, and I'm looking at some old hacks I put into the old implementation to sanitise the Exec and/or TryExec keys before using them. Regarding the TryExec key, what can I expect to find there? Are the 'field codes' allowed in the Exec key also allowed in TryExec (I would think/hope not)? How is quoting handled? Same as Exec? Basically my question is this: can I take the value of TryExec and pass it unaltered to something like g_find_program_in_path() and expect that to always work? If not, what are the problems with that? The desktop entry spec says very little about TryExec. Also, I'm realising the desktop entry spec is very ambiguous as to how to even use TryExec: File name of a binary on disk used to determine if the program is actually installed. If not, entry may not show in menus, etc. What does 'used to determine' mean in this context? Was the original intention that the TryExec program should actually be *executed* to determine if the program is installed (my assumption is no)? Or is just verifying that the program exists, is in PATH, is exectuable, etc. all that's intended here? I am not the author of the original spec but it does not make sense to actually execute anything. Some programs may never return (waiting for stdin), some might fork and detach. The way I understand TryExec is that it's supposed to point to a binary that is required for the entry to make sense (ie. work) in the menus. If the binary exists (can be found in PATH), is executable and the current user has rights to execute it, that should be enough. Actually executing the binary might lead to multiple undesired results and would give no additional information (when is running a GTK/Qt application cosidered successful?). -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xgl hangs when openoffice menu is clicked
On 3/21/07, Cengiz Gunay [EMAIL PROTECTED] wrote: Hi, I've been using Xgl+Beryl on a Nvidia/x86-64 OpenSuSE 10.2 for a while now. Apart from the occasional beryl crashes from which one can recover quickly, I get Xgl hangs which require a killall -9 Xgl and cause a lot of loss. I found one reproducible example: Xgl consistently hangs when I click on any OpenOffice menu bar. Xgl takes 100% of the CPU, mouse moves but nothing else happens. Switching to console and back works but results in a black screen with only the mouse cursor moving. I can provide more details if one can show me how to get debug info from Xgl or Xorg. Are you absolutely positively sure this is the right place to report this? This is a freedesktop.org standards list. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On 3/22/07, Richard Hughes [EMAIL PROTECTED] wrote: On 22/03/07, Rob Taylor [EMAIL PROTECTED] wrote: Umm, i was actually talking about context switches, nothing to do with async versus sync. I'd expect an app to do async calls on startup. I guess its theoretically possible at the libdbus level to queue up a number of messages and do one context switch to send them all... Gotcha. What about doing both? We keep the CanSuspend for the trivial desktop case, and also provide a GetCapabilities method that returns a bitfield for embedded use, or for languages like python that can unwrap a bitfield easily. It's one extra method, and one extra signal, so it's hardly much API duplication. Disagreed. I'd rather keep one GetCaps that can be called by a wrapper library (thing glib and stuff) on startup and cached so later that *wrapper* can provide you with individual CanDoSomething wrappers. This would reduce the bus traffic and remove the requirement of caching the values on the application side. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [Wasabi] Project renaming
On 3/16/07, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: Specifically on XdgSearch; the project will likely expand beyond pure searching so it might send the wrong signals. Also I don't even know what Xdg stands for :-) - but the name as such might be more politically correct. Then call it MetaSauce or DataSauce (sorry, could not resist) :D -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [Wasabi Proposal] End user search language
Dnia 28-01-2007, nie o godzinie 22:37 +0100, Mikkel Kamstrup Erlandsen napisał(a): Hi All, I put together a first take on formalizing an end user search language. http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage Let me emphasize that I write search language and not query language. This is designed for the average user that find the Google search language more than enough. It has powerful features but I try to keep it as simple as possible - both because i claim that users dont need more[1], and because it should be as easy as possible to parse. When this is said, it doesn't rule out that developers that want a basic search feature in their music app/help browser insert pet peeve can't use this language. There's still lots of functionality. I'm not saying that I didn't forget anything or didn't totally blow it, so go ahead and gimme the flames! +1, no flames here I like the idea of using something more human-friendly. But you seem to have left out the grouping parentheses? type:audio (author=foo title=bar) or (author=bar title=foo) [1]: We actually have usability studies at work supporting this. Users simply fire of lots of simple queries instead of doing one complex one. Admit it - you do the same :-) About usability - I think having to change the Reply-To for each post to this list is somewhat odd :) -- Patryk Zawadzki [EMAIL PROTECTED] PLD Linux signature.asc Description: To jest część listu podpisana cyfrowo ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Recommendation for $HOME
Dnia 28-12-2006, czw o godzinie 13:55 +0100, David Faure napisał(a):
On Tuesday 19 December 2006 11:28, Jon Dowland wrote:
I agree utterly. I think the suggestion that
$HOME/{var,etc,...} is too confusing for beginners is
laughable.
Is it? My wife would surely be _very_ confused with those things in her $HOME.
I really like the XDG* vars approach, where you have .config and .cache
by default but are free to set them up differently.
Are beginners not going to notice things outside of /home ?
That's right. They aren't. They really don't need to go into /etc or /var.
Yes but some people here forget that user != admin/sysop. I work for a
hosting company and some of my users don't even know they are using
Linux. Same applies to corporate desktop users.
--
Patryk Zawadzki [EMAIL PROTECTED]
PLD Linux
signature.asc
Description: To jest część listu podpisana cyfrowo
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: hicolor algorithm clarification in Icon Theme Spec
Dnia 24-12-2006, nie o godzinie 00:28 -0800, Octavio Alvarez Piza
napisał(a):
Hi, everybody. I'm new to the list. My name is Octavio Alvarez and I'm
developing a small app named Superkb, intended to make something fancy
for Xorg.
I'm converting the lookup algorithm in the Icon Theme Specification to
C code. I have noticed that the hicolor fallback theme will be
looked up before a second parent, thus, having the wrong lookup
priority.
Why are you rewriting this from scratch if all widget toolkits already
provide such functionality?
One of the paragraphs that says so is:
In order to have a place for third party applications to install
their icons there should always exist a theme called 'hicolor' [1].
The data for the hicolor theme is available for download at:
http://www.freedesktop.org/software/icon-theme/. Implementations are
required to look in the hicolor theme if an icon was not found in
the current theme.
This makes a second parent theme to get ignored if an icon exists in
hicolor. Themes that use hicolor as a parent should explicitly say
so in their Inherits key.
I think I know what you mean:
Here is a patch for the lookup pseudocode.
FindIcon(icon, size) {
filename = FindIconHelper(icon, size, user selected theme);
if filename != none
return filename
+ filename = FindIconHelper(icon, size, hicolor);
+ if filename != none
+ return filename
return LookupFallbackIcon (icon)
}
FindIconHelper(icon, size, theme) {
filename = LookupIcon (icon, size, theme)
if filename != none
return filename
if theme has parents
parents = theme.parents
- else if theme != hicolor
-parents = [hicolor]
for parent in parents {
filename = FindIconHelper (icon, size, parent)
if filename != none
return filename
}
The above call in the loop is recursive so it will always reach a
grand-grand-...-parent that has no more parents and thus fall back into
hicolor in the first step of the for loop.
return none
}
It is my understanding that implementations must not look in hicolor
when looking into a parent theme. Instead, it should be checked right
before unthemed icons.
And you are probably true.
--
Patryk Zawadzki [EMAIL PROTECTED]
PLD Linux
signature.asc
Description: To jest część listu podpisana cyfrowo
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org and accelerated desktop standards
Dnia 06-12-2006, śro o godzinie 17:37 -0200, Carlos Eduardo Rodrigues Diógenes napisał(a): Yes, I never oppose the fact that WM an CM must merge, and I also agree that the easiest path is a plugin architecture to support magnification is this enviroment. The problem IMO is that if we can't run the magnifier in environments that doesn't support the plugin architecture implemented by Beryl/Compiz (from the little that I saw, they appear to be the same) we will be putting a burden to people that need accessibility support in experimenting with new enviroments. Then you can push metacity maintainers to export the same API and provide a fallback compositing app for the rest of the non-conforming desktops. You don't have to cover all desktops in one release. -- Patryk Zawadzki [EMAIL PROTECTED] PLD Linux signature.asc Description: To jest część listu podpisana cyfrowo ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
