State of morphic
Hi Sig,
I look forward to seeing your enhancements.
The best way to address these issues is to raise a flag for each of them in the form of a mantis report.
Keep separate ideas separate and possibly also create a mother report for collecting similar ideas together under one banner.
The challange with putting complaints on mantis is 1) to describe each problem clearly. I usually give a simple recipe for running into trouble. And then 2 ) to add to the report as you gather more information or code to support your view of things.
No one here is tasked with solving other peoples problems (or good ideas) for free. If you are the first one bugged about something. You are probably also the first one who will do something about it. No matter how long it takes.
Mantis provides the possibilty others will notice and support an issue. And it provides patience and persistance to get the fixes in front of the release teams.
Here are the Faqs:
FAQ: Is this a known issue ? Where is the place to report bugs (or check if some have already been raised) ?
The best place for this info would be to start a Mantis report. (You can get a mantis acct freely and easily).
A good place to start is:
http://bugs.squeak.org/my_view_page.php
Mantis provides a patient persistent way to focus on an issue. I use it to accumulate data on a problem until a solution can be found. It provides a place to alert the community to a problem; -accumulate facts and clues from the analysis; -publish preposed solutions and get feedback; -get solutions harvested and included into the main stream.
This FAQ is available at the Squeak wiki site. http://wiki.squeak.org/squeak/Mantis%20FAQ%20and%20Tips aka: http://wiki.squeak.org/squeak/5912 Mantis FAQ and Tips
***
Igor Stasenko siguctua at gmail.com Mon Aug 27 15:40:49 UTC 2007
Jerome, thank you for good overview. My personal interest, as you may know, is the
graphics part of morphic.
I'm developer of GLMorphic project, which draws all
morphs using openGL.
There are some things which i wish to be cleaned up /
rethought.
First is the hard-wiring with Forms and blitting: i
don't like, that
many morphs relying on fact, that display surface
represented by
rectangular area of pixels (Forms), and can be
manipulated directly
with blitting operations. This is what i want to be avoided at all, and to draw
all morphs using
calls to canvas only.
Second is font rendering and paragraphs rendering.
Most of morphs use
paragraphs to hold text, and paragraphs using special
class like
CanvasCharacterScanner which containing very complex
and ugly (IMHO)
code to render text. I don't know why simple text
rendering became so
complex in respect to rendering paragraphs. And i
wish this to be
simplified someday. Personally i don't think that message
#paragraph:bounds:color: need to
be included in Canvas protocol, since its too complex
to pass in
single command and always splitting to more basic
commands like draw
string.
-- Best regards, Igor Stasenko AKA sig.
***
____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
On 28/08/07, Jerome Peace peace_the_dreamer@yahoo.com wrote:
State of morphic
Hi Sig,
I look forward to seeing your enhancements.
The best way to address these issues is to raise a flag for each of them in the form of a mantis report.
Keep separate ideas separate and possibly also create a mother report for collecting similar ideas together under one banner.
The challange with putting complaints on mantis is
- to describe each problem clearly. I usually give a
simple recipe for running into trouble. And then 2 ) to add to the report as you gather more information or code to support your view of things.
No one here is tasked with solving other people's problems (or good ideas) for free. If you are the first one bugged about something. You are probably also the first one who will do something about it. No matter how long it takes.
Mantis provides the possibilty others will notice and support an issue. And it provides patience and persistance to get the fixes in front of the release teams.
Here are the Faq's:
FAQ: Is this a known issue ? Where is the place to report bugs (or check if some have already been raised) ?
The best place for this info would be to start a Mantis report. (You can get a mantis acct freely and easily).
A good place to start is:
http://bugs.squeak.org/my_view_page.php
Mantis provides a patient persistent way to focus on an issue. I use it to accumulate data on a problem until a solution can be found. It provides a place to alert the community to a problem; -accumulate facts and clues from the analysis; -publish preposed solutions and get feedback; -get solutions harvested and included into the main stream.
This FAQ is available at the Squeak wiki site. http://wiki.squeak.org/squeak/Mantis%20FAQ%20and%20Tips aka: http://wiki.squeak.org/squeak/5912 Mantis FAQ and Tips
Well, i agree that problems must be described precisely and also possible ways how to solve them. But i doubt that someone except me (or others who look forward to support GL rendering) will support the changes. A most 'killer' arguments always be: it works fine now, why do we need to change anything? And then: you can keep your changes in your image.
And such position doesn't helps with moving forward for the benefit of all.
You can reread my early notes on all of this. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-April/115907.htm... I described most of my problems there :)