On Sun, 19 Jan 2003, Martin Albert wrote:
> Q: S'2.1 with ggi-target-x needs options -nobuf:-nocursor. How to
> arrange for that from in the program? I was starting to parse the
> environment for GGI_DISPLAY to evtly extend it, but that cannot quite
> be the suggested method?
GGI can add optio
On Tuesday 17 December 2002 23:44, Martin Albert wrote:
> Hanging out on dubious hacker websites, like ggi-project.org and
> such, following links to stuff that interests me, i often end up
> downloading from stacken.kth.se, strange favicon, strange mackan@ ...
> :-)
>
> Eg., svgalib4libggi, ggi dr
On Fri, 20 Dec 2002, Rodolphe Ortalo wrote:
> I really think it is a very important point to get _applications_ using a
> GUI. I'd even say that it should be a requirement.
> But I understand that you may also have a lot of work to do to get the
> GUI essential elements running in Fresco... :-)
On Thu, 19 Dec 2002, Stefan Seefeld wrote:
> I don't think an interactive GUI builder is an absolute must to get a
> GUI,
[...]
I really think it is a very important point to get _applications_ using a
GUI. I'd even say that it should be a requirement.
But I understand that you may also have a
Rodolphe Ortalo wrote:
>>> Of course, there is a bootstrap problem here: which GUI to use for
the UI
>>>generator... :-)) But I really believe the latter should be able to
>>>generate itself before claiming v.1!
>>
>>:-). Right. Well usual solution. Use an existing compile to compile,
>>then comp
On Thu, 19 Dec 2002, Andreas Beck wrote:
> > 1- For precise interface layout, I do not want to program: I simply want
> > an UI builder. I do *not* care of the actual API involved below, I do not
> > want to be able to call it directly. I want these damns buttons to get
> > drawn, I do not want
On Tue, 17 Dec 2002, Filip Spacek wrote:
> What I think is needed is a more evolved concept of a subvisual. The
> current one can only be used to create a rectangular viewport on an
> existing visual is unfortunately insufficient. What we need is a subvisual
> that can be defined by an arbitrary n
Hi Rodolphe,
> > > Which widget library? Some of your own or something more general?
> > One of my own.
> I'm sure it is interesting and I'll certainly have a look at it, but don't
> you think that yet another custom widget library would not give problems
> to GGI (as a project)?
That's one of
On Wed, 18 Dec 2002, Andreas Beck wrote:
> > Which widget library? Some of your own or something more general?
>
> One of my own. Basically something to do away with an ugly TCL/Tk
> script that is used to control eccet. The idea is to have something that
> can nicely live side by side with o
On Tue, 17 Dec 2002, Filip Spacek wrote:
[...]
> Yes! These are exactly my dreams for the (near) future of libggi.
>
> What I think is needed is a more evolved concept of a subvisual. The
> current one can only be used to create a rectangular viewport on an
> existing visual is unfortunately ins
> > > Which widget library? Some of your own or something more general?
> > One of my own.
> How about uploading to our GGI ftp server and posting the URL here?
Done. It's in the misc-directory. widget.tgz
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]>
On Wed, 18 Dec 2002, Andreas Beck wrote:
> Rodolphe Ortalo <[EMAIL PROTECTED]> wrote:
>
> > What about 2 independent applications sharing a single 3D engine?
>
> :-) - yeah - what about any two apps sharing the same graphics subsystem
> (apart from X) ;-).
>
>
> > Which widget library? Some of y
> > Which widget library? Some of your own or something more general?
>
> One of my own. Basically something to do away with an ugly TCL/Tk
> script that is used to control eccet. The idea is to have something that
> can nicely live side by side with other stuff on a GGI visual.
>
> Existing li
Rodolphe Ortalo <[EMAIL PROTECTED]> wrote:
> > crunching even badly structured code. GGI was _interesting_ - it gave
> > something we didn't have on Linux yet, and it was _challenging_ to
> > write Code for it.
> You are too negative.
Right. I was playing advocatus diaboli.
> What about 2 ind
On Tuesday 17 December 2002 20:25, Martin Albert wrote:
> > Heh! Where do you get this messages from?
> Huh? This my own!
[Explicit On]
Hanging out on dubious hacker websites, like ggi-project.org and such,
following links to stuff that interests me, i often end up downloading
from stacken.kth.
On Tue, 17 Dec 2002, Andreas Beck wrote:
> When GGI was you, graphics on Linux was something exciting, new. And
> hardware wasn't that overly powerful, that you could just take some
> strange highlevel toolkit, drop in a scenery and get a 3D rendering
> from it. in realtime, just because the ha
On Tuesday 17 December 2002 18:42, Christoph Egger wrote:
> Heh! Where do you get this messages from?
Huh? This my own!
martin
> of minor importance, just to avoid duplication ;)
>
> - Hey, Marcus, i'm porting your synaesthesia ggi-driver to the current
> version.
>
> - Hey, Marcus, i'm after that svga4libggi of yours. Although you once
> pointed out it was just a hack, there is so much serious interest in
> it, it mi
of minor importance, just to avoid duplication ;)
- Hey, Marcus, i'm porting your synaesthesia ggi-driver to the current
version.
- Hey, Marcus, i'm after that svga4libggi of yours. Although you once
pointed out it was just a hack, there is so much serious interest in
it, it might become one o
On Tue, 17 Dec 2002, Andreas Beck wrote:
> 4. Take every fscking application you find nice and provide it with
>a LibGGI target. Show maintainers why LibGGI is a cool thing to have.
>See my example about why GGI for mplayer rocks.
This is indeed very important, IMO. There are lots of ap
> Well, ok... When there are no objections within the next 6 hours,
> I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and
> extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp,
> libvideo, libxmi, etc.) to the form of libggi. (i.e. libggigpf,
> libggigic, libggibse, libg
> > libbse, libgic and libgpf are NO extensions. Thus, how should we mark
> > ggi libs, which are NO extensions? IMO, extensions should be
> > distinguishable from non-extensions by their (package-)names.
> I clearly seem to fail to understand why this would be important, but
> anyway, this is not
> > On Sunday 15 December 2002 16:01, Christoph Egger wrote:
> > > libbse, libgic and libgpf are NO extensions. Thus, how should we mark
> > > ggi libs, which are NO extensions? IMO, extensions should be
> > > distinguishable from non-extensions by their (package-)names.
> >
> > I clearly seem to
> On Sunday 15 December 2002 16:01, Christoph Egger wrote:
> > libbse, libgic and libgpf are NO extensions. Thus, how should we mark
> > ggi libs, which are NO extensions? IMO, extensions should be
> > distinguishable from non-extensions by their (package-)names.
>
> I clearly seem to fail to unde
On Sunday 15 December 2002 16:01, Christoph Egger wrote:
> libbse, libgic and libgpf are NO extensions. Thus, how should we mark
> ggi libs, which are NO extensions? IMO, extensions should be
> distinguishable from non-extensions by their (package-)names.
I clearly seem to fail to understand why t
> Neil Pilgrim <[EMAIL PROTECTED]> wrote:
> > > I have tested your patch under Linux/i386 and Solaris 8/Sparc32.
> > > Tomorrow evening, I can test it under MacOS X/PPC32, too.
> > I've tested this and it works fine for me with Fresco, after prompting
> > from bughunter^WChristoph that it might fix
On Sat, 14 Dec 2002, Andreas Beck wrote:
> I spent quite a while thinking this code through, and suppose I got it
> right. I am not quite sure about the last two ifs in each chain. I think one
> could use greater/less-or-equal in the comparisions as well, thus correctly
> handling regions that jus
Neil Pilgrim <[EMAIL PROTECTED]> wrote:
> > I have tested your patch under Linux/i386 and Solaris 8/Sparc32.
> > Tomorrow evening, I can test it under MacOS X/PPC32, too.
> I've tested this and it works fine for me with Fresco, after prompting
> from bughunter^WChristoph that it might fix the curre
Christoph Egger wrote:
> On Sat, 14 Dec 2002, Andreas Beck wrote:
> [...]
> > I have tested these changes with my application, and it fixes the problems
> > I reported.
> >
> > Could you please go over the code and my comments and have a look, if the
> > fix is right? That stuff is pretty complex t
On Sat, 14 Dec 2002, Filip Spacek wrote:
> On Sat, 14 Dec 2002, Martin Albert wrote:
>
> > Sorry, if you find i'm insisting or sth. like that. I feel that i have
> > unsolved problems (some more?: eg. module-versioning).
> >
> > Tell me to shut up or to try to do more mindreading about authors
>
On Sat, 14 Dec 2002, Martin Albert wrote:
> Sorry, if you find i'm insisting or sth. like that. I feel that i have
> unsolved problems (some more?: eg. module-versioning).
>
> Tell me to shut up or to try to do more mindreading about authors
> reasons for those choices (am i not correct with: bu
On Sat, 14 Dec 2002, Andreas Beck wrote:
> > My guess is, that the dirty region tracking code gets messed up by
> > the Hline.
>
> Confirmed the GGI_X_CLEAN-Macro contains a bug (I think, it is pretty
> had to understand) Diff attached, please validate before I commit.
>
> Rationale for the chang
On Saturday 14 December 2002 15:06, Filip Spacek wrote:
> Personally, I would prefer something like
> libggi_window_manager_hints.so, because I don't quite see the need
> for shortening the name. And this goes for all extensions:
> libggi_descriptive_name_of_the_extension.so. Currently, I have
> ab
> My guess is, that the dirty region tracking code gets messed up by
> the Hline.
Confirmed the GGI_X_CLEAN-Macro contains a bug (I think, it is pretty
had to understand) Diff attached, please validate before I commit.
Rationale for the changes:
Old code was:
#define GGI_X_CLEAN(vis, _x, _y, _
On Sat, 14 Dec 2002, Martin Albert wrote:
> Oh, no, not that again ...! ;-) Yet it must be.
>
> Christoph Egger on Friday 13 December 2002 21:24:
> > Wann wird -rc5 ueberhaupt via aptget downloadbar?
>
> Packages are ready. I haven't uploaded, 'cause i don't like them yet.
> All that strange nam
Oh, no, not that again ...! ;-) Yet it must be.
Christoph Egger on Friday 13 December 2002 21:24:
> Wann wird -rc5 ueberhaupt via aptget downloadbar?
Packages are ready. I haven't uploaded, 'cause i don't like them yet.
All that strange names ...
On Saturday 14 December 2002 02:35, Andreas Beck
Forgot to mention - X server is XGGI running on top of matrox-fbdev.
CU, Andy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
> > > [Crosshatch/HLine disturbs update of region below]
> > This goes away, if I use either -noaccel or -nobuffer.
> Sounds like a broken MIT-SHM X extension. Please check out -noshm,
> -nobuffer:-noshm and -noaccel:-noshm
Test results: "-noshm" doesn't change anything.
The combination "-nobuffer
On Sat, 14 Dec 2002, Andreas Beck wrote:
> Yet another update:
>
> > > 3. One of my applications doesn't correctly update its windows. It draws a
> > > picture and then a crosshatch above it and a small figure that can be moved
> > > together with the crosshatch. Moving down works fine while movin
Yet another update:
> > 3. One of my applications doesn't correctly update its windows. It draws a
> > picture and then a crosshatch above it and a small figure that can be moved
> > together with the crosshatch. Moving down works fine while moving up/left
> > leaves old crosshatch marks on the s
> 1. The X target seems to use a proportional font now.
I was wrong on that. However it is using a 6x13 font now. I have fixed my
app to properly check the font size now, but:
The font size cannot be determined before the mode is set, which is pretty
annoying, as I want to size a window to hold
Christoph asked me to check my multi-visual, multi-threaded Application
with the current RC.
I just did, and the results are not quite pleasing:
1. The X target seems to use a proportional font now. While it looks nice
for looking at, it breaks quite some assumptions in my application and
makes i
42 matches
Mail list logo
