Re: [Plone-developers] Plone 5 Theme

ops.. "*only reset.css or normalize.css (my favorite)...*"


2013/11/21 Felipe Duardo <[email protected]>

> What I do not like the Plone when creating a theme,
> use "*!important*" for almost all attributes of the css selectors ..
> Maybe being a child in Plone, I'm working in the wrong way
>
> In other CMS's, my favorite themes are those that CSS
> only reset.css normalize.css or (my favorite)...
>
> I think this would be a legal way for the initial themes Plone
>
> Att.
>
>
> 2013/11/21 André Nogueira <andre-grcfPhwenrP3rCIxTHco+PB2xoqF/[email protected]>
>
>> I know a lot of people that just use Plone as a framework.
>> Just edit one custom CSS file and transform the Frontend. No python
>> and no PHP too :) And no XML :)
>> This is the easyer and most important way to use Plone now
>>
>> To me, the basic steps for a new themer (for regular users not
>> advanced users) is:
>> 1. Clone the default DIazo theme
>> 2. Try to find and change the logo
>> 3. Try to make some CSS chances
>>
>> Newcommer and basic users will never create a Diazo theme from the
>> scracth. I dont see this action as a trivial action. Can be trivial
>> just for advanced front end developers
>>
>> To me, trown all the Front end responsability to custom diazo themes
>> could kill one of the Plone most important feature: Accessibility. We
>> really need a strong starting point for new themes and for small
>> customizations.
>>
>> To me, the only option to make plone more popular with the public you
>> are aiming, is to reach this 5 points:
>>
>> 1. One click install in production (something like Ploud or ready to
>> use droplet in digital ocean or similar players)
>> 2. A great number of high quality themes.
>> 3. Very easy way to customize this themes (change logo and base
>> colors). A editor based in LESS/SASS will be amazing.
>> 4. Very easy way to install addons
>> 5. very easy way to updat Plone and addons
>>
>> Only after that, Plone can become popular.
>>
>> Andre Nogueira
>> andre-grcfPhwenrP3rCIxTHco+PB2xoqF/[email protected]
>> Simples Consultoria
>> www.simplesconsultoria.com.br
>> Tel. (11) 3898-2121
>>
>>
>> On Thu, Nov 21, 2013 at 6:40 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
>> > Hi,
>> >
>> > I'd be interested to know of those in this discussion how many do
>> custom themes on a regular basis? ie take html/css or a PSD from a designer
>> and construct a theme.
>> > I suspect we're coming at this issue from a variety of different
>> experiences and perhaps there are a lot of people on the plone developers
>> list who consider themselves more of a python programmer than a FE
>> developer.
>> > I'm not saying that plone shouldn't be useful out of the box but I am
>> saying it's a huge barrier to it's adoption by other that it is so hard to
>> customise. Diazo is a massive improvement in this respect and I can only
>> think that you must be doing very different work from us if you don't see
>> that.
>> > As an example, this week we're tutoring a fedral government department
>> on how to create their own intranet. They've already installed, configured
>> it, installed the plugins they want, setup the IA, dummy content etc. They
>> have got a html/css design mockup in php from a web agency based on their
>> ideas (we had no input). Now we'll do a day workshop with them using diazo,
>> the theme editor and within the week they will have a working intranet. No
>> python written, no php written. However the biggest hurdle will be
>> integrating the editing UI, something that will be fixed with toolbar. The
>> next biggest hurdle is to make sure all the bits of Plone UI and the right
>> versions of jquery etc still work with the theme, or someone has to rewrite
>> them.
>> >
>> > Also trying to attract Python developers to Plone IMO is a waste of
>> time. I understand the attraction. We love python, and we love other stuff
>> python people do. However 99% of python programmers don't need or like a
>> CMS. A CMS solves problems they don't have. Most python programmers are
>> happy with static html generation like pelican. I think it's our pride that
>> makes us want to be recognised within the Plone community for doing
>> something worthy. I certainly feel that sometimes.
>> > The solution however is to grow Plone itself into something widely used
>> and admired. Not by pythonistas but by people who want to build websites
>> quickly and that look awesome and have huge power underneath. At least then
>> not only will we still have jobs working with software we love, by
>> pythonistas would at least have to admit we created something popular even
>> if it's not something they can use.
>> > We won't create this popularity by trying to compete with flask or
>> django or by make an out a kind of app container hybrid framework thing. If
>> you want to build forms and apps etc that need complex FE widgets etc then
>> you probably shouldn't be using a CMS IMO (Except if you want to do it TTW
>> in which Plone/Plomino is great).
>> > To do this we need to attract the very people that aren't here.
>> Intergrators/themers. They don't care about Plone widgets and frameworks.
>> They just want software that tick all the boxes for their clients/editors,
>> and doesn't get in the way of implementing their design.
>> >
>> > Dylan Jay
>> >
>> > ---
>> > www.pretagov.com - Secure SaaS for Government hosted locally.
>> > P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75
>> >
>> >
>> >
>> > On 20 Nov 2013, at 11:51 pm, Alex Clark <[email protected]> wrote:
>> >
>> >> On 11/20/13, 5:25 AM, Rok Garbas wrote:
>> >>> Quoting Ryan Foster (2013-11-20 08:08:12)
>> >>>> On Nov 19, 2013, at 6:46 PM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
>> >>>>
>> >>>>>
>> >>>>> On 20 Nov 2013, at 4:26 am, David Glick (Plone) <
>> david.glick-z4DKO/[email protected]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> On 11/19/13, 1:27 AM, Dylan Jay wrote:
>> >>>>>>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <
>> david.glick-z4DKO/[email protected]>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On 11/18/13, 4:13 AM, Ramon Navarro Bosch wrote:
>> >>>>>>>>> Sorry for the cross-posting!
>> >>>>>>>>>
>> >>>>>>>>> I decided to write down my opinions after working at Arnhem
>> sprint on
>> >>>>>>>>> plone 5 theme, it's just a dump of what I have in mind :
>> >>>>>>>>>
>> >>>>>>>>>
>> http://bloc.jardigrec.cat/2013/11/plone-5-theme-plonethemebarceloneta.html
>> >>>>>>>>>
>> >>>>>>>>> Go go go !
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> I think there's been a big thing missing from the discussion of
>> >>>>>>>> plone.app.toolbar and isolating theme resources from Plone edit
>> UI
>> >>>>>>>> resources. That big thing is what it means for add-on authors:
>> how can
>> >>>>>>>> we make sure add-ons get a look and feel that fits with a site's
>> custom
>> >>>>>>>> theme?
>> >>>>>>>>
>> >>>>>>>> Some add-ons only change things in the edit UI, and they'll be
>> fine. But
>> >>>>>>>> what about add-ons that provide their own portlets or viewlets,
>> or
>> >>>>>>>> a custom template that renders in the content area? These are
>> common.
>> >>>>>>> +1 it's something we haven't talked enough about.  However I'm -1
>> that
>> >>>>>>> it's common.  These days a lot of the front end (FE) facing
>> plugins can
>> >>>>>>> be replaced by custom diazo based solutions quickly since most
>> plugins
>> >>>>>>> aren't generic enough to meet the needs of the theme. A good
>> example is
>> >>>>>>> a carousel.
>> >>>>>>>
>> >>>>>>> I had a look at plugins we often use that are FE general plugins
>> that do
>> >>>>>>> require their own js and css.  - PloneFormGen - PloneBoard -
>> Plomino
>> >>>>>>> - collective.recaptcha - oembed and video stuff
>> >>>>>>>
>> >>>>>>> Thats pretty much it. Some of these use their own frameworks, for
>> >>>>>>> instance Plomino uses lots of JQuery UI so they don't rely on
>> much from
>> >>>>>>> Plone
>> >>>>>>
>> >>>>>> Wow, I guess we totally disagree.
>> >>>>>>
>> >>>>>> Here are some other examples: - collective.cover -
>> Solgema.fullcalendar
>> >>>>>> - collective.plonetruegallery - eea.facetednavigation -
>> cioppino.twothumbs
>> >>>>>>
>> >>>>>> If addons no longer have a common library of markup they can
>> expect to
>> >>>>>> work and a consistent way to inject their own Javascript and CSS,
>> I think
>> >>>>>> we basically destroy the Plone add-on ecosystem. And I think that
>> >>>>>> ecosystem is a huge part of Plone's continued success. Without it
>> we only
>> >>>>>> have an archaic web framework with a better-than-average editing
>> UI.
>> >>>>>
>> >>>>> I'm not saying we remove the consistent way to inject CSS and JS.
>> I'm
>> >>>>> saying we reduce as much as possible the opinion plone is putting
>> on themes
>> >>>>> about what CSS and JS they have to implement to make a site work.
>>  It isn't
>> >>>>> destroying the eco-system, it will make it stronger by making plugin
>> >>>>> developers develop plugins which are designed to be themed as
>> opposed to be
>> >>>>> ones that can only be used on sites that look like Plone sites.
>>  Most of
>> >>>>> the above plugins install their own JS which may or may not be
>> compatible
>> >>>>> with your theme. For example collective.cover uses deco.js.
>> Facetednav uses
>> >>>>> it's own JS. The themer will have to go through a process of
>> testing these
>> >>>>> themes to make sure they work with their theme regardless of if
>> they are
>> >>>>> made to be compatible with the default plone theme or not. Your
>> suggestion
>> >>>>> doesn't prevent this unless we install every framework known. There
>> really
>> >>>>> isn't this "common" library of JS and CSS that works with all
>> themes. By
>> >>>>> enforcing such a set of CSS and JS you are instantly dating and
>> >>>>> straightjacketing Plone to only be used by themers that know how to
>> work
>> >>>>> with Plones version of jquery, plones version or Jquery UI, plones
>> version
>> >>>>> of overlays etc. We keeping the club of people that can use Plone
>> to just
>> >>>>> us experienced Plone developers and missing the opportunity to make
>> Plone
>> >>>>> a system that is inviting for anyone to create a site or intranet.
>>  I see
>> >>>>> no problem with plugins being opinionated and installing their own
>> CSS and
>> >>>>> JS but obviously they have to do this at the risk of making it less
>> likely
>> >>>>> to be used by others since it will require more integration work.
>> Make all
>> >>>>> Plone sites look the same doesn't solve that problem.  For example
>> Plone's
>> >>>>> current use of jquery means that it's impossible to use custom JS
>> in your
>> >>>>> theme that requires a later version of jquery.  A Plone default
>> theme
>> >>>>> should be an "example" theme, not the basis for which all themes in
>> Plone
>> >>>>> should be built. I think it would be great to ship with multiple
>> example
>> >>>>> themes, perhaps based on different frameworks. If a plugin requires
>> the use
>> >>>>> of bootstrap or the CSS that comes with a certain theme then they
>> should
>> >>>>> make that an explicit dependency of their plugin. If we can
>> automate that,
>> >>>>> even better.
>> >>>>
>> >>>> FWIW, I think flexibility can be a dangerous road when it comes to
>> theming
>> >>>> and can lead to issues with CSS and markup integrity. In general, if
>> addons
>> >>>> don’t have guidelines for markup and CSS they will make their own
>> choices,
>> >>>> which then makes them harder to support and theme.  A framework, in
>> this case
>> >>>> Bootstrap, might actually make theming Plone simpler and more
>> approachable to
>> >>>> new themers.
>> >>>>
>> >>>> I truly don’t think it would be easier to theme Plone if it were
>> less styled
>> >>>> and addons provided less in terms of markup and styles.
>> >>>>
>> >>>> I also don’t prefer it when addons decide to use their own
>> opinionated
>> >>>> frameworks that differ from plone core. In some cases it is
>> justified but in
>> >>>> others it is just an opinion that gets in the way of my integrating
>> the addon
>> >>>> into my theme.
>> >>>>
>> >>>> If we provide logical defaults and guidelines for addons that are
>> popular,
>> >>>> well tested, neutral but attractive, and easy to customize with
>> little
>> >>>> effort, I believe we make things much easier for most themers.  A
>> framework
>> >>>> does that.  Bootstrap is the logical choice because it has the most
>> backing
>> >>>> and popular support.
>> >>>>
>> >>>> Nothing about using Bootstrap as a starting point leads me to think
>> that
>> >>>> every site has to look the same.  If anything I think it will open
>> the door
>> >>>> for many more themes.  It does however, make it more difficult to use
>> >>>> a different framework. Personally, I am fine with that trade off
>> considering
>> >>>> the simplicity that consistency and logical defaults might provide.
>> My worst
>> >>>> case scenario is that Plone makes no assertions about markup and
>> styling and
>> >>>> addons and themes diverge further than they already have.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>>>> In terms of Plone itself there is very little that needs styling
>> or JS
>> >>>>>>> that is FE. Things like the contact form and public registrations
>> we
>> >>>>>>> should try and remove I believe. These things we almost always
>> replace by
>> >>>>>>> things like PFG as it gives more flexibility. We even do public
>> user
>> >>>>>>> registration with PFG now via collective.pfg.signup. Commenting is
>> >>>>>>> perhaps another feature that requires special CSS. It's not
>> something
>> >>>>>>> I've ever used but perhaps it needs to go out of the core too?
>> Live
>> >>>>>>> search should be removed since it's a performance killer anyway
>> and
>> >>>>>>> almost no public site would want to turn this on unless they can
>> >>>>>>> guarantee a very light load.  Once you take all of that out, I
>> think you
>> >>>>>>> only very basic styles such as those that can be set in tinymce.
>>  I think
>> >>>>>>> we should make this set of style as small as possible and should
>> not
>> >>>>>>> assume that any of p.a.widgets is available on the FE.
>> >>>>>>>
>> >>>>>>>> Currently in Plone there is a de facto "standard library" of
>> markup
>> >>>>>>>> available to add-on authors. You can get an idea of what's
>> included in
>> >>>>>>>> this if you look at /test_rendering on a Plone 3 or Plone 4
>> site. As an
>> >>>>>>>> add-on developer, I don't have to spend time on CSS or work with
>> >>>>>>>> a designer, because I know what markup to use for a portlet or
>> an alert
>> >>>>>>>> message or a form, and can expect that all Plone themes will
>> provide
>> >>>>>>>> styles for that markup. This idea of a markup library is similar
>> to
>> >>>>>>>> Twitter Bootstrap, only ours has evolved organically over time
>> rather
>> >>>>>>>> than being carefully designed.
>> >>>>>>>>
>> >>>>>>>> We can decide to change this library of markup patterns for Plone
>> >>>>>>>> 5 (switch to Bootstrap, perhaps), if we want. But we can't stop
>> having
>> >>>>>>>> a library available altogether. The result would be that
>> >>>>>>>> 1. Add-on authors have to spend time writing their own CSS
>> >>>>>>>> 2. Different add-ons will not have a consistent look and feel
>> >>>>>>>> 3. Themers will need to spend time overriding the styles for each
>> >>>>>>>>    addon's markup, rather than merely implementing styles for the
>> >>>>>>>>    standard markup
>> >>>>>>> This side steps the issue that in reality themers spend that time
>> >>>>>>> overriding the styles assumed by a plugin, whether its provided
>> by Plone
>> >>>>>>> or not. We don't live in a world where websites look like their
>> CMS
>> >>>>>>> anymore. We need to encourage an eco system of plugins that make
>> >>>>>>> a minimum of style decisions, or make it really easy to diazo to
>> make the
>> >>>>>>> markup work with our chosen style framework such as bootstrap. If
>> we try
>> >>>>>>> to enforce a particular style framework on our themers we lose a
>> lot of
>> >>>>>>> potential users of Plone because Plone is too opinionated. Plone
>> should
>> >>>>>>> be the blanksheet that a designer can rely on to make any site
>> they want.
>> >>>>>>> This makes Plone a truely useful CMS that will stand out of the
>> pack.
>> >>>>>>
>> >>>>>> I still think using a framework makes it easier for the themer.
>> >>>>>
>> >>>>> Yes but which framework? If plone relies of bootstrap 3 then we
>> lock out
>> >>>>> anyone that doesn't want to use bootstrap 3. What happens if a
>> theme is
>> >>>>> built on bootstrap 3 and plone 5 moves to bootstrap4?  Simpler more
>> >>>>> independent plugins that are designed to not intefer with each
>> other and
>> >>>>> have simple html that is easy to theme. I think this is the way to
>> go.
>> >>>>
>> >>>> Then themes will need to be upgraded, however, the guidelines for
>> how to do
>> >>>> so might be clear and consistent across the board.
>> >>>>
>> >>>>>
>> >>>>>> They can style the conventional markup, instead of figuring out
>> what
>> >>>>>> different markup each addon uses. It also provides greater
>> flexibility.
>> >>>>>> A site can be left without a custom theme, if it's look isn't
>> important.
>> >>>>>> Or the style framework can be replaced with custom CSS. Or a
>> published
>> >>>>>> theme addon can be used, since the markup is standard. If we don't
>> try to
>> >>>>>> define common markup, the *only* option is writing a custom theme.
>> Yes,
>> >>>>>> that happens for most sites by the time the site launches, but
>> flexibility
>> >>>>>> in when it happens is good.
>> >>>>>
>> >>>>> I think there could be ways of handling this. For example a plugin
>> could
>> >>>>> come with same css which you insert into your theme. This is as
>> opposed to
>> >>>>> a plugin that fails to work at all if it doesn't include exactly
>> the CSS
>> >>>>> that came with it and therefore you have to fight against the
>> plugin CSS to
>> >>>>> be able to use the plugin with your custom theme.
>> >>>>
>> >>>> Again, I think not using a framework encourages addons to include
>> more CSS
>> >>>> which is then harder to work with.  Of course, it could still be
>> optional.
>> >>>> But what about the markup?  Do we make the markup optional?  How
>> would that
>> >>>> work?  Well, the theme could include diazo rules to deal with the
>> markup for
>> >>>> the addon, but that is more work for the themer.  In most cases,
>> logical
>> >>>> defaults are good, especially when they are consistent and modern.
>>  The
>> >>>> problem with plone now is that it is neither consistent nor modern
>> nor in
>> >>>> some cases logical.
>> >>>>
>> >>>
>> >>> i think we are forgetting what we are already doing.
>> >>>
>> >>> default plone theme provides easier way to theme plone and allows
>> addons to
>> >>> know (almost) what kind of html/css to expect. in plone 4 we call it
>> sunburst
>> >>> in plone 5 we'll call it barceloneta. in the same manner addons in
>> future could
>> >>> expect barceloneta based theme. in case of high customization you
>> will have to
>> >>> manually fix things anyway.
>> >>>
>> >>> barceloneta (as far as i know, ramon please correct me if i'm wrong)
>> will be
>> >>> based on bootstrap 3.if somebody prefers other framework please go
>> ahead and
>> >>> create your own theme in a similar fasion that braceloneta is doing
>> it. so
>> >>> there is no lockin.  i'm not huge fan of bootstap, but i recognize
>> most of
>> >>> designers/developers are familiar with it and should provide low
>> entry barrier
>> >>> and sane default.
>> >>>
>> >>> also important to mention is that there is "minimal" theme which
>> barceloneta is
>> >>> based uppon -> no css only clean html which you can style from
>> scratch.
>> >>>
>> >>> i dont see much problem with addons space in future. they will
>> continue to be
>> >>> written in similar manner. what we will add is new area where addons
>> can hook
>> >>> into - let call it "backend" for now. that dom space has more
>> predictable
>> >>> css/html then frontend theme which changes from one to another
>> project and can
>> >>> more reliably hook into it.
>> >>>
>> >>> so in short: we're *adding* possibility to addons to hook into
>> backend. how
>> >>> they hooked into frontend stays the same as in plone 4.
>> >>
>> >>
>> >> Wow, I'm only loosely following this thread and I had to jump back in
>> to
>> >> Thunderbird to see the full discussion (I've been following things via
>> >> Feedly/RSS for months.) :-) Anyway, first allow me to say this: I am
>> >> very excited to see the discussion "heat up" over all things Plone 5 &
>> >> in particular theming.
>> >>
>> >> Obviously, we have a variety of different use cases "battling it out".
>> >> This is our chance to define what we want Plone 5 to be and it's
>> >> important we get it right NOW, because we're going to be living with
>> >> Plone 5 LATER (for the next few years at least). Now, let me take a
>> step
>> >> back from the immediate theming discussion and reiterate what I want
>> >> Plone 5 to be, FWIW:
>> >>
>> >> - Lightweight, fast & modern, in the Python sense. This means: fewer
>> >> Python packages and as much deprecation of old technologies as humanly
>> >> possible. Ripping stuff out and turning stuff off MUST be the priority,
>> >> and easily represents the most challenging work. `pip install Plone` is
>> >> still my benchmark for this. Not because I love pip, but because it's
>> >> now part of the Python core and we need to start paying more attention
>> >> to it IF we want the Python community's attention[1]. I've begun some
>> >> work on something called Plock to bridge the gap: `pip install plock`
>> >> until `pip install Plone` actually works[2].
>> >>
>> >> - Lightweight, fast & modern, in the Web sense. This means: using web
>> >> technologies that web developers actually understand, are already
>> >> familiar with, and can begin using quickly in the Plone context. I
>> don't
>> >> care about what framework we use (e.g. Bootstrap 3) as much as I INSIST
>> >> the choice be lightweight, fast & modern in the Web sense. If that
>> means
>> >> we pick Bootstrap 3 now and a new framework for Plone 6, so be it.
>> >> That's a lot of work, but at least it is' *definable* work. My eyes
>> >> glaze over and roll back in my head whenever the discussion turns to
>> >> "how do we bring the right HTML/CSS/JavaScript in from Plone to our
>> theme".
>> >>
>> >> Much like with Buildout, I worry our choice to rely so heavily on Diazo
>> >> may have been a mistake. Instead, I think we should focus on discussing
>> >> why we needed Diazo in the first place. What is Plone? Is it a system
>> >> that enables inline editing of websites for every-theme-on-earth? Are
>> we
>> >> still aiming to perform every management task TTP (through-the-Plone)?
>> >> If so, do we absolutely positively need Diazo to do this? If the answer
>> >> is "yes", then I don't fully understand why. If the answer is "no",
>> then
>> >> I'm no better off, because I don't know how to implement the above
>> >> feature set without Diazo (i.e. I need to strictly control Plone's UI
>> >> and let folks 'tie in' via Diazo). Obviously mapping content to a theme
>> >> is attractive, which is why we all went for it in the first place. But
>> >> if you look at any other modern system that allows customization (e.g.
>> >> GMail) they make it easy for you to customize AND strictly limit what
>> >> you can customize. I worry that by relying on an increasingly more
>> >> complex Diazo rule set we are complicating the stack and still not
>> >> achieving the goal of everything TTP.
>> >>
>> >> Lastly, I think we should make these decisions first then decide how to
>> >> approach them in the current ecosystem. If we are confident about the
>> >> direction, then we should have no issue documenting our progress and
>> >> leading the users and integrators by example.
>> >>
>> >>
>> >> Alex
>> >>
>> >>
>> >> [1] This is just one case of many: "making Plone appealing to Python
>> >> programmers." Arguably not even the most important, but one that I
>> >> happen to care about.
>> >>
>> >> [2] https://github.com/aclark4life/plock
>> >>
>> >> [3] Both great tools, but overkill in a lot of cases where folks just
>> >> want to "do Python & Web".
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> --
>> >>> Rok Garbas - http://www.garbas.si
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Shape the Mobile Experience: Free Subscription
>> >>> Software experts and developers: Be at the forefront of tech
>> innovation.
>> >>> Intel(R) Software Adrenaline delivers strategic insight and
>> game-changing
>> >>> conversations that shape the rapidly evolving mobile landscape. Sign
>> up now.
>> >>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> Plone-developers mailing list
>> >>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> >>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>> >>>
>> >>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Shape the Mobile Experience: Free Subscription
>> >> Software experts and developers: Be at the forefront of tech
>> innovation.
>> >> Intel(R) Software Adrenaline delivers strategic insight and
>> game-changing
>> >> conversations that shape the rapidly evolving mobile landscape. Sign
>> up now.
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Plone-developers mailing list
>> >> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> >> https://lists.sourceforge.net/lists/listinfo/plone-developers
>> >
>> > _______________________________________________
>> > UI mailing list
>> > [email protected]
>> > https://lists.plone.org/mailman/listinfo/plone-ui
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Plone-developers mailing list
>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>
>
>
> --
> Felipe Duardo
>



-- 
Felipe Duardo

_______________________________________________
UI mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-ui