Re: menu editing griefs: How collaboration did not work. But it should work!
On 9/22/06, Christian Neumair <[EMAIL PROTECTED]> wrote: > Roughly at the same time, Travis Watkins wanted to have a feature-rich > menu menu editor [5], totally not modelled after Calum's proposal. It > was called smeg (and later renamed to alacarte), but more and more > converged to Calum's ideas. It was and is a good piece of software, but > it turned out to be the third implementation of the same concept with > some minor tweaks. When I started working on Alacarte I knew nothing about calum's design for a menu editor. By around version 0.6 I had it implemented like he drew it up and then went beyond that to remove the dialog/application confusion. I started work on alacarte independant from your work (I believe I started before Mark) because I had little confidence in my C skills and believed I could finish faster using Python. It still uses the gnome-menus library that all three of us put some sort of work into so it's not a complete loss. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: menu editing griefs: How collaboration did not work. But it should work!
On Fri, 2006-09-22 at 16:37 -0400, Christian Neumair wrote: > > Dear developer community. > > I'm a bit disappointed by how the GNOME menu editing journey went. Thanks Christian for sharing. This is indeed the kind of resource wastage that we really should avoid. -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
menu editing griefs: How collaboration did not work. But it should work!
Dear developer community. I'm a bit disappointed by how the GNOME menu editing journey went. In the very beginning, a menu editing API on top of the XDG menu spec was developed for GNOME, by Mark and Frederic, which was and still is a very clean and good API. I stepped up and implemented a C menu editor called gnome-menu-editor, entirely based on proposals Calum made [1] that were highly appreciated by the community. I invested lots of time into making it behave according to Calum's suggestions, it was really a fruitful task and we had a frequent exchange of thoughts and source code. It looked like we'd soon have a usable reference implementation. Suddently, shortly before the end of a development cycle, Mark came up with another menu editor [2], called gmenu-simple-editor, which was also based on Calum's proposal, but as far as I know Mark didn't really arrange detailed usability aspects with Calum. I wasn't sure why he came up with it, and supposed that he might have some different innovative ideas in mind, or maybe just preferred Python, but then again we could have used Alacarte as a base. Because Mark told me (in private) that my GUI wasn't simple enough, I shifted the advanced stuff into context menus. At some point the GUI exactly matched gmenu-simple-editor except for more features, which were only accessible through the context menu, shortcuts and DND, but now the UI didn't entirely match Calum's proposal anymore. >From the followup discussion to [2] ([3a], [3b]), it was very obvious that I were greedy for collaboration and exclusively interested in a great joined effort that would satisfy most of our users. I was even willing to blow my whole codebase away if it wouldn't match quality requirements. Make sure that you read these posts before presuming defamation. Unfortunately, time went by and I received no development feedback, just some user criticism, and no offers for collaboration. I got less and less enthusiastic, and not really integrated into platform/desktop development, although I tried to contribute as much as I could to gnome-menus improvements. gmenu-simple-editor was picked as GNOME menu editor, although it wasn't as feature-rich as gnome-menu-editor. Nevertheless, no discussion was raised at the ddl which menu editor should be picked, possibly because I failed to bring the issue up again - so it was also my fault, but maybe it should also have been brought up by other interested parties. I was very reluctant to initiate collaboration discussion again, because I made a blanket-check offer (read: [3a]), and it might have looked as if personal motives played a major role (i.e. pushing "my" implementation). gmenu-simple-editor still was exposed to many user rants. gnome-menu-editor was quite popular these days and is still on place 4 of the gnomefiles.org download statistics [4]. At this time I was quite pissed off and stopped gnome-menu-editor development, having spent many hours on it, and was very angry that my concerns were ignored. People had to install a gnome-* package, where something not included in the platform was installed, and a gmenu-* binary was shipped with a gnome-* package. Roughly at the same time, Travis Watkins wanted to have a feature-rich menu menu editor [5], totally not modelled after Calum's proposal. It was called smeg (and later renamed to alacarte), but more and more converged to Calum's ideas. It was and is a good piece of software, but it turned out to be the third implementation of the same concept with some minor tweaks. Short story: We had three implementations, and none was really perfect, until Alacarte became more mature and Calumistic (it's almost perfect now), and just became the default menu editor. But because there was no communication channel between the developing parties established, we just wasted many valuable hours. This (possibly one-sided) report shows us how collaboration does not work (lack of communication), and remind us that parallel development of core components with very similar targets in mind has to be watched carefully and as heavy redundance occurs, this should be brought up on the relevant development lists. I just want to make sure that something like this doesn't happen again, maybe for Alex Larsson's great ideas on the next generation of the GNOME VFS - so you may want to watch out for wasted efforts and point them out/bring them up as you encounter them. [1] http://www.gnome.org/~calum/usability/specs/menu-edit/ [2] http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00069.html [3a] http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00075.html [3b] http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00115.html [4] http://www.gnomefiles.org/app.php?soft_id=867 [5] http://www.realistanew.com/2005/03/18/gnome-menu-editor/ -- Christian Neumair <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On Fri, 2006-09-22 at 13:01 -0600, Elijah Newren wrote: > On 9/22/06, Elijah Newren <[EMAIL PROTECTED]> wrote: > > On 9/22/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > Don't get me wrong, it is of course great to have the latest bugfixes and > > > get > > > dbus release candidates widely tested, but if the focus is on answering > > > the > > > question: "can Gnome x.y be deployed on z ?" we should look at the hard > > > requirements (as in can not work with a version older than...). Maybe > > > we should split the list of external dependencies into required and > > > recommended versions. Then we could have e.g. a required dbus-glib > > > version of 0.70, but recommend 0.71. > > > > Sounds good to me... > > And done -- http://live.gnome.org/TwoPointSeventeen/ExternalDependencies > has been split into minimum versions and recommended versions, with > the minimum versions being lowered for the three tarballs you pointed > out and the recommended versions being bumped higher for the important > ones Kjartan pointed out. Looks good. Might be worth discussing libnotify now we are on the topic of library deps. For gnome-power-manager 2.17.1 I'm in the unpleasant situation of requiring CVS HEAD for libnotify to work 'correctly' because of a bug[1] in the latest release for the GtkStatusIcon handling. I think we should aim for libnotify-0.4.3 for 2-17 as it should be easier to compile than libvolume_id. That was a joke btw. JOKE! :-) On a more serious note, is libnotify "blessed" as a hard dep yet? Richard. [1] http://bugzilla.gnome.org/show_bug.cgi?id=356431 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
I think this question hits at the very heart of the issue with designing a whole new concept of "desktop." Not only do we have the whole mouse vs. keyboard issue, but as software, we are limited by what hardware our users have access to. We can design a system that takes advantage of pen computing, touch screens, holographic displays, and any other number of new input and display devices, but if we implement it, and let the classic "desktop" fall out of mind, we end up losing a large amount of our user base, when they don't all have the new hardware, when we release the new desktop. And I think for the current set of readily available and inexpensive hardware that people use and have access to, the current classic desktop metaphor is what works best. If we had had the ability to drive hardware development as well, we could do something a lot more extravagent with the "new desktop". In fact, it would be nice to move away from the idea of a "desktop" for one's computing experience alltogether, and move toward a more universal design, where you have many devices with similar interfaces, designed for specific tasks, which all integrate and co-operate with each other. Then your "desktop" would just be a common place where these devices can collaborate to sync information, charge, and do other similar things. But, as I said, doing something that interesting, requires the ability to drive hardware development as well as the software. -- dobey Më Pre , 2006-09-22 at 14:47 -0400, Willie Walker ka shkruar: > Pretty neat looking. At first blush, there seems to be a lot of > dependency on the mouse. I'm curious what your plans are for > keyboard-only access? > > Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
Thanks Jeff for the quick and right answer :) -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
Hello, > Pretty neat looking. At first blush, there seems to be a lot of > dependency on the mouse. I'm curious what your plans are for > keyboard-only access? Right. We completely ignore a11y. I think that's a mistake. When i thought about such Topaz design, i tried to forget existing desktop design and rethink of : How to make a computer as easy to use as your real desktop. This end up with similar concept as today (document ~= window), so keyboard shordcut should be quite similar. Would be nice to be able to choose toolbar layout like we do now, applied to dock layout too. The idea about docks. User must be able to switch docks/desktop like we switch panel/desktop now, and then, go thru items of docks. On selection, an item expand like a desklet, allowing to see some info (CPUs load, printjob status, battery level, etc.). That's an example I'm not an a11y guru at all. I don't even know well how things works today. (i'm just working on completing highcontrast icons). Don't know how Brian thought about that. Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
Hello, Why should Gnome 3 look and behave like Gnome 2 ? Isn't Gnome 3 the opportunity to make deep changes ? Something really cool in Gnome 2 is that since the beginning, it has a lot evolved but still inside a defined vision of the way to use a desktop. Gnome 3.0 shouldn't just break the API. Imho, we should change some design of the overall desktop. There is two way to design Gnoem 3. The one you seems to have is "What problem/lake do we have in Gnome 2 and how to fix the desktop design to hangle that". This mockup is more in the "What desktop de we want to have" way. I think that NeXT guys did something similar when they design NeXTStep. Finaly, Mac OS X looks quite similar to Mac OS 9, but is far easier to use. In the end, you can just pick the menubar layout and the popup handling and drop all that docks and tools. No problem. Please don't consider this mockup as normative. Also, i don't like the way Brian make me the most important author behind this mockup. Cheers, Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Elijah Newren <[EMAIL PROTECTED]> wrote: > On 9/22/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > Don't get me wrong, it is of course great to have the latest bugfixes and > > get > > dbus release candidates widely tested, but if the focus is on answering the > > question: "can Gnome x.y be deployed on z ?" we should look at the hard > > requirements (as in can not work with a version older than...). Maybe > > we should split the list of external dependencies into required and > > recommended versions. Then we could have e.g. a required dbus-glib > > version of 0.70, but recommend 0.71. > > Sounds good to me... And done -- http://live.gnome.org/TwoPointSeventeen/ExternalDependencies has been split into minimum versions and recommended versions, with the minimum versions being lowered for the three tarballs you pointed out and the recommended versions being bumped higher for the important ones Kjartan pointed out. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Joseph E. Sacco, Ph.D. <[EMAIL PROTECTED]> wrote: > As to your suggestion on how to proceed... We do think alike [:-)]. > Since there has been such a fuss raised over who should or should not > build libvolume_id, I have revisited automating the extraction of the > libvolume_id bits from udev. A GAR makefile to accomplish this is shown > below. David, as well as others within the community, should be > pleased. Awesome, thanks for the work. :-) > Time to move on. There will be other dragons to slay. Well, the build issue still bites jhbuild until there is either a separate libvolume_id tarball or someone gets similar hacks into jhbuild (or some other fix/workaround is found). James appears to be uneasy with trying to use current udev tarballs, judging from his previous email in this thread. Anyway, we also need to work that out before bumping the requirement. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
Pretty neat looking. At first blush, there seems to be a lot of dependency on the mouse. I'm curious what your plans are for keyboard-only access? Will On Fri, 2006-09-22 at 16:49 +0300, brian muhumuza wrote: > Hello there, > > I've posted some mockups of a ToPaZ desktop which i made in > collaboration with Étienne Bersac. I actually added onto Étienne's > original ideas. > > Inspiration was derived from the work flow in a typical office work > environment where we use a number of tools to perform a single task > i.e. pull an empty paper, pick a pen and write, then pick a pencil and > draw, then pick a paint brush and paint, etc. > > Here's the link: > > http://live.gnome.org/BrianMuhumuza/ToPaZ > > -- > > Happy day > > - > Brian > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
On Sat, 2006-09-23 at 04:19 +1000, Jeff Waugh wrote: > > > > Whatever crazy ideas people come up with, you can never guarantee that > > they are going to be universally better than what we currently have. As > > such, with something as completely, drastically different, I see no > > benefit in calling this GNOME 3.0. > > The reason we came up with "Topaz" was so that we could stop talking about > "GNOME 3.0". Don't think of forward-looking, out-of-the-box suggestions as > "GNOME 3.0", because it puts a whole different spin on your thought > processes. Ahh, fair play Jeff. :) Dream on! > > - Jeff > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > On 9/22/06, Joseph E. Sacco, Ph.D. <[EMAIL PROTECTED]> wrote: > > Mattias, > > > > I believe that you are correct [for the moment]. I took a quick look > > through apps in GARNOME-2.16.x dependent up dbus. I found that > > dbus-0.70, required by gnome-power-manager-2.17.1, appears to be good > > enough for now. > > > > Don't get me wrong, it is of course great to have the latest bugfixes and get > dbus release candidates widely tested, but if the focus is on answering the > question: "can Gnome x.y be deployed on z ?" we should look at the hard > requirements (as in can not work with a version older than...). Maybe > we should split the list of external dependencies into required and > recommended versions. Then we could have e.g. a required dbus-glib > version of 0.70, but recommend 0.71. Sounds good to me... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Kjartan Maraas <[EMAIL PROTECTED]> wrote: > > Available enforcement mechanism: > > If a module depends on either a new external dependency not listed > > here or a newer version of an external dependency than one listed > > here, we may revert to an older version of that module for Gnome > > 2.17.x (which may result in reversions of other modules too). The > > development version of that module can again be used once either > > this page is updated by the release-team or the new(er) external > > dependency is made optional. > > > Or we could make it a prerequisite for module maintainers to go through > the petition to get the dependency version bumped before adding the dep > in the module? That's exactly what the "Basics" part of the proposal does. This section just addresses the question of what happens if someone ignores the rule, or more likely forgets or isn't aware of that rule. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
On Fri, 2006-09-22 at 19:01 +0100, Alex Jones wrote: > Hey, Brian! > > Please don't take this the wrong way, but from what I can see, you might > as well not even call this GNOME! having seen the mock-ups, I'd say that Brian took the Gimmie UI and pumped it up on steroids; not that I say it's not borderline-crack in some parts, but I think it's a nice approach and at least there's some UI design process behind it. better than the people asking for a complete rewrite in XUL or high-level language just for the sake of it for sure. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
> Whatever crazy ideas people come up with, you can never guarantee that > they are going to be universally better than what we currently have. As > such, with something as completely, drastically different, I see no > benefit in calling this GNOME 3.0. The reason we came up with "Topaz" was so that we could stop talking about "GNOME 3.0". Don't think of forward-looking, out-of-the-box suggestions as "GNOME 3.0", because it puts a whole different spin on your thought processes. - Jeff -- Ohio LinuxFest 2006: Columbus OH, USA http://www.ohiolinux.org/ "Are you XFire's crazy girlfriend? And if so, shine on you crazy diamond!" - Paul Cameron ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > On 9/22/06, Rob Bradford <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > > > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > > The topic came up earlier, and I think there was a general consensus > > > > that it is a good idea to freeze the versions of external dependencies, > > > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > > > > > Due to the feedback received so far, I've modifed the exact wording of > > > the proposal and the list of versions a couple times so far. I > > > thought it'd be worth posting the most recent version and asking if > > > there was any further feedback on it or objections to it being > > > adopted: > > > > Ace. I created and populated: > > http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis > > > > Looking at this, and noticing that FC6 does not meet some of the requirement > made me wonder: what exacly are the reasons that we require > > dbus-glib0.71 > desktop-file-utils 0.11 > liboil 0.3.9 > > ? > > In particular the desktop-file-utils version seems pretty arbitrary, > since for all I > know the only change wrt to 0.10 was to switch to goption commandline > parsing... Yes, they are almost completely arbitrary. I didn't have the time to investigate the best versions of each, and often just took the latest release (figuring that it'd be better to get a cap on version number now than to stick with the current depend-on-cvs situation). I figured others could provide feedback on improvements, like you are doing. Anyway, if those older versions satisfy current dependencies, I'll be happy to downgrade those three. Does anyone see any others? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
On Fri, 2006-09-22 at 14:05 -0400, Luis Villa wrote: > On 9/22/06, Alex Jones <[EMAIL PROTECTED]> wrote: > > Hey, Brian! > > > > Please don't take this the wrong way, but from what I can see, you might > > as well not even call this GNOME! > > Not having seen the mockups at all, but... so? I believe we call that > 'thinking outside the box'. Whatever crazy ideas people come up with, you can never guarantee that they are going to be universally better than what we currently have. As such, with something as completely, drastically different, I see no benefit in calling this GNOME 3.0. > > Luis > > > On Fri, 2006-09-22 at 16:49 +0300, brian muhumuza wrote: > > > http://live.gnome.org/BrianMuhumuza/ToPaZ > > -- > > Alex Jones <[EMAIL PROTECTED]> > > > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
On 9/22/06, Alex Jones <[EMAIL PROTECTED]> wrote: > Hey, Brian! > > Please don't take this the wrong way, but from what I can see, you might > as well not even call this GNOME! Not having seen the mockups at all, but... so? I believe we call that 'thinking outside the box'. Luis > On Fri, 2006-09-22 at 16:49 +0300, brian muhumuza wrote: > > http://live.gnome.org/BrianMuhumuza/ToPaZ > -- > Alex Jones <[EMAIL PROTECTED]> > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
Hey, Brian! Please don't take this the wrong way, but from what I can see, you might as well not even call this GNOME! On Fri, 2006-09-22 at 16:49 +0300, brian muhumuza wrote: > http://live.gnome.org/BrianMuhumuza/ToPaZ -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 05:49 -0400, Richard Hughes wrote: > So I propose, tell maintainers to link against linguniqueapp (as it's > more sane that what we have already[1]) and then depreciate it in a > couple of years time when we've decided where it belongs. This means > maintainers like me get single-instance support *now*. It also means that even with deprecation, it will be used and shipped around for years to come, just because someone doesn't like depending on Gtk+ 2.12, or have not converted, or whatever. Copy/pasting is a superior solution if we know the code is going to be merged soonish. -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
David, You are welcome. The open source movement is all about "we", not "I". I will update GARNOME CVS-HEAD this weekend to give our users the opportunity to exercise HAL-0.5.8.1. Be well, -Joseph === On Fri, 2006-09-22 at 11:36 -0400, David Zeuthen wrote: > On Fri, 2006-09-22 at 09:38 -0400, Joseph E. Sacco, Ph.D. wrote: > > A GAR makefile to accomplish this is shown > > below. David, as well as others within the community, should be > > pleased. > > Awesome. Thanks for doing this! > > David > > -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On Fri, 2006-09-22 at 09:38 -0400, Joseph E. Sacco, Ph.D. wrote: > A GAR makefile to accomplish this is shown > below. David, as well as others within the community, should be > pleased. Awesome. Thanks for doing this! David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 02:12 -0600, Elijah Newren wrote: > On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > Uhm? Why not use X for IPC? > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > Bonobo, and Bacon (since there were several Gnome applications using > each of those for their single-instance mechanism) and X (which > Matthias brought up and also since Mozilla/Firefox uses it for its > single-instance mechanism). However, I no longer recall any details > about this particular choice since I was more interested in the WM > interaction details (surprise, surprise). It may have been that Vytas > was familiar with D-Bus and Bacon and we figured it was more important > to get other details worked out first, but I just don't remember. > > However, Vytas did design GUnique to make the backend easy to > transparently replace. I frequently use XNest at work. Some of the builds I have to run automatically open and close hundreds of windows. So I run the builds inside XNest, and I don't have to look at all those windows popping up on my screen. If I try to open an application inside XNest that I already have available outside XNest, and if that application uses one of our existing single-instance schemes (like bonobo), I get another window *outside* the XNest, which is annoying. Using X for IPC would, presumably, solve this. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Joseph E. Sacco, Ph.D. <[EMAIL PROTECTED]> wrote: > Mattias, > > I believe that you are correct [for the moment]. I took a quick look > through apps in GARNOME-2.16.x dependent up dbus. I found that > dbus-0.70, required by gnome-power-manager-2.17.1, appears to be good > enough for now. > Don't get me wrong, it is of course great to have the latest bugfixes and get dbus release candidates widely tested, but if the focus is on answering the question: "can Gnome x.y be deployed on z ?" we should look at the hard requirements (as in can not work with a version older than...). Maybe we should split the list of external dependencies into required and recommended versions. Then we could have e.g. a required dbus-glib version of 0.70, but recommend 0.71. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On Thu, 2006-09-21 at 23:09 -0400, Joseph E. Sacco, Ph.D. wrote: > GARNOME does not roll or maintain source tarballs for developers. But it's not so uncommon for GARNOME to patch its tarballs. Isn't that a possible solution to this awkwardness, even if it's just for GARNOME? > I do not know of any stable Linux distro that currently offers a new > enough version of udev that provides libvolume_id. At some point, > hopefully in the near future, this will change. Until that time, a > source tarball for libvolume_id will need to be made available in order > to build HAL-0.5.8.x. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
Mattias, I believe that you are correct [for the moment]. I took a quick look through apps in GARNOME-2.16.x dependent up dbus. I found that dbus-0.70, required by gnome-power-manager-2.17.1, appears to be good enough for now. -Joseph === On Fri, 2006-09-22 at 10:45 -0400, Matthias Clasen wrote: > On 9/22/06, Joseph E. Sacco, Ph.D. <[EMAIL PROTECTED]> wrote: > > I believe that liboil-0.3.9 has a number of bug fixes. It appears to > > have been released a day after 0.3.8 was released: > > > > [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K > > [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K > > [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K > > > > > > dbus-glib used to be packaged as part of dbus. It is now a dependency > > for HAL. > > > > Oh, I am aware of this. I am just questioning why we have to require > the newer version. Why is dbus-0.70 not good enough ? -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
oops... middle-aged eyesight... [blush..] On Fri, 2006-09-22 at 16:43 +0200, Kjartan Maraas wrote: > fre, 22,.09.2006 kl. 10.34 -0400, skrev Joseph E. Sacco, Ph.D.: > > I believe that liboil-0.3.9 has a number of bug fixes. It appears to > > have been released a day after 0.3.8 was released: > > > > [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K > > [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K > > [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K > > > That's two months and a day... > > Cheers > Kjartan > > -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Joseph E. Sacco, Ph.D. <[EMAIL PROTECTED]> wrote: > I believe that liboil-0.3.9 has a number of bug fixes. It appears to > have been released a day after 0.3.8 was released: > > [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K > [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K > [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K > > > dbus-glib used to be packaged as part of dbus. It is now a dependency > for HAL. > Oh, I am aware of this. I am just questioning why we have to require the newer version. Why is dbus-0.70 not good enough ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
fre, 22,.09.2006 kl. 10.34 -0400, skrev Joseph E. Sacco, Ph.D.: > I believe that liboil-0.3.9 has a number of bug fixes. It appears to > have been released a day after 0.3.8 was released: > > [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K > [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K > [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K > That's two months and a day... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
tor, 21,.09.2006 kl. 16.51 -0600, skrev Elijah Newren: > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > The topic came up earlier, and I think there was a general consensus > > that it is a good idea to freeze the versions of external dependencies, > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > Due to the feedback received so far, I've modifed the exact wording of > the proposal and the list of versions a couple times so far. I > thought it'd be worth posting the most recent version and asking if > there was any further feedback on it or objections to it being > adopted: > > The basics: > The versions of external dependencies that Gnome module may depend > upon are listed on a link from the release schedule > (http://live.gnome.org/TwoPointSeventeen/External Dependencies, > for this release). It may be updated at any time by the > release-team. > Looks very good. > Getting the list updated: > If you want to add a new dependency or want one of the versions > updated, make a good case for it on desktop-devel-list. In > particular, provide reasons why it is important to bump the > version number, explain any impact (compile and run time) on other > modules, and list any additional external dependencies it would > pull in. Be prepared for others to take a few days to test it (in > particular, to ensure it builds) before giving a thumbs up or > down. > I'd like to see fontconfig updated to 2.4.1 since 2.4.0 lost API by accident. Also GnuTLS seems to have had a few releases with fixes for security issues in the 1.4.x series that we might want to look at. Other possible updates: - dbus: 0.93 contains a bunch of bugfixes and we probably want to help push dbus along towards a quality 1.0 release. - libgpg-error: 1.4 has some changes but nothing that is compelling enough to bump it I guess - libgcrypt: 1.2.3 has some minor bugfixes, not needed IMO - libmusicbrainz: 2.1.4 fixes buffer overflows and memory leaks so I would want to use that - libtasn: 0.3.6 has a bunch of bugfixes over 0.3.4, but I don't know if this is something we actually use or if it's just pulled in by gnutls. - opencdk: 0.5.9 has a few minor bugfixes and build fixes it seems - poppler: 0.5.4 fixes a bunch of bugs including crashes, build fixes, rendering issues, etc My impression is that we should bump fontconfig, dbus, poppler, libmusicbrainz and possibly gnutls at least. > Available enforcement mechanism: > If a module depends on either a new external dependency not listed > here or a newer version of an external dependency than one listed > here, we may revert to an older version of that module for Gnome > 2.17.x (which may result in reversions of other modules too). The > development version of that module can again be used once either > this page is updated by the release-team or the new(er) external > dependency is made optional. > Or we could make it a prerequisite for module maintainers to go through the petition to get the dependency version bumped before adding the dep in the module? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
fre, 22,.09.2006 kl. 12.03 +0200, skrev Rob Bradford: > On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > The topic came up earlier, and I think there was a general consensus > > > that it is a good idea to freeze the versions of external dependencies, > > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > > > Due to the feedback received so far, I've modifed the exact wording of > > the proposal and the list of versions a couple times so far. I > > thought it'd be worth posting the most recent version and asking if > > there was any further feedback on it or objections to it being > > adopted: > > Ace. I created and populated: > http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis > > for Debian. > And I added two columns for FC 5 and FC devel Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
I believe that liboil-0.3.9 has a number of bug fixes. It appears to have been released a day after 0.3.8 was released: [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K dbus-glib used to be packaged as part of dbus. It is now a dependency for HAL. -Joseph On Fri, 2006-09-22 at 10:17 -0400, Matthias Clasen wrote: > On 9/22/06, Rob Bradford <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > > > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > > The topic came up earlier, and I think there was a general consensus > > > > that it is a good idea to freeze the versions of external dependencies, > > > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > > > > > Due to the feedback received so far, I've modifed the exact wording of > > > the proposal and the list of versions a couple times so far. I > > > thought it'd be worth posting the most recent version and asking if > > > there was any further feedback on it or objections to it being > > > adopted: > > > > Ace. I created and populated: > > http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis > > > > Looking at this, and noticing that FC6 does not meet some of the requirement > made me wonder: what exacly are the reasons that we require > > dbus-glib0.71 > desktop-file-utils 0.11 > liboil 0.3.9 > > ? > > In particular the desktop-file-utils version seems pretty arbitrary, > since for all I > know the only change wrt to 0.10 was to switch to goption commandline > parsing... > > Matthias > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Empowering platform developers [Was: GUnique]
Richard Hughes wrote: > No stick taken :-) For me, is the dependency issue. Can gtk+ depend on > DBUS? If the answer is yes, then the decision is a no-brainer - put > libguniqueapp into gtk. > Remember the question isn't just "can it depend" but how, cf. http://mail.gnome.org/archives/gnomecc-list/2006-September/msg00025.html My opinion (fwiw, maybe not much) is that the X11 backend of GDK should have an optional dependency on dbus, since dbus is how we're proposing you canonically do certain things on the platform (while on win32 these things might be canonically done with syscalls or COM but not with dbus, since on win32 dbus is not the "native" API). By optional I mean both compile-time and runtime: - check for HAVE_DBUS similar to the checks for various X extensions - at runtime, continue in some way if the session bus is not running, perhaps minus certain functionality or falling back to X hacks Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Alexander Larsson wrote: > One advantage of using X would be that it works for remote X clients > too. > I think it'd be a mistake to start using X for all ipc for that reason - you'd end up never using dbus, and X is kind of a sucky IPC. To solve this for dbus there are two basic approaches, one is to make ssh forward DBUS_SESSION_BUS_ADDRESS and have the session bus listen on tcp, the other is to write an X11 transport that tunnels a bus connection through X. Neither is very hard in theory though I grant neither is already done. The dbus bus name stuff is essentially designed for the unique app use-case - though, I grant it's modeled on X selections which are also essentially designed for this use-case. Either way, I think it's important to make the bus name or X selection name look "sane" when not used through the GUnique interface, i.e. on dbus the bus name for Evolution should be something like "org.gnome.Evolution" and on X the selection name should be something like "_GNOME_EVOLUTION_INSTANCE" (btw, in both cases a --replace mode would be nice, especially for debugging, and is natively/easily supported) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 9/22/06, Rob Bradford <[EMAIL PROTECTED]> wrote: > On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > The topic came up earlier, and I think there was a general consensus > > > that it is a good idea to freeze the versions of external dependencies, > > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > > > Due to the feedback received so far, I've modifed the exact wording of > > the proposal and the list of versions a couple times so far. I > > thought it'd be worth posting the most recent version and asking if > > there was any further feedback on it or objections to it being > > adopted: > > Ace. I created and populated: > http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis > Looking at this, and noticing that FC6 does not meet some of the requirement made me wonder: what exacly are the reasons that we require dbus-glib0.71 desktop-file-utils 0.11 liboil 0.3.9 ? In particular the desktop-file-utils version seems pretty arbitrary, since for all I know the only change wrt to 0.10 was to switch to goption commandline parsing... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
ToPaZ, anyone?
Hello there, I've posted some mockups of a ToPaZ desktop which i made in collaboration with Étienne Bersac. I actually added onto Étienne's original ideas. Inspiration was derived from the work flow in a typical office work environment where we use a number of tools to perform a single task i.e. pull an empty paper, pick a pen and write, then pick a pencil and draw, then pick a paint brush and paint, etc. Here's the link: http://live.gnome.org/BrianMuhumuza/ToPaZ-- Happy day-Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
Jürg, Thank you for introducing me to yet another GNU/Linux distro. Variety and innovation are things I truly love about the open source movement. The issue with HAL-0.5.8.x is one of timing. David jumped the gun by removing the source code for libvolume_id from HAL. Had he waited a few months, or rolled up the libvolume_id source into a separate tarball, there would have never been an issue. I am currently running HAL-0.5.8.1 within GARNOME-2.16.x on a PPC running YDL-4.1 [an FC4 clone]. In order to build HAL, I built udev-100 in a "sandbox" within the GARNOME build environment and manually extracted the necessary libvolume_id bits. At that time, I noted that I could automate the extraction process since GARNOME framework supports "custom" configure, build, and install targets. As to your suggestion on how to proceed... We do think alike [:-)]. Since there has been such a fuss raised over who should or should not build libvolume_id, I have revisited automating the extraction of the libvolume_id bits from udev. A GAR makefile to accomplish this is shown below. David, as well as others within the community, should be pleased. Time to move on. There will be other dragons to slay. Kind regards, -Joseph = [GAR makefile to biuld and install libvolume_id bits from udev] GARNAME = udev GARVERSION = 100 CATEGORIES = freedesktop DISTFILES = $(GARNAME)-$(GARVERSION).tar.gz MASTER_SITES = http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/ DESCRIPTION = libvolume_id define BLURB Build and extract the libvolume_id bits from udev. endef BUILD_SCRIPTS = custom INSTALL_SCRIPTS = custom CONFIGURE_ARGS = $(DIRPATHS) include ../category.mk build-custom: @cd $(WORKSRC) && make EXTRAS=extras/volume_id prefix=$(prefix) @$(MAKECOOKIE) install-custom: @cd $(WORKSRC) && make -C extras/volume_id prefix=$(prefix) \ install-bin install-man @$(MAKECOOKIE) == On Fri, 2006-09-22 at 05:44 +, Jürg Billeter wrote: > On Don, 2006-09-21 at 23:09 -0400, Joseph E. Sacco, Ph.D. wrote: > > GARNOME does not roll or maintain source tarballs for developers. > > > > I do not know of any stable Linux distro that currently offers a new > > enough version of udev that provides libvolume_id. At some point, > > hopefully in the near future, this will change. Until that time, a > > source tarball for libvolume_id will need to be made available in order > > to build HAL-0.5.8.x. > > paldo[1] provides udev-096 in stable (and udev-100 in testing). So now > you know of one... > > Why can't GARNOME just call these commands in the unpacked udev tarball? > (possibly adding prefix to the install) > > make EXTRAS="extras/volume_id" > make -C extras/volume_id/lib install > > Jürg > > [1] http://www.paldo.org/ > > -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Hi; On Fri, 2006-09-22 at 13:49 +0200, Alexander Larsson wrote: > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > > Bonobo, and Bacon (since there were several Gnome applications using > > each of those for their single-instance mechanism) and X (which > > Matthias brought up and also since Mozilla/Firefox uses it for its > > single-instance mechanism). However, I no longer recall any details > > about this particular choice since I was more interested in the WM > > interaction details (surprise, surprise). It may have been that Vytas > > was familiar with D-Bus and Bacon and we figured it was more important > > to get other details worked out first, but I just don't remember. > > > > However, Vytas did design GUnique to make the backend easy to > > transparently replace. > > One advantage of using X would be that it works for remote X clients > too. Right now, GUniqueApp depends on a compile-time check for D-Bus and a run-time check between D-Bus (if support was compiled in) and Bacon (as a fallback). In order to add it to GTK+ a Xlib default IPC should be used[1], and I'd suggest to use modules loadable at run-time for the other transports, like D-Bus. We'd also have to use something on win32 and OSX, even though I think that other platforms already have facilities for this kind of stuff. +++ [1] We could define a spec with some default properties, like: _G_UNIQUE_VERSION integer, in form 0x%02d%02d%02d _G_UNIQUE_NAMEUTF-8 string _G_UNIQUE_STARTUP_ID string _G_UNIQUE_COMMAND integer _G_UNIQUE_DATAstring which maps the protocol used by the current GUniqueApp implementation as far as I can see. The _VERSION property could be used for versioning, in case we'd add some new commands. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 02:12 -0600, Elijah Newren wrote: > On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > Uhm? Why not use X for IPC? > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > Bonobo, and Bacon (since there were several Gnome applications using > each of those for their single-instance mechanism) and X (which > Matthias brought up and also since Mozilla/Firefox uses it for its > single-instance mechanism). However, I no longer recall any details > about this particular choice since I was more interested in the WM > interaction details (surprise, surprise). It may have been that Vytas > was familiar with D-Bus and Bacon and we figured it was more important > to get other details worked out first, but I just don't remember. > > However, Vytas did design GUnique to make the backend easy to > transparently replace. One advantage of using X would be that it works for remote X clients too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a maverick vegetarian photographer on his last day in the job. She's a blind communist hooker who hides her beauty behind a pair of thick-framed spectacles. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On Fri, 2006-09-22 at 12:03 +0200, Rob Bradford wrote: > On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > The topic came up earlier, and I think there was a general consensus > > > that it is a good idea to freeze the versions of external dependencies, > > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > > > Due to the feedback received so far, I've modifed the exact wording of > > the proposal and the list of versions a couple times so far. I > > thought it'd be worth posting the most recent version and asking if > > there was any further feedback on it or objections to it being > > adopted: > > Ace. I created and populated: > http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis Now with FC5 & Rawhide by Kjartan Maraas. Even more ace. Cheers, Rob -- Rob Bradford <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On 22/09/06, David Zeuthen <[EMAIL PROTECTED]> wrote: > On Thu, 2006-09-21 at 23:09 -0400, Joseph E. Sacco, Ph.D. wrote: > > GARNOME does not roll or maintain source tarballs for developers. > > > > I do not know of any stable Linux distro that currently offers a new > > enough version of udev that provides libvolume_id. At some point, > > hopefully in the near future, this will change. Until that time, a > > source tarball for libvolume_id will need to be made available in order > > to build HAL-0.5.8.x. > > There is. It's called udev. You can download it from here > > http://kernel.org/pub/linux/utils/kernel/hotplug/ > > It's not really my fault GARNOME can't handle this. Sorry. I'm not going > to carry extremely security sensitive code (that introduces attack > vectors like root exploits via USB keys) with all the fun that entails > like coordinated releases, embargo fun and what not, just because > GARNOME lacks a feature. > > I hope you realize what a silly thing you are asking me to do. > > Release team: Please apply cluebat. Thanks. Given that a lot of this thread has been about making things easier to build, I can understand Joseph's complaints. While most of the stack people build for testing Gnome use roughly the same build infrastructure, udev has it's own setup which doesn't seem as well suited to building in a non-default prefix. Here are some notes on trying to do this: 1. it doesn't use the standard autoconf setup, but that isn't too surprising since it isn't intended to be portable. 2. Running "make" doesn't appear to build libvolume_id -- just the basic udev utilities. Consulting the README file indicates that I was really meant to run "make EXTRAS=extras/volume_id". 3. Using the "make install-bin" target attempts to delete a bunch of files under /dev and restart a system daemon (it ignores the errors when this fails due to me not being root -- I wouldn't want to include this sort of thing in a build script that other people will run). 4. You can set the prefix variable when installing things to $prefix/usr/lib, $prefix/usr/bin, etc. It looks like setting includedir and usrlibdir and a few others might do the right thing though. The README file doesn't really mention any of this, so it isn't clear that it'd continue to work with new versions, or might need new/different variables. Now given that I don't really care about the rest of udev here, it might be easier to just build in "extras/volume_id/lib", but the Makefile in that directory doesn't seem complete: relying on a bunch of variables defined in the calling Makefile (from an initial look, Q, E and RANLIB at a minimum). The installation issues are the same for this method of building. So I can understand wanting to either rely on a distro installed libvolume_id, or rely on some package other than udev to provide the library (which is effectively what Joseph is doing by using the older hal). James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Empowering platform developers [Was: GUnique]
On Fri, 2006-09-22 at 20:03 +1000, Jeff Waugh wrote: > > > > I also think one of the reasons it was not written with gtk+ as a target > > was the "level choice" i.e. does this stuff belong in gtk+, libgnome, > > or some other module. > > It's really important we put a lid in this kind of confusion quickly, so we > can breathe life back into coherent platform design and development. It is a > serious problem when some of our best hackers don't feel empowered to design > for a particular target: Seriously, why *wouldn't* GTK+ be the correct place > to solve this *obviously* important use case (how many apps on our desktop > or embedded environments do or should need this functionality - heaps)? > > I'm not giving you stick here, Richard... although reading back I realise it > may sound that way. Mostly, I'm rocking the boat to find out how we can do > platform design and development in a more coherent way. Is the GTK+ team too > scary? Are GNOME platform requirements incompatible with GTK+ at all? Can we > build a better bridge between the projects? How can we break the cycle of > bollocks solutions like libegg and so on? How do we empower platform hackers > to make decisions and Get Things Done? No stick taken :-) For me, is the dependency issue. Can gtk+ depend on DBUS? If the answer is yes, then the decision is a no-brainer - put libguniqueapp into gtk. If the answer is no[1], then we need something higher in the stack like libgnome, although I agree that it is not the preferred solution. Also, I want stuff to work *now*, not in 18 months time with a gtk+ module that (for me at least) is far on the horizon. The 'temporary' shared module gives us that. Thanks. Richard [1] or maybe, or "we probably need to ifdef stuff just in case..." ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Empowering platform developers [Was: GUnique]
> I also think one of the reasons it was not written with gtk+ as a target > was the "level choice" i.e. does this stuff belong in gtk+, libgnome, > or some other module. It's really important we put a lid in this kind of confusion quickly, so we can breathe life back into coherent platform design and development. It is a serious problem when some of our best hackers don't feel empowered to design for a particular target: Seriously, why *wouldn't* GTK+ be the correct place to solve this *obviously* important use case (how many apps on our desktop or embedded environments do or should need this functionality - heaps)? I'm not giving you stick here, Richard... although reading back I realise it may sound that way. Mostly, I'm rocking the boat to find out how we can do platform design and development in a more coherent way. Is the GTK+ team too scary? Are GNOME platform requirements incompatible with GTK+ at all? Can we build a better bridge between the projects? How can we break the cycle of bollocks solutions like libegg and so on? How do we empower platform hackers to make decisions and Get Things Done? - Jeff -- Ohio LinuxFest 2006: Columbus OH, USA http://www.ohiolinux.org/ "Not a lot of brothers there." - Jamie Foxx on Australia ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: > On 9/11/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > The topic came up earlier, and I think there was a general consensus > > that it is a good idea to freeze the versions of external dependencies, > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. > > Due to the feedback received so far, I've modifed the exact wording of > the proposal and the list of versions a couple times so far. I > thought it'd be worth posting the most recent version and asking if > there was any further feedback on it or objections to it being > adopted: Ace. I created and populated: http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis for Debian. Cheers, Rob -- Rob Bradford <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Thu, 2006-09-21 at 19:36 -0600, Elijah Newren wrote: > I agree that we don't really want another shared library, long term. > Luckily, it should be easy to update apps when GUnique becomes part of > some other library, as the code required to use GUnique is pretty > small. As to how we get there, though, Matthias and others with more > knowledge of the platform stack will need to comment. First, sorry for branching the thread. If we use linguniqueapp as a shared library we can use it in applications now (2.17), and during the 2.18 cycle. If libguniqueapp is included in gtk+ at some state (and GNOME depends on this new version) then I think it is very sane to "convert" apps to use the new gtk feature and depreciate libguniqueapp. Think like eggtrayicon to GtkStatusIcon, only less copy and paste ;-) I also think one of the reasons it was not written with gtk+ as a target was the "level choice" i.e. does this stuff belong in gtk+, libgnome, or some other module. So I propose, tell maintainers to link against linguniqueapp (as it's more sane that what we have already[1]) and then depreciate it in a couple of years time when we've decided where it belongs. This means maintainers like me get single-instance support *now*. Just my opinion tho. Richard. [1] Which are lots of hacks IMO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > Uhm? Why not use X for IPC? *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, Bonobo, and Bacon (since there were several Gnome applications using each of those for their single-instance mechanism) and X (which Matthias brought up and also since Mozilla/Firefox uses it for its single-instance mechanism). However, I no longer recall any details about this particular choice since I was more interested in the WM interaction details (surprise, surprise). It may have been that Vytas was familiar with D-Bus and Bacon and we figured it was more important to get other details worked out first, but I just don't remember. However, Vytas did design GUnique to make the backend easy to transparently replace. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
> Uhm? Why not use X for IPC? Because clearly you would be hit by a bus if you considered such outrageous notions. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "Whatcha wanna be when you grow up?" "Eight and a half." ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Thu, 2006-09-21 at 19:36 -0600, Elijah Newren wrote: > On 9/21/06, Jeff Waugh <[EMAIL PROTECTED]> wrote: > > Before recommending that everyone use GUnique, could we define a > > migration path for it to enter the platform? We really don't need yet > > another > > shared library, and yet another module to release, and yet another separate > > API to learn. Is this API appropriate for GTK+ and adaptable for use with > > Windows and OS X? > > > > Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and > > plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least > > have a plan for it, otherwise we're just adding yet another [as above] with > > little active thought for our users, distributors and platform consumers. > > You're asking all the right questions. Unfortunately, I don't have > complete answers. > > IIRC (which is questionable), the biggest potential issue with it > being in GTK+ was its IPC mechanism. In fact, Vytautas decided to put > two IPC mechanisms into it partially because of this (Matthias was not > sure GTK+ was ready to depend on D-Bus yet, so Vytas made it possible > to use either D-Bus or Bacon, chosen at compile time). Uhm? Why not use X for IPC? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a benighted drug-addicted gangster fleeing from a secret government programme. She's a pregnant streetsmart soap star from a secret island of warrior women. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
