[
https://issues.apache.org/jira/browse/PIVOT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908221#action_12908221
]
Greg Brown commented on PIVOT-633:
--
Note that, in order to use the geom primitives effectiv
Provide automated support for setting enum values
-
Key: PIVOT-634
URL: https://issues.apache.org/jira/browse/PIVOT-634
Project: Pivot
Issue Type: Improvement
Components: core-beans
Eliminate use of GraphicsUtilities.drawRect() and drawLine()
Key: PIVOT-633
URL: https://issues.apache.org/jira/browse/PIVOT-633
Project: Pivot
Issue Type: Improvement
Co
[
https://issues.apache.org/jira/browse/PIVOT-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown resolved PIVOT-632.
--
Resolution: Fixed
> Add a source argument to Action#perform()
>
Add a source argument to Action#perform()
-
Key: PIVOT-632
URL: https://issues.apache.org/jira/browse/PIVOT-632
Project: Pivot
Issue Type: Improvement
Components: wtk
Reporter: Gr
For me TextPane is Ok, +1 .
Sandro
> Do you have time to quickly summarize what text based components &
> containers you envision for Pivot 2.0?
Pivot 2.0 will include the same set of text components as earlier releases:
Label (read-only, optionally wrapping, unstyled label)
TextInput (single-line unstyled text field)
TextArea (mu
Greg,
Do you have time to quickly summarize what text based components &
containers you envision for Pivot 2.0?
Names are not so important here, I am just trying to understand the features
that would be available.
I suppose the most important points are whether they would be editable or
not, comp
> I think it depends on a few factors such as the actual code complexity
As I mentioned earlier, the code is simply more complex than it needs to be at
the moment. Removing what I would consider to be non-essential code from the
existing rich TextArea component and related DOM classes will strea
I think it depends on a few factors such as the actual code complexity,
memory footprint and other benefits and capabilities for styled text etc.
Its not clear it's a high-priority area for pivot as a project.
I built a read-only text area based on the jse's line breaking support
classes, multiple
It occurs to me that this would require the developer to use two box panes - an
outer one, with dividers enabled, that would contain a number of inner ones
representing the actual toolbars. But that doesn't seem like a bad thing,
necessarily.
Then again, this can already be accomplished using T
I'm ready to rename the new TextArea2 class to TextArea, but I first need to
rename the existing class. Can we come to a consensus on the new name for this
class? My vote is TextPane.
No one yet, as far as I know. We need to finish the features for 2.0 before we
can document them. ;-)
On Sep 10, 2010, at 12:10 PM, Sandro Martini wrote:
>
> I wasn't aware of this ... who is working on this ?
>
> I'll try to look, and fix it if it's enough simple, otherwise we could make
> t
I wasn't aware of this ... who is working on this ?
I'll try to look, and fix it if it's enough simple, otherwise we could make
this for the 2.0 in the base css.
Bye,
Sandro
--
View this message in context:
http://apache-pivot-developers.417237.n3.nabble.com/Improvement-to-Css-for-Printing-Tu
You are welcome to try to fix it, but the CSS (and the tutorial) is going to
get a major overhaul as part of the 2.0 release, so it may not be worth the
effort.
On Sep 10, 2010, at 12:01 PM, Sandro Martini wrote:
>
> Hi to all,I've just seen that printing from the Browser some Tutorials pages
Hi to all,I've just seen that printing from the Browser some Tutorials pages
(for example this: http://pivot.apache.org/tutorials/wtkx-primer.html ) that
some elements are present in the print (the main menu on the top, and the
secondary menu at left), but with some little changes (I think :-) ) t
> What specific bugs did you find? As far as I know, I've worked them all out
> now.
I had some trouble getting bulleted lists to work.
>> Yes, we can do this. But I am genuinely concerned about the stability and
>> maintenance of RichTextArea - not because the work that Noel has done
>> rece
Just a little more background on this - to me, it is as much a question about
process as it is about design. Like most open-source projects, Pivot is a
volunteer-driven effort with limited resources. In order to be successful, we
need to map our development process to these constraints. That's o
Greg Brown wrote:
> I noticed a few bugs, though Noel may be planning to work these out before we
> release 2.0. Also, we'd ideally want to
> include a RichTextToolbar component along with RichTextArea, since most
> developers will want to use the two together.
What specific bugs did you find?
I actually like TextPane:
1) As I mentioned in the other email, it doesn't imply editability but can also
support it in the future.
2) The "Pane" suffix makes it clear that it is a container and therefore used
for layout.
3) Since its primary purpose would be to support text-like layouts (wher
[
https://issues.apache.org/jira/browse/PIVOT-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908001#action_12908001
]
Greg Brown commented on PIVOT-631:
--
As I mentioned, after giving this some thought, I don't
That is a good suggestion. Maybe adding a showDividerLines style to BoxPane
would be a better way to handle dividers than a dedicated BoxPane.Divider
component.
On Sep 10, 2010, at 8:09 AM, Olivier Dutrieux wrote:
> Me to have a vertical separator I put each components into a cell of
> TablePa
>> The existing (rich) TextArea class can certainly be used for this purpose,
>> but it currently has a lot of baggage since it supports editing. A pure
>> "text pane" wouldn't need such support, so it would significantly simplify
>> the codebase if we were to eliminate it.
>
> Perhaps I am misund
Add an Orientation property to the org.apache.pivot.wtk.Separator component
---
Key: PIVOT-631
URL: https://issues.apache.org/jira/browse/PIVOT-631
Project: Pivot
Issue
On 10 September 2010 08:42, Greg Brown wrote:
>
> The existing (rich) TextArea class can certainly be used for this purpose,
> but it currently has a lot of baggage since it supports editing. A pure
> "text pane" wouldn't need such support, so it would significantly simplify
> the codebase if we
NPE when using ReflectionDecorator on Dialog with TextInput inside
--
Key: PIVOT-630
URL: https://issues.apache.org/jira/browse/PIVOT-630
Project: Pivot
Issue Type: Bug
Obviously, I'm a little biased, because I did the rich text area work :-), but
I think there is a lot of value in
continuing to support the current rich text editor component.
However, I really like what you are proposing. It sounds a lot like the Eclipse
Forms project,
http://www.eclipse.org/a
27 matches
Mail list logo
