On Mon Jul 07, 2003 at 04:38:27PM +0200, Sven Luther wrote:
> Notice that you could also use XDirectFB on top of libdirectfb.
Alledgedly gtk can render directly to the framebuffer...
http://developer.gnome.org/doc/API/2.2/gtk/gtk-framebuffer.html
-Erik
--
Erik B. Andersen http:
On Thu, Jun 12, 2003 at 11:27:48PM +0200, Bastian Blank wrote:
> On Thu, Jun 12, 2003 at 10:28:43PM +0200, Sebastian Ley wrote:
> > Against libdirectfb:
> > - vt switching not supported. This is only for the moment, I just
> > recieved word, that it is supported in the cvs version
>
> i ask for
On 13.VI.2003 at 01:19 Sebastian Ley wrote:
> > /usr/X11R6/bin/XFree86: 1500kb
>
> The tiny X Server should be substantially smaller. Unfortunatly I do
> not have any numbers presently:
There is already a package xserver-tinyx-fbdev. Its binary is about
630kb.
Anton Zinoviev
--
To UNSUBSCRIB
On Thu, Jun 12, 2003 at 03:11:44PM -0700, Blars Blarson wrote:
> >Against libdirectfb:
> - x86 only
yeah, one of the main developer only works with powerpc.
> >For X:
> - (mostly?) architecture independant
arch independant as framebuffer devices.
bastian
--
He's dead, Jim.
--
Bastian Blank wrote:
>>Against X:
>>- larger than libdirectfb (is this true?)
[Some numbers which may or may not be applicable.]
IMHO really one would have to compare libdirectfb+gtk+2.0-directfb with
X-Server+X-Client lib+Toolkit.
Cheers
T.
pgp0.pgp
Description: PGP signature
* Bastian Blank wrote:
> > Against libdirectfb:
> > - vt switching not supported. This is only for the moment, I just
> > recieved word, that it is supported in the cvs version
>
> i ask for support a long time ago but had no time to write a patch.
It must be a brand-new feature, available alr
* Blars Blarson wrote:
> >I am still looking for killer arguments for/against one of the two
> >solutions: X server vs. libdirectfb.
>
> >Against libdirectfb:
>
> - x86 only
Oha, is this really true? This would be a knockout criterium wouldn't it?
Sebastian
--
PGP-Key: http://www.mmweg.rwth-
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>I am still looking for killer arguments for/against one of the two
>solutions: X server vs. libdirectfb.
>Against libdirectfb:
- x86 only
>For X:
- (mostly?) architecture independant
>Against X:
>- more difficult to configure (is this
On Thu, Jun 12, 2003 at 10:28:43PM +0200, Sebastian Ley wrote:
> Against libdirectfb:
> - vt switching not supported. This is only for the moment, I just
> recieved word, that it is supported in the cvs version
i ask for support a long time ago but had no time to write a patch.
> - does not (ye
* Thomas Viehmann wrote:
> (But as Sebastian points out, a mini-X-Server might be preferred.)
I am still looking for killer arguments for/against one of the two
solutions: X server vs. libdirectfb.
If I might start:
For libdirectfb:
- small
- easy to setup
- very actively maintained
- fast
- al
My apologies for writing German.
Thomas Viehmann wrote:
> Sebastian Ley wrote:
>
>
>>libdirectfb does not support vt switching, so I searched for a possibility
>>to use a graphical terminal. There are terminal widgets for gtk (vte, zvt)
>>but they require the X target of gtk, so they will only wo
Sebastian Ley wrote:
> libdirectfb does not support vt switching, so I searched for a possibility
> to use a graphical terminal. There are terminal widgets for gtk (vte, zvt)
> but they require the X target of gtk, so they will only work with an X
> server.
1. zvt ist kleiner (ist ja auch erklärt
* Sebastian Ley <[EMAIL PROTECTED]> [030611 00:19]:
> Starting an all new process should not be that
> difficult. Frontend.init would start this process which is then
> responsible for all gtk actions, such as drawing widgets and running
> gtkmain. This process must then be told via an appropriate
* Bernhard R. Link wrote:
> Does this means executing a shell in a gtk-frontend will need
> another udeb than getting a shell in a text-frontend?
I would like to have a terminal widget accessible all the time for the
gtk frontend. E.g. a gtk notebook with three entries: the main dialog
window, a
* Emile van Bergen wrote:
> [many good reasons to avoid threads]
Yes, most probably you are right. You are definitly right in assuming
I have to learn much about Unix system programming ;-)
Starting an all new process should not be that
difficult. Frontend.init would start this process which is
* Sebastian Ley <[EMAIL PROTECTED]> [030610 18:30]:
> > What is the current way to get some program (like a shell) working? Is
> > it still the menu-items responsibility (like it was when I last looked
> > quite some time ago) or was the debconf-protocol extended to allow the
> > frontend to take t
On Tue, Jun 10, 2003 at 11:48:07AM +, Sebastian Ley wrote:
> - Bring up a shell
How about just exiting the gtk framebuffer process, which would drop
the user into a shell?
> - Provide the user with an error log
How about just bringing up a dialog with a big, scrollable, static
text widget wh
Hi,
On Tue, Jun 10, 2003 at 02:49:15PM +, Sebastian Ley wrote:
>
> Bernhard R. Link schrieb:
>
> > What is the current way to get some program (like a shell) working? Is
> > it still the menu-items responsibility (like it was when I last looked
> > quite some time ago) or was the debconf-pr
Bernhard R. Link schrieb:
> What is the current way to get some program (like a shell) working? Is
> it still the menu-items responsibility (like it was when I last looked
> quite some time ago) or was the debconf-protocol extended to allow the
> frontend to take the needed steps or was it even i
* Sebastian Ley <[EMAIL PROTECTED]> [030610 14:19]:
> - Bring up a shell
> - Provide the user with an error log
>
> libdirectfb does not support vt switching, so I searched for a possibility
> to use a graphical terminal. There are terminal widgets for gtk (vte, zvt)
> but they require the X targe
Hello,
the progress for the gtk frontend for cdebconf is stalled because of some
nasty issues. I need some help/suggestions of how to tackle these problems:
Plans were to base the frontend on the framebuffer library libdirectfb.
First efforts were successfull, the basic functions could be implem
21 matches
Mail list logo
