This is a little project I did, specifically for controlling a large number of LEDs for ambient information (CPU load, music visualization...). It connects to the serial port, and can control up to 72 LEDs with variable brightness.
I was planning on making kits for this available if there's interest, but that's on hold until I finish a new design (thousands of LEDs, true color, USB).
There is hardware info, source code, and photos at the project web page.
XF86 does have a platform-agnostic module loader that (as far as I know) is used for drivers as well - why not implement that code and load the drivers the same way X does?
Eventually I'd like to write something like this as a library that can be used by multiple projects. It's not nearly as easy as you make it sound though, mainly because the drivers require a lot of internal structures and functions from XFree86 itself.
What you're suggesting would be like making a library for running qt apps on gtk, or Motif apps in Swing. It might be possible, but it will definitely be hard and a lot will be lost in the translation. This will be particularly hard in PicoGUI because of how it handles widget layout.
The web site could use an overhaul, and a better screenshot categorization system. (maybe show the latest each from a couple categories on the front page?) But, we haven't had any volunteers to do this, and the web site isn't a high priority for me.
t's ridiculous because it implies an obligation for the X developers that doesn't exist. If you want the code, it's available (for most X implementations.) But there's no reason they should have to put extra work in to support other GUIs if they don't want to.
I said that it was my opinion. As far as I can tell from looking at the X source code, the architecture is close to what would have been required to implement the drivers separately from the rest of X, but they failed to make some design decisions that would allow this.
But maybe I'm just bitter that sometime in the future I'll be digging through the bowels of XAA to patch together an interface for dlopen()'ing X video drivers, when they could have just designed it a bit better:)
X's architecture is completely different than PicoGUI. PicoGUI's architecture is based on widgets, and a tree that organizes and lays out the widget's elements. In PicoGUI, everything is a widget, including things like an app's main window, and the background. X is based on windows, using expose events to coordinate redrawing. There would be no point to combining the two, if it was even possible.
What you probably want is just a way to run both picogui and X apps at the same time. Just pick one as the main GUI and run the other's apps through an additional layer. You can already run PicoGUI apps under X.
I just get tired of all the people saying "we need to get rid of Xwindows because XFree86 is too hard to configure" or "Xwindows is so slow, just look at how long it takes to change directories in Nautilus" or something like that.
Yeah, I do feel sorry for X because of how many completely unknowledgeable people bash it. Sadly, this has hardened the developers against genuine and informed criticisms.
The PicoGUI API is small, but that's because most functions can be used and combined in many ways. The design is a little like how UNIX allows you to use a small number of flexible command line utilities to do almost anything rather than having a specialized program for everything they think you need. This makes the API both easier to learn and easier to write new client libraries for. (Each language picogui supports uses a native client library, not a wrapper around a C library)
Also, you're right that PicoGUI isn't designed to replace X. It does do the same job as X and/or a widget toolkit in many instances though. After PicoGUI has more apps and more drivers, it could be used on desktops instead of X. For now, it's mainly focusing on embedded systems.
I do hope that someday a good number of embedded systems will run on PicoGUI and a good number of desktops will be at least PicoGUI-compatible (via a rootless driver like the one we currently have for X11) that you will be able to run apps on any of these platforms transparently. Some of the things you'd be able to do include:
Write an installer or configuration tool that could be run in ncurses, on the framebuffer device, or in X, without changing any code in the installer
Run the PIM software from a PDA over a USB or wireless network, displaying itself rootless under X or Win32. The PIM would have a look and feel native to the desktop, but would be running on the PDA.
PicoGUI and Fresco are both network-transparent GUIs, so the argument that people just want to replace X with something that's not network transparent doesn't hold.
You say X is so low level it doesn't make sense to criticize it, but I think X has actually taken the worst of both the high-level and low-level worlds. X is low-level enough that you don't get any application consistency and you still end up sending individual graphics primitives over the wire. But, it's still high-level enough that it makes it hard to do some types of graphics operations. Yes, I know about RENDER. Putting aside all arguments on X's architecture, that still doesn't make it any easier to do things like blurring, multiplying two bitmaps, or rotation.
Berlin/Fresco and PicoGUI actually have a lot of similarities in their design. PicoGUI's speed is more of a side effect of having a good design rather than a primary motivation.
We can, and probably will, run Qt and GTK apps on top of PicoGUI through some sort of emulation layer at the framebuffer level. But that would only be an emulation layer. It would give you none of the benefits that PicoGUI is designed to provide.
It is almost certainly not worth it to try porting Gtk, Qt, or anything else at the widget level, as PicoGUI's widgets are designed differently than most GUIs' widgets.
Unfortunately this is the same attitude that the X developers seem to have. As it is, X is the only project that has usable drivers for desktop video cards. (I know about DirectFB, but it's level of card support is nowhere near X's)
IMHO this gives X a responsibility to write the drivers in a way that other GUIs can use them, but as it is, the developers just don't care.
What you're talking about isn't picogui itself, it's just the PicoAqua theme. If you don't like it, read the docs on picogui's theme language and fix it.
PicoGUI's architecture is nothing like OS X.
Since I'm the creator of PicoGUI, I thought I should elaborate a bit
PicoGUI is designed with a lot of goals in mind, but for me the largest goal is scalability. I'd like to be able to run one app, with minimal code changes if any, on a PDA, desktop, cell phone, phone, toaster:)
There are also a lot of architectural decisions PicoGUI makes that lends itself to easy and consistent solutions for common problems other GUIs have to deal with. PicoGUI has a theme system that manages everything from drawing the widgets to laying out entire application UIs, all with surprisingly little code. It has a video driver architecture that handles raw framebuffers, accelerator cards, and even esoteric devices like ncurses rendering or text-mode LCDs. PicoGUI's widgets are designed with more of a UNIX philosophy- small but powerful widgets that can be combined in nifty ways.
I didn't originally intend PicoGUI to be a primary GUI for desktop computers. I started it for a PDA project I was working on. But, given how its architecture lends itself well to scalability, it could soon be a good GUI for desktops. Recently PicoGUI gained the ability to run in a "rootless" mode where it acts more like a widget toolkit than a complete GUI. Once PicoGUI has drivers for DirectFB or some other acceleration backend, and a way to run X apps in an emulation mode, it should be able to completely replace X.
In my opinion, the biggest stumbling block to replacing X on the desktop is having accelerated video drivers that work on other GUIs. I've talked to X developers about separating the video drivers into a layer that can be used directly by projects like PicoGUI, GGI, and Fresco, but they had no interest. From what I've seen of X developers, they want all the world to run in X.
72 LEDs mounted behind translucent plastic, all with computer controlled brightness. There's an XMMS plugin:)
Re:3500 year old technology
on
Awari Solved
·
· Score: 2
Hrm.. slashdot has done bad things to this code. Remove the " " above the # shape, and replace the "i f (e<0)" in the bottom-right with "if (e<0)"
Re:3500 year old technology
on
Awari Solved
·
· Score: 5, Funny
/* Obfuscated tic-tac-toe in C * Copyright 2002 Micah Dowty <micahjd@users.sourceforge.net> * * Enter your moves using this key: * 0|1|2 * -+-+- * 3|4|5 * -+-+- * 6|7|8 */
#include <stdio.h> #define E " | | \n" #define F "-+-+-\n" #define L(x)b[x/3*12+x%3*2] #define P(x)e=x<0?e:x; #define R(a,b,c,p)if(L(x)==a&&L(y)==b&&L(z)==c)p=z;   ; int x,y,z, e,i,v,o,h, X=88,S=32, O=48,r[]={ 0,1,2,3,4, 5,6,7,8,0, 3,6,1,4,7, 2,5,8,0,4, 8,2,4,6};char b[]=E F E F E;void a(int x,int y,int z){if(L(z)==S)e=z;R(O,O,S, v)R(X,X,S,o)R(X,S,S,h)}void l(){for(i= 0;i<24;){x=r[i++];y=r[i++];z=r[i++];a( x,y,z);a(y,x,z);a(z, y,x);a(x,z,y);a(y,z, x);a(z,x,y );if(L(r[x ])!=S&&L(r [x])==L(r[ y])&&L(r[y])==L(r[z]))exit(printf("%s" "You Lose\n",b));}}int main(){puts(b); for(;;){i=getc(stdin)-O;if(i>(e=v=o=h= -1)&&i<9&&L(i)==S){L(i)=X;l();i f (e<0) exit(1-1&& printf("%" "sCat's G" "ame\n",b) );P(h)P(o) P(v)L(e)=O ;l();puts( b);;;;;}}}
You're forgetting SDL... SDL along with OpenGL (which it interates with very nicely) provide pretty much the same scope of functionality as DirectX.
Plus, by using SDL your app is portable to Windows, BeOS, MacOS, etc. (in theory)
I've done some DirectX programming a while ago and a good bit of SDL programming recently. The SDL and OpenGL APIs are much cleaner and easier to use than DirectX.
(announcer) Yes, it's Happy Fun Ball, the toy sensation that's sweeping the nation. Only 14.95 at participating stores!
Get one Today
(background voice) Warning: Pregnant women, the elderly, and children should avoid prolonged exposure to Happy Fun Ball.
Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds.
Happy Fun Ball contains a liquid core, which if exposed due to rupture should not be touched, inhaled, or looked at.
Do not use Happy Fun Ball on concrete.
Discontinue use of Happy Fun Ball if any of the following occurs:
# Itching
# Vertigo
# Dizziness
# Tingling in extremities
# Loss of balance or coordination
# Slurred speech
# Temporary blindness
# Profuse Sweating
or
# Heart palpitations
If Happy Fun Ball begins to smoke, get away immediately. Seek shelter and cover head.
Happy Fun Ball may stick to certain types of skin.
When not in use, Happy Fun Ball should be returned to its special container and kept under refrigeration.
Failure to do so relieves the makers of Happy Fun Ball, Wacky Products Incorporated, and its parent company, Global Chemical Unlimited, of any and all liability.
Ingredients of Happy Fun Ball include an unknown glowing substance which fell to Earth, presumably from outer space.
Happy Fun Ball has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq.
Do not taunt Happy Fun Ball.
Happy Fun Ball comes with a lifetime guarantee.
(announcer) Happy Fun Ball! Accept no substitutes!
Good point, if you get a Zaurus, you're not limited to Qt. The Zaurus has a normal linux framebuffer, so there are several alternativeGUIs you could run.
Anyone else notice that http://sourceforge.net is blocked? I've had Chinese developers asking me to mirror documentation on my sourceforge-hosted site because it was blocked.
Slashdot Mirror
I was planning on making kits for this available if there's interest, but that's on hold until I finish a new design (thousands of LEDs, true color, USB).
There is hardware info, source code, and photos at the project web page.
Eventually I'd like to write something like this as a library that can be used by multiple projects. It's not nearly as easy as you make it sound though, mainly because the drivers require a lot of internal structures and functions from XFree86 itself.
I said that it was my opinion. As far as I can tell from looking at the X source code, the architecture is close to what would have been required to implement the drivers separately from the rest of X, but they failed to make some design decisions that would allow this.
But maybe I'm just bitter that sometime in the future I'll be digging through the bowels of XAA to patch together an interface for dlopen()'ing X video drivers, when they could have just designed it a bit better :)
What you probably want is just a way to run both picogui and X apps at the same time. Just pick one as the main GUI and run the other's apps through an additional layer. You can already run PicoGUI apps under X.
Yeah, I do feel sorry for X because of how many completely unknowledgeable people bash it. Sadly, this has hardened the developers against genuine and informed criticisms.
The PicoGUI API is small, but that's because most functions can be used and combined in many ways. The design is a little like how UNIX allows you to use a small number of flexible command line utilities to do almost anything rather than having a specialized program for everything they think you need. This makes the API both easier to learn and easier to write new client libraries for. (Each language picogui supports uses a native client library, not a wrapper around a C library)
Also, you're right that PicoGUI isn't designed to replace X. It does do the same job as X and/or a widget toolkit in many instances though. After PicoGUI has more apps and more drivers, it could be used on desktops instead of X. For now, it's mainly focusing on embedded systems.
I do hope that someday a good number of embedded systems will run on PicoGUI and a good number of desktops will be at least PicoGUI-compatible (via a rootless driver like the one we currently have for X11) that you will be able to run apps on any of these platforms transparently. Some of the things you'd be able to do include:
Also, the open source project the images for PicoAqua were taken from (a Gtk theme) seems to be just fine.
You say X is so low level it doesn't make sense to criticize it, but I think X has actually taken the worst of both the high-level and low-level worlds. X is low-level enough that you don't get any application consistency and you still end up sending individual graphics primitives over the wire. But, it's still high-level enough that it makes it hard to do some types of graphics operations. Yes, I know about RENDER. Putting aside all arguments on X's architecture, that still doesn't make it any easier to do things like blurring, multiplying two bitmaps, or rotation.
It is almost certainly not worth it to try porting Gtk, Qt, or anything else at the widget level, as PicoGUI's widgets are designed differently than most GUIs' widgets.
IMHO this gives X a responsibility to write the drivers in a way that other GUIs can use them, but as it is, the developers just don't care.
PicoGUI is designed with a lot of goals in mind, but for me the largest goal is scalability. I'd like to be able to run one app, with minimal code changes if any, on a PDA, desktop, cell phone, phone, toaster :)
There are also a lot of architectural decisions PicoGUI makes that lends itself to easy and consistent solutions for common problems other GUIs have to deal with. PicoGUI has a theme system that manages everything from drawing the widgets to laying out entire application UIs, all with surprisingly little code. It has a video driver architecture that handles raw framebuffers, accelerator cards, and even esoteric devices like ncurses rendering or text-mode LCDs. PicoGUI's widgets are designed with more of a UNIX philosophy- small but powerful widgets that can be combined in nifty ways.
I didn't originally intend PicoGUI to be a primary GUI for desktop computers. I started it for a PDA project I was working on. But, given how its architecture lends itself well to scalability, it could soon be a good GUI for desktops. Recently PicoGUI gained the ability to run in a "rootless" mode where it acts more like a widget toolkit than a complete GUI. Once PicoGUI has drivers for DirectFB or some other acceleration backend, and a way to run X apps in an emulation mode, it should be able to completely replace X.
In my opinion, the biggest stumbling block to replacing X on the desktop is having accelerated video drivers that work on other GUIs. I've talked to X developers about separating the video drivers into a layer that can be used directly by projects like PicoGUI, GGI, and Fresco, but they had no interest. From what I've seen of X developers, they want all the world to run in X.
My case mod
72 LEDs mounted behind translucent plastic, all with computer controlled brightness. There's an XMMS plugin :)
/* Obfuscated tic-tac-toe in C
p ; ,x,z);a(z, ,y);a(y,z,
;l();puts( b);;;;;}}}
* Copyright 2002 Micah Dowty <micahjd@users.sourceforge.net>
*
* Enter your moves using this key:
* 0|1|2
* -+-+-
* 3|4|5
* -+-+-
* 6|7|8
*/
#include <stdio.h>
#define E " | | \n"
#define F "-+-+-\n"
#define L(x)b[x/3*12+x%3*2]
#define P(x)e=x<0?e:x;
#define R(a,b,c,p)if(L(x)==a&&L(y)==b&&L(z)==c)p=z;
&nbs
int x,y,z, e,i,v,o,h,
X=88,S=32, O=48,r[]={
0,1,2,3,4, 5,6,7,8,0,
3,6,1,4,7, 2,5,8,0,4,
8,2,4,6};char b[]=E F E F E;void a(int
x,int y,int z){if(L(z)==S)e=z;R(O,O,S,
v)R(X,X,S,o)R(X,S,S,h)}void l(){for(i=
0;i<24;){x=r[i++];y=r[i++];z=r[i++];a(
x,y,z);a(y
y,x);a(x,z
x);a(z,x,y );if(L(r[x
])!=S&&L(r [x])==L(r[
y])&&L(r[y])==L(r[z]))exit(printf("%s"
"You Lose\n",b));}}int main(){puts(b);
for(;;){i=getc(stdin)-O;if(i>(e=v=o=h=
-1)&&i<9&&L(i)==S){L(i)=X;l();i f (e<0)
exit(1-1&& printf("%"
"sCat's G" "ame\n",b)
);P(h)P(o) P(v)L(e)=O
Plus, by using SDL your app is portable to Windows, BeOS, MacOS, etc. (in theory)
I've done some DirectX programming a while ago and a good bit of SDL programming recently. The SDL and OpenGL APIs are much cleaner and easier to use than DirectX.
(kids) It's Happy! It's Fun! It's Happy Fun Ball!
(announcer) Yes, it's Happy Fun Ball, the toy sensation that's sweeping the nation. Only 14.95 at participating stores!
Get one Today
(background voice) Warning: Pregnant women, the elderly, and children should avoid prolonged exposure to Happy Fun Ball.
Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds.
Happy Fun Ball contains a liquid core, which if exposed due to rupture should not be touched, inhaled, or looked at.
Do not use Happy Fun Ball on concrete.
Discontinue use of Happy Fun Ball if any of the following occurs:
# Itching
# Vertigo
# Dizziness
# Tingling in extremities
# Loss of balance or coordination
# Slurred speech
# Temporary blindness
# Profuse Sweating
or
# Heart palpitations
If Happy Fun Ball begins to smoke, get away immediately. Seek shelter and cover head.
Happy Fun Ball may stick to certain types of skin.
When not in use, Happy Fun Ball should be returned to its special container and kept under refrigeration.
Failure to do so relieves the makers of Happy Fun Ball, Wacky Products Incorporated, and its parent company, Global Chemical Unlimited, of any and all liability.
Ingredients of Happy Fun Ball include an unknown glowing substance which fell to Earth, presumably from outer space.
Happy Fun Ball has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq.
Do not taunt Happy Fun Ball.
Happy Fun Ball comes with a lifetime guarantee.
(announcer) Happy Fun Ball! Accept no substitutes!