On the other hand, you can't use any C++ features such as namespaces, templates, operator overloading etc.
C is an excellent low level systems programming language. C++ is just about usable for GUI's, but its a lot better than C for that sort of thing. p.s. you don't need to do thread management and locking manually to program BeOS.
BeOS has an excellent one. But wait -- since BeOS supports the BeOS API, why not use that -- it's much better featured than Qt in many regards... John
GTK+ is better than nothing, but not much better
on
GTK+ for BeOS Update
·
· Score: 1
There is a native port going on. I would expect that to be much better than any GTK based port, since GTK applications can't integrate themselves into BeOS properly, let alone use the facilities offered.
For one example, threads -- the GTK framework isn't thread safe, not to mention actually having integrated thread support.
Get the KOffice project and the various GNOME oriented office projects using the same canvas, based on libArt.
Either get ONE single CORBA ORB, or get some way for the various ORBS to share objects efficiently -- i.e. no IIOP.
Make all the core stuff toolkit agnostic. In KDE's case -- get Qt into separable parts -- such that using the UI doesn't mnandate using the rest of the framework, and using the STL where appropriate rather than the Qt built in classes.
The other (IMHO better) approach, taken by NeWS, was to allow the server to be dynamically extended with a (Postscript) VM (like the way that JAVA classes can be dynamically loaded).
The window management was customisable, but ran inside then display -- rather than over a network connection
My take on this would be to represent most GUI controls abstractly, let the display handle drawing them, and then allow for high performance streaming through the display system.
John
Take one step forward -- and drop X
on
Is X The Future?
·
· Score: 1
How exactly does one extend X with features such as
Elegant minimalism
The Archimedes could put the entire basic windowing system into less than 1MB of RAM. Why not do that for the drawing infrastructure, and then bolt on an extra 100Kb of RAM requirements for the networking -- and then dedecate another few Mb of RAM for image cacheing, texture cacheing, VM workspace etc. -- X requires too much memory on both the client and server end (whichever they are) -- the only difference with X these days is that the requirements are tolerable.
A single unified font subsystem that understands font metrics correctly...
In short -- extending an existing architecture CANNOT make it any leaner John
Re:Want to 'replace' X? Go nutz
on
Is X The Future?
·
· Score: 1
You've bumpoed into the 'Rolls Royce over night' problem -- one person alone can't code that much... John
Simple character outlines are only part of the problem.
You need to be able to handle kerning of letters, substituting ligatures for 'fi', 'ffi', etc. and do all this in a language neutral way (so that the system will work for Arabic and Hebrew).
There was an interesting piece by somebody on the merits of OpenType vs QuickdrawGX on things like this...
At a guess, then you mean ~1979 (based on MetaFont being MF78), and the publisher was probably Addison-Wesley (I think that they did the TeXbook and a few other of Knuth's books).
What I was asking about was concrete points to contest the patent on -- "A bit is from this bit of software, a bit from that, and a few thingies here and there, and sorta this, and that, and it is a nice day today" doesn't really stand up in court
First -- there's the pixel size vs screen size problem (the hinting should adjust to the dpi of your monitor -- giving two or more axes to vary the font over...).
Second -- its easier to generate multiple separately hinted type 1 fonts from the TTF font (assuming that you can understand the hinting info)
Neither of which are really RISC anyhow -- if you want RISC, take a look at ARM (the Alpha dies and the PPC dies are way too complicated to pass as RISC...) John
For one thing, the body can handle iron intake far more easily than it can nickel. It's easy to get a nickel allergy from ingesting too much (and the body takes a very long time to get rid of it), whereas an excessive iron intake will only hammer your heart to bits (if I remember correctly). John
A good part of the mindshare of M$ software is due to people having illegitamate copies. Rent-a-soft gets rid of that -- probably causing the said people to go the way of the demo scene (into either nothingness, or the 'Way of the Penguin'(tm):-)) John
Besides -- what's wrong with a little competition between GPL'd projects??
I also read somewhere that someone is concerned about license compatibility with FreeBSD. A better solution than dual licensing would be for the FreeBSD and Linux kernel hackers to get together and sort out a decent cross platform 'Installable FileSystem' API so that the same code can be shared across OS's (And not necessarily linked to the kernel in order to work)
The good bits of NeWS seems to be one of the design aims of the Berlin project. However, so far as doing it the right way is concerned, consider that they used 'Object Orientated Postscript'!!?? John
If you recall, the first FSF Free Software award went to Larry Wall for his development of PERL and other free software. Linus, RMS and similar people were adjudged ineligible because they had received enough for their contributions already. John
By not spending as much space on bass sounds, you get more bandwidth for other areas of the frequency spectrum.
John
As others will most doubt suggest -- why not just stuff it atop a (possibly cut down) Linux kernel?
John
This comment should be archived (if that is the right word) and sent to http://www.gnu.org for posting there -- they like this sort of thing.
John
On the other hand, you can't use any C++ features such as namespaces, templates, operator overloading etc.
C is an excellent low level systems programming language. C++ is just about usable for GUI's, but its a lot better than C for that sort of thing. p.s. you don't need to do thread management and locking manually to program BeOS.
John
BeOS has an excellent one. But wait -- since BeOS supports the BeOS API, why not use that -- it's much better featured than Qt in many regards...
John
There is a native port going on. I would expect that to be much better than any GTK based port, since GTK applications can't integrate themselves into BeOS properly, let alone use the facilities offered.
For one example, threads -- the GTK framework isn't thread safe, not to mention actually having integrated thread support.
John
John
The other (IMHO better) approach, taken by NeWS, was to allow the server to be dynamically extended with a (Postscript) VM (like the way that JAVA classes can be dynamically loaded).
The window management was customisable, but ran inside then display -- rather than over a network connection
My take on this would be to represent most GUI controls abstractly, let the display handle drawing them, and then allow for high performance streaming through the display system.
John
How exactly does one extend X with features such as
- Elegant minimalism
- A single unified font subsystem that understands font metrics correctly...
In short -- extending an existing architecture CANNOT make it any leanerJohn
You've bumpoed into the 'Rolls Royce over night' problem -- one person alone can't code that much...
John
Simple character outlines are only part of the problem.
You need to be able to handle kerning of letters, substituting ligatures for 'fi', 'ffi', etc. and do all this in a language neutral way (so that the system will work for Arabic and Hebrew).
There was an interesting piece by somebody on the merits of OpenType vs QuickdrawGX on things like this...
John
At a guess, then you mean ~1979 (based on MetaFont being MF78), and the publisher was probably Addison-Wesley (I think that they did the TeXbook and a few other of Knuth's books).
What I was asking about was concrete points to contest the patent on -- "A bit is from this bit of software, a bit from that, and a few thingies here and there, and sorta this, and that, and it is a nice day today" doesn't really stand up in court
John
John
Could you elaborate?
John
Neither of which are really RISC anyhow -- if you want RISC, take a look at ARM (the Alpha dies and the PPC dies are way too complicated to pass as RISC...)
John
For one thing, the body can handle iron intake far more easily than it can nickel. It's easy to get a nickel allergy from ingesting too much (and the body takes a very long time to get rid of it), whereas an excessive iron intake will only hammer your heart to bits (if I remember correctly).
John
A good part of the mindshare of M$ software is due to people having illegitamate copies. Rent-a-soft gets rid of that -- probably causing the said people to go the way of the demo scene (into either nothingness, or the 'Way of the Penguin'(tm) :-))
John
IBM: We took the intel out of Wintel
Linux: We took the Win out of Wintel
IMB Lawyers: Hang on -- who owns the in in Wintel??
John
Besides -- what's wrong with a little competition between GPL'd projects??
I also read somewhere that someone is concerned about license compatibility with FreeBSD. A better solution than dual licensing would be for the FreeBSD and Linux kernel hackers to get together and sort out a decent cross platform 'Installable FileSystem' API so that the same code can be shared across OS's (And not necessarily linked to the kernel in order to work)
John
It's not the end of the world after a
John
Wherever there isnt clouds, and about 3.5 hours ago. (It also went near Paris I think)
John
Plain and simple.
I cycled down to teignmouth, and got to watch the lights go out (and street lights on) for about 15 seconds.
There was one brief hole in the clouds where we could see a glowing banana, but a totality, just clouds.
That said, the sight of the shadow cast on the clouds rushing in is still a little spectacular.
John
The good bits of NeWS seems to be one of the design aims of the Berlin project. However, so far as doing it the right way is concerned, consider that they used 'Object Orientated Postscript'!!??
John
If you recall, the first FSF Free Software award went to Larry Wall for his development of PERL and other free software. Linus, RMS and similar people were adjudged ineligible because they had received enough for their contributions already.
John
Sorry. I've been reading/watching/believing too much Red Dwarf...
John