Hello,
I am working since a long time with zope and was continuously worried about
a few problems, unfortunately none of them was fixed along the years:
- zserver can not 'recover' busy thread
- log show nothing in case of blocking: log is written when the request is
completed, and the log is
Hi,
The zope management interface has some robustness problems:
whenever you call manage_workspace (the normal way of managing a folder
through the HTML Zope management interface) on a folder X, and some
object y in that folder gives an error (fi, it has no title attribute, )
the whole folder
Romain Slootmaekers wrote:
Hi,
The zope management interface has some robustness problems:
whenever you call manage_workspace (the normal way of managing a
folder through the HTML Zope management interface) on a folder X, and
some object y in that folder gives an error (fi, it has no title
Jim Washington wrote:
Romain Slootmaekers wrote:
Hi,
The zope management interface has some robustness problems:
whenever you call manage_workspace (the normal way of managing a
folder through the HTML Zope management interface) on a folder X, and
some object y in that folder gives an error
Ooh! I've been thinking about something like this as well; PyQt would
definately be the way to go. The backend should be de-coupled from the UI, of
course.
Getting the gears turning,
Eron
On Friday 07 February 2003 12:47 am, Shane Hathaway wrote:
Zope-Dev'ers,
Just for fun, I made a mockup
On 02/07/2003 11:43 AM, Gilles wrote:
Hello,
I am working since a long time with zope and was continuously worried about
a few problems, unfortunately none of them was fixed along the years:
- zserver can not 'recover' busy thread
- log show nothing in case of blocking: log is written when the
On Fri, Feb 07, 2003 at 10:06:55AM -0500, Shane Hathaway wrote:
You have to keep it in perspective. Spin prevention is a small part of
the stability equation. Zope is quite stable--if it weren't, CBS, SGI,
and others wouldn't use it.
Indeed. To put this in perspective, I have had exactly 1
On Fri, Feb 07, 2003 at 10:32:44AM -0800, [EMAIL PROTECTED] wrote:
If there is any interest in a framework that could provide the underlying
functionality to multiple UI front-ends, as well as automated stuff like
alerts/monitoring, I would certainly be interested in using and contributing
to
On 02/07/2003 02:16 PM, Paul Winkler wrote:
On Fri, Feb 07, 2003 at 10:32:44AM -0800, [EMAIL PROTECTED] wrote:
If there is any interest in a framework that could provide the underlying
functionality to multiple UI front-ends, as well as automated stuff like
alerts/monitoring, I would certainly
[EMAIL PROTECTED] wrote:
I'm not sure I understand the reasons why this solves the consolidation
problem (i.e. I have 2 dozen ZEO clients and 2 ZSSs and want to manage them
remotely in a single interface). Please explain.
mix 1 part ssh, add shell script to taste
It would be trivial, for
Paul Winkler wrote:
... which, FYI is kind of a pain to use with zope prior to
CVS / 2.7, because zope insists on forking to the background
unless you run in debug (-D) mode, and daemontools (or rather, svc)
is designed to work with daemons that can be run in the
foreground. So we can either
On Fri, Feb 07, 2003 at 03:16:46PM -0500, Shane Hathaway wrote:
Okay, I added some features to the mockup:
http://hathaway.freezope.org/Images/controller_snapshot2.png
I dig it.
(clicking on the mockup buttons) Ungh. Can't seem to make it work.
(drool drool)
--
Paul Winkler
The buttons work; you are not clicking with enough pressure. Try again
until your wrist hurts. ;)
I agree, this looks nice. I also wonder about adding total memory usage for
each Zope ZEO client.
Also, this layout could be tweaked to have a more vertical look and likely
work in a PyQT app on
13 matches
Mail list logo
