Menu
▾
▴
notion-devel — Development discussion about the notion window manager
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(66) |
May
|
Jun
|
Jul
|
Aug
(31) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(35) |
Mar
(11) |
Apr
(16) |
May
(18) |
Jun
|
Jul
(1) |
Aug
(12) |
Sep
(21) |
Oct
(23) |
Nov
(12) |
Dec
|
| 2012 |
Jan
(5) |
Feb
(14) |
Mar
(3) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
(12) |
| 2013 |
Jan
(11) |
Feb
(10) |
Mar
(2) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(2) |
| 2014 |
Jan
(43) |
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(4) |
Nov
|
Dec
|
|
From: Josef 'J. S. <je...@jo...> - 2011-09-28 00:39:08
|
Hello, I'm an OpenIndiana [1] develaper. I'd love to package up Notion, but long story short, the lack of tarballs releases makes it rather difficult. Are there any plans for a release in the near future? Thanks, Jeff. [1] http://openindiana.org -- *NOTE: This message is ROT-13 encrypted twice for extra protection* |
|
From: Arnout E. <no...@bz...> - 2011-09-14 16:42:40
|
Merged, thanks! On Wed, Sep 14, 2011 at 01:27:06PM +0400, Sergej Pupykin wrote: > At Tue, 13 Sep 2011 21:08:51 +0200, > Arnout Engelen <no...@bz...> wrote: > > > Also mod_xkb looks usefull, but not included. > > > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb > > > > That looks distinct from the mod_xkbevents that's in notion indeed. > > > > Perhaps it could be renamed to make the distinction between mod_xkbevents and > > this one clear? What would be a good name? > > Here is the patch for mod_xkbevents which adds mod_xkb functionality. > Only 22 lines of C-code was added. > |
|
From: Sergej P. <ml...@se...> - 2011-09-14 09:27:20
|
At Tue, 13 Sep 2011 21:08:51 +0200, Arnout Engelen <no...@bz...> wrote: > > Also mod_xkb looks usefull, but not included. > > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb > > That looks distinct from the mod_xkbevents that's in notion indeed. > > Perhaps it could be renamed to make the distinction between mod_xkbevents and > this one clear? What would be a good name? Here is the patch for mod_xkbevents which adds mod_xkb functionality. Only 22 lines of C-code was added. |
|
From: Arnout E. <no...@bz...> - 2011-09-13 22:10:25
|
On Tue, Sep 13, 2011 at 08:11:12PM +0400, Sergej Pupykin wrote: > what do you think about adding contrib/ - usefull (but probably > unmaintained) scripts into notion tree or another git repo on > notion.sf.net? > > Saved in anion: > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib There's another repository with this collection at: https://github.com/jhamb/NotionScriptsCollection.git It seems both that repo and yours have some fixes, I merged the two and added the result to the notion git repo: http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/contrib;a=shortlog;h=HEAD Kind regards, Arnout |
|
From: Sergej P. <ml...@se...> - 2011-09-13 20:11:14
|
On 13.09.2011 23:08, Arnout Engelen wrote: > On Tue, Sep 13, 2011 at 08:46:25PM +0400, Sergej Pupykin wrote: >> At Tue, 13 Sep 2011 20:11:12 +0400, >> Sergej Pupykin<ml...@se...> wrote: >>> what do you think about adding contrib/ - usefull (but probably >>> unmaintained) scripts into notion tree or another git repo on >>> notion.sf.net? >>> >>> Saved in anion: >>> http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib >> >> Also mod_xkb looks usefull, but not included. >> http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb > > That looks distinct from the mod_xkbevents that's in notion indeed. > > Perhaps it could be renamed to make the distinction between mod_xkbevents and > this one clear? What would be a good name? May be merge them? I can make patch. |
|
From: Arnout E. <no...@bz...> - 2011-09-13 20:08:17
|
On Tue, Sep 13, 2011 at 11:55:56PM +0400, Sergej Pupykin wrote: > On 13.09.2011 23:08, Arnout Engelen wrote: > >On Tue, Sep 13, 2011 at 08:46:25PM +0400, Sergej Pupykin wrote: > >>At Tue, 13 Sep 2011 20:11:12 +0400, > >>Sergej Pupykin<ml...@se...> wrote: > >>>what do you think about adding contrib/ - usefull (but probably > >>>unmaintained) scripts into notion tree or another git repo on > >>>notion.sf.net? > >>> > >>>Saved in anion: > >>>http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib > >> > >>Also mod_xkb looks usefull, but not included. > >>http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb > > > >That looks distinct from the mod_xkbevents that's in notion indeed. > > > >Perhaps it could be renamed to make the distinction between mod_xkbevents and > >this one clear? What would be a good name? > > May be merge them? I can make patch. If it makes sense - I'm not too familiar with XKB, don't know if people might be interested in one but not the other. Arnout |
|
From: Arnout E. <no...@bz...> - 2011-09-13 19:09:01
|
On Tue, Sep 13, 2011 at 08:46:25PM +0400, Sergej Pupykin wrote: > At Tue, 13 Sep 2011 20:11:12 +0400, > Sergej Pupykin <ml...@se...> wrote: > > what do you think about adding contrib/ - usefull (but probably > > unmaintained) scripts into notion tree or another git repo on > > notion.sf.net? > > > > Saved in anion: > > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib > > Also mod_xkb looks usefull, but not included. > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb That looks distinct from the mod_xkbevents that's in notion indeed. Perhaps it could be renamed to make the distinction between mod_xkbevents and this one clear? What would be a good name? Kind regards, Arnout |
|
From: Sergej P. <ml...@se...> - 2011-09-13 16:46:32
|
At Tue, 13 Sep 2011 20:11:12 +0400, Sergej Pupykin <ml...@se...> wrote: > what do you think about adding contrib/ - usefull (but probably > unmaintained) scripts into notion tree or another git repo on > notion.sf.net? > > Saved in anion: > http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib Also mod_xkb looks usefull, but not included. http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fmod_xkb |
|
From: Sergej P. <ml...@se...> - 2011-09-13 16:36:12
|
Hi, what do you think about adding contrib/ - usefull (but probably unmaintained) scripts into notion tree or another git repo on notion.sf.net? Saved in anion: http://code.google.com/p/anion3/source/browse/#hg%2Fanionwm-3%2Fanionwm-3%2Fcontrib |
|
From: Arnout E. <no...@bz...> - 2011-08-30 22:30:18
|
On Sat, Aug 06, 2011 at 01:49:34PM +0200, Arnout Engelen wrote: > b) Continue to put (one or multiple) WScreen's under the WRootWin. In this > case WRootWin should no longer be a WMPlex - and thus no longer a WScreen. > Instead, WRootWin would become a subclass of WGroup, and (also in the > non-Xinerama case) contain 1 WScreen. A WRootWin would continue to > correspond to an X Screen, and a WScreen would correspond to a physical > monitor. Hmm. This is tricky because WGroup expectes to be the child of a WWindow (either WRootWin or WFrame). We could either drop this expectation, or make WRootWin a subclass of WWindow rather than WGroup - just like WMPlex. I'm leaning towards the latter. Kind regards, Arnout |
|
From: Arnout E. <no...@bz...> - 2011-08-30 20:29:35
|
Hi, Looks like utils/ion-completefile/ion-completefile.c is licensed under a variant of the 4-clause BSD license, which afaics is incompatible with both the GPL, the LGPL and the Notion license. While this might not be an urgent issue (after all, the code has been in there for more than 10 years now), we should fix this. Probably by ripping this code out and replacing it with new completion code. Kind regards, Arnout |
|
From: Arnout E. <no...@bz...> - 2011-08-30 20:12:38
|
On Wed, Aug 24, 2011 at 01:06:23PM +0400, Sergej Pupykin wrote: > here is small patch for notion-doc makefile. It contains mostly > dependency fixes Thanks, applied and committed! > take attention to > cat $< | sed 's|UTF8_STRING|UTF8\\_STRING|' >$@ > > at the end of this patch. Probably it should be fixed in another way > in ioncore. I agree: EXTL_DOC should be valid TeX to begin with. Fixed that in property.c Thanks, Arnout |
|
From: Sergej P. <ml...@se...> - 2011-08-24 09:24:59
|
Hi, here is small patch for notion-doc makefile. It contains mostly dependency fixes, but take attention to cat $< | sed 's|UTF8_STRING|UTF8\\_STRING|' >$@ at the end of this patch. Probably it should be fixed in another way in ioncore. |
|
From: Arnout E. <no...@bz...> - 2011-08-21 21:27:20
|
On Sat, Aug 06, 2011 at 01:49:34PM +0200, Arnout Engelen wrote: > https://sourceforge.net/tracker/?func=detail&aid=3349390&group_id=314802&atid=1324528 > > notion/mod_xinerama are not implemented correctly. I see 2 obvious ways > forward: > > a) Modify mod_xinerama to not put the WScreen's for the physicial screens > directly under the WRootWin. Instead, we could introduce a WGroupS (group of > screens), put the WGroupS under the WRootWin and put the WScreen's under that > WGroupS > > b) Continue to put (one or multiple) WScreen's under the WRootWin. In this > case WRootWin should no longer be a WMPlex - and thus no longer a WScreen. > Instead, WRootWin would become a subclass of WGroup of WScreen's, and also in > the non-Xinerama case contain 1 WScreen. A WRootWin would continue to > correspond to an X Screen, and a WScreen would correspond to a physical > monitor. > > Any comments? As far as I can see now, option 'b' seems like a larger change, > but on the other hand the end-result seems more elegant and easier to maintain. This is not an academical issue btw: our current workaround (the original, incorrect behavior) does not allow us to resize the WScreen's at all - of course that won't do, for example when the resolution is changed. Arnout |
|
From: Arnout E. <no...@bz...> - 2011-08-14 18:22:18
|
Hello,
Afaics there are currently no release-critical bugs in our bugtracker.
Perhaps we should start thinking of putting out a first release (0.1? 1.0?).
After that packaging notion for various distributions can get started, of
course aside from continuing development.
Are there any current problems we need to solve before putting out a release?
What should this release contain? Notion, of course, but also a collection of
scripts ('NotionScriptsCollection'?), modules (xkbevents, xrandr, xinerama)?
What do you think?
Kind regards,
Arnout
|
|
From: Arnout E. <no...@bz...> - 2011-08-14 17:23:00
|
Hello, Earlier this year Tomáš Ebenlendr (ebik) and me did some improvements on 'mod_xinerama' in the 'split' branch. In summary: * Refactor to put more of the logic in lua * Start on support for updating existing screens (in preperation of supporting on-the-fly RandR changes in screens layout) This work is not finished, there are some open questions. Most importantly: what to do when changing layout to a layout with less WScreen's. What should we do with the 'leftover' WScreens? Still, I feel the 'split' branch is a real improvement over the old approach already, so I've merged into 'master'. Kind regards, Arnout |
|
From: Arnout E. <no...@bz...> - 2011-08-14 15:17:48
|
Hello, It seems there's a patch floating around for adding XFT support to ion3 - for example I found it at http://aur.archlinux.org/packages.php?ID=28065 It seems Tuomo was not too impressed by this patch (for example http://lists.berlios.de/pipermail/ion-general/2007-December/000912.html ). To be quite honest, I hardly know what XFT *is*, but it appears people care about it. Is it possible to support XFT (as a run-time option), so people who want it have it but it isn't forced upon others? Does anyone know who wrote this patch and how it's licensed? Do we want this? Regards, Arnout |
|
From: Sascha S. <sas...@si...> - 2011-08-08 08:02:30
|
Excerpts from Arnout Engelen's message of Sun Aug 07 15:23:34 +0200 2011: > Thank you for your patch and sorry about not looking into it earlier. I have > pushed it and refactored it a bit, adding some more explicit documentation > in a couple of places. Thanks, much appreciated (both pushing and the improvements)! Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ |
|
From: Arnout E. <no...@bz...> - 2011-08-07 14:21:36
|
It seems both system-inc.mk and system.mk were originally meant for 'system-specific configuration'. Perhaps we should drop build/system-inc.mk, move system.mk to build/autodetect.mk(?) and include build/libs.mk, build/autodetect.mk and local.mk (if available) directly from the Makefile? This has gotten a bit complex, now seems like a good time to clean up and and simplify :). Regards, Arnout On Sat, May 14, 2011 at 06:26:11PM +0200, Arnout Engelen wrote: > On Fri, May 13, 2011 at 07:24:29AM -0400, Etan Reisner wrote: > > I'm also open to simply having system.mk include (without failing if it > > doesn't exit) a local.mk (or similar) file to allow these sort of > > custom definitions. > > This sounds like an elegant solution to me - any drawbacks we can think of? > > > Arnout > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel |
|
From: Arnout E. <no...@bz...> - 2011-08-07 13:38:53
|
Hello Sascha, Thank you for your patch and sorry about not looking into it earlier. I have pushed it and refactored it a bit, adding some more explicit documentation in a couple of places. Kind regards, Arnout On Sat, Jul 02, 2011 at 01:51:28PM +0200, Sascha Silbe wrote: > In case Xlib doesn't support XUTF8StringStyle we fall back to the old, broken > behaviour of using the encoding of the current locale. If there's really > anyone still using such a beast _and_ caring about EWMH [1] they can enhance > the code to do an explicit conversion (locale enconding to UTF-8) and set the > type to the UTF8_STRING Atom manually. > > [1] http://freedesktop.org/wiki/Specifications/wm-spec > > Signed-off-by: Sascha Silbe <sas...@si...> > --- > > With this fix wnck_screen_get_window_manager_name() (libwnck) will return > "notion" instead of NULL, thus notion gets recognised as an active EWMH > compliant window manager. > > ioncore/netwm.c | 4 ++++ > ioncore/property.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > ioncore/property.h | 4 ++++ > 3 files changed, 55 insertions(+), 0 deletions(-) > > diff --git a/ioncore/netwm.c b/ioncore/netwm.c > index 06471c7..5e4b763 100644 > --- a/ioncore/netwm.c > +++ b/ioncore/netwm.c > @@ -81,7 +81,11 @@ void netwm_init_rootwin(WRootWin *rw) > 32, PropModeReplace, (uchar*)atoms, N_NETWM); > > p[0]=libtu_progbasename(); > +#ifdef X_HAVE_UTF8_STRING > + xwindow_set_utf8_property(rw->dummy_win, atom_net_wm_name, p, 1); > +#else > xwindow_set_text_property(rw->dummy_win, atom_net_wm_name, p, 1); > +#endif > } > > > diff --git a/ioncore/property.c b/ioncore/property.c > index 4ef66e3..8cc1937 100644 > --- a/ioncore/property.c > +++ b/ioncore/property.c > @@ -230,6 +230,24 @@ void xwindow_set_text_property(Window win, Atom a, const char **ptr, int n) > XFree(prop.value); > } > > +#ifdef X_HAVE_UTF8_STRING > +void xwindow_set_utf8_property(Window win, Atom a, const char **ptr, int n) > +{ > + XTextProperty prop; > + bool ok; > + > + int st=XmbTextListToTextProperty(ioncore_g.dpy, (char **)ptr, n, > + XUTF8StringStyle, &prop); > + ok=(st>=0); > + > + if(!ok) > + return; > + > + XSetTextProperty(ioncore_g.dpy, win, &prop, a); > + XFree(prop.value); > +} > +#endif > + > > /*}}}*/ > > @@ -437,6 +455,35 @@ void ioncore_x_set_text_property(int win, int atom, ExtlTab tab) > } > > > +#ifdef X_HAVE_UTF8_STRING > +/*EXTL_DOC > + * Set a UTF8_STRING property for a window. The fields of \var{tab} starting > + * from 1 should be the different null-separated parts of the property. > + * See the \code{XSetTextProperty}(3) manual page for more information. > + */ > +EXTL_EXPORT > +void ioncore_x_set_utf8_property(int win, int atom, ExtlTab tab) > +{ > + char **list; > + int i, n=extl_table_get_n(tab); > + > + list=ALLOC_N(char*, n); > + > + if(list==NULL) > + return; > + > + for(i=0; i<n; i++){ > + list[i]=NULL; > + extl_table_geti_s(tab, i+1, &(list[i])); > + } > + > + xwindow_set_utf8_property(win, atom, (const char **)list, n); > + > + XFreeStringList(list); > +} > +#endif > + > + > /*}}}*/ > > > diff --git a/ioncore/property.h b/ioncore/property.h > index e1cd083..0e321c2 100644 > --- a/ioncore/property.h > +++ b/ioncore/property.h > @@ -25,6 +25,10 @@ extern void xwindow_set_state_property(Window win, int state); > extern char **xwindow_get_text_property(Window win, Atom a, int *nret); > extern void xwindow_set_text_property(Window win, Atom a, > const char **p, int n); > +#ifdef X_HAVE_UTF8_STRING > +extern void xwindow_set_utf8_property(Window win, Atom a, > + const char **p, int n); > +#endif > extern bool xwindow_get_cardinal_property(Window win, Atom a, CARD32 *vret); > > #endif /* ION_IONCORE_PROPERTY_H */ > -- > 1.7.2.5 > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel |
|
From: Arnout E. <no...@bz...> - 2011-08-06 12:04:54
|
Hi, In looking at https://sourceforge.net/tracker/?func=detail&aid=3349390&group_id=314802&atid=1324528 , I decided I'm confused about the Notion/X11 data model, and wanted to run this by you guys. As far as I understand, X defines a 'Display' which corresponds to an X server. A Display may have multiple X Screen's, when supporting multiple monitors. However, when using 'multihead', nowadays it is common for the X server to have only 1 'virtual' Screen spanning all physical monitors. Each Screen has 1 'root window' (of type Window). Over to the Notion side, we have the WRootWin which is a WScreen which is an MPlex. There is 1 WRootWin per X Screen. This window, being an MPlex, may contain multiple regions, only one of which is visible at a time (http://notion.sourceforge.net/notionnotes/node2.html#SECTION00021000000000000000). Typically, it will have one instance of WGroupWS per workspace on that monitor. In the current implementation of mod_xinerama, mod_xinerama creates a new WScreen for each monitor. When using Xinerama/RandR, there's only one X Screen and thus only one WRootWin. Instead of WGroupWS's, mod_xinerama puts these new sub-WScreen's under the WRootWin, and puts the WGroupWS's under those sub-WScreen's. That seems to make sense to me, except that WRootWin is a WMPlex, so this would mean only one of the sub-WScreen's should be visible at the time. Of course in this context that's not the case. Question 1) is my above interpretation correct? If my above interpretation is correct, then notion/mod_xinerama are not implemented correctly. I see 2 obvious ways forward: a) Modify mod_xinerama to not put the WScreen's for the physicial screens directly under the WRootWin. Instead, we could introduce a WGroupS (group of screens), put the WGroupS under the WRootWin and put the WScreen's under that WGroupS b) Continue to put (one or multiple) WScreen's under the WRootWin. In this case WRootWin should no longer be a WMPlex - and thus no longer a WScreen. Instead, WRootWin would become a subclass of WGroup of WScreen's, and also in the non-Xinerama case contain 1 WScreen. A WRootWin would continue to correspond to an X Screen, and a WScreen would correspond to a physical monitor. Any comments? As far as I can see now, option 'b' seems like a larger change, but on the other hand the end-result seems more elegant and easier to maintain. Kind regards, Arnout |
|
From: Sascha S. <sas...@si...> - 2011-07-02 12:18:45
|
In case Xlib doesn't support XUTF8StringStyle we fall back to the old, broken behaviour of using the encoding of the current locale. If there's really anyone still using such a beast _and_ caring about EWMH [1] they can enhance the code to do an explicit conversion (locale enconding to UTF-8) and set the type to the UTF8_STRING Atom manually. [1] http://freedesktop.org/wiki/Specifications/wm-spec Signed-off-by: Sascha Silbe <sas...@si...> --- With this fix wnck_screen_get_window_manager_name() (libwnck) will return "notion" instead of NULL, thus notion gets recognised as an active EWMH compliant window manager. ioncore/netwm.c | 4 ++++ ioncore/property.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ ioncore/property.h | 4 ++++ 3 files changed, 55 insertions(+), 0 deletions(-) diff --git a/ioncore/netwm.c b/ioncore/netwm.c index 06471c7..5e4b763 100644 --- a/ioncore/netwm.c +++ b/ioncore/netwm.c @@ -81,7 +81,11 @@ void netwm_init_rootwin(WRootWin *rw) 32, PropModeReplace, (uchar*)atoms, N_NETWM); p[0]=libtu_progbasename(); +#ifdef X_HAVE_UTF8_STRING + xwindow_set_utf8_property(rw->dummy_win, atom_net_wm_name, p, 1); +#else xwindow_set_text_property(rw->dummy_win, atom_net_wm_name, p, 1); +#endif } diff --git a/ioncore/property.c b/ioncore/property.c index 4ef66e3..8cc1937 100644 --- a/ioncore/property.c +++ b/ioncore/property.c @@ -230,6 +230,24 @@ void xwindow_set_text_property(Window win, Atom a, const char **ptr, int n) XFree(prop.value); } +#ifdef X_HAVE_UTF8_STRING +void xwindow_set_utf8_property(Window win, Atom a, const char **ptr, int n) +{ + XTextProperty prop; + bool ok; + + int st=XmbTextListToTextProperty(ioncore_g.dpy, (char **)ptr, n, + XUTF8StringStyle, &prop); + ok=(st>=0); + + if(!ok) + return; + + XSetTextProperty(ioncore_g.dpy, win, &prop, a); + XFree(prop.value); +} +#endif + /*}}}*/ @@ -437,6 +455,35 @@ void ioncore_x_set_text_property(int win, int atom, ExtlTab tab) } +#ifdef X_HAVE_UTF8_STRING +/*EXTL_DOC + * Set a UTF8_STRING property for a window. The fields of \var{tab} starting + * from 1 should be the different null-separated parts of the property. + * See the \code{XSetTextProperty}(3) manual page for more information. + */ +EXTL_EXPORT +void ioncore_x_set_utf8_property(int win, int atom, ExtlTab tab) +{ + char **list; + int i, n=extl_table_get_n(tab); + + list=ALLOC_N(char*, n); + + if(list==NULL) + return; + + for(i=0; i<n; i++){ + list[i]=NULL; + extl_table_geti_s(tab, i+1, &(list[i])); + } + + xwindow_set_utf8_property(win, atom, (const char **)list, n); + + XFreeStringList(list); +} +#endif + + /*}}}*/ diff --git a/ioncore/property.h b/ioncore/property.h index e1cd083..0e321c2 100644 --- a/ioncore/property.h +++ b/ioncore/property.h @@ -25,6 +25,10 @@ extern void xwindow_set_state_property(Window win, int state); extern char **xwindow_get_text_property(Window win, Atom a, int *nret); extern void xwindow_set_text_property(Window win, Atom a, const char **p, int n); +#ifdef X_HAVE_UTF8_STRING +extern void xwindow_set_utf8_property(Window win, Atom a, + const char **p, int n); +#endif extern bool xwindow_get_cardinal_property(Window win, Atom a, CARD32 *vret); #endif /* ION_IONCORE_PROPERTY_H */ -- 1.7.2.5 |
|
From: Arnout E. <no...@bz...> - 2011-05-14 16:26:25
|
On Fri, May 13, 2011 at 07:24:29AM -0400, Etan Reisner wrote: > I'm also open to simply having system.mk include (without failing if it > doesn't exit) a local.mk (or similar) file to allow these sort of > custom definitions. This sounds like an elegant solution to me - any drawbacks we can think of? Arnout |
|
From: <eb...@dr...> - 2011-05-14 14:41:30
|
On Sat, 14 May 2011 14:45:19 +0200 Ole Jørgen Brønner <ole...@ya...> wrote: > On Fri, 13 May 2011 13:24:29 +0200, Etan Reisner > <de...@un...> wrote: > > Well, what do other people do with git and local modifications? 'make > -f custom-makefile' ? > > > git has some sort of relevant mechanism: > http://dancingpenguinsoflight.com/2010/02/git-tip-ignoring-modifications-to-tracked-files/ > > - Ole That mechanism is good only as long as you don't want to commit some other changes in those files. I wanted to make some "public" changes in these files later, and after few tries I decided to do these changes in fresh clone of the repositor instead. -- Tomáš 'ebík' Ebenlendr PF 2011.36627473364 |
|
From: Ole J. B. <ole...@ya...> - 2011-05-14 12:45:31
|
On Fri, 13 May 2011 13:24:29 +0200, Etan Reisner <de...@un...> wrote: > On Fri, May 13, 2011 at 08:58:20AM +0200, Ole Jørgen Brønner wrote: >> Ah.. so that's what ac stands for :) > > Heh. > >> I have used system-ac.mk to avoid constant diffs from git/darcs since I need local changes in build configuration. >> >> Maybe there is another way to avoid that problem though? I guess git might have some sort of ignore mechanism for these kinds of things. > > Yeah, it occurred to me as I was writing my email that things like this > (and/or distributions wanting to package notion) could use system-ac.mk to > avoid needing to edit system.mk or use env vars. > > But I'm not convinced that's a useful enough reason to keep it around. > > I'm also open to simply having system.mk include (without failing if it > doesn't exit) a local.mk (or similar) file to allow these sort of > custom definitions. > > But this is exactly the sort of thing that caused me to send an email > about this before just making the change. > > -Etan > Well, what do other people do with git and local modifications? 'make -f custom-makefile' ? git has some sort of relevant mechanism: http://dancingpenguinsoflight.com/2010/02/git-tip-ignoring-modifications-to-tracked-files/ - Ole |
