On Wednesday 12 June 2002 11.17, Vincent Touquet wrote: > I have never done any GUI programming before. > > Writing these comprehensive widgets > with cool knobs, smooth slides, > graphical equalizers etc. seems > difficult though.
GUI programming is not really difficult IMHO, but the difference between the first estimation of development time and the time it actually takes to hack is probably the bigger than for any other kind of programming. It looks like it would be a fast and easy hack, as everything's so visually "obvious" and intuitive, but that's just an illusion... > I think an effort should be undertaken to > get a group of people to write these damn things :) Yes, but how about motivation, and getting the right people to do their best? > I fear model-view-controller separation > doesn't apply here, as we are entirely > in the view realm. I don't agree there. The major difference is probably that there's much more "logic" inside the GUI part - not that there all of a sudden is a good reason to mix things that don't belong together. In fact, the separation between engine and UI is an absolute *requirement* for real time audio/MIDI applications, as you simply cannot make them work reliably if there are too many places where the UI may interfere with the timing of the engine. "Monolith GUI + modular engine" is a basic design idea that makes sense here, IMHO. (A modular/plugin based GUI might work as well, but then we're back in this "different toolkits won't mix" mess again...) > So we are stuck basicly to implement > these things for *all* the major toolkits, > GTK, QT, etc. Yes, but perhaps we can do something about that, as a part of creating a VSTGUI style toolkit, more suitable for the kind of highly interactive GUIs we need. The design I have in mind could be implemented inside any toolkit that provides access to the underlying "drawing toolkit" - or directly on top of the rendering target or API (SDL, X, fbdev, svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that matter. The only truly required feature is a way of rendering rectangular images into windows. All higher level stuff is just to allow certain targets to use hardware acceleration for specific features - ie performance hacks. (That is, stuff that optimization freaks can play around with after the toolkit is implemented and working. :-) If one can get away with designing such a toolkit that's actually usable, any code that uses it will happily interact with any toolkit, and it could also serve as a highly portable stand-alone toolkit. [...] Either way, the major issue here is not *how* we should go about getting proper GUIs for more and larger Linux music application, but how we should get anyone to do any serious GUI hacking *at all*. There are a few exceptions, but the fact remains: The LAD community consists mostly of *audio* hackers. (Makes sense, sorta'... ;-) //David .- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---------------------------> http://www.linuxdj.com/maia/ -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -'
