Hi
I agree with Guillaume. In my company most screens are set to 1024x768 (and can't be changed) and i guess that adding a text to an icon could result in scrollbars on some screens. I would prefer a tooltip.
-----Message d'origine-----
De : devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] De la part de Guillaume Lerouge
Envoyé : lundi 27 juillet 2009 12:20
À : XWiki Developers
Objet : Re: [xwiki-devs] [Proposal][UX] Standardization of icon usage onactions
Hi,
On Mon, Jul 27, 2009 …
[View More]at 11:58 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
> wrote:
> On Mon, Jul 27, 2009 at 11:45, Ecaterina Valica<valicac(a)gmail.com> wrote:
> > Hi Devs,
> >
> > There are two different standards on the action icon usage in the
> LiveTable:
> >
> > - with icon + text
> > - only with icon
> >
> > The main problem is the lack of consistency.
> >
> > Please vote on three versions:
> > Var 1 : Icon + Text
> > <http://incubator.myxwiki.org/xwiki/bin/view/Standards/ActionIcons#var1>
> > Var 2 : Just Icon<
> http://incubator.myxwiki.org/xwiki/bin/view/Standards/ActionIcons#var2>
> > Var 3 : Icon + Legend<
> http://incubator.myxwiki.org/xwiki/bin/view/Standards/ActionIcons#var3>
> >
>
> +1 for Var 1 : Icon + Text (at first i taught i would take too many
> place but it seems ok with several icon in
>
> http://incubator.myxwiki.org/xwiki/bin/view/Standards/ActionIcons#HOtherUsa…
> )
Well, when using a small screen (1024*768), the document index becomes too
wide. Thus I'd rather be +1 for Var 2 as it takes less space.
Instead of having a caption at the bottom as on Var 3, we could put the
action's legend in a tooltip displayed when hovering over the action
icon. WDYT?
Guillaume
> > Thanks,
> > Caty
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--------------------------------------------------------------------------------
This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies.
While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection.
KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1
[View Less]
(resending since I got a failure from xwiki's mail content filter )
---------- Forwarded message ----------
From: Vincent Massol <vincent(a)massol.net>
Date: Sun, Jul 26, 2009 at 12:08 PM
Subject: Re: [xwiki-devs] [VOTE] What to do with RawBlock in plain
text renderer ?
To: XWiki Developers <devs(a)xwiki.org>
On Jul 26, 2009, at 11:52 AM, Thomas Mortagne wrote:
> Hi devs,
>
> We need to decide what to do with html macro content (or any other
> RawBlock content) in …
[View More]plain text renderer.
>
> For me the rule of plain text renderer should be to print anything we
> are able to print which mean printing any pure text content and skip
> styles for which obviously we don't have syntax. RawBlock content is
> pure text so we should print it.
>
> Note that first version of plain text renderer was printing html
> content and it was lost when introducing RawBlock.
>
> Here is my +1 for printing RawBlock content in plain text renderer.
-1 for now (I can be convinced to change it): RawBlock is very special
and should only be interpreted by renderers which understand the raw
syntax. The plain text renderer shouldn't understand any syntax IMO.
I'd like to see a real use case before changing my -1 to a +1.
Right now if a page has for example a form to create a new type of
page and this page is output in plain text, I will not want to see the
HTML printed as content. It doesn't make sense to me.
Thanks
-Vincent
[View Less]
(resending since I got a failure from xwiki's mail content filter )
---------- Forwarded message ----------
From: Vincent Massol <vincent(a)massol.net>
Date: Sun, Jul 26, 2009 at 10:21 AM
Subject: Re: [xwiki-devs] adding a new jsr-223 scripting language to
xwiki (clojure)
To: XWiki Developers <devs(a)xwiki.org>
Hi Niels,
On Jul 26, 2009, at 10:13 AM, Niels Mayer wrote:
> In
> http://code.xwiki.org/xwiki/bin/view/Snippets/DisplayFormatedCodeAttachment…
>
>> …
[View More]VincentMassol | 2009/05/05 20:03
>>
>>> Niels, no there's no plan but we can now support any language using macros
>>
>> so feel free to provide a clojure macro if you're interested. Shouldn't be
>> too hard to do, especially if there's a JSR-223 implementation (in which
>> case simply dropping the jar in WEB-INF/lib should be enough - you'd then
>> use it using the script macro).
>
>
> Clojure <http://groups.google.com/group/clojure> has aJSR-223 implementation
> according to:
> http://github.com/pmf/clojure-jsr223/tree/master
> http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
> http://sayspy.blogspot.com/2009/03/interacting-between-jvm-lang-here-and.ht…
>
> Are there any examples, documentation, or suggestions of writing a "script
> macro" to call a new jar in WEB-INF/lib ?
Well all you need is drop the JSR223 jar in WEB-INF/lib and then you
can use the new language using the script macro:
http://code.xwiki.org/xwiki/bin/view/Macros/ScriptMacro
Then if you want you can write a wrapping macro such as we've done for
groovy and jruby so that it can be called with {{clojure}} instead of
{{script language="clojure"}}.
> Any other special magic I should know? Does anything from the above suggest
> that Clojure couldn't be used as an Xwiki scripting language, replacing
> cases where Groovy scripting might normally be employed?
>
> Niels
> http://nielsmayer.com
>
> PS: Here's examples of easy "scripted java" programming you can do in
> Clojure (note the helpful parallelism constructs):
> http://travis-whitton.blogspot.com/2009/07/network-sweeping-with-clojure.ht…
> http://travis-whitton.blogspot.com/2009/06/clojures-agents-scientists-monke…
>
> It could be very useful to employ massive parallelism via such Clojure
> scripts, which could achieve a xwiki-based web portal performance akin to
> Yahoo's, Google's, etc. For example, the following describes how Yahoo works
> -- and would be quite easy to implement this kind of processing "for free"
> in Clojure with very little code:
>
> http://research.yahoo.com/files/pnuts.pdf
I'm definitely +1 to make it part of the XWiki platform (same as for
jruby) if you develop it. Similar to jruby I don't think we should
package it in the default WAR though but as an optional download to
install (will be even easier with the app manager).
Thanks
-Vincent
>
> The component responsible for multi-record requests is called the
>>
>> scatter-gather engine, and is a component of the router.
>> The scatter-gather engine receives a multi-record request,
>> splits it into multiple individual requests for single records
>> or single tablet scans, and initiates those requests in parallel.
>> As the requests return success or failure, the scatter-gather
>> engine assembles the results and then passes them to the
>> client. In our implementation, the engine can begin streaming
>> some results back to the client as soon as they appear.
>> We chose a server-side approach instead of having the client
>> initiate multiple parallel requests for several reasons. First,
>> at the TCP/IP layer, it is preferable to have one connection
>> per client to the PNUTS service; since there are many clients
>> (and many concurrent processes per client machine) opening
>> one connection to PNUTS for each record being requested
>> in parallel overloads the network stack. Second, placing this
>> functionality on the server side allows us to optimize, for
>> example by grouping multiple requests to the same storage
>> server in the same web service call.
>>
>> Range queries and table scans are also handled by the
>> scatter gather engine. Typically there is only a single client
>> process retrieving the results for a query. The scatter gather
>> engine will scan only one tablet at a time and return results
>> to the client; this is about as fast as a typical client can
>> process results. In the case of a range scan, this mecha-
>> nism simplifies the process of returning the top-K results
>> (a frequently requested feature), since we only need to scan
>> enough tablets to provide K results. After returning the
>> first set of results, the scatter-gather engine constructs and
>> returns a continuation object, which allows the client to re-
>> trieve the next set of results. The continuation object con-
>> tains a modified range query, which, when executed, restarts
>> the range scan at the point the previous results left off. Con-
>> tinuation objects allow us to have cursor state on the client
>> side rather than the server. In a shared service such as
>> PNUTS, it is essential to minimize the amount of server-
>> side state we have to manage on behalf of clients.
[View Less]
Hi,
I'd like to propose to release XE 1.9.2 on 27th of July (next Monday).
There are already a good number of fixes:
http://jira.xwiki.org/jira/browse/XWIKI/fixforversion/11171
Other issues not done can be moved to 1.9.3 (which could be released
in 2 weeks time).
Here's my +1
Thanks
-Vincent
Hi
Soon I should have upgraded my own blog to Blog 2.0 syntax and so I am confident that it should work quite well. So I started to look into how to upgrade the Blog application. It is not a problem to upgrade the most of the application documents except for the Blog.BlogCode and Blog.CategoriesCode because they are used in the Panels which I think cannot be upgraded (at least not for 1.9.X).
This means I can do either:
1) Replace everything except for BlogCode and CategoriesCode which must …
[View More]remain as is and us BlogCode2 and CategoriesCode2 instead.
2) Keep all the documents as attached (new documents have the suffix 2) and only overwrite WebHome with the new code because 2.0 Blog Entries will not display well in the old application.
At least all the old entries will display with the new application the same way.
Cheers
Andreas Schaefer
CEO of Madplanet.com Inc.
EMail: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter: andy_mpc
AIM: schaefera(a)me.com
[View Less]
Go easy. First time. Pointed here by your Ideas page.
Would be great to have a link/icon from [any] Wiki page to activate the Google Language API and allow the end user to translate the page into the language of their choice. Preferred/default target language could be stored as part of profile.
-David.
p.s. Great app you've put together.
_________________________________________________________________
View photos of singles in your area Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau…
Hi Vincent
Great.
I was wondering if anyone knows what has changed to fix this so that I could retrofit 1.9.1 because I wanted to upgrade my own Blog to 2.0 to test it.
Thanks - Andy
On Thursday, July 16, 2009, at 12:12PM, "Vincent Massol" <vincent(a)massol.net> wrote:
>
>On Jul 16, 2009, at 8:43 PM, Andreas Schaefer wrote:
>
>> Well, I tried this and it works to some degree but for example Links
>> were lost when switching to the Source tab.
>
>This is a …
[View More]bug that was fixed in 2.0M2 AFAIK.
>
>Thanks
>-Vincent
>
>>
>> Cheers - Andy
>>
>> On Wednesday, July 15, 2009, at 11:43PM, "Marius Dumitru Florea" <mariusdumitru.florea(a)xwiki.com
>> > wrote:
>>
>>> templates/textarea_wysiwyg.vm and replace
>>>
>>> #wysiwyg_editProperties($tdoc $editors false)
>>>
>>> with
>>>
>>> #wysiwyg_editProperties($tdoc $editors true)
>_______________________________________________
>devs mailing list
>devs(a)xwiki.org
>http://lists.xwiki.org/mailman/listinfo/devs
>
>
[View Less]