Lorn Potter wrote:
> Qt's rotation is not done on the hardware level, it is done in Qt's
> software. It can be done, if the transformed driver is being used.
OK - given no tilt sensor, I'd put buttons in the corners that do the same 
thing.

Also, I've just written my first app in gtk/C.
After sobbing quietly and trying to avoid getting tears on my N800 I'm looking
forward to getting back to Qt!!

Apologies to any gtk fans out there - I just have a hard time with all the
pointer casting and trying to bludgeon the OO api into C. Qt was so much more
elegant.

check = (GtkCheckButton*) gtk_check_button_new_with_label("aargh");
Since when does a constructor need type casting?

So when can I
  maemo-rootstrap diablo50_Qt_armel
? <grin>

gary liquid wrote:
> David,
> 
> There are a number of options available to you, but each will depend
> upon your requirements.
> On the nokia device its not lack of options, but graphical bandwidth:
> the display cannot update fast enough to render full screen RGB graphics
> at fullspeed without some sort of tearing.
Ok - not a huge deal; the app is (currently) a simple gtk app; no requirement
for high refresh etc.

> However if you are willing to try, you could look at the following
> options and you may find something which suits you.
> 
> The simplest if you are producing an application which just needs to be
> on its side is to rotate your assets:
> Load in the images at 90degrees and translate coordinates around, but
> basically keep the system working as standard on stock hardware.
> Depending upon the performance level you hope to achieve this method may
> not produce desirable results, but will at least be round the corner.
> You should be able to prove pretty quickly if this approach will work
> for you with just a quick hunt through your program.
It's the gtk+ ui that needs to be sideways; tickboxes aren't a huge problem (!)
but labels, scrollbars etc are.

> The second is to actually bite the bullet and install a kernel patch to
> rotate the display.
I'll certainly investigate that. Sounds fun. links? (I'm lost - I think I'm in
maemo.org/twisty passage#341)

> A deeper more outlandish method would be to work around the graphics
> bandwidth problem by coding yourself a graphics library which is based
> on YUV (full resolution greyscale, lower resolution color) and see where
> it gets you..
Ummm, or not. <grin>
I was raised on perl - I pride myself on my laziness.

> Much like I've started to do:  http://www.youtube.com/watch?v=PUPp_mE7rwI
Hmm - that looks rather nice - are you sharing the code anywhere?
It's nothing like what I'm doing but looks fascinating and I'd be interested in
having a look.

(OK, nice is an understatement. I'd buy another N800 just to play with that!)

How about having non-linear display of the graphics? Ie scaling at the top is
x1, then gradually up to x2, linear for a while and then back down...

David

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to