On Sat, 15 May 2010 10:48:38 +0100
Anselm R Garbe <ans...@garbe.us> wrote:
> On 14 May 2010 07:41, Anselm R Garbe <ans...@garbe.us> wrote:
> > On Fri, May 14, 2010 at 12:02:47AM +0200, pancake wrote:
> >> Is simpler to just change a pointer. We can make global. I will do the
> >> change tomorrow.
> >
> > I will review the current state today and provide my comments in detail.
>
> I had a look through everything and think overall it is a good
> starting point. Though we should concentrate on text input now (I know
> pancake did already something line based here), but I'll focus on this
> in the x11 part. Very important is proper multiline text input.
>
> I also believe we can remove quite a bit of stuff and do some
> renaming. For example I dislike the Callback term, it is in fact an
> event handler and should be called accordingly.
I have pushed the change to make SwkWindow unique in the library, by just
changing a pointer, and moving 'running' outside the struct, it was not
the right place to put it :)
Now the code is few lines more long, but takes more sense. Feel free to
change the name of what you like.
I agree that the most important part is a multiline text input widget,
this will require to fix the support for multiline widgets and.
Another issue is the thing that the graphical backend uses font size to
draw as a quad primitive..this was a simplicity decision, but imposide
some problematics in the process:
- you cannot use the drawing backend to draw in surface at pixel-level
(no posisblity to create graph widgets, paintbrush or so)
- font size is not 'quadratic' (the fonts we are going to use here in swk
are going to be fixed size, this means that ALL characters have same
width and same height, but this doesnt means height == width which
is one of the problematics of SWK actually (feel free to fix this if
you find a clear solution)..
I think we should have a 2nd variable to handle character width, and
not only height.
- while font size is drawing position multiplier, result is that you
put text and lines on the same position, so you usually need a border
to make things draw correctly, so you end up drawing extra space for
lines or just reducing font size. (any idea is welcome)
phil is writing the direct-framebuffer graphical interface backend for swk,
he plans to use it in openmoko device.
If you anselm write the x11 backend, and then the android one.. we will be
probably covering most of the platforms we use.
The thing is that X11 is probably the best option for the backend, so the
appliction will be able to look quite better than in SDL does and use the
X11 clipboard and so.. we still need to add the clipboard api in the gi
backend.
I think that having multiple GI backends is problematic because we still
dont have it well defiend, so all them will need to change at some point,
and its boring to sync all backends at a time.
But this 'problem' will be good because it will open our mind to understand
other needs or situations where the initial design doesnt fits.
I'm looking forward to see the X11 backend working :D
--pancake
