On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote: (cut) >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 I agree, though my GUI programming experience is quite nonexistant :) (or: :()
>> 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'm motivated :) Now only to find time and someone who can tell the bad code from the good. >> 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. :-) Actually, I wrote this to stir some reaction. I don't agree with it myself. I believe there is stuff that can be abstracted about this GUI thing. >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. True, writing anything inside the GUI event loop is wrong (at least when you want low latency). (cut) >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. Lets put this on the table then :) Could you draw a class diagram or something to show us your model ? >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. :-) Well, we could just skip this at first as premature optimization is the root of all evil :) >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'... ;-) :) you have a point. We have here a large based of knowledgeable coders though and a potential userbase. So involving LAD in this seems sensible enough. And hey, I'm interested. I hang around here, for the same reason as I hang around on other lists, to learn. I like to read the code. And I like to make code, even though I need some project that will tickle my mind. Such as this :) regards Vincent
