Daniel Stone wrote: > On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: >> Daniel Stone wrote: >>> On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: >>>> One can make their own widget libraries based on Xlib, then write apps >>>> using the libraries. Nothing hard about that ("hard" is relative;) >>> It's not 'hard' in the sense of being groundbreaking CS research, no, >>> but it would take an immense amount of time to get non-Western scripts >>> (including bidi), accessibility, copy & paste, full ICCCM compliance >>> including doing the right thing with EWMH, input (including input >>> methods), selections, etc working properly and correctly. Oh, and your >>> app doesn't look anything like any other app now. >> All that is done to a degree. Theming engine allows apps to look and act >> like any other system. Once you architect the full depth of the problem >> with minimal things that work at every stage, you can add more parallelable >> features whenever required. > > OK, sounds like it should be pretty easy for you to knock up?
It works, but needs refining. I shouldn't use "Theming engine". That's a programmer wankword for some kind of state machine. I do theming with a simple plugin api. >>> Ooh yeah, and your app has no concept of double-clicking. You could >>> reimplement it and have it be completely different to the rest of the >>> system (different maximum time between clicks, different maximum >>> distance between click positions, etc) if you like. All the little >>> stuff like this really does add up. >> Would you like a ctrl-shift+triple-middle-click popup menu? I only make >> useability different if i know it's the right thing to do. > > No, I just want double-clicking to work. It works. >>> Please, please, stop telling people to write their own toolkits; it's >>> quite possibly the worst advice I've ever heard on this list, to be >>> honest. >> I didn't say it would be unconditionally easy, but to solve an >> immediate engineering problem of drawing to a full screen and having >> a menu, Xlib + OpenGL + Glut is fairly easy. > > I assume their requirements will eventually run deeper than 'full > screen, one menu'. > >> Progressing on from that and creating new widgets is useful innovation >> that can solve many more problems. > > No, it's not useful innovation at all. Why? Try scrolling a list with 1e6 elements with ease. >> All the answers to do anything you want is available on the web, email >> lists, and in books. It's definitely not quick and easy to do the whole >> thing. > > No, hence why someone asking how to do something eye-wateringly simple, > we should recommend they use existing toolkits. All the answers exist, but any low-grade resource needs searching and refining. That's why toolkits exist. All the answers in one spot. Sometimes they're not suitable answers. >> I wouldn't be recommending any of this if i found existing widget toolkits >> easy to make new non-trivial widgets that run well. I've battled widget >> toolkits since Windows95. The code for various existing X toolkits is >> inpenetrable, and made overly complex for porting to non-X systems >> that i don't require. Having thought through many problems, these >> codebases can be more comprehensible, but what's the use when one >> has had to figure out how to make a toolkit in order to figure out >> how to fix one? > > He doesn't want non-trivial widgets, he wants full-screen and a menu, > remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to "just use a toolkit" when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg