Daniel Stone wrote: > On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: >> This means abstracting >> everything with pointer indirections leading to slow > > Any performance problems you may have are not caused by excessive > pointer dereferences.
Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). >> feature-bare toolkits. > > Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity of C++ toolkit code compared to the results achieved. I find C++ harder to understand and debug compared to C. Gdb had problems with C++. GObject was unsufficiently documented to achieve a full working knowledge of what it is doing. I might be able to figure that out now, but i still find the rest of gtk too tedious to use in C. Gtk has (or had) many dozens of terse gtkdoc generated docs on apis for widgets that are deprecated. Seemingly good useful widgets had no replacements (quite a while since i looked). Various points above may be out of date to some degree. I was done with all that stuff 5+ years ago. >> Instead, X should have been ported >> to those systems and the widget toolkits should have only been a >> slight bit of sugar around an enhanced Xlib. If i ever do anything >> cross-platform, it will only be when an Xlib or an enhanced replacement >> of it is ported. > > I very much look forward to your new X toolkit: please let us know when > it's available. > > In the meantime, let's just limit our recommendations to things that > exist. I could still use freetype/pango for fonts, but it would have to be at arms length. It would have to be interfaceable to code without gobject/gtkisms. I would need to completely understand it before i even think of using it. I've read the fontconfig manual and the whole thing about fontconfig just doesn't cut it as a useable or even comprehendable utility imo. Either i understand fontconfig, or else have to do my own unicode coverage functionality which i was going to do anyway. Even if all this font stuff is made to work, truetype/type1 is not a good way of creating new fonts imo. The whole area needs drastic fixing. Using the stuff on my own, i would just create everything i haven't done yet from scratch. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg