Re: Xaw: Label widget class
Tim Roberts wrote: Alexander Pohoyda wrote: I'd very like to have color pixmaps in labels and buttons, which I suppose is only possible with XCopyArea() call. Please correct me if I'm wrong. Yes, but that's not the only place it will burn you. I could fix one place at a time, or even bulk search and replace. I don't want to start yet another Xaw clone. Xaw is so yesterday. Yes, but I like that simple look and feel. I'm writing some new control prototypes and I think that the simplest the framework, the better. There has been some work at updating it (check for Xaw3d, XawPlus, or XawXpm), I know about them, but I could not find them in XFree86 source tree, so they don't exist for me. It's a pity those people spent so much time in wain. but I suspect you'd be better off moving into the 1990s with something like gtk or Qt. I will use some modern toolkit if my prototypes prove to be useful. Thank you very much for reply! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Xaw: Label widget class
There's a feature to draw a pixmap on the left of a label, but why is this done using XCopyPlane(..., 1L) and not XCopyArea() instead? I'd very like to have color pixmaps in labels and buttons, which I suppose is only possible with XCopyArea() call. Please correct me if I'm wrong. -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Xaw: Tree widget class
Hi folks, Currently, treeWidgetClass from Xaw supports only vertical: [node 1] [node 1.1][node 1.2] [node 1.1.1] and horizontal: [node 1.1] [node 1.1.1] [node 1] [node 1.2] layouts (which are set via gravity property). I would like to have a tree widget class with a standard tree layout, where nodes expand diagonally like this: [node 1] [node 1.1] [node 1.1.1] [node 1.2] This change may be seen as a simple extension to an existing treeWidgetClass. I have coded this already and I'm ready to send a patch. However, I need more features for this diagonal layout which may not be seen as extension, but are indeed new. For example, +/- knobs: -[node 1] -[node 1.1] [node 1.1.1] +[node 1.2] My question is: should I submit the simple diagonal layout patch and for new features derive a new class from treeWidgetClass or just put both diagonal layout and new features into a new derived class? Your input is very much appreciated. -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Xaw/simpleWidgetClass: I18N problem with XtNtip resource
The problem is that this resource is stored as char* in Simple.c (see XtNewString() call), but is used as XChar2b* in Tip.c when XtNinternational is True. The real problem is that simpleWidgetClass has neither XtNinternational, nor XtNencoding resources. simpleWidgetClass still has XtPointer pad[2] free, so it should be possible to extend it. Any objections? Another question is why do we actually need those both resources? Encoding is more expressive information, so I suggest to prefer it over international flag. Yet another idea: Tip.c contains a lot of code that manages multiline strings in windows, but the same stuff is done in Label.c and it should be possible for tipWidgetClass to handle only events and timers and use labelWidgetClass to draw the actual string. Any objections on this? Please CC me on reply. Thank you! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Moving XtWidth, XtHeight, XtX and XtY macroes from XmP.h to IntrinsicP.h
On Wed, 14 Sep 2005, Alexander Pohoyda wrote: On Tue, 13 Sep 2005, Marc Aurele La France wrote: On Tue, 13 Sep 2005, Alexander Pohoyda wrote: Don't you think it makes sense to move (some of) those macroes from Xm/XmP.h to X11/IntrinsicP.h file? They seem to belong there. Given that what you actually mean is Xt/IntrinsicP.h, I'd tend to agree with you. Especially given that, in out source tree, only Xaw references these anyway. ... even though Xm/XmP.h is a Motif thing (i.e. not distributed with any XFree86 or X.Org server, per se). You're right. I should have checked first. So, should I not use those macroes in libXaw at all, or should I bring them to Xt headers files like this: #ifndef XtWidth #define XtWidth(w) (((Widget)(w))-core.width) #endif ... Which solution do you prefer? My preference is definitely b, i.e. your second choice. Mind you I've no idea how this would affect the various Xm/XmP.h's out there. I have also found these defines in Xaw/Private.h, so the problem is solved for me. -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: libXaw/Viewport widget initialization
I do have one request though. If you are to contune with more Xaw work, please ensure you do not adversely affect Xaw6. What do you mean? How do I ensure this? I mean that, even with your changes to xc/lib/Xaw, you should ensure xc/lib/Xaw6 is still buildable. OK, I see. I will provide patches to fix those build errors caused by my changes. Thanks a lot for pointing that out! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Moving XtWidth, XtHeight, XtX and XtY macroes from XmP.h to IntrinsicP.h
Don't you think it makes sense to move (some of) those macroes from Xm/XmP.h to X11/IntrinsicP.h file? They seem to belong there. Please CC me on reply. Thank you! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
libXaw/Viewport widget initialization
The original problem is that when I use my experimental Hyperbolic Tree widget as a child of Viewport widget, the size of unrealized Viewport widget is not yet set and thus I cannot find out how much space I have available for layout. I have the following patch in mind and it solves the problem for me. Does it make sense or should I look for another solution? Index: Viewport.c === RCS file: /cvs/xc/lib/Xaw/Viewport.c,v retrieving revision 1.11 diff -u -r1.11 Viewport.c --- Viewport.c 14 Dec 2001 19:54:45 - 1.11 +++ Viewport.c 13 Sep 2005 18:18:07 - @@ -292,6 +292,12 @@ w-form.default_spacing = 0; /* Reset the default spacing to 0 pixels */ /* + * Get the size from the parent + */ +XtWidth(w) = XtWidth(XtParent(w)); +XtHeight(w) = XtHeight(XtParent(w)); + +/* * Initialize all widget pointers to NULL */ w-viewport.child = NULL; Please CC me on reply. Thank you. -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
VisibilityNotify/XRaiseWindow race
Hi!
This is a general question on X client design. Please excuse me that
it is not directly related to the XFree86 Project.
Imagine there are two clients running the same code:
while (!done)
{
XWindowEvent(... | VisibilityChangeMask, theEvent);
switch (theEvent.type)
{
...
case VisibilityNotify:
XRaiseWindow(...);
break;
}
}
Obviously, there's a race here. Both clients are fighting to get on
top.
There's a real-world example of this problem. One application is
called xbattbar (which is a battery status indicator), another is
xlock (used as screensaver).
While I was able to find a description of the problem on the Net,
there was no solution offered.
Is there a Right Way to solve this problem?
Many thanks for any answers in advance!
--
Alexander Pohoyda [EMAIL PROTECTED]
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
[XFree86] TWM patches
Hi, Would somebody please have a look at my TWM patches? http://bugs.xfree86.org/show_bug.cgi?id=968 XPM picture format support for icons. http://bugs.xfree86.org/show_bug.cgi?id=1078 Function to change window/icon titles. http://bugs.xfree86.org/show_bug.cgi?id=1124 IconMaxWidth parameter to limit the width of the icon window (Mozilla tends to have very long titles) These all are small enhancements, but I'd like to know if they have any chance to be accepted. Thank you very much! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] TWM patches
Hi, Would somebody please have a look at my TWM patches? http://bugs.xfree86.org/show_bug.cgi?id=968 XPM icon support. http://bugs.xfree86.org/show_bug.cgi?id=1078 Function to change window titles. http://bugs.xfree86.org/show_bug.cgi?id=1124 IconMaxWidth parameter to limit the width of the icon window (Mozilla tends to have very long titles) These all are small enhancements, but I'd like to know if they have any chance to be accepted. Thank you very much! -- Alexander Pohoyda [EMAIL PROTECTED] PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
VisibilityNotify/XRaiseWindow question
Hi!
This is a general question on X client design. Please excuse me that
it is not directly related to the XFree86 Project.
Imagine there are two clients running the same code:
while (!done)
{
XWindowEvent(... | VisibilityChangeMask, theEvent);
switch (theEvent.type)
{
...
case VisibilityNotify:
XRaiseWindow(...);
break;
}
}
Obviously, there's a race here. Both clients are fighting to get on top.
There's a real example of this problem. One application is called
xbattbar (which is a battery status indicator), another is xlock
(used as screensaver).
What would be the right way to solve this problem?
Thanks for any answers in advance!
--
Alexander Pohoyda [EMAIL PROTECTED]
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
VisibilityNotify/XRaiseWindow race
Hi developers,
This question is probably not related to the XFree86 itself, but is a
general X client design decision.
There is a small but useful X client called xbattbar. It's a notebook
battery status indicator. It has an option to keep it always visible
on the screen. This option is implemented like this:
...
myEventMask = VisibilityChangeMask | ...;
...
XSelectInput(disp, winbar, myEventMask);
while (1) {
XWindowEvent(disp, winbar, myEventMask, theEvent);
switch (theEvent.type) {
...
case VisibilityNotify:
if (alwaysontop) XRaiseWindow(disp, winbar);
break;
...
This works great until there's another client which wants to do the
same. At this time, both applications are racing to get on top of the
screen.
Let's have a look at the xlock used as a screensaver:
...
case VisibilityNotify:
/* next line for -geometry */
if (event.xvisibility.state != VisibilityUnobscured) {
/* window was restacked or exposed */
if (!debug !inwindow)
XRaiseWindow(dsp, event.xvisibility.window);
break;
...
What would be the right way to fix this?
Thanks for your attention.
--
Alexander Pohoyda [EMAIL PROTECTED]
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [I18n] Re: Some thoughts on XKB symbols
Danilo Segan [EMAIL PROTECTED] writes: On Thu, 14 Aug 2003, Danilo Segan wrote: For the sake of difference, I would recommend the following: - National keymaps should use ISO 3166 code in all UPPERCASE (eg. US) - Linguistic keymaps should use ISO 639 code in all lowercase (eg. en) Is this going to cause us to run into CVS problem we had resentily, where we couldn't rename file hp to directory HP (or similar) ? [...] Though, if anything of this scale is to be done, I'd be very eager to add a completely new directory (namespace) in order not to break compatibility. Eg. I'd introduce a new xkb/symbols/improved directory where to put these kind of maps ;-) I'm thinking about a proposal to move `geometry' directory to some more apropriate directory to change it's internal structure a bit. Please keep me posted if you plan to do any changes to symbols directory. Thank you in advance. -- Alexander Pohoyda [EMAIL PROTECTED] ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: CVS Update: xc (branch: trunk)
Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. That's right, we can. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. OK, let's do it this way. Some brands just had luck to be created as directories in the first place. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes [EMAIL PROTECTED] writes: On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. If you decide to go this way, please let me know and I will be happy to prepare new diffs. This strategy will require some re-arrangements: instead of accessing a `hp/omnibook(us)', we'll need to do `hp(omnibook.us)' or whatever. Actually, we are trying to fit company/family/model/variant into 2-level structure file/section. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes [EMAIL PROTECTED] writes: going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. OK, it seems to be the best solution in this situation. I dare to propose another solution, however: to delete the `geometry' directory and created a new one (named `geometry2` or `geom` or whatever) which will have companies as lowercased directories. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. Yes, that's right. This is not a limitaton of XKB. If you have a look into newly created geometry, you'll see that it already contains 3 sections, which are nested and re-used: 1. for the mouse stick 2. for the base frame and common buttons 3. for US keyboard layout. Some other geometries (like ibm/thinkpad) have also 4. for national layouts. I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) I'm open to suggestions. Thanks! -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Todd T. Fries [EMAIL PROTECTED] writes: Penned by Dr Andrew C Aitchison on Thu, Jul 24, 2003 at 04:30:47PM +0100, we have: [..] | Aside: | Which operating systems are shipping with IPv6 enabled by default ? OpenBSD ships with IPv6 enabled by default. Anytime an interface is brought FreeBSD too. Tested on 4.8-STABLE. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
twm crash with debug info
, heightEverChangedByUser = 0} (gdb) So, the problem is that the theWindow-name is NULL. Now, if you look into add_window.c, you'll see: 188 tmp_win = (TwmWindow *)calloc(1, sizeof(TwmWindow)); ... BTW, ... 205 if (!I18N_FetchName(dpy, tmp_win-w, name)) (gdb) p name $1 = 0x80948c0 TWM Icon Manager I have no idea what's the correct way to fix this. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: a small twm/Imakefile patch
Marc Aurele La France [EMAIL PROTECTED] writes: http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff Updated. Can you elaborate on why is it useful to switch from single quote quoting to backslashes? It may be not useful as much, but with an old version we end up calling a command: [...] cc -c [...] -DHAS_MKSTEMP '-DSYSTEM_INIT_FILE='/usr/X11R6/lib/X11/twm'/system.twmrc' parse.c which is not consistent, does not look very nice and requires more processing by the shell. ... but is still required for portability reasons. Oh! Good to know. Thanks. May I also ask on which system/shell/compiler/imake would my patch fail? Just for the record. With your change, on IRIX, I get: [aurora:/scratch_large/root/X11/alpha/loader/xc/programs] make SUBDIRS=twm Makefiles making Makefiles in programs/twm... mv -f Makefile Makefile.bak cc-1018 cc: ERROR at end of source An unmatched left parentheses ( appears in an expression. Would you please try if it works on IRIX this way: -SpecialCObjectRule(parse,$(_NOOP_),'-DSYSTEM_INIT_FILE='$(TWMDIR)'/system.twmrc') +SpecialCObjectRule(parse,$(_NOOP_),'-DSYSTEM_INIT_FILE=$(TWMDIR)/system.twmrc') It's not about commiting this senseless patch, of course :-) Thank you very much! -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: a small twm/Imakefile patch
Matthieu Herrb [EMAIL PROTECTED] writes: Alexander Pohoyda wrote (in a message from Monday 7) http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff Can you elaborate on why is it useful to switch from single quote quoting to backslashes? It may be not useful as much, but with an old version we end up calling a command: [...] cc -c [...] -DHAS_MKSTEMP '-DSYSTEM_INIT_FILE='/usr/X11R6/lib/X11/twm'/system.twmrc' parse.c which is not consistent, does not look very nice and requires more processing by the shell. I have no more arguments, sorry. Please forget the issue if you don't agree with my reasoning. Many thanks for the reply anyway! -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: a small twm/Imakefile patch
Marc Aurele La France [EMAIL PROTECTED] writes: On 9 Jul 2003, Alexander Pohoyda wrote: Matthieu Herrb [EMAIL PROTECTED] writes: Alexander Pohoyda wrote (in a message from Monday 7) http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff Can you elaborate on why is it useful to switch from single quote quoting to backslashes? It may be not useful as much, but with an old version we end up calling a command: [...] cc -c [...] -DHAS_MKSTEMP '-DSYSTEM_INIT_FILE='/usr/X11R6/lib/X11/twm'/system.twmrc' parse.c which is not consistent, does not look very nice and requires more processing by the shell. ... but is still required for portability reasons. Oh! Good to know. Thanks. May I also ask on which system/shell/compiler/imake would my patch fail? Just for the record. I'm really sorry if I miss some common knowledge here. I'm wondering how this can work then: ./xc/programs/xkbcomp/Imakefile:ROOT_DEFINES = -DDFLT_XKB_CONFIG_ROOT=\$(LIBDIR)/xkb\ ./xc/programs/xdm/Imakefile:RANDOM_DEFINES = -DDEV_RANDOM=\/dev/urandom\ -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: twm makes uninitialized memory access after malloc()
I'll try that tonight on the FreeBSD system. We have these options for malloc: A All warnings (except for the warning about unknown flags being set) become fatal. The process will call abort(3) in these cases. J Each byte of new memory allocated by malloc(), realloc() or reallocf() as well as all memory returned by free(), realloc() or reallocf() will be initialized to 0xd0. This options also sets the ``R'' option. This is intended for debugging and will impact performance negatively. I'm running a debug version of twm with /etc/malloc.conf - AJ since Friday, and it never crashed. I'll try to run non-debug version. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
a small twm/Imakefile patch
Does not really deserves a Bugzilla report (1K): http://www.alexander-pohoyda.privat.t-online.de/patches/twm.Imakefile.diff -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Egbert Eich [EMAIL PROTECTED] writes: [...] static int doScalable; static int doBitmaps; -static int doEncodings; +static int onlyEncodings; +static int onlyEncodings; A typo? -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: twm makes uninitialized memory access after malloc()
I'll try that tonight on the FreeBSD system. We have these options for malloc: A All warnings (except for the warning about unknown flags being set) become fatal. The process will call abort(3) in these cases. J Each byte of new memory allocated by malloc(), realloc() or reallocf() as well as all memory returned by free(), realloc() or reallocf() will be initialized to 0xd0. This options also sets the ``R'' option. This is intended for debugging and will impact performance negatively. We have a report in Bugzilla (#464), concerning twm. This test can only be made on NetBSD: === if you set /etc/malloc.conf to AJ (fill malloc'ed region with random value), twm crashes occasionary. i'm yet to find out a concrete way to repeat the symptom, however, it seems that twm (or some library) is touching malloc'ed memory region without initialization. === Could somebody with NetBSD please try to reproduce this? I'd at least need a debugger backtrace to get a clue where the problem may be. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
imake template to install files from a third directory
Hi list, I am unable to find a template to create a rule to install files from a directory which does not have a makefile itself. I need to process some files matching a mask (e.g. somedir/*.xpm) without having to list them all in a makefile. There is an InstallMultiple(list,dest) macro, but it takes a file list as an argument, so that's exactly what I want to avoid. I believe that this is quite a general task, so I dare to propose a new template. Please see the attached patch. I would appreciate any ideas about this patch or maybe there are good reasons not to have such a template? Better ways to do this? Thanks in advance! -- Alexander Pohoyda [EMAIL PROTECTED] Imake.rules.diff Description: Binary data
