Re: autotools gives autopain
BJörn Lindqvist wrote: > > 1) SCons intentionally ignores most standard *FLAGS (documentation says > > so). > According to the devs, that is a feature of scons. This page has a > workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings > Although I think your real problem is badly written SConstruct-files. Thanks for the link. It is a feature for reproducible building of a binary. For distribution-release packaging it is a problem - distribution maintainer needs to change the whole distribution by changing of a few variables (e. g. RPM_OPT_FLAGS -> CFLAGS). > > 2) It is hard to change hardwired default paths and change, say /usr/lib > > to /usr/lib64 for all packages. > I think you are being unfair to scons. Ofcourse it is not right to > hardwire architecture dependent paths in SConstruct-files, but that's > not a problem with scons, it's a problem with bad SConstruct files. It is a problem of both, most paths are hardwired in SConstruct files, the rest in SCons. My problem was http://sourceforge.net/tracker/index.php?func=detail&aid=1368255&group_id=30337&atid=398971 > Likewise, someone could hardwire installation paths in Makefiles. > Scons really is nothing more than a very nice make-replacement inside > a very nice programming language. A fairer comparision would be > bksys/scons (which kde is built with) against autotools/make. It means, that projects using scons without bksys are in the same situation as projects using make without autotools 10 years ago. Autotools were written just to prevent hardwired paths and features in makefiles. And bksys could change the quality of SConstruct files. >From the view of the package maintainer, I would prefer move from make+autotools to bksys+scons and discourage move from autools+make to plain scons. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SystemTray: docked Java Window size is too small
Hello, sorry for the delay. I tried this patch but unfortunately it does not work. Are there any other suggestions I could try? thank you very much in advance, stefan On Thursday 29 December 2005 23:57, Vincent Untz wrote: > Hi, > > Le mardi 27 décembre 2005 à 09:47 +0100, Stefan Walkner a écrit : > > Hello, > > > > I wrote a little JNI (Java native Interface) Shared Library for a Java > > Application (www.tvbrowser.org) which docks a Java Window into the X11 > > System Tray Area. > > This works fine under certain Windowmanagers/DEs (we tried KDE, Fluxbox, > > Xfce) - but in Gnome the docked window does not have the size 21x21 (as > > it should be) but there is a (about) 1-2px wide strip in the Systray Area > > instead. > > > > Unfortunately I was not able to track this problem down. > > The code can be found here: > > http://cvs.sourceforge.net/viewcvs.py/tvbrowser/tvbrowser/deployment/x11/ > >src/ > > > > jni_wrapper.c > just a file that handles the JNI calls and wraps them to > > functions declared in x11_systray_window.c > > > > It's not really much code - because the event handling etc are done in > > Java. I hope anyone is able to tell me why the size of the docked Window > > is not 21x21 as specified in the Standard. > > I think there must be a missing Xevent or Xfunction call... > > Does it work if you compile the notification area with the patch in > http://bugzilla.gnome.org/show_bug.cgi?id=108864 ? > > Vincent pgptNZoha4hA5.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SystemTray: docked Java Window size is too small
Hi, On Tue, January 3, 2006 13:55, Stefan Walkner wrote: > Hello, > > sorry for the delay. > I tried this patch but unfortunately it does not work. If it works in XFCE but doesn't work in GNOME with this patch, then there's really something weird since the patch should synchronize the GNOME code with the XFCE code. > Are there any other suggestions I could try? Well, you can open a bug. I would have thought that the patch would fix it, though. FWIW, it's been committed and it'll be in GNOME 2.13.4. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SystemTray: docked Java Window size is too small
Hello, > If it works in XFCE but doesn't work in GNOME with this patch, then > there's really something weird since the patch should synchronize > the GNOME code with the XFCE code. well I just tried again and it works in xfce 4.2.2 > Well, you can open a bug. I would have thought that the patch would > fix it, though. FWIW, it's been committed and it'll be in GNOME 2.13.4. Ok thank you very much for your help. I will try to track this down. But because this SystrayWindow is a Window executing Java Methods I would prefer another solution anyway. > QT Application starting Systray AND Java Program... something like that. thanks, stefan pgpeOKQQcrIxG.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libnotify and notification-daemon for GNOME 2.14
On Thu, 2005-12-08 at 23:17 -0500, John (J5) Palmieri wrote: > I'm in the middle of revamping the API and protocol. I'm just about to > do the first release this weekend. I have been stuck on D-Bus issues > which is why it has taken so long. We could possible go with the old > API and I could add a compatibility layer to the daemon since I am so > late in releasing it (this would suck) or we could start using the new > API and port the couple of apps that use it. It is pretty easy to use. > Take a look at the libnotify-ng and notify-daemon-ng packages in the svn > server on http://www.galago-project.org/. > anybody has changed any of the apps that use the old version to use the new one? -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libnotify and notification-daemon for GNOME 2.14
I believe gnome-power-manager has it in CVS. I'm making some quality changes to the internals today to address a couple of issues. I also have one of our guys looking at using the new stuff. (He has code for NetworkManager). On Tue, 2006-01-03 at 17:19 +0100, Rodrigo Moya wrote: > On Thu, 2005-12-08 at 23:17 -0500, John (J5) Palmieri wrote: > > I'm in the middle of revamping the API and protocol. I'm just about to > > do the first release this weekend. I have been stuck on D-Bus issues > > which is why it has taken so long. We could possible go with the old > > API and I could add a compatibility layer to the daemon since I am so > > late in releasing it (this would suck) or we could start using the new > > API and port the couple of apps that use it. It is pretty easy to use. > > Take a look at the libnotify-ng and notify-daemon-ng packages in the svn > > server on http://www.galago-project.org/. > > > anybody has changed any of the apps that use the old version to use the > new one? -- John (J5) Palmieri <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libnotify and notification-daemon for GNOME 2.14
On Tue, 2006-01-03 at 11:32 -0500, John (J5) Palmieri wrote: > I believe gnome-power-manager has it in CVS. > yes, it does > I'm making some quality > changes to the internals today to address a couple of issues. I also > have one of our guys looking at using the new stuff. (He has code for > NetworkManager). > we have already talked about it, but since not in public, here it is, for the record. For the -ng version, I love everything (great API), except one thing, which is the look of the bubbles. I liked it much better in the old version. Any possibility of using that instead of the yellow ones? Or at least have someone from the UI team look at it? -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-volume-manager behaviour
I began investigating this because I wanted to know if it was possible to tell gvm to only auto-mount a single partition on my firewire drive and not all five when I switch it on. Since then I have observed the following broken behaviour in the two simplest cases: Gnome menu -> Desktop -> Preferences -> Removable Drives and Media provides three check boxes: Mount removable drives when hotplugged Mount removable media when inserted Browse removable media when inserted With ALL of these checkboxes UNCHECKED, gnome-volume-manager mounts all the partitions on my firewire drive the *first* time I switch it on. With ALL of these checkboxes CHECKED, gnome-volume-manager will ONLY mount any of the partitions on my firewire drive the *first* time I switch it on. The following errors are reported in my kern.log on every subsequent switch-on: ieee1394: sbp2: Error reconnecting to SBP-2 device - reconnect failed ieee1394: sbp2: Logged out of SBP-2 device ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [1024] I'm aware these errors have nothing to do the gvm but they may explain why gvm appears to be broken in the second simplest case. Despite these errors, I can still mount, unmount and remount partitions manaually (using pmount) or using the Gnome Disk Mounter panel applet without any problems at all. sdt P.S. I think the dbus/hald/udevd/gvm hardware conspiracy is fantastic by the way. Keep up the good work. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf merged tree with split translations
Hi, I've switched this on by default now for the defaults database now. Please keep an eye out for any weird issues that might have been caused by this. Cheers, Mark. On Sun, 2005-12-11 at 15:38 +, Mark McLoughlin wrote: > Hey, > I've finally gotten around to committing some code[1] to implement the > conlusions wrt. GConf which we came to as a result of Lorenzo's > excellent analysis[2] > > Basically, the markup backend (in "merged tree" mode) now stores > translations of schema descriptions in separate per-locale files. The > idea is to load the entire GConf database in one go to avoid lots of > seeking, whilst also avoiding the overhead of loading the descriptions > of keys for locales which will never be used during the session. > > Hopefully, we'll switch this on for the defaults database for GNOME > 2.14. It'll need some further profiling and testing, though. > > To test it out, build and install GConf head (or apply the patch below) > and run: > > $> gconf-merge-tree $(prefix)/etc/gconf/gconf.xml.defaults > > The directory should then look like: > > drwxr-xr-x 55 markmc markmc4096 Nov 12 16:18 apps > drwxr-xr-x 3 markmc markmc4096 Nov 12 16:18 desktop > -rw-r--r-- 1 markmc markmc 141968 Nov 17 20:12 %gconf-tree-af.xml > -rw-r--r-- 1 markmc markmc 33759 Nov 17 20:12 %gconf-tree-am.xml > -rw-r--r-- 1 markmc markmc 573836 Nov 17 20:12 %gconf-tree-ar.xml > -rw-r--r-- 1 markmc markmc 494313 Nov 17 20:12 %gconf-tree-az.xml > ... > -rw-r--r-- 1 markmc markmc 3052624 Nov 25 10:19 %gconf-tree.xml > ... > drwxr-xr-x 5 markmc markmc4096 Nov 12 16:18 schemas > drwxr-xr-x 8 markmc markmc4096 Nov 12 16:18 system > > Hopefully, no-one should notice any difference aside from a shorter > login time. Please file bugs if any issues do crop up. > > Thanks, > Mark. > > [1] - > http://www.gnome.org/~markmc/code/gconf-merged-tree-split-translations.patch > [2] - http://www.gnome.org/~lcolitti/gnome-startup/analysis/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libnotify and notification-daemon for GNOME 2.14
Le mardi 03 janvier 2006 à 17:19 +0100, Rodrigo Moya a écrit : > anybody has changed any of the apps that use the old version to use the > new one? Ubuntu has patches for evolution/gnome-applets which are attached to bugzilla.gnome but not applied yet Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf merged tree with split translations
Le mardi 03 janvier 2006 à 17:32 +, Mark McLoughlin a écrit : > Hi, > I've switched this on by default now for the defaults database now. > Please keep an eye out for any weird issues that might have been caused > by this. hi, Do you have any plan to roll a new tarball of gconf with that? It would be nice for distros by example :) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote:
>>>According to the devs, that is a feature of scons. This page has a
>>>workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings
>>>Although I think your real problem is badly written SConstruct-files.
>>>
>>>
>>>
>>It may be the fault of the person writing the SConstruct file, but it is
>>a problem that is not often encountered for autoconf/automake projects.
>>
>>
>
>Indeed. But considering that the workaround is less than 15 characters
>to type and that the scons developers probably have some good reasons
>for not inheriting the environment by default I don't think it's much
>to argue about.
>
>
>
>>>I think you are being unfair to scons. Ofcourse it is not right to
>>>hardwire architecture dependent paths in SConstruct-files, but that's
>>>not a problem with scons, it's a problem with bad SConstruct files.
>>>Likewise, someone could hardwire installation paths in Makefiles.
>>>
>>>
>>>
>>Again, this is not a problem often seen for programs using
>>autoconf/automake for the build system, so it really sounds like scons
>>just makes it easier for a developer to shoot themselves in the foot.
>>
>>(this is probably a slightly unfair comparison though: I am sure there
>>are areas where scons makes it easier for developers to do the right thing).
>>
>>
>
>Yes it is. You are comparing apples with oranges.
>
>make = scons
>autotools = bksys/project specific Python/???
>
>I think I may have misrepresented scons in this thread. I wrote
>"replace Autotools with scons." But that's not really true. What I
>really meant was "replace Autotools/make with scons and a
>configuration system written in Python around it." Apologises about
>that.
>
>
Okay, so I think we can pretty much ignore scons on its own as a build
solution, and instead should talk about frameworks built on top of it
(like bksys, which you mentioned).
>>Are there any particular medium complexity packages you could point out
>>using bksys? Have those modules been packaged by any Linux distros? If
>>so, did they need to resort to any ugly workarounds?
>>
>>
>
>rosegarden, kdissert and codeine. rosegarden and kdissert are packaged
>by Ubuntu. No clue about ugly workarounds.
>
>
Rosegarden in Ubuntu appears to be built with autoconf/make. The
"kdissert" package does appear to be using scons to build, the basic
steps being:
SCONS = scons --no-cache -Q
$(SCONS) configure prefix=/usr
$(SCONS)
DESTDIR=... $(SCONS) install
So it looks like scons+bksys handles a destdir build quite well. I
didn't check very closely to see if things like CFLAGS were getting
propagated correctly.
It seems that the kdissert tarball includes the bksys files. Is that
the intended way to handle things? This doesn't necessarily count
against it when comparing to autoconf though: autoconf based packages
end up carrying around a big generated configure script).
As far as replacing autoconf-style functionality though, it looks like
the bksys checks for each library are fairly long-winded compared to
what I'd write in an autoconf configure.in script:
http://websvn.kde.org/trunk/KDE/kdelibs/bksys/
Would developers be required to write scripts like these for every
library or header they want to check for?
Also, I haven't checked to see whether bksys provides something that is
equivalent to "make distcheck".
>>The command Stanislav gave approximates this if all files for the
>>program fall under /usr, but would not be enough if some files should go
>>under e.g. /etc. A DESTDIR install should rebase every installed file.
>>
>>
>
>In scons, the rough equivalent would be:
>
>opts = Options()
>opts.AddPathOption("destdir", "Base path for installed files", "/")
>opts.Update(env)
>
>And then prefix all installation paths with env["destdir"].
>
>
This is the sort of thing I'd hope that the build system does
automatically for me. It gets done automatically by automake.
I get the feeling that scons plus something like bksys might be worth
considering in the future, but it seems a bit immature right now. I'm
sure it has benefits right now, such as removing libtool from the build
process (which takes up a noticeable amount of time in builds), but it
isn't clear that the benefits currently outweigh the switching costs.
James.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Quoting James Henstridge <[EMAIL PROTECTED]>: I get the feeling that scons plus something like bksys might be worth considering in the future, but it seems a bit immature right now. I'm sure it has benefits right now, such as removing libtool from the build process (which takes up a noticeable amount of time in builds), but it isn't clear that the benefits currently outweigh the switching costs. What about platforms where libtool is required? --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Davyd Madeley wrote: > Quoting James Henstridge <[EMAIL PROTECTED]>: > >> I get the feeling that scons plus something like bksys might be worth >> considering in the future, but it seems a bit immature right now. I'm >> sure it has benefits right now, such as removing libtool from the build >> process (which takes up a noticeable amount of time in builds), but it >> isn't clear that the benefits currently outweigh the switching costs. > > > What about platforms where libtool is required? Which platforms would they be? Don't all the platforms we support support shared libraries without libtool? My point above is that libtool-like functionality for abstracting the shared library build process should be possible from within an extensible build framework like scons. This eliminates the need to call a big-arse shell script that calls dozens of shell utilities (which is particularly slow on win32), so you just end up forking to call the compiler, linker, etc. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
