[Ipodlinux-devel] Podzilla and PTK

[Matthew J. S. <ge...@do...>]

For those who haven't paid attention to the forums, and for the fact alone that I said I'd post on here when the time came, I'm making an anouncement.

As many of you well know, PTK has matured a fair amount to the point where Podzilla coding has begun.  I'm actually progressing through Podzilla rather quickly aswell.  However, at the moment Bernard is doing some cleanup work and additions to PTK so I'm trying to stay away from it.  Despite this I've had to make some slight changes during the Podzilla development which should be easily incorporated to whatever he does.

Anyway, this call is to all of those who were interesting in submitting ideas that they felt should be included in Podzilla.  I recommend using the forum to actually discuss this as I think it's a better medium and will serve us better to look back on the ideas and pull them in as we develop.  But to all those who were interested, jump on the forum ASAP and get your ideas out.

Here's the rundown of where Podzilla stands at the moment (tis not much, but as I said I'm progressing faster now that my laptop is set up):

- Initialization works great.  Most of the objects we see now are global and exist on a main window..  these things are stuff that a lot of functions need to be able to write to, for example the title in the header.  The clock is also global, as will be any indicators that get stuck on the footer once the indicator widget is done.

- There's some general event handling stuff in there.  Mainly just for hitting the menu key right now.  The menu key with a simple push and let off will close a window -- I plan to implement it so that holding the menu key minimizes a window and all windows will be accessible through a list added either on the Main menu or in Extras -> Windows.  This creates some unique functionality that podzilla will have over apple's firmware.  While apple's firmware no doubt could do this and may (you just don't see the inactive windows unless you close or minimize the active one) we will have more like a window manager type scenario. This means users can keep seveal windows open one with a calendar, one with contacts, and maybe a file browser or something, and switch between them.  The benefit of this is not losing your place or something if you close another window and want to come back to what you were doing with a calendar.

- With that said, I've implemented a crude window stack which is just an array of MAX_WINDOWS number of pointers to windows.  It seems pointless to go through another child/parent/sibling scheme, and the seek time to place a window in a slot and remove one should be minimal.  The current MAX_WINDOWS is set to 50 which will probably be extremely high.  Once some testing is done It'll probably get cut down quite a bit.

- The main menu initializes, however, right now all the functions are ptk_nullvoid_function.  There's an issue at this point in the game with the way the listbox widget is designed, and I'm probably gonna have to rework some of it, but I'm waiting till Bern finishes up as that's more of a major bit of work.  The problem is as follows:  I want to make all items essentially the same, thus we have all items containing a pointer to a function which is to be called when that list item is "executed" so to speak.  However, depending on what the list item is, these function may require different types and amounts of arguments.  So I'm still cooking up a way to fit around that.

- There's some crap animation job I did that slides the windows off to the right when they are minimized.  Maximizing a window slides it back in from the left -- similar to apple's -- not sure how smooth it's going to be yet as I've only tested this on X on my laptop where it's actually not that great looking.

- I've pulled in the old ipod.c file I used with the settings stuff, so basically the old podzilla.conf system is what I'm gonna stick with, which I find personally to be the better way to keep it going.  It's still up in the air how the menu's are going to be formed.  The options are to keep all menu information in a structures or to have it in a file and then have those parsed onto the menu.  Either way there will exist two major menu functions... the first is for the main menu -- this requires it's own function as the main menu is configurable from within the iPod such as apple's firmware is.  Thus it's construction looks something like:

Pseudo code:

   if(main_menu_option == True)
	add the proper option to the menu

All other menus just need to run through the list and add each thing in the list to the menu, thus those will be created using a simple generate menu function which will run through the structure or a section of a config file and put everything in place.  File menus will of course also have their own function that actually reads the directory.  Eventually I would suspect that menus built on the iTunes database would also have their own menu function. -- this however seems messy, and I may look for a cleaner solution later.

I think that's about it for now.  Podzilla "looks" fairly interesting as it stands -- but really doesn't do much of anything yet.  Any ideas or suggestions on how to fix any of the problems (especially the one about item's function pointers) are going to be very well received.

Lastly I'd just like to note some oddities and see if anyone out there with more technical skill than me can figure out why these happen:

1)  In the PTK I handed of to Bern a couple days ago and what is currently linked in the forum things that created their own Graphic's Contexts would copy the original ptk_gc context -- thus creating a new one that is a copy.  In their destroy functions they used GrDestroyGC to destroy it.  However, I noticed upon destroying a listbox in podzilla that it seemed GrDestroyWindow attempted to destroy the GC aswell.  This didn't make much sense to me because the Window doesn't really seem to have any way of knowing what GC is related to it.  I double checked to make sure my relative update functions weren't accidently calling the destroy on a few things twice, and eventually boiled it down that GrDestroyWindow pretty much has to be what's also trying to destroy it.  To resolve this I took GrDestroyGC out and just let the DestroyWindow handle it, however, I'm confused where this actually destroys the graphics context -- whether it somehow gets destroyed in my code or via microwindows stuff I don't know, but it DOES try to destroy it twice if both GrDestroyGC and GrDestroyWindow are used.  The bug itself was microwindows spititng out a bunch of crap about being unable to destroy the Graphics context and then seg faulting.  As I said, it's fixed by using just GrDestroyWindow but I'm really curious and want to ensure that the graphic's context is being destroyed properly.

2)  For those who aren't familiar with my coding background or who don't hang out on IRC enough, I pretty much openly admit that I'm not a very good programmer.  Despite this I move on for you the people.  However, having no experience really with programming a toolkit or graphical applications in my life, I'm a bit confused with some of the concepts.  One of these is the idea of the exposure.  While I understand what kinds of things can cause the exposure event, I'm unsure exactly why or why it shouldn't be handled.  The Podzilla event handler right now does nothing on an exposure event, and windows only get redrawn really when they are directly changed by podzilla. While PTK draws when a window is created and such, it by no means does it any other time, and with no concept of event handling does nothing on Exposure either.  However, the weird thing about this all is that the Podzilla window on X seems to flicker as if it's being redrawn a tad bit slowly or something.  It does this somewhat randomly, sometimes about a second apart here ot there, sometimes longer -- I suppose it may not actually be redrawing -- as I don't see where it would be... but any ideas what might cause this flicker on a Microwindows, X11, or Podzilla/PTK level?

LAST FEW NOTES:

Aside from removing GrDestroyGC from the destroy function in PTK I noted that PTK_CH didn't exist anymore, I had two PTK_CHAR's in ptk.h -- so I fixed that real quick by making on PTK_CH.  I also ensured that the listbox, slider, and window based widgets cleared their windows before the redrew themselves.  And I added a quick eventhandler function to widgets -- I may end up laying groundwork for PTK event handling, however, right now it's only there so that event handlers can be set on various widgets to actually handle keypresses.  The original Demo didn't have this issue cause it only had one listbox and the event handler called it's functions directly, but since the event handler is not 100% centralized in PZ (at least not for keypresses) they each have to be aware of keypress function to call in the event a key falls to them.

I guess until Bern is done with PTK and I come up with some other ideas I'll be trying to wrap my head around how microwindows handles 16-bit unicode and fonts and stuff and trying to make that a reality so I can convert PTK_CHAR's to wchar_t and use wchar based functions when necessary.  There's still a long way to go in terms of internationalization support.

I'm sure I'll figure it all out in the end...

Sincerely,
Matthew J. Sahagian (Efram)