Re: extensions.gnome.org - Public Alpha Now Available
On Thu, Dec 1, 2011 at 5:41 PM, Jasper St. Pierre wrote: > There is no single sign on at the moment. Vinnicus Depizzol's study > mentioned that users would like a single sign on, and I'm all for > integrating with it once it appears. > > This seems to be something we could add to "online accounts" I think as a service. sri > On Thu, Dec 1, 2011 at 8:24 PM, Frederic Muller wrote: > > Hi! > > > > Very nice site. Is the login integrated with the GNOME wiki accounts, or > do > > we need to maintain a different user/password combination? > > > > Thanks. > > > > Fred > > > > > > On 12/02/2011 05:16 AM, Jasper St. Pierre wrote: > >> > >> We're happy to announce that extensions.gnome.org is now in > >> public alpha testing at: > >> > >> https://extensions.gnome.org > >> > >> If you have GNOME Shell 3.2 on your system, you should be able to > >> install extensions from the website via your browser. This uses the > >> "GNOME Shell Integration" browser plugin which is likely already > >> installed on your system if you have GNOME 3.2. The plugin only works > >> with Firefox currently - see "Known Bugs" below. > >> > >> We've seeded the site with a small set of extensions, including > >> the extensions from gnome-shell-extensions. If you are the author > >> of an extension that has been uploaded, and you want to take over > >> uploading future releases, please contact us, and we'll get you > >> access. > >> > >> The set of extensions on the site is still small compared to the total > >> number of extensions available. We expect more extensions to be > >> available over the next few weeks as authors upload them and they > >> are reviewed. > >> > >> About GNOME Shell Extensions > >> > >> > >> GNOME Shell extensions are small pieces of code written by third party > >> developers that modify the way GNOME works. (If you are familiar with > >> Chrome Extensions or Firefox Addons, GNOME Shell extensions are > >> similar to them.) > >> > >> Since extensions are created outside of the normal GNOME design and > >> development process, they are are supported by their authors, rather > >> than by the GNOME community. > >> > >> Extensions provide a way to prototype out new possible features for > >> future versions of GNOME, and for advanced users to make > >> customizations in ways that aren't necessarily compatible with the > >> overall design vision of GNOME, but are still cool and useful to > >> a subset of users. > >> > >> Since extensions become part of the core operating system, they need > >> to be checked for potential security problems. Extensions uploaded > >> to extensions.gnome.org go through code review before they are > >> made available for download. More information can be found at > >> https://extensions.gnome.org/about/. > >> > >> Known Bugs and Problems > >> === > >> > >> * There are some bugs that currently cause the browser plugin to > >> not work correctly in WebKit-based browsers like Epiphany > >> or Chrome. We will fix these bugs in subsequent releases of > >> GNOME Shell, but for now using Firefox to access > >> extensions.gnome.org is advised. > >> > >> * Extensions that use GSettings to store user settings cannot be > >> currently installed as a user; this limitation will be fixed > >> for GNOME 3.4. In the mean time, extension authors should > >> avoid the use of GSettings if they want to make their extension > >> available via extensions.gnome.org. > >> > >> * Due to a bug in GNOME Shell 3.2.1 code, the uninstall button > >> will not work for some extensions. Disabling extensions still > >> works, but if you want to remove an extension entirely, you'll > >> need to manually delete it from ~/.local/share/gnome-shell/extensions. > >> > >> Reporting Problems > >> == > >> > >> If you find problems with the site, please file them in > >> bugzilla.gnome.org against the 'extensions.gnome.org' component > >> of the website product. > >> > >> Problems with individual extensions should be reported using > >> the "Help! It didn't work!" link on the extension's page. > >> > >> Thanks to everybody that made this happen! > >> > >> -- > >> Jasper St. Pierre > >> ___ > >> desktop-devel-list mailing list > >> desktop-devel-list@gnome.org > >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > >> > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > -- > Jasper > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: extensions.gnome.org - Public Alpha Now Available
There is no single sign on at the moment. Vinnicus Depizzol's study mentioned that users would like a single sign on, and I'm all for integrating with it once it appears. On Thu, Dec 1, 2011 at 8:24 PM, Frederic Muller wrote: > Hi! > > Very nice site. Is the login integrated with the GNOME wiki accounts, or do > we need to maintain a different user/password combination? > > Thanks. > > Fred > > > On 12/02/2011 05:16 AM, Jasper St. Pierre wrote: >> >> We're happy to announce that extensions.gnome.org is now in >> public alpha testing at: >> >> https://extensions.gnome.org >> >> If you have GNOME Shell 3.2 on your system, you should be able to >> install extensions from the website via your browser. This uses the >> "GNOME Shell Integration" browser plugin which is likely already >> installed on your system if you have GNOME 3.2. The plugin only works >> with Firefox currently - see "Known Bugs" below. >> >> We've seeded the site with a small set of extensions, including >> the extensions from gnome-shell-extensions. If you are the author >> of an extension that has been uploaded, and you want to take over >> uploading future releases, please contact us, and we'll get you >> access. >> >> The set of extensions on the site is still small compared to the total >> number of extensions available. We expect more extensions to be >> available over the next few weeks as authors upload them and they >> are reviewed. >> >> About GNOME Shell Extensions >> >> >> GNOME Shell extensions are small pieces of code written by third party >> developers that modify the way GNOME works. (If you are familiar with >> Chrome Extensions or Firefox Addons, GNOME Shell extensions are >> similar to them.) >> >> Since extensions are created outside of the normal GNOME design and >> development process, they are are supported by their authors, rather >> than by the GNOME community. >> >> Extensions provide a way to prototype out new possible features for >> future versions of GNOME, and for advanced users to make >> customizations in ways that aren't necessarily compatible with the >> overall design vision of GNOME, but are still cool and useful to >> a subset of users. >> >> Since extensions become part of the core operating system, they need >> to be checked for potential security problems. Extensions uploaded >> to extensions.gnome.org go through code review before they are >> made available for download. More information can be found at >> https://extensions.gnome.org/about/. >> >> Known Bugs and Problems >> === >> >> * There are some bugs that currently cause the browser plugin to >> not work correctly in WebKit-based browsers like Epiphany >> or Chrome. We will fix these bugs in subsequent releases of >> GNOME Shell, but for now using Firefox to access >> extensions.gnome.org is advised. >> >> * Extensions that use GSettings to store user settings cannot be >> currently installed as a user; this limitation will be fixed >> for GNOME 3.4. In the mean time, extension authors should >> avoid the use of GSettings if they want to make their extension >> available via extensions.gnome.org. >> >> * Due to a bug in GNOME Shell 3.2.1 code, the uninstall button >> will not work for some extensions. Disabling extensions still >> works, but if you want to remove an extension entirely, you'll >> need to manually delete it from ~/.local/share/gnome-shell/extensions. >> >> Reporting Problems >> == >> >> If you find problems with the site, please file them in >> bugzilla.gnome.org against the 'extensions.gnome.org' component >> of the website product. >> >> Problems with individual extensions should be reported using >> the "Help! It didn't work!" link on the extension's page. >> >> Thanks to everybody that made this happen! >> >> -- >> Jasper St. Pierre >> ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: extensions.gnome.org - Public Alpha Now Available
Hi! Very nice site. Is the login integrated with the GNOME wiki accounts, or do we need to maintain a different user/password combination? Thanks. Fred On 12/02/2011 05:16 AM, Jasper St. Pierre wrote: We're happy to announce that extensions.gnome.org is now in public alpha testing at: https://extensions.gnome.org If you have GNOME Shell 3.2 on your system, you should be able to install extensions from the website via your browser. This uses the "GNOME Shell Integration" browser plugin which is likely already installed on your system if you have GNOME 3.2. The plugin only works with Firefox currently - see "Known Bugs" below. We've seeded the site with a small set of extensions, including the extensions from gnome-shell-extensions. If you are the author of an extension that has been uploaded, and you want to take over uploading future releases, please contact us, and we'll get you access. The set of extensions on the site is still small compared to the total number of extensions available. We expect more extensions to be available over the next few weeks as authors upload them and they are reviewed. About GNOME Shell Extensions GNOME Shell extensions are small pieces of code written by third party developers that modify the way GNOME works. (If you are familiar with Chrome Extensions or Firefox Addons, GNOME Shell extensions are similar to them.) Since extensions are created outside of the normal GNOME design and development process, they are are supported by their authors, rather than by the GNOME community. Extensions provide a way to prototype out new possible features for future versions of GNOME, and for advanced users to make customizations in ways that aren't necessarily compatible with the overall design vision of GNOME, but are still cool and useful to a subset of users. Since extensions become part of the core operating system, they need to be checked for potential security problems. Extensions uploaded to extensions.gnome.org go through code review before they are made available for download. More information can be found at https://extensions.gnome.org/about/. Known Bugs and Problems === * There are some bugs that currently cause the browser plugin to not work correctly in WebKit-based browsers like Epiphany or Chrome. We will fix these bugs in subsequent releases of GNOME Shell, but for now using Firefox to access extensions.gnome.org is advised. * Extensions that use GSettings to store user settings cannot be currently installed as a user; this limitation will be fixed for GNOME 3.4. In the mean time, extension authors should avoid the use of GSettings if they want to make their extension available via extensions.gnome.org. * Due to a bug in GNOME Shell 3.2.1 code, the uninstall button will not work for some extensions. Disabling extensions still works, but if you want to remove an extension entirely, you'll need to manually delete it from ~/.local/share/gnome-shell/extensions. Reporting Problems == If you find problems with the site, please file them in bugzilla.gnome.org against the 'extensions.gnome.org' component of the website product. Problems with individual extensions should be reported using the "Help! It didn't work!" link on the extension's page. Thanks to everybody that made this happen! -- Jasper St. Pierre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: extensions.gnome.org - Public Alpha Now Available
On Thu, Dec 1, 2011 at 5:46 PM, Bastien Nocera wrote: > Em Thu, 2011-12-01 às 16:16 -0500, Jasper St. Pierre escreveu: >> We're happy to announce that extensions.gnome.org is now in >> public alpha testing at: >> >> https://extensions.gnome.org > >> Known Bugs and Problems >> === >> >> * There are some bugs that currently cause the browser plugin to >> not work correctly in WebKit-based browsers like Epiphany >> or Chrome. We will fix these bugs in subsequent releases of >> GNOME Shell, but for now using Firefox to access >> extensions.gnome.org is advised. > > The WebKitGTK+ hackers at the hackfest these days are not amused. They > are thinking of declaring war on the Kingdom Of Extensions. Is it their > fault? Do they need to send diplomats, or is a land war in Asia the only > answer? > If any WebKit hacker wants to comment, there are two bugs: 1) We don't set the flag that says we want to use XEmbed. We're an NPRuntime plugin that doesn't need to draw anything. With Firefox, we get by alright. WebKit aborts because it thinks we want to use the Xt mainloop. See the chromium bug[0] for information. 2) We don't obey the UTF8Length parameter of a string NPVariant and just use the bytes as a NUL-terminated string blindly. On Firefox, this is fine. On WebKit, there's extra junk after the string data, so we need to switch to a g_strndup. [0] http://code.google.com/p/chromium/issues/detail?id=38229 -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: extensions.gnome.org - Public Alpha Now Available
Em Thu, 2011-12-01 às 16:16 -0500, Jasper St. Pierre escreveu: > We're happy to announce that extensions.gnome.org is now in > public alpha testing at: > > https://extensions.gnome.org > Known Bugs and Problems > === > > * There are some bugs that currently cause the browser plugin to > not work correctly in WebKit-based browsers like Epiphany > or Chrome. We will fix these bugs in subsequent releases of > GNOME Shell, but for now using Firefox to access > extensions.gnome.org is advised. The WebKitGTK+ hackers at the hackfest these days are not amused. They are thinking of declaring war on the Kingdom Of Extensions. Is it their fault? Do they need to send diplomats, or is a land war in Asia the only answer? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: extensions.gnome.org - Public Alpha Now Available
On Thu, Dec 1, 2011 at 4:16 PM, Jasper St. Pierre wrote: > We're happy to announce that extensions.gnome.org is now in > public alpha testing at: > > https://extensions.gnome.org > I just tried this. This is absolutely awesome. Great work! Congratulations to everyone involved. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
extensions.gnome.org - Public Alpha Now Available
We're happy to announce that extensions.gnome.org is now in public alpha testing at: https://extensions.gnome.org If you have GNOME Shell 3.2 on your system, you should be able to install extensions from the website via your browser. This uses the "GNOME Shell Integration" browser plugin which is likely already installed on your system if you have GNOME 3.2. The plugin only works with Firefox currently - see "Known Bugs" below. We've seeded the site with a small set of extensions, including the extensions from gnome-shell-extensions. If you are the author of an extension that has been uploaded, and you want to take over uploading future releases, please contact us, and we'll get you access. The set of extensions on the site is still small compared to the total number of extensions available. We expect more extensions to be available over the next few weeks as authors upload them and they are reviewed. About GNOME Shell Extensions GNOME Shell extensions are small pieces of code written by third party developers that modify the way GNOME works. (If you are familiar with Chrome Extensions or Firefox Addons, GNOME Shell extensions are similar to them.) Since extensions are created outside of the normal GNOME design and development process, they are are supported by their authors, rather than by the GNOME community. Extensions provide a way to prototype out new possible features for future versions of GNOME, and for advanced users to make customizations in ways that aren't necessarily compatible with the overall design vision of GNOME, but are still cool and useful to a subset of users. Since extensions become part of the core operating system, they need to be checked for potential security problems. Extensions uploaded to extensions.gnome.org go through code review before they are made available for download. More information can be found at https://extensions.gnome.org/about/. Known Bugs and Problems === * There are some bugs that currently cause the browser plugin to not work correctly in WebKit-based browsers like Epiphany or Chrome. We will fix these bugs in subsequent releases of GNOME Shell, but for now using Firefox to access extensions.gnome.org is advised. * Extensions that use GSettings to store user settings cannot be currently installed as a user; this limitation will be fixed for GNOME 3.4. In the mean time, extension authors should avoid the use of GSettings if they want to make their extension available via extensions.gnome.org. * Due to a bug in GNOME Shell 3.2.1 code, the uninstall button will not work for some extensions. Disabling extensions still works, but if you want to remove an extension entirely, you'll need to manually delete it from ~/.local/share/gnome-shell/extensions. Reporting Problems == If you find problems with the site, please file them in bugzilla.gnome.org against the 'extensions.gnome.org' component of the website product. Problems with individual extensions should be reported using the "Help! It didn't work!" link on the extension's page. Thanks to everybody that made this happen! -- Jasper St. Pierre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
On Thu, Dec 1, 2011 at 13:00, Frederic Peters wrote: > But despite that announcement, most of the application module > maintainers continued to follow the release schedule, and were part of > releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/ > ) > Yes, we want that and we get it without having to fight about Vinagre vs. Boxes, for example. GNOME's process is a great set of best practices to follow without having to involve the release team in picking GNOME favorites (eg. The One True Music Player). And because it gives GNOME translation and documentation teams an implicit schedule they can rely on. Want to be part of GNOME? Join are community and you are. Want to be a GNOME App? Follow our practices and you are. Again, the question, what's the meaning of the apps moduleset? It's > been the place for "a serie of applications" handled by the release > team, remnants of the old modulesets, but doesn't it lack some more > formal definition? > It shouldn't be handled by the release team because that gets us in to these threads all over again which was entirely the point of implementing this change. If that's been going on, it really shouldn't be. The i18n coordinators add modules to Damned Lies; the Documentation coordinators (eg. Shawn) track the Mallard work across modules; in the same way, the release team or anyone with git access, really, can and should be encouraged to add their build instructions to the apps moduleset. If it's applications released by the GNOME project, shouldn't we get > back some release criteria? > Module maintainers release their modules; GNOME provides infrastructure and a community. If it's just to facilitate jhbuilding, what's the difference between > the -apps and the -world modulesets? > That should be fixed, I agree. Well, there was the moduleset reorg announcement, but after that we > also had 8 months of practice, and they don't quite fit, because in > some sense, what has changed? nothing, applications still wanted to be under the GNOME shelter, and the release team kept offering that. > > We put up a "feature proposal period" in place, and applications kept > being proposed, and that discrepancy is part of this thread, Vincent > wrote: "I said that I didn't feel Boxes should be tracked as a feature". > If that's what happened then did we ever /really/ implement the change that we all agreed on? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Jason D. Clinton wrote: > When did this happen? I admit I've been a bit disconnected for a few months > but even if the Featured Apps didn't get updated, it was never intended to > be an exhaustive list. In fact, I explicitly stated in > the announcement (with blessing from the Release Team) that there was no > mechanism by which to apply for "featured" status and it was to be > construed as nothing more than what it was: purely a marketing designation. > There were only 8 Featured Apps the 3.0 and 3.2 release (these eight > http://www.gnome.org/applications/) *and* we still had an apps moduleset > for both releases. But what's the meaning of the apps moduleset? It is not about featured apps, as you wrote earlier: This list is not jhbuild-maintained because it is a function of marketing, not development. The list of featured applications is maintained on our web properties and has nothing to do with any official module status. -- http://git.gnome.org/browse/jhbuild/commit/?id=12a0bd91 And applications got out of release team scope in the announcement you refer to: Release Team continue to administer the formal new module proposal process for Core (that is, everything which would be considered part of "GNOME OS" and is currently in the Core moduleset) -- https://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00045.html But despite that announcement, most of the application module maintainers continued to follow the release schedule, and were part of releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/) Again, the question, what's the meaning of the apps moduleset? It's been the place for "a serie of applications" handled by the release team, remnants of the old modulesets, but doesn't it lack some more formal definition? If it's applications released by the GNOME project, shouldn't we get back some release criteria? If it's just to facilitate jhbuilding, what's the difference between the -apps and the -world modulesets? > So what has changed? I think that there's some confusion here and I'd like > to clear it up. As far as I know, everything is just fine: Featured Apps is > a marketing function and apps moduleset can include anything to facilitate > jhbuilding. Well, there was the moduleset reorg announcement, but after that we also had 8 months of practice, and they don't quite fit, because in some sense, what has changed? nothing, applications still wanted to be under the GNOME shelter, and the release team kept offering that. We put up a "feature proposal period" in place, and applications kept being proposed, and that discrepancy is part of this thread, Vincent wrote: "I said that I didn't feel Boxes should be tracked as a feature". Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
On Thu, Dec 1, 2011 at 03:00, Frederic Peters wrote: > Jason D. Clinton wrote: > > > > Because there's a big difference between an integrated, designed, > > > polished, documented and translated GNOME app and something that > happens > > > to use GTK, right? > > > > > > > That's the distinction between Featured Apps and everything else in the > > world. Core is for, well, core OS and desktop functionality that everyone > > can't do without. The only thing requiring approval today is Platform and > > Core. > > > > It certainly belongs in the apps moduleset where it is now so that it can > > facilitate easy jhbuilding. There's no approval required for the apps > > moduleset nor for Feature Apps (which is only a marketing distinction). > > Thanks for bringing this as that was certainly the plan but (by lack > of resources in the marketing team?) it fell down and we got back to > square one with the release team "somehow" handling applications, in > this case "Boxes". > > "Somehow", because we didn't redefine criterias, in terms of > documentation, schedule, all the things we had before. If people wants > the release team to handle apps, we should get back to some processes. > When did this happen? I admit I've been a bit disconnected for a few months but even if the Featured Apps didn't get updated, it was never intended to be an exhaustive list. In fact, I explicitly stated in the announcement (with blessing from the Release Team) that there was no mechanism by which to apply for "featured" status and it was to be construed as nothing more than what it was: purely a marketing designation. There were only 8 Featured Apps the 3.0 and 3.2 release (these eight http://www.gnome.org/applications/) *and* we still had an apps moduleset for both releases. So what has changed? I think that there's some confusion here and I'd like to clear it up. As far as I know, everything is just fine: Featured Apps is a marketing function and apps moduleset can include anything to facilitate jhbuilding. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boxes and 3.4
Jason D. Clinton wrote: > > Because there's a big difference between an integrated, designed, > > polished, documented and translated GNOME app and something that happens > > to use GTK, right? > > > > That's the distinction between Featured Apps and everything else in the > world. Core is for, well, core OS and desktop functionality that everyone > can't do without. The only thing requiring approval today is Platform and > Core. > > It certainly belongs in the apps moduleset where it is now so that it can > facilitate easy jhbuilding. There's no approval required for the apps > moduleset nor for Feature Apps (which is only a marketing distinction). Thanks for bringing this as that was certainly the plan but (by lack of resources in the marketing team?) it fell down and we got back to square one with the release team "somehow" handling applications, in this case "Boxes". "Somehow", because we didn't redefine criterias, in terms of documentation, schedule, all the things we had before. If people wants the release team to handle apps, we should get back to some processes. So I guess my questions are about roles, marketing team? release team? and consequences. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
