Hi there, I'm going to cut quite a bit to keep the discussion readable. If others are following it, please read the full messages that came before this one. > Hmm, well I think camel is a bit too complicated. It makes it > difficult to implement backends for the interface. Well, maybe a > little bit more difficult than need be. But I suppose not many mail > clients try to throw 100K+ message folders at a treeview, and expect > it not to use a lot of memory.
I have this naive idea that phones of tomorrow will have much more Internet related functionality than today's modern desktops. In a much more integrated way. I believe people hate desktops but enjoy the applications on top of it. Like how iPods are designed for playing music, car navigation designed for bringing you to your destination, DVD players for ..., cameras for ..., etc If that naive idea happens, there will be a huge demand for mail clients that can show 100K+ messages yet not use a lot memory. > But if it's too complex to use or maintain, then it is more wasted > effort. I'm becomming much lazier in my older-age perhaps! My reason is the technical challenge and the enjoyment of trying to make a difference. The path to it, not the result. It might make it more difficult for me to view things as wasted effort (but I'm also young and naive). Perfect is anti-perfect because then it lacks the possibility of improvement. It's fun and fuelling to watch people use it. That is true. > Having extra indices on disk - you're really just writing datbase > table - and all of the associated complexity, consistency and > coherency issues that implies. I wouldn't be against using one of those 'embedded' database engines like sqlite3*, mysql-embedded or db* and ask for a cursor at the model impl of a treeview. * sqlite3_prepare(), sqlite3_step(), sqlite3_reset() etc etc I fear copying the entire query result in the memory of the application (how most developers use databases in their apps) wouldn't reduce memory consumption at all. Launching a full new SQL query each time a row becomes visible, is going to cost a lot in performance. Since sorting would be done at the db, it might indeed be 'fast enough'. On a mobile device, screens are small. Amounts of visible headers too. 20 queries isn't a lot. > Maybe gtktreeview changed since i last looked at it. It was rather > slow too, iirc. There's only so much virtualisation you can do with > tree's anyway, some of the data you need all of the other data to > calculate - unless you keep another on-disk index in 'tree sort' > order, and virtualise even that. Sorting is indeed still a pain. Showing once the model is sorted isn't anymore with the current gtktreeview and fixed-row height turned on. The cursor idea and a db engine might be a quick solution for this. Databases are often very good at sorting stuff. > > Thanks a lot for your point of view Michael. I value it. > Well you've piqued my interest ever-so-slightly in mail things again, > but I'm not sure - i'm not sure I really want to get back into coding > it again, at least. Well, it's a start ;) > It would be more fun writing something a-new than trying to fix > something else, and particularly having to worry about client > compatability. Jeffrey is (or has been) (as you probably know) working on libspruce. A fresh Camel with input from those people who made a good E-mail library already, would definitely be something I'd both enjoy using as a devel- oper and co developing of necessary (I like getting my hands dirty). I, however, realize that I lack field-experience to make such a thing my one person show. On top of that it's quite a lot man-years of work to have something that works only a little bit better than current Camel (and not as significantly better that people would pick it over Camel). I'm experienced enough to realize that ;). I didn't start tinymail as a specialist in E-mail. Which probably explains why I'm doing so many refactor iterations. But redesigning is imo okay. I just called it "Agile" as explanation why redesigning and rethinking is important. Not being afraid of changing things is in my opinion important. It's a problem the Evolution project is, I think, experiencing. But I'm powerless when it comes to Evolution. I look at Harish and technical Novell decision makers and Novell management to solve this. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
