*Hi Devs,*
*I'm coming back from a meeting with a corporate XWiki user.*
*The project manager there reported a "bug" to me: when hitting Return while
at the end of the link, she was still in the link. The item she created
after hitting return was a title and due to style settings she couldn't see
it was still a link. Then she hit Return again and after her title the text
was still a link. She felt confused and didn't understand why the link was
still there.*
*This is due to the fact that right now, when the caret is at the end of an
element with an inline style applied, it keeps applying that style upon
hitting Return. This applies to bold, italics, underlined, strikethrough,
color, background color and links (all inline elements). I've talked about
this with Anca a number of times, saying that it was wrong for links to be
kept when hitting enter (since users very rarely want links that span 2
paragraphs). Her answer was that all inline styles should be treated the
same for technical reasons.*
*After giving it more thought and gathering feedback from our project
managers it appears that the use case of willing the current inline style to
be kept after hitting Return is actually less frequent than wanting the new
line to be "clean". Moreover, it's extremely confusing for users when the
link is kept.*
*Thus I'd like to suggest that hitting Return (= generating a new paragraph)
should get the caret out of the current inline style in the WYSIWYG editor.
Here are a couple more reasons why I believe this to be the best option:*
- There are shortcuts available in the WYSIWYG for most inline styles
(CTRL-B, CTRL-I) thus it's easy for the user to activate it again on a new
line
- It's very easy to select a wide area of text with the mouse and then
apply an inline style to it, thus styling can conveniently be done after the
actual writing
- Hitting SHIFT-Return will keep the user in the same paragraph and thus
will keep the current inline styles
- It's very rare that users want to apply an inline style to several
paragraphs in a row since bold, italics are most often used to create
contrast with surrounding text
To summarize, I think hitting Return should generate "virgin" new lines. The
only thing that should be kept is the alignment.
WDYT?
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Hi,
As you know I like clean stuff (some could call it an obsession ;)).
While browsing the Design/Idea spaces on dev.xwiki.org I noticed
several pages containing stuff already implemented.
I'd like to propose the following strategy:
* Once a design has been implemented, document it (for example in the
Modules space on code.xwiki.org)
* When both the new design has been implemented and documented, delete
the wiki page in the Design space.
WDYT?
For example I'd like to remove this page:
http://dev.xwiki.org/xwiki/bin/view/Design/XWikiSyntaxMapping
I'd also like to document the xwiki-component module in Modules and
then remove this page:
http://dev.xwiki.org/xwiki/bin/view/Design/ArchitectureV2
Thanks
-Vincent
Hi everyone,
Till now we were using IRC (and we still are) but there are a few
issues with it and the biggest one is that you don't get to see
messages sent to you when you're offline. Thus we're trying a new
solution using Jabber/XMPP.
If it works well we'll then switch from IRC to it.
If you want to participate in the test and join us you can log in on xwiki(a)conference.jabber.org
name: xwiki
server: conference.jabber.org
Note that you can log with your gmail id if you don't have a jabber id.
See you there.
Thanks
-Vincent
Hi Silvia,
Good to have you on board.
Just for the record, Silvia is an employee of XWiki Lasi (romanian
branch of XWiki SAS, see http://xwiki.com and
http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource
for those who want to know the relationship between XWiki SAS and the
XWiki open source project).
From the open source point of view, Silvia is not a committer, she's
just a contributor like anyone can be.
Silvia this means that for anything important you'd like to change,
you'll need to propose it here on this mailing list for agreement.
Obviously there's no need to propose anything for creating JIRA issues
about bugs found... ;)
However if you want to reorganize xwiki.org for example and make some
substantial changes you'll need to make a proposal here first and get
some agreement first since this is how the XWiki open source project
works.
Guys let's not completely rely on Silvia though! It's everyone's job
to help by improving the doc on xwiki.org and by discovering/fixing
bugs. Silvia is a bonus.
Thanks and again, welcome on board!
-Vincent
On Aug 20, 2009, at 10:34 AM, Silvia Rusu wrote:
> Hi,
>
> I am Silvia Rusu (http://www.xwiki.org/xwiki/bin/view/XWiki/
> SilviaRusu)
> and I have joined the XWiki Iasi team this week as a tester and
> documentation writer.
>
> As a tester my role will be to uncover any issues and inconsistencies
> that might affect the products you love developing/using.
> I will also be talking to our project managers, product manager and
> mailing list users in order to find out more about our customers
> expectations and needs. Taking this into consideration I will come up
> with suggestions on how to improve user experience.
>
> As a documentation writer I will make sure users who aren't familiar
> with XWiki discover what the products do in order to take advantage of
> their features. In the process I will be making sure all user-facing
> features are well documented on XWIki.org, writing user guides,
> creating
> videos explaining how to use features, etc.
>
> I am happy to be joining XWiki and hope this will develop into a very
> successful collaboration.
>
> You can find me online on Twitter at http://twitter.com/silviarusu.
> Should you have any suggestions regarding testing and documentation
> please feel free to contact me by email at silvia.rusu(a)xwiki.com.
>
> Thanks,
> Silvia
Sorry here is a link version :
http://www.design-platform.org/sourcefiles/XWiki%20users%20com%20board%20co…
2009/8/20 Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com>:
> Ok, it just take a little more time to reproduce (completly or just a
> part to get the feeling) any image to svg/ai yet it is not the best to
> collaborate.
>
> Can have a look at the design platform story on Flickr :
> http://www.flickr.com/photos/evalica/3761778569/
>
>
>
> 2009/8/19 Ecaterina Valica <valicac(a)gmail.com>:
>> Sorry, we currently don't have a especially place for SVG files. :)
>>
>> On Wed, Aug 19, 2009 at 18:37, Thibaut DEVERAUX
>> <thibaut.deveraux(a)gmail.com>wrote:
>>
>>> Thanks.
>>>
>>> Where can I find the svg files in the futur ?
>>>
>>> 2009/8/19 Ecaterina Valica <valicac(a)gmail.com>:
>>> > Usually I use Inkscape, but for the skin mockups it's not a mockup, but
>>> the
>>> > actually site modified with CSS. I worked on a local XE instance on my
>>> > computer.
>>> >
>>> > On Wed, Aug 19, 2009 at 14:04, Thibaut DEVERAUX
>>> > <thibaut.deveraux(a)gmail.com>wrote:
>>> >
>>> >> Nice !
>>> >> I can't wait to see it. ;-)
>>> >>
>>> >>
>>> >> >> Also I'd love to make propositions of architecture modifications to
>>> >> visauy
>>> >> >> show my means. Yet I have not many time. Is there a place where
>>> source
>>> >> >> files
>>> >> >> can be downloaded to speed the process ?
>>> >> >>
>>> >> >
>>> >> > The new skin will be available in it's first version with the RC1 on
>>> 24
>>> >> > august.
>>> >>
>>> >>
>>> >> I was speaking of the design source files, not code. :-)
>>> >>
>>> >> Photoshop, Gimp, Illustrator, Inkscape or whatever you use.
>>> >>
>>> >> -- Yet I will wait to see your skin and think I will not make mockup
>>> >> then. Yet in general cases we found having design files open source
>>> >> too can help as we experienced in the design platform project.
>>> >> _______________________________________________
>>> >> devs mailing list
>>> >> devs(a)xwiki.org
>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>>> >>
>>> > _______________________________________________
>>> > devs mailing list
>>> > devs(a)xwiki.org
>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
Hello,
In April there was a discussion on the list with this subject. This
discussion ends without a solution. Does anyone know if this problem has
been solved. It seems I am having the same problem here when running
1.9.3 on a Oracle OC4J container.
Thanks,
Henk
==
Henk F. Schouten, ICT-architect, Dienst ICT
room: SL 2.32, phone (31) 70 4457611, email: H.F.Schouten(a)hhs.nl
De Haagse Hogeschool, Johanna Westerdijkplein 75, 2521 EN the Hague (NL)
Hi,
I've started a refactoring of DevGuide today:
* Removed the Tutorial page and put everything on DevGuide.WebHome. It
was too hard to decide what was a tutorial from what wasn't.
* Reordered stuff on DevGuide.WebHome. Notably I've put XWiki
Architecture on top and I've started to improve it, see
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture
* All Reference docs should go in a Module on code:Modules.WebHome
* Module doc should contain:
- general architecture
- features of the module
- quick examples where it makes sense
- link to tutorials that should be written in the DevGuide
WDYT? What am I missing?
Thanks
-Vincent
Hi devs!
I've just noticed that OpenOffice Web/Writer doesn't work properly for
"<br/>" element. (With "<br />" works fine). The answer can be the
compatibility problems between XHTML1.0 and HTML.
http://www.w3.org/TR/xhtml1/guidelines.html - Appendix - C2
My question is should I change the rendering module or I solve this problem
locally , at my client?
Best regards,
Cristina
Hello all,
I noticed that when a document is renamed, it's "child" documents
don't have their parent values updated. It looks like just a few lines
of code, maybe an hql
ALTER XWikiDocument doc WHERE doc.parent = '"+oldName+"' SET doc.parent
= '"+newName+"'
Is this too messy?
I think a loop with doc.doc.setParent(newName) and doc.save() would be
too resource intensive with databases which fsync every transaction.
Should we bother to even ask the user the way it asks to update links?
Should we update #includeForm, #includeInContext, and #includeTopic as well?
What are your thoughts?
~Caleb James DeLisle
I'm new here, let me know if I posted in the wrong section