X11 fullscreen

[Russell Shaw]

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.