From j.w.r.degoede at hhs.nl Mon May 1 11:59:48 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 May 2006 13:59:48 +0200 Subject: optional game music files In-Reply-To: <1146482012.5802.37.camel@localhost.localdomain> References: <445528B8.6020807@kobold.org> <4455E72C.6080800@hhs.nl> <1146482012.5802.37.camel@localhost.localdomain> Message-ID: <4455F834.7090401@hhs.nl> Ville Skytt? wrote: > On Mon, 2006-05-01 at 12:47 +0200, Hans de Goede wrote: >> Wart wrote: >>> Some examples of content which are not permissable: >>> >>> * Ogg/mp3 files >>> >>> Since these ogg files are part of the game, but not part of the upstream >>> sources, are they still considered acceptable? >>> >> Since there has been no reaction for the last 12 hours, may I assume >> that no-one objects or? > > IMO 12 hours is much too little time for doing something which appears > to be directly against the packaging guidelines, especially considering > that today is a holiday in lots of countries and probably considerably > less people than usual are reading their FE mail. Patience, please. > I wasn't aware of the vacation bit, sure I'll wait a bit more. > I'm not saying that this case is not acceptable for inclusion, but it > sounds somewhat like being against the intended purpose or the "spirit" > of that rule. I guess it depends on exactly how optional those files > are, how easy it is to properly install/remove them without them being > rpm-packaged, and whether anyone would have any complaints about their > inclusion if they'd be part of the upstream tarball which also contains > the actual game. > Thats exactly my problem with the possible explanation of these rules as this being unacceptable, if these files were in the same upstream tarball as the game engine and other gamedata nobody would be complaining. I've packaged plenty of other game packages containing music, how is this _any_ different except that the music is in a seperate tarball? Which is acutally good, because this means that the raidem-music pakcage will probably never have to change saving bandwidth! I would actually love to see other upstreams do similar splits, see below. However this whole story seems to penalize the good upstream behaviour of spitting of almost never changing content > (There are some examples in the repo that I think would be better off > handled by end users themselves and not packaged) If the files are looked for by the package / game under /usr/share/%{name} I believe they should be packaged I don't want users dropping stuff there themselves potentially breaking upgrades, leaving cruft behind on uninstall, etc. >, so one should apply > criticism when/if looking for previous examples. One example are the > huge optional content blobs for uqm, of which only a subset changes > between releases which can't be sanely handled in the current > uqm-content package. But the uqm case predates the guideline...) > I know there are packages which could do with an upstream split in code and content so we could create seperate SRPMS for engine and content and thus easily (relative small download) upgrade the engine for bug fixes / new features. In general content tends to be much more static then the engines. I've actually been thinking about making 2 SRPMS both containing the same upstream tarball to fake this split. Unfortunatly this would take twice the space in the SRPMS dir on the mirrors, or I would have to create a split source tarbal myself. Regards, Hans From wart at kobold.org Thu May 4 18:45:39 2006 From: wart at kobold.org (Michael Thomas) Date: Thu, 04 May 2006 11:45:39 -0700 Subject: game data packages Message-ID: <445A4BD3.3020305@kobold.org> At the last FESCo meeting the following packaging guideline was modified: * Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered. The restriction on ogg files was removed, but it's still not allowed to ship mp3 files for game music. This clarifies the rule for game music files, so it's clear now that packages like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 are ok. However, brought up a concern about the disk usage from having duplicate packages of this static content on the fedora mirrors. Clearly most game data/music should be in a noarch package, but it still means that each dist (fc4, fc5, fc6...) will end up with a duplicate package. The recommendation to work around this is to _not_ use the %dist tag on large, noarch, game data packages. This will result in identical package filenames when built on each of the branches. While this won't immediately reduce the disk usage on the mirrors, it will be one step forward to helping solve the problem. Does anyone else see any problem with prohibiting the %dist tag for game data packages (unless the packager has a reasonable justification)? --Wart -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From j.w.r.degoede at hhs.nl Thu May 4 18:55:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 04 May 2006 20:55:35 +0200 Subject: game data packages In-Reply-To: <445A4BD3.3020305@kobold.org> References: <445A4BD3.3020305@kobold.org> Message-ID: <445A4E27.1090704@hhs.nl> Michael Thomas wrote: > At the last FESCo meeting the following packaging guideline was modified: > > * Game music or audio content is permissible, as long as the content is > freely distributable without restriction, and the format is not patent > encumbered. > > The restriction on ogg files was removed, but it's still not allowed to > ship mp3 files for game music. > > This clarifies the rule for game music files, so it's clear now that > packages like > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 are ok. > > However, brought up a concern about the disk usage from having duplicate > packages of this static content on the fedora mirrors. Clearly most > game data/music should be in a noarch package, but it still means that > each dist (fc4, fc5, fc6...) will end up with a duplicate package. > > The recommendation to work around this is to _not_ use the %dist tag on > large, noarch, game data packages. This will result in identical > package filenames when built on each of the branches. While this won't > immediately reduce the disk usage on the mirrors, it will be one step > forward to helping solve the problem. > > Does anyone else see any problem with prohibiting the %dist tag for game > data packages (unless the packager has a reasonable justification)? > I see no problem in doing this for raidem-music (bug 190267), nor for worminator-data. But I think we should be very carefull with this, I dunno why I think this, but I'm afraid we might run into some kinda trouble. Anyways concider this done for raidem-music. Regards, Hans > --Wart > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-games-list mailing list > Fedora-games-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-games-list From j.w.r.degoede at hhs.nl Thu May 4 18:58:14 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 04 May 2006 20:58:14 +0200 Subject: game data packages In-Reply-To: <445A4BD3.3020305@kobold.org> References: <445A4BD3.3020305@kobold.org> Message-ID: <445A4EC6.7060107@hhs.nl> Michael Thomas wrote: > At the last FESCo meeting the following packaging guideline was modified: > > * Game music or audio content is permissible, as long as the content is > freely distributable without restriction, and the format is not patent > encumbered. > > The restriction on ogg files was removed, but it's still not allowed to > ship mp3 files for game music. > > This clarifies the rule for game music files, so it's clear now that > packages like > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 are ok. > > However, brought up a concern about the disk usage from having duplicate > packages of this static content on the fedora mirrors. Clearly most > game data/music should be in a noarch package, but it still means that > each dist (fc4, fc5, fc6...) will end up with a duplicate package. > > The recommendation to work around this is to _not_ use the %dist tag on > large, noarch, game data packages. This will result in identical > package filenames when built on each of the branches. While this won't > immediately reduce the disk usage on the mirrors, it will be one step > forward to helping solve the problem. > > Does anyone else see any problem with prohibiting the %dist tag for game > data packages (unless the packager has a reasonable justification)? > > --Wart > Erm, will this work? This means one can only do "make tag" for one branch won't plague be upset when you tell it to make something on FC-5 and the passed tag belongs to the devel branch? Regards, Hans From j.w.r.degoede at hhs.nl Thu May 4 19:47:44 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 04 May 2006 21:47:44 +0200 Subject: game data packages In-Reply-To: <445A4EC6.7060107@hhs.nl> References: <445A4BD3.3020305@kobold.org> <445A4EC6.7060107@hhs.nl> Message-ID: <445A5A60.9080003@hhs.nl> Hans de Goede wrote: > > Michael Thomas wrote: >> At the last FESCo meeting the following packaging guideline was modified: >> >> * Game music or audio content is permissible, as long as the content is >> freely distributable without restriction, and the format is not patent >> encumbered. >> >> The restriction on ogg files was removed, but it's still not allowed to >> ship mp3 files for game music. >> >> This clarifies the rule for game music files, so it's clear now that >> packages like >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 are ok. >> >> However, brought up a concern about the disk usage from having duplicate >> packages of this static content on the fedora mirrors. Clearly most >> game data/music should be in a noarch package, but it still means that >> each dist (fc4, fc5, fc6...) will end up with a duplicate package. >> >> The recommendation to work around this is to _not_ use the %dist tag on >> large, noarch, game data packages. This will result in identical >> package filenames when built on each of the branches. While this won't >> immediately reduce the disk usage on the mirrors, it will be one step >> forward to helping solve the problem. >> >> Does anyone else see any problem with prohibiting the %dist tag for game >> data packages (unless the packager has a reasonable justification)? >> >> --Wart >> > > Erm, will this work? This means one can only do "make tag" for one > branch won't plague be upset when you tell it to make something on FC-5 > and the passed tag belongs to the devel branch? > I think we need to think this one over a bit more. For now I'm just going along with raidem-music with %{?dist}, I want to get that of my todo list. Then we can take our time to come up with something sane for this. We might as well include packages in the discussion were upstream doesn't split content and engine and we want to split these. Regards, Hans From wtogami at redhat.com Thu May 4 22:01:59 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 May 2006 18:01:59 -0400 Subject: game data packages In-Reply-To: <445A5A60.9080003@hhs.nl> References: <445A4BD3.3020305@kobold.org> <445A4EC6.7060107@hhs.nl> <445A5A60.9080003@hhs.nl> Message-ID: <445A79D7.70601@redhat.com> Hans de Goede wrote: > > I think we need to think this one over a bit more. For now I'm just > going along with raidem-music with %{?dist}, I want to get that of my > todo list. Then we can take our time to come up with something sane for > this. > > We might as well include packages in the discussion were upstream > doesn't split content and engine and we want to split these. > For the noarch data package that is the same in content between dists, go ahead and go distless for now. Send me requests directly, and I will *copy* the entire signed package from one dist tree to another. So you build it once and it will be replicated. We will need to formalize this process sometime later. "make tag" failing on multiple branches is not a big problem if they are identical in content. Warren Togami wtogami at redhat.com From j.w.r.degoede at hhs.nl Fri May 5 07:39:09 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 05 May 2006 09:39:09 +0200 Subject: game data packages In-Reply-To: <445A79D7.70601@redhat.com> References: <445A4BD3.3020305@kobold.org> <445A4EC6.7060107@hhs.nl> <445A5A60.9080003@hhs.nl> <445A79D7.70601@redhat.com> Message-ID: <445B011D.3050004@hhs.nl> Warren Togami wrote: > Hans de Goede wrote: >> >> I think we need to think this one over a bit more. For now I'm just >> going along with raidem-music with %{?dist}, I want to get that of my >> todo list. Then we can take our time to come up with something sane for >> this. >> >> We might as well include packages in the discussion were upstream >> doesn't split content and engine and we want to split these. >> > > For the noarch data package that is the same in content between dists, > go ahead and go distless for now. Send me requests directly, and I will > *copy* the entire signed package from one dist tree to another. So you > build it once and it will be replicated. We will need to formalize this > process sometime later. > Okay, sounds good, so I basicly only keep a devel branch (no use for other identical branches then I guess, especially since I cannot tag them), build that and ask you to the result over to FC-5 (and possible others, but in this case only FC-5). Wouldn't it be a good idea to use symlinks for this then, or can't the mirrors handle this? With symlinks we would get a real save in diskspace and bandwidth (only mirroring bandwidth, but still). The same (symlinks) can be argued for the i386 packages currently copied into the x86_64 repo. Regards, Hans From chris.stone at gmail.com Sun May 7 16:40:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 7 May 2006 09:40:53 -0700 Subject: Games submenus Message-ID: A few months ago I tried out GNOME to see if it has made any improvements, and one thing I noticed is that the Games menu does not have any submenus. As someone who installs every game available, this made the menu quite unorganized. KDE has several submenus under games such as Arcade, Card Games, Kids Games, Strategy etc. I am wondering if it is possible to define some sub-categories we can use for games to help clean up the games menu? Does GNOME support these submenus? And is it possible to define our own set of submenus for the Games menu? I think that since there are going to be many more games added over the coming months and years it would be prudent to implement some standards for this if possible as the Games menu is already quite large, especially in GNOME. From j.w.r.degoede at hhs.nl Sun May 7 19:36:25 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 07 May 2006 21:36:25 +0200 Subject: Games submenus In-Reply-To: References: Message-ID: <445E4C39.9090108@hhs.nl> Christopher Stone wrote: > A few months ago I tried out GNOME to see if it has made any > improvements, and one thing I noticed is that the Games menu does not > have any submenus. As someone who installs every game available, this > made the menu quite unorganized. KDE has several submenus under games > such as Arcade, Card Games, Kids Games, Strategy etc. > > I am wondering if it is possible to define some sub-categories we can > use for games to help clean up the games menu? Does GNOME support > these submenus? And is it possible to define our own set of submenus > for the Games menu? I think that since there are going to be many > more games added over the coming months and years it would be prudent > to implement some standards for this if possible as the Games menu is > already quite large, especially in GNOME. > Yes, the Games menu under GNOME is getting really full. Another off topic but related question. Their is an official list of all official categories which can be used in a .desktop file at: http://standards.freedesktop.org/menu-spec/latest/apa.html According to this their is a separate category Education in which educational programs like gcompris and childsplay (review request https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190876 any takers?) could be put I've tried adding Education as a category to childplays .desktop file. Under gnome this adds a new entry to the main applications menu called Education between Applications and Games to which childsplay is added, childsplay also stays available under the Games menu. what do you think of using the Education category, on one hand I like the idea of having Education software separate from normal games and easy accessible through the main software menu otoh I think that adding a new main software menu entry for a handful of programs is a bit overkill. Opinions? Regards, Hans From nicu_fedora at nicubunu.ro Mon May 8 06:08:50 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 08 May 2006 09:08:50 +0300 Subject: Games submenus In-Reply-To: References: Message-ID: <445EE072.5060208@nicubunu.ro> Christopher Stone wrote: > > I am wondering if it is possible to define some sub-categories we can > use for games to help clean up the games menu? Does GNOME support > these submenus? And is it possible to define our own set of submenus > for the Games menu? I think that since there are going to be many > more games added over the coming months and years it would be prudent > to implement some standards for this if possible as the Games menu is > already quite large, especially in GNOME. Good question. For sometime I want to submit myself (but I keep not remembering about it at the right time) a RFE to prboom to have a submenu with two item: one for safe mode and another for the OpenGL version. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From j.w.r.degoede at hhs.nl Wed May 10 21:44:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 10 May 2006 23:44:32 +0200 Subject: Splitting content and engine for games where they come 1 one upstream tarbal Message-ID: <44625EC0.2000607@hhs.nl> Hi, I've been pushing about one gcompris release / day the last few days (I fixed a simple bug, but as these things go the fix introduced new bugS). That means that I've been pushing a whopping 60Mb / day. Which IMHO is not really acceptable. I know better testing -> less releases, but sometimes things don't work like that. For example todays gcompris release fixes a bug which is gnome-panel configuration dependent and now amount of testing would have shown it with my panel config. So I was thinking that I really need a seperate package for the gcompris-data where most of the Mb's are. Just creating a seperate sub-package won't help since that will get build with a new release of the main engine package too and will have the same newer e-v-r, resulting in the unchanged data still being updated. So I could make 2 spec files, so 2 really seperate packages, both with the same Source0, 3 problems: 1) ugly as hell 2) 2 large srpms, one of which will get updated each engine fix still eating mirror bandwidth to mirror 3) this will take twice the space for srpms on mirrors Now I had this idea which I would like to share: Add a %define which makes building the data sub-package conditonal and when a new release is needed with only engine fixes unset this define in the spec so that the -data subpackage doesn't get rebuild. Advantages: 1) No bandwidth wasted by mirrors mirroring huge data package for each small engine bugfix 2) Even more bandwidth saved by people who regular do a yum update and now only need to download the small engine update. Disadvantage: 1) The SRPM will still be large and get updated as a whole for each engine bugfix. This will take some bandwidth to mirror, but since not many people actually download SRPM's their won't be much other bandwidth usage caused by this. 2) Someone building from an SRPM which was just an engine fix release will first need to set the define to true otherwise he will get an incomplete (no -data package) build. I think that the advantages out way the disadvantages, what do you think? Regards, Hans From wart at kobold.org Wed May 17 21:10:47 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 17 May 2006 14:10:47 -0700 Subject: Games submenus In-Reply-To: References: Message-ID: <446B9157.8000504@kobold.org> Christopher Stone wrote: > A few months ago I tried out GNOME to see if it has made any > improvements, and one thing I noticed is that the Games menu does not > have any submenus. As someone who installs every game available, this > made the menu quite unorganized. KDE has several submenus under games > such as Arcade, Card Games, Kids Games, Strategy etc. > > I am wondering if it is possible to define some sub-categories we can > use for games to help clean up the games menu? Does GNOME support > these submenus? And is it possible to define our own set of submenus > for the Games menu? I think that since there are going to be many > more games added over the coming months and years it would be prudent > to implement some standards for this if possible as the Games menu is > already quite large, especially in GNOME. If I'm not mistaken, I believe the menus are built from the Category settings in the .desktop files. I wonder if there's a way to get submenus created for the various categories of games: ArcadeGame, StrategyGame, PuzzleGame, 3DGame, etc. I agree that having a Games menu so large that it can't be fully rendered on a 1600x1200 display is a little annoying. :) --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Wed May 17 23:16:00 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 17 May 2006 18:16:00 -0500 Subject: Games submenus In-Reply-To: <446B9157.8000504@kobold.org> (Michael Thomas's message of "Wed, 17 May 2006 14:10:47 -0700") References: <446B9157.8000504@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> If I'm not mistaken, I believe the menus are built from the MT> Category settings in the .desktop files. I wonder if there's a MT> way to get submenus created for the various categories of games: MT> ArcadeGame, StrategyGame, PuzzleGame, 3DGame, etc. My current (kde) desktop has "Arcade", "Board Games" and "Card Games". A random example, "Nibbles" is a board game; /usr/share/applications/gnome-gnibbles.desktop contains: Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; and the icon lives in the "Arcade" submenu. So I think this is already set up. In fact, looking through all .desktop files gives: hippogriff:/usr/share/applications> grep -i Categories *|grep -i game gnome-blackjack.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; gnome-freecell.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; gnome-gataxx.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; gnome-glines.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-gnect.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-gnibbles.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; gnome-gnobots2.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; gnome-gnomine.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-gnotravex.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-gnotski.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-gtali.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; gnome-iagno.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; gnome-mahjongg.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; gnome-same-gnome.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; gnome-sol.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; So it looks like these categories have already been decided upon but things haven't been completely implemented in the desktop environments. (For example, KDE doesn't have a submenu for "LogicGame".) - J< From wart at kobold.org Wed May 17 23:21:48 2006 From: wart at kobold.org (Michael Thomas) Date: Wed, 17 May 2006 16:21:48 -0700 Subject: Games submenus In-Reply-To: References: <446B9157.8000504@kobold.org> Message-ID: <446BB00C.1080106@kobold.org> Jason L Tibbitts III wrote: >>>>>>"MT" == Michael Thomas writes: > > > MT> If I'm not mistaken, I believe the menus are built from the > MT> Category settings in the .desktop files. I wonder if there's a > MT> way to get submenus created for the various categories of games: > MT> ArcadeGame, StrategyGame, PuzzleGame, 3DGame, etc. > > My current (kde) desktop has "Arcade", "Board Games" and "Card > Games". A random example, "Nibbles" is a board game; > /usr/share/applications/gnome-gnibbles.desktop contains: > > Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; > > and the icon lives in the "Arcade" submenu. So I think this is > already set up. In fact, looking through all .desktop files gives: > > hippogriff:/usr/share/applications> grep -i Categories *|grep -i game > gnome-blackjack.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; > gnome-freecell.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; > gnome-gataxx.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; > gnome-glines.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-gnect.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-gnibbles.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; > gnome-gnobots2.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; > gnome-gnomine.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-gnotravex.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-gnotski.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-gtali.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; > gnome-iagno.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; > gnome-mahjongg.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; > gnome-same-gnome.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; > gnome-sol.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; > > So it looks like these categories have already been decided upon but > things haven't been completely implemented in the desktop > environments. (For example, KDE doesn't have a submenu for > "LogicGame".) The accepted list of categories can be found at http://standards.freedesktop.org/menu-spec/latest/apa.html, as Hans previously pointed out. And as you found, many games already include some of these subcategories. Unfortunately, Gnome doesn't seem to use the subcategories for Games to create submenus in the panel. Is there a gnome desktop hacker on the list who can figure out what needs to be done to generate these submenus? --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Thu May 18 00:17:21 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 17 May 2006 19:17:21 -0500 Subject: Games submenus In-Reply-To: <446BB00C.1080106@kobold.org> (Michael Thomas's message of "Wed, 17 May 2006 16:21:48 -0700") References: <446B9157.8000504@kobold.org> <446BB00C.1080106@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> Is there a gnome desktop hacker on the list who can figure out MT> what needs to be done to generate these submenus? Oddly enough, it shouldn't be a gnome thing; the menu description is a standard. http://standards.freedesktop.org/menu-spec/latest/ However, it looks like some kde-specific setup is being done. Look in /etc/xdg/menus; compare applications.menu with kde-applications.menu. - J< From j.w.r.degoede at hhs.nl Thu May 18 05:18:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 18 May 2006 07:18:46 +0200 Subject: Games submenus In-Reply-To: <446BB00C.1080106@kobold.org> References: <446B9157.8000504@kobold.org> <446BB00C.1080106@kobold.org> Message-ID: <446C03B6.1040901@hhs.nl> Michael Thomas wrote: > Jason L Tibbitts III wrote: >>>>>>> "MT" == Michael Thomas writes: >> >> MT> If I'm not mistaken, I believe the menus are built from the >> MT> Category settings in the .desktop files. I wonder if there's a >> MT> way to get submenus created for the various categories of games: >> MT> ArcadeGame, StrategyGame, PuzzleGame, 3DGame, etc. >> >> My current (kde) desktop has "Arcade", "Board Games" and "Card >> Games". A random example, "Nibbles" is a board game; >> /usr/share/applications/gnome-gnibbles.desktop contains: >> >> Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; >> >> and the icon lives in the "Arcade" submenu. So I think this is >> already set up. In fact, looking through all .desktop files gives: >> >> hippogriff:/usr/share/applications> grep -i Categories *|grep -i game >> gnome-blackjack.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; >> gnome-freecell.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; >> gnome-gataxx.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; >> gnome-glines.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-gnect.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-gnibbles.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; >> gnome-gnobots2.desktop:Categories=GNOME;GTK;Game;ArcadeGame;X-Red-Hat-Base; >> gnome-gnomine.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-gnotravex.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-gnotski.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-gtali.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; >> gnome-iagno.desktop:Categories=GNOME;GTK;Game;X-Red-Hat-Base; >> gnome-mahjongg.desktop:Categories=GNOME;GTK;Game;BoardGame;X-Red-Hat-Base; >> gnome-same-gnome.desktop:Categories=GNOME;GTK;Game;LogicGame;X-Red-Hat-Base; >> gnome-sol.desktop:Categories=GNOME;GTK;Game;CardGame;X-Red-Hat-Base; >> >> So it looks like these categories have already been decided upon but >> things haven't been completely implemented in the desktop >> environments. (For example, KDE doesn't have a submenu for >> "LogicGame".) > > The accepted list of categories can be found at > http://standards.freedesktop.org/menu-spec/latest/apa.html, as Hans > previously pointed out. And as you found, many games already include > some of these subcategories. Unfortunately, Gnome doesn't seem to use > the subcategories for Games to create submenus in the panel. > > Is there a gnome desktop hacker on the list who can figure out what > needs to be done to generate these submenus? > We indeed need the assistence / opinion of a gnome hacker, maybe its a good idea to post this to the fedora-devel list? Regards, Hans From nicu_fedora at nicubunu.ro Thu May 18 05:42:31 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 18 May 2006 08:42:31 +0300 Subject: Games submenus In-Reply-To: <446C03B6.1040901@hhs.nl> References: <446B9157.8000504@kobold.org> <446BB00C.1080106@kobold.org> <446C03B6.1040901@hhs.nl> Message-ID: <446C0947.6050400@nicubunu.ro> Hans de Goede wrote: > > We indeed need the assistence / opinion of a gnome hacker, maybe its a > good idea to post this to the fedora-devel list? Or fedora-desktop-list -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro