[silva-dev] silva-2.2: comments

[Andy Altepeter]

Hi Marc,

Thanks for your feedback.  I'll address the items I can below:

On Sunday 31 May 2009 03:55:31 pm Marc Petitmermet wrote:
> uploading image:
> why do i have to browse again for the image when i forgot to enter the
> required title?
I think this is standard web behavior for file input fields.  The path isn't 
sent to the server (that's a security issue), only the contents of the file.  
So unfortunately it is impossible for Silva to re-populate the image path.
>
> smi image:
> the image assets are represented with the icon "silvafile.png" instead
> of the icon "silvaimage.gif" (why the mixed image formats?).
This is now fixed.
>
> smi consistency:
> why didn't you replace the big buttons in the kupu image tool for the
> image reference with the same/similar buttons like in the link tool?
> it's very nicely done there with the buttons on the left and right of
> the input field. the same applies for "link to:" field.
I'm glad you like the redesigned link tool.  This is kind of a feature preview 
in 2.2; I developed it for the formulator reference lookup window widget and 
thought the larger community would appreciate it as well.  The integration 
with the link tool was an afterthought, but if I have time before 2.2 final I 
would also like to see the rest of the link fields in kupu proper updated as 
well.
>
> edit link reference...:
> i was a little surprised about what happened when clicking on this new
> icon in the kupu link tool. sometimes we have long urls/paths and it
> is not that easy to fix those because of the need of horizontal
> scrolling. so i expected that this button opens up a larger link field
> that would help me in this situation. but instead it opened up the
> silva document where it linked to. therefore, could you please rename
> the tool tip from "edit link reference..." to "edit linked
> reference...". small detail but the two character change makes the
> description correct.
This is a good catch; thank you.  I understand what you mean about editing 
long links.  Do you think that if the link is long, the input field is 
switched to a textarea when it has the focus?  If the textarea wrapped rather 
than added a scrollbar, it may be easier to edit long links...
>
> edit link(ed) reference...:
> is it possible to have the button "edit link(ed) reference..."
> disabled from the beginning for not valid relative silva references?
> currently, it gets disabled after the user has clicked on it, that's
> too late and useless because the next time the cursor is on the same
> link the button is enabled again.
By disabled, do you mean that it would be sufficient to do nothing if the 
reference wasn't "editable"?
> warning message: what is the definition of "valid relative silva
> references"? what about "valid absolute silva references", won't they
> be edited? don't you mean local and external references here?
An ajax call to Silva happens whenever the button is clicked and there is text 
in the input field.  Silva then determines if the text is a link to a Silva 
object, and returns an absolute edit url.  If it isn't an editable link, the 
alert message is displayed.

This initial implementation needs relative links, which are the easiest to 
resolve to Silva objects.  If it has to deal with absolute urls, Silva then 
needs to know how to translate a server name to the root of a vhost within 
Silva.  A single silva root could support multiple virtual hosts, but Silva 
doesn't necessarily know that.  It only knows about the vhost you're 
accessing from.

I recall Kit and I chatting about this feature.  I had forgotten this, but we 
decided to try out absolute urls for the host you're accessing silva from as 
well.  Zope does provide a nice method to translate this type of absolute url 
into a zope path.  I'll put this on my list.
>
> lookup users.../groups admin...:
> i think since silva-2.1 (i don't know about 2.0) the "lookup
> users..."/"groups admin..." buttons have been moved away from their
> boxes on the right side to the top left side of the smi. i miss them
> at their old locations, it was much more convenient.
I didn't make this change, so I can't really comment other than to say I agree 
with Marc.  My muscle memory is stronger than the standardization of actions 
into the middleground.
>
> export to open document (odt):
> nice that this feature is now built in. i had quite good experience
> with https://viewvc.infrae.com/svn/silva2odt/ by dave kuhlmann. this
> built in export has still a few issues like missing images, list
> styling, export of complete branches.
Is there a launchpad bug to tracking these issues?  I can only hope Dave will 
come out with version 2 of silva2odt which includes these features...
>
> user settings:
> is it possible to have the languages somehow sorted?

How would you think these should be sorted?  It doesn't appear this list is 
sorted in any particular order.  Do you think the language code is more 
natural than a string-comparison sort on the language names?  We only 
use 'en' over here in the states, so I really have no idea...

Thanks again for your valuable feedback.  I know your contributions are much 
appreciated in this community.

Take care,
Andy

>
> regards,
> marc
>
>
> _______________________________________________
> silva-dev mailing list
> silva-dev at lists.infrae.com
> https://lists.infrae.com/mailman/listinfo/silva-dev