Bug#768400: ITP: libjs-iframe-resizer -- Javascript library that enables the automatic resizing of iframes
Package: wnpp Severity: wishlist Owner: Maxime Chatelle * Package name: libjs-iframe-resizer Version : 2.6.2 Upstream Author : David J. Bradshaw * URL : https://github.com/davidjbradshaw/iframe-resizer * License : MIT Programming Lang: Javascript Description : Javascript library that enables the automatic resizing of iframes This library enables the automatic resizing of the height and width of both same and cross domain iFrames to fit the contained content. It uses postMessage to pass messages between the host page and the iFrame and when available MutationObserver to detect DOM changes, with a fallback to setInterval for IE8-10. . The code also detects browser events that can cause the content to resize; provides functions to allow the iFrame to set a custom size and close itself. Plus it supports having multiple iFrames on the host-page and additionally provides for the sending of simple messages from the iFrame to the parent page. . For security, by default the host-page automatically checks that the origin of incoming messages are from the domain of the page listed in the src property of the iFrame. Greetings, xakz -- Maxime Chatelle (xakz) gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B pgpIjr_03qDSO.pgp Description: PGP signature
Bug#768401: ITP: libjs-collapsible-lists -- Javascript library that turns a normal HTML list into a tree view
Package: wnpp Severity: wishlist Owner: Maxime Chatelle * Package name: libjs-collapsible-lists Version : 1.0.0 Upstream Author : Stephen Morley * URL : http://code.stephenmorley.org/javascript/collapsible-lists/ * License : CC0 Programming Lang: Javascript Description : Javascript library that turns a normal HTML list into a tree view Long nested lists on web pages can be difficult to understand, especially if the visitor must scroll to see the entire list. The tree view, a user interface widget that displays hierarchical data as nested lists, solves this problem by making lists collapsible and expandable; a list can be opened by or closed by clicking on its parent list item. CollapsibleLists is a JavaScript object that turns a normal HTML list into a tree view. Click on the items with plus and minus icons to expand and collapse their lists. -- Maxime Chatelle (xakz) gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B pgpLIhmKO740Q.pgp Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 12:11:12PM +0100, Guillem Jover wrote: > Hi! > > On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote: > > On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: > > > I'd like to note that there are very good reasons for a debian-only, > > > overlay-style packaging repository too. This section should, in my > > > opinion, at least acknowledge that, and briefly mention it as an option. > > > I find it a bit sad that it was outright discouraged. > > > > Personally I wouldn't use anything other than debian-only repos, at > > least for those where I have a choice. I also actively avoid > > contributing to packages that don't use such repos. > > Exactly. In addition I also only tend to «git clone» native packages, > for anything else I just simply «apt-get source» and can be pretty sure > what I will get, because the alternatives are just annoying. > > As a maintainer and upstream, I also find crawling the packaging repos > for many of the RPM based distros, Gentoo and BSDs port collections for > example, actually way more pleasant and clear than many of the Debian > packaging repos with packaging bits mixed with upstream code TBH, because > they only have the build recipes and possibly patches, so I don't need > to know their tools or path layouts to be able to find the packaging > bits, because they are just obviously there, in front of you, alone. > > Not to mention the “unholy” practice of having to store autogenerated > stuff shipped only in release tarballs in a git repo! :) > > I also fantasize sometimes of a day where the whole distribution would > be stored on VCSs (per package) with a debian-only layout, so that I > could have a local copy for the whole archive, taking only a couple of > GiB at most, instead of the monstrosity of a complete exploded sources > archive (according to <http://sources.debian.net/stats/>, that's currently > 205 GiB, w/o including git history, which could easily double that > size); and don't tell me space is cheap, because that does not take > into account the downloading, nor the huge amount of wasted space if > you only want the packaging bits. > > Even though it might be more convenient for the maintainer, in general > I find the mixed up repos to be a disservice to the rest of the world. I share your point of view so much. Having upstream history into a packaging repo is probably too much for most of the debian packages. Not to mention pristine-tar, Debian servers already contain .orig.tar.gz tarballs... Making buildd be able to work directly from VCS can be a plus also. No more sync problem between NMU, and/or contributor that forgot (or ignore) to push onto the repository. Where the VCS *is* the .debian.tar.gz. From this, it's easy to formalize helper tools. Ok, I know that is too much changes. But maybe there is some ideas here. Greetings, -- Maxime Chatelle (xakz) gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112164619.ga10...@hermes.rxsoft.eu
ESA Summer of Code in Space 2011
Hi, This annonce may be interresting. :) It's a gsoc-like, but by european space agency. http://sophia.estec.esa.int/socis2011/ cheers, xakz -- Maxime Chatelle, human from earth, 01000.cm94IGxvdmVyCg==.kpr 79E0 25F5 06C5 5C7F F57C BADD 13EE 911A 8A1A 9DE9 pgpeNa0lupARV.pgp Description: PGP signature
Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)
Package: wnpp Severity: wishlist Owner: Maxime Chatelle * Package name: cakephp2 Version : 2.5.6 Upstream Author : http://cakefoundation.org/ * URL : http://cakephp.org/ * License : MIT Programming Lang: PHP Description : MVC rapid application development framework for PHP (2.x series) CakePHP is a flexible model-view-controller rapid application development framework for PHP inspired by Ruby on Rails. . CakePHP makes developing applications swiftly and with the least amount of hassle: . * Integrated CRUD for database interaction and simplified queries including scaffolding * Request dispatcher with good looking, custom URLs * Caching * Localisation * Fast and flexible templating (PHP syntax, with helpers) * Useful core features (access control lists, AJAX integration, etc.) * Works from any website subdirectory Regards -- Maxime Chatelle gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141126184721.ga4...@hermes.rxsoft.eu
Re: Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)
On Fri, Nov 28, 2014 at 08:27:51PM +0100, Moritz Mühlenhoff wrote: > Maxime Chatelle schrieb: > > Package: wnpp > > Severity: wishlist > > Owner: Maxime Chatelle > > > > * Package name: cakephp2 > > Version : 2.5.6 > > Upstream Author : http://cakefoundation.org/ > > * URL : http://cakephp.org/ > > * License : MIT > > Programming Lang: PHP > > Description : MVC rapid application development framework for PHP > > (2.x series) > > CakePHP is a flexible model-view-controller rapid application development > > framework for PHP inspired by Ruby on Rails. > > Why a separate source package? cakephp is orphaned, you should rather > adopt it and update it to the most recent upstream release. I'm already adopting cakephp, in fact I just need a sponsor, the last 1.x upstream release is waiting on mentors.d.n cakephp (1.x series) is still used by peoples (120+ installs in popcon) and still maintained by upstream. So instead of forcing users to migrate their webapp I prefer to add alternative. And 2.x series is not backward compatible with 1.x series. Regards, -- Maxime Chatelle gpg: 5111 3F15 362E 13C6 CCDE 03BE BFBA B6E3 24AE 0C5B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141128201710.ga4...@hermes.rxsoft.eu
