I totally agree, I love the sketching, it is so natural on this device and is closest to my thoughts and I use it every single day.
Development is continuing on it, I just have a number of chicken and egg problems which need solving before the next visible iteration emerges.
The test screens I write would normally live in stand alone projects, but since liqbase isn't a library this is not practical (if anyone does want to talk to me about creating a library version I would be eager to know the details).
In vb, its insanely easy for me to create a whole new project and get the input method correct before transposing into the real project.
This is the most natural way for me to work.
I have a more integrated plan for the sketching system as it stands, and a new simplified sketching front end showing recent history and tagging and a big clear simple start sketching button is the aim.
This will be the default entry for the application though this should also be configurable.
I like the idea of performance by default, it does make a big difference.
stability is as high as I can personally make it, if the xv system returns a failure and locks up what am I as a user application to do?
otherwise I believe liqbase is as stable as I can make it.
if you have a specific stability problem please let me know.
I'm actively thinking about additional tools (circles and erasers and other things) and hope to expand this nicely very soon.
once my chicken and egg problems are fixed I will be motoring
I suppose I'm just not used to public development or discussing my ongoing code, I've done these kinds of test screens for years quietly and integrated the results into my focused work projects, I spend my downtime learning and trying new things.
I have taken everything on board and its working its way through my brain
1) Thank you for this program and while it is in its early stages it has HUGE potential. You also have a really great attitude that you can listen to suggestions and criticisms and keep moving forward.
2) Whenever I see the name of Lcuk, I think of LeChuck from the Monkey Island series
3) Last, I was wondering if there is any way to reap some of the speed improvements that you have obviously dug into through Python? For me, Python has been my only successful means of programming on the Nokia but it's kind of slow when it comes to moving graphics around. Could I somehow initialize the screen in the same YUVV thingy format that you are using? (Sorry, I read how you set the screen mode up long ago and it's mostly deteriorated at this point).
this is the very first time I've ever built anything like this before, I know I have made and will continue to make mistakes. If I am not smart enough to listen to the people around me then I should not be here.
I bought this device to use it to its fullest potential, and was determined to do whatever I had to do to get it to FEEL like I always imagined it should.
I did not want to get bogged down with learning how to load images, or how to blit things onto a screen or create a (very poor) widgetset from scratch, I wanted to be coding my pretty UIs and scratching at the screen making more and more new connections with my sketches.
Every time I do one of these test projects I think "why isn't the email like this" or "why can't blah be tearfree" "why can't the app manager list be kinetic" "why can't I use the brightness with my finger", and by releasing them and showing them it will hopefully give people ideas and we can work together to find a way to improve the experience for everyone on current hardware.
I know I'm never going to write a book reader which competes with fbreader, and I wouldn't want to try. But I don't see why we cannot use this kind of rendering in fbreader itself.
If some enterprising young coder wants to take a look, I will be happy to work with them (obviously liqbase itself may need expanding to cater with requirements).
this applies to many things.
I think the only way to bring faster code into the mainstream to improve the performance for ALL applications is exposure.
If I show people it CAN be done, I'm hopeful they will try to take those ideas and build from them.
Maybe someone could find an alternative method (like lower resolution RGB) which negates liqbase totally and just gives global performance boost.
At least they are looking because of me.
As for python I'm just looking at a few things regarding creating a library or plugin architecture, depending on which way I go, it should be possible in the future to do such a thing.
I wouldn't know the first thing about it though, lemme see how this library goes.
If it makes development any easier, I build everything in C but I have a windows installation and do compiling directly on the n810.
I copy the files needed for editing using winscp and edit in komodo edit.
Its reasonably slick and whilst its not the fastest in the world helped me to bypass a whole brainfunk of scratchbox.
I just have to give some props to lcuk for actually making a camera app that doesn't crash the 810. I love this app and I cant wait to see the improvements to come! Great Job!
The tablet doesn't crash, but the photos are tiny, much smaller than the 640x480 frame size that the camera is capable of. That might be one of the reasons the tablet doesn't crash.
As for rotation and mplayer (I'm not sure which thread we were discussing this in): it doesn't scale video properly when rotated 90 degrees. I made a test video with the correct aspect ratio for fullscreen video when rotated (400 high, 240 wide); it doesn't scale correctly at all.
3) Last, I was wondering if there is any way to reap some of the speed improvements that you have obviously dug into through Python? For me, Python has been my only successful means of programming on the Nokia but it's kind of slow when it comes to moving graphics around. Could I somehow initialize the screen in the same YUVV thingy format that you are using? (Sorry, I read how you set the screen mode up long ago and it's mostly deteriorated at this point).
When moving graphics, the bottleneck is not Python, it's the X server and its tricky design with client-side and server-side graphics.
liqbase circumvents this (network-stuff) by directly rendering to the framebuffer. Using a lower resolution and the 12bit YUV colorspace instead of 16bit RGB, it gets blazingly fast.
SDL and EFL also circumvent the network-stuff and render directly on the X server (using shared memory). Python bindings for both exist.
But if you try moving graphics with GTK it will always be slow, no matter if Python or C. The bottleneck is the network, because X is designed to be completely network-transparent.
I'm impressed with what you've done so far, but would like one feature on the next version to help a bit--deletion of a sketch or photo.
Sometimes you want to get rid of a graffitti or a bad photo.
**[edit] Until I went to the liqbase website and started reading I didn't realize that there was a delete (albiet rename at this time) function. The problem is that most of the command "windows" are compressed so that I cannot read but one or two characters of the command words. Is there a "fix" for this problem? I suspect that it is that another lib is setting some default width.
allnames, draw the icon in liqbase (see my sig as an example)
all screens allow for [Fullscreen] screenshots to be taken.
pycage, theres other reasons, and its 24bit resolution
qole, thats what I noticed as well.
rdcinhou, yes sorry about the deletion/renaming - will be resolved asap.
its not a library issue other than inside liqbase, its all handcoded and I don't get everything right everytime.
