i'm back, i've reach the end of my hollydays :(
Le Vendredi 6 Ao=FBt 2004 18:56, Jason K a =E9crit :
> At last! I figured out the issue of the screwed up recipe view (after
> finally upgrading to KDE 3.2.3 a couple days ago). After all the time put
> into this, it turns out that all we had to do was call
> sizeCalculator->view()->layout() before we tried to get the height. I
> guess this is an optimization by khtml, putting off the layouting until it
> is needed.
That's a very good news, now i'm on KDE 3.3rc2 and the problem is now=20
> Now I've been thinking about releasing. We've fixed several critical
> bugs, most importantly the recipe view and the problem of displaying
> certain characters in certain character sets. And of course, there are
> the numerous new features and usability improvements.
I've noticed a little bug with characters encoding when you want to export=
recipe with a title containing non latin1 chars, eg:
recipe name: Marbr=E9 de foie gras de canard au vinaigre de miel et coulis =
export in html file: Marbr=C3=A9 de foie gras de canard au vinaigre de miel=
coulis de kaki.html
Like you, i think it's time to release ;)
> First off, are there any features you all wanted in before 0.6? I'm
> certainly in no rush to get this out. I actually want to test this very
> well before releasing. I certainly don't see a release in the very near
> future. I just want to start thinking in that direction and to have it in
I was thinking about a screen keyboard (the future is a lcd touch screen in=
the kitchen ;) ).
=46irst i've looked at KDE Accessibility, but they haven't done something l=
that. I've read that QTopia has something like that:=20
so as QTopia is under GPL we can port the class under KDE.
What do you think of that?
> Bugs I still see are doing an advanced search with categories (the
> subcategories messed this up), which I'm working on now. There is also
> the rendering of QListViewItems in the Ingredient Matcher. I've tried to
> tackle this problem, but it seems to be outside Qt's API to have an item
> act as a header like we're using it. How do you want to handle this?
Do you talk about the header line which is not centered?
If yes, i think we can use a widget on which we add a klistview per result=
(one for matching recipes, one for 1 ingredient missing, etc...).
Also in the ingredient matcher, if you have some recipes with no ingredient=
they are always listed. It could be fine if this type of recipes will not b=
displayed in the matcher list or display recipes with at least one selected=
> In the meantime, I'll be doing some more fun bug hunting :p
I'll also do that ;)
Dis, Papa, ca veut dire quoi "FORMATTING DRIVE C:" ?