Open Question : Glittering Features or Stability?
Gregory Brown
I'm trying to get a sense of direction and focus for the remaining 200
hrs or so of work on Prawn that I plan to do over the next several
weeks. I want to poll our users for their opinions, since Ruby
Mendicant was funded by the community. Is the most important thing
for Prawn right now to try to build up its feature base, or is it to
focus on being tight, fast, and clean?
In my mind, there is merit to both approaches. If additional feature
work feels like a necessity to folks, I don't mind working the rest of
the summer on core functionality that seems to be in high demand.
However, if people want to see me focus on getting the bare framework
tuned, I'd be happy to do that instead. Either way, some degree of
both will happen... if I go with moving ahead to implement as much
stuff as possible, I'll still be stopping to refactor some, and to
check in with performance and whatnot. If I focus on the tuning
itself, new features will still make it in as we see fit.
However, part of me feels like the best thing for the project would be
to ignore the swarm of excitement and requests for glittering
features, and focus on building a tiny, solid, and wicked fast core.
This will in turn make future expansion easier, and make it possible
for contributors to implement the features they want. Since it is
rare to have an opportunity to really spend the necessary time to do
things 'right', it seems like I should take advantage of that.
All comments are welcome. I'll try to plot a course in accordance
with people's wishes on this.
-greg
--
Technical Blaag at: http://blog.majesticseacreature.com | Non-tech
stuff at: http://metametta.blogspot.com
Rob Kaufman
I'd advocate getting the tuning done. It seems likely that once you start calling the framework stable and fast that people will use it, see features they want and submit patches. I don't think people see features they want, use it even though it's not stable, then spend time submitting tuning patches as much.
Just A Hunch,
Rob
Gregory Brown
> Hi Greg,
> I'd advocate getting the tuning done. It seems likely that once you start
> calling the framework stable and fast that people will use it, see features
> they want and submit patches. I don't think people see features they want,
> use it even though it's not stable, then spend time submitting tuning
> patches as much.
Good to hear. The more I think about this, the more I want to work on
our existing features so that I can be sure to get their API right, be
happy with the way they work, etc.
Does anyone object to this?
Lee Irving(MagpieUK)
thorny_sun
new features-- i would love a way to turn text 90degrees-- to make
skinny columns that still have meaningful headers. If you decide not
to build, please do give me any hints you can think of since I will be
trying to build myself then.
James Healy
> Stability/speed is definitely good-- but if you did happen to work on
> new features-- i would love a way to turn text 90degrees-- to make
> skinny columns that still have meaningful headers. If you decide not
> to build, please do give me any hints you can think of since I will be
> trying to build myself then.
I just had a quick crack at rotated text support, and the basic patch is
quite small.
http://github.com/yob/prawn/commit/ebbc97e482c7eed1564d3330c00d8e987d991b61
I imagine before Greg even considers merging it though, we'll need to
think through the ramifications on bounding boxes (the basic building
block used to render table cells).
At the moment, each bounding box in a table calculates it's desired
dimensions and then there's some smarts that decides final column
widths, row heights, etc.
Until the bounding box can recognise that its contents will be rotated,
it will assume no rotation and size the table cell incorrectly.
-- James Healy <jimmy-at-deefa-dot-com> Wed, 20 Aug 2008 00:13:55 +1000
Dominic Sisneros
bounding_box
bounding_box [100,600], :width => 200, :rotate => 90 do
text "The rain in spain falls mainly on the plains " * 5
stroke do
line bounds.top_left, bounds.top_right
line bounds.bottom_left, bounds.bottom_right
end
end
Gregory Brown
>
> Stability/speed is definitely good-- but if you did happen to work on
> new features-- i would love a way to turn text 90degrees-- to make
> skinny columns that still have meaningful headers. If you decide not
> to build, please do give me any hints you can think of since I will be
> trying to build myself then.
This request is one we accepted and it looks like James Healy is
working on it, and I'll try to polish it up today for inclusion in
Prawn 0.2
To clarify about working on new features, if I encounter missing core
functionality, or I find features that can be implemented within the
course of a couple hours, I'll be adding them. For this reason, I
hope as many people as possible continue to submit requests.
However, features that require multiple days of effort will probably
be put on the back burner until I feel like the core is stable. This
means that you're going to see a lot of 'cool' tickets piling up in
the "On Hold" section. If making the core as stable as I want it to
be takes less than the allotted time, you can bet I'll be working on
some of those.
But yeah, text rotation is important, so we'll do what we can.
Gregory Brown
I have no intention to support rotation in flowing text, unless
someone shows us a magical way to make this work.
I think of positioned text as a drawing operation, so it would just
overflow the bounding boxes (requiring a height).
Once I add the ability to table to replace a cell with an Element
(which is essentially the LazyBoundingBox stuff I just added plus some
niceties),
you'll be able to position rotated text within an element so long as
you've specified a height and width for the element.
In the short term, we can add the functionality for text rotation, to
only be used with :at, and I may be able to add something like:
:header_layout => :vertical in table. We'll see... that's starting to
sound a lot like work :-/
Gregory Brown
>
> I think another thing that would be usable is the ability to rotate a
> bounding_box
Good luck with that patch. :)
Sean
as a programmer's toolkit (i.e., sharp knives) rather than a turnkey
solution (i.e., a soggy hoagie).
So, far it's got all the glitter that I need. Thanks again!
On Aug 18, 12:42 pm, "Gregory Brown" <gregory.t.br...@gmail.com>
wrote:
Gregory Brown
>
> I vote for tight, fast and clean. I would prefer that Prawn function
> as a programmer's toolkit (i.e., sharp knives) rather than a turnkey
> solution (i.e., a soggy hoagie).
>
> So, far it's got all the glitter that I need. Thanks again!
Okay, that's enough positive support to convince me. After 0.2.0, I'm
putting forward progress on hold until I feel very happy with the
core.
This certainly means small, incremental improvements to the existing
feature set, and filling in major missing components if we discover
them.
However, large feature requests will be put on hold, and I'll be a
little slower to pull up code until the core is in good condition.
That having been said, don't let that stop anyone from contributing!
File the requests, keep the forks going, and let's see where we're at
in a few weeks.
I'll get out 0.2.0 tonight or tomorrow, and then we'll work on
stabilizing things a bit from there.