Re: cursor spec
2014-04-07 15:15 GMT+02:00 Jerome Leclanche : > All the web browsers already use the same convention, don't they? If > so, it should probably be added, yes. > J. Leclanche > they use the name in the CSS, but implementations are… complicated. under the hood, firefox and chrome use gdk_cursor_new, which does NOT use the spec names (e.g. it uses “plus”, not “cell”) the gdk cursor type is a direct mirror of the XLib constants, and indeed gdk_cursor_new thinly wraps XLib https://developer.gnome.org/gdk3/stable/gdk3-Cursors.html#GdkCursorType however, i got a patch in that adds more robust behavior to firefox: https://hg.mozilla.org/mozilla-central/rev/068ed8d0e7c2 i’ll file another bug with patch to get in vertical-text and the zoom things once the latter are added to the spec. 2014-04-07 16:24 GMT+02:00 Bastien Nocera : > Are there implementations already using this? > > We'd be happy having this added in GNOME. > > Cheers > i researched a bit, and there are quite a few cursor themes which do have it, and all use zoom-in and zoom-out (except for one, that uses zoomIn and zoomOut. but since no other cursor has camelCase, i think we should ignore that) i think toolkit maintainers are hesistant to add support until there’s some agreed-upon name (that’s speculation, though) best, phil ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: cursor spec
On Sun, 2014-04-06 at 19:35 +0200, Philipp A. wrote: > hi people, > > > how about adding zoom-in and zoom-out to the cursor spec? (I’d guess > “nice-to-have” section) > > http://www.freedesktop.org/wiki/Specifications/cursor-spec/ Are there implementations already using this? We'd be happy having this added in GNOME. Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
hi,
On Mon, Apr 7, 2014, at 9:45, Bastien Nocera wrote:
> Using this example.
>
> System-wide:
> - eog.desktop isn't available
> - gthumb.desktop is available
> - mimeapps.list says:
> image/bmp=eog.desktop;gthumb.desktop;
>
> User-wide:
> - no mimeapps.list
> - eog.desktop is available
>
> I would expect gthumb.desktop being the default for the user. Meaning
> that even if the mimeapps.list contains multiple values, it would only
> check for desktop files/applications availability at the same level.
This matches my expectations as well (at least I think it does...), but
this is not how the spec is currently written.
> I don't think we ever supported that, unless the mime-type was added at
> the user-level. Eg. if x.desktop has support for text/plain, it always
> does even at the user-level. The glib API seems to match that
> interpretation with g_app_info_can_remove_supports_type().
static gboolean
g_desktop_app_info_can_remove_supports_type (GAppInfo *appinfo)
{
return TRUE;
}
After a bit more thinking, it seems desirable to make the following
tweaks:
At each level that we have added and removed associations referring to a
desktop file that resides in the same directory as the mimeapps.list
file, we should treat the Added and Removed associations as being
exactly equivalent to this file having been edited and those entries
added/removed from the MimeTypes field.
We should forbid [added] or [removed] entries in the desktop-specific
*-mimeapps.list files -- only defaults should be allowed here. This
means that I can now give a canonical list of "mime types supported by
this app" per desktop file in a given directory and not have it be
desktop-dependent. This simplifies the cache.
When mimeapps.list exists in directories above the directories where the
desktop file exists (ie: in the homedir for a desktop file in /usr) then
we should treat added/removed here as equivalent to copying the file
from the lower directory to the current directory, with the MimeTypes=
line tweaked by any changes we found along the way.
All of the above depends _only_ on Added and Removed.
In order to simplify the above logic we should separate the handling of
defaults entirely. Any language about 'default' implying 'added' should
be removed.
I consider it to be an open question as to what happens if Defaults
"picks" an application that is installed but not listed as supporting
the mimetype (either by not having it listed in the desktop file, or by
the user having removed the association). I think this is actually not
a very interesting question because anyone who sets something as a
default should either make sure that it is supported (and not 'Removed'
by user config) and/or explicitly mentioned in 'Added'. I would even be
happy to leave this implementation defined.
It would also be nice if we could see mention in the spec about "if
applications want to order the keys in added, it should do it by MRU
order, but this is optional" in order to document the only existing
implementation that cares about this order and to prevent other
implementations from thinking that it is appropriate to use the order
for something else. Implementations that do not care about order are
free to ignore it and certainly don't need to update it.
Cheers
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, 2014-04-06 at 19:50 -0400, Ryan Lortie wrote: > hi David, > > On Wed, Apr 2, 2014, at 11:06, David Faure wrote: > > After so many years, he's finally a proposal for a unified mechanism for > > selecting the default application for a given mimetype. > > A couple notes after my attempts to integrate this work with the desktop > file index: > > The multiple defaults thing is a bit strange and it makes the cache more > complex. It would be nice to just give the desktop file ID for each > type. This was something that was possible using the old defaults.list: http://pkgs.fedoraproject.org/cgit/shared-mime-info.git/tree/defaults.list#n13 But this is a fallback that's implemented based on the available desktop files. Using this example. System-wide: - eog.desktop isn't available - gthumb.desktop is available - mimeapps.list says: image/bmp=eog.desktop;gthumb.desktop; User-wide: - no mimeapps.list - eog.desktop is available I would expect gthumb.desktop being the default for the user. Meaning that even if the mimeapps.list contains multiple values, it would only check for desktop files/applications availability at the same level. > What is the interaction between the mime cache and replaced desktop > files? > > Specifically, imagine this situation: we have 'x.desktop' in ~ and /usr. > In /usr it supports MimeType=text/plain, but the .desktop file in ~ has > no such mention. In /usr it is listed in mimeapps.info as the default > for text/plain. > > As written, the spec suggests that because x.desktop is mentioned as the > default for text/plain we should implicitly add it. What if it was in > Added, though? It seems that, at any given level, having an Added > association for a desktop file that already lists the mime type among > its MimeTypes= should be redundant, but here we see that we would get a > different result. I don't think we ever supported that, unless the mime-type was added at the user-level. Eg. if x.desktop has support for text/plain, it always does even at the user-level. The glib API seems to match that interpretation with g_app_info_can_remove_supports_type(). > Is this desirable? What does it mean if the user replaces a desktop > file with one in their homedir that has a more restrictive set of > supported mimetypes? Probably that means that the version that they > install does not support the wider range, and then the added association > is probably inappropriate -- doubly so if it was only there in order to > break a tie over the choice of default. > > Thoughts? Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: cursor spec
All the web browsers already use the same convention, don't they? If so, it should probably be added, yes. J. Leclanche On Sun, Apr 6, 2014 at 6:35 PM, Philipp A. wrote: > hi people, > > how about adding zoom-in and zoom-out to the cursor spec? (I’d guess > “nice-to-have” section) > > http://www.freedesktop.org/wiki/Specifications/cursor-spec/ > > best, philipp > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sat, 2014-04-05 at 15:04 -0400, Jasper St. Pierre wrote: > No idea how "DPNH" got there. Cat on a keyboard or something. > > > RealPlayer was an app known for making terrible forceful > customizations to the user's system on Windows. If you deleted the > Start Menu, Desktop, or Quick Launch shortcut and ran RealPlayer, it > would notice and re-add all the shortcuts. If it wasn't the default > MIME handler, it would silently reregister itself for all media types > it supported. > > > Having an official way to do this is a way to tell ISVs that they > *should* do this, We also have official ways to delete every user owned files... > that it's recommended practice if you have an app that handles a MIME > type. Apps that want to force their way into the user's customizations > are RealPlayer, and we should let them feel shameful hacking > up /usr/share/applications/mimeapps.list on install, and bare the > responsibility if it breaks, not give them an API for it. This is silly. In the long run, those files won't be accessible to applications. Right now, applications can already set themselves as the default application for each user when they're run, it was simply implemented in desktop/toolkit-specific ways. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
