Re: PicoGUI1 and 2

On Thu, Apr 17, 2003 at 10:57:54AM +0200, Peter Graf wrote:
> Micah wrote:
> 
> >> Just the (hopefully unnecessary) plea to keep in mind that a major 
> >strength
> >> of pg is it's potential good portability to non-Linux embedded targets. 
> >Some
> >> of those targets only offer a C-Compiler and limited POSIX compatibility.
> >> Don't leave this market sector to NanoX!
> >
> >Definitely. I'd love to get PicoGUI working on eCos, OSKit, NetBSD, L4... 
> >the
> >main problem currently is that the build system is quite baroque.
> 
> Later Micah wrote:
> 
> >I do expect we'll be able to reuse a lot of driver code from pg1.
> >glib... that depends. If we end up writing most of it in c++, we could
> >use uSTL. (A more code-space-efficient implementation of the STL)
> >If we're using C, we'd probably want something less huge than glib.
> 
> Once you start requiring a C++ cross-compiler, PicoGUI will immediately
> become uninteresting for many embedded targets. I was very interested
> in porting PicoGUI on two embedded platforms, but watching the direction
> of the ideas and the discussions for a while.

Remember that pg2 won't be ready for use for at least a year. Will it be
possible to get a C++ compiler working on all embedded systems that
might want to use picogui then?

> 
> (I did not want to use a separate compositing engine in addition to
> PicoGUI to implement a certain feature which is required for me. This
> feature will likely be part of PicoGUI 2 rather that PicoGIU 1. It is
> also implemented in NanoX.)

There's no way overlapping windows can be properly implemented in pg1
without rewriting the rendering engine.

> 
> But now that I see target-specific tools beyond a C cross-compiler thrown
> into discussion again and again, my feeling of uncertainty grows. I'm
> at the verge of giving up any interest in PicoGUI 2 for my "embedded"
> targets.

The only tool being discussed here is the compiler. Also note that even
if we use C++, we won't use the C++ standard library. Using C++ in this
way, we get the benefit of exceptions and classes with very little
difference in binary size.

So the only reason this would be harmful is if the embedded system in
question doesn't have a C++ compiler. Almost all the systems I've seen
use gcc, so it should be easy to use g++ on them.

> 
> I don't want to be too pessimistic, but just from the standpoint of a long
> time embedded hardware and software developer who has ported quite a lot of
> software to real embedded targets, I feel uncertain if PicoGUI 2 will
> become the ideal solution (which it could be!!). Actual tool and OS
> functionality in the embedded world is often very restricted, more than
> many announcements suggest. Don't underestimate the number of targets
> which only have a C crosscompiler, limited POSIX library support,
> and selfmade or incompletely ported operating systems.

Aside for the compiler (which is still very much up for debate) that's
all pg1 or pg2 should need. I'm hoping that pg2's architecture is better
for embedded, since it will have even more compile-time configurability
than pg1, and an architecture lending itself to easier porting to
different OSes.

> 
> What seems to remain for "embedded" folks like me, is NanoX :-((

If all you need is a way to draw primitives into overlapping windows,
use NanoX. If you need a complete GUI with a cool design, use PicoGUI :)

--Micah

-- 
"For every problem, there is a solution that is simple, elegant, and wrong."
           -- H.L. Mencken


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf