From what I understand, this is how X-Windows works.
Actually, the X window system falls into your "Intercepting Graphics Libraries" bin. The widgets in X are not standardized. Applications usually use a shared library to provide any widgets they need, and the widget sends drawing commands. This lets apps use any widget set they want, but it's relatively high bandwidth.
There are a few GUIs that can send widget commands via a network though. PicoGUI, a project I have been working on for a while, does this. I think Photon (QNX's GUI) can do this as well. There are a lot of advantages- in PicoGUI's implementation, all the widgets are implemented in the server. The network communication is very low bandwidth, and the server has all the information it needs to redraw the screen or scroll without any interaction with the client. This for example would make a remote web browser take some network activity to load a page, but viewing and scrolling the page would be done without any network access. The disadvantage to this system is that it requires completely rethinking the GUI, so there isn't much software available for it yet.
<shameless plug> of course we could always use help with the PicoGUI project:) </shameless plug>
With software like Microwindows, PicoGUI, and Qtopia available, a lot of companies will probably be finding Linux useful on PDAs and smaller embedded devices like Cellphones.
If the goal is to make KDE and Gnome/Gtk themes compatible, I think the right way to make this happen would be to create a new theme system that could be compatible with both systems.
There are several exciting theme systems out there now: both PicoGUI's theme system and Enlightenment's Ebits are theme systems based on a database, capable of storing data for the windowing system, the widget toolkit, and all the applications. If a system like this were implemented in the major GUI toolkits and window managers on the desktop, it should give a way for all applications, toolkits, and window managers to be consistant and completely under the user's control.
PicoGUI's still in need of developers, authors, and artists. We need developers to write PicoGUI applications and help debug/extend/port pgserver. We need authors to write more documentation. We could even use some artists (preferably with some programming knowledge) to make some more themes. If you're interested in helping, join the pgui-devel mailing list or stop by the #picogui IRC channel on irc.openprojects.net.
Well, there is a larger reason behind themes... I explain this some on picogui.org, but the themes in PicoGUI are mostly for defining the look completely separately from the application or the GUI code itself.
As for the synchronization, PIM, etc. to go along with a Linux PDA, that's where there are lots of options. Microwindows, X, Qt/Embedded.. and PicoGUI. To me, the best reason to run Linux on a handheld is to take advantage of cross-platform applications. Especially in a GUI designed for scalability, you should be able to run the same app (with a recompile if it's in a compiled language of course) on a Helio, VR3, Psion, Zaurus, or a laptop.
I wrote this ncurses driver more as a joke, but maybe it would be useful for someone...
PicoGUI is a GUI for embedded systems I've been working on for a while. It's video library is pretty flexible, so much so that it can render to ncurses! This means that PicoGUI apps can run in text mode almost the same as they would run in a graphical mode. The advantages would be a capable GUI that's in active development, and an easy upgrade path to a graphical system. Oh, and it's client-server if that helps. PicoGUI has client libraries for C and Perl, and more languages will be coming.
Some disadvantages though... Currently the keyboard tabbing isn't fully functional, and mouse input probably isn't applicable here, so you might have to do some funky coding to move the focus from field to field, etc. Also, it's a relatively new GUI so it might be missing features here and there.
Admittedly what's available now isn't flexible or transparent, but it is flat. I have a set of Monsoon speakers. Each satellite speaker has a normal cone-type midrange element, but the high-frequency element appears to be a clear piece of plastic printed with circuit traces and surrounded by magnets. In Monsoon's higher-end speakers, the satellite units are 100% flat-panel. Apparently the larger the panels are the lower frequencies they can handle. (makes sense)
I'm not sure whether Monsoon has this stuff patented or whether there just aren't many companies implementing it yet...
They have had machines with living components ever since The Flintstones!
Re:Going to wait for a post-release review
on
Agenda VR3 Review
·
· Score: 2
- The applications should run about as fast as Palms - after all, the Palms have less than a 30 Mhz processor. This is the true test of how fast Linux can be on slower devices.
Though Linux isn't perfectly suited to handhelds, it isn't bad. The reason these things are slow is because they run X. Though it "isn't ready for prime time" yet, I and a couple others have been working on creating a usable PDA system. It will work on nearly any CPU, but the focus is on the 68EZ328. Yep, the same one in Palm computers.
The OS is uClinux, and the user interface is a project I've been working on since last March, PicoGUI. The video drivers still need lots of work, but for the most part uClinux and PicoGUI gives good results even on a little 16mhz CPU. This will allow better battery life no matter what CPU used. Smartdata has been working on a handheld computer using PicoGUI, and I have a piece of hardware or two that will run it.
It seems that Question 9 is where he really felt pinned, because instead of answering the question, the question got redefined somehow...
The distinction here is that POSIX and the other unix standards had to be _added to_ because other features not included in them are necessary. Java (and kerberos IIRC) were blatantly contradicted in a way that added a few extra features but sacrificed the spirit of the original standard, interoperability.
Well, I don't use windows except when absolutely necessary, so I may be wrong. But, from what I've seen the windows 'themes' only let you change things like wallpaper and color schemes. I'm talking about an interface that lets you completely reprogram the look and actions of every single UI element. In many GUI systems I've seen (enlightenment, sawmill, picogui) there is no built-in look, everything is defined by a theme file. Everything is customizable.
that new interface looks like a skin to me... and yet Microsoft still hasn't thought of a skinnable UI
There must be some reason they don't include a customizable UI. I know it's not a hard thing to do. I'm the author of the Open Source GUI PicoGUI and it must have taken about 1000 lines of C to write a fast theme interpreter. Maybe they just don't like giving people choices? Or maybe they want Windows to have a distinct look so they can target their advertising to it and make people upgrade to make their desktop pretty.
HTML documents written in emacs and printed with Netscape
But you're forgetting the original --and probably still the best-- document system that works in Linux. (La)TeX!
LaTeX has a bit of a learning curve, but really no more so than HTML. It makes very professional output and it's un-bloated enough that I can use it just fine on my 486 laptop.
Then came along programs like LyX that built easier UI's on top of TeX...
Looks to me like not only are these principles still applicable, but they're pretty integral parts of everybody's favorite OS:
Convenient remote terminal use
Linux/BSD/UNIX: Check! telnet/ssh and X can make nearly everything network transparent
Windows: Need an extra program like PCanywhere, and even then it's single user. (but isn't m$ fixing this in win2k?)
Continuous operation analogous to power & telephone services
Well, all modern operating systems can do this in theory at least;-)
A wide range of system configurations, changeable without system or
user program reorganization.
Windows: Only three reboots to install a sound card!
Linux: Exchange anything but the kernel without rebooting
Microkernels: 8-D
A highly reliable internal file system
Windows: NTFS seems to be close enough for most people
Linux: ext3 and reiserfs
Support for selective controlled information sharing.
Windows: Network Neighborhood ought to be enough for anybody!
Linux/UNIX/BSD: NFS, Coda, FTP, scp, etc...
Hierarchical structures of information for system administration and
decentralization of user activities.
Not entirely sure what they mean by this...
Support for a wide range of applications.
Check.
Support for multiple programming environments & human interfaces
Windows: IDEs, IDEs and more IDEs.
Linux: Your choice of gcc,emacs,kdevelop,vi, or whatever else you find on freshmeat
The ability to evolve the system with changes in technology and in
user aspirations.
Open source!
But, it's not just about speed. There's a bit of consideration for memory, and quite a lot for screen space. But who says desktop apps have to be slower just because they have a bigger CPU to work with? Just think how much farther desktops could go if you ran PDA software on them:)
Please, we need to stop thinking of the Palmtop as just a PC with a small screen. It is a completely different way of
thinking.
Exactly! Just take a look at the Palm computers vs a M$ "Handheld PC". M$ tries to make it easy for developers to transition, but this just brings along all the memory leaks, bad code, and screen-cluttering UIs that the desktop has.
Now imagine PalmOS with a fully configurable client/server GUI, multitasking, and a Linux kernel. That's what I've been trying to do for the past seven months or so with PicoGUI.
Why should any app (besides the obvious, like image processing and databases) need that much memory? I continue to be appaled by Gates' Law. (and it applies to all software, not just M$)
In today's gigabyte era most people don't remember how much a megabyte used to be able to store. Some of the extra memory usage is for actual functionality, but most of it is just programmers taking shortcuts.
In addition to optimizing my own software, I've always wondered where the memory goes in a program like Linux or XFree86. Does anyone know of a program for profiling memory usage?
Ugh. Do you really want to live in a world where web pages can say they're compatible with a "4.0 browser" or (soon) a "6.0 browser"?
It will be interesting to see what happens when (not if!) other browsers gain popularity. Hopefully by then the web browser authors will actually follow the standards, so people can refer to standards instead of particular programs.
In the 1988 Republican primary in New Hampshire, there was no
panel of computer experts who worked for the people and thoroughly
examined the source codes before and after the voting. It is likely that
a notoriously riggable collection of "Shouptronic" computers
"preordained" voting results to give George Bush his "Hail Mary"
victory in New Hampshire.
What makes you think the entire Slashdot demographic uses open source software?
Maybe it's one of those statements that makes an assumption, both to congratulate the people it applies to and attempt to change the other people's minds, like "Thank you for not smoking!"
Slashdot Mirror
Oh, and here I am assuming that's some VLIW ASM code ..
Actually, the X window system falls into your "Intercepting Graphics Libraries" bin. The widgets in X are not standardized. Applications usually use a shared library to provide any widgets they need, and the widget sends drawing commands. This lets apps use any widget set they want, but it's relatively high bandwidth.
There are a few GUIs that can send widget commands via a network though. PicoGUI, a project I have been working on for a while, does this. I think Photon (QNX's GUI) can do this as well. There are a lot of advantages- in PicoGUI's implementation, all the widgets are implemented in the server. The network communication is very low bandwidth, and the server has all the information it needs to redraw the screen or scroll without any interaction with the client. This for example would make a remote web browser take some network activity to load a page, but viewing and scrolling the page would be done without any network access. The disadvantage to this system is that it requires completely rethinking the GUI, so there isn't much software available for it yet.
<shameless plug> of course we could always use help with the PicoGUI project :) </shameless plug>
With software like Microwindows, PicoGUI, and Qtopia available, a lot of companies will probably be finding Linux useful on PDAs and smaller embedded devices like Cellphones.
There are several exciting theme systems out there now: both PicoGUI's theme system and Enlightenment's Ebits are theme systems based on a database, capable of storing data for the windowing system, the widget toolkit, and all the applications. If a system like this were implemented in the major GUI toolkits and window managers on the desktop, it should give a way for all applications, toolkits, and window managers to be consistant and completely under the user's control.
PicoGUI's still in need of developers, authors, and artists. We need developers to write PicoGUI applications and help debug/extend/port pgserver. We need authors to write more documentation. We could even use some artists (preferably with some programming knowledge) to make some more themes. If you're interested in helping, join the pgui-devel mailing list or stop by the #picogui IRC channel on irc.openprojects.net.
Well, there is a larger reason behind themes... I explain this some on picogui.org, but the themes in PicoGUI are mostly for defining the look completely separately from the application or the GUI code itself.
As for the synchronization, PIM, etc. to go along with a Linux PDA, that's where there are lots of options. Microwindows, X, Qt/Embedded.. and PicoGUI. To me, the best reason to run Linux on a handheld is to take advantage of cross-platform applications. Especially in a GUI designed for scalability, you should be able to run the same app (with a recompile if it's in a compiled language of course) on a Helio, VR3, Psion, Zaurus, or a laptop.
In MacOS 9.1 you can just force quit the registration and rebood. If you try that in MacOS X though it just restarts it.
PicoGUI is a GUI for embedded systems I've been working on for a while. It's video library is pretty flexible, so much so that it can render to ncurses! This means that PicoGUI apps can run in text mode almost the same as they would run in a graphical mode. The advantages would be a capable GUI that's in active development, and an easy upgrade path to a graphical system. Oh, and it's client-server if that helps. PicoGUI has client libraries for C and Perl, and more languages will be coming.
Some disadvantages though... Currently the keyboard tabbing isn't fully functional, and mouse input probably isn't applicable here, so you might have to do some funky coding to move the focus from field to field, etc. Also, it's a relatively new GUI so it might be missing features here and there.
Admittedly what's available now isn't flexible or transparent, but it is flat. I have a set of Monsoon speakers. Each satellite speaker has a normal cone-type midrange element, but the high-frequency element appears to be a clear piece of plastic printed with circuit traces and surrounded by magnets. In Monsoon's higher-end speakers, the satellite units are 100% flat-panel. Apparently the larger the panels are the lower frequencies they can handle. (makes sense)
I'm not sure whether Monsoon has this stuff patented or whether there just aren't many companies implementing it yet...
They have had machines with living components ever since The Flintstones!
Though Linux isn't perfectly suited to handhelds, it isn't bad. The reason these things are slow is because they run X. Though it "isn't ready for prime time" yet, I and a couple others have been working on creating a usable PDA system. It will work on nearly any CPU, but the focus is on the 68EZ328. Yep, the same one in Palm computers.
The OS is uClinux, and the user interface is a project I've been working on since last March, PicoGUI. The video drivers still need lots of work, but for the most part uClinux and PicoGUI gives good results even on a little 16mhz CPU. This will allow better battery life no matter what CPU used. Smartdata has been working on a handheld computer using PicoGUI, and I have a piece of hardware or two that will run it.
The distinction here is that POSIX and the other unix standards had to be _added to_ because other features not included in them are necessary. Java (and kerberos IIRC) were blatantly contradicted in a way that added a few extra features but sacrificed the spirit of the original standard, interoperability.
Well, I don't use windows except when absolutely necessary, so I may be wrong. But, from what I've seen the windows 'themes' only let you change things like wallpaper and color schemes. I'm talking about an interface that lets you completely reprogram the look and actions of every single UI element. In many GUI systems I've seen (enlightenment, sawmill, picogui) there is no built-in look, everything is defined by a theme file. Everything is customizable.
There must be some reason they don't include a customizable UI. I know it's not a hard thing to do. I'm the author of the Open Source GUI PicoGUI and it must have taken about 1000 lines of C to write a fast theme interpreter. Maybe they just don't like giving people choices? Or maybe they want Windows to have a distinct look so they can target their advertising to it and make people upgrade to make their desktop pretty.
Oh well. I like enlightenment :)
Remember when DRAM peaked at 640K?
But you're forgetting the original --and probably still the best-- document system that works in Linux. (La)TeX!
LaTeX has a bit of a learning curve, but really no more so than HTML. It makes very professional output and it's un-bloated enough that I can use it just fine on my 486 laptop.
Then came along programs like LyX that built easier UI's on top of TeX...
Linux/BSD/UNIX: Check! telnet/ssh and X can make nearly everything network transparent
Windows: Need an extra program like PCanywhere, and even then it's single user. (but isn't m$ fixing this in win2k?)
Well, all modern operating systems can do this in theory at least
Windows: Only three reboots to install a sound card!
Linux: Exchange anything but the kernel without rebooting
Microkernels: 8-D
Windows: NTFS seems to be close enough for most people Linux: ext3 and reiserfs
Windows: Network Neighborhood ought to be enough for anybody!
Linux/UNIX/BSD: NFS, Coda, FTP, scp, etc...
Not entirely sure what they mean by this...
Check.
Windows: IDEs, IDEs and more IDEs.
Linux: Your choice of gcc,emacs,kdevelop,vi, or whatever else you find on freshmeat
Open source!
But, it's not just about speed. There's a bit of consideration for memory, and quite a lot for screen space. But who says desktop apps have to be slower just because they have a bigger CPU to work with? Just think how much farther desktops could go if you ran PDA software on them :)
Exactly! Just take a look at the Palm computers vs a M$ "Handheld PC". M$ tries to make it easy for developers to transition, but this just brings along all the memory leaks, bad code, and screen-cluttering UIs that the desktop has.
Now imagine PalmOS with a fully configurable client/server GUI, multitasking, and a Linux kernel. That's what I've been trying to do for the past seven months or so with PicoGUI.
Why should any app (besides the obvious, like image processing and databases) need that much memory? I continue to be appaled by Gates' Law. (and it applies to all software, not just M$) In today's gigabyte era most people don't remember how much a megabyte used to be able to store. Some of the extra memory usage is for actual functionality, but most of it is just programmers taking shortcuts.
In addition to optimizing my own software, I've always wondered where the memory goes in a program like Linux or XFree86. Does anyone know of a program for profiling memory usage?
It will be interesting to see what happens when (not if!) other browsers gain popularity. Hopefully by then the web browser authors will actually follow the standards, so people can refer to standards instead of particular programs.
Here's an excerpt:
Maybe it's one of those statements that makes an assumption, both to congratulate the people it applies to and attempt to change the other people's minds, like "Thank you for not smoking!"