Re: Gnome Shell Extension manager/framework planned?
On Sat, Jun 4, 2011 at 1:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Michael Wiktowy wrote: The cognative dissonance required to misconstrue an extension framework that has provided people with a previously impossible amount of customization in Gnome as something negative is quite astounding. The complaint is not about the fact that GNOME 3 is extensible, but about the fact that extensions are required for many things which should be built in, either by default (e.g. the shut down entry in the menu) or as an option. Yes. I happen to agree with that complaint and have installed the appropriate extension as a result. However, I was equally happy to just configure my power button to power off instantly rather than hibernate as an acceptable alternative that is in some ways even better than an option that pops up another dialog. ... and that complaint (which seems to snarkily creep into every single gnome-shell conversation regardless of applicability) has little to do with my response. Read it again in the context of the leap in logic from premise to conclusion in the quoted text ... and in the persecution complex replies further up ... and in various other numerous threads elsewhere that at time same time complain that Gnome developers are imposing their rigid world-view on them while, at the same time, offering an amazingly accessible extensibility ... a low enough barrier to entry that even I (with my meagre coding skills) am thinking of exploring the potential. I'm not terribly interested in making this another dog pile thread of people meta-arguing about people's world views of the way gnome-shell ought to have been designed and that everyone else besides them are flat-out wrong. There are many world-views out there. Some think that every option should be installed by default and selectable through configuration panels. Others think that good defaults should be chosen and that everyone should be forced into the model that was provided. I think that the gnome-shell option of offering a very basic, trimmed to the bone efficient desktop as a base to allow people to easily extend is a good middle ground that should satisfy the base-system-minimalists, total-newb-users and (maybe in time, once there are more extensions out there) the feature-maximalists all at the same time. Sometimes we have to get a little wet to get to the other side of the river. I just hope that other side of the river includes some system to configure extensions that doesn't involve editing text files or poking values into dconf using gsettings from the command line. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Shell Extension manager/framework planned?
On Fri, Jun 3, 2011 at 2:24 PM, tim.laurid...@gmail.com tim.laurid...@gmail.com wrote: The latest version of gnome-tweak-tool can enable/disable installed extentions http://timlau.fedorapeople.org/files/pics/tweek-tool.png That is excellent. I would assume that disabled extensions are just added to the blacklist using: $ gsettngs reset org.gnome.shell disabled-extensions $ gsettings set org.gnome.shell disabled-extensions ['hellowo...@gnome.org'] Ref: Shamelessly pulled from: http://blog.fpmurphy.com/2011/04/gnome-3-shell-extensions.html#ixzz1OLNZQmNZ Is there/can there be a way for extension creators to add a stanza of javascript that would cause some configuration options to show up in each extension's section or a format they could use in dconf that gnome-tweak-tool could read in and control? /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomboy orphaned
On Thu, Jun 2, 2011 at 5:28 PM, Rahul Sundaram methe...@gmail.com wrote: When set to auto start on a session launch, users expect it to sit on the tray (without any wrappers needed) and not show the search all notes window. That would be exactly what I want. I would even be happy with a command line option to enable this behaviour but there doesn't seem to be anything applicable at the moment. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Gnome Shell Extension manager/framework planned?
Hello, I am seeing a metric ton of extensions showing up for Gnome shell that are enhancing the shell in positive ways. Some are packaged singly; some are grouped together in bundles; some are configured by editing .js files directly. I am hesitant to install any of them because of the manual, bolted on feel of them and the risk of them causing trouble in the future. Is there some sort of extension management planned that would handle the separate enabling/disabling/configuration of individual extensions via the grand unified Settings menu? If this is under way, could extension makers be pointed towards it to future-proof their extensions. If not then I think it needs to be introduced early to avoid the mess that is beginning to develop. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for removal of package from Fedora repositories: dasher.x86_64
On Thu, Jun 2, 2011 at 3:00 PM, nodata l...@nodata.co.uk wrote: Hello, dasher in Fedora has been broken for me since Fedora 12. The bug I entered has recently been automatically closed. dasher doesn't work in 64-bit and can be crashed by asking it to go fullscreen. What's the procedure to get the package removed? Thanks. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=538336 Dasher works fine on a 64 bit system on F15 here. My version = dasher-4.10.1-2.fc12.x86_64 It looks like it hasn't been touched in some time though. There is a newer version out (4.11) available here: http://www.inference.phy.cam.ac.uk/dasher/Download.html Not sure if that will make the difference for you. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomboy orphaned
On Fri, May 6, 2011 at 1:06 PM, Adam Williamson awill...@redhat.com wrote: It doesn't integrate into GNOME 3 any more, since it relies on a panel applet and GNOME 3 doesn't support those. It seems to work really well in Gnome 3. The applet sits down in the notification bar (like empathy) and is almost as convenient to use as it used to be. I just wish I could figure out how to get it to start that way using gnome-session-properties ... it only seems to include a persistent notification bar icon if you start it after logging in. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Highlighting totem-upnp issue and possible koji problem?
On Thu, May 26, 2011 at 6:21 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2011-05-26 at 14:19 -0700, Adam Williamson wrote: You could say Bastien should have stopped the upnp package building at all rather than making it empty, but then if he didn't make something obsolete it, old versions would have stuck around and caused trouble, and if he makes something obsolete it, then re-introducing it when it actually works becomes more complex. One thing I forgot, btw - we can't disallow empty packages in general, because an empty package is a perfectly allowable and sometimes useful thing: an empty package with some dependencies is what we mean when we talk about 'metapackages'. So if you have a suite of packages which are generally installed and work together, you can create an empty package with dependencies on all the packages that typically go together to make up that suite, and the user can just do 'yum install foobar' and get all the right packages to make the Foobar suite work as intended. The use of metapackages is generally somewhat frowned on in Fedora in favour of comps-based groups, but there are a few. Thank you for the clarification. Poking around the Internets led me to believe that the totem-upnp plugin and coherence is dead. However, there is work is under way to make a totem grilo plugin that switches the upnp framework to Rygel. https://bugzilla.gnome.org/show_bug.cgi?id=628648 I'll keep my eyes open and hope that plugin makes it into F15 soon. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Highlighting totem-upnp issue and possible koji problem?
On Fri, May 27, 2011 at 3:03 PM, Adam Williamson awill...@redhat.com wrote: If that's the case it should probably be dropped and properly obsoleted rather than being shipped as an empty package, but I wouldn't want to run ahead of Bastien on this one. He's the totem lead developer as well as the Fedora maintainer, so he probably knows what's going on =) Bastien Nocera is the one working with upstream to get something out the door in that gnome bug that I quoted so, while the workings are not transparent, they are turning. I just wanted to pass on what I discovered to tie together the lack of totem-upnp with the birth of a new grilo plugin for people who are wondering why their plugin doesn't show up in the list after installing the package manually (like me). /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Highlighting totem-upnp issue and possible koji problem?
Hello, In trying to report a bug about the totem-upnp package not working in F15, I found that someone had already filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=694507 In it, the reason for it not working was totem-upnp was an *empty* package. I checked on koji and while the build of totem and it subpackages were completed, the build process seemed to have disabled the upnp plugin because of a problem PyGTK vs. pygobject issue and built an empty package. I can understand the whole build not being killed over an optional plugin. However, should koji build an empty package? I would think that koji should just not make that subpackage at all. Then at least people will not be tricked into updating a working package to an empty one should this slip though QA/testing ... which I am guessing this particular package has. Maybe even some indication that there was a successful build but with some caveats listed on the package build page: http://koji.fedoraproject.org/koji/buildinfo?buildID=242946 Are there other empty packages out there? /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-Shell and F14
On Thu, Apr 7, 2011 at 7:16 AM, Chris Jones chrisjo...@comcen.com.au wrote: Well when I installed Gnome-Shell just the other day it was only a ~10MB download and the installation was simple and didn't seem to alter anything. Am I getting confused or something between Gnome 3 and Gnome-Shell. Are they two different packages or the same thing? I believe the gnome-shell included in F13 and earlier was an early prototype that used toolkits and libraries that were available in Gnome 2. The latest gnome-shell uses updated resourses available only in Gnome 3 so there is no clear update path from one to the other without including the entire Gnome 3 infrastructure and I think that would be considered too big of a change to make within a Fedora version. /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
On Wed, Mar 30, 2011 at 4:59 PM, Chris Adams cmad...@hiwaay.net wrote: I think the problem here is how this was done, not as much what was done. Would it have been so much trouble to have discussed this in advance? ... it is way more efficient to beg forgiveness for picking a colour for a bikeshed than soliciting everyone's opinion ... especially when one is never planning to beg forgiveness. ;] /Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
