X11 fullscreen

[Clemens Eisserer]

Man, don't have a job? Is your time worth anything to you?
And by the way ... I've never read so many *strange* arguments in one
discussion.

(using shm ximage for normal drawing is bullshit)

- Clemens

2010/1/30 Russell Shaw <rjshaw at netspace.net.au>:
> 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.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>