re: SoC Idea: Improve bultin WordPad

[Dan Kegel]

Alex wrote:
> > > closest I have gotten is some patches for Wine's WordPad implementation.
> >
> > Granted, it's less sexy than games, but you could learn more about C and
> > Wine by building on that experience. There are lots of small and easy
> > improvements that can be done get Wordpad up to par with native. Then come
> > back next year to fix the games!
>
> That  i s  a good idea. :)
>
> I think I will go for it, unless anyone has objections to it.

Sounds good to me.  Suggestion: spend a day or two filing bugs
or enhancement requests now for a bunch of things you'd like to fix / improve
in wordpad.  (I might even suggest broadening your proposal to
include notepad; maybe there are a couple low-hanging fruit there.)
- Dan

SoC Idea: Improve bultin WordPad

[Duane Clark]

Dan Kegel wrote:
> Alex wrote:
> > > > closest I have gotten is some patches for Wine's WordPad implementation.
> > >
> > > Granted, it's less sexy than games, but you could learn more about C and
> > > Wine by building on that experience. There are lots of small and easy
> > > improvements that can be done get Wordpad up to par with native. Then come
> > > back next year to fix the games!
> >
> > That  i s  a good idea. :)
> >
> > I think I will go for it, unless anyone has objections to it.
>
> Sounds good to me.  Suggestion: spend a day or two filing bugs
> or enhancement requests now for a bunch of things you'd like to fix / improve
> in wordpad.  (I might even suggest broadening your proposal to
> include notepad; maybe there are a couple low-hanging fruit there.)

Printing please! It needs lots of work. Wordpad doesn't have it, and 
notepad printing is terrible.

SoC Idea: Improve bultin WordPad

Hi,
> Printing please! It needs lots of work. Wordpad doesn't have it, and
> notepad printing is terrible.

It will be done as soon as a cheap cure for cancer will be found ;)

Not something to be done by an inexperienced person and definitely not  
a "low-hanging fruit" of any kind.

It looks like I have an idea or two about how to deal with printing,  
but first architectural changes that have to be done, then testing it  
all, scare the hell out of me.

The problem is representing two different visual representations of  
the same physical text, one for display, one for printing (which can  
be wrapped differently, as far as I know). Some hack may be used (like  
making a physical copy of the text being printed, a separate  
ME_TextEditor structure), but it's kind of ugly and I don't know if  
such a design decision wouldn't give future compatibility headaches.  
On the other hand, a "virtual representation" may be used (for  
printing, we'd use a list of runs and lines containing pointers to  
text fragments and styles in screen representation instead of separate  
copy of the text).

The SDK documentation for EM_DISPLAYBAND and EM_FORMATRANGE aren't  
really clear to me. Maybe (pure wild speculation) there is no need to  
keep separate versions, because a client is required to free the  
printer formatting information before screen is updated? Some tests  
(reverse engineering, or just making an example application that  
prints using richedit) definitely need to be done. Anyone? :D