Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion.
(using shm ximage for normal drawing is bullshit) - Clemens 2010/1/30 Russell Shaw <rjs...@netspace.net.au>: > 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 > _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg