Keith --
I was trying out your MADivsRenderer this evening and found that if my
description class has no cssClass specified, that the following causes
problems when the call to "(self classFor: aDescription)" returns
nil.. It then tries to append "clear" to the list and that gets me a
DNU.. It took me a while to track it down as I initially thought it
might be a general Migritte issue.. Anyway,
MAComponentRenderer>>classFor: has a call to #reduce at the end and if
the class list is empty it returns nil which is where the initial nil
is coming from. I checked to see what Squeak has for the #reduce:
method and it also returns nil when the OrderedCollection is empty --
so this bug should be reproducible on Squeak as well..
I suppose one work-around would be to change
MAComponentRenderer>>classFor: to check if it gets nil back from the
reduce call and not return a nil object or perhaps something else like
changing MADivsRenderer>>renderContainer to check the return value of
#classFor: to see if it gets a nil back and if so create a string
object....
comments/suggestions welcome..
Greetings,
The videos at http://www.lukas-renggli.ch/smalltalk/pier are causing me
some problems.
When I download a video, e.g, "Creating Pages and Files" and play it,
all I see is the initial page just sitting there. No mouse movement,
nothing changes and there is no audio.
Is anyone else experiencing this? I am using Windoze XP and using VLC
Media Player to play the video.
Thanks,
Frank
---------- Forwarded message ----------
From: Paolo Bonzini <bonzini(a)gnu.org>
Date: Aug 14, 2008 10:45 AM
Subject: [Help-smalltalk] Magritte ported to GNU Smalltalk
To: help-smalltalk(a)gnu.org
I committed a port of Magritte and of the Seaside bindings to
Magritte. This highlighted a few bugs (in the class library and in
gst-convert) and provided a better stress test for the Seaside/Swazoo
pair.
You can test Magritte-Seaside by doing
gst-package --start Seaside Magritte-Seaside
and pointing your browser to http://localhost:8080/seaside/editor.
Paolo
_______________________________________________
help-smalltalk mailing list
help-smalltalk(a)gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi,
I'm trying to use MAOneToManyComponentEditInPlace, and can't realize
how it is supposed to work... what I want to do is add rows and edit
them "InPlace"... now I can add new rows, but empty ones. Is possible
to edit them? how?
Thanks in advance,
Esteban
Hi all..
I'm trying to wrap my brain around the above classes and what they
offer over the default rendering that Magritte offers
(MATableRenderer)... To that end, I've seen a few little snippets
using a little of the above but still can't seem to figure out the
typical usage scenario.. I've got existing css that I would like to
use to dress up various pieces of one or more objects -- similar to
what Keith has submitted in photo form here on this mailing list
earlier this year (enclosing various fields in boxes,etc).. Anyway, if
someone can post a little code that can do something akin to that,
that would get me past my current hurdle.. MANY thanks in advance!
-- Rick
Hi all,
I've got a class inherited from PRPage with some additional
properties, and I want to hide those properties from all but the page
owner at edit time. The problem is that PREditCommand doesn't pass the
context to the page before requesting its description, so the page
instance doesn't have the necessary information to dynamically change
its description.
I can get the required functionality to work, by overriding
PREditCommand>>description to make decisions about how to render the
page, but that seems I wonder if there's a better way to approach
this? In other words, is there a sensible way to make PRPage aware of
the context in which its edit form is being rendered? I was
contemplating adding context as an instance variable on PRPage and
setting it from PREditCommand, but I suspect that if that was a
sensible approach, it would have been done already!
I've only just started using Pier in earnest, so if this question
exposes a lack of understanding of anything fundamental, please feel
free to point this out.
Cheers,
Michael
Hi
I recently read an article how KDevelop handles threading and that got
me thinking. As far as I understand Pier currently uses a global lock
for all write operations (where #isView returns false). All good an
fine so far. But shouldn't this be a a read-write lock? Imagine the
following scenario:
- a view command is executed, is starts to read some objects, iterates
over some objects
- the current process is unscheduled
- a new process is with a write command is scheduled, it executes to completion
- the original view command is scheduled a again but it has
inconsistent information, eg the parent of an already read structure
has changed
A read-write lock should not affect performance because it allows
multiple concurrent readers.
Cheers
Philippe