headers
anton | 1 Mar 2007 09:15
Picon
Picon

[Trac-dev] WebAdmin for Trac 10.3 tarball (svn doesn't work)


Hi,

I am trying to checkout the WebAdmin like 
described on
http://trac.edgewall.org/wiki/WebAdmin

But I get only errors (I am sitting behind a proxy,
don't know why it doesnt work).

Anyway ... could I get somewhere else 
the *.tgz or *.egg for trac 10.3 & python 2.4.3 ??

Thanks a lot

  Anton

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 2 comments |
headers
anton | 1 Mar 2007 09:28
Picon
Picon

[Trac-dev] Re: WebAdmin for Trac 10.3 tarball (svn doesn't work)


Hi,

its me again ... I found out the link is wrong,
we need https:
wrong: http://trac.edgewall.org/wiki/WebAdmin

ok: https://trac.edgewall.org/wiki/WebAdmin

Bye

 Anton 

I go now to fix this in the doc.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Matt Good | 1 Mar 2007 10:22
Gravatar

[Trac-dev] Re: WebAdmin for Trac 10.3 tarball (svn doesn't work)


On Mar 1, 2:28 am, anton <anto... <at> gmx.de> wrote:
> Hi,
>
> its me again ... I found out the link is wrong,
> we need https:
> wrong:http://trac.edgewall.org/wiki/WebAdmin
>
> ok:https://trac.edgewall.org/wiki/WebAdmin
>
> Bye
>
>  Anton
>
> I go now to fix this in the doc.

This is a problem with your proxy.  It does not properly handle WebDAV
commands so the SVN checkout fails.  The https access to the
repository is provided as a workaround to these proxy problems since
they can't filter the encrypted traffic.  However, the http link is
still valid for users not behind proxies.

-- Matt Good

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Lenz | 1 Mar 2007 20:43
Picon
Picon
Gravatar

[Trac-dev] Re: genshi and hdfdump


Am 28.02.2007 um 12:02 schrieb Emmanuel Blot:
>> Is there a "magic" debug parameter such as "hdfdump" that can be used
>> along with Genshi-rendered pages?
>
> Follow-up: Alec implemented it in [4868].

I was playing with the idea to move this functionality out into a  
"TracDevTools" plugin, which would include "pretty" template data  
dumping as well as other things (such as an enhanced version of the  
about/plugins page, showing relationships between components via  
extension points).

The template data debugging will be based on the IRequestFilter  
extension point, and probably use AJAX to be able to drill-down into  
objects (in a manner similar to evalexception). Also, it'll define  
its own permission actions and maybe be configurable to only work on  
requests via localhost, or on the local network, or a configurable  
set of IPs.

I've started work on that plugin and will probably push it up on trac- 
hacks.org in the next couple of days.

Any ideas for what other functionality such a plugin could provide  
for aiding plugin developmnent?

Cheers,
Chris
--
Christopher Lenz
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alec Thomas | 1 Mar 2007 20:57

[Trac-dev] Re: genshi and hdfdump


On Thu, Mar 01, 2007 at 08:43:37PM +0100, Christopher Lenz wrote:
> I was playing with the idea to move this functionality out into a  
> "TracDevTools" plugin, which would include "pretty" template data  
> dumping as well as other things (such as an enhanced version of the  
> about/plugins page, showing relationships between components via  
> extension points).
> 
> The template data debugging will be based on the IRequestFilter  
> extension point, and probably use AJAX to be able to drill-down into  
> objects (in a manner similar to evalexception). Also, it'll define  
> its own permission actions and maybe be configurable to only work on  
> requests via localhost, or on the local network, or a configurable  
> set of IPs.
> 
> I've started work on that plugin and will probably push it up on trac- 
> hacks.org in the next couple of days.
> 
> Any ideas for what other functionality such a plugin could provide  
> for aiding plugin developmnent?

This sounds useful.

An extra addition might be interface validation, like this patch:
http://www.swapoff.org/files/interface-check.diff.

Also, once workflow goes in, Eli's Graphviz visualisation and validation of
the workflow state changes.

Though these might be more useful as TRAC_ADMIN only preference panels.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Boos | 1 Mar 2007 22:55
Picon

[Trac-dev] Re: genshi and hdfdump


Hello,

That sounds very interesting indeed.

On Mar 1, 8:43 pm, Christopher Lenz <cml... <at> gmx.de> wrote:
> The template data debugging will be based on the IRequestFilter
> extension point, and probably use AJAX to be able to drill-down into
> objects

I see this also useful on the error page, as an enhancement for the
list of frame locals.

> Any ideas for what other functionality such a plugin could provide
> for aiding plugin developmnent?

Well, a good object inspector would do 90% of the job.
I guess we'd need also a "Done" button so that the server can release
all the information kept for a request, once we're done inspecting the
results.

What would be also useful is a trace of all the SQL queries that were
executed during the request (in the spirit of the commented out print
lines I've left in IterableCursor).

-- Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Thomas | 1 Mar 2007 22:57

[Trac-dev] Reply button in tickets broken


As the subject says...haven't checked what changeset this occurred in.

--

-- 
Evolution: Taking care of those too stupid to take care of themselves.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Alec Thomas | 1 Mar 2007 23:39

[Trac-dev] Re: Discussing two changesets


I think we should roll this change back for a few reasons:                                                                                                                

    1. As Matt mentioned, it breaks the expected behaviour of the RSS feed.                                                                                               
    2. It doesn't make sense if other timline events should have occurred in                                                                                            
       between the coalesced events. eg. a wiki page is changed in between                                                                                                
       two changesets that are coalesced.                                                                                                                                 
    3. It is inconsistent with other timeline providers, such as the Wiki,                                                                                                
       where identical changes are not coalesced.                                                                                                                         

That being said, I think the ability to collapse timeline events is useful, but                                                                                           
I think it should be occurring in the timeline module itself, rather than                                                                                                 
individual event providers.                                                                                                                                               

Two options for representing this that I can think of off the top of my head,                                                                                             
with both requiring  the timline module to detect identical sequential events and                                                                                         
mark them as being from the same "group" of coalesced events (ie. a grouping_id):                                                                                         

    1. Draw every event and have JS collapse/expand them dynamically. This                                                                                            
       might clutter the interface though, if not done right.                                                                                                         
    2. Have an option in the INI file for coalescing the events server-side.                                                                                              
       Possibly with a toggle in the UI for overriding it.                                                                                                                

On Fri, Feb 23, 2007 at 10:10:07AM +0100, Christian Boos wrote:
> 
> Matt Good wrote:
> > On Feb 22, 6:20 pm, "Emmanuel Blot" <manu.b... <at> gmail.com> wrote:
> >   
> >>> I'm OK to make it optional for those not wanting that feature, but I
> >>> don't see any good reason to turn it /off/ by default.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Carter | 2 Mar 2007 04:26

[Trac-dev] [RFC] ticket-preview sandbox


All,

I'd like to get feedback on the sandbox/pycon/ticket-preview branch.

The purpose of the branch is to clean up the new vs view ticket templates
and in the process, improve the ticket previewing functionality.  To that
end, the ticket_view.html and ticket_new.html templates have been combined
into/replaced by ticket.html.

The changes that will be made as a side-effect of an action are not
included in the preview.  (I'd like to do that, but it will need some
support from workflow before it's feasable, and there are questions of how
that would be implemented cleanly.)
Also, I haven't tackled cleaning up the ticket view vs new logic in the
python code.  I believe the work done on the branch is an improvement even
without that.

Comments welcome,

Eli

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 16 comments |
headers
Alec Thomas | 2 Mar 2007 04:36

[Trac-dev] Re: [RFC] ticket-preview sandbox


+1

Only wart I see is the layout of the "username/email" field when creating
tickets.

On Thu, Mar 01, 2007 at 09:26:09PM -0600, Eli Carter wrote:
> 
> All,
> 
> I'd like to get feedback on the sandbox/pycon/ticket-preview branch.
> 
> The purpose of the branch is to clean up the new vs view ticket templates
> and in the process, improve the ticket previewing functionality.  To that
> end, the ticket_view.html and ticket_new.html templates have been combined
> into/replaced by ticket.html.
> 
> The changes that will be made as a side-effect of an action are not
> included in the preview.  (I'd like to do that, but it will need some
> support from workflow before it's feasable, and there are questions of how
> that would be implemented cleanly.)
> Also, I haven't tackled cleaning up the ticket view vs new logic in the
> python code.  I believe the work done on the branch is an improvement even
> without that.
> 
> Comments welcome,
> 
> Eli
> 
>
(Continue reading)

Permalink | Reply | 10 comments |

Gmane