Hi,
I noticed we now install the new Characters app by default, which is great. However, wouldn't it make more sense if it'd go in the Utilities folder, where the old one used to live?
Additionally I noticed Disks also found its way out of the Utilities folder, which also feels weird. It should probably go back to Utilities as well
What do you think?
On Wed, 2015-09-23 at 17:09 +0300, Elad Alfassa wrote:
Additionally I noticed Disks also found its way out of the Utilities folder, which also feels weird. It should probably go back to Utilities as well
I don't know why. The only commit to touch the desktop file was [1].
[1] https://git.gnome.org/browse/gnome-disk-utility/commit/?id=6192f56b eb27ed573d18dfb0a0f080a471a1cef4
On Wed, Sep 23, 2015 at 5:56 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2015-09-23 at 17:09 +0300, Elad Alfassa wrote:
Additionally I noticed Disks also found its way out of the Utilities folder, which also feels weird. It should probably go back to Utilities as well
I don't know why. The only commit to touch the desktop file was [1].
[1] https://git.gnome.org/browse/gnome-disk-utility/commit/?id=6192f56b eb27ed573d18dfb0a0f080a471a1cef4 -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Simple explanation: The changed desktop file name means the rule here: https://git.gnome.org/browse/gnome-menus/tree/layout/gnome-applications.menu no longer matches.
The proper way to fix it would be adding X-GNOME-Utilities to the category list in the desktop file.
On Wed, 2015-09-23 at 18:06 +0300, Elad Alfassa wrote:
Simple explanation: The changed desktop file name means the rule here: https://git.gnome.org/browse/gnome-menus/tree/layout/gnome-applicatio ns.menu no longer matches.
The proper way to fix it would be adding X-GNOME-Utilities to the category list in the desktop file.
Thanks, will-do for both Characters and Disks.
Michael
On Wed, Sep 23, 2015 at 6:20 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2015-09-23 at 18:06 +0300, Elad Alfassa wrote:
Simple explanation: The changed desktop file name means the rule here: https://git.gnome.org/browse/gnome-menus/tree/layout/gnome-applicatio ns.menu no longer matches.
The proper way to fix it would be adding X-GNOME-Utilities to the category list in the desktop file.
Thanks, will-do for both Characters and Disks.
Michael
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Would probably be a good idea to patch this downstream so we'll have a polished-looking final release, since I don't know if Disks and Characters are going to get a 3.18.1 in time (or at all)
On Mon, 2015-09-28 at 22:14 +0300, Elad Alfassa wrote:
Would probably be a good idea to patch this downstream so we'll have a polished-looking final release, since I don't know if Disks and Characters are going to get a 3.18.1 in time (or at all)
I'll do a Disks 3.18.1, but it might be too late to get into F23 due to the conflicting schedules, so if someone wants to add the patch downstream, that's indeed not a bad idea.... I expect Daiki will do Characters 3.18.1 since he's been following the GNOME release cycle rather closely. That one we don't have to worry about, since Characters 3.18.1 doesn't have a symbolic icon, and that is a release blocker. :)
Michael
On Mon, Sep 28, 2015 at 10:40 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2015-09-28 at 22:14 +0300, Elad Alfassa wrote:
Would probably be a good idea to patch this downstream so we'll have a polished-looking final release, since I don't know if Disks and Characters are going to get a 3.18.1 in time (or at all)
I'll do a Disks 3.18.1, but it might be too late to get into F23 due to the conflicting schedules, so if someone wants to add the patch downstream, that's indeed not a bad idea....
I would make a downstream patch but I don't have commit access to this package. Will anyone with commit access volunteer to make the downstream patch? It'll probably be faster than granting me commit access since it's a one-liner patch :)
On Thu, Sep 24, 2015 at 12:20 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
The proper way to fix it would be adding X-GNOME-Utilities to the category list in the desktop file.
Thanks, will-do for both Characters and Disks.
Thanks - Daiki Ueno added group::gnome-sig to Fedora gnome-characters yesterday. So you should have commit access now.
Jens
Hi,
Simple explanation: The changed desktop file name means the rule here: https://git.gnome.org/browse/gnome-menus/tree/layout/gnome-applications.menu no longer matches.
The proper way to fix it would be adding X-GNOME-Utilities to the category list in the desktop file.
hey, I chatted with Matthias a little about this in meat space.
Are you talking about in classic mode?
We don't think it uses the menu file in the non-classic mode. Instead it uses a relocatable dconf schemas . See:
https://wiki.gnome.org/HowDoI/AppFolders
My guess is gnome-shell's hardcoded mapping of compat names to new names needs an update. But could also be gnome-shell doesn't use that mapping table when generating the launcher groups, not sure.
--Ray
On Wed, Sep 23, 2015 at 6:02 PM, Ray Strode rstrode@redhat.com wrote:
We don't think it uses the menu file in the non-classic mode. Instead it uses a
relocatable dconf schemas . See:
Yes, however the schema allows to associate (menu spec) categories with app folders, and that's what gnome-software is doing[0]. It also sets a list of apps directly, and said list hasn't been updated for gnome-characters or disk's renamed desktop file ...
[0] https://git.gnome.org/browse/gnome-software/tree/src/gs-folders.c#n551
On 09/23/2015 06:11 PM, Florian Müllner wrote:
On Wed, Sep 23, 2015 at 6:02 PM, Ray Strode rstrode@redhat.com wrote:
We don't think it uses the menu file in the non-classic mode. Instead it uses a
relocatable dconf schemas . See:
Yes, however the schema allows to associate (menu spec) categories with app folders, and that's what gnome-software is doing[0]. It also sets a list of apps directly, and said list hasn't been updated for gnome-characters or disk's renamed desktop file ...
[0] https://git.gnome.org/browse/gnome-software/tree/src/gs-folders.c#n551
https://git.gnome.org/browse/gnome-software/commit/?id=798516d should fix that up.
On Wed, Sep 23, 2015 at 7:02 PM, Ray Strode rstrode@redhat.com wrote:
Hi,
Simple explanation: The changed desktop file name means the rule here:
https://git.gnome.org/browse/gnome-menus/tree/layout/gnome-applications.menu
no longer matches.
The proper way to fix it would be adding X-GNOME-Utilities to the
category
list in the desktop file.
hey, I chatted with Matthias a little about this in meat space.
Are you talking about in classic mode?
Nope.
We don't think it uses the menu file in the non-classic mode. Instead it uses a relocatable dconf schemas . See:
https://wiki.gnome.org/HowDoI/AppFolders
My guess is gnome-shell's hardcoded mapping of compat names to new names needs an update. But could also be gnome-shell doesn't use that mapping table when generating the launcher groups, not sure.
I think the menu file is still relevant, but now that you say it isn't I'm not sure anymore. I think what this file does is add categories to desktop files according to a match pattern.
But it doesn't matter much because the correct solution is not to hardcode the desktop file name in the menu file, but rather add the appropriate category to the desktop files in question. I did that for a few apps some time ago: https://bugzilla.gnome.org/show_bug.cgi?id=735127
On 09/24/2015 12:09 AM, Elad Alfassa wrote:
Hi,
I noticed we now install the new Characters app by default, which is great. However, wouldn't it make more sense if it'd go in the Utilities folder, where the old one used to live?
Additionally I noticed Disks also found its way out of the Utilities folder, which also feels weird. It should probably go back to Utilities as well
What do you think?
-Elad.
+1 from me on these -- these are definitely prime candidates to be in the utilities group / folder.
One quick question about the new charachters app -- is the search provider (showing results in the overview when searching) enabled by default? I'm on the edge about this one -- it is a neat feature, but probably not useful for everyone.
cheers, ryanlerch
On Thu, Sep 24, 2015 at 2:04 AM, Ryan Lerch rlerch@redhat.com wrote:
One quick question about the new charachters app -- is the search provider (showing results in the overview when searching) enabled by default? I'm on the edge about this one -- it is a neat feature, but probably not useful for everyone.
It seems to be enabled by default. I also think the same thing. It's a neat feature but since it's named "Characters" it appears at the top of the result list and you sometimes need to scroll to see entries from providers that are more relevant.
On Thu, 2015-09-24 at 02:20 +0300, Elad Alfassa wrote:
On Thu, Sep 24, 2015 at 2:04 AM, Ryan Lerch rlerch@redhat.com wrote:
One quick question about the new charachters app -- is the search provider (showing results in the overview when searching) enabled by default? I'm on the edge about this one -- it is a neat feature, but probably not useful for everyone.
It seems to be enabled by default. I also think the same thing. It's a neat feature but since it's named "Characters" it appears at the top of the result list and you sometimes need to scroll to see entries from providers that are more relevant.
Is the ordering really alphabetical?
That ordering can be changed in Settings -> Search, so hopefully it can be changed by default.
desktop@lists.stg.fedoraproject.org
-
Elad Alfassa -
Florian Müllner -
Jens-Ulrik Petersen -
Kalev Lember -
Mathieu Bridon -
Michael Catanzaro -
Ray Strode -
Ryan Lerch