X11 fullscreen

[Russell Shaw]

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++.